From:	Martin Steuer <ms172554 AT mail DOT inf DOT tu-dresden DOT de>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: WinXP's unbreakable console cursor
Date:	Tue, 22 Oct 2002 11:45:31 +0200
Lines:	19
Message-ID:	<3DB51E3B.4030002@mail.inf.tu-dresden.de>
References:	<3dad920f DOT sandmann AT clio DOT rice DOT edu> <3DAE8D71 DOT 7050904 AT mail DOT inf DOT tu-dresden DOT de> <3db10922 DOT sandmann AT clio DOT rice DOT edu>
NNTP-Posting-Host:	irz757.inf.tu-dresden.de (141.76.7.57)
Mime-Version:	1.0
X-Trace:	fu-berlin.de 1035279930 28245541 141.76.7.57 (16 [142788])
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language:	de-DE
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Charles Sandmann wrote:

> 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.
> 


Yes the consistency between these two values is a problem it was even on 
  Win9x Machines for me but I managed to get correct timing there.
Another problem I found on NT Machines is, that they dont allow you to 
reprogram the mode of PIT 0 to Mode 2 it always seems to stay in mode 3. 
    And the counting in mode 3 makes it harder to get an absolute timestamp.

- Raw text -