Don't waste money on a math coprocessor they said

We kind of marveled back then because MHz meant speed.

Edit: I just remembered one of them was "Eye of the Beholder III"

Edit- Dune 2, not Dune 2000

a rather difficult game.

f16 however was a joy. happy days

To be sure, the author should remove and reinstall the coprocessor 10 times, testing after each. :)

Also it looks like there may be some issues with FP/FP emulation on the OS/2 DOS extender host: https://www.os2museum.com/wp/floating-point-exceptions-and-d...

Poor though my memory is, it happens often enough that I have a decent chance.

[1] https://en.wikipedia.org/wiki/X87#80487

I still don’t know why the addition of the math coprocessor helped so much

https://news.ycombinator.com/item?id=38275340

English Wikipedia isn't very helpful on the regard but I found a page in German [1] that lists a number of 387DX-compatible chips running at 40MHz, so maybe it was just a matter of price, local availability, or lack of trust in the brands.

[1] https://de.wikipedia.org/wiki/Liste_der_x86er-Koprozessoren

You're thinking of the 486.

The 80386DX was the first x86 CPU to be 32-bit and have an on-chip MMU. And nothing else: no cache, no FPU.

The FPU was a discrete part, the 80387DX.

Because OS/2 1.x didn't support the 80386, and so couldn't run DOS apps well, and so flopped, the 16-bit 80286 kept selling well. It ran DOS fast and it could run Windows 2/286 and Windows 3 in Standard Mode which was good enough. It could only address 16MB of RAM but that was fantastically expensive and it was more than enough for DOS and Windows 3.

So, because DOS still ruled, Intel made a cost-reduced version of the 80386DX, the 80386SX. This had a 16-bit data bus, so it could use cheaper 16-bit motherboards and 16-bit wide RAM, still limited to a max of 16MB. Still enough.

That needed a maths copro for hardware floating point, too: a different part, the 80387SX.

Then Windows 3 came along, which was also good enough, and started a move in PC apps to GUIs. Windows 3.1 (1992) was better still.

So Intel had a 2nd go at the 32-bit chip market with the 80486, marketed as the "486". This integrated a better 386DX-compatible CPU core with a few extra instructions, complete with MMU, plus a 387-style FPU, plus a small amount of L1 cache, all onto one die.

But it was expensive, and didn't sell well.

Also, all the 3rd party x86 makers leapt on the bandwagon and integrated the extra instructions into 16-bit bus 386SX compatible chips and branded them as 486s: the Cyrix and IBM "486slc" for instance. This ate into sales of the real 486.

So Intel came up with an ethically very dodgy borderline scam: it shipped 486s with the FPU disabled, calling them the "486DX" to reuse the branding that distinguished the 32-bit-bus models of 386 from the 16-bit-bus.

People don't understand stuff like bus widths or part numbers, as your post demonstrates, and I mean no offense. They don't.

So now there was a new model of 486, the 486SX with a disabled FPU, and the 486DX with it still turned on.

The "SX" model needed a new motherboard with a 2nd CPU socket that accepted a "floating point co-processor", called the "487", which was nothing of the kind. The "SX" was a lie and so was the "487 copro". The 487 was a 2nd complete 486 chip that disabled the original and took over.

But it reused the older branding, which is what you've remembered.

Later, briefly, Intel made a cheaper cost-reduced 486SX with a smaller die with no FPU present, but not many of them. The clock-doubled 486DX2 took over quite quickly and killed the 486DX and 486SX market.

Some commentators speculated that the 486DX vs 486SX marketing thing allowed Intel to sell defective 486s in which the FPU didn't work but if it did that was a tiny tiny number: a rounding error.

https://ardent-tool.com/AIX_1-3/

https://ardent-tool.com/AIX_1-3/AIX_Origions.html

I was using it on period H/W, and in at least one case it was an IBM PS/2 with an 8514 graphics adapter and writing to it using some graphics primitives. The only wonk thing I recall was that if I cranked up the compiler optimizations, it just drew lines at various angles all over the screen instead of the images I needed. IIRC there were a few cranky things about writing directly to the graphics but I don't recall problems otherwise.

AutoCAD was 64-bit floating point (and sometimes 80-bit internally). Trying to do 80-bit floating point computations on a 16-bit CPU was painfully slow. Previous low-end CAD systems were 32-bit, and large drawings would have errors. That's why the Golden Gate Bridge drawing was a common AutoCAD demo. Zoomed out, you could see the whole bridge, and you could zoom in on the details. Big selling point.

(I did some of the early AutoCAD ports. Not all DOS machines were fully compatible with the IBM PC. There were many 80286 machines which were mostly-compatible. Each needed its own software. Every display, mouse, and plotter needed its own driver. Autodesk had a big room in Sausalito with one each of everything they supported. For a while, it looked like the Texas Instruments TI-Pro was going to win, because it had a color display good enough for text. But it was an awful computer. No memory parity and bad parts. I had to compile everything twice and compare the results.)

They are far from the best performers, of course. They are meant to run on low-ish power, especially compared to a desktop or server chip.

You can see a (small) annotated die shot of the M1 here:

https://www.tomshardware.com/news/apple-m1-vs-apple-m14-floo...