🚀 go-pugleaf

In article <773@csource.oz.au> david@csource.oz.au (david nugent) writes:
>Using the timer (hardware) interrupt is guaranteed to cause problems where
>some previously installed TSR or device driver speeds up the timer rate.
>Normally such programs filter those to make any "higher level" timer
>handler receive control at the correct rate.

Counter arguements - (1) most of the time you probably don't care the
frequency int 8 is called anyhow; (2) BIOS assume that the frequency 
would be 18.2 and IT attaches to int 8. :-) 

But keep in mind that I was arguing AGAINST using the timer interrupts to
do prolonged background processing, especially when such processing
involves accessing the disks and other hardwares or interacting with the
user. If you are writing a timer which only involves decrementing an 
internal counter, that's another story.

>Also, the PIC is rearmed by the time INT 1cH gets control, so you don't
>have to fiddle around with EOI's at all.  It's an "ideal" place to pop-up.

The part about EOI is not *quite* true, see my reply to an earlier
article. On the other hand, if you APPEND (not PREPEND) to int 8, then 
the EOI is guaranteed to have been taken care of.

>I've been using INT 1cH for a looong time without problems, so I just
>can't see why it's "preferrable", especially in a multitasking-under-DOS
>environment, like DESQview.

Well, I've seen examples of int 1Ch having problems (incompatibility
with SK, etc), but I've not seen an example of int 8 having problems.
I'll be interested to know whether DESQview is having problem with TSRs
using int 8. 

>I liked your suggestions re INT 16H though - they certainly have merrit.
>  david

Thank you,

yawei