Mac OS 9 Lives
Mac OS 9 Discussion => Mac OS 9, Hacks & Upgrades => Mac OS 9 on Unsupported Hardware => Topic started by: gtxaspec on December 11, 2015, 11:27:56 PM
-
Hello All!
My name is Alfonso, I have been working with the QEMU project as of late to have MacOS 9.2.2 boot successfully on the emulator. Most of research and progress has been on the emaculation forums, and on the QEMU-Devel mailing list. In my research to debug and provide feedback to the developers with the intended goal of QEMU successfully emulating a a real Macintosh from a hardware standpoint, I have found this forum and its users to be a trove of information.
I seek assistance for this project, and invite the anyone here to look at what we have accomplished and provide feedback and input on what we would like to accomplish.
As it currently stands, QEMU successfully boots MacOS 9.2.1 and 9.2.2 in a limited fashion. There is no sound, or network support currently on either version. You are able to boot a full MacOS 9.2.1 system with Open Transport disabled.
MacOS 9.2.2 functions with a patched System Suitcase (wart resource removed) and Open Transport ASLM libraries removed from the extensions folder.
What we need help with:
Open Transport seems to crash the system at boot. If Open Transport ASLM is present in the extensions folder, system crashes. If the System file has the resource "wart" present, crash, because this references Open Transport calls. My theory now is that Open Transport's serial subsystem is causing the crashes. If you are able to debug with macsbug or QEMU, please help! =D
I have been compiling and hosting disk images with my progress so others may debug and provide feedback. It’s also pretty cool to actually see MacOS 9.2.2 boot to the desktop on your Windows, Mac, or Linux computer and run some programs!
See this thread on the QEMU-Devel mailing list for the in-depth play by play from the developers of MacOS support in QEMU:
https://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg02688.html
Check progress over at emaculation QEMU forum too for lots of detailed into on the years of trying to make this work. ( not sure if OK to post direct link to other forum so I will omit for now. )
Huge thanks to Cormac O'Brien and Mark Cave-Ayland for the heavy work programming OpenBIOS and QEMU. Mark has been active lately assisting us with debugging and he is a contributor to both the OpenBIOS and QEMU projects.
regards,
alfonso
-
What is QEMU?
A powerful emulator capable of emulating the PowerPC instruction set, as well as specific PowerPC processors including the G3 and G4. QEMU also provides emulation of Old-World (g3beige) and New-World (mac99) Apple Macintosh architectures.
QEMU currently works together with OpenBIOS, which provides an open-source OpenFirmware implementation. QEMU, together with OpenBIOS provides the device tree, device initialization, etc that enables MacOS to boot in QEMU.
For more information on OpenBIOS support for MacOS9, see this:
http://www.openfirmware.info/pipermail/openbios/2015-October/008809.html
This past summer, Cormac O’Brien was one of QEMU's student developers for Google Summer of Code 2015. His project goal was to have Mac OS 9 running on both the g3beige and mac99 machines in QEMU by the end of the summer. He contributed many patches during GSOC, and we have now are able to boot MacOS 9.2.2 to the desktop thanks to Cormac and the other QEMU developers hard work.
For more information see:
http://c-obrien.org/qemu-os9/
https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg02422.html
-
Extra Goodies:
QEMU from Mark's repo ( built on osx 10.11 )
http://bebop.gtxent.com/qemu_mark_latest.tar.gz
Resedit, Stuffit, Toast, Disk Copy, utilities in an ISO to mount within QEMU:
http://bebop.gtxent.com/qemu_os9_utilities.iso.zip
MacOS 9.2.2 basic bootable image:
http://bebop.gtxent.com/os922_uni.iso.zip
MacOS 9.2.1 basic bootable image:
http://bebop.gtxent.com/os92_test.iso.zip
MacOS 9.2.1 basic bootable image with macsbug:
http://bebop.gtxent.com/os92_test_macsbug.iso.zip
example boot args:
Code:
##boot off CD with install iso and utility iso
./qemu-system-ppc -bios ~/MacOS/qemu_master/openbios-qemu.elf \
-boot d -drive file=~/MacOS/OS\ Images/os922_uni.iso,index=0,media=cdrom \
-drive file=~/MacOS/QEMU\ HD\ Images/test.raw,format=raw,index=1,media=disk \
-drive file=~/MacOS/OS\ Images/macos-922-uni.iso,index=2,media=cdrom \
-M mac99 -m 256 -prom-env 'auto-boot?=true' -g 1024x768x32 -cpu G3 -net none
Also,
Here is a zip containing qemu-ppc, and a 2gb disk image file with macos 9.2.1 stock (no system modifications) installed. The system folder was modified to allow it to boot from an unlocked HFS volume. This image has lots of extensions and control panels included and enabled. Once you download qemu_easy.zip, extract it, and run qemu_os9.command (this is just a batch file with argumentsx osx only. you can use the test.raw with other platforms as outlined above.)
qemu will now load and boot from the disk image to OS9 desktop. The disk image included here is read/write enabled. I have only tried this on OS10.11, your success may vary. MacsBug is included in the root directory, but is not enabled.
http://bebop.gtxent.com/qemu_easy.zip
-
Here is a bootable installation of MacOS 9.2.2 with the latest QEMU compiled from QEMU Devel git repo, with a disk image of installed MacOS 9.2.2 extracted from NetBoot9.dmg. Extract contents, then simply run qemu_os9.command to enjoy.
Booting was made possible by patching the System Suitcase to remove some Open Transport code:
Removed entire resource "wart" from the System Suitcase,
which upon inspection contained references to Open Transport libraries, without this
resource removed, booting MacOS was
impossible even with all Open Transport extensions and libraries removed.
Some Control Panels and Extensions still needed to be removed to fully boot to the Finder:
Control Panels Removed:
Trackpad [ confirmed crash ]
Extensions Removed:
QuickDraw 3D Rave [ confirmed crash ]
Open Transport ASLM [ confirmed crash ]
Quicktime Extensions * firewire enablers [ confirmed crash ]
ATI & NVIDIA Video Drivers [ result in black screen in QEMU ]
Multiprocessing Folder [QEMU hard crash]
Apple Audio Extension [QEMU hard crash]
Multiple Users Extension [ crashes finder ]
This disk image is a full MacOS 9.2.2 installation, with lots of extensions and control panels. Virtual Memory is enabled and seems to work. Various utilities included. Your milage may vary.
Remember, the System Suitcase in this image has been modified. Replacing the Suitcase with a different version may result in a crash at boot. You may attempt modification to your own System Suitcase file, use a resource editor like ResEdit or Resorcerer, and just remove the entire "wart" resource. Save, and boot. Results may vary.
I will complete more research based on Mark's advice and report back with results. While this is not the intended goal of my research ( I hope QEMU to boot a stock OS9 installation with nothing removed or patched ), it is another nice proof of concept that MacOS does have much potential to work with QEMU, and validates the hard work that everyone involved in both the OpenBIOS and QEMU projects have put into making this all possible.
http://bebop.gtxent.com/qemu_easy_02.tar.gz
[extract test.raw disk image from here and you can use on any platform, Windows/Linux/OSX]
regards,
alfonso
-
Hi Alfonso. Instead of boring with emulators that can't run a shit until x86 achieve the 10 Ghz , why you don't work in to porting Linux G5 motherboard drivers to Mac Os 9 to allow it to run in to a 3.0 Ghz quad core PPC?
That's the point. Not emulators. IMHO.
Anyway good luck.
-
Yeah... nothing personal, but most of us here are "Anti-emulator" The "real thing" has proven itself to be best in both the the OS9 arena and in women.
-
Yeah... nothing personal, but most of us here are "Anti-emulator" The "real thing" has proven itself to be best in both the the OS9 arena and in women.
Haha... ;D
But it would be interesting to see how far this actually does go and if it ports to Macintel.
-
I dunno, boss… it would seem to me that any R & D involving our beloved Mac OS must be a good thing… n'est-ce pas?
You never know where it might lead…
-
stop whining guys, a proper emulation would be more than welcome, so you can at least use the one or other old a app under OSX 10.x.
of course video and audio drivers would be great to have (for users like us), but a missing network functionality is not really a problem.
-
Hi Alfonso. Instead of boring with emulators that can't run a shit until x86 achieve the 10 Ghz , why you don't work in to porting Linux G5 motherboard drivers to Mac Os 9 to allow it to run in to a 3.0 Ghz quad core PPC?
That's the point. Not emulators. IMHO.
Anyway good luck.
In our research we have been looking for people who have experience coding device drivers for MacOS9, extensions namely. We have been unable to locate anyone.
Is there anyone on this forum with assembly level knowledge of the MacOS and PPC? Not only would that person be able to aid to the QEMU project, but also in extending the drivers of MacOS to new hardware!
regards,
alfonso
-
In our research we have been looking for people who have experience coding device drivers for MacOS9, extensions namely. We have been unable to locate anyone.
Is there anyone on this forum with assembly level knowledge of the MacOS and PPC? Not only would that person be able to aid to the QEMU project, but also in extending the drivers of MacOS to new hardware!
regards,
alfonso
I may not be the most experienced developer when it comes to new drivers for OS 9 but I will be working on some updates.
Not sure if you've followed any of it
Original thread where I brought up the idea.
http://macos9lives.com/smforum/index.php?topic=2727.0
Poll for application development based on input from other users
http://macos9lives.com/smforum/index.php?topic=2891.0
OS Enhancements/Extension based on input from other users.
http://macos9lives.com/smforum/index.php?topic=2890.0
As much as most users here would not see a lot of use with an emulator, it would provide a more convenient way to debug low level os calls and patches that I will end up working on.
So I for one am interested in this and may look into helping on that project. My only issue is very limited time and what free time I have I would like to commit to the other projects I've suggested here.
-
I've linked this discussion over in the 9.2.2 QEMU thread over on ThinkClassic (http://www.thinkclassic.org/viewtopic.php?pid=10440#p10440) to help spread the word.
I'm not sure if anyone still actively develops for Mac OS 9 over there (with the exception of ClassicHasClass and the Classilla browser, of course) but it's worth a shot.
-
IS there actually anyone still developing Classilla? My impression was that it had died a quiet death in 2014 at version 9.3.3, which I'm running on my beige G3.
-
Qemu-PPC has come a long way, so I thought I'd add an update and some new info.
As far as OS 9 support, you can boot OS 9.x with all extensions enabled. The Sungem ethernet device in now in the master and works very well, with no need to install 3rd party drivers for the Mac OS.
There is a branch working on the Screamer audio device, and it is reported to work well with OS 9, and some early versions of OS X, but later versions are still having trouble with it. Hopefully the bugs will get ironed out soon and it will be merged with the master.
As far as the speed of the emulated CPU, on my Ryzen 7 1700 @3.75 Ghz the integer performance is about the same as a 1.27 Ghz G4. However the FPU and Vec units are in desperate need of work, and perform about as well as a 70 Mhz G4.
There is no emulation of the L2 or L3 cache. Cache emulation presents at set of problems that are, as yet, unimplemented. It's very hard to emulate this sort of thing, and have there be any real speed benefit.
I've done some work adding some more PPC CPU's to Openbios and Qemu, but that was done for my benefit so I could use these CPU's under Linux PPC with KVM.
The state of KVM on the G4 is very poor and buggy. With the 7447a ( PVR 80030105 ) You'll need to patch qemu-system-ppc and OpenBios to support it, but for some reason OS X's mach_kernel tries to read the state of the L3CR to make sure the register returns 0x00000000, and if it doesn't then it tries to write that value to the register. This is very odd, and perplexing, as the 7447a does not have, nor support an L3 cache, nor would that register be writable.
I implemented the L3CR register with a patch to qemu-system-ppc, but KVM will not allow a read there, so the kernel just hangs. Some more work to patch KVM is needed, but I haven't figured a correct patch.
You can boot OS X with --enable-kvm -cpu 7410, 7400, G3, 604. On the 7447a and you will get KVM acceleration but it's buggy at best. Seem to have a lot of trouble with disk access.
The state of KVM on the 7455 is even worse, I'm pretty sure KVM is conflicting with disk access. Oddly, OS X doesn't care that there is no L3CR on a CPU that has an L3 cache. KVM does not seem to pass the cache, and Openbios has no support of it.
OS 9 with KVM on the 4747a is a no go, the Mac OS Rom does something KVM doesn't like.
OS 9 with KVM on the 7455 is also a no go, Openbios says it can't find a valid state or init program when trying to boot the 9.2.2 Retail install CD. Odd, because without KVM it boots just fine, tho I haven't looked into tracking down the issue yet.
For those that are anti-emulator, all I can say is OS 9 booting hardware is getting more and more rare every day. People are just trashing these things as the cost of shipping exceeds the sale price, and even if you get one that works, the hardware is:
A. Never going to get any faster.
B. Not going to last forever.
Qemu-system-ppc will continue to get faster, not only as we work to better code the emulator, but as the host cpu's get faster. The DTC module that is in the master is good for a 10% increase across the board for the CPU.
Also, if anyone ever wants to get the G5 to native boot OS 9, it just far easier to debug an emulator than it is the bare metal, and you won't fry your logicboard. :P
-
L2 and L3 cache isn’t something you can emulate.
It’s transparent to the software. So the only thing you can do is emulate the registers as you say- but they won’t have any practical use.
As for KVM, if you use KVM-PR it should be able to pose as the CPU you determine.
The problem with KVM-PR on at least the G5 it doesn’t seem feature complete- I guess it lacks BAT emulation or something cause MacOS 9 will crash early on when you try to boot it on that processor.
-
I am pretty sure that MacOS 9 cannot run on G5s at all, at least without massive changes. G5s are 64 bit. MacOS 9 is 32 bit.
-
Is there a Step by Step Guide from Install to Setup (including good hints) QEMU for setup on an Intel Mac running ML thru El cap ?
I'm Gonna try this out...
https://www.emaculation.com/doku.php/ppc-osx-on-qemu-for-osx
-
wow 18000 views on this thread? :o
-
I am pretty sure that MacOS 9 cannot run on G5s at all, at least without massive changes. G5s are 64 bit. MacOS 9 is 32 bit.
G5's aren't 64bit only, they run 32bit code just fine.
It's not the CPU, it the other hardware on the logic board. OS 9 just has no drivers for it.
Qemu-system-ppc64 has a mac99u machine, that is basically a Sawthooth with a G5. It shouldn't be that hard to get OS 9 to run on that. OS X would just panic, finding a G5, and expecting to find the other hardware that goes with it, but that could be fixed with a custom mach_kernel.
-
You are correct that G5s run 32 bit code ”just fine”.
But at the same time it’s not really a proper PowerPC, it does not implement all things defined in the PowerPC architecture. It doesn’t even have all instructions, so some have to be implemented and emulated at OS level (an application wouldn’t notice though).
But MacOS 9 is not an application; and it uses a lot of the constructs that the G5 lacks (BAT registers for example. And emulating the BATs with PTEs would probably require quite some hacks in the nanokernel.
Drivers are an issue too of course but shouldn’t be necessary to get the system up and running, open firmware drivers will still work although at a severe performance penalty.
-
G5 = Mega tough
Agreed.
64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit. Doesn't mater if its 32 or 64 bit process.
Open firmware drivers will only be used if they are OS 9 compatible.
My understanding though is that G5's do implement PowerPC architecture. The things that are missing are actually suggested and not required for a PowerPC architecture. If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.
Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing), I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel. From there, kaboom. Like big time bad. Not sure what the fuck happened, but it left my G5 in a very sorry state.
-
G5 = Mega tough
Agreed.
64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit. Doesn't mater if its 32 or 64 bit process.
Open firmware drivers will only be used if they are OS 9 compatible.
My understanding though is that G5's do implement PowerPC architecture. The things that are missing are actually suggested and not required for a PowerPC architecture. If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.
Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing), I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel. From there, kaboom. Like big time bad. Not sure what the fuck happened, but it left my G5 in a very sorry state.
64/32 bit does matter as it affect the EA calculations and register content... But it’s no big deal to switch a 64 bit PPC to address mode.
Open firmware drivers are per definition OS 9 compliant, however there exists a shim to use respective driver from OS 9 is another question.
No the G5 does NOT implement the entire PowerPC architecture; the most well known lacking feature is swizzle mode (pesudo little endian).
There differences documented in the OS X Internals - A system approach.
Additionally XNU (The OS X kernel) has at least the UISA breaches documented and handled here
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.5.x/osfmk/ppc/Emulate64.s
IBM never claimed the PowerPC 970 implemented anything but PowerPC UISA compatibilty (which isnt entierly correct either as noted in the emulate.s file)
VEA and OSA is very different and does not conform to Book E.
-
G5 = Mega tough
Agreed.
64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit. Doesn't mater if its 32 or 64 bit process.
Open firmware drivers will only be used if they are OS 9 compatible.
My understanding though is that G5's do implement PowerPC architecture. The things that are missing are actually suggested and not required for a PowerPC architecture. If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.
Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing), I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel. From there, kaboom. Like big time bad. Not sure what the fuck happened, but it left my G5 in a very sorry state.
64/32 bit does matter as it affect the EA calculations and register content... But it’s no big deal to switch a 64 bit PPC to address mode.
Open firmware drivers are per definition OS 9 compliant, however there exists a shim to use respective driver from OS 9 is another question.
No the G5 does NOT implement the entire PowerPC architecture; the most well known lacking feature is swizzle mode (pesudo little endian).
There differences documented in the OS X Internals - A system approach.
Additionally XNU (The OS X kernel) has at least the UISA breaches documented and handled here
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.5.x/osfmk/ppc/Emulate64.s
IBM never claimed the PowerPC 970 implemented anything but PowerPC UISA compatibilty (which isnt entierly correct either as noted in the emulate.s file)
VEA and OSA is very different and does not conform to Book E.
I'll back up. Yes some of this I was wrong on.
But I'm not conviced on the Open Firmware drivers.
What is the definition that states the compatibility?
If I understand your statement, then OS 9 should have no problem booting on the xserve without removing the bridge controller for the ATA bus controlling the hard disks (not the one the optical drive is attached to).
-
G5 = Mega tough
Agreed.
64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit. Doesn't mater if its 32 or 64 bit process.
Open firmware drivers will only be used if they are OS 9 compatible.
My understanding though is that G5's do implement PowerPC architecture. The things that are missing are actually suggested and not required for a PowerPC architecture. If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.
Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing), I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel. From there, kaboom. Like big time bad. Not sure what the fuck happened, but it left my G5 in a very sorry state.
64/32 bit does matter as it affect the EA calculations and register content... But it’s no big deal to switch a 64 bit PPC to address mode.
Open firmware drivers are per definition OS 9 compliant, however there exists a shim to use respective driver from OS 9 is another question.
No the G5 does NOT implement the entire PowerPC architecture; the most well known lacking feature is swizzle mode (pesudo little endian).
There differences documented in the OS X Internals - A system approach.
Additionally XNU (The OS X kernel) has at least the UISA breaches documented and handled here
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.5.x/osfmk/ppc/Emulate64.s
IBM never claimed the PowerPC 970 implemented anything but PowerPC UISA compatibilty (which isnt entierly correct either as noted in the emulate.s file)
VEA and OSA is very different and does not conform to Book E.
I'll back up. Yes some of this I was wrong on.
But I'm not conviced on the Open Firmware drivers.
What is the definition that states the compatibility?
If I understand your statement, then OS 9 should have no problem booting on the xserve without removing the bridge controller for the ATA bus controlling the hard disks (not the one the optical drive is attached to).
No I'm saying that Open Firmware has builtin drivers for accessing the disk, for reading input devices, for ethernet etc. You loose this ability as soon as you quiesce the firmware however (that essentially tells the firmware to backdown, so normally you wouldn't quiesce until copied the device tree and loaded a replacement driver)-
but the OS can restore the open firmware for a single call if it wants to (requires supervisor access however)... So what I'm saying is that technically relatively simple shims should be possible to write to have something running.
I'm not saying Mac OS 9 does this, but technically it's possible (it's very likely it never opens an OF connection again once it's quiesced it).
-
however there exists a shim to use respective driver from OS 9 is another question.
Yes we are on the same page here, but the wording of this made it not clear.
-
G5 = Mega tough
Agreed.
64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit. Doesn't mater if its 32 or 64 bit process.
Open firmware drivers will only be used if they are OS 9 compatible.
My understanding though is that G5's do implement PowerPC architecture. The things that are missing are actually suggested and not required for a PowerPC architecture. If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.
Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing), I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel. From there, kaboom. Like big time bad. Not sure what the fuck happened, but it left my G5 in a very sorry state.
64/32 bit does matter as it affect the EA calculations and register content... But it’s no big deal to switch a 64 bit PPC to address mode.
Open firmware drivers are per definition OS 9 compliant, however there exists a shim to use respective driver from OS 9 is another question.
No the G5 does NOT implement the entire PowerPC architecture; the most well known lacking feature is swizzle mode (pesudo little endian).
There differences documented in the OS X Internals - A system approach.
Additionally XNU (The OS X kernel) has at least the UISA breaches documented and handled here
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.5.x/osfmk/ppc/Emulate64.s
IBM never claimed the PowerPC 970 implemented anything but PowerPC UISA compatibilty (which isnt entierly correct either as noted in the emulate.s file)
VEA and OSA is very different and does not conform to Book E.
I'll back up. Yes some of this I was wrong on.
But I'm not conviced on the Open Firmware drivers.
What is the definition that states the compatibility?
If I understand your statement, then OS 9 should have no problem booting on the xserve without removing the bridge controller for the ATA bus controlling the hard disks (not the one the optical drive is attached to).
No I'm saying that Open Firmware has builtin drivers for accessing the disk, for reading input devices, for ethernet etc. You loose this ability as soon as you quiesce the firmware however (that essentially tells the firmware to backdown, so normally you wouldn't quiesce until copied the device tree and loaded a replacement driver)-
but the OS can restore the open firmware for a single call if it wants to (requires supervisor access however)... So what I'm saying is that technically relatively simple shims should be possible to write to have something running.
I'm not saying Mac OS 9 does this, but technically it's possible (it's very likely it never opens an OF connection again once it's quiesced it).
It is possible to do this, but it would require a bit of knowledge on how things work.
Here is what I think would be needed to write an ATA driver for the 9Serve.
It would probably be easiest to copy the code from OF and write a regular driver, rather than use OF directly. Disk drivers get called at all kinds of inconvenient times and it would be hard to make sure OF is safe. OF code is PPC and relevant code is neatly grouped in packages. It would be fairly simple to adapt the driver code to use different calling conventions.
We would need to figure out how the API/ABI for ATA drivers work in Mac OS 9. I hope that there is documentation on this, but I don't trust that there is any. Maybe we could reverse engineer other ATA drivers to figure out how they work?
We need to figure out how to make the Trampoline not freak out when it encounters the ATA device tree node in a 9serve. I have absolutely no idea how to do this, but it will involve understanding both the Trampoline and the way Mac OS 9 handles interrupts.
Once we have done all these things, we will have a device driver and a modified Trampoline. I am guessing that both of these will go in the Mac OS ROM file.
-
My 9serve is standing by with eager anticipation! ;)
-
G5 = Mega tough
Agreed.
64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit. Doesn't mater if its 32 or 64 bit process.
Open firmware drivers will only be used if they are OS 9 compatible.
My understanding though is that G5's do implement PowerPC architecture. The things that are missing are actually suggested and not required for a PowerPC architecture. If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.
Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing), I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel. From there, kaboom. Like big time bad. Not sure what the fuck happened, but it left my G5 in a very sorry state.
64/32 bit does matter as it affect the EA calculations and register content... But it’s no big deal to switch a 64 bit PPC to address mode.
Open firmware drivers are per definition OS 9 compliant, however there exists a shim to use respective driver from OS 9 is another question.
No the G5 does NOT implement the entire PowerPC architecture; the most well known lacking feature is swizzle mode (pesudo little endian).
There differences documented in the OS X Internals - A system approach.
Additionally XNU (The OS X kernel) has at least the UISA breaches documented and handled here
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.5.x/osfmk/ppc/Emulate64.s
IBM never claimed the PowerPC 970 implemented anything but PowerPC UISA compatibilty (which isnt entierly correct either as noted in the emulate.s file)
VEA and OSA is very different and does not conform to Book E.
I'll back up. Yes some of this I was wrong on.
But I'm not conviced on the Open Firmware drivers.
What is the definition that states the compatibility?
If I understand your statement, then OS 9 should have no problem booting on the xserve without removing the bridge controller for the ATA bus controlling the hard disks (not the one the optical drive is attached to).
No I'm saying that Open Firmware has builtin drivers for accessing the disk, for reading input devices, for ethernet etc. You loose this ability as soon as you quiesce the firmware however (that essentially tells the firmware to backdown, so normally you wouldn't quiesce until copied the device tree and loaded a replacement driver)-
but the OS can restore the open firmware for a single call if it wants to (requires supervisor access however)... So what I'm saying is that technically relatively simple shims should be possible to write to have something running.
I'm not saying Mac OS 9 does this, but technically it's possible (it's very likely it never opens an OF connection again once it's quiesced it).
It is possible to do this, but it would require a bit of knowledge on how things work.
Here is what I think would be needed to write an ATA driver for the 9Serve.
It would probably be easiest to copy the code from OF and write a regular driver, rather than use OF directly. Disk drivers get called at all kinds of inconvenient times and it would be hard to make sure OF is safe. OF code is PPC and relevant code is neatly grouped in packages. It would be fairly simple to adapt the driver code to use different calling conventions.
We would need to figure out how the API/ABI for ATA drivers work in Mac OS 9. I hope that there is documentation on this, but I don't trust that there is any. Maybe we could reverse engineer other ATA drivers to figure out how they work?
We need to figure out how to make the Trampoline not freak out when it encounters the ATA device tree node in a 9serve. I have absolutely no idea how to do this, but it will involve understanding both the Trampoline and the way Mac OS 9 handles interrupts.
Once we have done all these things, we will have a device driver and a modified Trampoline. I am guessing that both of these will go in the Mac OS ROM file.
I don't know about the Xserve (and why it would be favoured over regular powermac g5s for this purpose).
On OS 9 I don't think there would be significant issues, OF driver calls are synchronous (which also means the performance impact would be huge), I'm not entierly sure how disk drivers are invoked in Mac OS 9-9.2.2, I do recall that the file manager was made MP safe in Mac OS 9, I think the simplest (but also fairly slow) solution would be to write a very slim ndrv that issues a sc (system call instruction) and funnel calls from a central (nano kernel) place if one would attempt the OF path.
As for drivers- I think the PCI SDK should have enough info to be able to progress on this (at least for the shim path). Unfortunately Mac OS 9 is a pain in the butt to work with when it comes to drivers. Personally I would rather prefer attempting to get something going in QEMU with a 970 target than physical hardware to start with.
Also I don't believe attempting to reverse engineer code from OF is worthwile (the FCode drivers that exist are as noted sync and just the absolute minimum to be able to operate on any arbitary device OF detects)- it's probably way easier to rip it from Mac OS X (if available. To be honest I'm not sure if the ATA kexts ever was open sourced) or Linux.
As for removing specific controllers from Mac OS 9s knowledge (if they pose a problem), perhaps I'm wrong but wouldn't dropping it from the device-tree be enough? I can't recall I ever heard of OS 9 doing hardware probes on it's own on PCI PowerMacs.
I'm not sure what you mean with how OS 9 handles interrupts? I believe (but I'm quite rusty on the area, it's been like 18 years since I last digged around deep in Mac OS, so it could be somewhat inaccurate) but I think the general architecture (as of Mac OS 8.6 and later at least) is be that the nanokernel recieves the exception (owns the physical exception vector) and either handles it directly or routes it to the active MPTasks exception handler which in case of Mac OS would be the blue task, which in turn maps it to a 68k interrupt level and hands it to the 68k emulator for processing inside Mac OS.
-
G5 = Mega tough
Agreed.
64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit. Doesn't mater if its 32 or 64 bit process.
Open firmware drivers will only be used if they are OS 9 compatible.
My understanding though is that G5's do implement PowerPC architecture. The things that are missing are actually suggested and not required for a PowerPC architecture. If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.
Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing), I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel. From there, kaboom. Like big time bad. Not sure what the fuck happened, but it left my G5 in a very sorry state.
64/32 bit does matter as it affect the EA calculations and register content... But it’s no big deal to switch a 64 bit PPC to address mode.
Open firmware drivers are per definition OS 9 compliant, however there exists a shim to use respective driver from OS 9 is another question.
No the G5 does NOT implement the entire PowerPC architecture; the most well known lacking feature is swizzle mode (pesudo little endian).
There differences documented in the OS X Internals - A system approach.
Additionally XNU (The OS X kernel) has at least the UISA breaches documented and handled here
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.5.x/osfmk/ppc/Emulate64.s
IBM never claimed the PowerPC 970 implemented anything but PowerPC UISA compatibilty (which isnt entierly correct either as noted in the emulate.s file)
VEA and OSA is very different and does not conform to Book E.
I'll back up. Yes some of this I was wrong on.
But I'm not conviced on the Open Firmware drivers.
What is the definition that states the compatibility?
If I understand your statement, then OS 9 should have no problem booting on the xserve without removing the bridge controller for the ATA bus controlling the hard disks (not the one the optical drive is attached to).
No I'm saying that Open Firmware has builtin drivers for accessing the disk, for reading input devices, for ethernet etc. You loose this ability as soon as you quiesce the firmware however (that essentially tells the firmware to backdown, so normally you wouldn't quiesce until copied the device tree and loaded a replacement driver)-
but the OS can restore the open firmware for a single call if it wants to (requires supervisor access however)... So what I'm saying is that technically relatively simple shims should be possible to write to have something running.
I'm not saying Mac OS 9 does this, but technically it's possible (it's very likely it never opens an OF connection again once it's quiesced it).
It is possible to do this, but it would require a bit of knowledge on how things work.
Here is what I think would be needed to write an ATA driver for the 9Serve.
It would probably be easiest to copy the code from OF and write a regular driver, rather than use OF directly. Disk drivers get called at all kinds of inconvenient times and it would be hard to make sure OF is safe. OF code is PPC and relevant code is neatly grouped in packages. It would be fairly simple to adapt the driver code to use different calling conventions.
We would need to figure out how the API/ABI for ATA drivers work in Mac OS 9. I hope that there is documentation on this, but I don't trust that there is any. Maybe we could reverse engineer other ATA drivers to figure out how they work?
We need to figure out how to make the Trampoline not freak out when it encounters the ATA device tree node in a 9serve. I have absolutely no idea how to do this, but it will involve understanding both the Trampoline and the way Mac OS 9 handles interrupts.
Once we have done all these things, we will have a device driver and a modified Trampoline. I am guessing that both of these will go in the Mac OS ROM file.
I don't know about the Xserve (and why it would be favoured over regular powermac g5s for this purpose).
On OS 9 I don't think there would be significant issues, OF driver calls are synchronous (which also means the performance impact would be huge), I'm not entierly sure how disk drivers are invoked in Mac OS 9-9.2.2, I do recall that the file manager was made MP safe in Mac OS 9, I think the simplest (but also fairly slow) solution would be to write a very slim ndrv that issues a sc (system call instruction) and funnel calls from a central (nano kernel) place if one would attempt the OF path.
As for drivers- I think the PCI SDK should have enough info to be able to progress on this (at least for the shim path). Unfortunately Mac OS 9 is a pain in the butt to work with when it comes to drivers. Personally I would rather prefer attempting to get something going in QEMU with a 970 target than physical hardware to start with.
Also I don't believe attempting to reverse engineer code from OF is worthwile (the FCode drivers that exist are as noted sync and just the absolute minimum to be able to operate on any arbitary device OF detects)- it's probably way easier to rip it from Mac OS X (if available. To be honest I'm not sure if the ATA kexts ever was open sourced) or Linux.
As for removing specific controllers from Mac OS 9s knowledge (if they pose a problem), perhaps I'm wrong but wouldn't dropping it from the device-tree be enough? I can't recall I ever heard of OS 9 doing hardware probes on it's own on PCI PowerMacs.
I'm not sure what you mean with how OS 9 handles interrupts? I believe (but I'm quite rusty on the area, it's been like 18 years since I last digged around deep in Mac OS, so it could be somewhat inaccurate) but I think the general architecture (as of Mac OS 8.6 and later at least) is be that the nanokernel recieves the exception (owns the physical exception vector) and either handles it directly or routes it to the active MPTasks exception handler which in case of Mac OS would be the blue task, which in turn maps it to a 68k interrupt level and hands it to the 68k emulator for processing inside Mac OS.
The Xserve is noteworthy because Mac OS 9 is only really incompatible with the ATA chipset on it. To boot it, you have to delete the nodes for the ATA controllers and everything is fine. I mentioned it because there is only one task that needs to be done with it. It has one component Mac OS 9 can't handle. The G5 has many, and it is not clear how to test if 1 problem is fixed when the others are still there.
Dropping stuff from the device tree is enough, but then you can't use the device you forgot about. The Trampoline crashes hard when it encounters the interrupt properties of the ATA chipset's device tree node. An understanding of how these values map to NanoKernel and Name Registry stuff is needed to properly fix those issues. I am guessing that this knowledge will be helpful for G5 stuff too, because of that "Cascading Interrupt but no Cascading Bridge" (or something like that) error message.
-
Daniel and I are on the same page here. The G5 is kinda like fighting a war on many fronts simultaneously. There are a number of fundamental things we can learn more easily by attacking isolated problems on other machines first, ones where we have at least been able to boot through to the Finder successfully. Good examples would be as follows:
- Powerbooks/iBooks - correct video, sound and trackpad behaviours
- Xserve - primary ATA/RAID controller driver or firmware resolution, support for front-panel CPU meters
- Mini - PMU driver, may simultaneously resolve the need for disabling USB
The G5 is a lofty goal, but should be easier with more experience under our belts. A good example of learning from another machine was when I figured out how to enable the serial port on the Xserve under OS 9. This would have been awfully difficult without getting the machine to boot first. The Xserve is actually a great platform for OS 9, and can use the dual 1.8GHz CPU. It seems far less likely to self-destruct than a G5 too.
-
Daniel and I are on the same page here. The G5 is kinda like fighting a war on many fronts simultaneously. There are a number of fundamental things we can learn more easily by attacking isolated problems on other machines first, ones where we have at least been able to boot through to the Finder successfully. Good examples would be as follows:
- Powerbooks/iBooks - correct video, sound and trackpad behaviours
- Xserve - primary ATA/RAID controller driver or firmware resolution, support for front-panel CPU meters
- Mini - PMU driver, may simultaneously resolve the need for disabling USB
The G5 is a lofty goal, but should be easier with more experience under our belts. A good example of learning from another machine was when I figured out how to enable the serial port on the Xserve under OS 9. This would have been awfully difficult without getting the machine to boot first. The Xserve is actually a great platform for OS 9, and can use the dual 1.8GHz CPU. It seems far less likely to self-destruct than a G5 too.
I don't think that native boot of OS 9 on a G5 will ever come, there are simply to many drivers that need to be written.
I do think that it could be done with qemu, as qemu does the G5 on a basic sawtooth machine. Tho the state of the emulated G5 is it can't boot the Mac OS, as there seem to be unimplemented spr's that the Mac OS expects to use.
Shouldn't be that hard to implement these missing spr's, I just haven't looked into it. The G5 does boot Linux in qemu-system-ppc64 on the mac99 machine.
I've pretty much figured out the graphics 'NDRV' for ATI cards in OS 9, soon I'll have an OS 9 compatible nVidia card, and I have a PowerBook6,8 with GFGO5200, so I should be able to figure out the nVidia 'NDRV'.
As for graphic acceleration, for the 9200 based systems, it should be doable, but 9550/9600/9700 likely will never do 3D under OS 9, unless someone wants to port linux's Radeon driver, and mesa to OS 9. Not an easy task as they are built on X11.
Sound seems fickle, I have and iBook G3 and an iBook G4, both have the i2s sound device in the device tree, and the iBook G4 won't boot unless " screamer" is used as the " compatible" property. Or the device is removed from the tree.
With the iBook G4 the mouse is odd, it's just a USB tracpad, and it should work with OS 9, but it doesn't. It doesn't work with Tiger 10.4.0 either, so we know that the driver was added to 10.4.2 and later.
Are the USBHID drivers open source for OS X?
Damn Apple and there non-standard USBHID device. >:(
-
Daniel and I are on the same page here. The G5 is kinda like fighting a war on many fronts simultaneously. There are a number of fundamental things we can learn more easily by attacking isolated problems on other machines first, ones where we have at least been able to boot through to the Finder successfully. Good examples would be as follows:
- Powerbooks/iBooks - correct video, sound and trackpad behaviours
- Xserve - primary ATA/RAID controller driver or firmware resolution, support for front-panel CPU meters
- Mini - PMU driver, may simultaneously resolve the need for disabling USB
The G5 is a lofty goal, but should be easier with more experience under our belts. A good example of learning from another machine was when I figured out how to enable the serial port on the Xserve under OS 9. This would have been awfully difficult without getting the machine to boot first. The Xserve is actually a great platform for OS 9, and can use the dual 1.8GHz CPU. It seems far less likely to self-destruct than a G5 too.
I don't think that native boot of OS 9 on a G5 will ever come, there are simply to many drivers that need to be written.
I do think that it could be done with qemu, as qemu does the G5 on a basic sawtooth machine. Tho the state of the emulated G5 is it can't boot the Mac OS, as there seem to be unimplemented spr's that the Mac OS expects to use.
Shouldn't be that hard to implement these missing spr's, I just haven't looked into it. The G5 does boot Linux in qemu-system-ppc64 on the mac99 machine.
I've pretty much figured out the graphics 'NDRV' for ATI cards in OS 9, soon I'll have an OS 9 compatible nVidia card, and I have a PowerBook6,8 with GFGO5200, so I should be able to figure out the nVidia 'NDRV'.
As for graphic acceleration, for the 9200 based systems, it should be doable, but 9550/9600/9700 likely will never do 3D under OS 9, unless someone wants to port linux's Radeon driver, and mesa to OS 9. Not an easy task as they are built on X11.
Sound seems fickle, I have and iBook G3 and an iBook G4, both have the i2s sound device in the device tree, and the iBook G4 won't boot unless " screamer" is used as the " compatible" property. Or the device is removed from the tree.
With the iBook G4 the mouse is odd, it's just a USB tracpad, and it should work with OS 9, but it doesn't. It doesn't work with Tiger 10.4.0 either, so we know that the driver was added to 10.4.2 and later.
Are the USBHID drivers open source for OS X?
Damn Apple and there non-standard USBHID device. >:(
No the unimplemented SPRs messages you see when you start QEMU is due to it’s firmware attempting to access book III SPRs.
As already said the most obvious modifications to even get past the lowest level code is to rewrite the TLB setup and as I said before several times the G5 don’t have BAT registers and I know for a fact Mac OS 9 uses them. But sure you could implement them, but it wouldn’t be a G5 anylonger.
As for 3D acceleration, Apple never released any 3D acceleration driver SDK, there is no hooks/API etc so even if you had complete documentation and or source code over a particular graphics chipset; what next? Reverse engineer Apples RAVE/OpenGL extension?
The basic 2D acceleraions hooks are documented however. (And further 2D acceleration- quickdraw for example is partially reverse engineered and can be found in the Basillisk source code)
---
I retract the statement about the SPRs above, my memory was apparently wrong; so now when I actually _tried_ it I get something like this (even on a cpu model that boots Mac OS 9 in qemu)
"Trying to write invalid spr 0 (0x000) at 00f113c0
Trying to read invalid spr 0 (0x000) at 00f113c8
Trying to write privileged spr 955 (0x3bb) at 00f168c8
Trying to write invalid spr 959 (0x3bf) at 00f16930
Trying to read invalid spr 959 (0x3bf) at 00f16938
Trying to write privileged spr 955 (0x3bb) at 00f168c8
Trying to write invalid spr 959 (0x3bf) at 00f16930
Trying to read invalid spr 959 (0x3bf) at 00f16938"
This is Mac OS probing the processor indeed,
spr 0 is the 601 only MQ register (used by POWER instructions that the 601 included).
https://www.nxp.com/docs/en/data-sheet/MPC601.pdf - Described at page 14
955 is SIA (Sampled Instruction Address) not essential to run the system.
959 is SDA (Sampled Data Address) same as above.
https://www.nxp.com/docs/en/data-sheet/MPC604.pdf - Described at page 19 (955/959)
Additionally compare (especially the "Memory Management Registers") to
http://www.redbooks.ibm.com/redpapers/pdfs/redp3890.pdf - Page 13 (OEA environment)
-
Daniel and I are on the same page here. The G5 is kinda like fighting a war on many fronts simultaneously. There are a number of fundamental things we can learn more easily by attacking isolated problems on other machines first, ones where we have at least been able to boot through to the Finder successfully. Good examples would be as follows:
- Powerbooks/iBooks - correct video, sound and trackpad behaviours
- Xserve - primary ATA/RAID controller driver or firmware resolution, support for front-panel CPU meters
- Mini - PMU driver, may simultaneously resolve the need for disabling USB
The G5 is a lofty goal, but should be easier with more experience under our belts. A good example of learning from another machine was when I figured out how to enable the serial port on the Xserve under OS 9. This would have been awfully difficult without getting the machine to boot first. The Xserve is actually a great platform for OS 9, and can use the dual 1.8GHz CPU. It seems far less likely to self-destruct than a G5 too.
I don't think that native boot of OS 9 on a G5 will ever come, there are simply to many drivers that need to be written.
I do think that it could be done with qemu, as qemu does the G5 on a basic sawtooth machine. Tho the state of the emulated G5 is it can't boot the Mac OS, as there seem to be unimplemented spr's that the Mac OS expects to use.
Shouldn't be that hard to implement these missing spr's, I just haven't looked into it. The G5 does boot Linux in qemu-system-ppc64 on the mac99 machine.
I've pretty much figured out the graphics 'NDRV' for ATI cards in OS 9, soon I'll have an OS 9 compatible nVidia card, and I have a PowerBook6,8 with GFGO5200, so I should be able to figure out the nVidia 'NDRV'.
As for graphic acceleration, for the 9200 based systems, it should be doable, but 9550/9600/9700 likely will never do 3D under OS 9, unless someone wants to port linux's Radeon driver, and mesa to OS 9. Not an easy task as they are built on X11.
Sound seems fickle, I have and iBook G3 and an iBook G4, both have the i2s sound device in the device tree, and the iBook G4 won't boot unless " screamer" is used as the " compatible" property. Or the device is removed from the tree.
With the iBook G4 the mouse is odd, it's just a USB tracpad, and it should work with OS 9, but it doesn't. It doesn't work with Tiger 10.4.0 either, so we know that the driver was added to 10.4.2 and later.
Are the USBHID drivers open source for OS X?
Damn Apple and there non-standard USBHID device. >:(
No the unimplemented SPRs messages you see when you start QEMU is due to it’s firmware attempting to access book III SPRs.
As already said the most obvious modifications to even get past the lowest level code is to rewrite the TLB setup and as I said before several times the G5 don’t have BAT registers and I know for a fact Mac OS 9 uses them. But sure you could implement them, but it wouldn’t be a G5 anylonger.
As for 3D acceleration, Apple never released any 3D acceleration driver SDK, there is no hooks/API etc so even if you had complete documentation and or source code over a particular graphics chipset; what next? Reverse engineer Apples RAVE/OpenGL extension?
The basic 2D acceleraions hooks are documented however. (And further 2D acceleration- quickdraw for example is partially reverse engineered and can be found in the Basillisk source code)
---
I retract the statement about the SPRs above, my memory was apparently wrong; so now when I actually _tried_ it I get something like this (even on a cpu model that boots Mac OS 9 in qemu)
"Trying to write invalid spr 0 (0x000) at 00f113c0
Trying to read invalid spr 0 (0x000) at 00f113c8
Trying to write privileged spr 955 (0x3bb) at 00f168c8
Trying to write invalid spr 959 (0x3bf) at 00f16930
Trying to read invalid spr 959 (0x3bf) at 00f16938
Trying to write privileged spr 955 (0x3bb) at 00f168c8
Trying to write invalid spr 959 (0x3bf) at 00f16930
Trying to read invalid spr 959 (0x3bf) at 00f16938"
This is Mac OS probing the processor indeed,
spr 0 is the 601 only MQ register (used by POWER instructions that the 601 included).
https://www.nxp.com/docs/en/data-sheet/MPC601.pdf - Described at page 14
955 is SIA (Sampled Instruction Address) not essential to run the system.
959 is SDA (Sampled Data Address) same as above.
https://www.nxp.com/docs/en/data-sheet/MPC604.pdf - Described at page 19 (955/959)
Additionally compare (especially the "Memory Management Registers") to
http://www.redbooks.ibm.com/redpapers/pdfs/redp3890.pdf - Page 13 (OEA environment)
Well, if you port Mesa to the Mac OS, you don't need to worry about Apple's OpenGL.
Not going to happen anyway, I only bring it up whereas to say what "could" be done, not what will be done.
I forget the SPR's that qemu-system-ppc64 spits out when trying to boot OS X with the G5 CPU, like I said, I really haven't looked into it. BootX just hangs, I created a version of BootX for Tiger with logging to see where the 7447a was hanging BootX, so I could use that to see where the touble is with the G5, tho it would only be an exercise in booting the Kernel, as we'd very soon be greeted by a kernel panic. As has already been confirmed by a KVM user that tried to boot on a real G5 using mac99 machine.
-
Sorry, I'm not following this thread, but:
Well, if you port Mesa to the Mac OS, you don't need to worry about Apple's OpenGL.
Just to note that this is already done. IIRC
-
Sorry, I'm not following this thread, but:
Well, if you port Mesa to the Mac OS, you don't need to worry about Apple's OpenGL.
Just to note that this is already done. IIRC
There is some super old port of Mesa somewhere, software rendering only.
And it was concieved before Apple purchased it’s OpenGL implementation from Conix.
But you’re right wouldn’t need to worry about Apples OpenGL in case, but rather getting gcc 4.2 or later, a modern pyhton etc.
Odd, Mac OS X boots just fine for me with Qemu and KVM on a G5, haven’t tried
TCG.
-
This is Mac OS probing the processor indeed,
Partly reversed here:
https://github.com/elliotnunn/powermac-rom/blob/master/NanoKernel/NKTranslation.s?ts=4#L2117-L2252 (https://github.com/elliotnunn/powermac-rom/blob/master/NanoKernel/NKTranslation.s?ts=4#L2117-L2252)
-
But at the same time it’s not really a proper PowerPC, it does not implement all things defined in the PowerPC architecture. It doesn’t even have all instructions, so some have to be implemented and emulated at OS level (an application wouldn’t notice though).
But MacOS 9 is not an application; and it uses a lot of the constructs that the G5 lacks (BAT registers for example. And emulating the BATs with PTEs would probably require quite some hacks in the nanokernel.
Naiw, I'd like to know a bit more about this, if you don't mind my asking. If OS 9 implements PowerPC mnemonics (if I understood you correctly) not present in IBM's 970 architecture (G5) as you say, then are you suggesting that Apple's Classic application not only virtualizes OS 9 in a transparent virtual machine as we all know, but also already emulates those few required Motorolla PPC instructions, perhaps by trapping them much like how Apple handled 68k+PPC code before? At the very least since late versions of Mac OS X 10.2 Jaguar, which was the first Mac OS X iteration to be available on G5s?
(Also, for reference, for those curious:
- Release date of the first G5s ever: June 23, 2003
- Release date of Mac OS 10.3 Panther: October 24, 2003
Source: Wikipedia 2018-03-28 11:00 AM GMT-3, Panther and PowerMac/iMac G5 articles.)
Because if Classic isn't doing such emulation, then running OS 9 on Classic (on G5) would be simply impossible, right? There's no way mere virtualization alone could handle that, correct?
... Unless they changed OS 9 itself to replace those instructions, and thus released Mac OS 9.2.2, which, by the way, I do remember reading from changelogs that it implemented "better Classic support" or so. Of course, that's just wishful thinking, but I can't discard the perfectly-valid possibility and, thus, I ask: Naiw, you mentioned OS 9 "uses a lot of the constructs that the G5 lacks", but did you verify that specifically with OS 9.2.2 or did you verify that only with some earlier version(s)?
I'm just trying to sort that stuff out. Again, I hope you don't mind my asking!
(Incidentally, I know the lack of ANY straightforward little-endian support on G5, which all 32-bit PPC processors (Motorolla's, at least) had, is not at all a problem for OS 9, but only for emulation/virtualization of little-endian architectures/OSes, which is the main reason VirtualPC is worse on G5s than G4s in, at least, an equal processor clock speed configuration.
Not that you necessarily said or implied otherwise, but I figured I'd clear that up in case anyone would be confused by this.)
-
Naiw, I'd like to know a bit more about this, if you don't mind my asking. If OS 9 implements PowerPC mnemonics (if I understood you correctly) not present in IBM's 970 architecture (G5) as you say, then are you suggesting that Apple's Classic application not only virtualizes OS 9 in a transparent virtual machine as we all know, but also already emulates those few required Motorolla PPC instructions, perhaps by trapping them much like how Apple handled 68k+PPC code before? At the very least since late versions of Mac OS X 10.2 Jaguar, which was the first Mac OS X iteration to be available on G5s?
OS X on the G5 emulates the instructions needed for OS 9 in the actual emulator/runtime environment in classic.
My understanding on 9 is that it may be trapping and handlig uknown PPC instructions. So in theory, those could be trapped and handled for running on the G5. The trampoline code can install the trap handler for that so that the core OS wouldn't need to be patched. I may be wrong on this though. I haven't dug too deep into it.
-
But at the same time it’s not really a proper PowerPC, it does not implement all things defined in the PowerPC architecture. It doesn’t even have all instructions, so some have to be implemented and emulated at OS level (an application wouldn’t notice though).
But MacOS 9 is not an application; and it uses a lot of the constructs that the G5 lacks (BAT registers for example. And emulating the BATs with PTEs would probably require quite some hacks in the nanokernel.
Naiw, I'd like to know a bit more about this, if you don't mind my asking. If OS 9 implements PowerPC mnemonics (if I understood you correctly) not present in IBM's 970 architecture (G5) as you say, then are you suggesting that Apple's Classic application not only virtualizes OS 9 in a transparent virtual machine as we all know, but also already emulates those few required Motorolla PPC instructions, perhaps by trapping them much like how Apple handled 68k+PPC code before? At the very least since late versions of Mac OS X 10.2 Jaguar, which was the first Mac OS X iteration to be available on G5s?
(Also, for reference, for those curious:
- Release date of the first G5s ever: June 23, 2003
- Release date of Mac OS 10.3 Panther: October 24, 2003
Source: Wikipedia 2018-03-28 11:00 AM GMT-3, Panther and PowerMac/iMac G5 articles.)
Because if Classic isn't doing such emulation, then running OS 9 on Classic (on G5) would be simply impossible, right? There's no way mere virtualization alone could handle that, correct?
... Unless they changed OS 9 itself to replace those instructions, and thus released Mac OS 9.2.2, which, by the way, I do remember reading from changelogs that it implemented "better Classic support" or so. Of course, that's just wishful thinking, but I can't discard the perfectly-valid possibility and, thus, I ask: Naiw, you mentioned OS 9 "uses a lot of the constructs that the G5 lacks", but did you verify that specifically with OS 9.2.2 or did you verify that only with some earlier version(s)?
I'm just trying to sort that stuff out. Again, I hope you don't mind my asking!
(Incidentally, I know the lack of ANY straightforward little-endian support on G5, which all 32-bit PPC processors (Motorolla's, at least) had, is not at all a problem for OS 9, but only for emulation/virtualization of little-endian architectures/OSes, which is the main reason VirtualPC is worse on G5s than G4s in, at least, an equal processor clock speed configuration.
Not that you necessarily said or implied otherwise, but I figured I'd clear that up in case anyone would be confused by this.)
First of all- just make one thing clear I’m not an expert on Classic; I stopped classic Mac OS development by the time Mac OS X was released, but I did use it a few times but not to that extent that I’ve actually reverse engineered it.
But I can share what I know (either because I found out by myself or because I at some point asked someone who ought to have good insight in the implementation out of curiousity)
But I’ll try to answer this the best I can and that I remember; with reservation for inaccuracies :p
Short answer:
Mac OS 7-9 works like this (abstraction level left to right)
HW -> Nanokernel -> 68k emulator -> Mac OS
Classic.
HW -> Xnu -> Classic -> 68k emulator -> Mac OS
Long answer:
As I said before the low level parts of ”Mac OS” (ie the parts that operates in powerpc supervisor mode) is the nanokernel (the nanokernel is not really part of Mac OS technically, but that’s something I’ve argued about before and really it doesn’t matter- it exists on all PowerPC implementations and later releases of Mac OS kind of depends on its services);
Classic however don’t use the nanokernel at all- instead it uses the Mac OS X kernel with a shim (the shim is of course to intercept nanokernel calls from within Mac OS- such those made internally by the MPLibrary).
This both makes the implementation easier as well removes complexity as well as avoids the need for supervisor mode at this abstraction level.
As for instruction emulation, this is also handled by Mac OS X kernel.
But there are exceptions that could be passed to classic via the OS kernel. Although this is the area my memory starts getting vague, I can not remember if custom exception handlers installed from classic apps actually worked.
But either way- there is no mechanism to override the kernel exception table; but unhandled exceptions are propagated to the currently executing mach tasks exception port and this is how classic would have to provide this functionality if it does/did.
A mach task (which is a container describing memory layout, threads and message ports- it’s kind of equivalent to a Process on most other systems, thus Mac OS X does not really have the concept of a process- but most of the system does... but that’s another topic)
Will recieve unhandled exceptions on it’s exception port
So summarized; The Mac OS X exception handler will always be first in line to handle any exceptions, (ie handle common exceptions). Unhandled exceptions will be passed to the mach tasks exception port and can be handled at that level.
But regardless as Mac OS 7-9 never exposed a powerpc supervisor mode to applications (and the area that is affected is the nanokernel which classic replace) there is little concern about instruction emulation. UISA is about the same.
But of course technically all of this could be emulated, but it’s certainly not the most efficient nor fastest path to solve the problem. What Apple did with classic is probably the most efficient way to solve it...
-
Ah, thanks, that was a great and well-detailed reply.
That clears a few things up a bit for me, and helped me realize something about what you said in an earlier post: according to you, the G5 processors implemented the UISA (User ISA) in a PowerPC-compliant way, meaning Book I of the POWER / PowerPC formal specifications, but not necessarily the rest (Books II, III and E).
Since the User ISA is 100% compatible and implemented between G5 and earlier PowerPC processors such as G3 and G4, doesn't that actually mean that Mac OS 9, which, being an OS, runs entirely on user space (excluding the nanokernel, which you suggested should be looked at separately) and, thus, is also 100% instruction-compatible with the G5 processor?
Assuming the answer to the previous question to be "Yes.", we are left with the nanokernel which, according to you, is normally used by OS 9, but is completely disregarded or even missing altogether in regards to Classic in Mac OS X (XNU). If I understood you correctly, the instructions you believe to be missing in the G5, which are on non-user-space, are present only in OS 9's nanokernel and are most likely emulated within XNU if XNU is running in a machine that lacks the native instruction.
Since Classic is a common program/process/task like any other that runs under Mac OS X, which in turn runs in user space, and since Classic delegates all the nanokernel calls to the XNU kernel instead, that means Classic itself does not and can not, by itself, emulate any missing instruction, but rely on XNU for all its nanokernel needs, including emulation of non-UISA-instructions, if needed. Classic is then unlike, for example, Rosetta on x86, which emulates the PPC UISA in an x86 UISA environment. And Classic IS like Rosetta in the sense that all that both can hope to achieve is stuck at UISA level (AKA user space).
With all this, I mean to conclude that, necessarily, Classic is not at all relevant to us here in terms of processor architecture compatibility or lack thereof for OS 9: the XNU kernel is. Correct?
If correct, then my understanding is that to solve this processor architecture problem, an implementation on the OS 9 nanokernel is necessary to immitate whatever the XNU is doing in those cases. And the XNU only. Preferably Tiger's XNU as opposed to Leopard's, as it's the last XNU revision we know for sure that had a motive to bother keeping OS 9 nanokernel instruction compatibility. Which is not to say that Mac OS X itself necessarily didn't contain those very instructions themselves to be later emulated within the XNU on G5s.
(For emphasis, motherboard & other hardware drivers, though, are still entirely different subjects and dependencies than what I'm trying to get at here.)
All OS 9 nanokernel gurus out there and Naiw, please do correct me if I said some gibberish somewhere here. :) I'm kinda walking blindfolded on some areas, but doing my best with it.
-
Ah, thanks, that was a great and well-detailed reply.
That clears a few things up a bit for me, and helped me realize something about what you said in an earlier post: according to you, the G5 processors implemented the UISA (User ISA) in a PowerPC-compliant way, meaning Book I of the POWER / PowerPC formal specifications, but not necessarily the rest (Books II, III and E).
Since the User ISA is 100% compatible and implemented between G5 and earlier PowerPC processors such as G3 and G4, doesn't that actually mean that Mac OS 9, which, being an OS, runs entirely on user space (excluding the nanokernel, which you suggested should be looked at separately) and, thus, is also 100% instruction-compatible with the G5 processor?
Assuming the answer to the previous question to be "Yes.", we are left with the nanokernel which, according to you, is normally used by OS 9, but is completely disregarded or even missing altogether in regards to Classic in Mac OS X (XNU). If I understood you correctly, the instructions you believe to be missing in the G5, which are on non-user-space, are present only in OS 9's nanokernel and are most likely emulated within XNU if XNU is running in a machine that lacks the native instruction.
Since Classic is a common program/process/task like any other that runs under Mac OS X, which in turn runs in user space, and since Classic delegates all the nanokernel calls to the XNU kernel instead, that means Classic itself does not and can not, by itself, emulate any missing instruction, but rely on XNU for all its nanokernel needs, including emulation of non-UISA-instructions, if needed. Classic is then unlike, for example, Rosetta on x86, which emulates the PPC UISA in an x86 UISA environment. And Classic IS like Rosetta in the sense that all that both can hope to achieve is stuck at UISA level (AKA user space).
With all this, I mean to conclude that, necessarily, Classic is not at all relevant to us here in terms of processor architecture compatibility or lack thereof for OS 9: the XNU kernel is. Correct?
If correct, then my understanding is that to solve this processor architecture problem, an implementation on the OS 9 nanokernel is necessary to immitate whatever the XNU is doing in those cases. And the XNU only. Preferably Tiger's XNU as opposed to Leopard's, as it's the last XNU revision we know for sure that had a motive to bother keeping OS 9 nanokernel instruction compatibility. Which is not to say that Mac OS X itself necessarily didn't contain those very instructions themselves to be later emulated within the XNU on G5s.
(For emphasis, motherboard & other hardware drivers, though, are still entirely different subjects and dependencies than what I'm trying to get at here.)
All OS 9 nanokernel gurus out there and Naiw, please do correct me if I said some gibberish somewhere here. :) I'm kinda walking blindfolded on some areas, but doing my best with it.
There is one or two instructions that isn't in UISA on the G5, but it's handled by the kernel as said in the earlier post.
(Posted this link before, but this is from Xnus kernel source. https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.4.x/osfmk/ppc/Emulate64.s - it explicitly lists dcba and mcrxr)
dcba is data cache block allocate- it can safely be ignored (it's just an optimisation instruction)
mcrxr is move to condition register from XER - this has uses and I don't know why IBM choose not to implement it in hardware, mainly it's useful to detect overflows.
Other than that I don't think there is any that is normally software emulated (if at all).
Xnu does not attempt to make the G5 behave like a G3 or G4 at OEA level- there is no reason to, it only bothers with UISA (most of the code in the emulate64.s class I posted above is actually about handling unaligned data- not because the G5 lacks hardware support for those instructions, the PowerPC can't access memory that isn't word aligned without throwing an exception- most systems therefor handles this by emulating the instructions when an unalignment exception occurs- this come at a performance penalty of course which is why NewPtr etc on Mac OS always returns (16 byte, if I remember right) aligned pointers- This is partially due to Altivec though so I would guess pre Mac OS 8.6 NewPtr probably returned 4 byte aligned pointers)
No that's not right, Classic can absolutely emulate instructions, to be able to emulate an instruction your software must be able to catch invalid instruction exceptions and get hold of the register state, Mac OS X certainly provides the facilities to do so- So does Mac OS 8.6+ as well for that matter- but you can of course not alter all registers in the representation,
I actually often used that when I wrote classic Mac OS apps, mainly for debug purposes- as you could do something like "sc" which would trigger the system call exception handler- once in the handler you could modify the single step bit of the represented MSR and return, this would trigger single step exceptions for each instruction Mac OS executed for that particular process (the exception handler was per process, not globally on the system). There for you could implement a simple software memory protection that you activated selectively around certain portions of the code you wanted to "sandbox"... but it was of course at a huge performance hit, but it was in my opinion better than crashing and potentially risk file system corruption or worse.
Yes I agree Classic is of little interest if you want to run Mac OS 9 natively on the G5. At least I can't come up with any particular area it would be worth investigating, drivers etc are as you say just delegated to OS X- possibly the only area that could be interesting as I see it is to see how it interfaced with the USB bus, cause classic allowed mac os 9 drivers to own USB devices as far as I remember.
Leopard would do fine as well, you don't have to focus blindly on Classic... Mac OS X binaries have the exact same problems/caveats when it comes to UISA as Classic did.
Yes drivers are a totally different beast and probably a much harder one at that... I still stand by that I believe OpenFirmware can be kept around to just have _something_ working/booting.