Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

[tmoran@bix.com (Tom Moran)]

  The 8253 tick rate was 1/4 of the 4.77 MHz of the original PC,
which was 1/3 the 14.31818 MHz rate of cheap color TV crystals.
The interrupt occurs when the 8253's internal 16 bit counter hits
zero, so the maximum delay between interrupts is 2**16 internal
ticks.  12/14.31818*65536= 54.925 milliseconds.  DOS, et al,
increment a four byte counter on the interrupt, so the lower two
bytes generate a carry to the upper two every 0.054925*65536=
3599.56 seconds.

  If the 8253's internal count is set to start at less than
maximum, it will reach zero sooner and interrupt sooner.  If the
program reads the 8253's internal count, it can append those two
bytes to the right of the software 4 bytes, giving a counter with
12/14.31818= 0.838 mics resolution.  Windows'
QueryPerformanceCounter does this on PC compatible hardware.
There was no such system call in DOS; you had to program this
yourself.  Most programs, including most Ada.Calendar.Clock's,
use the low-res Time system call, so they get the interrupt
count, which only changes every 55 ms.  It's easy enough to make
your own Ada.Calendar.Clock that reads the high-res
software+hardware time, but some Ada run-times may not use
Ada.Calendar.Clock internally, so 'delay' might not use your new
high-res Clock.

  Win95 has a system call to release the CPU until a certain time.
That time has a 55ms resolution.  So, without fancy footwork, you
can't get interrupts with smaller resolution.  I think NT sets
the interrupt time to 10ms.  Of course, if the system decides to
flush the disk cache or something, it may be quite a bit longer
before you get the CPU.

  If you have control of the hardware, eg DOS, you have freedom
to poll without worrying you're slowing Solitaire, or to change
the interrupt rate, or whatever.