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

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

[Steve Ellenoff]

[-- Attachment #1: Type: text/html, Size: 1649 bytes --]

[Qemu-devel] Adding a device into Qemu ARM

[Tieu Ma Dau]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

Hi all,
 I'm running Qemu ARM system and Debian Sarge on it.
 I try to add a new device, for example a LED, into Qemu ARM system. And I think that I must do the following steps:
 1. Make a file led.c which simulates this LED, edit the file vl.c and vl.h
 2. In file integratorcp.c, function integratorcp_init(), I must register a MEMORY SPACE for this LED (as the PL011 UART at 0x16000000)
 3. Write a character device driver; this device driver will function on the MEMORY SPACE of the LED device. And this device driver has a MAJOR NUMBER
 4. Make a character device file with the corresponding MAJOR NUMBER: mknod /dev/my_LED c MAJOR_NUMBER 0
 5. Write an application which opens the file /dev/my_LED and write on it (to communication with my LED on Linux)
 OR: for example "echo -n a > /dev/my_LED" to communication with my LED on Linux
 
 I find that some of you who added the devices into Qemu ARM system, but I don't sure the steps I think above is as you 've done or not? Please confirm it for me, thank a lot!
 
 Furthermore,  I have some questions on the steps above:
 + step 2: which interrupt I can register with the PIC? Or in my case, it must not?
 + step 2: which value of MEMORY SPACE I can register for this LED?
 Best regards,
 Tieu
 
 		
---------------------------------
Do you Yahoo!?
 Next-gen email? Have it all with the  all-new Yahoo! Mail Beta.

[-- Attachment #2: Type: text/html, Size: 1507 bytes --]

Re: [Qemu-devel] Adding a device into Qemu ARM

[Paul Brook]

>  Furthermore,  I have some questions on the steps above:
>  + step 2: which interrupt I can register with the PIC? Or in my case, it
> must not? 
> + step 2: which value of MEMORY SPACE I can register for this 
> LED?

Anything that's not already being used. Same way you would if you were 
designing real hardware.

Paul

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

[André Braga]

On 7/27/06, Steve Ellenoff <sellenoff@hotmail.com> wrote:
> The guest os code is polling this register on a very fast interval, and when
> it detects a certain # of scanlines have been counted, it will swap it's
> display buffers, ie, it's waiting for the vblank, so it can have nice smooth
> animations.

Since this is all custom, I'd rather raise an interrupt when the DAC
reaches the final portion of the frame buffer... This has to be better
than polling.

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

[Steve Ellenoff]

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?


>Since this is all custom, I'd rather raise an interrupt when the DAC 
>reaches the final portion of the frame buffer... This has to be better than 
>polling.

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

[Paul Brook]

> 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.

No. The gui timer (in fact the whole display mechanis) is independant of the 
emulated VGA hardware. If you need accurate scanline emulation you just treat 
it like any other timer.

qemu doesn't currenly provide high-fidelity timer emulation, but that's a 
different problem altogether.

Paul

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

[Steve Ellenoff]

Sorry, stupid hotmail default. According to the options I've now turned that 
feature off, so hopefully that won't happen again, but there's no easy way 
to verify it before sending that I can see in hotmail.

-Steve



>From: Paul Brook <paul@codesourcery.com>
>To: "Steve Ellenoff" <sellenoff@hotmail.com>
>Subject: Re: [Qemu-devel] How to Simulate hardware that counts scanlines?
>Date: Thu, 27 Jul 2006 13:42:20 +0100
>
>On Thursday 27 July 2006 04:22, Steve Ellenoff wrote:
> > <html><div style='background-color:'><DIV class=RTE>
><unreadable crud deleted>
>
>Please use plain text email.
>
>Paul

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

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

[Fabrice Bellard]

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
> 
> 

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

[Steve Ellenoff]

That's great news, thanks for letting us know.
Steve

>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.

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

[Steve Ellenoff]

Thanks malc-

Turns out I didn't need it after all. Once I pumped up my RTC Frequency to 
4096 from 1024 (thanks Brad), my 'fake' scanline counting code seemed to 
satisfy the machine and all looks perfect. Thanks for the help anyway, it 
was much appreciated, and may serve useful for future projects.

Regards-
Steve


>From: malc <malc@pulsesoft.com>
>To: Steve Ellenoff <sellenoff@hotmail.com>
>Subject: Re: [Qemu-devel] How to Simulate hardware that counts scanlines?
>Date: Tue, 1 Aug 2006 04:16:32 +0400 (MSD)
>
>On Mon, 31 Jul 2006, 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?
>>
>
>I don't know wether this is applicable or not, but it might help:
>http://www.boblycat.org/~malc/code/patches/qemu/5c_rqemu.patch.gz
>
>Is the patch that does something that sounds a bit like what you
>want. Basically this tries to provide a bit better h/v retrace
>polling support than what qemu orignally does (needed for some
>old DOS applications) Each time guest reads the VGA register
>that contains h/v retrace bits the virtual time is calculated
>and that gives some indication where the beam might be at the
>current point in time, with a bit of tweaking this can report
>current scanline and whatnot too.
>
>--
>mailto:malc@pulsesoft.com