Eric.Bohlman@p1.f778.n115.z1.fidonet.org (Eric Bohlman) (09/20/90)
Index Number: 10482
[This is from the Blink Talk Conference]
UA> From: UCCXMGM@OSUCC.BITNET
UA> The program works pretty well except that the real-time
UA> clock interrupt, (1CH), which drives it, has such a high
UA> priority that it conflicts with communications programs such
UA> as "Kermit." Believe me, you know you've got problems when
UA> ...
UA> Keeping with the issue at hand, I need to find an
UA> interrupt whose priority is somewhere between that of the
UA> clock-tick, (1CH) and that of the idle, (28H). The interrupt
UA> for "PRINT.COM" seems to be a good candidate if I could find
UA> out which interrupt number drives it. I want to stay away
UA> from rearranging the interrupt mask for many reasons. Thank
The only interrupts that have "priorities" are the hardware interrupts 08
through 0F. All the others are software interrupts, and the priority
controller has nothing to do with them. 1C is a software interrupt issued by
the handler for 08; the problem is that the 08 handler doesn't issue an EOI to
the PIC until after issuing the 1C software interrupt. The solution is for
your 1C handler to do it itself (just write 20H to port 20H). That will
re-enable the serial interrupts. If I remember right, the 08 handler issues
the EOI immediately on return from invoking 1C, so you shouldn't cause any
problems.
By the way, I found some problems in working with 1C (I've also written a
screen reader) and had to eventually go with a 08 handler instead. Apparently
some applications were taking control of 1C but not chaining it; this was over
a year ago and I've forgotten the specifics.
--
Uucp: ..!{decvax,oliveb}!bunker!hcap!hnews!115!778.1!Eric.Bohlman
Internet: Eric.Bohlman@p1.f778.n115.z1.fidonet.org