GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

[Programmingkid]

If the save state feature actually works, maybe it is time to add save state menu items to QEMU's interface.

Well that was an interesting discussion on the mailing list. Case closed
I see the issues about command line reconstruction and hot-plug history, migration etc.

But why not add a simple way to access what is already there through the compat monitor?
Does adding these options to the gui mean that the user will/can expect more (stability, fail safe?) than what is available now on a command line? Now the discoverability and responsibility are placed at the user end.

If these issues are really holding back inclusion in the GUI, then perhaps the options to save and load vm states should not be in compat monitor (or qemu for that matter) at all.

Just my two cents.

Best,
Cat_7

Yeah there's quite a bit of history here... basically the newer QEMU-internal QOM APIs allow you to create a "blank" machine and then plug in devices using -device on the command line to add virtual hardware, and the concept of a machine e.g. mac99 was to preconfigure a default set of devices from a file.

Now the QEMU mac emulation still uses several legacy APIs, e.g. for serial ports which means it isn't possible to represent the entire machine in this way would be the requirement for this to work. Then again I'd much prefer to have a warning stating the user is responsible for using a compatible machine to least make the functionality available which should work just fine as long as you don't start adding extra -device options other than the defaults onto the command line.

Also I did work on this before and the loadvm/savevm code isn't quite right for the PPC mac machines yet - I posted a patch set at https://github.com/mcayland/qemu/commit ... advm-cpu-3 which fixes up Darwin/OS X but wasn't able to get agreement on how to migrate the timebase which is why I wasn't able to upstream it.

I was under the impression this was done. If any of us can help let us know.

[mcayland]

What if the AWACS driver or some decoder uses floating point operations? The sound would still not play correctly.

If the decoder uses floating point instructions then that work will still need to be done before it gets to the hardware regardless, so all your USB audio tests have done is reduce the extra floating point operations used to actually emit the sound (and even then, I am still suspicious that you're hitting an issue with the USB emulation here).

Assuming that AWACS is standard register-based hardware, the resulting (integer) register values should be going straight to the hardware without any additional floating point work which should at least match what you saw in your preliminary USB test, and hopefully surpass it since you also no longer have to worry about the extra USB overhead.

[Programmingkid]

What if the AWACS driver or some decoder uses floating point operations? The sound would still not play correctly.

If the decoder uses floating point instructions then that work will still need to be done before it gets to the hardware regardless, so all your USB audio tests have done is reduce the extra floating point operations used to actually emit the sound (and even then, I am still suspicious that you're hitting an issue with the USB emulation here).

USB problems could still be an issue. When I played an MP3 on Linux running on pretty much the same mac99 machine that Mac OS X would run on, the audio played perfectly using usb audio. Windows 2000 was able to play an MP3 perfectly thru the usb audio card as well. This doesn't prove that USB emulation is perfect. But I suspect USB emulation might be good enough.

Assuming that AWACS is standard register-based hardware, the resulting (integer) register values should be going straight to the hardware without any additional floating point work which should at least match what you saw in your preliminary USB test, and hopefully surpass it since you also no longer have to worry about the extra USB overhead.

http://opensource.apple.com/source/Appl ... acs_OWhw.h
I found this page on AWACS. It looks connected to the screamer chip. There were no sign of floating point operations here so you may be right.

There are a lot of assumptions that I don't know about yet. Does the AWACS implementation on Mac-on-Linux actually work? If so how well? Are there any licensing issues with QEMU's license? What operating systems would it be compatible with it?

http://opensource.apple.com/source/Appl ... rAudio.cpp
This is the source code to the screamer/AWACS driver. After looking at it, I definitely think speeding up floating-point instructions looks easier. There may be others who are more confortable with working with device registers, so who knows which is easier.

<goes and looks at awacs.c source code from Mac-on-Linux>
https://sourcecodebrowser.com/mol/0.9.7 ... ource.html

OMG The entire source code to awacs is just 198 lines!?! A lot smaller than I thought it would be. Maybe porting awacs instead might be the easier solution.

<throws hands in the air and admits I don't know what to do>

[probninalogadam]

i think next goals are:

FPU - i don't think this can be fixed very soon without considering rewrite in QEMU translation ...
Sound -
Cocoa interface / Q like interface -

[bumper314]

Any progress on this?

[Programmingkid]

Does anyone here have experience with Mac-On-Linux? I was wondering how well its audio worked. Is it able to play an MP3?

[sentient06]

Does anyone here have experience with Mac-On-Linux? I was wondering how well its audio worked. Is it able to play an MP3?

Correct me if I am wrong, but isn't mac-on-linux for PowerPC machines?
In that case it would probably be easier to emulate sound, I reckon, at least the processor should be used without several layers of emulation, yes?

[adespoton]

MoL mostly does passthrough, but it does need to set up virtual hardware I/O. The virtual hardware framework for AWACS is that small chunk of code that's available... all floating point operations are passed through to the host for computation.

Since we've already isolated that a few key floating point operations are what's causing performance issues... I agree, MoL might not really help that much. It will, however, provide a test framework other than USB Audio so we can separate the framework implementation defects from the underlying defects.

[Programmingkid]

Does anyone here have experience with Mac-On-Linux? I was wondering how well its audio worked. Is it able to play an MP3?

Correct me if I am wrong, but isn't mac-on-linux for PowerPC machines?
In that case it would probably be easier to emulate sound, I reckon, at least the processor should be used without several layers of emulation, yes?

Yes, I think mac-on-linux is probably for PowerPC machines only. It could be the case that the awacs sound chip emulation might be only useful for mac-on-linux.

[adespoton]

Does anyone here have experience with Mac-On-Linux? I was wondering how well its audio worked. Is it able to play an MP3?

Correct me if I am wrong, but isn't mac-on-linux for PowerPC machines?
In that case it would probably be easier to emulate sound, I reckon, at least the processor should be used without several layers of emulation, yes?

Yes, I think mac-on-linux is probably for PowerPC machines only. It could be the case that the awacs sound chip emulation might be only useful for mac-on-linux.

Mac-on-linux only runs on a PowerPC Mac running Linux. But as I mentioned, the hardware framework's still sound; it's just that FPU emulation isn't needed, so we're back at square one on that.

[Programmingkid]

Correct me if I am wrong, but isn't mac-on-linux for PowerPC machines?
In that case it would probably be easier to emulate sound, I reckon, at least the processor should be used without several layers of emulation, yes?

Yes, I think mac-on-linux is probably for PowerPC machines only. It could be the case that the awacs sound chip emulation might be only useful for mac-on-linux.

Mac-on-linux only runs on a PowerPC Mac running Linux. But as I mentioned, the hardware framework's still sound; it's just that FPU emulation isn't needed, so we're back at square one on that.

To investigate I tried building Mac-On-Linux on my iMac G5. The error message I saw indicates it doesn't even support the PowerPC G5 processor.

Maybe there is someone out there who has a fast G4 that can tell us if sound actually works on Mac-On-Linux.

[Programmingkid]

There isn't very information on Apple's sound chips out there. I did find this: http://manualzz.com/download/1237515. It has some information on AWACS and the DAV bus.

If anyone else has information about any of Apple's sound chips, please post a link. Maybe we can build our knowledge base to the point we can implement one of them.

[Programmingkid]

i think next goals are:

FPU - i don't think this can be fixed very soon without considering rewrite in QEMU translation ...
Sound -
Cocoa interface / Q like interface -

The Cocoa interface is easy to improve. Right now I have a patch that adds the ability to insert image files as USB flash drives into the guest. Very useful for moving files between host and guest. Adding the ability to save and restore QEMU's state can be implemented as well. A keyboard shortcut patch has been made that provides a drop down menu to access common shortcuts that can be used in the guest. Stuff like Control-Alt-Delete, Command-Option-Esc (force quit), Command-Shift-3 (take picture of desktop) and any others the user wants. Anyone has a request?

Rather than using patches, I will just post the entire cocoa.m file somewhere so it can replace the file that comes with QEMU.

As for sound and FPU, I think the sound will work correctly for audio formats like MP3 once the floating point unit is made faster.

[adespoton]

There isn't very information on Apple's sound chips out there. I did find this: http://manualzz.com/download/1237515. It has some information on AWACS and the DAV bus.

If anyone else has information about any of Apple's sound chips, please post a link. Maybe we can build our knowledge base to the point we can implement one of them.

I think MoL just leveraged the Nubus Linux support: http://nubus-pmac.sourceforge.net/#support

So the information should be in the kernel source for the linux nubus core.

[Programmingkid]

i think next goals are:

FPU - i don't think this can be fixed very soon without considering rewrite in QEMU translation ...
Sound -
Cocoa interface / Q like interface -

The Cocoa interface is easy to improve. Right now I have a patch that adds the ability to insert image files as USB flash drives into the guest. Very useful for moving files between host and guest. Adding the ability to save and restore QEMU's state can be implemented as well. A keyboard shortcut patch has been made that provides a drop down menu to access common shortcuts that can be used in the guest. Stuff like Control-Alt-Delete, Command-Option-Esc (force quit), Command-Shift-3 (take picture of desktop) and any others the user wants. Anyone has a request?

Rather than using patches, I will just post the entire cocoa.m file somewhere so it can replace the file that comes with QEMU.

As for sound and FPU, I think the sound will work correctly for audio formats like MP3 once the floating point unit is made faster.

Ok I have finished my changes to the Cocoa.m file. You can download it here: http://www.mediafire.com/file/9rohbhsdni049ra/cocoa.m

To use it, just replace your old version of ui/cocoa.m with this one.

It has the menu items for loading and unloading an image file as a USB flash drive under the Machine menu.

To use the Send Key menu, just add this to your command line: -sendkeymenu Command-Option-Esc:0x37,0x3a,0x35:Command-Power:0x37,0x7f7f:Power:0x7f7f:Command-Shift-3:0x37,0x38,0x14:Command-Tab:0x37,0x30

The format is -sendkeymenu <title for menu item>:<hex values for the keycodes to send to QEMU separated by commas>: ...

The save state feature does not work in QEMU very well. Mac OS 10.4 would not do anything after I restored the state. Maybe some day all the patches needed to make this feature work will be implemented.

I am debating on whether there should be a USB menu. The items it would probably have are:
Add Keyboard
Add Mouse
Add Sound
Add Network
Add Tablet

The "Add" would change to "Remove" when the user selects the menu item.

I'm always accepting requests for features.

[Cat_7]

Hi,

Those changes work nicely. Finally a way to get into the debugger!

I am debating on whether there should be a USB menu. The items it would probably have are:
Add Keyboard
Add Mouse
Add Sound
Add Network
Add Tablet

How would that work? Are these hot-plugged?

Best,
Cat_7

[sentient06]

Ok I have finished my changes to the Cocoa.m file. You can download it here: http://www.mediafire.com/file/9rohbhsdni049ra/cocoa.m

That's nice. But won't the changes eventually become outdated? Do you apply similar changes with every version as necessary? What if you create a repository only to keep these features updated and people can use as a submodule?

[sentient06]

I'm always accepting requests for features.

Programmingkid, I use a lot of hot corners in my host Mac OS, but sometimes I would like to use hot corners in the virtual machine too. I have this problem with VirtualBox and Parallels where I go full screen and I accidentaly trigger a hot corner action. Is there a way of making some sort of toggle? I imagine a keyboard shortcut that will do something like mouse capture/release. Perhaps the mouse capture in the guest OS already solves the issue, but would be really cool to simply release the mouse, move to another space, do something, then return and capture the mouse again. Then use hot-corners and whatever I want in the guest machine.

And maybe, I don't know how difficult or off track that would be, a drag & drop file transfer functionality? I know that stuff like Parallels and VMWare, they have a guest application running, so it knows what the target is, but if we could simply copy files into the desktop it would be a massively welcome improvement. Maybe if we could connect an external application that uses something like HFSUtils.. so the emulator simply passes the filepath forward and that application gets the copy done. Well, there is a problem with the disk image being used, so perhaps we need a guest application anyway...

Multiple display support would be awesome too. It could be division in several windows in the host machine, each window being a display. Perhaps that's even more complex than the previous ideas. Is it?

This is just a small brainstorm moment, if these are too crazy or somehow already implemented/operational, please don't mind it. =D

Cheers!

[Programmingkid]

Hi,

Those changes work nicely. Finally a way to get into the debugger!

I am debating on whether there should be a USB menu. The items it would probably have are:
Add Keyboard
Add Mouse
Add Sound
Add Network
Add Tablet

How would that work? Are these hot-plugged?

Best,
Cat_7

Selecting "Add Sound" would be like plugging in a USB audio card into a computer. Selected "Remove Sound" would be like removing the USB audio card from the computer. It would work the same way for all the other menu items.

Yes, these are all hot-pluggable.

Does anyone want a USB menu?

[Programmingkid]

Ok I have finished my changes to the Cocoa.m file. You can download it here: http://www.mediafire.com/file/9rohbhsdni049ra/cocoa.m

That's nice. But won't the changes eventually become outdated? Do you apply similar changes with every version as necessary? What if you create a repository only to keep these features updated and people can use as a submodule?

It is possible the changes will become outdated, but if they do I can always update them. I do a 'git pull' about every week. If something breaks, I can always update the file and upload it again.

A repository would be a little more difficult to use than what I have setup now.

[Programmingkid]

I'm always accepting requests for features.

Programmingkid, I use a lot of hot corners in my host Mac OS, but sometimes I would like to use hot corners in the virtual machine too. I have this problem with VirtualBox and Parallels where I go full screen and I accidentaly trigger a hot corner action. Is there a way of making some sort of toggle? I imagine a keyboard shortcut that will do something like mouse capture/release. Perhaps the mouse capture in the guest OS already solves the issue, but would be really cool to simply release the mouse, move to another space, do something, then return and capture the mouse again. Then use hot-corners and whatever I want in the guest machine.

It sounds impossible. The host will always see the hot corner actions first and handle them. You could assign one hot corner to the guest and another hot corner to the host.

And maybe, I don't know how difficult or off track that would be, a drag & drop file transfer functionality? I know that stuff like Parallels and VMWare, they have a guest application running, so it knows what the target is, but if we could simply copy files into the desktop it would be a massively welcome improvement. Maybe if we could connect an external application that uses something like HFSUtils.. so the emulator simply passes the filepath forward and that application gets the copy done. Well, there is a problem with the disk image being used, so perhaps we need a guest application anyway...

This would be an awesome feature! The hardest part would be making a driver for the guest that detects the drag and performs an action. I think QEMU would have to write the path of the file into guest memory. Some place that a driver is monitoring for changes.

Multiple display support would be awesome too. It could be division in several windows in the host machine, each window being a display. Perhaps that's even more complex than the previous ideas. Is it?

I have never thought about multiple display support for a guest operating system. It is an interesting idea. I will ask the VGA maintainer about this feature. See what he has to say.

This is just a small brainstorm moment, if these are too crazy or somehow already implemented/operational, please don't mind it. =D

Cheers!

Great ideas!

[adespoton]

I'm always accepting requests for features.

Programmingkid, I use a lot of hot corners in my host Mac OS, but sometimes I would like to use hot corners in the virtual machine too. I have this problem with VirtualBox and Parallels where I go full screen and I accidentaly trigger a hot corner action. Is there a way of making some sort of toggle? I imagine a keyboard shortcut that will do something like mouse capture/release. Perhaps the mouse capture in the guest OS already solves the issue, but would be really cool to simply release the mouse, move to another space, do something, then return and capture the mouse again. Then use hot-corners and whatever I want in the guest machine.

It sounds impossible. The host will always see the hot corner actions first and handle them. You could assign one hot corner to the guest and another hot corner to the host.

And maybe, I don't know how difficult or off track that would be, a drag & drop file transfer functionality? I know that stuff like Parallels and VMWare, they have a guest application running, so it knows what the target is, but if we could simply copy files into the desktop it would be a massively welcome improvement. Maybe if we could connect an external application that uses something like HFSUtils.. so the emulator simply passes the filepath forward and that application gets the copy done. Well, there is a problem with the disk image being used, so perhaps we need a guest application anyway...

This would be an awesome feature! The hardest part would be making a driver for the guest that detects the drag and performs an action. I think QEMU would have to write the path of the file into guest memory. Some place that a driver is monitoring for changes.

Multiple display support would be awesome too. It could be division in several windows in the host machine, each window being a display. Perhaps that's even more complex than the previous ideas. Is it?

I have never thought about multiple display support for a guest operating system. It is an interesting idea. I will ask the VGA maintainer about this feature. See what he has to say.

This is just a small brainstorm moment, if these are too crazy or somehow already implemented/operational, please don't mind it. =D

Cheers!

Great ideas!

Hot corners: if you enabled the system scripting addition, you could use it to disable the host hot corners when qemu loaded in full screen mode, and re-enable host hot corners when qemu quits. Actually, I could probably add this into my clickable wrappers right now without much difficulty.

D&D File transfer: On OS X guests, you could probably add a folder action script, and present a host folder as a network share. When a file shows up in the network share, the folder action script could perform some action, like copying it to the guest and deleting it from the network share.

That said: I'd prefer just having BII/SheepShaver's feature of a "unix folder" where you could mount a host folder as a USB drive instead of using an image file.

Multiple windows: This should actually be "relatively easy"; I think most of the code is already in the VGA driver; we just need to pass it the right values for extra screens, and have enough VRAM allocated to manage the displays. If the VGA maintainer doesn't want to be bothered, ping me and I'll try to make time to have a look at this. It will require multiple window management, which is an area I haven't touched before though, so this part may be more difficult.

[Programmingkid]

Multiple windows: This should actually be "relatively easy"; I think most of the code is already in the VGA driver; we just need to pass it the right values for extra screens, and have enough VRAM allocated to manage the displays. If the VGA maintainer doesn't want to be bothered, ping me and I'll try to make time to have a look at this. It will require multiple window management, which is an area I haven't touched before though, so this part may be more difficult.

Looks like nobody has responded to my email. Maybe you might have more success.

[LightBulbFun]

Just a heads up I installed OS X Sever 1.2V3 onto a real computer (a then imaged its hard drive and pointed qemu to that image and much to my surprise it did start booting but it hung just after detecting the ATA devices. I tried a couple builds of QEMU with no avail (all hang in the same place) (also note i had to do 8bit colour otherwise it was all corrupted) now this was with mac99



I just now (like after writing the above section) decided to try g3beige machine option and much to my surprise it booted all the way to the normal login screen! sadly my mouse and keyboard are unresponsive in the emulated machine



just a quick post from me heh hope it all makes sense

[hyoenmadan]

Again, is the same thing that we have commented before. Sawtooth will not do it for older MacOS versions than 9.1.x or 9.0.x with the special Sawtooth Mac OS ROM file "patch". For these older versions you really need a complete Gossamer g3beige emulated in QEMU (or the Yosemite G3 "blue&white", which doesn't exist in QEMU).