GSOC bringing MacOS 9 to Qemu

It's some progress!

It’s some progress!

I know it may not look like much right now, but Cormac O’Brien is working on bringing MacOS 9 support to Qemu!  This is really great news as Sheepshaver has painted itself in a corner with it’s CPU code that requires memory access to 0x00000000 which more and more operating systems deny.

So you can download the snap and follow the instructions here. And you too can watch it fail.

Screen Shot 2015-07-20 at 9.57.16 AM

Starting to boot

During the boot you’ll see a message from MacOS on the CLI that it is unable to find a NVRAM partition.  During this time you will either see a bunch of CUDA and IRQ messages, and there is a good chance from here it’ll progress to loading the New World ROM.  If it gets stuck you’ll see tonnes of the following messages:

CUDA: read: reg=0xd val=00
CUDA: read: reg=0x0 val=30
CUDA: read: reg=0xd val=00
CUDA: read: reg=0x0 val=30

From here the screen should turn grey, and again it may or may not go to a happy mac, or again get stuck on the CUDA read 30/00 thing above.

New World ROM loaded

New World ROM loaded

Once it goes New World happy mac, it’ll load MacOS then bomb over one of the extensions.

I tried some OpenBSD for the heck of it, the good news is the kernel loads and starts the boot, but it has some issues with either memory or mapping the PCI bus.

Screen Shot 2015-07-19 at 6.03.43 PM

OpenBSD 5.7

Screen Shot 2015-07-19 at 6.08.31 PM

OpenBSD 3.3

Screen Shot 2015-07-19 at 6.16.02 PM

OpenBSD 4.0

And for the heck of it, Debian 5.0.0

Debian 5.0.0 installer

Debian 5.0.0 installer

I didn’t bother installing but nice to see the installer CD runs fine.

40 thoughts on “GSOC bringing MacOS 9 to Qemu

    • Qemu does support the MMU, I know OS X 10.2 – 10.4 can boot on Qemu. I haven’t tried linux but qemu tends to target qemu so probably.

    • Yes it is! It’ll really be cool! Although I can hear people complaining about sound and other trivial things……

      • Nice to see someone getting MacOS 9.2.2 working. Sound and such was run by off the shelf chips in later Macs. One could just peek at the Mac-On-Linux source and emulate a “dummy” sound device and use a Mac OS-side driver. Seems to work for them. I think MOL does that for Ethernet access as well.

        • I think for ethernet Qemu emulates enough adapters there ought to be something that MacOS has a driver for it. rtl8039, rtl8139, ne2000, amd pcnet, e1000…

      • Yeah, the Realtek 10/100 PCI chips have MacOS 9 drivers so that is an option. Regarding the crash on boot, you may want to try pressing and holding Shift on boot when you see the Happy Mac. That disables all the extensions, some of which can be troublesome to emulators.

    • Which would make sense…. How did you disable extensions? I tried a USB keyboard and that didn’t work. Custom ISO?

      • Hold shift during the happy Mac. I didn’t need to grab the cursor for it either. (Which really mangles the display in a tiling WM because it’ll try to autoresize to something ridiculous.)

        • I dont think it’s actually disabling the extensions for you, as it would say ‘starting with extensions disabled’, which I don’t think you can actually disable from a 9 boot CD, or at least sheep won’t let me. Also my screen cap is from 9.0.4, when I try 9.2 I get as much status bar as you. You can tell the keyboard & mouse don’t work as you can’t click restart.

    • Well I wouldn’t sweat it too much, it doesn’t actually work on OS X or Linux, so you’re basically getting as far as we do. Hopefully enough progress is made to get it going before the end of the GSOC.

  1. Looks like Mac OS 9.x has a sort of hidden coolbits that can enable a set of debugging facilities bundled in the Mac OS ROM file, pretty useful to check what is really happening at boot-time. These coolbits are enable via OpenFirmware commands at boot time prompt.

    https://www.thinkclassic.org/viewtopic.php?pid=4077#p4077

    The most interesting is the ones that enable the Nanokernel log, and the Nanokernel debugger.

    • I tried it on the CLI, and in openhackware by setting the -prom-env ‘auto-boot?=false’ and typing it in manually…

      2000000 encode-int ” AAPL,debug” property
      boot cd:,\\:tbxi

      I didn’t see any debug output.

    • Well, the debug support is supposed to be in the Mac OS ROM image, not in the OpenFirmware. Can you try with the first command list first?

      dev /
      0 0 encode-string ” AAPL,debug” property
      boot hd:,\\:tbxi

      This ones is supposed to use OF standard facilities to print until quiesce() function is executed (OF console unloading). This will allow us to see if that basic thing works at least.

    • Would be also a good idea to tell about this link to the developer of this GSoC project. Maybe this could ease his work a little :-).

  2. I wonder if it will be able to boot into Mac OS X Public Beta or one of the DPs one day… I mean, the MMU is supported so….
    Anyone tried to run these versions?

    • OS X starts to load then crashes out. I haven’t tried DP, or PB.

      OS X Server 1.0 won’t boot since it needs MacOS 8.6 to install, while OS X Server 1.2 uses MacOS 9 so … maybe?

      Until it boots into 9, it won’t do very much. And sadly it can’t read disks setup in SheepShaver.

      • Well, I guess we’ll have to wait for someone to get OS 9 booting & installing just to see how earlier versions of OS X behave on QEMU.

  3. “Are you on mainstream QEMU?”

    Yeah, it is just a vanilla 64-bit Windowz compiled version.

    When I got to the console I forgot my user name, but then got in as root user thankfully…I did create the HD image 3 years ago. XFree86 wasn’t configured, so I did that, ran it but the quartz display wouldn’t initialize 🙁

    I have a bunch of pre-done images I made on PearPC, and also other stuff, but it will take some time to test everything.

  4. Tried Classic on Jaguar last night, an OS9 Application seems to fully load, but the Classic display is just a white box. After that I tried setting the 9.2.2 System folder as the boot, and open-firmware has a good inspection for a few seconds before dumping out to the ‘…no valid state set’. I might be able to get further with some bad magic at open-firmware, but I have a lot to do at the office today.

    One last thing, neozeed could you recommend a good PPC program to write a dmg hd image back to a physical drive? In any case I will look into it myself later.

    • The early Amiga NetBSD installation tools could write directly to the disk, I suspect the same holds true to the Mac? I’ve only installed Net/Open on an OpenFirmware Mac so I could boot from CD.

      Then again anything that old would be 68k, and probably wouldn’t support disks the size you’d hope for on a PowerPC.

  5. Well, I have done more testing and I can officially say Qemu PPC has better compatibility than PearPC, but the kicker is you won’t be spending much time swimming in Aqua 🙂 I got Puma (10.1) to boot in single-user mode which is progress since it would always panic fairly early in older builds. I may have had a breakthrough with DP4 but I don’t want to speak too soon. I haven’t even touched GNUStep or MKLinux, but sometimes my heart becomes faint 🙂

    To be honest I thought there would be at least twice as many posts on this thread, but I suppose interest in PPC emulation is not what it used to be…

  6. Truly unexciting pics

    OS X 10.0.4.4S10 console mode

    [IMG]http://i60.tinypic.com/6jdaqg.png[/IMG]

    OS X 10.1

    [IMG]http://i62.tinypic.com/o0w96d.png[/IMG]

    Similar to PearPC, the memory configuration is important. With Puma the virtual memory wont initialize if the guest memory isn’t set to 128, but even then it will stall there with the build I’m using.

  7. I just got something interesting while i was comparing the log screenshots that you got from OS9 Nanokernel debugger running in QEMU, vs the log that some dude got from running the same debugger log in a real Mac that boots full from desktop.

    http://i.imgur.com/P3fDtPX.png <<< Your log, before the OS just hangs booting.
    http://s9.postimg.org/6i7omewnj/photo_3a.jpg <<>> QEMU hangs here.
    Legacy VMInit 0003ff00 005720000 <<< but before this one.

    Legacy VMInit task is responsible to initialize the BlueBox environment, the emulator were all the 68k code built in these older OS versions runs. MacOS9 still has a lot of 68k code, not only running at high level, but also running at low level, in drivers, extensions and toolbox firmware device managers. That explains why the OS stops very early in the boot process. Is also said that the Bluebox makes use of PPC/MMU rare instructions and chip facilities to speed up the emulation.

    Probably QEMU CPU/MMU emulation is still not good enough to run the BlueBox environment. MacBugs uses almost the same facilities that BlueBox. So, if they manage to run MacBugs in QEMU, for sure it will also run Bluebox, allowing the OS to boot full to desktop.

    • not too surprising! Tearing a little into SheepShaver, and it’ll reveal that it is basically the same as Basilisk, it just hooks the 68000 code. Although the newer the version of MacOS, the fewer things it hooks in the 68000 code, until 9.2 where it’s all gone. Not to mention how 8.0/8.1 are far more stable than 8.5/8.6/9.0 … No doubt they pushed that PPC to the limit, and since they were privy to those IBM design meetings they knew all kinds of not so generic ways to do that.

      It’s all very cool thought.

  8. FWIW the latest patches have been merged into QEMU git master which means that QEMU 2.7 vanilla will be able to boot MacOS 9 😀

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.