Path: utzoo!news-server.csri.toronto.edu!rutgers!ucsd!qualcom.qualcomm.com!maui.qualcomm.com!rdippold
From: rdippold@maui.qualcomm.com (Ron Dippold)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Accurate timing request
Message-ID: <1991Mar14.202729.7884@qualcomm.com>
Date: 14 Mar 91 20:27:29 GMT
References: <1991Mar6.145414.8747@uwovax.uwo.ca> <1991Mar7.025205.9213@qualcomm.com> <1991Mar14.040625.13212@comp.vuw.ac.nz>
Sender: news@qualcomm.com
Organization: Qualcomm, Inc., San Diego, CA
Lines: 31

In article <1991Mar14.040625.13212@comp.vuw.ac.nz> Timothy.Litton@comp.vuw.ac.nz (Tim Litton) writes:
>
>In article <1991Mar7.025205.9213@qualcomm.com>,
>rdippold@maui.qualcomm.com (Ron Dippold) writes:
>|> I would suggest that you speed up the clock ticks.  Currently they
>|> occur
>|> 18.2 times a second, but you can speed it up so that they occur 1000
>|> times
>|> a second or more, as the timer is programmable.  Your interrupt
>|> routine will
>|> need to scale whatever timer value you use down to the expected value
>|> and
>|> pass that on to the old timer.  For example, if you speed up the
>|> timer 128
>|> times, you will need to call the old interrupt vector every 128
>|> actual ticks.
>|> You can get some great accuracy this way, just keep in mind that the
>|> faster
>|> you interrupt the processor, the more machine power it gobbles up.
>
>
>Don't try this!!!
>
>Your system clock is dependent on that timer, so are most of your I/O
>devices for time outs!  Personally, I would put up the +/- 5ms
>inaccuracy then try this!

Look, I _said_ that you should step down the ticks that you get so that you
continue to call the old timer interrupt at the same rate.  I have been
using this method for years without problems.  The only caveat is that if
you exit without restoring the old interrupt, you could be in trouble.