Re: [AD] Retrace Simulator

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Jason Wilkins <fenix@xxxxxxxxxx> writes:
> Does the standard _handle_timer_tick allow reprogramming of the retrace
> simulator.

It returns the desired delay until the next tick, so you can do dynamic 
speed adjustments with it. Sometimes you will need to do more specialised 
processing inside the handler, though, in which case the generic 
implementation is no use.

> _handle_timer_tick is duplicated more or less in many places in code for 
> different drivers, so I get the feeling that my driver is the only one 
> that uses _handle_timer_tick unchanged.

Unix and the DOS i_love_bill mode both use it. The Windows single threaded 
version could also probably do so, but doesn't at the moment. The Windows 
multithreaded timer driver can't use it because it works in a totally 
different way, and the DOS high precision timer can't use it because it 
needs to recalibrate itself by reading the elapsed time at numerous points 
during the processing.

btw. Stefan, a random observation: I noticed that there was no trailing 
carriage return at the end of wtimer.c. You need to watch out for that, 
because diff/patch don't handle it properly.

> It appears that this generic version only does 70 BPS retrace simulation. 
> I believe I can do retrace interupt simulation on the BeOS because I have 
> a function that waits for a retrace and has a timeout. So, I could easily
> write a thread or timer interupt which simulates a vertical retrace
> interupt.

How accurate are your timers, though? You need to be able to trigger this 
poll reliably (ie. without any other threads getting in the way) before the 
retrace, but not too much before it to avoid slowing the whole system down 
too much. In DOS I request the interrupt about 1/2000 of a second in advance 
of when I'm expecting the retrace, which is just adequate even when you have 
sound DMA going on. It will be an impressive feat if BeOS can keep adjusting 
things to that kind of precision in a multitasking OS! a nice option if it 
really is possible...

If you have true triple buffering support in the graphics driver, though 
(ie. some way to request a flip, and then later poll to see whether it has 
taken place yet), it is usually better to use that directly rather than 
bodging it with a timer.

> The problem is that it looks like _handle_timer_tick is locked into 70 BPS
> on incrementing retrace_count. I am loathed to duplicate the timer handler 
> yet again like the DOS and Windows drivers have.

If you only need to run your retrace code before or after the other 
handling, add a parameter to _handle_timer_tick() that can disable the 
retrace emulation. If you need to interleave your code with it, though, you 
are best off duplicating the whole routine. It's only a small piece of code, 
anyway. I did originally try to write this as a single routine that would 
handle both of the DOS timer modes, but the hooks and driver callbacks 
became so complicated, the code actually shrunk a lot when I took them out 
and just rewrote it as two unique versions for the different scenarios.



--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."