Author Topic: MacOS 9.2.2 Emulation with QEMU...we need help!  (Read 19070 times)

Offline gtxaspec

  • Member
  • *
  • Posts: 5
  • new to the forums
MacOS 9.2.2 Emulation with QEMU...we need help!
« 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
« Last Edit: December 12, 2015, 12:03:07 AM by gtxaspec »

Offline gtxaspec

  • Member
  • *
  • Posts: 5
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #1 on: December 11, 2015, 11:28:18 PM »
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
« Last Edit: December 11, 2015, 11:53:34 PM by gtxaspec »

Offline gtxaspec

  • Member
  • *
  • Posts: 5
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #2 on: December 11, 2015, 11:30:34 PM »
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
« Last Edit: December 11, 2015, 11:45:36 PM by gtxaspec »

Offline gtxaspec

  • Member
  • *
  • Posts: 5
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #3 on: December 11, 2015, 11:31:16 PM »
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:

Code: [Select]
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:

Code: [Select]
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
« Last Edit: December 11, 2015, 11:45:06 PM by gtxaspec »

Offline MacTron

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 1957
  • keep it simple
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #4 on: December 12, 2015, 01:52:38 AM »
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.
Please don't PM about things that are not private.

Offline DieHard

  • Administrator
  • Platinum Member
  • *****
  • Posts: 1321
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #5 on: December 12, 2015, 01:27:55 PM »
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.

Offline Jakl

  • Gold Member
  • *****
  • Posts: 304
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #6 on: December 12, 2015, 03:12:59 PM »
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.

Offline GaryN

  • Platinum Member
  • *****
  • Posts: 750
  • active member
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #7 on: December 12, 2015, 04:57:26 PM »
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Ö

Offline IIO

  • Platinum Member
  • *****
  • Posts: 1582
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #8 on: December 12, 2015, 11:22:36 PM »
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.
 
"It is true that the "pre-emptive multitasking" advantage present in OS X can be illustrated by downloading CD-ROM ISOs and rendering chaos theory formulas while simultaneously instant messaging and posting on FaceBook what you ate... but in reality, what did you create?"
- DieHard, random forum troll at macos9lives.com

Offline gtxaspec

  • Member
  • *
  • Posts: 5
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #9 on: December 13, 2015, 12:37:52 AM »
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

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 700
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #10 on: December 13, 2015, 07:11:22 AM »
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.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline iMic

  • Enthusiast
  • **
  • Posts: 26
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #11 on: December 16, 2015, 05:33:07 PM »
I've linked this discussion over in the 9.2.2 QEMU thread over on ThinkClassic 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.


Offline Texas_RangerAT

  • Active Member
  • **
  • Posts: 20
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #12 on: July 14, 2016, 08:23:35 AM »
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.

Offline darthnVader

  • Consistant Contributor
  • ***
  • Posts: 80
  • New Member
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #13 on: February 10, 2018, 03:22:45 PM »
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


Offline Naiw

  • Enthusiast
  • **
  • Posts: 46
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #14 on: February 11, 2018, 10:01:23 AM »
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.

Offline Daniel

  • Consistant Contributor
  • ***
  • Posts: 105
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #15 on: February 11, 2018, 10:50:48 AM »
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.

Offline DieHard

  • Administrator
  • Platinum Member
  • *****
  • Posts: 1321
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #16 on: February 11, 2018, 03:36:55 PM »
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

Offline macStuff

  • Gold Member
  • *****
  • Posts: 475
  • knowledge is power!
    • oldschooldaw
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #17 on: February 11, 2018, 06:56:05 PM »
wow 18000 views on this thread?  :o

Offline darthnVader

  • Consistant Contributor
  • ***
  • Posts: 80
  • New Member
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #18 on: February 12, 2018, 01:15:14 AM »
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.

 

Offline Naiw

  • Enthusiast
  • **
  • Posts: 46
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #19 on: February 12, 2018, 09:59:37 AM »
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.


Offline nanopico

  • Platinum Member
  • *****
  • Posts: 700
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #20 on: February 12, 2018, 08:18:53 PM »
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.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline Naiw

  • Enthusiast
  • **
  • Posts: 46
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #21 on: February 13, 2018, 03:43:08 AM »
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.



Offline nanopico

  • Platinum Member
  • *****
  • Posts: 700
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #22 on: February 13, 2018, 12:29:23 PM »
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).
If it ain't broke, don't fix it, or break it so you can fix it!

Offline Naiw

  • Enthusiast
  • **
  • Posts: 46
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #23 on: February 13, 2018, 01:07:04 PM »
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).

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 700
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #24 on: February 13, 2018, 01:59:09 PM »
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.


If it ain't broke, don't fix it, or break it so you can fix it!

Offline Daniel

  • Consistant Contributor
  • ***
  • Posts: 105
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #25 on: February 13, 2018, 02:22:49 PM »
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.

Offline MacOS Plus

  • Gold Member
  • *****
  • Posts: 342
  • The 9serve Lives!
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #26 on: February 13, 2018, 04:14:52 PM »
My 9serve is standing by with eager anticipation! ;)

Offline Naiw

  • Enthusiast
  • **
  • Posts: 46
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #27 on: February 13, 2018, 04:56:27 PM »
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.

Offline Daniel

  • Consistant Contributor
  • ***
  • Posts: 105
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #28 on: February 13, 2018, 07:18:14 PM »
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.


Offline MacOS Plus

  • Gold Member
  • *****
  • Posts: 342
  • The 9serve Lives!
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #29 on: February 13, 2018, 09:47:34 PM »
  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.

Offline darthnVader

  • Consistant Contributor
  • ***
  • Posts: 80
  • New Member
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #30 on: February 14, 2018, 06:57:54 AM »
  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. >:(

Offline Naiw

  • Enthusiast
  • **
  • Posts: 46
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #31 on: February 14, 2018, 11:05:44 AM »
  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)
« Last Edit: February 14, 2018, 01:00:43 PM by Naiw »

Offline darthnVader

  • Consistant Contributor
  • ***
  • Posts: 80
  • New Member
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #32 on: February 15, 2018, 03:45:47 AM »
  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.

Offline MacTron

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 1957
  • keep it simple
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #33 on: February 15, 2018, 06:55:36 AM »
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
Please don't PM about things that are not private.

Offline Naiw

  • Enthusiast
  • **
  • Posts: 46
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #34 on: February 15, 2018, 10:48:56 AM »
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.