From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: WinXP's unbreakable console cursor
Date: Sat, 19 Oct 2002 02:26:26 CDT
Organization: Rice University, Houston TX
Lines: 16
Message-ID: <3db10922.sandmann@clio.rice.edu>
References: <3dad920f DOT sandmann AT clio DOT rice DOT edu> <3DAE8D71 DOT 7050904 AT mail DOT inf DOT tu-dresden DOT de>
NNTP-Posting-Host: clio.rice.edu
X-Trace: joe.rice.edu 1035012643 9982 128.42.105.3 (19 Oct 2002 07:30:43 GMT)
X-Complaints-To: abuse AT rice DOT edu
NNTP-Posting-Date: 19 Oct 2002 07:30:43 GMT
X-NewsEditor: ED-1.5.9
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

> > I've looked at an alternate delay implementation.  Getting timer tick
> > resolution is fairly easy, but since uclock() is also flakey I don't have
> > not checked in a updated delay() into the new release yet.

> I have access to a Win2k machine here and tried reading the latched 
> timer tick this seems to work (using DJ's public compiler service :).
> My own timer routines are based on an absolute tick count which is 
> composed of the BIOS' timer ticks low-word and  the tick count.

This is how uclock works, but the bios area count is not coordinated with
the PIT.  The roll over isn't at PIT 0, and it doesn't even happen exactly
at the same PIT value either for each tick (drift back and forth).  At first 
glance uclock() seems to work, but then you see ugly jumps occasionally.

This same drift is what makes delay() a mess, unless you try to busy wait
while hitting the PIT counter.  Not the best method on a multi-tasking OS.