🚀 go-pugleaf

In article <1992Dec14.065626.27427@jyu.fi> ap@jyu.fi (Patrick Aalto) writes:
>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. .....

>but it disables any TSR that relies on the timer interrupt.
>

  That is a good idea.  I never tried this, because I thought maybe a TSR
which had trapped int 8, and some others like comm ports or keyboard might
become unhappy when you shut down the timer int.  Maybe it could cause 
crashes when the game is over and the old timer int is turned back on.  That
is DOS's biggest bane.  It lets you make TSR's, but the operating system
(and I use the term OS loosely here) doesn't help moderate between TSRs at
all.  

>>  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, .......

  Ah, but can you really depend on everybody's TSR to have a nicely written
re-entrant timer int routine?   One must be very careful about assumptions
like that in the DOS marketplace.  But I suppose you should be able to make
your int 8 routine nicely reentrant and reject ints which occur before you
get control back from the DOS int 8 from the previous int.  I remember that
you had to fool around with the bits in the interrupt controller.
  I never got that to work reliably, but setting the timer back to 18.2 ticks
before calling the DOS chain worked great, so that's how I did it.  Only 
after distributing did I find out that not all machines responded reliably
to timer rate changes.


>>  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.
>......
>sync. My game works quite well under Windows, OS/2 and DESQview with the
>timer ticking at 768 times per second,

  Be very carefull here.  The failure at higher int rates might be directly
related to the time it takes to process ints.  Thus on a 12mhz 286, you
might be in trouble even if it runs great on your 486 or whatever.  I
definitely had that problem.

  Make sure you start your distribution slowly so you can quickly get reports
back about crashes before going hogwild and send it all over the world.
DOS systems are infamous for software conflicts, and the more odd your
technique, the higher probability of problems.

  Anyway, good luck with the project.  What kind of game is it?

                                              -Kevin



-- 
------------------------------------------------------------------------------
|  Kevin Stokes                        |     Please direct all pointless     |
|  Pie in the Sky Software             |   flames to my mailbox, it's much   |
|                                      |          more irritating.           |