I haven't really given an update as I don't have any thing to show at this point. I don't expect this to be quick and easy by any means.
But I can give you an update on what I have found and know.
I have found through exhaustive searching old documentations on various parts of the mac internals (well as much as apple documented for developer use).
I found several references that stated that the Classic Support extension used for Classic mode in os x does some interesting things such as completely replace all memory management routines to map them to the memory manager of OS X. This is probably the main reason why you can not access hardware directly from with in classic mode.
The earliest part of the boot process that open firmware hands off to is an elf executable. OS 9 uses PEF executable format, but Open Firmware knows about ELF formats. The elf file is actually responsible for loading, decompressing/decoding either an LZSS file embedded in the ROM (used on versions lower than 9.0) or parcels embedded in the rom file. These parts are in the data fork of Mac OS ROM.
The ELF file is a valid ELF file but most decompilers/disassemblers do not recognize it as they expect a record size for sections. The standard states that if no sections are defined then the record size can be zero. This is the case in this ELF file so the decompilers out there think it's an invalid file. The second problem with the disassemblers that are available is that they only speak the simplified PPC instruction set. After extracing the program headers from the elf file and running it through several disassemblers as raw code I figured this out as the output had a lot of long jumps which are not part of the PPS ISA.
So I set forth and wrote a small utility program that loads the ROM into ram in a known place. The reason for this is that after everything is loaded and booted, parts are moved around and removed from memory so you can't view the data in the ram locations these parts are where loaded in. Once I loaded the ROM into ram the program analizes all the parts to find the entry point that open firmware essentially jumps to. So once I have that address for my loaded ROM, I dropped into macsbug and used that disassembler and told it to start dissasembling from the entry address. This produced much different output than other disassemblers and I was able to figure out that the PPC processor apple uses (at least starting with the g3's and forward) are using the ISA For PowerPC Book E (Which is an enhanced instruction set). The other thing that indicates that the ISA for the g3 and newer is Book E is that the instructoins 2-4 from the entry point are all Book E instructions. If a cpu doesn't support Book E the unsupported instructions can be emulated in code, but you need to load a trap/interrupt, a function to handle it and then a look up table to decide what actual procedure to run. These things would not be loaded with in the first 4 instructions.
The other thing I've figured out is the PVR (cpu_version) is checked early on in the elf file to even determine if it should move forward.
On New World machines the elf file is loaded and one of the first things it does is pull some data out of the device tree then issues the DO-QUIESCES which basicly suspends open firmware.
I haven't fully decifered everything in that elf boot loader code, but my suspicions at the moment lead me to believe that it does the following.
Checks the CPU Version to ensure it is a version supported (updating this will get OS 9 booting on the G4's that require the cpu-version property change in the open firmware device tree with out having to do the update)
Decodes the toolbox rom from either the LZSS file or the Parcels
Jumps to the kernel to finish booting.
It's at the point once the nano-kernel is started that you will see the Happy Mac.
I haven't figured out if the nano-kernel is part of the elf file or int the LZSS or Parcels.
And some very early notes on the possibility of booting on the G5.
The 64 Bit version of the Book E ISA is backwards compatible with the 32 bit version. This is actually why all the OS X versions suppored on the G5 where 32 bit. They could write it in 32 bit and it would run on the G4, G3 and G5 with no real issue.
So the cpu will not be a limiting factor on the G5.
The error seen booting on the G5
MacOS: cascade interrupt, but no cascading bridge
Is an issue early on with in the ELF file mentioned. In both the G4 and G5's the cascading bridge is implemented in the north bridge.
The north bridge is completely different (as noted elsewhere in this thread) on these two systems. The drivers for the Uni North are in a resource in the Mac OS ROM file. I haven't figured out though if there is some basic initialization code that runs prior to that driver (to enable full functionality) in the boot loader because I haven't figured out if it has access to the items in the resource fork by that time in the boot process. I think it might so if a U3 driver can be written and dropped in that resource that would solve that problem. Of course this would still not allow the G5 to fully boot OS 9. Other things that would have to be added to get the G5 working is support for AGP 8x and pci-e. These are implemented also in the U3 controller. The AGP 8x ports on the G5 are not backwards compatible at all according to Apple documentation.
I have not given up hope of booting on the G5, it will just take a lot more time than getting full support on unsupported G4's and doing a couple more memory enhancements as well.
On the subject of memory here's an interesting tidbit.
The Toolbox kernel and system resources (including the finder) are loaded into the lowest part of memory.
Applications are loaded into the top part of memory.
So when you have 2 GB of ram in OS9 and the finder takes 512 MB. This is the first 512 MB (well starting from the kernel, toolbox)
This means that applications can run when their memory addresses are up in the top 2GB of ram.
So I am fairly confident that the memory management routines can be updated to get access to that part the finder is taking up.
That's it for my rambles. Again nothing to show other than some understanding about early boot process.
Author
Topic: Any one want to help build a community made OS 9.3? (Read 193512 times)