🚀 go-pugleaf

In article <7992@news.duke.edu> kds@phy.duke.edu (Stokes Kevin) writes:
>In article <1992Dec14.065626.27427@jyu.fi> ap@jyu.fi (Patrick Aalto) writes:
>>alternatively handle the BIOS clock tick increment internally, never
>>calling the original timer int. .....
>  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.

Well, it certainly is possible that a certain TSR will 'become unhappy' as
you say if the timer int is stolen from it. That's why it is an option in
my game. So far I haven't found a TSR that would do this, but my search has
been far from extensive.

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

True. Although I think the problems with the TSR are likely to happen even
before the original timer int is restored. The TSR might for example wait
for a certain number of ticks, effectively hanging the machine if it never
gets a timer int.

>>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?

I don't think that is the problem. If you call the original timer int only
about 18 times a second there should never be a need for that original
timer handler to be re-entrant. If it takes so long for the original timer
routine to run that you must re-run it from your handler before the original
call has returned, the machine would hang even without your new routine.
(Sorry if I cannot express myself clearly, english is not my native language.)

The only routine that must be re-entrant is your own handler routine.

>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 am not quite sure what you mean by 'rejecting' ints. One can do with the
new ints (happening before the chain call has returned) whatever one wishes,
as long as one does not call the chain routine again. I use a timer int
routine roughly like this (in a sort of pseudo-code):

	push regs
	inc counter
	if (counter == chaincount)
	{
	    counter = 0;
	    pushf
	    call oldtimer
	}
	else
	{
	    mov al,20h
	    out 20h,al
	}
	do my own stuff here
	pop regs
	iret

That code is re-entrant enough for my purposes.

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

I see. That method will not work for me, I think, because I cannot afford
to wait 1/18th of a second before getting the next timer int.

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

Yes, very likely. And as the multitasking environments usually reprogram the
interrupt chip to actually use some other range of interrupt vectors than
the DOS standard, they will spend time handling the interrupt before giving
control to my int 8 handler. This is by the way why QEMM for example might
cause the machine to crash when playing digitized music at high rates.
The rate of 768 ticks/sec should still be relatively safe, though. I can
use half of that if absolutely necessary, but not slower. The slowest
machine I have tested my routines on is a 10 Mhz 386SX.

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

This is a good guideline.

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

Thanks! It is a 3D space game, something like Elite or Wing Commander, but
with a multiple player option.

Patrick Aalto
ap@jyu.fi