Qemu virtio drivers for Mac OS 9.x

[elliotnunn]

Hello all,

I am working on Mac OS 9 drivers for Qemu's suite of Virtio devices (file sharing, sound, tablet input etc).

macOS host:

virtio-tablet, virtio-9p
13-01-2024
qemu-system-ppc-macOS-13-01-2024.zip
https://surfdrive.surf.nl/files/index.p ... 1/download

Thanks to the hard work by elliotnunn and mcayland, we now have some virtio drivers available.
The download contains a specific qemu build, a specific openbios and a ndrvloader. See the example below for the command line options.
You always need to use the lastest ndrvloader from here: https://github.com/elliotnunn/classicvi ... tag/latest

virtio-tablet-pci makes qemu use an absolute pointing device which can move seamlessly outside the qemu window
virtio-9p-pci allows to either get read/write access to a local folder, or to boot from a folder into which you copied a full Mac OS 9 installation

Code: Select all

./qemu-system-ppc \
-L pc-bios \
-bios openbios-qemu-virtiogpu.elf \
-M mac99 \
-display cocoa \
-m 512 \
-boot c \
-device loader,addr=0x4000000,file=ndrvloader \
-prom-env "boot-command=init-program go" \
-drive file=9.2.img,format=raw,media=disk \
-device virtio-tablet-pci \
-device virtio-9p-pci,fsdev=UNIQUENAME,mount_tag="Macintosh HD" \
-fsdev local,id=UNIQUENAME,security_model=none,path=/PATH/TO/HOST/FOLDER

Booting Mac OS 9.2 from a local folder:
You can boot Mac OS 9 from a local folder on your host.

Copy the content of a disk image containing a Mac OS 9 installation into a folder on your host hard disk.
Add the following to your qemu arguments and adjust the paths as needed.

Code: Select all

-device virtio-9p-pci,fsdev=UNIQUENAME,mount_tag="Macintosh HD"
-fsdev local,id=UNIQUENAME,security_model=none,path=/PATH/TO/HOST/FOLDER
-device loader,addr=0x4400000,file="/PATH/TO/HOST/FOLDER/System Folder/Mac OS ROM"

Windows host:
Note: the tablet driver can be used with regular windows builds.
To use the shared folder option in Windows, you need a specific Qemu build. Download it here: https://surfdrive.surf.nl/files/index.p ... J/download
Example bat file:

Code: Select all

qemu-system-ppc-virtio.exe ^
-M mac99 ^
-m 512 ^
-L pc-bios ^
-bios openbios-qemu-virtio.elf ^
-display sdl ^
-device loader,addr=0x4000000,file=ndrvloader ^
-prom-env "boot-command=init-program go" ^
-boot c ^
-drive file=MacOS9.2.img,format=raw,media=disk ^
-device virtio-tablet-pci ^
-device virtio-9p-pci,fsdev=UNIQUENAME,mount_tag="Macintosh HD" ^
-fsdev local,id=UNIQUENAME,security_model=none,path=path_to_a_folder_on_your_host

I am very grateful to my friends at #mac68k on Libera for their help and support. Help is very welcome: the code is at https://github.com/elliotnunn/classicvi ... tag/latest.


– Elliot/edited by Cat_7

[adespoton]

Thanks, Elliot! Can't wait to try this out!

[robin-fo]

This is just... WOW! It even works with UTM! Tested with UTM 4.1.6 running on Mac OS 12.6. I Just had to install the extension and choose VirtFS in directory share mode. Not even some additional command-line parameters were required!

[robin-fo]

Do you have any plans for an 68k version?

[adespoton]

I've got another request: any chance it could be hosted somewhere with http:// ? I've been having a bit of a headache shoehorning it into one of my existing images (eventually I'll have to convert my qcow2 image back to raw, mount it on the host and copy over -- attempts to use smb, afp, ftp and ssh between guest and host have all been failing since macOS 13 and I haven't had the time to figure out why).

[Cat_7]

I'm sorry, I have no other option.

You say you can no longer get Qemu to forward the ftp port to your host?

Best,
Cat_7

[adespoton]

I'm sorry, I have no other option.

You say you can no longer get Qemu to forward the ftp port to your host?

Best,
Cat_7

Yes; not sure what's going on; it's either a UTM thing or a macOS 13 thing or a combination. I've done the "convert qcow2 to raw, mount, write the driver, unmount, convert to qcow2, launch emulator" dance now, and it's all working, other than being read-only.

I haven't attempted doing a raw qemu-x86_64 run to see if that works; I expect it would, but I'm specifically attempting to test UTM 4.4.1 right now

[Cat_7]

A new version of the 9p driver was posted in the first post. It now has basic write support.

Best,
Cat_7

[adespoton]

Thanks, Elliot and Cat_7!

Anyone mind if I mirror the driver to somewhere like Macintosh Garden so it's available over HTTP to OS 9 browsers?

[Cat_7]

It's open source.

Isn't it only an issue to get the first driver going? After that you can use it to import from your host.
I guess if you post any version on a http-enabled site, the post should stress to immediately update.

Does Classilla not do https?

BTW: I just posted the 30-09-2023 version.

Best,
Cat_7

[adespoton]

It's open source.

Isn't it only an issue to get the first driver going? After that you can use it to import from your host.
I guess if you post any version on a http-enabled site, the post should stress to immediately update.

Does Classilla not do https?

BTW: I just posted the 30-09-2023 version.

Best,
Cat_7

Yeah; my plan was to put the version somewhere http-accessible with a note to use it ONLY to bootstrap the process of downloading the latest version. I don't want to get caught up in the update cycle Still figuring out the best place to do this; MG may end up with it being buried or considered "latest version".

[Cat_7]

I've added a 9p tablet driver to the downloads in the first post. It only works in Mac OS 9.2

Best,
Cat_7

[adespoton]

Here's a question: someone (I believe it was Elliot?) previously came up with a way of injecting a tablet driver into OpenFirmware directly via a QEMU command line parameter, without having to mess with the host OS directly. Would that be possible for the current batch of Virtio drivers? And would it work for all guests loading OpenFirmware (so the drivers would be available for both OS 9 and OS X prior to OS initialization?)

Just thinking that if this is possible, they could be rolled directly into QEMU in this manner with no need to add extensions and automatic support for 10.1-10.5 (and booting from a shared folder) without needing a special boot floppy.

[Cat_7]

10.2 (later versions) up to 10.5 have their own tablet driver (-device usb-tablet).

I might be mistaken, but I guess these 9p drivers use functionality exposed on the host.

Best,
Cat_7

[adespoton]

10.2 (later versions) up to 10.5 have their own tablet driver (-device usb-tablet).

I might be mistaken, but I guess these 9p drivers use functionality exposed on the host.

Best,
Cat_7

The initial implementation of a tablet driver for Mac OS 9 involved pushing a driver via OpenFirmware that enabled OS 9 to use -device usb-tablet. This works for 9.1 and later. I never really thought about how it was pulling the functionality from the host; we may need someone like Elliot or Mark to weigh in on that.

The more interesting bit to me is whether the 9p file sharing driver could be implemented in a similar manner, as QEMU already supports the file system hook on the host side. Because then the emulated hardware would support file sharing by default and the OS would pick it up as a regular filesystem during initialization. This could be useful for display drivers and for clipboard management as well; if all these things are done in OF init and loaded from QEMU, then we don't need to modify the disk images themselves to pick up the features, unless I'm missing something.

[Cat_7]

A new experimental build sporting a virtiogpu driver has been posted in the first post in this thread. For now, this is for macOS host only.

Best,
Cat_7

[mocha]

First time posting, long time lurker.

Is there anyway to get this working on a Linux host and Mac OS 9.2 guest?

This is the exact procedure I use to compile a screamer version of qemu for ppc (procedure thanks to you folks):

Code: Select all

$ git clone -b screamer https://github.com/mcayland/qemu.git qemu-screamer
$ cd qemu-screamer
$ ./configure --target-list="ppc-softmmu" --disable-werror --enable-sdl --enable-gtk --audio-drv-list="pa" --enable-virtfs --enable-virtiofsd
$ make -j9
$ cd build
$ strip qemu-system-ppc

I use some scripts to run the system, and I tried adding the options like you guys mentioned in this post but I don't see any shared directory on the Mac OS 9.2 guest.

For example:

Code: Select all

#!/bin/bash
export QEMU_AUDIO_DRV=pa
./qemu-system-ppc -L pc-bios -cpu "g4" -M mac99,via=pmu -m 512 -g 1280x768x32 -rtc base=localtime -display sdl -boot c -drive file=922.img,format=raw,media=disk -drive file=OS9storage.img,format=raw,media=disk -netdev user,id=mynet0,hostfwd=tcp::2121-:21 -device sungem,netdev=mynet0 -drive format=raw,media=disk,file=bootstrap.img -virtfs local,security_model=none,mount_tag=doesntmatter,path=os9test -serial stdio -prom-env 'nvramrc=dev /pci/pci1af4,1009 1 encode-int " debug" property'

??? Why doesn't any method work on a Linux host?

[Cat_7]

Sure you can run this on Linux. But you can't attempt this on the screamer code (so no audio), as both require a different openbios.

Download the qemu-virtio-gpu.patch from:
https://github.com/elliotnunn/classicvi ... in/patches

Download qemu and patch it:

git clone https://gitlab.com/qemu-project/qemu qemu-master
cd qemu-master
patch -p1 < path-to/qemu-virtio-gpu.patch
./configure --target-list="ppc-softmmu" --enable-slirp --enable-sdl --enable-gtk
make
cd build
strip qemu-system-ppc

Download the build for mac OS host from the first post in the forum and extract the required openbios-qemu-virtio.elf.
Download https://github.com/elliotnunn/classicvi ... latest.zip and extract the required ndrvloader.

Put both files in a convenient place

Run qemu:
#!/bin/bash

./qemu-system-ppc \
-L pc-bios \
-bios path-to/openbios-qemu-virtio.elf \
-M mac99,via=pmu \
-m 512 \
-g 1280x768x32 \
-rtc base=localtime \
-display sdl \
-boot c \
-drive file=922.img,format=raw,media=disk \
-drive file=OS9storage.img,format=raw,media=disk \
-netdev user,id=mynet0,hostfwd=tcp::2121-:21 \
-device sungem,netdev=mynet0 \
-device loader,addr=0x4000000,file=path-to/ndrvloader \
-prom-env "boot-command=init-program go" \
-device virtio-9p-pci,fsdev=UNIQUENAME,mount_tag="Macintosh HD" \
-fsdev local,id=UNIQUENAME,security_model=none,path=path_to_a_folder_on_your_host

[mocha]

Thanks it works great but I had to move the "-bios ./openbios-qemu-virtiogpu.elf" option AFTER the -boot and -drive options, otherwise I was getting the "no valid state has been set by load or init-program" from openBIOS.

There's so much outdated and conflicting info about running QEMU on Linux hosts with Mac OS 9/10 guests. This is an awesome method to move files from the host to the guest and then shutdown and re-run it using the qemu-screamer binary.

I suppose this method works for Mac OS X 10.1 guests as well? I'll have to try it.

[Cat_7]

I had to move the "-bios ./openbios-qemu-virtiogpu.elf" option AFTER the -boot and -drive options

That is strange, doesn't happen to me.

EDIT: Oh, I see, the line did not end with a "\" so the next line(s) were not read.

I suppose this method works for Mac OS X 10.1 guests as well? I'll have to try it.

Nope, only for Mac 9.x

There's so much outdated and conflicting info about running QEMU on Linux hosts with Mac OS 9/10 guests.

Running it in macOS is rather close to running it in Linux, so our guide for running in maOS can be helpful. But admittedly not for everything.

Best,
Cat_7

[mocha]

Heheh, I just noticed that as well. I just self resolved it when I rearranged the command in my script.

I had to move the "-bios ./openbios-qemu-virtiogpu.elf" option AFTER the -boot and -drive options

That is strange, doesn't happen to me.

EDIT: Oh, I see, the line did not end with a "\" so the next line(s) were not read.

[adespoton]

Thanks it works great but I had to move the "-bios ./openbios-qemu-virtiogpu.elf" option AFTER the -boot and -drive options, otherwise I was getting the "no valid state has been set by load or init-program" from openBIOS.

There's so much outdated and conflicting info about running QEMU on Linux hosts with Mac OS 9/10 guests. This is an awesome method to move files from the host to the guest and then shutdown and re-run it using the qemu-screamer binary.

I suppose this method works for Mac OS X 10.1 guests as well? I'll have to try it.

Under Linux Mint, I move files from the host to the guest by mounting the raw disk image, moving the files, unmounting the raw disk image, then running the emulator. Ubuntu/Mint (and likely other Linuxen) handle HFS+ partitions natively.

[Cat_7]

One of the intriguing options of the file share option is that it aims to run Mac OS straight from a folder on the host drive

Together with some upcoming screamer patches, the file sharing, tablet and virtio-gpu work will make for a great step forward for qemu-system-ppc

Best,
Cat_7

[ckweb]

This is fantastic news indeed! I can't wait to install the updated Windows QEMU PPC build once it's ready; thanks to everyone working on this!!

I did have a little side question on resolutions:
I thought QEMU PPC supported multiple resolutions in 9.2.2? I tried -g width x height x depth, -full screen, and -vga std but it booted with the default display resolutions. Since info on this seems to be missing from the wiki, I'm guessing that this isn't an option yet? just checkin'

[adespoton]

This is fantastic news indeed! I can't wait to install the updated Windows QEMU PPC build once it's ready; thanks to everyone working on this!!

I did have a little side question on resolutions:
I thought QEMU PPC supported multiple resolutions in 9.2.2? I tried -g width x height x depth, -full screen, and -vga std but it booted with the default display resolutions. Since info on this seems to be missing from the wiki, I'm guessing that this isn't an option yet? just checkin'

-g sets the starting dimensions of the Open Firmware boot window. The OS then reads the available resolutions from the populated NDRV table in Open Firmware, and draws the screen using the default or the EDID selected value.

-fullscreen just displays the output to the entire screen instead of in a windowed mode.

-vga std just selects the PC BIOS resolution value of Standard VGA -- but since Mac OS never checks that, it has no effect. -device VGA,EDID=on is the flag to populate resolutions from the ndrv file, but this is enabled by default.

So what you need is a build of QEMU that comes with the appropriate qemu-vga.ndrv file, like is provided at this site. If you don't like the default values provided to Mac OS 9 by qemu-vga.ndrv, you can open the file with a hex editor and change them -- the values are in a table, and the w x h values are stored as hexadecimal values, one after the other. I usually just look for 0x0400 0x0300 (1024x768) near 0x0320 0x0258 (800x600). You can replace any of these values with anything up to 0xFFFF 0xFFFF (65535x65535) and the emulator should faithfully make that resolution available in the Monitors control panel.

If you have Mac OS 9 set up in QEMU already and have CodeWarrior 6 or similar installed, you can also take the source files and compile your own qemu-vga.ndrv file with however many resolutions you want in it. In the source, it's just a list of resolutions, and you can add as many as you want.

Personally, I'd love it if someone could hack things such that the -g values are automatically inserted in the NDRV table in OF, providing a nice command-line solution to setting screen resolution for both the window AND the OS running inside it.