GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

[that-ben]

Oxyd does run in SheepShaver:

It's just almost impossible to play due to SheepShaver's janky mouse support. At any rate, the issue is not graphics acceleration (it runs on a Mac Plus, which definitely does not have any accelerated graphics).

Believe it or not, even if the game is old, it does NOT run on SheepShaver for Windows here. I see you're running it on a real Mac. Maybe it has something to do with the host OS or even the specific version of SheepShaver I'm using (which is SheepShaver_2015-03-15.exe for Windows). Inside SheepShaver, I'm running almost vanilla Mac OS 9.0.4 except for the screen resolution (widescreen) but again, if it has nothing to do with graphics acceleration as you say, then anything related to my screen shouldn't matter, right? What happens is it changes the color depth to black and white, then crashes the whole SheepShaver emulator before displaying the Oxyd game window. The same file runs good on my iMac (real hardware) with a COPY/PASTE of the *SAME* System Folder, tough, so I'm sure it has something to do with graphics emulation not being done properly. Again, the point is it's not the only software that does not run on SheepShaver due to graphics acceleration not being emulated or not being handled correctly, and YES I do agree it shouldn't be priority #1 but in my book, it would wrap the things up nicely after having an emulator capable of booting and properly running Mac OS 9.2.2... lol and also having an emulator not re-centering the mouse on the host OS everytime the cursor image changes in Mac OS like SheepShaver does *facepalm* that's the most annoying thing ever, but I still love you truely SheepShaver

KEEP IT UP GUYS, the hype/efforts with QEMU are really awesome!

[adespoton]

Here's a question about something I've forgotten:
Does QEMU emulate the PPC instructions that emulate an MC68040? I know QEMU emulates the 040 natively, but I can't recall whether it emulates via PPC, and my google searches are inconclusive.

I'd guess the answer is "yes" or else we'd still be having problems launching the Finder (which contains 040 code) from within QEMU, correct?

[gtxaspec]

QEMU emulates a PPC CPU completely; MacOS runs a 68k emulator that uses PPC instructions to translate 68k instructions.

The problem we have now is making sure QEMU emulates the hardware MacOS is expecting to be present, in the same exact way a real Macintosh would present it to the OS.

QEMU has no problem running linux and other operating systems that can run on a real Macintosh, it's just that MacOS expects many things to behave certain ways that other operating systems would ignore or wouldn't access in those certain ways, that is the real challenge.

[gtxaspec]

I have done extensive testing with MacOS 9.2.2 and QEMU. Most, if not all problems relate to Open Transport. It wreaks havok on QEMU, the OT extensions crash, and the OT code built into the System Suitcase's "wart" resource crashes the system as well. We will need assistance with the QEMU people to resolve these issues.


On the bright side, I have successfully booted an installed os 9.2.2 using QEMU. I will post a disk image shortly.

[mcayland]

I have done extensive testing with MacOS 9.2.2 and QEMU. Most, if not all problems relate to Open Transport. It wreaks havok on QEMU, the OT extensions crash, and the OT code built into the System Suitcase's "wart" resource crashes the system as well. We will need assistance with the QEMU people to resolve these issues.


On the bright side, I have successfully booted an installed os 9.2.2 using QEMU. I will post a disk image shortly.

Thanks a lot for taking a look at this. Just catching up on the thread here:

- Part of GSoC involved adding extra properties for the serial port. You can enable debugging in escc to see if any writes are being made here. Also does start QEMU with -serial stdio and typing a few characters help? Maybe OT gets upset if it the virtual serial port isn't connected to anything?

- QEMU currently doesn't emulate serial DMA (DBDMA). Then again, given that until a week or so ago a DBDMA access for an unmapped device would segfault the QEMU process then this would seem unlikely. Try enabling debugging in hw/misc/macio/mac_dbdma.c to see if anything is going to the serial port (note you will see disk accesses here too)

[gtxaspec]

Hi Mark,

Just finished doing a lot of testing last few days. Will follow your instructions and report back! Thanks for checking in! =D

[gtxaspec]

Hello,

Here is a bootable installation of MacOS 9.2.2 with the latest QEMU compiled from QEMU Devel git repo, with a disk image of installed MacOS 9.2.2 extracted from NetBoot9.dmg. Extract contents, then simply run qemu_os9.command to enjoy.

Booting was made possible by patching the System Suitcase to remove some Open Transport code:

Code: Select all

Removed entire resource "wart" from the System Suitcase, which upon inspection contained references to Open Transport libraries, without this resource removed, booting MacOS was impossible even with all Open Transport extensions and libraries removed.

Some Control Panels and Extensions still needed to be removed to fully boot to the Finder:

Code: Select all

Control Panels Removed:

Trackpad [ confirmed crash ]

Extensions Removed:

QuickDraw 3D Rave [ confirmed crash ]
Open Transport ASLM [ confirmed crash ]
Quicktime Extensions * firewire enablers [ confirmed crash ]
ATI & NVIDIA Video Drivers [ result in black screen in QEMU ]
Multiprocessing Folder [QEMU hard crash]
Apple Audio Extension [QEMU hard crash]
Multiple Users Extension [ crashes finder ]

This disk image is a full MacOS 9.2.2 installation, with lots of extensions and control panels. Virtual Memory is enabled and seems to work. Various utilities included. Your milage may vary.

Remember, the System Suitcase in this image has been modified. Replacing the Suitcase with a different version may result in a crash at boot. You may attempt modification to your own System Suitcase file, use a resource editor like ResEdit or Resorcerer, and just remove the entire "wart" resource. Save, and boot. Results may vary.

I will complete more research based on Mark's advice and report back with results. While this is not the intended goal of my research ( I hope QEMU to boot a stock OS9 installation with nothing removed or patched ), it is another nice proof of concept that MacOS does have much potential to work with QEMU, and validates the hard work that everyone involved in both the OpenBIOS and QEMU projects have put into making this all possible.

http://bebop.gtxent.com/qemu_easy_02.tar.gz

regards,
alfonso

[sentient06]

Mac OS 9.2.2.

It is happening!

[emendelson]

This is very promising. Unfortunately, I run Macports, not Brew, so when I run the command, I get this error message:

Code: Select all

dyld: Library not loaded: /usr/local/opt/pixman/lib/libpixman-1.0.dylib
  Referenced from: /Users/edward/Downloads/qemu_easy_02/./qemu-system-ppc
  Reason: image not found
./qemu_os9.command: line 3: 75882 Trace/BPT trap: 5       ./qemu-system-ppc -bios ./openbios-qemu.elf -boot c -drive file=./test.raw,format=raw,index=0,media=disk,cache=none -M mac99 -m 256 -prom-env 'auto-boot?=true' -g 1024x768x32 -cpu G4

I have libpixman and glib2 installed via Macports, but these don't seem to be useful here. Probably I'm just being incompetent, but if anyone knows a workaround for Macports users, I'll be grateful.

[gtxaspec]

not familiar with macports, I'll try to do some research, if anyone else knows macports please chime in

[adespoton]

It looks like there might be some hardlinked paths here, and macports uses /opt/ to store things rather than /usr/local/.

What is likely needed is a proper export to allow Homebrew to see your macports paths, or the opposite: a proper export of /opt/ so that Homebrew can see it.

So you know, Homebrew is very aware of MacPorts and Fink, and using the doctor is useful to highlight any issues. MacPorts is totally unaware of anything outside of /opt, and operates in its own little (and very complex) world of dependencies.

I eventually moved almost all my macports installs over to homebrew, as I've found it much easier to manage the dependencies that way, despite Homebrew basically just being individual recipes for installing specific software packages, and MacPorts being a complete porting of the BSD Ports system.

[adespoton]

I have done extensive testing with MacOS 9.2.2 and QEMU. Most, if not all problems relate to Open Transport. It wreaks havok on QEMU, the OT extensions crash, and the OT code built into the System Suitcase's "wart" resource crashes the system as well. We will need assistance with the QEMU people to resolve these issues.


On the bright side, I have successfully booted an installed os 9.2.2 using QEMU. I will post a disk image shortly.

Thanks a lot for taking a look at this. Just catching up on the thread here:

- Part of GSoC involved adding extra properties for the serial port. You can enable debugging in escc to see if any writes are being made here. Also does start QEMU with -serial stdio and typing a few characters help? Maybe OT gets upset if it the virtual serial port isn't connected to anything?

- QEMU currently doesn't emulate serial DMA (DBDMA). Then again, given that until a week or so ago a DBDMA access for an unmapped device would segfault the QEMU process then this would seem unlikely. Try enabling debugging in hw/misc/macio/mac_dbdma.c to see if anything is going to the serial port (note you will see disk accesses here too)

I seem to recall Pruten having similar networking issues when writing ShoeBill, although of course A/UX is very pre-OpenTransport in terms of both hardware and software. But he had some issues where if the correct data wasn't available in the buffer while Mac OS was initializing, things would go south quickly. Oddly, I can't find that thread anymore; perhaps I'm conflating two things/emulators?

[sentient06]

Guys, I know this might be somewhere in this thread and I will look for it in a minute, but honestly, it has 14 pages at this point and I don't want to raise questions to make the subject even more difficult to find. I tested the compiled version on Yosemite and it works just fine. I can't say the same for Snow Leopard. Is there a missing dependency on SL, or maybe a different compilation I can test it?
How are the systems in between? Is this working for Windows? I saw some screens from Linux, so I assume it works for any distro if it is configured correctly.
What do you think we open a thread only about compiling into different systems?

I can make a few tests, I have gcc 4.2, 4.6 and 4.8 on my homebrew and Apple's version of gcc (llvm) from XCode 3.2.1 and XCode 4.2. And 7.0.1, though I never used this one.

Cheers!

-- Update --

By the way, do all the stuff mentioned in that sticky OSX thread apply for Mac OS 9 emulation?

[kataetheweirdo]

@sentient06:
Make sure you have all of the libraries QEMU wants. Since you are trying to use QEMU on Mac OS 10.6, that may be a bit difficult getting these libraries.

Cat7 got it working with Windows, albeit with really dysfunctional mouse support. I can boot it up on my end, but it bombs out, crashes and is just plain unable to reach the desktop.

As for compiling QEMU on other systems, I would like a general compilation issues topic as well. I'm not sure if one has already been made though.

I'm not so sure about Mac OS X, but I think it may be a tad bit better. However, it still does not support things like sound or graphics acceleration. I'm not even sure if networking works (Mac OS X does have a driver for Realtek RTL8139, but I don't think Mac OS 9 does).

[Cat_7]

There is info on building qemu on the qemu site. I see at least three different ways of getting the dependencies for compiling on OSX: use homebrew, use macports, use rudix.

This guide uses rudix: https://theintobooks.wordpress.com/2015 ... -yosemite/
This (older) one uses homebrew: http://mikelev.in/2012/10/qemu-mac-os-x-success/
This guide describes using macports: https://alexwinston.wordpress.com/2015/ ... mu-on-osx/

I take my windows builds from: http://qemu.weilnetz.de/

@kataetheweirdo: the lastest hard disk image in the easy_qemu package by gtxaspec contains a realtek8139 driver for OS9. It loads as extension without problem, and you can add support for the rtl8139 device to the qemu command line. But as all open transport is disabled in the latest hard disk image networking can't be tested.

Best,
Cat_7

[adespoton]

I'm not even sure if networking works (Mac OS X does have a driver for Realtek RTL8139, but I don't think Mac OS 9 does).

There is one, and gtxaspec has included it in his 9.2.2 image (not installed)

However, the fact that we had to yank out all OpenTransport support means it's not usable (yet) unless you can figure out some way to boot with the old Ethernet, AppleTalk and MacTCP drivers.

[gtxaspec]

stay tuned. currently debugging open transport as to why it crashes within QEMU. I have a theory it has to do with serial communication and not ethernet networking, which happens to be intertwined in OT.

[adespoton]

I share your theory; the ethernet code outside of OT appears to have no problems. Have you tried just removing the serial resources? OT architecture is robust enough that it should be able to handle that without fully failing.

[gtxaspec]

currently reading: http://bebop.gtxent.com/NetworkingOT.pdf

from http://web.archive.org/web/200204130925 ... WOT-2.html
and
http://web.archive.org/web/200206102000 ... transport/

Inside Macintosh: Networking With Open Transport

Debug Version of Open Transport:
http://bebop.gtxent.com/OpenTransportDebug.img.hqx (2.7.4, havent tried yet, feel free, try with macsbug and http://bebop.gtxent.com/qemu_easy.zip)

[gtxaspec]

updated utilities iso:

http://bebop.gtxent.com/qemu_os9_utilitiesv2.iso.zip

Aladdin
RedEdit 2.1.3
MacsBug 6.6.3
Tome Viewer
Toast Deluxe
TattleTech
RTL8139x Driver
TechTool Lite
Kaleidoscope
HexEdit 1.92
RS 2.2

[Cat_7]

Hi,

I removed both Startup ASML PPC and Startup ASML 68K from the AINI's in the Open Transport extension in the debug extension set you provided.
I then copied all extensions from the debug set to the extensions folder in your second 9.2.2 disk (not the one with the CD background). This allows Mac OS to succesfully boot. So it seems the current issue is in the ASLM modules. These seem to refer to the functions in the shared libs, but
I have no idea where/how to edit the PPC and 68K shared libs.

Best,
Cat_7

[romper]

Is it possible to run run this image under linux?

[gtxaspec]

Yes, it is possible to have versions for MacOSX, PPC or x86, Windows and Linux.

You just need to compile QEMU for linux. There might be some pre-compiled versions out there.

[sentient06]

I am testing what is missing on my Snow Leopard machine to run QEMU. I found this nice 'otool' command that should do a similar job to Linux's 'ldd'. I thought it could be useful to other interested people, so I am dropping an example here.

The command:

Code: Select all

$ otool -L ./qemu-system-ppc

The output (this is a mbp mid-2014 with OSX 10.10.5 and the binary is from 'qemu_easy_02'):

Code: Select all

./qemu-system-ppc:
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1253.0.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
	/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 8.0.0)
	/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
	/usr/local/opt/pixman/lib/libpixman-1.0.dylib (compatibility version 33.0.0, current version 33.8.0)
	/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libsasl2.2.dylib (compatibility version 3.0.0, current version 3.15.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0)
	/usr/local/opt/glib/lib/libgthread-2.0.0.dylib (compatibility version 4601.0.0, current version 4601.1.0)
	/usr/local/opt/glib/lib/libglib-2.0.0.dylib (compatibility version 4601.0.0, current version 4601.1.0)
	/usr/local/opt/gettext/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.4.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1404.0.0)
	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0)
	/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 600.0.0)

[sentient06]

Can we copy MacTCP from System 7 and try using on 9.2.2? If I remember correctly, the use of MacTCP and OT were mutually exclusive.