#: 11563 S10/OS9/6809 (CoCo)
    31-Jul-91  23:55:53
Sb: #Timer Thoughts
Fm: PaulSeniura 76476,464
To: Kevin Darling 76703,4227 (X)


The second Timer article update is a very watered-down (or boiled away) set of
ideas we ended up discussing on Delphi.  I didn't include the whole history and
the entire reasoning behind those three ways of supporting the timer.

And there's nothing vague about our ideas whatsoever.  I ended up stating how
we want to make the SVC support games and MIDI and whatever else would need a
Programmable Timer interrupt.  That's the crux of our project right there.

We don't want a constant cycle interrupting all the time -- the 60-Hz vertical
sync interrupt is for that.  We want a programmable-length delayed one-shot IRQ
and the quickest way to kick in the user task's "timer pop" routine.

If some program calculates the need for a 0.045-second delay, for example, the
12-bit timer can give us incredible accuracy compared to counting 60-Hz VIRQs
(the way those Sierra games do it; I studied Bruce Isted's VRN sources).  The
number of 60-Hz pulses for a 0.045-sec pause turns out to be 2.7.  But you
can't count 0.7 pulses, and that's where the inaccurate timing can be fixed by
using the 12-bit timer.  If we count 2 VIRQs, that's almost a -26% error;
counting 3 VIRQs has a +11% error.  And those errors will be cumulative as the
program continues to time things that way.

Using 63.5-microsecond resolution of the 12-bit timer, we would set a 0.045-sec
delay this way:  That turns out to be 708 or 709 units, and that's the number
to poke into the timer register after setting the IRQ flags on.  It produces an
error of less than 0.1% (that's one-TENTH of 1%).

This lets the program continue generating whatever it needs to accomplish the
"next" time, i.e. after the timer pops, without wasting CPU resources to count
VIRQs.  Since we want a one-shot effect, immediately after it pops, the SVC
must turn off those IRQ flags before making OS9 kick in the user task's code.

..

There is 1 Reply.