QEMU 9.2.2 on OSX

[pcamen]

Just in case this is helpful to anyone, I was able to quickly get a 9.2.2 VM under OSX (Sierra, but probably doesn't matter) running under QEMU as follows.

1. Install QEMU via homebrew

brew install qemu

2. Download this build from Macintosh Repository for Windows:

https://www.macintoshrepository.org/9641-qemu-for-windows-ppc-emulator-runs-mac-os-9-1-9-2-osx-10-0-to-10-5

Specifically, this one:

https://www.macintoshrepository.org/download.php?id=23709

You'll need to be registered with MR to download a file of that size (about 500 MB).

This unpacked in my downloads folder to:

Qemu (20181030) - PPC - Mac OS 9.2.2

3. Create a folder to hold the disk image and copy it there.

4. I grabbed the launch command from the file "Qemu - Mac OS 9.2.2.bat" and modified it for the Mac.  I had to remove the .exe from the executable name, and remove the -sdl command.  Run this in the folder where the .dsk file lives.

qemu-system-ppc -L pc-bios -boot c -m 512 -M mac99 -prom-env "auto-boot?=true" -prom-env "boot-args=-v" -prom-env "vga-ndrv?=true" -netdev user,id=network01 -device sungem,netdev=network01 -device usb-mouse -drive "file=Mac OS 9.2.2 for QEMU (2GB).dsk,format=raw,media=disk"

Voila, a base system running 9.2.2 with Classzilla and functional networking. 

I don't know what other people think of QEMU but it seems slower than other emulators (like Basilisk, SheepShaver or MiniVMac).  However, one thing I really like is that it doesn't have the config stickyness that Basilisk and SheepShaver seem to have, meaning, if you change the settings on one instance of those, it affects your ability to run another one on the same host system.  With QEMU, the config is all on the command line, so one instance is nicely separated from another and you won't screw anything else up just by running it. 

I wonder if I can take my SheepShaver disk image and run it under QEMU.  Hmm. 

 

[nglevin]

I'm pretty sure that all of those QEMU builds are copied from the E-Maculation OS X guide and the thread where Cat_7 regularly shares stable and experimental builds. Which will probably get you a better QEMU for Mac OS X.

Not a fan of resources that copy without credit. It will save you from having to register with an abandonware site, which is another plus.

 

[Gorgonops]

I don't know what other people think of QEMU but it seems slower than other emulators (like Basilisk, SheepShaver or MiniVMac).

It's definitely sluggish compared to SheepShaver, but it does seem immensely more stable, at least in my so-far limited experience. SheepShaver has this bad and well-earned rep for behaving a bit like one of Wile E. Coyote's rocket skateboards or whatever; it's great until it runs you off a cliff or into a brick wall.

Did the possibly sketchily-sourced build you acquired have working sound out of the box? I've been idly digging around to try to find instructions for building the experimental versions that have working sound from the official sources myself, as I'm generally rather cool on installing binaries from untrusted sources.

 

[nglevin]

I've been idly digging around to try to find instructions for building the experimental versions that have working sound from the official sources myself, as I'm generally rather cool on installing binaries from untrusted sources.

Speaking of, Cat_7 shared instructions via https://www.emaculation.com/forum/viewtopic.php?f=34&t=9820&sid=82d8b47320436047d61fb6d727d78789#p60834

No guarantees that this works with QEMU 4 or even various earlier versions. I'm largely waiting on POWER9 hardware to arrive before I try these things.

 

[pcamen]

Topic is a bit old but ...

I got an install of OS9.2.2 on the qemu-screamer branch going today.  I don't mind the speed overall ... feels a bit more like a real Mac of the day versus SheepShaver that starts up so damn fast it doesn't feel real.  

The thing that bothers me though is the mouse.  When moving fast, the mouse is fine.  But when moving the mouse slowly, it feels chunky and imprecise.  Anyone else experienced this?  Is there a startup setting or something that might help? 

 

[pcamen]

Ok, adding -device usb-mouse seems to have helped.  Or perhaps it is my imagination.  But putting it into full screen mode with zoom to fit makes the problem go away for sure. 

 

[Cory5412]

There's an alternate device you can use for tablet, which for me made the problem go away entirely for me. My guess is that if it thinks you have a tablet, it's fine with the mouse entering and exiting the screen anywhere. If it thinks you have a mouse, it'll fall out of alignment if you exit/enter the screen in different spots. I'll paste my run-line in when I get home. 

On my i5-2400 is benches about where you'd expect a 300Mhz PowerMac G3 to do, except for a couple things that are much faster (storage, namely) so it's pretty good. The build I have is several months old (from April or so of 2019?) but it's been stable so I'm a little hesitant to touch it.

 

[pcamen]

I just tried -usbdevice tablet and -device usb-tablet and neither worked, sadly.  The most cursor was just frozen, although it did respond at first while booting and then part way through the boot process, froze. 

 

[CC_333]

On my i5-2400 is benches about where you'd expect a 300Mhz PowerMac G3 to do, except for a couple things that are much faster (storage, namely) so it's pretty good.

Agreed. Classic Mac OS doesn't really make efficient use of the extra speed anyway, as you've so often pointed out.

I wonder how the performance would be on, say, an i5-6600k? If the i5-2400 is equivalent to a 300 MHz G3, then, if we assume that QEMU's performance increases in a roughly linear fashion, it should feel approximately like a 600-700 MHz G3 (or perhaps an early G4, say around 400 or 500 MHz) on the i5-6600k, since that CPU is easily at least 50% faster than the i5-2400, you think?

Since I happen to have a PC with that exact CPU, I might as well try it and see for myself!

c

 

[Cory5412]

Hmm. This is of course on Windows but here's the command I'm using, as of April 2019:

qemu-system-ppc.exe -sdl -L pc-bios -boot c -M mac99 -m 512 -hda macos.img -netdev user,id=net0 -device sungem,netdev=net0 -device usb-tablet -device usb-kbd

I haven't tried any newer builds of the software since a bit before then so I don't know if any of this has gotten better or worse. If you have a newer build and the mouse doesn't move at all (does it look like maybe the emulator or the emulation crashed?) then it might be a different problem.

Using -device usb-tablet got me mousing working correctly. The problem it fixed for me was that the mouse cursor on the emulated Mac wouldn't stay matched up with where my actual mouse cursor was, and it was worse if I remotely accessed my PC (which I frequently do.)

I've been meaning to have another go at it because I want to use it to make some ASIP6 best practices/how-to information documentation and perhaps do some of the testing with backup software, and because having an emulated OS9 machine around is just kind of handy, regardless.

In terms of performance: yeah, newer microarchs should do better and emulation is mostly a single-threaded task, so this is a scenario where fewer faster cores with better IPC and higher clock speed will win.

Of course, as mentioned, this is an area where "win" is sort of... highly dependent on what it is you need to do. I'd be curious on what the highest single-thread performing i5/i7/i9 chips can do these days and whether or not that currently exceeds, say, what one of the nicer/faster single-cpu G4 powermacs can do. (Let alone a 1.5GHz mini booting OS9, which blows away all the powermacs in most numbers benchmarks.)

For most tourism tasks, the performance of whatever you happen to have is probably fine. (I'm tempted to put some extra ram in the old N270 netbook and see how it does there.)

 

[Cory5412]

(Update: I tried this again on RDP and I'm seeing the same mouse behavior mentioned above - the machine seems to boot but the mouse doesn't move, so now I'm doubly confused because this was working, but TBH I don't remember if I had it working in RDP or not.)