Amiga OS4 on old (PPC) Macs

[HenryCase]

Right, as far as I can see it, if OS4 has any chance of running on Mac hardware, emulated in software, etc... we need to understand how it works. As we don't have the source code, this means reverse engineering. When approaching this reverse engineering work, we have two directions to go in, from low level up, or from high level down.

Let's start looking at the workload involved and the potential benefits of both methods. One way to start at the high level would be to deconstruct the OS4 SDK. From there you should get clues about how the low level stuff works. However, you would not get a complete enough picture to design new hardware drivers and integrate it into the OS AFAIK.

Going from the low level, the most useful device to concentrate on would be the BIOS from the A1. Deconstruct that and you're laughing as drivers all need to run through the BIOS (in Amiga OS4 for A1 anyway), so you'd understand a great deal of what OS4 requires to run. This would require a lot of work, but there are some useful resources on the Internet for completing this work.

Introduction to A1 BIOS:
http://www.amigahistory.co.uk/press/1stoct2002.html
Based on PPCBoot:
http://www.linuxdevices.com/links/LK6257448893.html
http://ppcboot.sourceforge.net/
PPCBoot evolved into UBoot:
http://www.denx.de/wiki/UBoot

BIOS disassembly book (for x86 BIOSes but principles will be useful for all BIOS disassembly):
http://www.amazon.com/BIOS-Disassembly-Ninjutsu-Uncovered/dp/1931769605
http://www.geocities.com/mamanzip/Articles/Award_Bios_RE/Award_Bios_RE_guide.html

Simpler BIOS hack (probably good place to get started):
http://os-fun.blogspot.com/2006/05/modifying-laptop-bios-for-fun-and.html

Technical OS information:
http://www.osdever.net/documents.php?cat=0&sort=1

But wait, maybe reverse engineering the BIOS isn't necessary after all. If the BIOS in the A1 is based on code from a GPL project like PPCBoot, don't Hyperion have to release the modifications they made to the code back into the original project code repository? As far as I can tell they do, unless the PPCBoot people gave Hyperion their own license. That means we should be able to find the Amiga DRM code that Hyperion added somewhere on the Internet. Anyone got info that would help us track down the code?

Of course UBoot isn't an essential part of running Phase5 OS4, but it is essential to running A1 OS4 and by understanding how the A1 BIOS works we understand OS4 better as a whole (as well as giving ourselves new hardware opportunities).

[HenryCase]

Hans wrote:
DRM code in UBoot? I doubt it. That would be the silliest place to put copy protection as replacing the bios would eliminate it. I'm not even sure if there is any DRM code in OS4; the A1 or classic Amiga hardware are dongles enough as-is.

Fair point.

Hans wrote:
I doubt that analysing UBoot would give you much knowledge about OS4 as it only affects the bootloader that copies the Kernel modules into RAM. I doubt that it would be too hard to write an alternative bootloader; the second-level booter basically searches for a kickstart directory and loads the modules as per instructions in the kicklayout file.

The real issue remains the drivers, and the fact that the HAL is compiled right into the kernel. It would make more sense to decompile the Loader module, and the kernel. Someone who could isolate the HAL code sections would be able to create a patch in such a way that the patch code contains no copyrighted IP. Replacing the HAL is a sizeable task.

I thought the BIOS would give us some clues about how the drivers worked, didn't realise the HAL (HAL = Hardware Abstraction Layer, right?) was purely run through software.

Hans, can you explain how the A1 version of OS4 boots (from your understanding of the matter)? I have never seen an A1 booting so my knowledge is limited. Does the system perform a POST?

Taking the display driver as an example, does the BIOS have to load the software kernel before anything is displayed on screen, or can you, like on x86 PCs, bring up BIOS settings on screen before the main OS starts?

motorollin wrote:
Well legal or not, I'm now convinced that this works. Having had another suggestion from AmigaMac, I got my copy of the OS4 boot CD to boot on my Mac Mini and get as far as launching ExecSG, and then it just went to a black screen.

That's awesome. You're not the only one to have some success here either:
http://moobunny.dreamhosters.com/cgi/mbmessage.pl/amiga/152833.shtml

Colani1200 wrote:
Did you try this with the OS 4 classic CD? I read somewhere that the A1 version is needed, maybe that is the problem.

The versions of OS4 released so far are meant to be similar, but I agree that the A1 version is more likely to be successful, as the h/w for MacMini is closer to A1 h/w than CSPPC/BPPC h/w. Also, if these are the leaked Project Moana files it would have been developed with A1 OS4 as Classic OS4 wasn't as complete at the time the Moana announcement was made.

[HenryCase]

@Hans
Thanks for the info Hans. I am basing my analysis of A1's boot sequence on my limited knowledge of the x86 PC boot sequence. However, one part of your explanation leaves me a little mystified...

If UBoot powers up the system and tests it before handing control to OS4, then it already has the hardware drivers loaded, right (otherwise it would limit the tests it could perform)? If the hardware drivers are loaded by UBoot, why would OS4 then go to the trouble of loading them again? If your description is accurate then Hyperion have shot themselves in the foot by not using the most efficient loading method.

@DBAlex
You da man! :-D

[HenryCase]

A1260 wrote:
Now Hyperion will go down and lose in court and your beloved AOS4.0 will be forever trapped.

Good luck in killing of AOS!!

This development doesn't have any affect on the AInc vs Hyperion cases...

1. AInc already knew about Project Moana's existence (which is what we could have the code for here).
2. Hyperion have never publicly endorsed Moana, the work was done by ACube, who had access to the source code as a trusted partner/developer. Therefore, Hyperion have nothing to do with this, and it won't affect the outcome of the court cases.

A1260 wrote:
read here you pirates!...

May I be the first to say: I don't care!

Piracy is only bad when there are negative consequences. Who is losing out here? AInc get the potential for more OS4 development, ACube and Hyperion get the potential for more OS4 sales. The code may have been stolen from the original author, but I don't completely understand why he is annoyed about its release, as he could never have released it himself (AInc wouldn't have endorsed it) and so his work would have gone to waste.

Hans wrote:
The VGABios is great for displaying text-mode graphics, but not much else. Likewise, the BIOS IDE drivers are pretty much the bare minimum needed to read the disks. These drivers aren't Amiga OS drivers at all.

Thank you for taking the time to explain this to me Hans, I've still got a lot to learn about computer architecture.

Okay, so the main focus of our research efforts should be on deconstructing the HAL. Could we use a PC Oscilloscope (such as this one: http://www.picotech.com/highperformance-oscilloscopes.html) to probe the control and data lines of an A1 to construct a picture of how the HAL works, or is there an easier way?

@Everyone
Will this allow everyone without a Mac to try the OS4 bootloader?
http://mac-on-linux.sourceforge.net/
Are there any other VM solutions we could use?

[HenryCase]

dammy wrote:
No, it should be Hyperion's issue as they authorized Acube access to AI's IP.

But did they break the terms of the contract?

Look at page 31 of this document:
http://merlancia.us/amiga-hyperion/35-5decmcewenexhibit5show_case_doc.pdf

Discussing Moana, Bill McEwan says:
"How do you have access to OS 4 source code?"

Nicola Morocutti replies:
"We don't have direct access to the source... we are working with some Italian OS4 developers and with Hyperion as well."

Nicola goes on to say that Hyperion had only really acted as consultants. Show me the part of Hyperion's contract where this consultation is illegal.

A1260 wrote:
as this aint enough there will not be any new updates of the aos because you killed of the business for these small companies like hyperion.

This is the core of your argument, but it's also the part you've got most wrong. Amiga users (in 2008) understand that a purchase of OS4 would be necessary to keep development going. People will purchase OS4 to run it on a Mac (if we can boot into Workbench). Hyperion makes more money if we can get this working, making future OS4 development MORE likely.

[HenryCase]

dammy wrote:
Reread what I said please as I didn't say it was illegal contractually for Hyperion to work with OS4 Devs.   Hyperion did have a responsibility to make reasonable and prudent safe guards of their partner's IP when dealing with third parties which seems not to have happened in this situtation.   That is what AI can hammer Hyperion on.

Dammy, we're not going to agree on Hyperion's responsibility for Moana until we can examine the relevant contract(s). Do you know where we can obtain these documents? I tried to download documents from this website:
http://tinyurl.com/394ump
Keep on getting "500 - Internal Server Error".

[HenryCase]

Hans_ wrote:
Hyperion have stated that they're committed to expanding the amount of hardware that OS4 will run on. I hope that they can deliver, despite the lawsuits. They have the source code and the expertise, and they don't have to reverse engineer anything.

I hope Hyperion do continue to develop OS4 in the way you describe, but I'm looking for solutions the community can implement to get us out of this legal mess.

How about an OS4 implementation layer for AROS? It wouldn't be as much work as when the AROS team started with OS 3.1 compatibility, as it could be built on top of the existing work. The OS4 SDK has been released, wouldn't an AROS implementation of this be enough to run OS4 apps?

With OS4 support built into AROS we free ourselves from not being able to develop apps for the platform, as well as giving ourselves many more hardware choices. If when the court case is finished, and new OS4 hardware is released, we will have a whole bunch of ready made apps that we wouldn't have otherwise.

Do you think we should start a bounty for OS4 AROS?

[HenryCase]

@Hans
I would be interested in using AROS as a platform for creating new apps (that would run on AROS and OS4) so recompiling wouldn't be a problem. Anything that makes porting between the two systems would be beneficial. Would the endianness really have that much affect? After all, 68K endianness is different to x86 endianness but that didn't stop OS 3.1 being recreated.

I'd like to ask the AROS devs to see if they are interested, but I'd like to know I wasn't the only one interested in OS4 compatibility in AROS first.

@Crumb
Must have overlooked that bounty before, thanks for bringing it in to this discussion.
Never realised there was an OS4 emulator for MorphOS. At the moment it's not complete but a port of it in its current state to AROS would be a great start, work could be done to improve compatibility later. Here's the current compatibility list:
http://amigazeux.net/os4emu/comp.php

[HenryCase]

Fats wrote:
I myself am a core AROS developer and I do plan in the future to make two PPC versions of AROS possible. One binary compatible with MorhOS and one compatible with OS4. First I want to finish the i386 ABI though.

That's great news (about your future plans). Thanks Fats. :-D

ABI = Application Binary Interface, right? It sounds pretty important, but I don't really understand how it will be used by AROS. Can you explain the benefits of a good i386 ABI implementation to us?