🚀 go-pugleaf

In <1991Jan6.005549.29246@bronze.ucs.indiana.edu> yawei@bronze.ucs.indiana.edu (mr. yawei) writes:

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

If you don't care, then it doesn't really matter.  But then you can't use
it as a "timekeeper".

Secondly, because you're adding additional code, aka clock cycles to 
a timer interrupt cycle - especially if you've got a timer running at 
higher than standard speeds.  Not, IMHO, a great way to go.


> (2) BIOS assume that the frequency would be 18.2 and IT attaches 
> to int 8. :-) 

I can't see the counter argument here.  If you intercept INT 08H and
speed up the timer for any reason, then naturally you would attempt
giving any previously installed handlers - including BIOS - ticks at 
the same rate.


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

Of course - no argument.

Timer counters are most often used for timing, else you'd use INT 09H
and set a flag on hot-key.


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

Yes, I posted a correction.  It's not consistent.  I haven't seen the
same problems with the Compaq machines though.  I'd be interested in
any further information.

Unlike INT 1cH, you can guarantee the PIC's state on returning from INT 8.
But there's only the price of a few bytes in sending SEOI to the PIC before
continuing.  Normally I wouldn't do that unless the hot-key flag had been
set and all is ok to "popup".


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

DESQview has it's own scheduler and runs the PIC at a different rate.
However, it does work around this problem by revectoring the PIC to another
set of interrupts, and still generates INT 08H at the correct rate.
Generally, there aren't too many problems. I guess they had to get it
to work with SideKick too. :-)


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


Strangly enough, DESQview has problems with TSR's grabbing INT 16H. :-)

The problem is that under DV there's a "common" INT 16H handler for all
tasks.  I've seen this really cause havoc, but after trying it and seeing
the results, decided not to work out why since there were better and
cleaner workarounds available.


 david