GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

[romper]

I have two laptops running OS9 vms now and both can reach the internet thanks to tap networking (great work and support on this forum)

I now need the vms to talk to each other. Internally they have ip addresses: '10.0.2.15'. It seems to me that I need to make these vms visible on my network and thus able to ping each other so will have addresses like 192.168.1.99 & 192.168.1.88

is this something that I need to adjust in the qemu startup script? thank you

[Cat_7]

What is your current script?

If you let your OS 9's get an ip address from your dhcp server (assuming you have dhcp available from your router) and bridge the tap and the default ethernet device, each OS9 should be able to see the other, and have internet working.

I see you have at least one OS9 with the default ip adres from the qemu-embedded slirp server (10.0.2.15). That will not work for your purposes.

Best,
Cat_7

[Programmingkid]

Hi all,

A quick update on where we are with upstream QEMU git master right now:

- David's ppc-for-2.8 branch with Ben's first round of fixes is now merged
- Fix for "Can't find root device" with OS X DPs
- Updated OpenBIOS binaries have been merged with the following:
* CPU context overhaul
* OS X DP fixes: kbd alias, 4+ implementation
* HFS+ startup folder fix
* RTL8139 support (with bus mastering enabled)

Ben's remaining wip patches still need to be tidied up and submitted upstream, however he has been tied up with other things over the past couple of weeks.

Glad to see progress.

Is Ben's patch that allows loading of his VGA driver going to be committed soon?

[adespoton]

This writeup might help:
https://people.gnome.org/~markmc/qemu-networking.html

[romper]

What is your current script?

If you let your OS 9's get an ip address from your dhcp server (assuming you have dhcp available from your router) and bridge the tap and the default ethernet device, each OS9 should be able to see the other, and have internet working.

I see you have at least one OS9 with the default ip adres from the qemu-embedded slirp server (10.0.2.15). That will not work for your purposes.

Best,
Cat_7

qemu-system-ppc-wip.exe -bios openbios-qemu-wip.elf -L pc-bios -boot c -m 512 -M mac99p -prom-env "auto-boot?=true" -prom-env "boot-args=-v" -sdl -cpu G3 -g 800x600x32 -drive file=macdisk.raw,format=raw,media=disk -net nic,model=sungem -net user -redir tcp:5003::5003

(reason I have opened 5003 is to expose filemakerpro's tcp port. I can telnet to that port from a different host using 'telnet $HOSTIP 5003' so it should be possible to get this working)

[adespoton]

In the document I linked, it shows how you can either go the tun/tap route, or just bridge the vlans from the two guests using -net nic -net socket,listen=:8010 on one, and -net nic,vlan=2 -net socket,vlan=2,connect=127.0.0.1:8010 on the other (or -net nic -net socket,mcast=230.0.0.1:1234 on both). Then all frames are shared between the two vlans, and you don't have to redirect port by port. But since qemu contains its own network stack, you may still run into issues with esoteric frames (Localtalk over Ethernet comes to mind), and this is handled by the Tun/Tap method.

[romper]

adespoton, thank you for the doc you linked and your helpful post. I would like to add that filemaker pro 5.5 had tcp disabled by default! Once enabled all was working.

It iz worth pointing out that my vms are on different host laptops and therefore the tcp redir option in qemu was a useful option.

thanks again to all on this forum for excelleng support and development work

[Programmingkid]

Hello everyone, as you I am trying to make the new VGA driver be able to use resolutions the user specifies at the command-line. The currently implementation has the user data placed in the options node of OpenBIOS. This node is fully accessible from Mac OS 9 and works well. The problem is with Mac OS X. It refuses to read anything from this node. So it looks like a workaround is in order. Placing the user specified resolutions in another node is one option I am thinking about.

My idea is this, we add a new command-line option called "-video-resolutions" that the user can use to add his or her resolutions like this -video-resolutions 640x480,1280x800,... Then QEMU sends these resolutions to a property called "resolutions" in the VGA device node. The VGA driver can then read this property and use the resolutions.

Does this sound good?

[sidoh]

It sounds pretty good to me. Anyway, is there a workaround to specify a keybinding for the Command button in QEMU for Windows?

[that-ben]

It sounds pretty good to me. Anyway, is there a workaround to specify a keybinding for the Command button in QEMU for Windows?

If posts had a thumbs up button, it'd be pressed. I was wondering the same thing 3 weeks ago

[adespoton]

Are you guys using an SDL build of qemu on Windows? I have to admit I haven't been keeping up with that side of things. But SDL allows you to supply a key mapping file, similar to the one available for Basilisk II and SheepShaver.

From within qemu itself, you can send keypresses via the monitor. See here for more info:
https://en.wikibooks.org/wiki/QEMU/Monitor#sendkey_keys

But of course, that could get extremely painful if you have to do it regularly. Useful for, say, moving the control strip around though.

Using the command line switch -k might work, but based on the feedback on http://michael.orlitzky.com/articles/fi ... eymaps.php you might find that it doesn't quite work the way you think it should.

[edit] If you want to create your own custom keymap, https://github.com/qemu/qemu/tree/331ac ... os/keymaps is the place to do it. Because this goes in the pc-bios folder, you should be able to create a new keymap and stick it in the pc-bios folder and have it picked up without having to recompile qemu as a whole.

[sidoh]

In the latest Windows/SDL build of QEMU, there doesn't seem to be any parameter to send the command key in the monitor when using sendkey.

I also messed around with the keymaps, but no dice there either.

I'll probably use a virtual keyboard program for OS 9/OS X (if it exists) as a workaround for the time being.

[adespoton]

Virtual Keyboards have been built-in since System 7. Key Caps in Classic Mac OS, Keyboard Viewer in OS X.

[CharlesS]

Virtual Keyboards have been built-in since System 7. Key Caps in Classic Mac OS, Keyboard Viewer in OS X.

Key Caps was built-in way before System 7; I think it goes all the way to the original System 1.0, IIRC.

[pjc1990]

hi, when I try to run netscape navigator 4.7 which comes with 9.2.2 it crashes upon creating a profile requiring to close the emulator, any reason why?

[sidoh]

For those who are curious: Mac OS X 10.0-10.1 (and maybe 10.2 and later, haven't tested those yet) work perfectly with qcow2 images. For example, here is the command I use to boot Mac OS X 10.0.3 (Installed using a 2Z CD) from a qcow2 image:

Code: Select all

qemu-system-ppc-wip -bios openbios-qemu-wip.elf -L pc-bios -boot c -m 1024 -M mac99p -prom-env "auto-boot?=true" -g 1024x768x32 -cpu G4 -drive file=macosx1003.img,if=ide,media=disk,format=qcow2,index=0,copy-on-read=off,werror=ignore,rerror=report,cache=writethrough -usb -device usb-mouse -sdl

I don't recommend using OS 9 with them, though. The last time I checked, I had several problems with installing 9.2.1 onto a qcow2 image.

[kataetheweirdo]

hi, when I try to run netscape navigator 4.7 which comes with 9.2.2 it crashes upon creating a profile requiring to close the emulator, any reason why?

Hard disk writing errors. I experienced this myself trying to use Stuff-It Expander, where that would crash the emulator any time I tried to unstuff files.

To prevent these with the Windows builds, set the compatibility mode to "Windows 7" if you're using Windows 8.x or 10. That almost completely eliminated any hard disk writing errors here.

[adespoton]

For those who are curious: Mac OS X 10.0-10.1 (and maybe 10.2 and later, haven't tested those yet) work perfectly with qcow2 images. For example, here is the command I use to boot Mac OS X 10.0.3 (Installed using a 2Z CD) from a qcow2 image:

Code: Select all

qemu-system-ppc-wip -bios openbios-qemu-wip.elf -L pc-bios -boot c -m 1024 -M mac99p -prom-env "auto-boot?=true" -g 1024x768x32 -cpu G4 -drive file=macosx1003.img,if=ide,media=disk,format=qcow2,index=0,copy-on-read=off,werror=ignore,rerror=report,cache=writethrough -usb -device usb-mouse -sdl

I don't recommend using OS 9 with them, though. The last time I checked, I had several problems with installing 9.2.1 onto a qcow2 image.

If you're using qcow, use qcow2 or 3; qcow1 should no longer be used. I've used qcow2 on an OS X host with no issues; it also makes saving/restoring states of OS 9 possible For the person commenting on wanting to save/restore state of Crystal Quest in Mini vMac, you can do it via OS 9 in qemu.

[sidoh]

Yeah, I'll probably have another go at installing OS 9 on a qcow2/3 image soon.

[CharlesS]

For the person commenting on wanting to save/restore state of Crystal Quest in Mini vMac, you can do it via OS 9 in qemu.

I was kidding, but thanks.

[bumper314]

The mouse is almost unusable for me. I have to click very long for a single click to get registered, which precludes being able to double-click. Anyone know how to fix this?

Mac OS X 10.9.5 host
qemu 2.7-rc0
Tried 9.2.2 and 9.2.1 guests.

[Programmingkid]

The mouse is almost unusable for me. I have to click very long for a single click to get registered, which precludes being able to double-click. Anyone know how to fix this?

Mac OS X 10.9.5 host
qemu 2.7-rc0
Tried 9.2.2 and 9.2.1 guests.

Your version of QEMU is an older version. Could you try the newest release?

[adespoton]

The mouse is almost unusable for me. I have to click very long for a single click to get registered, which precludes being able to double-click. Anyone know how to fix this?

Mac OS X 10.9.5 host
qemu 2.7-rc0
Tried 9.2.2 and 9.2.1 guests.

Beyond upgrading to at least 2.7 final, what command-line options are you using? I found that enabling USB audio on OS 9, for example, causes slowness and crashes.

[bumper314]

Thanks for the reply. I updated to 2.7 final via Brew (--with-sdl), but now the mouse just flies to each corner of the VM and is uncontrollable.

Code: Select all

/usr/local/Cellar/qemu/2.7.0/bin/qemu-system-ppc -bios ./openbios-ppc -boot c -M mac99 -m 256 -prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -g 1440x900x32 -netdev user,id=network0 -device rtl8139,netdev=network0 -drive file=os9.raw,format=raw,media=disk

Tried `-vnc :5`, but the VM locks up as soon as I connect.

I got openbios-ppc from http://www.emaculation.com/doku.php/ppc ... mu-for-osx
I don't know if there's an official channel.

Any help is appreciated.

[Cat_7]

Why don't you use our cocoa builds? They don't have your sdl mouse problem.

See here:
http://www.emaculation.com/forum/viewto ... =34&t=8848

Take e.g., this build:
http://www.open.ou.nl/hsp/downloads3/Qe ... 082016.zip

Best,
Cat_7