Amiga OS4 on old (PPC) Macs

[Hans_]

Correct. It's ACube's Moana project. This has even been submitted as evidence by Amiga Inc in their lawsuit. ACube showed Bill McEwen a screenshot of it running during an IRC chat session. Unfortunately Amiga Inc. wouldn't give them a license, and ACube have had to suspend its development. It's a pity as there are so many more Mac Minis out there than classic PowerPC cards. ACube's SAM440 also doesn't have a license.

Hans

[Hans_]

Kronos wrote:
@da9000

Well, with Hyperion refusing to honor their part of the contract there is hardly any money to made for AInc in OS4 on MacMini.

Mind, I doubt things would be much different if everything was o.k. between AInc and Hyperion, but atm their both big show-stopper when it comes to new HW.

This makes no sense to me. If ACube had a license, they would be paying royalties per copy of Amiga OS4 the same way that Eyetech was. Exactly which obligation is Hyperion not honouring that would prevent them from making money? AFAIK the only thing that Hyperion have refused to do is hand over the source-code on the assertion that Amiga Inc. haven't fulfilled their obligations yet. Hand over of the source-code was about developing OS 4.1+, not about OS 4.0 itself.

Hans

[Hans_]

Kronos wrote:
@Hans

No need to start another lawsuit-thread,

I agree completely with you on this point. I just hope that they can hurry up and get the lawsuit over with.

In the meantime, it's good to see a few new users will finally be able to get their hands on OS 4.

Hans

[Hans_]

persia wrote:
But again, is there anything in the A1 specs that isn't a PPC Mac?  Well, except for legacy ports...

The A1 uses UBoot, so the A1 version of OS4 only has a UBoot bootloader; it won't work on a Mac. The A1 uses the Artica S chipset (from the now defunct MAI Logic), whereas Macs use their own chipset. These are incompatible.

Hans
 

[Hans_]

persia wrote:
There's the problem, the user base for OS4 is so bloody tiny that no one will develop for it.  Put it on old Macs and you'll have a potential base.

And developers will also be able to obtain machines on wich to develop and test code.

Hans

[Hans_]

@HenryCase

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.

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.

The sad thing is that working MacMini OS4 code is sitting on a hard-drive (or hard-drives) at ACube, but they're not allowed to do anything with it.

Hans

[Hans_]

HenryCase wrote:
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?

UBoot looks a lot like a PC bios. It has an x86 emulator so that it can use the VGA-bios to display text/menus. After power-on tests it searches for a hard-drive with a Second-Level Booter (SLB). You can configure UBoot to boot via other methods too, e.g., via TFTP. The second-level booter scans the hard-drive for a partition containing Amiga OS4, and for Linux boot directories containing a boot.conf (or is that a1boot.conf? I can't remember). The user can select whatever configuration he/she wishes to boot. If OS4 is selected, the SLB loads the kickstart modules into RAM and starts ExecSG and UBoot drops out of the picture. The kickstart modules must include all the drivers for the essential hardware components (i.e., the IDE drivers, VGA drivers, northbridge, etc.). Holding down both mouse buttons at this point brings up the Amiga Boot menu that people are used to from Amiga OS 2.0 and up.

This is my basic understanding of the boot process on my A1.  Note that I've never seen any code, nor tried to analyse the process in any detail. I think that loading the kickstart into memory would be the easiest thing to do if you were porting OS4, and the OS4 developers have said that different BIOSes are fairly trivial to adapt to. The HAL, on the other hand, must be adapted to whatever particular PowerPC variant is being used.

Hans

[Hans_]

HenryCase wrote:
@Hans
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.

No OS (not even windows) uses the BIOS drivers for more than is absolutely necessary. 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. A BIOS's job is to initialize the hardware, provide a means for loading an OS, and then should disappear.

This is completely different from computers such as the classic Amiga, in which the core of the OS is held in ROM, and the machine isn't designed to run any other OS.

Hans

[Hans_]

A1260 wrote:
Unfortunately for you the OS4 fans, that dont seem to understand this not being a hoax is definitely not a very good thing. Instead you are mostly cheering. You all is too stupid to see the big picture. Reminds me of Lemmings.

The probability of new lawsuits materializing between old and new players has greatly increased.

DBAlex has now actually helped Amiga Inc, I think we have not seen any court document on this matter because it has not been proved working, now that Amiga Inc have proof you can expect a document stating HOW Hyperion has NOT been able to protect their IP and moving their Amiga Inc's operating system to another hardware that is not licenced, aka not AmigaOne. Amiga Inc probably have a copy of the leaked iso also.  

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

Good luck in killing of AOS!!

 :-x

If Amiga Inc. had any semblance of intelligence, they'd see a demand for Amiga OS4 on any hardware.

BTW, it's not a leaked copy of OS4; we know that it contains - apparently old versions of - Moana code, but we don't know if it's an actual project Moana ISO (I doubt it). Claiming that Hyperion is covertly shifting their OS to another system is a real stretch. Added to this, no-one's managed to swipe any OS4 source-code; the ISO contains binaries only. There is no software company in existence that has managed to prevent the unauthorized spread of binaries.

Hans

[Hans_]

HenryCase wrote:

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?

A much easier way would be to use a disassembler on the kernel and loader, and examine the resulting assembly code, comparing it to the hardware documentation. Either way, it would take a considerable amount of effort as disassembled code is much less understandable than the original code. We're talking about thousands of lines of PowerPC assembly here.

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.

Hans
 

[Hans_]

HenryCase wrote:
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?

AROS was about source-compatibility so OS4 apps won't run unless recompiled for AROS on whatever processor AROS is running on. That's ignoring the endianness issues of-course. As you've already realized, it would also be a big job.

They could replicate the OS4 API, but IIRC, they don't like OS4's new library interfaces concept. Plus it looks as though they're starting to deviate from the 3.1 API and developing their own ones. You could try, but I'd expect considerable resistance from the current AROS devs.

Hans

[Hans_]

HenryCase wrote:
@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.

The endianness issue isn't as big as some people think, or as insignificant as others think. Basically, even with source compatibility, some code is endian-specific. This is usually code to load/save data or send it over a network (assuming that you're not writing device drivers). It means that a simple compile won't just get it working. Something like a DVD writer app that communicates with a DVD drive needs slight variations of certain code depending on the processor endianness. Other manifestations of this are the colours of an image being wrong, or audio sounding really noisy.

Hans

[Hans_]

Fats wrote:

Hans_ wrote:

AROS was about source-compatibility so OS4 apps won't run unless recompiled for AROS on whatever processor AROS is running on. That's ignoring the endianness issues of-course. As you've already realized, it would also be a big job.

AROS was about binary compatibility on m68k and source compatbility for non-amiga CPUs.

I'd forgotten about the 68k binary compatibility goal. But things have changed since then haven't they?

I don't see why there would be a big resistance from the developers if somebody makes an OS4 compatible AROS version. The mentality is that each developer should be able to do with the open-source source code what he likes. That is the spirit.
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.
One of the biggest hurdles IMO for true OS4 compatibility is an open-source Reaction implementation.

Maybe you should tell some of the more vocal AROS advocates to STFU then. The impression that I got was that AROS developers have no interest in OS4 compatibility at all, see it as inferior, blah blah blah.

Hans