System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

[Craig Garrett]

In Dos/Win95, the system clock is only updated every 0.055 milliseconds,
which from a real-time simulation perspective is absolutely pitiful.  Is
there a system call to force the OS to update the system clock more
frequently or on demand?  I am sick of having such low resolution.  How do
real-time games such as Quake and flight-sims on PCs running Dos/Win95 get
around this problem?
  Craig

Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

[Paul Whittington]

There are at least two possibilities.  One is Win32 specific and the
other Intel specific.

1) Win32 API call.  The GetTickCount function retrieves the number of 
milliseconds that have elapsed since Windows was started.

2) Use the RDTSC instruction on the Intel Pentium processor to
read the timestamp counter.

Both of these are not platform portable.  The first is accurate to one
millisecond while the second is accurate to one processor cycle.

TTFN Paul

Craig Garrett wrote:
> 
> In Dos/Win95, the system clock is only updated every 0.055 milliseconds,
> which from a real-time simulation perspective is absolutely pitiful.  Is
> there a system call to force the OS to update the system clock more
> frequently or on demand?  I am sick of having such low resolution.  How do
> real-time games such as Quake and flight-sims on PCs running Dos/Win95 get
> around this problem?
>   Craig

-- 
Paul Whittington
GrepNet, Inc.
(208)523-7375
paul@grep.net

"Even if you're on the right track you'll get
 run over if you stand still."

Will Rogers

Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

[robert_dewar]

In article <36984F3F.FA6C58C3@grep.net>,
  Paul Whittington <paul@grep.net> wrote:

> 2) Use the RDTSC instruction on the Intel Pentium
> processor to read the timestamp counter.

The time stamp counter is for time stamping, not for timing
per se, I doubt it will meet real time scheduling needs.
Check the documentation carefully before you try this
route!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

[dmitry6243]

Tom Moran wrote:

>  Win95 has a system call to release the CPU until a certain time.
>  That time has a 55ms resolution.  So, without fancy footwork, you
>  can't get interrupts with smaller resolution.  I think NT sets
>  the interrupt time to 10ms.  Of course, if the system decides to
>  flush the disk cache or something, it may be quite a bit longer
>  before you get the CPU.

However it is possible (with heavy performance penalty!) to diminish the clock
resolution up to 1 ms under NT (see timeBeginPeriod from winmm.dll). I didn't
find it in Win32 bindings, but I believe it should not be a great problem.

Dmitry Kazakov

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

[Tom Moran]

Is it possible (and reasonable) under NT to dynamically vary the clock
interrupt rate?  ie, Interrupt at the soonest of (set of times various
tasks need an interrupt, 55ms) instead of always at a constant rate?

Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

[Tom Moran]

There are different ways for different OSes.  If you have access to
the hardware (DOS) you can reprogram the clock to interrupt more
often, or you can modify ada.calendar.clock to read it more
accurately.  (See the replacement Calendar body I uploaded years ago
to the old Janus BBS that does the latter.)  If you're unfortunate
enough to be running on such a "modern" OS as Windows, there's a
system call to get the time down to the submillisecond (see, eg, the
Ada.Calendar in RRsoftware's latest version of their Ada 95).  Getting
faster interrupts is somewhat more difficult, since you need get the
OS's permission.

Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

[Craig Garrett]

> If you have access to
> the hardware (DOS) you can reprogram the clock to interrupt more
> often, 
That sounds like EXACTLY what I want to do.... ummm.... now how do I do
that?  In the Bios?  In the OS?  In Ada?  Where and how? (code would be
really nice)

Now, I am meaning for this to run on Win95, but I thought that
Ada.Calendar.Clock is "presice" enough, but the date it reads is the EXACT
same value from the system clock for 55 milliseconds at a time, that is the
problem.  I dont think its Ada.Calendar's fault, because you can subtract
time types and get really "precise" floating point numbers, so that is not
the issue, I need the faster (umm, more frequent) clock interrupts, how is
that done?
  Craig

Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

[Tom Moran]

I happen to know the Janus Ada.Calendar.Clock uses the Windows API
call QueryPerformanceCounter to get the time since boot in clock ticks
(0.055/2**16=0.9 mics).  If you aren't using the Janus compiler, you
could still build your own clock routines that way to give you a clock
that changes value more often than every 55 ms.  If you need to do
something like update the screen, or start a sound periodically, but
more accurately than 55ms resolution, you can do the equivalent of,
say, "delay 0.001;" by polling that hires clock.
  If you really need interrupts - ie, polling won't do what you need,
and you need them more often than every 55ms, then there are some
tricks you could do like sending dummy data out a serial port and
using those interrupts for timing, but I'd be surprised if Win95
allowed you to actually reprogram the clock tick time.  If it does
allow it, I suggest "Programmer's Problem Solver for the IBM PC, XT, &
AT", ISBN 0-89303-787-7, which has good info on various such low level
fiddling.

Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

[dennison]

In article <01be3c40$f93dc120$3804fbd1@longslide>,
  "Craig Garrett" <cgarrett@siscom.net> wrote:
> frequently or on demand?  I am sick of having such low resolution.  How do
> real-time games such as Quake and flight-sims on PCs running Dos/Win95 get
> around this problem?

My understanding is that such games continually render as fast as they can.
That's why system performance is often measured in Quake or Turok frames
displayed per second.

But then if your system hiccups and a whole second passes between two
displayed Quake frames, nothing horrible will happen (unless you count
getting fraggged as horrible :-)  ). If you actually have *hard* performance
deadlines, Windoze is not the OS for you.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

[David C. Hoos, Sr.]

Jerry Petrey wrote in message <369A7B97.6AC0CA00@hercii.mar.lmco.com>...
>Craig Garrett wrote:
>
>> In Dos/Win95, the system clock is only updated every 0.055 milliseconds,
>
>
>^ .055 seconds or 55 miliseconds
>
>> which from a real-time simulation perspective is absolutely pitiful.  Is
>> there a system call to force the OS to update the system clock more
>> frequently or on demand?  I am sick of having such low resolution.  How
do
>> real-time games such as Quake and flight-sims on PCs running Dos/Win95
get
>> around this problem?
>>   Craig
>
>
>Back in the mid 80's, we used to reprogram the 8254 Timer chip in the PC
>to give a faster interrupt (usually 1 millisecond) and then call the normal
>timer ISR every 55 miliseconds to make the change transparent to the PC.
>This was in a Forth application and it worked quite well.
>
The reason for the particular update rate on DOS systems is that a 16-bit
counter is incremented by one for each interrupt, and the rate was chosen so
that the counter "wraps" once per hour (on the hour).

My guess is that the Ada run-time is using OS information derived from that
counter, so one would need to use something other than Ada.Calendar.Clock,
and one could not use delay statements without reworking the Ada run-time to
use information generated from the faster interrupts.

It seems doubtful to me that checking for delay expirations every 55
milliseconds would not be acceptable, even if you could obtain current time
with one millisecond resolution.

David C. Hoos, Sr.

Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar

[Tom Moran]

  The 8253 tick rate was 1/4 of the 4.77 MHz of the original PC,
which was 1/3 the 14.31818 MHz rate of cheap color TV crystals.
The interrupt occurs when the 8253's internal 16 bit counter hits
zero, so the maximum delay between interrupts is 2**16 internal
ticks.  12/14.31818*65536= 54.925 milliseconds.  DOS, et al,
increment a four byte counter on the interrupt, so the lower two
bytes generate a carry to the upper two every 0.054925*65536=
3599.56 seconds.

  If the 8253's internal count is set to start at less than
maximum, it will reach zero sooner and interrupt sooner.  If the
program reads the 8253's internal count, it can append those two
bytes to the right of the software 4 bytes, giving a counter with
12/14.31818= 0.838 mics resolution.  Windows'
QueryPerformanceCounter does this on PC compatible hardware.
There was no such system call in DOS; you had to program this
yourself.  Most programs, including most Ada.Calendar.Clock's,
use the low-res Time system call, so they get the interrupt
count, which only changes every 55 ms.  It's easy enough to make
your own Ada.Calendar.Clock that reads the high-res
software+hardware time, but some Ada run-times may not use
Ada.Calendar.Clock internally, so 'delay' might not use your new
high-res Clock.

  Win95 has a system call to release the CPU until a certain time.
That time has a 55ms resolution.  So, without fancy footwork, you
can't get interrupts with smaller resolution.  I think NT sets
the interrupt time to 10ms.  Of course, if the system decides to
flush the disk cache or something, it may be quite a bit longer
before you get the CPU.

  If you have control of the hardware, eg DOS, you have freedom
to poll without worrying you're slowing Solitaire, or to change
the interrupt rate, or whatever.