GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

About QEMU, a PPC Mac emulator for Windows, macOS and Linux that can run Mac OS 9.0 up to Mac OS X 10.5

Moderators: Cat_7, Ronald P. Regensburg

WizKid
Tinkerer
Posts: 53
Joined: Sun Jul 31, 2016 11:58 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by WizKid »

Github repo or set of patches, please (against mcayland's branch)?
Programmingkid
Apple Corer
Posts: 243
Joined: Sun Jan 31, 2016 6:01 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Programmingkid »

alex195812 wrote:I did it another way(don't know if it matters though):
git clone -b screamer --single-branch https://github.com/mcayland/qemu.git
When started ./confugure it wanted dtc so I had to do:
git submodule update --init dtc.Next it went smoothly.
But I'm acquainted with the error you described.I met it when trying to use early 2.8.0 distribution(downloaded 21 Dec). ./confugure --help showed "awailable targets:qemu-2.8 *-sofmmu".In later distribution (downloaded 27 Dec) all is OK.
Thanx for macpack link.Now when my researches have slowered(met harder problems) it's time to learn making portable builds so people could really use them.
By the way,mcayland qemu version is network-broken,so it makes sense to port screamer and some other stuff(exept mac99p for it is based on incompatible changes in openbios) to 2.8.0.I have done something manually and can post the changed files for time-saving:
https://drive.google.com/open?id=0B69bs ... HJiT3N1Z0U Hope I haven't missed something essential.
Thank you for the info. The same thing happened again when I followed your instructions. I still saw the problem with the ppc-softmmu target. Running 'configure --help' did show that all of the targets are gone. This is what was there: *-softmmu.
alex195812 wrote: Well,using Macpack I've made this:
https://drive.google.com/open?id=0B69bs ... 2JJMXJDSnc
It should work on any system.At least it doesn't work on my system when I move libs folder.
Tested with Mac OS 9.2.2.Sound works,sungem network and resolutions,too.Generally,in mac99 screamer,sungem and vga should work,in g3beige vga only.Runs Leopard,too(slowly,usb-mouse and usb-kbd needed).No mac99p.It is more complcated for porting.
This release was a huge improvement over the last release. It does work on Mac OS 10.9.5. There were a few issues. I saw an error message that said it couldn't find the file efi-ne2k_pci.rom. I think the best thing to do is to just distribute the entire pc-bios folder with your QEMU binary. Using "-net none" fixed that problem for me. I was hoping you used my cooca.m file for your build. I am going to upload a version two that fixes the problems that were found with the first version. Also the icon for QEMU is missing. This isn't a big problem.

Screamer does work with Mac OS 10.4.3. I was able to play an mp3 with it. The sound quality is way better than the usb-audio device. I tried Mac OS 9.2, but the mouse kept jumping all over the place after pushing the play button in Quicktime. Changing resolutions works on both Mac OS 10.4.3 and Mac OS 9.2.

In order to test out how portable your binary is, I suggest you install Mac OS X on a usb flash drive. Then just boot off the flash drive and unmount the volume you made QEMU on. If all goes well, QEMU should boot up.

Thank you for all your work. I am glad that macpack helped you.
User avatar
adespoton
Forum All-Star
Posts: 3102
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

I think I'll wait until you two have gone a few more iterations before I test again; I'm looking for a version that I can patch with my OpenBIOS VGA variant that also has sungem and the screamer audio. We don't really have a version with better Leopard performance than the summer's mac99p build, right?
Programmingkid
Apple Corer
Posts: 243
Joined: Sun Jan 31, 2016 6:01 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Programmingkid »

This is version 2 of the super cocoa.m file. It fixed fullscreen mode not receiving mouse clicks, stops unicode characters from being used by the paste feature, and allows for uppercase characters to be pasted.

http://www.mediafire.com/file/93c1s4v1h ... file_2.zip
WizKid
Tinkerer
Posts: 53
Joined: Sun Jul 31, 2016 11:58 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by WizKid »

One nice feature to have would be to support 256 color mode. A lot or older games (Lemmings, SimCity 2000, etc) won't run in thousands or millions of colors.

They pop up a message saying that they must be run in 256 color mode.
Programmingkid
Apple Corer
Posts: 243
Joined: Sun Jan 31, 2016 6:01 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Programmingkid »

WizKid wrote:One nice feature to have would be to support 256 color mode. A lot or older games (Lemmings, SimCity 2000, etc) won't run in thousands or millions of colors.

They pop up a message saying that they must be run in 256 color mode.
That shouldn't be a problem. I do remember Ben's VGA driver giving the Mac OS the ability to select that resolution in the past. I wonder what changed to cause the color mode to disappear.
Programmingkid
Apple Corer
Posts: 243
Joined: Sun Jan 31, 2016 6:01 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Programmingkid »

Finally figured out what was wrong when trying to clone Mark's repo. If there are spaces in the path to the repo, the configure command will fail. I finally built his repo on Mac OS 10.6. Screamer audio is a lot better than usb-audio.
User avatar
adespoton
Forum All-Star
Posts: 3102
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

Programmingkid wrote:
WizKid wrote:One nice feature to have would be to support 256 color mode. A lot or older games (Lemmings, SimCity 2000, etc) won't run in thousands or millions of colors.

They pop up a message saying that they must be run in 256 color mode.
That shouldn't be a problem. I do remember Ben's VGA driver giving the Mac OS the ability to select that resolution in the past. I wonder what changed to cause the color mode to disappear.
I'n not sure; my build of the VGA code supports 256 colors just fine.
Programmingkid
Apple Corer
Posts: 243
Joined: Sun Jan 31, 2016 6:01 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Programmingkid »

adespoton wrote:
Programmingkid wrote:
WizKid wrote:One nice feature to have would be to support 256 color mode. A lot or older games (Lemmings, SimCity 2000, etc) won't run in thousands or millions of colors.

They pop up a message saying that they must be run in 256 color mode.
That shouldn't be a problem. I do remember Ben's VGA driver giving the Mac OS the ability to select that resolution in the past. I wonder what changed to cause the color mode to disappear.
I'n not sure; my build of the VGA code supports 256 colors just fine.
What is the exact version of the Mac OS you see 256 colors in?
User avatar
adespoton
Forum All-Star
Posts: 3102
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

Odd; I thought it was 9.2.2 using qemu 1.8pre with the VGA patch; but I just checked, and I've only got thousands and millions now. I'm SURE I had it working at some point in the past...?
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

This is version 2 of the super cocoa.m file. It fixed fullscreen mode not receiving mouse clicks, stops unicode characters from being used by the paste feature, and allows for uppercase characters to be pasted.

http://www.mediafire.com/file/93c1s4v1h ... file_2.zip
The same as above qemu version with extended cocoa added:
https://drive.google.com/open?id=0B69bs ... HZlSGxIWkE
Tested with Panther guest.Full screen clicks OK,pasting text,too.But there's an old issue with leaving full screen and turning back:for example,when you successfully pasted into TextEdit,then go full screen and back to windowed mode,and next try to paste it again,what happens...OMG!I have to reswitch to full screen and back(even few times) to make it calm and even force quit TextEdit for its menu comes unmanageble.
Generally,it's an old bug--mouse and keyboard behave differenlty when you leave fullscreen and return again.I ususally have to do it twice.I think it is due to Alt/Option keys engaged in switching keyboard layouts.Maybe these key combinations should be remapped in the guest not to suffer of this strange behavior or should full screen keys be remapped to,say,Ctl-F
As for 8bit mode it seems it doesn't work with VGA enabled(at least with standard drivers) even when specifyed on command line.In qemu versions without vga it can be specifyed on command line but what you get is black-white thing with inadequate tone.
This mode is desired(besides games) for BeOS to run.Though BeOS seems also not to supporti Mac OS 9.The only way I know to run Mac OS <9.0 in qemu is MacOS.app in MOSX10.0 DP1(emulated Mac OS 8.6).I wonder can BeOS be started there?

In DP1 256 color mode is present in Preferences but defalts to thousands and "Mode switching is currently not supported".Perhaps it can be changed somewhere manually.
WizKid
Tinkerer
Posts: 53
Joined: Sun Jul 31, 2016 11:58 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by WizKid »

I've noticed that when there's audio playing via CoreAudio, and then launch qemu with the screamer emulation, that whatever is playing in OS X is momentarily clipped for a second. Is this a bug?

It's also funny how it pastes text the same way an AlphaSmart does by emulating a keyboard...
User avatar
adespoton
Forum All-Star
Posts: 3102
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

The clipping is to be expected IMO, due to how qemu is interfacing with CoreAudio.

The keyboard-based clipboard entry is also to be expected as we're trying to do real emulation in qemu -- because otherwise, we'd have to be figuring out what the guest OS is, and then injecting the host clipboard contents into memory. This means the emulator has to know what guest OS is running, or there needs to be a guest driver that interfaces with the emulator to pass the data through. The emulator also has to keep track of things like endianness WRT the guest and host, among other things. But ASCII and UTF-8 don't really change, so as long as you know your keyboard mapping, you can just send the text through the keyboard interface and trust that it'll be at least somewhat legible. Images and audio could be a bit trickier. I haven't looked into how VirtualBox is doing those.
Programmingkid
Apple Corer
Posts: 243
Joined: Sun Jan 31, 2016 6:01 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Programmingkid »

alex195812 wrote:
This is version 2 of the super cocoa.m file. It fixed fullscreen mode not receiving mouse clicks, stops unicode characters from being used by the paste feature, and allows for uppercase characters to be pasted.

http://www.mediafire.com/file/93c1s4v1h ... file_2.zip
The same as above qemu version with extended cocoa added:
https://drive.google.com/open?id=0B69bs ... HZlSGxIWkE
Tested with Panther guest.Full screen clicks OK,pasting text,too.But there's an old issue with leaving full screen and turning back:for example,when you successfully pasted into TextEdit,then go full screen and back to windowed mode,and next try to paste it again,what happens...OMG!I have to reswitch to full screen and back(even few times) to make it calm and even force quit TextEdit for its menu comes unmanageble.
Generally,it's an old bug--mouse and keyboard behave differenlty when you leave fullscreen and return again.I ususally have to do it twice.I think it is due to Alt/Option keys engaged in switching keyboard layouts.Maybe these key combinations should be remapped in the guest not to suffer of this strange behavior or should full screen keys be remapped to,say,Ctl-F
As for 8bit mode it seems it doesn't work with VGA enabled(at least with standard drivers) even when specifyed on command line.In qemu versions without vga it can be specifyed on command line but what you get is black-white thing with inadequate tone.
This mode is desired(besides games) for BeOS to run.Though BeOS seems also not to supporti Mac OS 9.The only way I know to run Mac OS <9.0 in qemu is MacOS.app in MOSX10.0 DP1(emulated Mac OS 8.6).I wonder can BeOS be started there?

In DP1 256 color mode is present in Preferences but defalts to thousands and "Mode switching is currently not supported".Perhaps it can be changed somewhere manually.
Excellent job. The binary works well. Sound works. Resolution switching works. Tested on a Core 2 Duo with Mac OS 10.9.5.

The problem with stuck keys is handled by simply moving QEMU to the background, then bringing back to the foreground. It is a quick fix. I suppose the problem with switching from fullscreen to windowed mode could be fixed by simply sending a keyup event to all keys. This would be like resetting the keyboard.

I do remember 256 color mode as well. It disappeared on us for some reason. Maybe Ben H. would know.
Programmingkid
Apple Corer
Posts: 243
Joined: Sun Jan 31, 2016 6:01 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by Programmingkid »

WizKid wrote:I've noticed that when there's audio playing via CoreAudio, and then launch qemu with the screamer emulation, that whatever is playing in OS X is momentarily clipped for a second. Is this a bug?

It's also funny how it pastes text the same way an AlphaSmart does by emulating a keyboard...
The screamer sound card is definitely not finished yet. The playing of old audio problem is something I encountered also. It can definitely be considered a bug. I will try to fix the issues with the screamer audio card soon.

I think I saw a student using something like the AlphaSmart back in high school during the mid 90's. Must have been a neat toy to have back then.
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

I have found that Ben's version is still more powerful in ability to boot Mac OS 9.0 and 9.04.This new version cannot do that.That is,some Ben's code related to mac99 is still not ported.I wonder what exactly it might be and how to extract and port it...Next to that,go expanding screamer and sungem to Old World and porting mac99p.
As for 256 color mode I've found out that qemu_vga.ndrv from 16.08.2016 doesn't support it while earlier versions do.I've reuploaded the last qemu version I posted with 31.07.2016 version of the driver included(as qemu_vga.ndev).
User avatar
adespoton
Forum All-Star
Posts: 3102
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

Ah; that explains it; I moved my resolution patch to the 16 Aug build to take advantage of some stability fixes he added there. If I get time, I'll diff the two builds and see what changed that could affect the 256 colour mode.
WizKid
Tinkerer
Posts: 53
Joined: Sun Jul 31, 2016 11:58 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by WizKid »

Programmingkid wrote: I think I saw a student using something like the AlphaSmart back in high school during the mid 90's. Must have been a neat toy to have back then.
When I was in high school, I was given an AlphaSmart 2000, then I dropped it too many times and it died.

So I was given another 2000 and the same thing happened. So then I was a given a 3000, and was told if it happened again, that was it.

I never dropped the 3000. I did use the infrared feature of the 2000 to print to a printer with an infrared port once.

Those printers were very rare then (1999-2003) and are nearly nonexistent today...
WizKid
Tinkerer
Posts: 53
Joined: Sun Jul 31, 2016 11:58 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by WizKid »

adespoton wrote:Ah; that explains it; I moved my resolution patch to the 16 Aug build to take advantage of some stability fixes he added there. If I get time, I'll diff the two builds and see what changed that could affect the 256 colour mode.
I tried the older qemu VGA driver (the one from July), and 256 colors works fine.

As an added bonus, the older driver makes the emulated Mac OS boot up faster and run smoother.

Sound doesn't crackle in games or other apps. Only with QuickTime. Tried with Bonkheads.

The only problem is qemu spikes to 72-105% CPU usage when playing games such as Bonkheads, causing severe keyboard input lag and higher levels impossible to complete.
This is with using the USB mouse device. Removing the USB keyboard device makes input lag a little less, but the problem it still there.

Also, the keyboard will sometimes randomly not respond to keypresses with such high CPU utilization.

When at the main screen of Bonkheads, CPU usage is 101.5%.

When in a level of Bonkheads, CPU usage is 105%, while at the highscore screen it's 72-76% CPU usage.

In SimCity 2000, all is fine except menus open slowly and CPU is again at 99%.

In Lemmings, once you get past the first level the mouse can't click anything, and again 99%+ CPU usage.

I think the CPU usage and the goofy keyboard behavior are linked. Seems that it might be related to this:
Trying to write invalid spr 0 (0x000) at 00f113c0
Trying to read invalid spr 0 (0x000) at 00f113c8
Trying to write privileged spr 955 (0x3bb) at 00f168c8
Trying to write invalid spr 959 (0x3bf) at 00f16930
Trying to read invalid spr 959 (0x3bf) at 00f16938
Trying to write invalid spr 944 (0x3b0) at 00f1694c
Trying to read invalid spr 944 (0x3b0) at 00f16954
Trying to write invalid spr 951 (0x3b7) at 00f16960
Trying to read invalid spr 951 (0x3b7) at 00f16968
Trying to write privileged spr 955 (0x3bb) at 00f168c8
Trying to write invalid spr 959 (0x3bf) at 00f16930
Trying to read invalid spr 959 (0x3bf) at 00f16938
Trying to write invalid spr 944 (0x3b0) at 00f1694c
Trying to read invalid spr 944 (0x3b0) at 00f16954
Trying to write invalid spr 951 (0x3b7) at 00f16960
Trying to read invalid spr 951 (0x3b7) at 00f16968
A lot of those seem to be related to the Blue Box layer of the nanokernel amd the 68k emulator built into the Mac OS ROM.

Seems that Qemu is not implementing some PowerPC Special-Purpose Registers (SPRs).

After quitting Bonkheads or SimCity, shortcut keys (like Command-Q) don't work at all until restarting the VM.

If you would like, I could upload a video of this problem.

I've tried apply the patches from mcalyand's screamer branch to qemu-master via dry-run and am having a hard time.

Hence it would be nice to have a GitHub repository, a zip file of such, or a patch against qemu 2.8.0.
User avatar
adespoton
Forum All-Star
Posts: 3102
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

All makes sense; using usb mouse and keyboard means that all HID I/O is being handled by the same CPU that's pegging, which means those signals have to wait their turn. I think the only fix for that is to implement the SPRs.

I agree that we need a github repo where we can mess with all this.
WizKid
Tinkerer
Posts: 53
Joined: Sun Jul 31, 2016 11:58 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by WizKid »

adespoton wrote:All makes sense I think the only fix for that is to implement the SPRs.
I agree that we need a github repo where we can mess with all this.
According to this post on the OpenBIOS mailing list, the SPRs are as follows:
It is probing if the hardware has these registers here. Nothing is wrong.
We discussed this on irc for the gsoc thing...

> 944 Monitor Control Register 2
> 951 Breakpoint Address Mask Register1
> 955 Sampled Instruction Address 1
> 959 Sampled Data Address * PowerPC 604 only

944 = MMCR2
951 = BAMR
955 = SIAR
959 = SDAR (not just 604, fwiw -- where did you read that?)

Yes. And 0 is MQ (a 601 thing), etc.

Some CPUs have slightly different names for the same thing (prefer SIA
to SIAR, etc.; some have different things at the same SPR #. What OS9
is doing here isn't exactly correct, but it is what it is.
So it's just probing to see what CPU it's running on.

The question is if any of those registers apply to the 950/7447/7457, which QEMU emulates.

Obviously we can fake register zero so it returns nil or something.
User avatar
adespoton
Forum All-Star
Posts: 3102
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

If I understand correctly, what's happening is that the code checks the SPRs, and based on the result (which I believe is already nil in qemu for at least some SPRs?) it chooses the appropriate code path. So getting nil is flagging that those features aren't available, which causes a longer code path to be taken -- possibly switching to 68k code emulation in some places. In the software mentioned, that would mean that the code execution is taking a very sub-optimal path, that may include 68k emulation, when it doesn't actually have to.

Not positive about this though; if someone can confirm or deny, I'd feel happier :)
alex195812
Mac Mechanic
Posts: 169
Joined: Mon Aug 29, 2016 3:44 am

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by alex195812 »

I've tried apply the patches from mcalyand's screamer branch to qemu-master via dry-run and am having a hard time.

Hence it would be nice to have a GitHub repository, a zip file of such, or a patch against qemu 2.8.0.
Surely,the patches cannot be applied mechanically for they were made for another qemu version.Me,for I've never been a developer,I don't know how to create patches correctly.Some ealier in the topic I posted the files I had changed,and here is the whole zipped repo I use(make clean;make distclean done):
https://drive.google.com/open?id=0B69bs ... HAwSkRGZ1U
Includes also ProgrammingKid's cocoa.m.Some(not all) orginal files backed-up.

I have met a strange thing with Mac OS 9 booting.It appears that qemu version I work on is compatible with ozbenh openbios versions and can boot Mac OS 9.0/9.04 with them.I can build unmodifyed ozbenh tree and everything's OK.But after adding screamer support(only additions,no deletions in two files) the yeilded binary becomes unable to boot OS 9.0/.04 neither with Ben's qemu version nor mine.At the same time it brings vga+sungem+screamer support with my version and mac99p support with Ben's.Strange...Other OSes seem not affected,only 9.0.How can it be so?For some reason I can't get all 4 features(OS 9.0 boot,screamer,vga and sungem) simulataneously...
User avatar
adespoton
Forum All-Star
Posts: 3102
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by adespoton »

If you set up a repository on GitHub, you can just run a diff against two code bases, and it will automatically generate the diff file for you. A Diff file is essentially a patch file, as it shows what has to change for each file in the tree to turn one into the other. Makes it easy ti disable patches that you *don't* want to port, as well.

[edit] If we generate a diff, it should reveal all the changes, which might help us isolate what's breaking 9.0 emulation.
WizKid
Tinkerer
Posts: 53
Joined: Sun Jul 31, 2016 11:58 pm

Re: GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

Post by WizKid »

adespoton wrote:If you set up a repository on GitHub
The only problem is that the zip file posted above (if that is indeed his local repository) is not a valid git repository according to SmartGit (a Java git client).

Sure, one could do 'git init' on the repo and create one, but the changes as compared to 2.8.0 wouldn't be logged as commits.

Yes, I've downloaded the zip and extracted it as the directory "qemu-alex-vga". My full directory listing is:
openbios-master
openbios-mcayland
openbios-ozbenh
qemu-master
qemu-mcayland
qemu-ozbenh
qemu-alex-vga
All except 'qmeu-alex-vga' cloned via git. I wonder what openbios branch he used, mcalyand's?

Another wish would be to get rid of all the Carbon calls in 'cocoa.m' and to add the patch 'ppc-Add-programmer-switch-hooked-up-to-NMI.patch' from ozbenh's branch so we could enter MicroBug to get out of tough situationsm short of a hard shutdown by quoting qemu due do a corrupt pointer stack.

I'm thinking of the infamous 'SM 0 A9F4<cr>G 0' trick.

Seems like the patch would have to be modified to be dependent on the CONFIG_GPIO_KEY/gpio_key.c option. After all, one doesn't duplicate what already exists: :)

And the patch itself could be a config option, such as CONFIG_PPC_NMI_DEUBG.

As a side note. remember how 64-bit Carbon was ready to ship but was killed at the last minute by Jobs? Cook would have never ordered that to happen.
Post Reply