From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,89d65c5ea403ba58
X-Google-Attributes: gid103376,public
From: "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com>
Subject: Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and
 Ada.Calendar
Date: 1999/01/12
Message-ID: <568mzAiP#GA.245@pet.hiwaay.net>#1/1
X-Deja-AN: 431628780
References: <01be3c40$f93dc120$3804fbd1@longslide>
 <369A7B97.6AC0CA00@hercii.mar.lmco.com>
Newsgroups: comp.lang.ada
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Date: 1999-01-12T00:00:00+00:00
List-Id: <comp.lang.ada>


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.