qemu runs too fast

[bob64832]

I realise that most users want QEMU to run as fast as possible, but I do not. I am trying to emulate a DOS PC to play DOS games and on my 2 Ghz PPC G5 QEMU runs fast too fast. I have tried the 'SlowMo' program which will slow down a real PC for the purpose of playing old games, but it does not seem to work on an emulated PC. (I have also tried using the DosBox emulator instead of QEMU, and this does have a speed control, but unfortunately it has the opposite problem - it will not run fast enough!)

How can I control the speed of the emulation?

[stefan.becker]

Probably Bochs is better Choice. In Bochs you can setup the IPS-Value.

[bob64832]

I tried Bochs briefly but it seemed far too slow - it takes 3 seconds just to register each keypress when typing commands into it! I also couldn't figure out how to get it to do fullscreen display - I got the impression they didn't care about OS X support much.

Fortunately I have just discovered a new version of DosBox was released last week which seems to improve performance on OS X so it is now usable. (I can't get midi sound to work properly though.)

It is very odd that every other emulator suffers from being too slow while QMEU suffers from being too fast.

[nkunkee]

It is very odd that every other emulator suffers from being too slow while QMEU suffers from being too fast.

To answer your question, the combination of Qemu and how the game was written cause the excessive speed.

Qemu supports a HALT instruction, which will cause the emulator to "sleep" until an interrupt or somthing else happens, letting the host CPU usage drop to 0. Operating systems that support this will run close to wall clock time. Not all operating systems, or in the case of DOS, video games, use this instruction. Instead, they use a busy loop. Qemu continues executing the busy loop regardless any expected execution delays. The problem arises because the game was written with a specific CPU in mind, and the busy loop was calibrated to that processor. As Qemu, or any other emulator, continues to run the busy loop, events in the game take place, but faster than intended.

To run the game at its expected speed you have to use an emulator that gives you a lot of control over its internal timing. Bochs does have options for this while Qemu does not (right now). Hope that helps

[aus9]

just a thought

give the virtual machine less ram eg

qemu -m 32......should slow down or try 16 8 or go higher?

[pablo]

If you enable profiling, it will slow qemu down a bit. It might not be enough.

Changing "#define TB_JMP_CACHE_BITS 12" from cpu-defs.h to smaller value will slow down the emulation. Busyloop performance shouldn't be affected (assuming translated busyloop fits into translation block). Decreasing translation block size should affect busyloop performance, because more and more busyloops won't fit into translation block. It's OPC_BUF_SIZE, defined in exec-all.h.

[miraz]

Hi,
I've made a patch Qemu Brake which slows down the Qemu and saves CPU usage. It is suitable mainly for DOS emulation.
It is available at http://miroslavnovak.com/qemu-brake.html including a ready to run sample for Linux and Windows. The sample contains an old dos game installed, which demostrates the capability od the Brake patch. Please try it.

[keybounce]

So this lets you slow down to 50%, 33%, 25%, etc.

I'm looking for something in the neighborhood of 66%, 75%. (As fast as possible without triggering the system's heat fan).

This looks like a good place to start, let me see what I can do. Thank you.

[keybounce]

Well, I'm not sure what's happening.

If I apply the patches, and recompile, then it seems to run fine.
But if I activate it, it locks up.

Using Q (kju) on Mac os 10.4.9
Alt-ctrl-2 to enter the monitor
"brake 1" to slow down to 50%.

And then the cpu usage goes to 100%, and no other keystrokes in the monitor are echoed out.

Aha! I see.

Alt-ctrl-2 to enter the monitor: Works
"brake 1" to slow down: Works

If I do "alt-ctrl-1" to return to the program it works

If I then come back to the monitor, it seems to be working.

I can give one monitor command, and it works.

After pressing enter in the monitor, anything other than alt-ctrl-1 will cause a lockup.

I can enter one monitor command per entry into the monitor, and need to leave the monitor (and re-enter) to give another command.

[keybounce]

More:
I can activate full screen while "brake" is zero.
And while in full screen, I can enter the monitor, give a brake command, and return to the program. But as mentioned, I cannot give a second command.

But if brake is non-zero, attempting to enter full screen results in a lockup.

However, this sequence does work:
1. Start with brake 0.
2. Enter full screen mode at the dos prompt
3. Monitor, give "brake 1" command.
4. Return to dos, run cpu hog

And oddly, it's not running at 50%. It's actually running at the right level (about 70%) to avoid the fan while getting as much CPU as possible.

[miraz]

Hi keybounce,
what cpu runs your mac? What is the emulated cpu? Do you use some virtualization like kqemu? What OS do you emulate?
I could test the brake on mac. How to compile qemu on mac? Is it just configure and make or is it more complex? What are the command line arguments for qemu when the problem occurs?
Mirek.

[keybounce]

Mac cpu: G4
Emulated cpu: x86
No virtualization aids.
FreeDos 1.0

Compiling the mac port of qemu: http://www.kju-app.org/proj/wiki/CompilingQ

Command line to run qemu: products/ppc/Q.app/Contents/MacOS/i386-softmmu.app/Contents/MacOS/i386-softmmu -m 16 -brake 0 -soundhw sb16,adlib -localtime -hdb fat:/Users/Michael/Documents/Q sandbox shared files/Installs -cdrom /dev/cdrom -hdd /Users/Michael/Documents/QEMU/xcom.qvm/Harddisk_1.qcow -boot c /Users/Michael/Documents/QEMU/xcom.qvm/HardDisk1Session.qcow2

[keybounce]

Some more feedback:

First, after I give a brake command, the monitor is not completely dead.

If I type very slowly -- with at least one or two seconds between keystrokes -- then it usually works. However, my normal typing speed is pretty fast, and this seems to trigger the cpu lockup.

This is not 100% repeatable -- on occasion, even while trying to type slowly it will lock up. And, while typing fast, it may work. But fast typing is the most reliable way to trigger the lockup.

During the lockup, something really strange is going on. I can hit "ctrl-Z" in Terminal, get a command prompt, and be told "Stopped". But it's still "running", using up CPU time. If I then say "kill -stop %1" (or whatever job number it is), then it actually does stop. Ctrl-Z is enough to get my shell prompt, but not actually stop it.

[miraz]

Hi keybounce,

I tried to reproduce the problems with Q on Mac OS X 10.4.9 i386.
The bug with switching fullscreen occurs there too. But the problem with fast typing in monitor doesn't appear.
I modified the brake patch so, that the brake multiplier is now in percent. I found that when brake is less than 100, e.g. 50, the fullscreen switching works fine.
I currently don't now where the problem is. Also the Qemu in Q application is patched a lot.

The new patch with percentual brake also helps to finetune the CPU usage as you mentioned.
It is available at http://miroslavnovak.com/qemu-brake.html as the last item in the download section.

It was quite difficult for me to get a Mac, I first tried to run the Mac OS on qemu for ppc, then the i386 version on vmware but without success.
Finally I borrowed a Mac from my colleague. When I activated the fullscreen with brake on, the Mac hanged so badly that it has to be powered off. Even if the Q was killed, the Qemu process still run and blocked the screen. Then I always tried the bug when switching from fullscreen. I'm wondering how did you kill the Qemu when it hanged in fullscreen?

I was not able to compile the universal binary of the Q on the borrowed Mac. If you can, please send me the binary.

[keybounce]

Foo, I can't upload the G4 binary (too big).

How did I kill it when it was full screen? Sometimes I could use apple-tab to force it back to another window. Other times I had to power down.

Yes, I see that there's a big list of patches that the build script is applying.

Alright, I got it hosted. The PPC/G4 version, with the old brake patch, is at
http://www.stb.nccom.com/~michael/ftp/Q_brake_ppc.zip

I cannot compile the i386 version. I'm not sure how the official universal is built. If you have both the i386 version, and the ppc version, you can combine them into the universal.