edhall@randvax.UUCP (Ed Hall) (11/02/88)
I may be missing something obvious, here: 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. Of course, the INTEL 80286 reference says all over it that INT 0x0 to INT 0x1f are ``reserved by INTEL.'' Short of hacking hardware, how do people deal with this problem? Or am I missing something? Do the external hardware vectors mysteriously move when the 80286 is in protected mode? Or is there some simple way to figure out whether an interrupt is external or some internal exception condition? Thanks for any help or advice you might give me. -Ed Hall edhall@rand.org hplabs!sm.unisys.com!randvax!edhall
jbrown@jato.Jpl.Nasa.Gov (Jordan Brown) (11/04/88)
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.)
alex@mks.UUCP (Alex White) (11/04/88)
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? You re-program the first 8259 interrupt chip to point the first 8 hardware interrupts to some other base location. The second interrupt chip is already programmed to point elsewhere - it was added for the AT, but they had to leave the first chip at the same location because thats how they did it on the pc. > > Of course, the INTEL 80286 reference says all over it that INT 0x0 to > INT 0x1f are ``reserved by INTEL.'' And all those idiots at IBM which ignored this should be shot.