RE: [Qemu-devel] How to Simulate hardware that counts scanlines?

[Armistead, Jason]

Steve Ellenoff wrote:

>You misunderstand, I have no control over the running program. I didn't
>write it, I don't have source code, and I surely wouldn't have used a 
>polling mechanism for determining the vblank as you suggested.

>My problem is that I wish to run this program through qemu. I've made a 
>bunch of hardware specific additions to qemu to emulate the specific 
>hardware this program runs on. I'm just not sure the best way to simulate 
>the scanline counting the hardware does.

>Seems nobody here has any ideas either, which is kind of hard to believe. I

>don't know if this would work, but one idea I had was to divide up the gui 
>timer into 260 slices (that's the # of scanlines the hardware expects), and

>simply update the hardware register that counts the scanlines this way.

>Does anyone thing that's the way to go, or if there's a better way?

As I see it, one of the problems in Steve's scenario is that QEMU does
dynamic translations based on blocks of code, and the interrupts or changes
to emulated hardware state are delivered only at the end of the execution of
an entire basic block.  While this might be adequate for an operating system
which cares for the most part very little about real world timing, it may
not be sufficient for every case where you want to do an emulation of a
processor in an embedded device or a curious non-standard PC like Steve's.

I think that's why the game system emulators MAME and MESS are perhaps more
akin to what he's wanting to do, in that they are able to deliver interrupts
in exactly the same way as the real CPU sees them i.e. at the end of
execution of the current instruction, and they consider instruction
execution timing to maintain an accurate internal time base, independent
from what the real world outside is doing.

On most modern fast PC CPUs, they can easily emulate the older arcade game
or computer system hardware with plenty of horsepower to spare, and so it
appears realtime, synchronised via RDTSC or similar.  I guess if you ran
them on an underperforming PC like an old 486 or early Pentium, you may see
things go at less than real speed.

Maybe I'm totally off the mark, but at least that's how I read the QEMU docs
relating to hardware interrupts

http://www.qemu.org/qemu-tech.html#SEC18

and the preceding sections about the way instruction blocks are translated
and executed.

I'm sure Fabrice and others can shoot me down if needs be ... 

Cheers

Jason