Quote:

Actually it can be done anywhere Andreas.
You might want to look at how some Z80 systems do it, it can really get strange there.
But no, there is no restraint on where to map I/O.
At the top of memory is a common spot, but hardly a requirement.

[ Edited by Jim 28.08.2015 - 13:45 ]

>>>> The address space between 1.5 and 2.0 GiB is used to map and access the memory
>>>> of on-board and expansion hardware. That's why the OS can't use it as system RAM
>>>> and it's also why 32-bit addressing would give us access to 3.0 to 3.5 GiB
>>>> system RAM instead of the entire 4 GiB.

>>> True, but I'm not even considering moving mapped I/O (which could be placed anywhere
>>> in the 32bit map).

>> Huh? Where would you place the mapped I/O on a 32-bit system if not in the upper
>> address space between 3.0/3.5 GiB and 4.0 GiB? I don't think there are options.

> Actually it can be done anywhere Andreas. [...] there is no restraint on where to
> map I/O. At the top of memory is a common spot, but hardly a requirement.

Yes, of course it can be done. But what would be the point? You'd still have only 3.0 to 3.5 GiB available RAM on a 32-bit system, as I said, not 4 GiB, even if you place the mapped I/O in the lower address space or in the middle or anywhere else. You started talking about "moving mapped I/O" and I really don't get the point of that in the context of what we discussed.

Well, you are not really following what I said then, Andreas.
What I was suggesting is rather similar to the kludge performed on MS-DOS once the need for more than 640K of memory became apparent and the developers wished to retain compatibility with legacy apps.
Anyone remember himem and extended memory?
The basic 640K memory map of MS-DOS remained unchanged including I/O, and routines were developed to utilize memory above that range.

This is NOT the elegant solution offered by the clean board design proposed for X64 MorphOS.
Its not even what could be done with a more complete reworking of PPC MorphOS.
Its a quick and dirty hacking solution that could be implemented with less work.

And we wouldn't have 3.5GBs of memory with this, we'd have 1.5GB devoted to legacy MorphOS apps, a half gig for OS and I/O functions, with another 2GB for any weird shit we can think of.

Remember, processes outside of MorphOS' address space, even those that might run on other cores can still read and write to the memory used by MorphOS giving us some interesting possibilities for increased functionality.

And...if 64bit and 32bit operations are possible concurrently, well our are options are even greater.

[ Edited by Jim 29.08.2015 - 07:26 ]

@Jim

There won't be any 32-bit MorphOS, period, and you have proved to yourself and others why not, so please stop this useless walk through ancient x86 computer history, there is no point...

Please correct me if I'm wrong, but currently the whole system is running in ABox, using legacy and rewritten PPC librarys filesystem handling, etc...

If the architecture is changed (and ABox is droped), how will the system look like? What kind of API's will present to handle Sound, Video, etc. Probably the limiting things shouldn't be carried further... SMP should introduce. I think, It's a much bigger work, than it seems.

Quote:

So basically something similar that was announced for AmigaOS4? I'd avoid any such "dirty hacks".

Of course a good compromise could be to use the "unusable" memory internally by the OS, so it won't be exposed to end users and 3rd party developers.

Quote:

YES!
I'm not worried about the ISA shift and will follow the development team once its ready.
I really trust these guys, they have great judgement and are some of the best programmers I have as yet come to know.
BUT, I still want to know where our current OS can be pushed.
AND I can't advocate a full overhaul of the PPC code as its a commitment to additional work that I can't ask the developers to make.
SO...the hacking solutions.

BTW - As far as I can tell, we already have the ability to read and write upper memory locations, we just don't have support to run code there.
So, how about giving us an option to move the ram disk there?

As to "ancient history", you learn from history or you repeat its mistakes.
I never really thought knowledge of old DOS systems would prove useful, but it has.

AND as Linux seems so annoyingly popular, it seems necessary to remind some that it is a thinly disguised rip off of UNIX and UNIX dates back to my childhood.
There more than a little value in knowing "ancient" history.
I may be venerable, but in terms of the evolution of computing we just got started with personal computers when I was a old adult and we're just started.
The utility I promised everyone in the early days is here, but we are still going to see VAST changes.

> What I was suggesting is rather similar to the kludge performed on MS-DOS

So you were essentially suggesting keeping MorphOS/A-Box as 31-bit OS and making use of the 2 GiB above by other means. I thought you were talking about a true 32-bit OS. Thanks for clarification.

> So basically something similar that was announced for AmigaOS4?

Is ExtMem not available in OS4.1FE yet?

> Linux [...] is a thinly disguised rip off of UNIX

Linux is as much a Unix rip-off as MorphOS is an AmigaOS rip-off :-)

Quote:

I don't know, MorphOS is quite an upgrade.
UNIX to Linux? Not as much.
There are some great UNIX descended BSD derivatives out there right now (including OSX) that give Linux more than a run for its money.

In any case, yes what I was proposing was to leave the body of MorphOS in the 31 bit space of Abox while adding code outside in either 32 or 64 bit memory.
That doesn't preclude a latter revision to PPC MorphOS, but it would allow some neat hacks to be created.

And if PPC MorphOS is to be relegated to a hobbyist OS, what is wrong with hacking?
Isn't that where most of our programmers started, hacking Amiga systems?

Quote:

Will PPC MorphOS be open sourced if developers stop working on it once they port to X64? I do not want to see PPC MorphOS abandoned entirely.

Quote:\

T'would be nice, but I doubt it.
However, there has been no announcement that PPC MorphOS would be completely abandoned.
Obviously, the primary focus will shift to the AMD64 platform.
But in the meanwhile we have been told we are still to receive some interesting upgrades.
It has been announced that there will be an X5000 port.
And I'd expect to see better support of the Radeon HD series.

Plus do you really think that this will fade that quickly or that its not going to steadily improve during this period of transition?

Quote:
From publically available information nothing has been set in stone yet. But I guess and hope the new API would be as similar to the old API as possible. Of course there are significant changes necessary. And there are things that should be replaced anyway because they are too limited (e.g. AHI).

Quote:
That's part of the reason for the system change. One thing is to use popular powerful hardware, the other is to actually use it and, while sacrifying compability anyway, get rid of the limitations in current MorphOS API.

I think one of the best advancements of the last years was Reggae which more powerful and future proof than (already brillant Datatypes). It is a functional replacement/improvement of an OS part, but it requires a new API. In current ABox Datatypes and Reggae coexist - dropping Datatypes would be no good. But when MorphOS NG drops backward compability anyway things where better improvements exists could get abandoned to clean up the OS.

Quote:

Precisely. It remains to be seen whether there'll be some (emulated?) compatibility layer for legacy stuff.

Quote:

It's already been said many times: no, MorphOS will not become open source. There are too many licensing issues involved.

Update:

> Is ExtMem not available in OS4.1FE yet?

"the Software Development Kit (SDK) for the largely successful AmigaOS 4.1 Final Edition [...] enables third party developers to access all the enhancements and new features added in AmigaOS 4.1 Final Edition including:
[...]
- Extended memory which goes beyond the 4 GB memory barrier.
[...]"
http://www.hyperion-entertainment.biz/index.php/news/36-amigaos-4x/163

Quote:

if there's no compatibility layer what would be the programming API? Something completely new or existing non Amiga API/Framework?
If this have been decided? If a new API/Framework is written/choosen then developer should be aware to prepare the transition a bit like what Apple did with Carbon to Cocoa.

Kamelito