🚀 go-pugleaf

In article <7871@news.duke.edu> kds@phy.duke.edu (Stokes Kevin) writes:
>>I use something like that in my game. At the start of the game I set the
>>timer to interrupt at 768 times/second (that particular number for various
>>reasons, all of which have nothing to do with the problem in question).

>  Since many user's TSR's depend on the timer interrupt, you must still
>call the old interrupt routine when yours is finished.  Obviously you
>want to call the old interrupt only every once and a while, so that the
>BIOS and TSR's still see the timer ints coming at 18 ticks/sec.

Yes, naturally. There is an option for this in my game. The game can be
set to either call the original timer int 18.2 times per second, or
alternatively handle the BIOS clock tick increment internally, never
calling the original timer int. The latter method saves a lot of time
to the foreground routine while still keeping the DOS clock on time,
but it disables any TSR that relies on the timer interrupt.

>  However, some TSR's do alot of stuff in their timer interrupt routines
>and you may miss interrupts if another 1/768th of a second goes by before
>you get control back from the called old interrupt.  On my system, this will
>simply crash the computer.

Hmm.. Why should it matter if I get control back to my timer routine
before the next timer tick happens? Timer interrupt routine must ofcourse
be re-entrant, so it makes no difference whether there are many instances
of timer int routine on the stack at the same time. I have usually not been
able to crash my computer even when I set the timer to run at over 24000
times per second and call the original INT8 vector 18.2 times per second.
In this case my routine interrupts the TSR routine many times before the
TSR gives control back to my routine. Depends on the TSR, I suppose.

>  So you have to set the timer int rate back to 18/sec before you call the
>old timer int routine.  This also keeps the task switchers happy.

This, I must admit, is something I have never thought of. I know that OS/2
for instance will not behave correctly if a DOS program sets the timer to
tick more than 1000 times per second. A very interesting idea. I am just
a bit worried if it can be made to work reliably and so that it stays in
sync. My game works quite well under Windows, OS/2 and DESQview with the
timer ticking at 768 times per second, however. Higher rates (to play
music thru an internal speaker or Covox Speech Thing) are not supported
in my game when running under any of these.

>  Now comes the bad part... I have found that on a small percentage of
>customer's machines, the timer doesn't reset to different speeds reliably.
>I found that increasing the delay between accesses to the timer chip
>helped, but there are many machines where this simply fails.  I was forced
>to put an option in for manual-fixed time scaling where the timer is not
>messed with.  Mostly I get complaints from PS/2 and Packard Bell owners.

Too bad. But perhaps there is nothing one can do about it.

Patrick Aalto
ap@jyu.fi