views:

147

answers:

4

From: http://software.intel.com/en-us/articles/introduction-to-pc-architecture/

Exception number 10h corresponds to a "Floating Point Error" but software interrupt 10h also corresponds to "Video support" BIOS interrupts (both in real mode).

What am I missing?

+2  A: 
asveikau
+4  A: 

You're not missing anything.

The 8088 processor (the one used in the original IBM PC) only defined exceptions 0, 1, 2, 3, and 4.

So IBM used 0x8 to 0xF for hardware interrupt handlers and 0x10 and above for BIOS routines. For some reason IBM ignored the fact that Intel had very clearly reserved numbers 0x5 to 0x1F for future processor exceptions.

As time went on, more exceptions were needed and Intel went ahead and assigned them. Most of the time, legacy software didn't trigger these exceptions anyway whilst newer operating systems (those that ran in protected mode) could assign different numbers so as not to clash with the processor exceptions.

There were plenty of hacks added to older software to gain some use of newer processor features without breaking too much compatibility. While I'm not sure, I suspect that perhaps newer BIOSes might have tried to detect whether INT10 was triggered by a software interrupt or by the coprocessor in their INT10 handler.

FYI, from the 386 programmers manual:

Coprocessor errors vector to interrupt 16. Any 80386 system with a coprocessor must use interrupt vector 16 for the coprocessor error exception. If an 8086/8088 system uses another vector for the 8087 interrupt, both vectors should point to the coprocessor-error exception handler.

Artelius
Interesting. So basically every time the 387 raised an interrupt, it used the same interrupt line for the BIOS, and the OS multiplexed it accordingly ?
Stefano Borini
Like I said, I'm not sure. asveikau has another good theory under 'edit 2'. Note that this is only really related to DOS (and anything else that runs in real mode) - this isn't a problem for protected-mode systems such as Windows and Linux.
Artelius
+3  A: 

OK, have a look here, on Watcom's site. This is the important part I think, although the old note about the 8087 is interesting too.

Due to the market reality of the vast majority of PC users still running PC DOS and requiring IBM PC compatibility, the way the IBM AT handled math errors was not straightforward. Because IBM ignored Intel's recommendation when designing the PC, 286's Math Fault or interrupt 16 conflicted with BIOS video service interrupt 10h (16 decimal). On top of that, existing software expected math exceptions to arrive through INT 2.

Instead of connecting the CPU and FPU ERROR pins, the IBM AT used motherboard circuitry to route the 287 ERROR signal to the cascaded second 8259A PIC and used IRQ 13 to signal math errors to the CPU. The default BIOS IRQ 13 handler (that is, INT 75h vector - remember that IRQ 8, the first IRQ line of the second PIC, corresponds to interrupt vector 70h) contains code to invoke INT 2 for compatibility with existing software. Software on the AT thus still can hook the NMI vector and run unchanged on the PC or AT.

External circuitry in the IBM AT drives the 286's BUSY input pin active when a 287 asserts its ERROR signal. This prevents execution of further FPU instructions and is required to avoid problems in the time window after the 287 signaled an error and before the time the 286 starts processing the resulting interrupt.

fvu
But these days the coprocessor is part of the same chip as the processor! I wonder whether Intel went with their own designs or bowed down to PC compatibility . . .
Artelius
@Artelius, also from the Watcom page: "By the time the i486 was released (1989), Intel had realized the importance of the PC compatible market. Therefore the i486 contains features designed specifically to provide compatibility with existing PC software and hardware designs". How's that for "reverse logic"....
fvu
A: 

The simple answer is that the int 10h Floating Point Error is a protected mode exception, while the int 10h BIOS Video Services is a real mode interrupt.

The happy answer is that clearing the NE bit in the CR0 register will prevent the exception from occurring and allow it's use in PM32 as a simple interrupt (for example in a 32 bit protected mode BIOS extender).

Mike Gonta