GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

[adespoton]

So is SheepShaver just cheating and passing the FPU operations off to the host CPU? I'm wondering if qemu is emulating the FPU with 32 bit integer math operations, which explains the bad scores. I thought there was JIT-FPU code though, which I would think would be passed to the host FPU operators. But looking at the existing softfloat code, it appears that the inlining at least is all done with 32 bit unsigned ints, even if the results are stored in 64 bits if the registers are available. This means that while the potential is all there to be blazing fast, the code designed to speed things up at runtime is actually acting as a bottleneck as the instructions are broken down into 32 bit segments, processed, and then built back up before dropping the result into the expected registers. Good for portability to 32-bit architectures with no FPU, but a total performance nightmare when run on a modern 64-bit architecture with pipelining designed to optimize floating point operations.

[kataetheweirdo]

Oh yeah, I never tested a benchmark on PearPC. I did use PearPC for a bit, but I didn't do much with it.

As for Sheepshaver, the FPU emulation was originally basically nonexistent. The instructions that were there were moving to and from the FPSCR. That's was it.

When Gwenole worked on Sheepshaver, he programmed it so that all the basic operations, including the floating point ones, were ran through expressions. Furthermore, the basic floating point operations were all made macros if the system was on a x86 processor to speed up floating point emulation.

As for QEMU, it's similar-ish to what Sheepshaver does, but it doesn't do any of the shortcuts Sheepshaver did. That means all the floating point operations have to be run in the guest alongside the rest of the instructions, rather than handling them to the host. Here's where the floating point emulation is located.

Lastly, for PearPC, it first takes apart the instructions by opcode, then by sub-opcode. All the functions are voids, which means these functions have to be taken apart and then stored into the variables desired by that operation.

EDIT: Before I forget, here's a site that notes unmerged commits. Pretty sure you can find this on GitHub too, which is where the QEMU source code is stored. As for finding out which patches on the QEMU dev mailing list have yet to be put into the master, I'm not quite that skilled yet.

[Programmingkid]

So... on my way to being able to build the VGA binary for qemu:

And yet, so far.

It's almost willing to work, but it looks like I'll have to hunt down a different license than the educational one I have.

What problems did you see when building the VGA driver?

I am trying to build it right now using MPW. If I succeed, I will give Ben my changes so the driver could be build on both CodeWarriors and MPW.

[Programmingkid]

So... on my way to being able to build the VGA binary for qemu:

And yet, so far.

It's almost willing to work, but it looks like I'll have to hunt down a different license than the educational one I have.

Ok, I have finally figured out how to build the VGA driver. First download CodeWarriors 7 Pro from here: http://macintoshgarden.org/apps/codewarrior-pro-71. Then install it and the 7.1 update. Use "wsde" as the registration code. Next open the file QemuVGADriver.mcp.xml. You will probably have to change the TYPE and CREATOR codes of the file to TEXT and CWIE respectively in order for the file to show up in CodeWarrior's Import Project file dialog. After it opens just select Project->Make. You will then have a new qemu_vga.ndr file in the Builds folder.

I did try to use the qemu_vga.ndr file, but the latest QEMU commit still doesn't the support code in OpenBIOS yet. It is possible I did something wrong. The qemu_vga.ndr file was placed in the pc-bios folder before starting QEMU. Maybe this isn't the right thing to do.

[adespoton]

That's great news that it works in 7! That means it should work in my copy of CW 8 Pro too. I've been keeping 6 installed because it's the last version that supported 68k targets, but the VGA project wouldn't open in it.

[edit] Hey... I just found out that you can use the CW6 68k compiler and linker with CW7 :D

I may go that route; I'd forgotten how much of a pain CW8 was.

[gtxaspec]

I did try to use the qemu_vga.ndr file, but the latest QEMU commit still doesn't the support code in OpenBIOS yet. It is possible I did something wrong. The qemu_vga.ndr file was placed in the pc-bios folder before starting QEMU. Maybe this isn't the right thing to do.

clone this repo "wip" from benh
https://github.com/ozbenh/qemu/tree/wip/


place your ndrv in pc-bios (remove the one included first), then include it in the command line when starting:
-L pc-bios

should automatically load it.

FYI I don't work in OSX anymore, i use linux (everything including VNC & gtk and sdl interfaces, really well!), so YMMV.

[adespoton]

I did try to use the qemu_vga.ndr file, but the latest QEMU commit still doesn't the support code in OpenBIOS yet. It is possible I did something wrong. The qemu_vga.ndr file was placed in the pc-bios folder before starting QEMU. Maybe this isn't the right thing to do.

clone this repo "wip" from benh
https://github.com/ozbenh/qemu/tree/wip/


place your ndrv in pc-bios (remove the one included first), then include it in the command line when starting:
-L pc-bios

should automatically load it.

FYI I don't work in OSX anymore, i use linux (everything including VNC & gtk and sdl interfaces, really well!), so YMMV.

For OS X there's no pc-bios folder; it goes in the same folder as the openbios.elf file and is named .ndrv instead of .ndr

[Cat_7]

For OS X there's no pc-bios folder; it goes in the same folder as the openbios.elf file and is named .ndrv instead of .ndr

There is no pc-bios folder in the builds I provided. But if you roll your own, there is.
You can also use a pc-bios folder with my builds, just put all files excluding the Libs folder and qemu/qemu-img in a pc-bios folder and refer to it with -L pc-bios. You can then add the qemu-vga driver to the pc-bios folder.

You might also need Ben's OpenBIOS to load the driver:
https://github.com/ozbenh/openbios

Or use the latest OpenBIOS from my download.

Best,
Cat_7

[Programmingkid]

That's great news that it works in 7! That means it should work in my copy of CW 8 Pro too. I've been keeping 6 installed because it's the last version that supported 68k targets, but the VGA project wouldn't open in it.

[edit] Hey... I just found out that you can use the CW6 68k compiler and linker with CW7 :D

I may go that route; I'd forgotten how much of a pain CW8 was.

If you thought CodeWarriors was a pain, you haven't tried MPW.

If you were able to add your code that allows the user to add resolutions from the command-line, could you sent it to me? I was thinking about doing the same thing, but if you already succeeded maybe I could review your code before you send it to the QEMU mailing list.

Thank you everyone for your help.

[Programmingkid]

My update on using qemu-system-ppc in KVM mode. The mouse seems to work very well. It is very fluid. Video playback is actually worse on KVM mode than it is in emulation mode on a Core 2 Duo. Audio is non-existent because of a bug with pulseaudio. I did report the bug. My KVM host is a 2 GHz iMac G5 running Ubuntu Mate.

[adespoton]

That's great news that it works in 7! That means it should work in my copy of CW 8 Pro too. I've been keeping 6 installed because it's the last version that supported 68k targets, but the VGA project wouldn't open in it.

[edit] Hey... I just found out that you can use the CW6 68k compiler and linker with CW7 :D

I may go that route; I'd forgotten how much of a pain CW8 was.

If you thought CodeWarriors was a pain, you haven't tried MPW.

If you were able to add your code that allows the user to add resolutions from the command-line, could you sent it to me? I was thinking about doing the same thing, but if you already succeeded maybe I could review your code before you send it to the QEMU mailing list.

Thank you everyone for your help.

Actually, I used to find MPW much easier; it was very POSIX, so every tool had a specific job and I could script them and just get on with it. CW 7 and earlier took the middle ground between this and the Think IDE "one interface" concept, which worked well, as for most projects you just use the IDE and it takes care of the rest. CW 8+ just got... weird. It did some things the old fashioned CW way, and then added on a bunch of other stuff (and removed some things) so that you were never sure whether you needed to add a new preference pane, find the feature you were looking at in the existing libraries, or use a specific tool earlier in your toolchain before presenting it to the IDE.

Personally, I always liked the atomic simplicity of MPW I used to have an add-on for the toolserver that let me log in remotely, and this allowed me to have a number of Macs set up with MPW, all part of a compile farm controlled by NetBSD via Telnet. Try THAT with CodeWarrior!

I've got limited time with my build VM this week, but I've got CW upgraded to 7 now, so I'll try importing the project into there and ensure it compiles. Once I've verified it is functional, I'll send it off to you for review My changes are pretty simple, as I just added extra resolutions to the existing list; I haven't gone as far as getting it to accept an external value yet. I figure there's really nothing wrong with having a long list of resolutions to pick from, so why not just include all the standard variations up to 4k? I haven't decided whether to do a set that accounts for windowed mode (leave room for Linux bars, Windows Start bar, Mac menu bar) yet.

[Programmingkid]

That's great news that it works in 7! That means it should work in my copy of CW 8 Pro too. I've been keeping 6 installed because it's the last version that supported 68k targets, but the VGA project wouldn't open in it.

[edit] Hey... I just found out that you can use the CW6 68k compiler and linker with CW7 :D

I may go that route; I'd forgotten how much of a pain CW8 was.

If you thought CodeWarriors was a pain, you haven't tried MPW.

If you were able to add your code that allows the user to add resolutions from the command-line, could you sent it to me? I was thinking about doing the same thing, but if you already succeeded maybe I could review your code before you send it to the QEMU mailing list.

Thank you everyone for your help.

Actually, I used to find MPW much easier; it was very POSIX, so every tool had a specific job and I could script them and just get on with it. CW 7 and earlier took the middle ground between this and the Think IDE "one interface" concept, which worked well, as for most projects you just use the IDE and it takes care of the rest. CW 8+ just got... weird. It did some things the old fashioned CW way, and then added on a bunch of other stuff (and removed some things) so that you were never sure whether you needed to add a new preference pane, find the feature you were looking at in the existing libraries, or use a specific tool earlier in your toolchain before presenting it to the IDE.

Personally, I always liked the atomic simplicity of MPW I used to have an add-on for the toolserver that let me log in remotely, and this allowed me to have a number of Macs set up with MPW, all part of a compile farm controlled by NetBSD via Telnet. Try THAT with CodeWarrior!

I've got limited time with my build VM this week, but I've got CW upgraded to 7 now, so I'll try importing the project into there and ensure it compiles. Once I've verified it is functional, I'll send it off to you for review My changes are pretty simple, as I just added extra resolutions to the existing list; I haven't gone as far as getting it to accept an external value yet. I figure there's really nothing wrong with having a long list of resolutions to pick from, so why not just include all the standard variations up to 4k? I haven't decided whether to do a set that accounts for windowed mode (leave room for Linux bars, Windows Start bar, Mac menu bar) yet.

Lets see the list of values. I'm hoping 1200x700 will make the list eventually.

Every common resolution to 8k! https://en.wikipedia.org/wiki/List_of_c ... esolutions

Ok, I came up with my own list of 20 resolutions. Let me know what you think.

640x400
640x480
800x600
1024x600
1024x640
1152x864
1200x700
1280x720
1280x768
1280x800
1366x768
1440x900
1920x1200
2304x1440
2560x1080
2560x1600
2880x1800
4096x3072
4096x2304
8192x4608

Please do a set that accounts for windowed mode. That would be helpful to those who do work in both the host and guest.

[adespoton]

That... might be a bit much.

How does this sound? People, feel free to add other resolutions you'd like to see

512x342
640x480
768x480
800x480
800x600
832x624
960x640
1024x576
1024x600
1024x768
1152x768
1152x864
1280x720
1280x768
1280x800
1280x854
1280x960
1280x1024
1334x750
1366x768
1400x1050
1440x900
1440x960
1440x1080
1600x900
1600x1200
1680x1050
1920x1080
1920x1200
1920x1400
2048x1152
2048x1536
2560x1440
2560x1600
2560x2048
2732x2048
2800x2100
2880x1800
3200x1800
3200x2048
3200x2400
3840x2160
4096x2304
4096x3072
5120x2880

I think going above that in emulation is a bit silly at this point; we could always add more in the future if we want to

[edit] I like your list better. I'd add 512x342 just in case we ever end up using this for Mac Plus/128k emulation.

[edit2] Mac menu bar is 22 pxels, Win7 taskbar is 70 pixels. Win8 taskbar is 30 or 40 pixels. LXDE appears to be about 30 pixels.
Should we take 40 pixels off the h resolutions to work for most people?

[Programmingkid]

That... might be a bit much.

How does this sound? People, feel free to add other resolutions you'd like to see

512x342
640x480
768x480
800x480
800x600
832x624
960x640
1024x576
1024x600
1024x768
1152x768
1152x864
1280x720
1280x768
1280x800
1280x854
1280x960
1280x1024
1334x750
1366x768
1400x1050
1440x900
1440x960
1440x1080
1600x900
1600x1200
1680x1050
1920x1080
1920x1200
1920x1400
2048x1152
2048x1536
2560x1440
2560x1600
2560x2048
2732x2048
2800x2100
2880x1800
3200x1800
3200x2048
3200x2400
3840x2160
4096x2304
4096x3072
5120x2880

45 resolutions!

I think going above that in emulation is a bit silly at this point; we could always add more in the future if we want to

[edit] I like your list better. I'd add 512x342 just in case we ever end up using this for Mac Plus/128k emulation.

I'm not sure how a MacPlus would access the driver. It was made before Apple switched to Open Firmware. I think the newest OS that can run on computers from that time period was System 7.5.5 or 7.6. If these operating systems could access the VGA driver then it would work. On second thought there were programs that were made with that resolution in mind, so using 512x342 sounds good.

[edit2] Mac menu bar is 22 pxels, Win7 taskbar is 70 pixels. Win8 taskbar is 30 or 40 pixels. LXDE appears to be about 30 pixels.
Should we take 40 pixels off the h resolutions to work for most people?

Don't forget the Mac OS X dock. It's height can change but I'm guessing 50 to 60 pixels might be the average size.

[Budgiebrain994]

Any chance of vertical resolutions? Hate me for this but I have a couple vertical screens. I guess it should be possible to rotate the screen in the OS.

Also, please make sure that full-screen resolutions are indeed full screen, without having a few pixels chopped off thanks Windowed resolutions would be fine to chop though.

I tried emulating this on my Pi BTW, it hung on the blue screen with the pinwheel of death for days.

[Programmingkid]

Any chance of vertical resolutions? Hate me for this but I have a couple vertical screens. I guess it should be possible to rotate the screen in the OS.

Also, please make sure that full-screen resolutions are indeed full screen, without having a few pixels chopped off thanks Windowed resolutions would be fine to chop though.

I tried emulating this on my Pi BTW, it hung on the blue screen with the pinwheel of death for days.

Yeah, just tell us what resolutions you want to see added.

Do you have the Raspberry Pi 3? There is a spot for a Raspberry Pi running Mac OS 9 video on Youtube waiting to be filled.

[adespoton]

A few vertical resolutions would be a good idea. Radius monitors tended to do 768x1024 through 1200x1600. I could add in the "standard" resolutions for those; I think there's only around 4 to deal with here. 768x1024, 800x1280, 900x1440, 1200x1600 sound good?

I was ignoring the dock because you can auto-hide the dock, or use a smaller resolution that doesn't go to the bottom of the screen. Otherwise, it's hard to account for something that can take up a variable amount of screen real estate. In practice, I've found that wide screen ratios handle the menu bar and dock quite nicely, with only a bit of extra space to spare. So I think we've already got that covered.

[Budgiebrain994]

Thanks guys, I'm specifically looking for 1080x1920 and 540x960 (for 2x scaling).

Do you have the Raspberry Pi 3? There is a spot for a Raspberry Pi running Mac OS 9 video on Youtube waiting to be filled.

I got Mac OS 9.2.2 working well so I'd love to do it :D

[Programmingkid]

A few vertical resolutions would be a good idea. Radius monitors tended to do 768x1024 through 1200x1600. I could add in the "standard" resolutions for those; I think there's only around 4 to deal with here. 768x1024, 800x1280, 900x1440, 1200x1600 sound good?

I will save these questions for Budgiebrain994.

I was ignoring the dock because you can auto-hide the dock, or use a smaller resolution that doesn't go to the bottom of the screen. Otherwise, it's hard to account for something that can take up a variable amount of screen real estate. In practice, I've found that wide screen ratios handle the menu bar and dock quite nicely, with only a bit of extra space to spare. So I think we've already got that covered.

There is another issue. How do we account for the task bar/dock when there are so many different resolutions available. Maybe a menu item that will automatically remove 40 pixels from the width of QEMU's window? A command-line option might also be the answer: -shrink_width 40.

[adespoton]

You've just raised another good point: I was assuming that the extra bar was on the top or bottom of the screen -- however, many people put their taskbar/dock on the side, which would adjust width, not height.

I think to really account for this, we're going to have to pass a value in. At which point, we can just pass the original resolution in.

So I'll ignore windowed widths for now (the widescreen vs ?GA ratio difference will already help here) and just go for standard aspect ratios and the special custom resolutions that some software might expect.

Meanwhile, we can work on a more complete solution of allowing resolution value to be passed in to the VGA firmware via an OpenBIOS setting.

[edit] In any case, it's easier than the poking around I've been doing in the VirtualBox EFI firmware; there, everything is stored as multipliers in registers, so you have to build out a table of values that shifts as more pixels need to be allocated. And VBox EFI is packed on disk, so you can't just open up the file in a hex editor and change the default resolution values. Thank you to those of you who put in the extra effort to make the VGA firmware code easily modifiable :D

[gtxaspec]

Hard coding these resolutions seems a bit backwards, don't you think?

Perhaps we should be reading this from the command line as arguments or from a configuration file so the user may specify ANY resolution they wish to display.

Just a thought.

[Programmingkid]

Hard coding these resolutions seems a bit backwards, don't you think?

Perhaps we should be reading this from the command line as arguments or from a configuration file so the user may specify ANY resolution they wish to display.

Just a thought.

Agreed.

[adespoton]

That's the idea.

The trick is that currently, there's a list of resolutions hard-coded into the VGA firmware code. We can add new ones without changing anything other than adding to a list. It's an easy quick win that then shows a nice list of options in the Monitors/Displays list in the OS. Looking at it closer, at least on my physical system, I have the following options by default on my 10.4.11 PPC rig:

Colors: 256/Thousands/Millions
Refresh: 56/60/67/70/72/73/75 -- I don't think this is really necessary to emulate. 60 should be fine.
Rotate: 90/180/270 -- not sure if this would work under qemu, or just display the screen sideways so you'd have to physically tilt the screen. I think some virtual vertical resolutions might be useful anyways, so you can take a modern wide screen display and show the guest system on half a screen.
Resolutions: 640x480, 640x480 (stretched), 640x512, 800x600, 800x600 (stretched), 800x640, 832x624, 848x480, 1024x768, 1024x768 (stretched), 1024x820, 1280x1024, 1360x768, 1440x900

The defaults for this device with the monitor I'm using are: 1280x1024, 60Hz, Millions / 1280x1024, 75Hz, Millions / 1440x900, 60Hz, Millions

So populating such a list in qemu seems like a good first step; then we can move on to work that will take actual vetting and development, adding in a pass-through parameter to allow a custom resolution. But having a pre-populated list of standard resolutions people can pick from is a good idea, and easy to implement, so why not? From qemu, a custom value set would have to go from qemu command line -> Open Firmware -> VGA Firmware, and then be sanity checked in code. So while this is a good idea, I think it's not only going to take longer, but is an additional feature we need, not a replacement feature.

[Programmingkid]

I did try to use the qemu_vga.ndr file, but the latest QEMU commit still doesn't the support code in OpenBIOS yet. It is possible I did something wrong. The qemu_vga.ndr file was placed in the pc-bios folder before starting QEMU. Maybe this isn't the right thing to do.

clone this repo "wip" from benh
https://github.com/ozbenh/qemu/tree/wip/


place your ndrv in pc-bios (remove the one included first), then include it in the command line when starting:
-L pc-bios

should automatically load it.

FYI I don't work in OSX anymore, i use linux (everything including VNC & gtk and sdl interfaces, really well!), so YMMV.

This is what I did:

git clone https://github.com/ozbenh/qemu.git
git checkout wip

Then I built qemu-system-ppc. Even with the '-L pc-bios' option I could not make the resolutions appear in Mac OS 9.2. The qemu_vga.ndrv file is in the pc-bios folder. Maybe Ben made some changes that make things incompatible with the vga driver.

[Cat_7]

You got the correct openbios?

best,
Cat_7