GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

About Qemu-system-ppc, a PPC Mac emulator for Windows, macOS and Linux that can run Mac OS 9.0 up to Mac OS X 10.5

Moderators: Cat_7, Ronald P. Regensburg

darthnvader
Mac Mechanic
Posts: 178
Joined: Sun Feb 07, 2016 4:40 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by darthnvader »

I tried to patch OS 8.6 to run on the mac99, but I just ended up with either "Unemployment Trap" or other errors.

At this point what may be needed is to use the real Beige G3 Old World Rom, in Qemu. I was told, on the qemu-ppc mailing list, there was an effort to do this, but I've been unable to find any info on it, so I don't know how far it got.
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

Afaik,the Old World boot method is still unimplemented in g3beige.It requires one more device: /rom where OldWorld Mac OS ROM lives (in /rom/macos).It then could be started by "boot /rom/macos" command.
So far we've booted qemu g3beige a NewWold way (directly from openbios).
It seems that it isn't exhausted yet. Typing

Code: Select all

-prom-env 'boot-command=dev / " PowerMac1,1" encode-string " model" property "PowerMac1,1" encode-string " MacRISC" encode-string encode+ " Power Macintosh" encode-string encode+ " compatible" property new-device " rtas" device-name finish-device dev /rtas " rtas" encode-string " name" property 0 encode-int " rtas-size" property' 
on qemu command line when starting OS 8.6 in g3beige we get
"MacOS: unable to find an interrupt controller node".
Normally,interrupt controller should be in /pci/mac-io.For mac99 it exists there and has some properties.But in g3beige dev tree it is missing.Which is not normal.
Anyway,it would be fine to find correct values for interrupt-controller in g3beige and push them in.Hopefully it could also move the 8.6 boot process on.
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

steventroughtonsmith wrote:Just to clarify — the reason my boot scripts sometimes spoof PowerMac1,1 isn't anything to do with the OS itself, but the Forth/OF boot script that runs before BootX to decide whether your machine is compatible with the OS or not. It's not a hard check for anything, it just checks the model number. You can patch the ISO if you prefer, but spoofing is easy. Oldworld g3beige is significantly different from an actual New World Yosemite-class PowerMac1,1.
Is it that different?If you use the same spoofing with mac99 will you boot DP1 or Rhapsody?No.
It shows that BW and mac99 are really significantly different.
If the boot-script wants PowerMac1,1, doesn't it mean that the OS is targetting BW,not G3B?And still it boots.It means that BW and G3B are compatible.
I read that G3B is 1 of 2 Old World machines capable of booting MOSX(offically up to 10.2,with processor upgraded to G4 up to 10.5,just like BW).It makes it very similar to New World machines besides the boot method.
hyoenmadan
Student Driver
Posts: 11
Joined: Sun Jul 31, 2016 2:55 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by hyoenmadan »

alex195812 wrote: Normally,interrupt controller should be in /pci/mac-io.For mac99 it exists there and has some properties.But in g3beige dev tree it is missing.Which is not normal.
From this commit to Linux Kernel PROM parser:
https://ford.biologie.hu-berlin.de/matz ... 0721d8b8d9

They say OldWorld MacOS machines don't have and use Interrupt Controller nodes in the DT. Linux determines this special case with extra codepath in real hardware as is seen in this commit.
alex195812 wrote: If the boot-script wants PowerMac1,1, doesn't it mean that the OS is targetting BW,not G3B?And still it boots.It means that BW and G3B are compatible.
OldWorld boot method doesn't use the "Mac OS ROM" file at all. That's only for NewWorld Macs which don't have any Toolbox code in EEPROM at all. So no OF boot script runs in this case (not at least from the OS CD).
OldWorld boot method loads both OF and Toolbox from EEPROM, and it searches for the System File once ROM is running (it also can try to read from a driver partition before if the boot media doesn't have built in driver access support).
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

Oh,I didn;t know that about OW Macs.
Anyway,trying to use g3beige "as if" New World BW this node is needed.The values from mac99 won't do as it has openpic,not heathrow.
In that quote it was about OF script,not CD.And about DP1/Rhapsody,not Mac OS.
Though MacOS ROM on cd includes a Forth boot-script,too.
And yes,real OW Mac's do boot the way you described,but our qemu-emulated g3beige doesn't.It does boot cd:,\\:tbxi ,that is,loads Mac OS ROM from cd.

Now when I add

Code: Select all

-prom-env 'boot-command=dev / " PowerMac1,1" encode-string " model" property "PowerMac1,1" encode-string " MacRISC" encode-string encode+ " Power Macintosh" encode-string encode+ " compatible" property new-device " rtas" device-name finish-device dev /rtas " rtas" encode-string " name" property 0 encode-int " rtas-size" property dev /pci/mac-io new-device " interrupt-controller" device-name finish-device dev /pci/mac-io/interrupt-controller " interrupt-controller" encode-string " name" property " heathrow" encode-string " device-type" property " heathrow" encode-string " mac-risc" encode-string encode+ " compatible" property 1 encode-int " #interrupt-cells" property 0 encode-int " #address-cells" property 16 encode-int 32 encode-int encode+ " reg" property' 
to qemu command-line I can see interrupt-controller in /pci/mac-io but still have
"MacOS: Boot Failure! (0xF3C481F6)
MacOS: unable to find an interrupt controller node".
steventroughtonsmith
Student Driver
Posts: 20
Joined: Fri Jan 06, 2017 10:02 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by steventroughtonsmith »

alex195812 wrote:
steventroughtonsmith wrote:Just to clarify — the reason my boot scripts sometimes spoof PowerMac1,1 isn't anything to do with the OS itself, but the Forth/OF boot script that runs before BootX to decide whether your machine is compatible with the OS or not. It's not a hard check for anything, it just checks the model number. You can patch the ISO if you prefer, but spoofing is easy. Oldworld g3beige is significantly different from an actual New World Yosemite-class PowerMac1,1.
Is it that different?If you use the same spoofing with mac99 will you boot DP1 or Rhapsody?No.
It shows that BW and mac99 are really significantly different.
If the boot-script wants PowerMac1,1, doesn't it mean that the OS is targetting BW,not G3B?And still it boots.It means that BW and G3B are compatible.
I read that G3B is 1 of 2 Old World machines capable of booting MOSX(offically up to 10.2,with processor upgraded to G4 up to 10.5,just like BW).It makes it very similar to New World machines besides the boot method.
Yes g3beige and PowerMac1,1 are that different. The g3beige is a Gossamer—mach in Rhapsody DR2 onwards supports Gossamer class machines, that's why it works. However that's different from the CHRP boot script check before BootX—this is merely a gatekeeper, and doesn't necessarily have any relation to whether the OS kernel will actually work or is compatible. When you're spoofing PowerMac1,1 (Yosemite) you're not really fooling mach, just the tiny script that OpenBIOS is using to check if it should boot the disc or not. mac99 is a PowerMac3,1, a Sawtooth. Again, different enough that it has its own hardware target.

I have both a Gossamer and Yosemite; the Gossamer is a SCSI-based legacy I/O machine, Yosemite is New World/ATA/USB, etc (it's been a loong time, but I /think/ the lowest end G4 (PCI) was on a modified Yosemite config). No variant of Gossamer booted Mac OS 8.6 from OpenFirmware, nor any variant of Sawtooth/mac99, so it's perhaps unsurprising that it doesn't quite like the device tree as-is.
Budgiebrain994
Student Driver
Posts: 10
Joined: Fri Jan 08, 2016 12:27 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Budgiebrain994 »

As an aside, I decided to try to get this up and running on my Raspberry Pi. Interesting results occurred.

Image
Image
Image

This is using QEMU 2.8 master branch compiled from source, running Mac OS 9.2.2 with 256MB of RAM. As you can see, the colours are all black & white and rather distorted. Switching this to greys in Monitors panel improves a few things but the greys are actually inverted! I'm using 8-bit depth for the monitor, as using 16-bit causes the system to never make it past OpenFirmware, hanging just after the NVram offset warning message.

The system overall is very slow, menus visibly build themselves, the mouse doesn't track correctly and I haven't got sound up and running yet. But it works! There are also a couple of errors in the terminal regarding NVram starting position and I/O running over 1000 cycles too.

Command line used:

Code: Select all

qemu-system-ppc -boot c -m 256 -M mac99 -prom-env auto-boot?=true -prom-env boot-args=-v -g 640x480x8 -cpu G3 -usb -usbdevice mouse -drive file=/mnt/HDD/MacOS9.2.2.img,format=raw,media=disk
The Mac OS was installed on my main PC with QEMU 2.7, and simply moving the hard drive image over once installed worked wonders.

Edit: I switched the bit depth to 32 and we have colour!

Image
darthnvader
Mac Mechanic
Posts: 178
Joined: Sun Feb 07, 2016 4:40 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by darthnvader »

Budgiebrain994 wrote:As an aside, I decided to try to get this up and running on my Raspberry Pi. Interesting results occurred.

Image
Image
Image

This is using QEMU 2.8 master branch compiled from source, running Mac OS 9.2.2 with 256MB of RAM. As you can see, the colours are all black & white and rather distorted. Switching this to greys in Monitors panel improves a few things but the greys are actually inverted! I'm using 8-bit depth for the monitor, as using 16-bit causes the system to never make it past OpenFirmware, hanging just after the NVram offset warning message.

The system overall is very slow, menus visibly build themselves, the mouse doesn't track correctly and I haven't got sound up and running yet. But it works! There are also a couple of errors in the terminal regarding NVram starting position and I/O running over 1000 cycles too.

Command line used:

Code: Select all

qemu-system-ppc -boot c -m 256 -M mac99 -prom-env auto-boot?=true -prom-env boot-args=-v -g 640x480x8 -cpu G3 -usb -usbdevice mouse -drive file=/mnt/HDD/MacOS9.2.2.img,format=raw,media=disk
The Mac OS was installed on my main PC with QEMU 2.7, and simply moving the hard drive image over once installed worked wonders.

Edit: I switched the bit depth to 32 and we have colour!

Image
Benchmarks, or it didn't happen :mrgreen:
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

steventroughtonsmith wrote: I have both a Gossamer and Yosemite; the Gossamer is a SCSI-based legacy I/O machine, Yosemite is New World/ATA/USB, etc (it's been a loong time, but I /think/ the lowest end G4 (PCI) was on a modified Yosemite config). No variant of Gossamer booted Mac OS 8.6 from OpenFirmware, nor any variant of Sawtooth/mac99, so it's perhaps unsurprising that it doesn't quite like the device tree as-is.
Sounds convincing especislly SCSI vs ATA part and you seem quite right about real machines but 1)in both emulated mac99 and g3beige device trees have ata,not scsi buses and those tree parts look the same;2)in my efforts boot process stops not because of those buses but because of not found interrupt-controller node;but as seen from Mac OS ROM,it knows about Heathrow pic(in MOL devtree for PowerMac1,1 its model is heathrow).Maybe I simply assign wrong values for this device or something?Looks like booting shouldn't stop so early...It could at least pass interrupt-controller part.
Last edited by alex195812 on Thu Feb 09, 2017 10:26 am, edited 5 times in total.
Budgiebrain994
Student Driver
Posts: 10
Joined: Fri Jan 08, 2016 12:27 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Budgiebrain994 »

darthnvader wrote: Benchmarks, or it didn't happen :mrgreen:
Forgive me :P How do I do benchmarks? What would you like me to run? I'd love to show off some super speedy stats :lol:

Edit: Looked up in this thread, found MacBench, now finding a way to get it inside the Mac :arrow: While I'm here, are there any optimizations I can make to my command line for better performance/more options? It looks like I'll need to add the network adapter in as a start
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

It may be like -netdev user,id=net0 -device rtl8139,netdev=net0
Realtek driver must be installed in guest system for this to work.See http://www.emaculation.com/forum/viewto ... =34&t=9012
WizKid
Tinkerer
Posts: 72
Joined: Sun Jul 31, 2016 11:58 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by WizKid »

Why does sungem even exist now? the realtek driver problems regarding mac os 9 have been fixed, so what's the point of the sungem patch? OS X PPC support?
User avatar
Cat_7
Expert User
Posts: 6121
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Cat_7 »

Why does sungem even exist now?
The sungem device emulates a built-in network card, hence no need for additional drivers to install as Mac OS and OSX have drivers included. To me that seems a huge benefit ;-)

It would say it is rather the opposite: why use the realtek device when there is the sungem device.
For now, the realtek is not supported in all PPC OSX versions qemu can run.

The only snag is that the sungem code is not yet in the qemu master code and therefore the "unofficial" build/patch is required.

Best,
Cat_7
User avatar
Meow_2004
Granny Smith
Posts: 108
Joined: Thu Jan 05, 2017 6:24 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Meow_2004 »

Hi!

I have a few questions for DP3:

1. What would be the best build?
2. What should I use to format the drive? 10.0? 10.1? 10.2?
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

1)If you mean best qemu build,then DP3 can run in August wip builds and the latest,provided by Cat_7(It's about Windows).Don't know which one is better.
2)I think any of them will do (for they all have Disk Utility).
Budgiebrain994
Student Driver
Posts: 10
Joined: Fri Jan 08, 2016 12:27 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Budgiebrain994 »

Cat_7 wrote: The only snag is that the sungem code is not yet in the qemu master code and therefore the "unofficial" build/patch is required.
Ahh! No wonder I couldn't get it working.

Code: Select all

qemu-system-ppc: -device sungem,netdev=network0: 'sungem' is not a valid device model name
I'll get to building the unofficial patch on the Pi and see how we go. Thanks!

Edit:

Aaand here we go!

Image

Disregard the terminal in this - I'm running QEMU from an SSH terminal on my main PC. As soon as Classilla is downloaded, I'll put on MacBench and deliver some benchmarks.
Budgiebrain994
Student Driver
Posts: 10
Joined: Fri Jan 08, 2016 12:27 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Budgiebrain994 »

Raspberry Pi benchmark scores are in :)

Image
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

Not fast,but working :smile:.Network is OK,I suppose?Gaming is hardly possible I think.
Is it Rasberry Pi 2?Never played with it,only in qemu fork running RiscOS (a couple years ago).
I suppose it can run on Androids,too...A 4-core ARM would do it fine.
Budgiebrain994
Student Driver
Posts: 10
Joined: Fri Jan 08, 2016 12:27 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Budgiebrain994 »

Network is anywhere from 0 to 20Kbps, often failing completely. I had to set up an FTP server to get the files in. This is a Raspberry Pi 3B. Gaming is not an option at the moment :wink:
just with the cores, the Pi has 4 but QEMU only uses one as its guest OS doesn't support more, so the performance graph is effectively capped at 25% or so and you only get one core working for Mac OS 9. There was someone earlier in this thread who said he got it running on his phone though.
kataetheweirdo
Master Emulator
Posts: 312
Joined: Sun Feb 01, 2009 4:55 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by kataetheweirdo »

It wasn't just you, QEMU 2.8 does indeed go much slower than in 2.7. I have no idea why, but it's best to find the offending GIT commit that caused the slowdown.
Programmingkid
Apple Corer
Posts: 243
Joined: Sun Jan 31, 2016 6:01 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Programmingkid »

Budgiebrain994 wrote: Image
1999 - It takes $1,499 for a computer to run Mac OS 9
2017 - $35 Raspberry Pi 3 does the job.

Be proud people, be proud...
darthnvader
Mac Mechanic
Posts: 178
Joined: Sun Feb 07, 2016 4:40 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by darthnvader »

Does anyone know the key command to invoke Macsbugs, once the OS has loaded to the Finder, it use to be Ctrl+Command+I, but that doesn't seem to work for Macsbugs 6.6.3?

EDIT: Ok, I fond a way.
Defining an 'FKEY' Resource to Invoke MacsBug 2
Another way to invoke MacsBug is to define an 'FKEY' resource using ResEdit or MPWS().Once you have defined this resource, you can use a Shift-Command-key combination to invoke MacsBug.
To define an 'FKEY' resource using ResEdit 2.1, follow these steps:
1. Launch ResEdit.
2. Open the 'FKEY' resource in the System File.
3. Choose “Create New Resource” from the Resource menu to create a new 'FKEY' resource.
4. Type the following numbers into the new resource exactly as shown:
A9FF 4E75
A9FF is machine code for the _Debugger trap; 4E75 is machine code for the RTS instruction.
Figure 2-6 shows what the resource looks like after you’ve entered the instruction.
Figure 2-6 Defining an 'FKEY' resource to invoke MacsBug
5. Choose Get Resource Info from the Resource menu and set its ID number to a number greater than 4 and less than or equal to 9. Please remember to use a number that is not already in use. The numbers 1, 2, 3, and 4 are reserved for system functions.
6. Close and save the System file.
7. To invoke MacsBug, press Command-Shift and the ID number you have assigned the resource. For example, if you’ve assigned the resource ID 7, press Command-Shift-7 to invoke MacsBug.
This method of invoking MacsBug will only work when the application is calling GetNextEvent or WaitNextEvent regularly, which it might not do if it’s hung or frozen.
User avatar
adespoton
Forum All-Star
Posts: 4208
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

You can also send the interrupt signal from the keyboard. Somewhere on here, the qemu sequence to trigger the interrupt signal is listed (command-option-power?).
User avatar
Cat_7
Expert User
Posts: 6121
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Cat_7 »

I'm not at all sure what you are talking about.

All builds are still up, I only updated the builds from the official source. Those does not include the empty disk and bat file anymore, because that makes it easier for me to maintain stuff. How to create an empty disk and the bat/command files is explained at length in the updated guides for both Windows and OSX.

Give them a try.

Best,
Cat_7
Programmingkid
Apple Corer
Posts: 243
Joined: Sun Jan 31, 2016 6:01 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Programmingkid »

I have done several tests with the screamer sound card in order to make it play audio better.

I thought a problem with it could be that the buffer might need to be completely emptied by setting all values in it to zero. So I added code to the pmac_screamer_tx_flush() function that would completely zero out the s->buf variable. This did not fix the problem.

I then tried commenting out the call to AUD_write() in pmac_screamer_tx_flush() to see if that would change anything. No change is audio quality was observed.

It then occurred to me that maybe I should inject silence into the audio stream. This is something the ac97.c file does in its write_bup() function. It could end the playback of old audio when playing a new audio file. The problem is knowing when and for how long to do this. This is just another theory. Maybe someone knows a better way to flush the audio stream of old audio?

I'm beginning to think maybe the problem is elsewhere. Maybe the macio controller?
Post Reply