I'm running QEMU 4.0.0, qemu-system-ppc emulating Mac OS 9.2.2 under Mojave on an Intel Mac. Startup script:

#!/bin/bash
cd "$(dirname "$0")"

/usr/local/bin/qemu-system-ppc \
-L ../newworld86.rom \
-cpu "g4" \
-M mac99,via=pmu \
-m 512 \
-boot c \
-hda ../qemu-try-5.img \
-g 1280x1024x32 \
-device usb-kbd \
-device usb-mouse \
-device usb-storage,drive=fat16 \
-drive file=fat:rw:fat-type=16:./qemu-shared,id=fat16,format=raw,if=none

The folder qemu-shared is enabled for sharing in Mojave. The above results in a mounted volume in the emulated OS9 environment named QEMU VVFAT (why??). On this volume I see files and folders that exist in Mojave, but executables and some folders don't work: on double-click both say "Could not find the application program that created the document named 'whatever'. To open the document, select an alternate program, with or without translation."

Clearly a FAT file system is not going to behave right here.

Question: what should be in the final -device and -drive lines in the startup script in order to share a folder in a way that is usable in both host and guest OS?

The shared folder feature in qemu is only designed to prevent (Moderator: Typo fixed prevent->provide) a FAT filesystem. To share a folder in another way, you need to set up networking such that you can share via some network connection -- AppleShare, or FTP. should work.

A FAT file system will not preserve Mac file attributes, so you need another way to exchange between guest and host. Furthermore, this shared folder is not without issues of its own: changing the content from within Mac OS can corrupt the content. Changes from within the host are not seen from the guest.

If you do not need real-time exchange, you can use a disk image to exchange. Just make sure not to mount it in the host and guest at the same time.

Some things puzzle me in your configuration file, and some things seem redundant:
-If you use -M mac99,via=pmu Qemu already provides usb-kdb and usb-mouse. Is there a reason to provide additional ones?
-You use -L ../newworld86.rom What does that do?
-Qemu-system-ppc already defaults to a G4 cpu, so there might not be a need to explicitly set it with -cpu "g4"

Best,
Cat_7

>> The shared folder feature in qemu is only designed to provide a FAT filesystem.

> A FAT file system will not preserve Mac file attributes, so you need another
> way to exchange between guest and host.

Thank you both, I appreciate the clear statement of something that has only been implied, if that, in all I have read.

> If you do not need real-time exchange, you can use a disk image to exchange.
> Just make sure not to mount it in the host and guest at the same time.

This would meet my needs. I could not figure out how to make it work though. Using qemu-init to create a gcow2 disk image doesn't give something that works on the host side.

qemu-img create -f qcow2 test.img 500M

Double-clicking the resulting .iso gives "The following images could not be opened... image not recognized." SheepShaver (another possible way to get file transfer done) also can't do anything with the .iso.

Using -f raw gives the same results.

How should I be creating an .iso that can be mounted on both ends, one at a time?

> To share a folder in another way, you need to set up networking such that you
> can share via some network connection -- AppleShare, or FTP. should work.

OK, I'll dive into this... have been avoiding the topic.

> Some things puzzle me in your configuration file, and some things seem redundant:

Thanks. I really have no idea about the config file options, just copying what I find that others have done. Got rid of the -L, -cpu, and mouse & keyboard lines and the guest still boots.

#!/bin/bash
#
cd "$(dirname "$0")"

/usr/local/bin/qemu-system-ppc \
-M mac99,via=pmu \
-m 512 \
-hda ../qemu-try-5.img \
-boot c \
-g 1280x1024x32

You use qemu-img to create a new disk image. Do not make an iso, as that would normally be a read-only format.

./qemu-img create -f raw -o size=2G Exchange.img will create an image file of 2Gb.

Add this image to your command line (as second disk).
-drive file=Exchange.img,format=raw,media=disk

When you then start Qemu, you get a message from Mac OS 9.2 that the disk is not readable. Use Drive Setup to initialise the disk with Mac OS extended format.

You can then copy stuff to that drive. Shut down Qemu when you want to open the disk image in you OSX host. And close it in OSX when you start Qemu.

Best,
Cat_7

Thanks again Cat_7, that was the ticket. I'm able to share files now between host & guest, so mission accomplished.

Never did get networking working though. Using this config:

#!/bin/bash
#
cd "$(dirname "$0")"

/usr/local/bin/qemu-system-ppc \
-M mac99,via=pmu \
-m 512 \
-hda ../qemu-try-5.img \
-boot c \
-g 1280x1024x32 \
-drive file=test.img,format=raw,media=disk \
-netdev user,id=network01,net=192.168.1.0/24 \
-device sungem,netdev=network01

DHCP sets the guest's IP to 192.168.0.15, the gateway to ...2, and the DNS server to ...3. Those latter two don't exist. In the TCP/IP control panel I set the networking manually so that both gateway and DNS are 192.168.1.1. Turned on sharing via the File Sharing control panel. The guest is simply not on the network. In the Network Browser, I can never see the host at afp://192.168.1.167, nor can I see the guest from the host.

This network issue is to be expected when you use -netdev user,id=network01,net=192.168.1.0/24

Qemu creates a DHCP server that is able to connect to you host network, but such a connecting does not allow all network traffic between guest and host.

You should set the TCP/IP settings in the guest to DHCP (or manually enter exactly the same values you now get). Otherwise the (limited) networking will not be available.

To have full networking from the guest, you need to use a tap connection. See our guide here:
https://www.emaculation.com/doku.php/pp ... networking

Due to Mac OS 9.2 not supporting newer versions of various network protocols and Apple dropping Appletalk from OSX a long time ago you cannot simply see the guest from the host and v.v. However, I do not know exactly which protocols are still compatible.

When using tap networking, two qemu-based 9.2 guests would be able to see each other on an Appletalk network.

Best,
Cat_7

> When using tap networking, two qemu-based 9.2 guests would be able to see each other
> on an Appletalk network.

To be clear, if I got tun/tap working would I be able to network between OS 9.2.2 guest and a Mojave 10.14 host? I found this discussion from 2-1/2 years ago when you helped a user get his network working again:

viewtopic.php?f=20&t=9026

He was running Sierra 10.12 (a beta I believe) and eventually got things back up. Will tun/tap still work under Mojave? I note that it hasn't been updated in almost 4 years, since El Capitan was current.

I downloaded tuntap_20150118.zip from Sourceforge and installed (dancing around Mojave's enhanced security to install from an unknown developer), then rebooted Mojave. While I see the two new kexts in /Library/Extensions, I can't tell if they are working.

Following the instructions at https://www.emaculation.com/doku.php/pp ... networking , I started Qemu under sudo and then in another Terminal window:

% [local] 2 > sudo ifconfig bridge0 create
ifconfig: SIOCIFCREATE2: File exists
% [local] 3 > sudo ifconfig bridge0 addm en0
% [local] 4 > sudo ifconfig bridge0 addm tap0
ifconfig: BRDGADD tap0: No such file or directory
% [local] 5 >

Shouldn't tap0 exist once Qemu is up? Its config:

#!/bin/bash
#
cd "$(dirname "$0")"

/usr/local/bin/qemu-system-ppc \
-M mac99,via=pmu \
-m 512 \
-hda ../qemu-try-5.img \
-boot c \
-g 1280x1024x32 \
-drive file=test2.img,format=raw,media=disk \
-netdev tap,id=network0,script=no,downscript=no \
-device sungem,netdev=network0

I just tested tuntaposx in a virtual machine running Mojave. It still works.

As I wrote earlier, there will be no Appletalk between 9.2.2 and Mojave. So it is not like 9.2.2 will show up as a file server in Mojave. Also not when you set file sharing over tcp/ip in the file sharing control panel in 9.2.2. Some other network protocols may work, but I'm not at all sure which still work between the archaic 9.2.2 and modern OSX.

You can have Appletalk/tcp-ip filesharing between two 9.2.2 (or 9.2.2 up to 10.5 PPC) installations running in Qemu. Anything still supporting Appletalk should see each other with tap networking.

To get tap networking going the easy way:
In OSX host: Create a bridge called bridge0 using the network preferences in OSX (at manage virtual interfaces) (not by using the script on the page I linked to). Add your current Ethernet connection to the bridge. If that is a wireless connection, I don't know if it will work.

I don't know how you installed Qemu, but the builds for OSX we provide contain a folder "tap-scripts". These scripts are used in the command line below. Perhaps you can download Qemu for OSX from this site and use only the tap scripts included.

Change your command line for starting Qemu. To activate the tap interface, Qemu has to be run as root. This is far from optimal, but I know of no other solution.

sudo /usr/local/bin/qemu-system-ppc \
-netdev tap,id=network0,script=./tap-scripts/tap-up.txt,downscript=./tap-scripts/tap-down.txt

The tap scripts will automatically add tap0 to the bridge0 you created in Mojave. And remove it from the bridge0 when you shut down Qemu.

If you then run Qemu, you need to enter your root password. In 9.2.2 you should see that you now get an IP address from your router.

Best,
Cat_7

> In OSX host: Create a bridge called bridge0 using the network preferences in
> OSX (at manage virtual interfaces)

bridge0 already exists and is named Thunderbolt Bridge. I think this is for networking via a Thunderbolt port, which I don't use. Should I delete this bridge and create bridge0 anew? Or can I use the existing bridge0 and add tap0 to that?

> I don't know how you installed Qemu

Said "brew install qemu" and it busily added many megabytes of dependencies for a long time. I just now downloaded those two scripts from this site so they're ready to go once the above is clarified.

> If that is a wireless connection, I don't know if it will work.

This machine does connect by Wi-Fi so we will see how that goes.

Does the thunderbolt bridge already contain your en0 or en1 ethernet connection? If it does you might give it a try.

If not working, leave the current configuration as it is. Create a second bridge called bridge1, add your ethernet connection to it.
Then edit the scripts to point to bridge1 instead of bridge0 and give it a try.
So change BRIDGEDEV="bridge0" into BRIDGEDEV="bridge1" in both scripts.

Best,
Cat_7

Created bridge1 (name Qemu Bridge) in Network Preferences / Manage Virtual Interfaces. But ifconfig -a does not show it.

So I tried using bridge0 with the original scripts. The guest started up fine. ifconfig -a shows that en0, en1, en2, and tap0 are members of bridge0. All good so far.

But in OS9 when I set the TCP/IP control panel to use DHCP, it gets a self-assigned address (169.254.206.85), which means that DHCP failed.

When I set the address by hand, everything fails in the usual way: Network Browser sees nothing on AppleTalk or Local Network.

And BTW, while the guest OS is sitting there doing not much, it's using between 160% and 200% CPU (this machine has 4 cores); it pretty much maxes out one core and uses fractions of the others. Trying to network?

Shutting down the guest removes tap0 as a member of bridge0.

I think I will just give up on the networking. It sounds like even if I got it working, the limited functionality wouldn't be all that useful. The serial-mounted .img technique gets me where I need to be.

This has been educational. Thanks for your generous and very responsive help.

That is the only thing a teacher can hope for

Good luck,
Cat_7