[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake

From: Miroslav Novak
Subject: Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake
Date: Tue, 05 Dec 2006 16:54:04 -0000

I'm sending some more facts that should make clear why I think the 
functionality provided by the patch is relevant. (At least for the DOS 

Making emulated CPU slower
  Some old DOS games runs too fast on modern CPUs, even the qemu-emulted
ones. This patch can make these games playable.
  This was reported in http://qemu-forum.ipi.fi/viewtopic.php?t=1264

Energy saving
  MSDOS doesn't use HLT insn. Even if the dosidle can help in command 
prompt, it doesn't work in other programs such as games.
  This was reported in http://qemu-forum.ipi.fi/viewtopic.php?t=1372

The similar approach is used in dosbox by setting "CPU cycles". I think 
qemu is better than dosbox, so it makes sense to me to include such 
capability too. 

This patch doesn't try to emulate the task scheduler that was why Martin 
voted against it. I'm sorry if I wasnt't clear enough in my first post.


On Thu, 30 Nov 2006, Miroslav Novak wrote:

> This patch adds support for slowing down qemu and saving cpu load.
> The '-brake' command line parameter or monitor command 'brake' determines how
> long to wait in the main_loop with respect to duration of time that qemu used
> for the emulation itself.
> Thus e.g. zero value runs at full speed, 1 at 1/2 speed, 10 at 1/11 speed,
> etc.
> A drawback of this approach is that the timer interrupt can be missed if
> raised too often. This happens if the loop_main divided by (1+brake) is less
> than the frequency of PIC interrupts.
> In such case the time of emulated system runs slowly.
> This problem occurs mainly for Linux emulation where kernel parameter HZ is of
> several hunderds.
> For DOS emulation, where the timer interrupts are raised usualy at 18Hz, this
> approach works nice, and one can play old DOS games at reasonable speed and
> save batteries.
> Mirek

reply via email to

[Prev in Thread] Current Thread [Next in Thread]