Okay, folks, I accidentally may have mislead some of us about
some of the timing issues on a P.C.  I will try to be brief, but clear
things up.

        The real-time clock updates every 55 milliseconds, all right.
When one boots DOS, the timer/counter that generates the interrupt
actually generates it at 55 milliseconds, also.  Then things can get
interesting.  The hardware interrupt ISR has a vector in low memory
along with many other such vectors that lets one put new ISR's in
which reroute the flow through your new ISR and then to what was
originally there.  This is typical ISR protocol anywhere.  One neat
thing that programmers can do is to set the deviser latch in the
timer/counter to some lower value so that the timer ISR rolls over
much more often such as 1,000 times per second.

        Now, if you want the rest of your computer to continue working
properly, that new ISR must call the ISR which is next in line every
55 milliseconds so the new ISR only does this every 55TH call.  The
rest of the time, it just does its thing and then exits with an iret.

        BASICA is reported to step up the timer hardware interrupt to
4 times the 18.2-HZ rate in order to make music routines run more
smoothly.

        All this is real nice, but it can only work if you control
everything that is run on that computer and the order in which it is
installed.

        There are recommended methods for installing custom routines
so that terrible things don't happen, but in the cowboy code world of
Windows, there are no guarantees and the 55-MS ticker is the only sure
timing constant without resorting to more cowboy or hotdog code and
its almost certain consequences.  All it takes for a grand mess is for
your timer modifier to somehow get installed in the wrong place in the
chain (such has happens if you run some other program with a timer
modifier), and your system is hosed.

Martin McCormick