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?
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.
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.
The floating point fault is a CPU interrupt, generated by an error condition. This is different from an IRQ.
The PIC (Programmable Interrupt Controller) can be used to modify which IRQs will get mapped to which CPU interrupt. If you send the PIC's IO port the proper sequence (using the OUT instruction), you can map the IRQ in such a way that it doesn't conflict with the CPU interrupt from a floating point exception.
See also this document.
EDIT: But now that I read your question again... We're not talking about IRQs here. BIOS Int 10h is a different beast altogether... It's some code that your BIOS has implemented for video routines. If you're writing an OS and wondering if you should handle floating point faults, you should probably forget this particular BIOS interrupt exists. :-)
EDIT 2: Come to think of it, probably the way old DOS programs worked around this was to backup the IVT entry, put their own exception handler in its place, did some floating point ops, and restored the old IVT entry when they were done with the FPU.
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).
