3 ms·
I'd argue the problem is that nobody enforced a strong peripheral API. We could have had a system like Commodore's intelligent peripherals-- a defined set of c
by hakfoo 2y ago
I'd argue the problem is that nobody enforced a strong peripheral API.
We could have had a system like Commodore's intelligent peripherals-- a defined set of commands issued on predictable ports-- and it shouldn't technically matter how the device chooses to implement it. This lets the vendor do whatever custom special sauce they want, but it also means that any operating system that speaks the standard API will be able to support it.
It could even have been moved one layer up-- letting them have some shim code running on the local machine, as long as it honoured a standard API at a sub-OS level. BIOS interrupts were a good example of this: everything from MFM hard discs to modern flash drives can all be supported with option ROMs providing interoperable INT 13h support.
It fell apart first when software chose to bypass the BIOS and twiddle the hardware directly, and second when BIOSes became vestigial, not really reimagined for 32 bit/multitasking use cases.