I used bolted on because it’s not transparent (I consider it a hack). AFAIK you have to explicitly use the new API for allocating memory, old/proprietary software for which source is not available will not benefit, which is unfortunately most of the software catalogue.

Also,

“System 7.1.2 for PowerPC was basically a paravirtualized operating system running inside emulation”

I remember running a stripped down MacOS 8 under ShapeShifter on my Amiga 4000 with 68060, and a full System 7.1, the first PPC MacOS was 8.1, not 7.1.

Incidentally, an Amiga with a 68060 expansion card could run MacOS faster than any real 68k Macintosh since the fastest 68k Macs had 68040 CPUs :)

You are wrong. The full OS3.1 sources is handled by Olaf Barthel, who
is part of the OS4 development team.
It’s some parts of the OS3.5 and OS3.9 sources that are lost or in
other ways not available for the OS4 dev team.

@aTmosh

Regarding BCPL.. AmigaOS developers have said that they had to
remove alot of BCPL code for AmigaOS 4. AmigaOS 3.x also compiled
with (if I remember correctly) seven different compilers with atleast four
different languages. Hyperion changed that to mainly one language, C
with some smaller parts done with PPC assembler, and one compiler,
GCC.
It would probably have been faster and easier to go the MorphOS way
and start from fresh than to port.
Commodore probably stopped using BCPL quite early but still left a hell
of lot of this code in parts that were not changed or just had small changes done to it over the years.

I wouldn’t call the virtual memory being “bolted on” as you put it.
But yes it was added as a feature in AmigaOS 4.1.

Where on earth did you get that? As part of the IP the sourcecode represents value, I’m sure it’s available as long as you wave a big enough cheque and have enough resources to negotiate the legal quagmire of disputed trademark/IP ownership changes. The biggest difficulty is probably drilling down to whoever is authorized to sell/licence it. Just because some hobby project scale developers can’t get it (officially) doesn’t mean it’s ‘completely lost’ a la Doctor Who.

Even if it were, the APIs are well documented, Commodore/CATS themselves did an excellent job on that (ROM Kernel Reference Manual etc.), plus you have superb third party books like the Guru book by Ralph Babel (especially if the new 3.1/4.0 edition is ever published). AmigaOS is probably one of the most extensible and hacked OSes around, there are tons of people with intimate knowledge of the innards that could even make source superfluous.

Additionally i’d include MorphOS to the story, which is a fully API/ABI compliant PowerPC replacement to AmigaOS, and in some levels it’s even more compatibile with the old AmigaOS 3.x, (and some de-facto standard enhancements to it) than AmigaOS 4.x, (while offering very similar advancements and new features over AOS 3.x) and it even predated and influenced AmigaOS 4.x in most of the 68k – PPC integration features and style. And as aTmosh said, it was created by the people, who brought PowerPC to the Amiga in the first place.

An interesting factor in all of this was page size. When the IA64 port of NT was done, various page sizes were tried (Itanium is flexible wrt to pte format and address translation) and they settled on 8K being more efficient. It was thought at the time that 4K pages were required for compatibility with 32-bit apps (Itanium was the future for everything then, so they wanted to be as compatible as possible). So the IA64 Windows kernel supports splitting up single WOW64 page mappings into two regions with differing protections. There’s a bunch of nasty little ifdefs all around the memory manager for this.

This is incorrect, BCPL program compatibility was retained up to 4.0 but BCPL code was dropped for C and assembler in 2.0 already (1990 IIRC), in fact the ARP project was already doing this during 1.3 days (1987-1989-ish). Porting was only a major effort in the sense that two guys normally doing game ports from PC to Mac did it over 6 years or so (starting in 2001, not counting developer betas), the scope of the project (e.g. AmigaOS didn’t have a TCP stack of its own, no USB support, there was no parent company established 3D support etc.) and due to OS design – chief of which were a historical lack of memory protection (no MMU available in the early days, messaging based microkernel), porting workarounds for chipset dependencies (e.g. Picasso96 to retarget graphics) and no native virtual memory. The latter has been bolted on but proper memory protection would need to be incorporated in a complete redesign (and it would be a mistake not to do this platform independently, or at least switch to x86).

“Amiga OS could not be ported, because the source code was not available.”

This is also incorrect, Hyperion was commissioned by Amiga Inc. and AFAIK had full access to the source code for the 4.0 port. The developers of MorphOS (who incidentally also did the phase 5 PPC boards) had no official access to the sourcecode. If you mean ported to the PPC boards in the nineties, it made no sense, at least commercially. Not much technically either due to the minor speed gap between 68k and PPC back then (060/50 vs. 604/233 at most), which would mostly have been negated by issues such as context switch overhead: the main 68k processor was removed and plugged into the PPC daughterboard, which then interfaced to the motherboard. The lowest level control including access to the chipset and thus mainboard memory/graphics/storage/the Zorro bus controlling all preexisting expansions such as NICs remained with the 68k. The daughtercard with the PPC could be extended with graphics and memory of its own, alleviating some of the bottlenecks, but a full porting effort didn’t make sense until the PPC clone market started up. Sadly this was killed off by Apple, so a full port had to wait another 10 years (Motorola was in fact ready to support an AmigaOS port to PPC in 1996, but this also went under with Escom).