Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!waikato.ac.nz!comp.vuw.ac.nz!cavebbs!frank
From: frank@cavebbs.gen.nz (Frank van der Hulst)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Accurate timing request
Message-ID: <1991Mar14.201445.22541@cavebbs.gen.nz>
Date: 14 Mar 91 20:14:45 GMT
References: <1991Mar6.145414.8747@uwovax.uwo.ca> <1991Mar7.025205.9213@qualcomm.com> <1991Mar14.040625.13212@comp.vuw.ac.nz>
Organization: The Cave MegaBBS, Public Access Usenet, Wellington, NZ
Lines: 58

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:
>|> In article <1991Mar6.145414.8747@uwovax.uwo.ca>
>|> bangarth@uwovax.uwo.ca writes:
>|> >Researchers here are looking for some facility to measure time with
>|> 1 ms. 
>|> >or less accuracy on an AT or 386 machine. We currently with our
>|> software 
>|> >(in Turbo Pascal) can't get any better than about 3 ms. accuracy. I
>|> have heard
>|> 
>|> 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!
>
I've done this very successfully (although only to get 3ms accuracy on an XT).
I simply sped up the interrupt by a factor of 16, then called the original
vector (from my new vector) once every 16 interrupts. Before my program exits,
it reset the tick interval, and restores the vector.

Therefore the RTC keeps getting called at the usual 18.2Hz.

I think you may be confused -- we're talking about changing, through software,
the frequency of interrupts coming into IRQ0 (interrupt 8 on the CPU). This
won't affect the clocking of signals on the bus, which is what "system clock"
implies to me.

Secondly, the only I/O device time-out controlled by the INT8 service routine
is the floppy disk. If that ISR isn't called, all that will happen is that the
floppy will continue to spin. That can be turned off by outputting a byte to
the appropriate port, if necessary..>

Frank.
>
-- 

Take a walk on the wild side, and I don't mean the Milford Track.