och wrote on 2023-12-26, 13:59:
Understood, thank you. Reading through this thread, it seems that even the FPU had to be explicitly supported by software to be utilized?
Yes. Basically DOS doesn't do any kind of abstraction of this kind of functionality. All you have is what BIOS offers you, which is I/O related, not any kind of graphics or sound or whatever, or even additional CPU instruction sets.
So if your software wants to talk to any hardware, it has to directly address it in whatever way the hardware itself understands. That's why you have to configure specific sound hardware in DOS, and the same applies for any form of co-processor, be it an FPU or a graphics accelerator. So AutoCAD for example supported at least three different kinds of FPU (8087 FPU, Intel 287/387/487 FPU (and compatibles) and Weitek). as well as 8514 and XGA drawing acceleration. But it was an outlier, as AutoCAD was so specialized and expensive that people built computers around the software - and almost everyone doing so ensured they had the hardware to optimally utilize that software. Once again, all this support needed to be hard-coded into your application, so every developer would have had to do it themselves as well. Both Lotus 1-2-3 and AutoCAD supported FPUs, but they each had had to invent the wheel themselves, as did Spectrum Holobyte with Falcon 3.0 and Maxis with SimCity.
For games, that generally made no commercial sense: in the 1980s and early 1990s (up to 386 era), accelerated hardware was so rare and expensive almost no one developed for it. By the time of the 486, FPU was fairly common (but still too slow to be of use to many games, as detailed above) as was graphics acceleration hardware, but the latter market was completely fragmented with every vendor having their own unique hardware that was only compatible with others at the most basic (S)VGA/VESA level. So that is what developers coded for. At no point would the extra effort of supporting multiple chips natively translate into additional sales and so revenue.
It's no coincidence that utilization of co-processors, graphics acceleration and indeed more advanced CPU instructions only became commonplace once Windows had abstracted the hardware, so you just developed once for DirectX (or maybe OpenGL) and let Windows and its drivers figure out how to talk to the hardware.