Message-Id:	<1.5.4.32.19970506133949.002e355c@ubeclu.unibe.ch>
Mime-Version:	1.0
Date:	Tue, 06 May 1997 15:39:49 +0200
To:	djgpp AT delorie DOT com
From:	Roger Noss <noss AT pupk DOT unibe DOT ch>
Subject:	reliable timer choices

In the short time I have been reading in this newsgroup, I have seen many
posts about timers.  It seems to me that a reliable high-resolution timer is
as important for programmers as a reliable power supply is for hardware
projects.  Indeed, that's one big reason there is still so much interest in
DOS, because the timing is reliable.  Nevertheless, reliable timers must
also exist for Win95/NT environments, because that's the way most computers
are sold today, so software must be written to run under those multitasking OSs.

One of the problems with evaluating timers is that the timer may be good but
a multitasking OS muddies the testing water.  It would be nice to read a
comprehensive guide to controlling multitasking for applications which must
keep control for a second or so at a time.

In my struggle to settle on a reliable timer, I have considered the
following timer choices, with their pros and cons listed.  I hope others can
comment on this, and correct misstatements.  Perhaps someone with an
appropriate web site can corral the subject completely, so that the rest of
us can do "one-stop shopping" and make an intelligent choice when we need to
choose a timer solution.

In djgpp, there is uclock().  It is easy to use, and is a documented
function with a close relative, usleep().  Recent posts have indicated that
uclock() cannot be trusted in a Win95/NT environment, because the OS resets
the timer chip to some (unknown) default mode.  Huge and negative values
have been timed for intervals which should be very short.  Workarounds have
been suggested, such as dropping high bytes and sampling several times to
exclude outliers.  Presumably programmers working in "pure DOS" (does that
mean DOS 6.2?) like uclock(), but that doesn't help those of us who "forgot"
to save the older OS when installing Win95/NT.

For Intel processors, there is zentimer.h, which makes use of an
undocumented register which is incremented once every clock cycle.  Has
anyone tested it on other processors, such as AMD, or the IBM 6x86 (or does
Intel make that too)?  This timer is an inline C++ implementation, so when
you use it you get that warm and fuzzy feeling that you're programming in
the right decade.  It needs some tuning for individual machines (which I
could not understand from the documentation) to correct for timer overhead.
It reports only clock cycles, so some calibration is also required.

Allegro also offers some timer functions, which appear to be fine for "pure
DOS".  Shawn Hargreaves explained them very nicely in an April 25, 1997,
posting, which I can send or repost if there is interest.  According to
Shawn, the best that can be attained under Win95 is 5 ms accuracy, and its
performance under WinNT hasn't been rigorously tested (if I understand his
comments correctly).  That's probably good enough for most folks, but 1 ms
would be much better.  Certainly 18.2/sec is too large an error to be
tolerated by anyone interested in using timers.

I am currently using the hsync and vsync indicator bits of port 0x3da
because I understand them.  They give me a resolution of about 36 us but are
clumsy to use, and are not true timers that will interrupt; polling is
required.  Moreover, game developers would not consider them because of
their hardware-specific nature.  But I trust them, and that is the most
important feature of a timer.  It would be nice to discover a register that
is incremented on every horizontal retrace, because then I would not have
sit and count them myself.

Then there is the speaker timer (1.19MHz).  In DOS you can just write your
own interrupt service routine for it, but you don't have to, because I
believe this is what Allegro uses for its timers and for vertical retrace
emulation.  However, Shawn reports that it doesn't behave well in Win95.

Finally, did I read in this group that Microsoft recommends a different way
to do high-resolution timing, perhaps using some multimedia ideas?  It
seemed strange to me at the time I read it.  If someone knows about this,
please share it.  Surely Windows programmers must also need to use timers.

I remember programming an SGI Iris Indigo in which I could just enable a
1-ms-resolution timer, but I had to run as superuser.  I would be happy for
a similar solution in Win95/NT.  There must be a way.

Roger Noss

- Raw text -