brad@looking.UUCP (Brad Templeton) (01/02/88)
My documentation on the 387 states that an exception triggers trap 16 (decimal) in the 386. If this maps into the 16th vector in real mode, as it seems to, this is the same as IBM's VIDEO Bios call! I wonder because some 387 software I am testing seems to clear the screen sometimes on a numeric exception! The 287 (which can also be used with a 386) triggers what they call an IRQ 13, which somehow becomes an INT 75 on an AT style machine. The code for INT 75 just resets the 287 and calls INT 2, the NMI vector. (On the PC, IBM wired the 8087 exception line to NMI.) Anyway, all this makes writing a good general exception handler for all three Intel 80x87 chips a tad complicated. Could the screen clear be the result of a hardware bug in the 386 board? Is it even possible to stop the 80387 exception from triggering an INT 16? Any info would be appreciated. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (01/05/88)
In article <1269@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: | My documentation on the 387 states that an exception triggers trap 16 (decimal) | in the 386. If this maps into the 16th vector in real mode, as it seems to, | this is the same as IBM's VIDEO Bios call! Looking at the original 8086 product manual, it clearly states that interrupts 0-31 are reserved to Intel for expansion, and int 224 is reserved to Digital Research for CP/M-86. There is a conflict, and it's because Microsoft/IBM messed up. Yes, you can get problems here. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
brad@looking.UUCP (Brad Templeton) (01/06/88)
In article <8349@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <1269@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: >| My documentation on the 387 states that an exception triggers trap 16 (decimal) >| in the 386. If this maps into the 16th vector in real mode, as it seems to, >| this is the same as IBM's VIDEO Bios call! > >Looking at the original 8086 product manual, it clearly states that >interrupts 0-31 are reserved to Intel for expansion, and int 224 is >reserved to Digital Research for CP/M-86. There is a conflict, and it's >because Microsoft/IBM messed up. Yes, you can get problems here. >-- Ok, so what do we do if we want to write a general exception handler for all these machines? What do the clones do? Do most of them map this exception in real mode to the old IRQ 13 on the 286? I know that a 287 in my 386 seems to do this. What do the Compaq Deskpro 386 and PS/2 model 80 do about this? My clone seems to call *both* IRQ 13 and Int 16. Do others do this? Is the only solution to write an interceptor for the BIOS call that checks the trap flag in the 387? Yuck. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
Usenet_area_"Cs.I.Pc"@watmath.waterloo.edu (01/09/88)
From Usenet: burl!codas!killer!richardh From: richardh@killer.UUCP (Richard Hargrove) Newsgroups: comp.sys.ibm.pc Subject: Re: What's the deal on the 80387 and real mode interrupts? Summary: Intel reserved interrupts 00h thru 1fh Message-ID: <2730@killer.UUCP> Date: 9 Jan 88 03:07:48 GMT References: <1269@looking.UUCP> Organization: The Unix(R) Connection, Dallas, Texas Lines: 39 In article <1269@looking.UUCP>, brad@looking.UUCP (Brad Templeton) writes: > My documentation on the 387 states that an exception triggers trap 16 ( decimal) > in the 386. If this maps into the 16th vector in real mode, as it seems to, > this is the same as IBM's VIDEO Bios call! > As the Intel documentation clearly states, (_iAPX 86/88, 186/188 User's Manual: Programmer's Reference_, pg. 4-9 and Fig. 4-9 on pg. 4-10) "The dedicated and reserved portions of the interrupt pointer table (locations 0H through 7FH), however, should not be used for any other purpose to insure proper system operation and to preserve compatibility with future Intel hardware and software products." Guess what? Those are all the interrupt vectors associated with interrupts 00h through 1fh! I think it took incredible stupidity or arrogance on the part of some designer at IBM to use the "unused" vectors in this range for the PC BIOS. This actually caused some problems for the early AT BIOS implemenatations because the 80286 claimed some of the reserved interrupts (the BOUND instruction traps to interrupt 5 if the tested value is out of the specified bounds, and we all know what's at INT 5 - the print-screen driver!) and the BIOS code wasn't written to handle them! The BOUND instruction could call the INT 5 routine with random parameters! > > Anyway, all this makes writing a good general exception handler for all three > Intel 80x87 chips a tad complicated. Could the screen clear be the result Too say the least. Good luck. Just remember the above said designer (or design committee) when you run into problems. You might try tracing through the code pointed to by the INT 13h handler to see how it discriminates between the two (extremely) dissimilar interrupt sources. That is the critical problem. Then re-vector to a truly unused interrupt if the '387 exception needs to be handled. richard hargrove ...!killer!richardh ------------------- --- via UGate v1.6 * Origin: watmath (221/163)
richardh@killer.UUCP (Richard Hargrove) (01/09/88)
In article <1269@looking.UUCP>, brad@looking.UUCP (Brad Templeton) writes: > My documentation on the 387 states that an exception triggers trap 16 (decimal) > in the 386. If this maps into the 16th vector in real mode, as it seems to, > this is the same as IBM's VIDEO Bios call! > As the Intel documentation clearly states, (_iAPX 86/88, 186/188 User's Manual: Programmer's Reference_, pg. 4-9 and Fig. 4-9 on pg. 4-10) "The dedicated and reserved portions of the interrupt pointer table (locations 0H through 7FH), however, should not be used for any other purpose to insure proper system operation and to preserve compatibility with future Intel hardware and software products." Guess what? Those are all the interrupt vectors associated with interrupts 00h through 1fh! I think it took incredible stupidity or arrogance on the part of some designer at IBM to use the "unused" vectors in this range for the PC BIOS. This actually caused some problems for the early AT BIOS implemenatations because the 80286 claimed some of the reserved interrupts (the BOUND instruction traps to interrupt 5 if the tested value is out of the specified bounds, and we all know what's at INT 5 - the print-screen driver!) and the BIOS code wasn't written to handle them! The BOUND instruction could call the INT 5 routine with random parameters! > > Anyway, all this makes writing a good general exception handler for all three > Intel 80x87 chips a tad complicated. Could the screen clear be the result Too say the least. Good luck. Just remember the above said designer (or design committee) when you run into problems. You might try tracing through the code pointed to by the INT 13h handler to see how it discriminates between the two (extremely) dissimilar interrupt sources. That is the critical problem. Then re-vector to a truly unused interrupt if the '387 exception needs to be handled. richard hargrove ...!killer!richardh -------------------
Ralf.Brown@B.GP.CS.CMU.EDU (01/09/88)
In article <2730@killer.UUCP>, richardh@killer.UUCP (Richard Hargrove) writes: }This actually caused some problems for the early AT BIOS implemenatations }because the 80286 claimed some of the reserved interrupts (the BOUND }instruction traps to interrupt 5 if the tested value is out of the specified }bounds, and we all know what's at INT 5 - the print-screen driver!) and the }BIOS code wasn't written to handle them! The BOUND instruction could call }the INT 5 routine with random parameters! What's worse, the BOUND exception is restartable--the handler is supposed to correct the condition (if possible), and then the BOUND instruction is re- executed on return. Since the print-screen handler doesn't take any parameters or modify any registers, the INT 5 is called again, and again, and... }richard hargrove }...!killer!richardh }-------------------