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
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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.