www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1997/02/19/12:36:46

Sender: mat AT kikashi DOT lcs DOT mit DOT edu
To: djgpp-workers AT delorie DOT com
Subject: Re: Exact timming II
References: <Pine DOT SUN DOT 3 DOT 91 DOT 970219112336 DOT 22519T-100000 AT is>
From: Mat Hostetter <mat AT lcs DOT mit DOT edu>
Date: 19 Feb 1997 12:18:03 -0500
In-Reply-To: Eli Zaretskii's message of Wed, 19 Feb 1997 11:25:13 +0200 (IST)
Message-ID: <qtwn2t0g1f8.fsf@kikashi.lcs.mit.edu>
Lines: 27

>>>>> "eliz" == Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> writes:

 >> It looks as though Win95 uses/resets the timer itself every so
 >> often. I tried reducing the wait interval.  At 1ms (or so) the
 >> result was consistently positive (780 or so). But from 2ms onwards
 >> these daft negative answers turn up regularly.

 eliz> Right, that is exactly what I see on a Windows 95 machine down
 eliz> here.  Does anybody know what part in Widnows resets the timer,
 eliz> or why, or how, if at all, this can be disabled?

I discovered this problem when writing Executor's timer code.  Windows
occasionally randomly takes over/turns off the BIOS event wait timer.
If I remember correctly, I could find no pattern and no way around it.
What I ended up doing was using the 18.2 Hz timer as a "watchdog" to
turn the BIOS event wait timer back on again if it seemed to be
stopped.  I patched my own real-mode handler into the 1024 Hz
interrupt chain and let it count ticks for me so even if Windows was
using the timer I still got the ticks.

A horrible hack...

Of course, if you're on a Pentium you can use "rdtsc" to get the
number of cycles elapsed as a 64-bit number.  That may be useful for
some timing applications.

-Mat

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019