Re: [AD] Retrace Simulator

[Jason Wilkins <fenix@xxxxxxxxxx>]

Shawn Hargreaves wrote:

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

Thread scheduling latency/jitter has been improved to 250 microseconds.
If you assign a thread to be real time then it will not be interupted
unless a real time thread of higher priority is scheduled.  This means
that if your code locks up in a real time thread that the entire system
comes to a screeching halt and you have to hit the reset button
(clt-alt-del does not work in this case!)

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

Its pretty easy to make sure that it will be the highest priority real time
thread on the system.  The system itself almost never creates real time threads
and the retrace simulator will be a very high priority real time thread, so it
will own the system when its time to run.

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

I was going to use the vsync function with the timeout to both calibrate the
resync simulator and implement triple buffering seperately.

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

I figured this was the case.  I'll experiment and see if I can implement
these things.  I have not used BeOS enough to be sure that I can really
trust that 250 microsecond latency, but I do know that real time threads
do what they say.  They have taught me I need to use high priority time
sharing threads before I switch to real-time.


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

-- 
           Phoenix -- President of The Artistic Intuition Company
       Caelius * Mirror Reflex * Runica * X-Domain * Infinite Realms
                          http://www.io.com/~fenix