* System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar @ 1999-01-10 0:00 Craig Garrett 1999-01-09 0:00 ` Paul Whittington ` (3 more replies) 0 siblings, 4 replies; 11+ messages in thread From: Craig Garrett @ 1999-01-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar 1999-01-10 0:00 System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar Craig Garrett @ 1999-01-09 0:00 ` Paul Whittington 1999-01-10 0:00 ` robert_dewar 1999-01-10 0:00 ` Tom Moran ` (2 subsequent siblings) 3 siblings, 1 reply; 11+ messages in thread From: Paul Whittington @ 1999-01-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar 1999-01-09 0:00 ` Paul Whittington @ 1999-01-10 0:00 ` robert_dewar 1999-01-13 0:00 ` dmitry6243 0 siblings, 1 reply; 11+ messages in thread From: robert_dewar @ 1999-01-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar 1999-01-10 0:00 ` robert_dewar @ 1999-01-13 0:00 ` dmitry6243 1999-01-13 0:00 ` Tom Moran 0 siblings, 1 reply; 11+ messages in thread From: dmitry6243 @ 1999-01-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar 1999-01-13 0:00 ` dmitry6243 @ 1999-01-13 0:00 ` Tom Moran 0 siblings, 0 replies; 11+ messages in thread From: Tom Moran @ 1999-01-13 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar 1999-01-10 0:00 System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar Craig Garrett 1999-01-09 0:00 ` Paul Whittington @ 1999-01-10 0:00 ` Tom Moran 1999-01-10 0:00 ` Craig Garrett 1999-01-11 0:00 ` dennison [not found] ` <369A7B97.6AC0CA00@hercii.mar.lmco.com> 3 siblings, 1 reply; 11+ messages in thread From: Tom Moran @ 1999-01-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar 1999-01-10 0:00 ` Tom Moran @ 1999-01-10 0:00 ` Craig Garrett 1999-01-10 0:00 ` Tom Moran 0 siblings, 1 reply; 11+ messages in thread From: Craig Garrett @ 1999-01-10 0:00 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar 1999-01-10 0:00 ` Craig Garrett @ 1999-01-10 0:00 ` Tom Moran 0 siblings, 0 replies; 11+ messages in thread From: Tom Moran @ 1999-01-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar 1999-01-10 0:00 System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar Craig Garrett 1999-01-09 0:00 ` Paul Whittington 1999-01-10 0:00 ` Tom Moran @ 1999-01-11 0:00 ` dennison [not found] ` <369A7B97.6AC0CA00@hercii.mar.lmco.com> 3 siblings, 0 replies; 11+ messages in thread From: dennison @ 1999-01-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <369A7B97.6AC0CA00@hercii.mar.lmco.com>]
* Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar [not found] ` <369A7B97.6AC0CA00@hercii.mar.lmco.com> @ 1999-01-12 0:00 ` David C. Hoos, Sr. 1999-01-12 0:00 ` Tom Moran 0 siblings, 1 reply; 11+ messages in thread From: David C. Hoos, Sr. @ 1999-01-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar 1999-01-12 0:00 ` David C. Hoos, Sr. @ 1999-01-12 0:00 ` Tom Moran 0 siblings, 0 replies; 11+ messages in thread From: Tom Moran @ 1999-01-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~1999-01-13 0:00 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-01-10 0:00 System Clock update rate of 0.055 milliseconds in DOS/Win95 and Ada.Calendar Craig Garrett 1999-01-09 0:00 ` Paul Whittington 1999-01-10 0:00 ` robert_dewar 1999-01-13 0:00 ` dmitry6243 1999-01-13 0:00 ` Tom Moran 1999-01-10 0:00 ` Tom Moran 1999-01-10 0:00 ` Craig Garrett 1999-01-10 0:00 ` Tom Moran 1999-01-11 0:00 ` dennison [not found] ` <369A7B97.6AC0CA00@hercii.mar.lmco.com> 1999-01-12 0:00 ` David C. Hoos, Sr. 1999-01-12 0:00 ` Tom Moran
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox