GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

[sidoh]

What happens if you do a clean install rather than upgrade? I clean installed all mine without a hitch, but I'm using the OS X build.

I end up with this screen:



I tried the same combos as above.

[Programmingkid]

I can confirm a regression in the mouse control between QEMU 2.7.0 rc5 (built by Stefan) and QEMU 2.8-devel (built by Cat7). The mouse is harder to control in fullscreen, particularly when the user is trying to click and drag on an anything, including a window for the OS.

In this case, I am using Mac OS 9.2.2 with 64-bit Windows builds of QEMU. I am using an old laptop (>5 years old) with 64-bit Windows 10.

Trying to resize a windows in QEMU 2.8-devel is very difficult. Normally, in Mac OS 9.2.2, you can resize a Finder window by dragging its bottom-left corner. However, doing so in QEMU 2.8-devel jerks the mouse all over the screen (possibly because of CUDA or the PMU). The mouse seems to have this tendency of trying to move to the corners. I'll definitely have to get a QEMU environment set up to test this out.

By contrast, QEMU 2.7.0 rc5 allows me to set the size windows by dragging along the bottom-left corner of a windows.

Setting the mouse speed with the mouse control panel does not affect this either.

In neither build does the mouse work correctly when windowed in either GTK or SDL.

I suspect this could also do with the refresh rate in QEMU, although I don't see any parameters that allow me to set this.

The cocoa interface also has this mouse problem with rc5. The parameter that controls the refresh rate is located in hw/misc/macio/cuda.c. It is called CUDA_ADB_POLL_FREQ.

[Amiganaut]

I end up with this screen:

Hmm. That's the same error I was getting after installation when I started with QEMU.

If you've been able to get other stuff installed ok, then I take it you have auto-boot set to false? That was the fix for me. I could then shut down QEMU cleanly after the installation had finished and rebooted to the openbios prompt and change from cd to hd booting.

There was nothing special required to get any of these builds installed here.

[sidoh]

Yes. I closed QEMU at the openbios prompt, changed the boot order and set auto boot to false, but when I reopen it, I get stuck at this screen.

[Cat_7]

The problems with the windows builds seem to be solved when you set the compatibility of the qemu executables to Windows7. I can now partition and install reliably.

At least in the "wip" build, there is even audio (crackles a little bit), provided you have a usb audio headset
In Mac OS 9.2, I use this in the command line: -usb -device usb-audio

Please give it a try and report back.

Best,
Cat_7

[sidoh]

The problems with the windows builds seem to be solved when you set the compatibility of the qemu executables to Windows7. I can now partition and install reliably.

Please give it a try and report back.

Best,
Cat_7

Hmm, this problem still happens with both the 10.2 and 10.3 WWDC builds:

[Cat_7]

No way of helping without the command line

Best,
Cat_7

[sidoh]

No way of helping without the command line

Best,
Cat_7

Heh, I'm trying something to see if it works. If it still doesn't, I'll post the command line here.

UPDATE: So it still does not work. Here's my command line pre-install (For the Mac OS X 10.3 WWDC build):

Code: Select all

qemu-system-ppc-wip -bios openbios-ppc-rtas -L pc-bios -boot d -m 256 -M mac99 -prom-env "auto-boot?=false" -g 1024x768x32 -cpu G3 -drive file=Disc1p.iso,format=raw,media=cdrom -drive file=macosx1037a179.raw,format=raw,media=disk

Where 'Disc1p.iso' is the 1st CD of 2 and 'macosx1037a179.raw' is the disk image I'm installing it to (4GB in size).

Post-install:

Code: Select all

qemu-system-ppc-wip -bios openbios-ppc-rtas -L pc-bios -boot c -m 256 -M mac99 -prom-env "auto-boot?=false" -g 1024x768x32 -cpu G3 -drive file=macosx1037a179.raw,format=raw,media=disk

Also, here's the command I used to create the disk:

Code: Select all

qemu-img create -f raw macosx1037a179.raw 4G

All of these were done on a Windows Server 2016 TP5 host.

[Amiganaut]

That's much the same as mine, except I used 1G ram and the openbios-qemu-wip bios. Maybe try that and see?

I did find the Windows version a lot buggier. Especially with disk handling. Which is why I stick with the OS X build.

[sidoh]

That's much the same as mine, except I used 1G ram and the openbios-qemu-wip bios. Maybe try that and see?

I did find the Windows version a lot buggier. Especially with disk handling. Which is why I stick with the OS X build.

OK, I'll try that. BTW, my only Mac is an iBook G4 which only supports 10.3.5-10.5.8. That's why I'm using the Windows build in the first place.

[Cat_7]

qemu-system-ppc-wip -bios openbios-ppc-rtas -L pc-bios -boot d -m 256 -M mac99 -prom-env "auto-boot?=false" -g 1024x768x32 -cpu G3 -drive file=Disc1p.iso,format=raw,media=cdrom -drive file=macosx1037a179.raw,format=raw,media=disk

There can be a problem when you mix those qemu and bios builds. Try with openbios-qemu-wip.elf file for bios and use the mac99p model.

I did find the Windows version a lot buggier. Especially with disk handling. Which is why I stick with the OS X build.

Set the qemu program compatibility to windows7 and your disk problems should be solved.

Best,
Cat_7

[CharlesS]

Then I looked at the IDE file... CodeWarrior 5 !?!? I guess I could try and dig out my copy of CodeWarrior, but that's an XML file, and I don't recall my copy of CodeWarrior 10 using XML -- which means this must be something more recent.

Ben Herrenschmidt will get his builds included in the qemu source as a submodule. And now you know why. If I recall correctly from the discussion on the board, he currently builds the vga driver in Mac OS, not OSX But that might change, seeing this:
http://lists.nongnu.org/archive/html/qe ... 00024.html

Best,
Cat_7

From the thread:

In fact I don't think Apple XCode can either, which leaves us with CodeWarrior (commercial) or MPW (which I think at some point became free but I didn't find it and it doesn't work on OS X afaik).

Has anyone told him about this?

https://github.com/ksherlock/mpw

[sidoh]

qemu-system-ppc-wip -bios openbios-ppc-rtas -L pc-bios -boot d -m 256 -M mac99 -prom-env "auto-boot?=false" -g 1024x768x32 -cpu G3 -drive file=Disc1p.iso,format=raw,media=cdrom -drive file=macosx1037a179.raw,format=raw,media=disk

There can be a problem when you mix those qemu and bios builds. Try with openbios-qemu-wip.elf file for bios and use the mac99p model.

I did find the Windows version a lot buggier. Especially with disk handling. Which is why I stick with the OS X build.

Set the qemu program compatibility to windows7 and your disk problems should be solved.

Best,
Cat_7

Nope, I still get the same problem here (see the above image). Also, with Mac OS X Developer Preview 4 and 10.1 Build 5F24, I can't boot up from the install disk. It looks like some problem with the disk drivers:



This has already been reported before, but has there been any progress on this since then? I'm using the latest QEMU build with the latest OpenBIOS for this, BTW.

[hyoenmadan]

Has anyone told him about this?
https://github.com/ksherlock/mpw

68k version only it seems. This needs to be updated for PowerPC.
In any case, i heard that even Apple switched from MPW to Codewarrior for all their PowerPC development... Probably even if you get MPW running in OSX, you will not be able to produce anything useful with that.

The best bet is still Codewarrior it seems.

That said, the format doesn't look too complex; we could probably compile the code to objects and write a linker in Python.

That's how it looks, but generally ends being annoying complex and a hell to maintain. For example, I remember ReactOS used to have in-home crafted tools for all their development, except compilers, taken from MinGW. But soon maintenance for these tools became an annoying hell. They ditched their homemade build system and linker patches for CMake, and gave on trying to construct their own debugging system. Almost all them even gave on fixing GDB to cooperate with their NT kernel. Nowadays almost all them use Visual Studio CL compiler + Cmake as development toolbox, and WinDBG for their debugging capabilities .

[adespoton]

I had been meaning to mention: going the Mini vMac/MPW route has the same issues as the MPW emulator: 68k only. That said, the PPC linker should still work, and a cross compiler is all we need for the PPC code. This should be something we can instrument without resorting to compiling it in CW from within the emulation environment we're compiling it to support.

I'm not suggesting doing anything like the mess ReactOS got into with the best of intentions; only retooling the bits that don't have an equivalent modern component in the toolchain; in this case, a linker that's aware of PowerPC structures. Since it's only doing one t hing, and that's for hardware that is old and is no longer being developed, it shouldn't be a maintenance nightmare.

[kataetheweirdo]

Code: Select all

qemu-system-ppc-wip -L pc-bios -bios openbios-qemu-wip.elf -boot c -M mac99 -m 256 -drive file=testimg.img,if=ide,media=disk,format=raw,index=0,copy-on-read=off,werror=report,rerror=report

Decided to try something a little different. With this, now I can see Ben's video driver in action and I can switch between resolutions on the fly. Not only that, but the 256 colors and 256 grays modes are no longer corrupted. This is definitely an excellent change.

The mouse still needs a bit of work, even in fullscreen, but it does work better. However, this still crashes QEMU any time you try hard disk operations...or even move icons, sometimes.

I changed werror to report to see if any errors were printed out. There were no errors printed out to either stderr or stdout, which makes some sense, since this is on OpenBIOS's side.

Here's stdout for curiosity's sake:

(qemu) MACIO: Creating CUDA
PMU: 0000000000000000
CUDA: 0000000008807da8
adb_bus: 00000000088081b0
Machine ARCH=1

I'll soon be trying out the cache, aio, and detect-zeroes command arguments.

EDIT: FINALLY fixed the disk writing issues in 2.8-devel with this command prompt:

Code: Select all

qemu-system-ppc-wip -L pc-bios -bios openbios-qemu-wip.elf -boot c -M mac99 -cpu G3 -m 256 -drive file=testimg.img,if=ide,media=disk,format=raw,index=0,copy-on-read=off,werror=ignore,rerror=report,cache=writethrough -usb -device usb-mouse -sdl

As I suspected, I just had to specify cache=writethrough for my hard disk.

Not perfect, but at least it doesn't freeze every time it does a block write. I do note that QEMU freezes when you restart the machine.

EDIT 2: I can also confirm that you can't boot Mac OS 9.x images if if=scsi. If you use the if command argument, if should always be ide.

EDIT 3: Modified the command prompt to the one that works best for me, with little to no mouse errors, functioning keyboard, non-crashing disk writes, and using the latest OpenBIOS.

[PeterHolbrook]

I've finally decided to take the plunge by installing Tiger on Qemu, but it seems I've got some resounding failure. This is what I've done:

• I downloaded http://www.open.ou.nl/hsp/downloads3/Qe ... 082016.zip and placed its unzipped contents in a folder in ~/Downloads
• Using Disk Utility in El Capitan, I created a disk image from my Tiger install DVD in the same folder as above. Although the image is actually a dmg, I named it "TigerDVD.iso"
• Using TextEdit, I edited qemu.command so that it will resort to the Tiger image just created. All other elements of qemu.command have been left untouched
• I ran qemu.command

The relevant Terminal window displays this:
MacPro:~ PJH$ /Users/PJH/Downloads/Qemu/Qemu_28pre-vga-OSX-Leopard-network-wip-21082016/qemu.command ; exit;
MACIO: Creating PMU
PMU: 0x7f85f9073c00
adb_bus: 0x7f85f9074190
Machine ARCH=4

The yellow Qemu window says:
Welcome to OpenBIOS v1.1 bullt on Aug 13 2016 06:48
Trying cd:,\\:tbxi...
Trying cd:,\\\ppc\botinfo.txt...
Trying cd,: %BOOT...
No valid state has been set by load or init-program
0 >

I must have done something wrong, but what?

[sentient06]

Isn't about us here, being copyrightnazis or such. Is about QEMU and Apple. QEMU isn't like the other emulators or MAME/MESS. They actually have strict rules about their emulated hardware targets requiring copyrighted code to even initialize, let alone boot. Doesn't help a lot that actually QEMU is part of commercial projects and drives actually the core of many commercial VM solutions. Sure, you can fork and do your own work outside moding the code for your needs, but you really don't want to do that in this case, because mac99 and g3beige are still targets in development.

The other side is that Apple actually can be as Nintendo with relation to their copyrighted works if you annoy them enough, or they think you are doing them a sort of damage. Sure, Apple doesn't care about niche emulators and fan communities, but this could change if this sort of resource appears in a widespread product like QEMU, which actually has commercial VM solutions based on it.

I know that's an overly simplistic question, but isn't it possible to develop some sort of wrapper for ROM images that could be used in conjunction with QEMU? So in a sense, the user is responsible for providing the ROM images of whatever computers they want and the data is just fed into the emulator somehow. This would allow not only Macintosh but a myriad systems to be emulated. So instead of wrapping the whole emulator, just wrap the ROM and feed the emulator.

Oh well, I guess we are back again to that idea that the solution would be to make a reverse engineering of a ROM using clean room technique, just like Compaq did with IBM. The clean room solution would be awesome.

[Amiganaut]

It sounds like you've imaged the volume, but not the whole disc, so it's missing the partition map required to make it bootable.

Click on the DVD drive (or the disc, I'm not 100% sure yet) in the left hand side and create an image from it (new image from untitled/volume label). Change the format to DVD/CD master and it will write out a .cdr file. This is the same as an iso so you can leave it at that or change the file extension.

Alternatively, you can use the Terminal.

Use the Info button in Disk Utility to identify what disk it is (if there's only one internal hard disk, the dvd will probably be disk1). Then use the Unmount button to unmount the disc so it can be copied.

Then in the terminal type:

dd if=/dev/disk1 of=~/TigerDVD.iso

And it will save it out to an iso file on your desktop. It will take a bit of time and there's no progress meter. When it's finished you'll be back at the command prompt again.

[PeterHolbrook]

It sounds like you've imaged the volume, but not the whole disc, so it's missing the partition map required to make it bootable.

I haven't proceeded with your advice yet, but I think you are absolutely right. Many thanks.

Edit: As already said, you were right. Currently installing Tiger. I don't recall if that will install Classic on its own or further user intervention is required.

Edit2: Sadly, I've come to another dead-end (for the time-being, I hope). When I try to boot the no-longer empty "empty_disk.raw" where Tiger has just been installed, I get the Apple logo for ever. No progress bar, no nothing.

This is the Qemu command line:

./qemu-system-ppc-wip-16082016 -bios ./openbios-qemu-wip-13082016.elf -boot c -M mac99p -m 512 -prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -netdev user,id=network0 -device sungem,netdev=network0 -g 1024x768x32 -drive file=empty_disk.raw,format=raw,media=disk

What an I doing wrong now?

Edit3: It appears I wasn't patient enough. After what must have been nearly five minutes (!) displaying the Apple logo, now I have a completely blue background and a spinning beachball. I suppose it will be several more minutes before it gets to the desktop.

[Amiganaut]

Yeah the first reboot can be slow. Are you using a retail or "grey" disc? IIRC, grey discs should have a Classic installer on them. Retail ones probably don't.

It's a long time since I've ran these old OS X versions but I've been getting back into them recently thanks to trying out QEMU. I just haven't been back down the Classic road yet.

[adespoton]

Better to use a retail disk, and then use a retail 9 disk and 9.2.2 update to install on a separate disk image. That way, you can dual boot, move the images around, and still use the secondary image as your Classic location.

[PeterHolbrook]

Yeah the first reboot can be slow. Are you using a retail or "grey" disc? IIRC, grey discs should have a Classic installer on them.

I was unable to find my original Tiger DVD, which was grey, so I've used a copy that I made when I bought it. In order to install classic, I've used the second Panther CD-ROM (grey) that came with my Power Mac G5. I suppose that's OS 9.2.1. So I imagine Software Update will offer me 9.2.2 soon enough.

I'm very impressed with Qemu's speed. The first boot was extremely slow, but now Tiger is capable of booting possibly just as fast, if not faster, than it used to take on my G5!

I guess that our next goal should be sound and better integration of the host in such things as transparently printing to the host's default printer, dragging and dropping files/folders to/from the client's desktop/folders, et cetera.

[Cat_7]

If you are going to install a classic system folder on the OSX partition, you can try this openbios. It allows you to use the startup disk control panel in both Mac OS and OSX.

http://www.open.ou.nl/hsp/downloads3/op ... er.elf.zip

It is the same bios as with the 21082016 download for OSX, with a small fix.

This was my report to the developer after testing it:

It works as advertised, but only when there are two systems on the same partition. It does not when you have two partitions with separate installations of OSX/MacOS. Furthermore, the restart option inside the OSX preferences panel doesn’t work. Only restart for the main menu works. After selecting another boot disk on the Mac OS side, clicking restart leads to a black screen. Shut down and new start of Qemu does change the OS to be booted.

Best,
Cat_7

[PeterHolbrook]

If you are going to install a classic system folder on the OSX partition, you can try this openbios. It allows you to use the startup disk control panel in both Mac OS and OSX.

http://www.open.ou.nl/hsp/downloads3/op ... er.elf.zip

Many thanks for that and for the continued support you've been providing for so long. Do you have any insider knowledge as to how far sound is for OS 9/X running on Qemu in El Capitan? Is anyone working on that?