From: mauch AT uni-duisburg DOT de (Michael Mauch)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Intermittent uclock() failure under DOS.
Date: Mon, 16 Jun 1997 00:24:45 +0200
Organization: Home, sweet home (via Gesamthochschule Duisburg)
Lines: 35
Message-ID: <5o1q2p$2r4$2@news-hrz.uni-duisburg.de>
References: <01BC7742 DOT 2B312840 AT TAURUS>
NNTP-Posting-Host: ppp76.uni-duisburg.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

On Thu, 12 Jun 1997 14:06:11 GMT, Steve Higgins
<steve AT psp-digital DOT co DOT uk> wrote:

> I've been using uclock() to time some routines.

[...]
 
> The problem is that no attempt is made to line these two timing sources up, so if your first call to uclock() happens to occur half way between BIOS ticks, we get the low order numbers wrapping to 0 before the high order numbers have incremented.

Strange - this problem should be taken care of by the uclock() source
itself:

  /* Make sure the numbers we get are consistent */
  do {
    otics = _farpeekl(_dos_ds, 0x46c);
    outportb(0x43, 0x00);
    lsb = inportb(0x40);
    msb = inportb(0x40);
    tics = _farpeekl(_dos_ds, 0x46c);
  } while (otics != tics);

Are you sure you don't have a driver/TSR that fiddles around with the
timer chip or the timer tick variable at 0x46c?

I cannot reproduce your problem on plain DOS - only in a DOS box of
Win3.1 or Win95 the original uclock() doesn't work, because Windows
reprograms the timer chip.

If you'd be happy with a Win3.1/Win95 substitute for uclock(), search
for "wuclock" in the comp.os.msdos.djgpp archive on www.delorie.com or
send me a mail.

Regards...
		Michael