Here is beta 2 of MacQEMU 2.0: http://www.mediafire.com/file/7parvyzvd ... beta_2.zip

Works nicely now. Here are my first impressions.

I think it is a bit slow in showing the Qemu window. I sometimes think it has not started. There seems no feedback when things do go wrong in e.g., the additional arguments. And there is no way of knowing you best use e.g., -M mac99 to boot the currently supported versions of MacOS

The sendkey editor is nice. I had to find out it is configured on a per machine basis.
I noticed my additional argument -prom-env "boot-args=-v" for OSX did not get picked up, while -g 1024x768x32 was picked up.

Perhaps an addition to pre-select the screen size would be nice?

I also noticed that when I choose Use Real Optical Media I cannot undo that choice without deleting the line manually. There is no menu option to set it back to "none".

Additionally, I noticed when trying to boot manually using the generated command line:
-qemu warned me of not providing a format for the disk.
-qemu reports there is no disk in the drive when I use the "use real optical media" in OSX host.

Qemu also doesn't come up when I use Use Real Optical Media from your tool.

But overall: very neat!


Best,
Cat_7

correction, I have a G4 Power Mac. Should be a 400 or 450MHz one.

What are you using to create the app bundle? https://py2app.readthedocs.io/en/latest/ ?

I'm thinking that it could be useful to keep the wxpython window running a la VirtualBox with some controls in it to stop/pause emulation as well as do snapshots. This should be doable by getting the python app to communicate with the monitor.

Also, both the python app and the qemu window loaded in the background for me; you can intentionally bring them to the front as part of code execution. If you don't have the code for that handy, I'll look it up; I use it in my qemu launch bundles (it goes at the end of the shell script).

I have noticed the QEMU not starting on time problem.
The additional arguments issue should be easy to fix.
Maybe a drop down menu control should be added that allows the user to choose between beige g3 and mac 99 machines.

Glad you like the sendkey editor. They originally weren't on a per configuration basis. One list was used with all configurations. I changed this when I realized using Control-Alt-Delete on Mac OS X was not very useful.

Given how we could just replace the OpenBIOS and vga.ndrv files give full resizing ability to the guest, this feature might not be needed. I do intend on distributing these files with MacQEMU in the next beta.

The -g option is good for setting the initial size of the screen so maybe it should be added to the guest.

Ok, I will make it so there is a none option that automatically deletes the old text.

I always ignore the raw format warning.
When starting up, be sure there is a disc in the optical drive before launching QEMU.


I will investigate this issue some more.


Thank you very much for your help.

I am actually making the application by hand. I did try py2app and was very disappointed with the results. A simple Hello world program using the Tk GUI framework would make an application that was 80MB in size. Way too big! I thought about how a lot of the Python and TK files were bundled with the application. I asked myself, if this was a java application, would I want to bundle the entire Java Virtual Machine in the application? The answer was a no. So now I expect the user to supply the requirements.


Actually I don't know wxpython. The TK framework was used instead. I orginally wanted this application to be the GUI to QEMU, but I didn't know how to display QEMU's video output. I tried using remote frame protocol, but it was too hard to parse. As for being able to do snapshots, I could just add the code to the cocoa.m file that saves and restores the state of QEMU. Be warned that this feature doesn't usually work. I think Mark Cave-Ayland was working on a fix for it a long time ago. He called it migration support. Have you tried saving and restoring QEMU's state using the monitor? If so, does it work?

Yes I will add code in the next release that brings the python application to the front.

Ah; I moved from Tk to WxWidgets in the late '90s. It almost became the official widget kit for Python, but was missing some support/behaved differently on Mac OS (classic) back then, so Guido decided to stick wtih Tk. As soon as OS X came out, WxWidgets was ported, which *should* have spelled the end of Tk, but the 2.x stream of Python was already well underway, so switching toolkits mid-stream seemed like a bad idea.

I've tried saving and restoring QEMUs state using the monitor and had success, when I had already flushed the write buffers and paused emulation. Mostly I was using disk snapshotting, more than full emulation snapshotting, which I've never got to work reliably. I've been waiting for Mark's fix to try full state saving again.

Wow, you have a lot of experience. I went from Apple's Cocoa framework to Tk and was really impressed by how easy it is to use. Building any GUI from code in Cocoa is painful. Tk's built in layout managers make it almost as easy to use as Interface Builder. Which one do you think is easier to use: Tk or WxWidgets?


I would not want someone to use the save state feature only to find out it failed on them and lost all their work. Otherwise adding a few more menu items to the Cocoa front-end is easy to do.

Tk is easier for basic placement, although in a complex project it can get unwieldy if you've got a lot of relationships to map. WxWidgets is more powerful and enables a more native interface. Like Tk, it is available on most platforms, and uses native elements instead of yet another widget interface.

For management of an existing project, I find Wx easier to use, but nothing beats Tk for rapid development.

I was wondering which Mac build of Qemu had 256 color support? Trying to test out a game but it requires 256 colors. Thanks!

If feels like this option up and left in the middle of the night. I don't have any idea why.

Did that ever make it into the official release? I thought it was only available in the VGA build from last August. It's possible it is in 2.7 as well; definitely isn't in official 2.8.

From what I gather from the developer mailing list and following some repo's on github:

Work is being done on the vga driver right now. Openbios will get the ability to load drivers. A build from the relevant new branches (openbios and qemu needed) does not support 256 colours. Perhaps we can make support for 256 colours an issue.

Those development branches also include support for the virtio block driver, which at first glance looks like it might increase overall speed by improving disk access.

There was also considerable effort put into fixing several recent issues with SDL.

Best,
Cat_7

My current wishlist (in descending order) is:
OpenBios driver support (now that I compile my own custom VGA drivers)
virtio support
sungem support
screamer support
Improved FPU virtualization
Improved OpenGL passthrough
ATi Rage virtualization
stable snapshotting

Hi,

Mac OS support in qemu could benefit from a virtio driver for disk access. The driver could be loaded from openbios, just as the vga driver can currently be loaded.

https://github.com/mcayland/openbios/co ... 23eae862b2

The virtio-blk seems a fairly simple device so writing a driver shouldn't be that hard, however it would need someone with CodeWarrior etc. set up and enough knowledge of the Mac SDK to write a PCI device driver.
It's very similar in operation to the MOL disk driver so it should give a very nice speed increase, but it does need someone to write the NDRV.

Any takers?

Best,
Cat_7

I have the IDE set up for working on the VGA driver, and I think I've got enough knowledge to write a PCI device driver, but at the rate my projects are going, it'll be 2030 before I found time to complete it.

If anyone else feels like scratching that itch, I'd be happy to help get them set up and provide advice when needed.

This does not work on my computer. it can't find libgtk-something. I tried to install libgtk with homebrew and macports and it still doesn't work

That is odd. MacQEMU includes libgtk-3.0.dylib. What version of Mac OS X are you using? Could you send the error message? It will be located in the Console application.

I was talking to the Openbios maintainer about VGA resolutions. His idea is to only supply a couple of built-in resolutions and one resolution the user specifies with the -g option. I think he wants these built-in resolutions only:
640x480,
800x600,
1024x768
1280x800
1440x900
1920×1080.

My idea was to make a new command-line option that allows the user to add as many resolutions as wanted. I was wondering what the community wanted. Please let us know what you want.

The ability to load a Fcode option rom, with it's own NDRV would be helpful. As it is now Openbios will load an NDRV, but won't phrase an NDRV from an option rom.

I'd like the ability to load an Fcode option rom as well, and possibly a custom resolution from the command line, like what we hacked together last summer. The default resolutions listed look fine.

I usually run it in 1280x720.

can mac qemu work for windows?

Not quite sure what you're asking. If you run qemu-x86 or qemu-ia64 on OS X, it can run Windows if you give it the correct BIOS image. This *should* work when running qemu on PPC OS X as well, although that version is rather old; I'm not sure if 2.8 builds correctly on Panther/Tiger.

However, this thread is specifically talking about qemu-ppc, which emulates PPC hardware such as New World Macs. Since Windows doesn't run on PPC hardware, it doesn't run on qemu-ppc.

Sorry MacQEMU 2.0 only runs on Mac OS X.

For the longest time we suspected something was wrong with QEMU. It would not play sound correctly under a Mac OS guest. We only had theories that we could only wonder about. Now we can finally see what is wrong. I would like to introduce risu to everyone. Risu is a program that can test each PowerPC instruction in a random order with random inputs. The state of all PowerPC user registers is compared to a real PowerPC chip to see which instructions are working correctly and which do not.

The command line program is a little challenging to use so I made this front end to make it a lot more user-friendly.

https://goo.gl/photos/WQW4v44AViNVGQpX8

To use it just launch the frontend.py file like this from the terminal: python frontend.py

How things work are you generate a file that contains all the PowerPC instructions to test, then run the test.

To generate the instructions, just enter a number in the number field. I suggest 1000. Then push the generate button. In the terminal you will see all the instructions that will be used printed out. What you do next is actually run the test. One real PowerPC Macintosh is required. The master is the PowerPC Macintosh, the host is QEMU. On the master system with the Risu Front-End running select "master" in the Test section. An ip address will appear in the IP address of master text field. You would enter this address into the corresponding text field of the QEMU system that would also be running the front-end. On the QEMU end select "host". Next you push the start button on the master first, then on the host. In the terminal of the master you will see the result of the test. To see each instruction in hexadecimal printed while being tested, check the "Verbose testing" option.

In the future I hope to see a "replay" feature implemented in risu that would allow the user to test QEMU's PowerPC implementation without the need for a real PowerPC Macintosh. But for now a computer that runs qemu-system-ppc and a real PowerPC Macintosh is required. The front-end needs Python and the Tk framework which Mac OS 10.4 or higher supplies. If you don't have python and the Tk framework installed, then you would have to use the command-line programs risugen and risu from the terminal. This is how you should use them:

./risugen --numinsns 1000 ppc.risu ppc.out
./risu --master ppc.out <---- on real PowerPC Macintosh
./risu --host <ip address of master> ppc.out <---- on qemu-system-ppc

The included readme file has more information.

During testing I did verify that many floating point instructions were incorrectly implemented. I wanted to exclude these problem instructions from the test so I entered them in the "Exclude Instructions" text field like this: "fdivs, fctiw, fdiv, fsub". Then I push the Generate button to make a new batch of test instructions to use. The instructions entered in the "Exclude Instructions" text field were not used in the new batch.

If you want to test one or a few instructions only, you would enter them in the "Only Instructions" field like this: "add, addi, addis". The instructions are comma separated.

Networking your computer that runs qemu-system-ppc to your PowerPC Macintosh is a requirement. Connecting both computers to the same router should be enough to put both computers on the same network. Be sure QEMU and the PowerPC Macintosh have the same network mask. This can be verified from the Network Pane in the System Preferences. QEMU also needs to have a network interface card. I used the RTL8139.

Another option is to use a crossover cable to connect your PowerPC Macintosh to your computer running QEMU.

If you need any assistance please let me know. Thank you.

risu download link: http://www.mediafire.com/file/4a0e3jdwj4j87hc/risu.zip

Note: be sure to compare the same processors together. That would mean comparing a PowerPC G3 to QEMU with the "-cpu 750" option selected. When I compared a real PowerPC G5 with a real PowerPC G3, there were differences detected. Particularly the floating point instructions.