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:	Thu, 17 Oct 2002 12:14:09 +0200
Lines:	27
Message-ID:	<3DAE8D71.7050904@mail.inf.tu-dresden.de>
References:	<3dad538f_1 AT news DOT arcor-ip DOT de> <3dad920f DOT sandmann AT clio DOT rice DOT edu>
NNTP-Posting-Host:	irz759.inf.tu-dresden.de (141.76.7.59)
Mime-Version:	1.0
X-Trace:	fu-berlin.de 1034849647 24838189 141.76.7.59 (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:

> 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 should also work under NT-family. But that way it requires a call 
to the timing routines at least approx. each hour or alternatively each 
day. This wont suffice the requirements of uclock(), right? But it 
should be allright as an alternate delay()implementation.
I think you're speaking of such an implementation.

Under some conditions however, consistency of the BIOS timer tick and 
the PIT's counting value is hard to get, I made this experience under 
Win9x:  only some strange workarounds made it work.
But I guess many of the fixes that make DJGPP more NT-reliable are a bit 
strange...

However it was surprising for me to see that Win2k at least virtualizes 
the PIT's ports.

- Raw text -