GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
Moderators: Cat_7, Ronald P. Regensburg
-
- Mac Mechanic
- Posts: 178
- Joined: Sun Feb 07, 2016 4:40 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.
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.
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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
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.
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'
"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.
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
Is it that different?If you use the same spoofing with mac99 will you boot DP1 or Rhapsody?No.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.
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.
-
- Student Driver
- Posts: 11
- Joined: Sun Jul 31, 2016 2:55 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
From this commit to Linux Kernel PROM parser: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.
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.
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).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 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).
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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 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".
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'
"MacOS: Boot Failure! (0xF3C481F6)
MacOS: unable to find an interrupt controller node".
-
- Student Driver
- Posts: 20
- Joined: Fri Jan 06, 2017 10:02 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.alex195812 wrote:Is it that different?If you use the same spoofing with mac99 will you boot DP1 or Rhapsody?No.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.
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.
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.
-
- Student Driver
- Posts: 10
- Joined: Fri Jan 08, 2016 12:27 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
As an aside, I decided to try to get this up and running on my Raspberry Pi. Interesting results occurred.
![Image](https://i.imgur.com/Tpswviv.png)
![Image](https://i.imgur.com/PFVy96L.png)
![Image](https://i.imgur.com/xnaph45.png)
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:
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](https://i.imgur.com/aiPfgPS.png)
![Image](https://i.imgur.com/Tpswviv.png)
![Image](https://i.imgur.com/PFVy96L.png)
![Image](https://i.imgur.com/xnaph45.png)
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
Edit: I switched the bit depth to 32 and we have colour!
![Image](https://i.imgur.com/aiPfgPS.png)
-
- Mac Mechanic
- Posts: 178
- Joined: Sun Feb 07, 2016 4:40 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
Benchmarks, or it didn't happenBudgiebrain994 wrote:As an aside, I decided to try to get this up and running on my Raspberry Pi. Interesting results occurred.
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:
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.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
Edit: I switched the bit depth to 32 and we have colour!
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.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.
Last edited by alex195812 on Thu Feb 09, 2017 10:26 am, edited 5 times in total.
-
- Student Driver
- Posts: 10
- Joined: Fri Jan 08, 2016 12:27 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
Forgive medarthnvader wrote: Benchmarks, or it didn't happen
![Razz :P](./images/smilies/icon_razz.gif)
![Laughing :lol:](./images/smilies/icon_lol.gif)
Edit: Looked up in this thread, found MacBench, now finding a way to get it inside the Mac
![Arrow :arrow:](./images/smilies/icon_arrow.gif)
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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
Realtek driver must be installed in guest system for this to work.See http://www.emaculation.com/forum/viewto ... =34&t=9012
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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?
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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 benefitWhy does sungem even exist now?
![Wink ;-)](./images/smilies/icon_wink.gif)
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
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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?
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?
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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).
2)I think any of them will do (for they all have Disk Utility).
-
- Student Driver
- Posts: 10
- Joined: Fri Jan 08, 2016 12:27 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
Ahh! No wonder I couldn't get it working.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.
Code: Select all
qemu-system-ppc: -device sungem,netdev=network0: 'sungem' is not a valid device model name
Edit:
Aaand here we go!
![Image](https://i.imgur.com/7PkzG5a.png)
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.
-
- Student Driver
- Posts: 10
- Joined: Fri Jan 08, 2016 12:27 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
Raspberry Pi benchmark scores are in ![Smile :)](./images/smilies/icon_smile.gif)
![Image](https://i.imgur.com/uMtnaQE.png)
![Smile :)](./images/smilies/icon_smile.gif)
![Image](https://i.imgur.com/uMtnaQE.png)
-
- Mac Mechanic
- Posts: 169
- Joined: Mon Aug 29, 2016 3:44 am
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
Not fast,but working
.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.
![Smile :smile:](./images/smilies/icon_smile.gif)
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.
-
- Student Driver
- Posts: 10
- Joined: Fri Jan 08, 2016 12:27 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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
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.
![Wink :wink:](./images/smilies/icon_wink.gif)
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.
-
- Master Emulator
- Posts: 313
- Joined: Sun Feb 01, 2009 4:55 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.
-
- Apple Corer
- Posts: 243
- Joined: Sun Jan 31, 2016 6:01 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
1999 - It takes $1,499 for a computer to run Mac OS 9Budgiebrain994 wrote:
2017 - $35 Raspberry Pi 3 does the job.
Be proud people, be proud...
-
- Mac Mechanic
- Posts: 178
- Joined: Sun Feb 07, 2016 4:40 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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.
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.
- adespoton
- Forum All-Star
- Posts: 4273
- Joined: Fri Nov 27, 2009 5:11 am
- Location: Emaculation.com
- Contact:
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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?).
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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
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
-
- Apple Corer
- Posts: 243
- Joined: Sun Jan 31, 2016 6:01 pm
Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system
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?
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?