🚀 go-pugleaf

Yesterday I posted:
>In the process of writing a routine to get high-resolution times from the PC's
>timer chip, I wondered at the weird clock rate for the timer chip: 1.193180
>Mhz.  Is that right?  If the clock rate were 1.193046 Mhz, the low-speed
>counter at 040:06eH would tick once per hour.  At 1.193180 Mhz, it ticks about
>1/2 second early (65536*65536/1193180 ~= 3599.597, 65536*65536/1193046 ~=
>3600.001), or about 6 us early per interrupt (65536/1193046-65536/1193180),
>assuming overflow of the medium-speed counter at 040:06cH is intended to tick
>the low-speed counter at 040:06eH once per hour.
>
>The counter in the timer runs continuously, that is, it doesn't stop when it
>generates an interrupt and wait to be restarted, so it doesn't seem reasonable
>that the approximately 6 us per interrupt are to allow for interrupt
>processing.
>
>Also, it seems the only thing one can do if one detects that the timer
>overflow interrupt pending bit is set in the peripheral interrupt controller
>(PIC 0, bit 0) is to pretend the count in the timer chip is 0.  If you
>enable interrupts, do a few NOP's, and start over (which disables
>interrupts), or keep track of the presence or absence of overflow, and add
>that onto the reported medium-speed counter (with carry into the reported
>value from the low-speed counter), the clock occasionally appears to
>run backward by about 20 ms.
>
>Any ideas.

I let a timer program, based on hrtime (Dobbs 1992 sep), which I thought
worked just fine, run all night.  The clock backed up once at midnight
(of course), and once again at about 09:00, about 21.5 ms.  This is not
one tick of the medium speed counter at 40:6c, nor 1/2 tick, which is
27.5 ms.  So does anybody have, or know of, a reliable high-resolution
and moderately long-duration (more than ~50 ms) timer routine?

Thanks in advance.
-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov