Path: utzoo!attcan!uunet!peregrine!elroy!jato!jbrown
From: jbrown@jato.Jpl.Nasa.Gov (Jordan Brown)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Interrupt/Exception Confusion on 80286
Keywords: 80286, Interrupts, Protected Mode
Message-ID: <417@jato.Jpl.Nasa.Gov>
Date: 4 Nov 88 12:05:28 GMT
References: <384@rondo.randvax.UUCP>
Reply-To: jbrown@jato.UUCP (Jordan Brown)
Organization: Me?  Organized?
Lines: 46

In article <384@rondo.randvax.UUCP> edhall@randvax.UUCP (Ed Hall) writes:
>When running an 80286 in protected mode (and for some limited cases
>in real mode) it is possible to generate exceptions with vector numbers
>between 0x8 and 0xf.  Now, on a PC/AT, COM1 is at INT 0xc--which is
>the INT for a stack overflow.  Just how do you tell the two apart?
>How about LPT2 and a general protection violation(0xd)?  And so on.

There are, I believe, two solutions.  You sort of stumbled over them.

>Do the external hardware vectors mysteriously move when the 80286 is
>in protected mode?

Not mysteriously...

1.  Reprogram the interrupt controller to generate interrupts someplace
else.  (You want to play with ICW1 and ICW2.)

>Or is there some simple way to figure out whether an interrupt is external
>or some internal exception condition?

2.  Look at the ISR to see if there's an 8259-generated interrupt being
serviced.  (It may take cleverness to handle an exception in the interrupt
routine.  You might need to EOI the interrupt early and manually mask it
off.)

>Of course, the INTEL 80286 reference says all over it that INT 0x0 to
>INT 0x1f are ``reserved by INTEL.''

Yup.  Ain't IBM wonderful?  I think the 8086/8088 docs said it too.
I think a few of those exceptions can be generated in real mode.

If you are trying to do this level of hacking, you NEED the Intel
Microprocessor and Peripheral Handbook, volume 1 in this case.
The two-volume set is $25 from 800-548-4725, order number 230843.

The phone number and pricing is from the 1988 book.  The how-to is
from 2-year-old memory and skimming the book.

For even more fun, read about what happens when some device requests an
interrupt and then drops the request before the 8259 gets to it.  The
8259 is stuck - it has already told the CPU about it - so it generates
a "phantom" interrupt on device 7.  Try to distinguish *that* from a
genuine printer interrupt!  (Then, try to figure out why your printer
doesn't work any more... in some cases the printer lives on these
phantoms, because that line isn't latched and some printers don't put
out a very long ack pulse.)