Message-ID:	<36937861.73F5F8F8@cyberoptics.com>
From:	Eric Rudd <rudd AT cyberoptics DOT com>
Organization:	CyberOptics
X-Mailer:	Mozilla 4.05 [en] (Win95; U)
MIME-Version:	1.0
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: timing in u sec range
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 990103103639 DOT 12860B-100000 AT is> <36928BD8 DOT 8FED643D AT cyberoptics DOT com> <3692B1AB DOT BD2391B7 AT montana DOT com>
Lines:	26
Date:	Wed, 06 Jan 1999 08:51:13 -0600
NNTP-Posting-Host:	206.144.150.73
X-Trace:	news2.randori.com 915634269 206.144.150.73 (Wed, 06 Jan 1999 06:51:09 PDT)
NNTP-Posting-Date:	Wed, 06 Jan 1999 06:51:09 PDT
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

bowman wrote:

> Eric Rudd wrote:
> > timer routine failed similarly, I have concluded that Win95 (in its infinite
> > wisdom) is periodically tampering with the 8254, so I gave up on uclock(),
>
> How were you attempting to read the 8254? It has been a while since I've
> played with it, but my impression was if you use inport*(), Windows32 is
> only allowing you access to a virtual 8254, with very little effort
> given to maintain in in sync.

That would explain a lot.  My old routine was written before I ever heard of DJGPP;
it was in Turbo Assembler, and used "in" and "out" instructions.

> There is a decent timer in the mmsystem package, but this is assuming
> you are building a windows app.

At home I'm not even running Windows, so I'd have to do more work to check if
Windows was running.  Actually, I don't have a problem myself, since I'm pretty
satisfied with my RDTSC routines, but there was some discussion in this thread about
using uclock() to get 840-ns resolution, and I wanted to point out that one can't
expect such resolution under Windows.

-Eric Rudd
rudd AT cyberoptics DOT com

- Raw text -