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

[Fabrice Bellard <fabrice@bellard.org>]

The next release of QEMU is likely to have cycle exact emulation and 
delivery of interrupts in the middle of a basic block.

Regards,

Fabrice.

Armistead, Jason wrote:
> 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
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
>