The PC could go there somewhat too; you have the interrupt vector table at the bottom of memory, nominally in control of the BIOS. If you invent a new disc con

The PC could go there somewhat too; you have the interrupt vector table at the bottom of memory, nominally in control of the BIOS. If you invent a new disc controller, for example, you can change the vector for Interrupt 0x19 to point to your code, and if you realize from the body of the request that the call was intended for another device, you pass it on to the original code. There were two problems: * The standard BIOS features were somewhat limited and narrow. * They added enough overhead that you might want to ignore them and start fiddling with registers directly. This was especially true for video control (BIOS Interrupt 0x10). Nobody was going to follow through on the proper way of stuffing the framebuffer when it was memory mapped and you could just dump stuff straight into it. So on the one hand, it meant a BIOS-level compatibility wasn't enough, and it also forced hardware rictus (I could imagine, for example, a video standard which communicated with I/O ports to open up more addressable memory, but there's no way it would support anything but the most well-behaved software).