I was actually hoping that by the end of the blog post, the mystery of why the game didn't run would be cleared up, but sadly it wasn't. Looks like it had trouble accessing the HDD - but why should HDD access for a DOS game running under OS/2 require a math coprocessor?!
I have my own story of living happily without a math coprocessor for quite some time: from 1992 to 1997, I had an IBM PS/1000 with a "Blue Lightning" CPU which can be best described as a "486SX3" (25 MHz bus clock, 75MHz internal). Then I tried to run the Quake demo and found out that "real" 3D games need an FPU :(
I got a math coprocessor relatively early for my 386SX20 - I wanted to use 3D Studio, the killer app for math processors back in the day! The vast majority of games simply used integer math and didn't require, or could take an advantage from a coprocessor, but I have no idea what was going on in the article. In the early 90s, the only games I can remember that could optionally leverage a coprocessor were the Falcon 3.0 family of simulators.
I remember being tired all day long after waking up many time during the night to check the progress of my renders or to tweak it and restart. And then I got a math coprocessor so I could wake up more often in the night to check my renders.
You lucky. I always dreamt of one, that and a TARGA graphics card. The last one not only for the looks but speed as well. Converting a *.TGA to a indexed color took a considerable amount of time.
I remember "Dune 2" (1992) could use a co-processor? Not sure, we never had a machine with a co-processor but a friend had and he said that at start-up the game said something like "Co-processor found - let's use it!" and then game could run faster I believe (not sure).
> I was actually hoping that by the end of the blog post, the mystery of why the game didn't run would be cleared up, but sadly it wasn't.
My best guess would be something of the following: The software tries to determine if the CPU has a 80(2/3)87 device some way. Thinks it does have it and then tries a FPU instruction to get the error signal firing and getting the eventual INT02 to blow up in it's face. But I'm not limited by any actual knowledge here so this might just as well be something completely different.
My guess is that the Infocom game was setting up some sort of FP emulation TSR and not cleaning it up, and BattleTech was coincidentally using it. Or whatever the equivalent of a windows 3.x VxD is for OS/2, if that exists. Or just otherwise messing with the interrupt tables involved in the arcane x87 protocol in a way that un-breaks things.
That sounds quite more plausible than my idea. FP emulation is always interesting if performed by multiple programs/companies messing with each other's implementation. Lots of fun with layers of interrupts, real/virtual/protected mode switches and all the other magic the original 87 was not designed for.
"I'm not limited by any actual knowledge here" is an excellent way of putting it and I shall endeavour to remember it next time I'm in such a situation.
Poor though my memory is, it happens often enough that I have a decent chance.
My Retro-socket3-toy-unit with a P83@100 MHz is fast (40MHz bus), but the DX5x86@150mhz (50MHz bus) beats everything except in quake. Timings aren't that great for the memory but the synchronous PCI bus (and working PCI VGA card at that speed) beats everything you throw at it.
Carmack and Abrash optimized the heck out of Quake making use of a “quirk” in the Pentium where you can overlap integer operations and floating point DIV to eke out every last drop of performance.
Unfortunately the trick doesn’t work on early AMD K5/6 nor Cyrix CPUs - although Cyrix CPUs probably had other more serious problems.
Yeah. Their perspective correct texture mapping did a perspective div only every 16 pixels drawn – in itself a considerable optimization with almost imperceptible loss in quality – but the big deal was that on the Pentium specifically, the integer pipeline could be almost perfectly cycle-optimized to process sixteen pixels in the time the FPU executed the next perspective division in parallel so the result was ready just as it was needed!
K5/Cyrix could overlap Integer and FPU operations, what they couldnt do was interleave (pipeline) FPU operations so that multiple floating point instructions ran in parallel.
Part of that was the bus and memory speed as well. The 486 bus ran at 33 MHz (the "DX4" is actually only clock-tripled to 100), while the Pentium bus and memory ran at 66.
Yes, I know. Setting the jumpers for the right bus speed for the multiplication was key. This was the time of the fine tuning and over clocking. Asus boards were the best for this job back then.
Yep. The P5 arch (original Pentium) superscalar design, combined with its much faster FPU and separation of data and code caches meant it could run circles around a 486-based CPU, even if it was running up to twice the speed of a 486 contender.
My parents were architects and they used AutoCAD. A very early version, maybe 3? So our PC had a math coprocessor... on a 286!!! Yes, the 80287 was a thing.
In the 286 era there were even different types of co-processor, the Weitek implementation (2167) absolutely trounced the official 80287 (and it's second source versions) at CAD, that's most likely what your parents had.
They had one (4167) for the 486 too, I have no idea if it only worked with 486SX systems, or if it could work alongside a DX (but then who'd have a co-processor socket on a DX board anyway, co-processor sockets had already become scarce in the 386 period).
By that era they appear to have mostly pivotted to their own 486 clones and VGA chipsets though.
edit: I just realised, it could have been like the Cyrix 487S which installed as a PCB carrier that plugged into the 486DX socket, and then had a socket on the carrier for the CPU itself, alongside the 487S chip.
The suggestion in the article was simply that his 386 was a crappy early one that may also be slightly defective seems plausible. IIRC the 387 was a full 386 plus the floating point logic, and when you installed it the coprocessor took over most of the processing and the 386 was reduced to being a data broker.
I believe the 387 was an actual coprocessor; the _487_ may be what you're thinking of -- the 487SX contained a whole 486DX inside and just disabled the host processor [1].
I would concur: The 386sx was just 16 bit. The 387sx was for that 16 bit processor. The 486sx was no math co-processor, and the 487 was a whole 486 DX, i.e. the vacancy slot, brought to you by Intel Marketing.
Or installing the coprocessor reseated a slightly-loose cable or created a better connection on a broken trace. The "boot step" could simply result in the system being warmer, which would make marginal connections like this behave differently.
To be sure, the author should remove and reinstall the coprocessor 10 times, testing after each. :)
I replaced the 386 today with one from 1990. I was able to boot a disk I keep around that has MS-DOS 3.30a and Windows/386 2.11 on it. I also have Battletech on there and yes it ran with no issues! It didn’t work at all on the older processor.
When I pushed it into the socket it made such a loud “ker chunk” noise that I wouldn’t want to constantly pull out and reseat these chips. Especially since I don’t have the Intel “rake” like puller I had to use a pair of card edge blanks to gently rock it out of the socket.
Although I do appreciate the 10x humor of it.
It’s weird that so many people focus on the software, which runs perfectly fine in emulation, but seem to lose their minds that an $8,000 machine from 1987 shipped with a buggy CPU…
Hopefully this tbh t will encourage someone out there with a 386 to try to replicate this.
My father wanted a computer for doing CAD, so of course he needed a 387 beside the 386.
From what I remember, unlike the 386, for which both Intel and AMD models were available, the 387 was produced only by Intel, which meant that the cheaper and more performant 40MHz AMD processor had not a corresponding FPU, so if you needed floating point operations you had to spend more money for a slower CPU.
What he ended up doing instead, was to get a relative to assemble him a PC with a 40MHz AMD 386 and a 20MHz Intel 387. Surprisingly it did work, as long as one would remember to press the "Turbo" button to slow the 386 to 20MHz before using the CAD software otherwise it would crash.
The rest of the software would happily work at 40MHz
IIRC, the 386 and 387 were exactly the same chip. The difference between them being the 387 had an activated math processor while the 386 did not.
If you plugged in a 387, it would disable the 386 chip and take over all the work of computation. Apparently, happened because the math coprocessor was where most of the manufacturing errors occurred so Intel just sold the defective chips as 386s in order to increase throughput
I think you're thinking of upgrading the 486sx which didn't have the on die coprocessor. That did disable the old chip as you basically replaced it with a 486dx
You're wrong, and so is the first comment. Sorry (and to @KayEss).
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.
You have a typo of "486DX" in your first line introducing the 486SX.
>> 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.
It was a significant amount of chips at the time, since the 486 was still new and the FPU is somewhere around 30% of the die, it would come out to a lot of them. They was also an overlap of the DX die with FPU disabled and SX die both being shipped at the same time.
> You have a typo of "486DX" in your first line introducing the 486SX.
You're right -- but I can't fix it now. :-(
> It was a significant amount of chips at the time, since the 486 was still new
It might have been. If you have any pointers to numbers, I'm curious.
But when the 80486 first appeared, it was just the "486". The DX/SX thing came later, and the early 486SX units definitely had a full FPU on the die -- I remember X-rays, de-capping, and die-shots.
I just checked and the gap was longer than I realised:
(80386, 1985)
(386SX, 1988)
i486, 1989
(Windows 3.0, 1990)
486SX, 1991
486DX2, March 1992
(Windows 3.1, April 1992)
Just a year between the 486SX and the DX2, which rendered it largely irrelevant -- then, the budget option became a non-clock-doubled model, and the clock-doubled one became the premium product.
It is a different game to play according to crossing the chasm. There were 8087, 80187, 80287 and 80387 is the last one. I do not know that only intel has 387 though.
That's interesting. I specifically remember buying a math coprocessor for my AMD 386DX-40. My motherboard definitely had the slot for a dedicated co-processor though, maybe that was the difference.
I was a kid listening to "grown-up talking" so I could remember the wrong reason for the funny pairing, or maybe I'm getting old :-) (it's been 30+ years).
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.
I remember the day I got my AMD 287 co-processor for my old Samsung 286. IIRC I ordered it from an ad I saw in Compute! magazine. At the time I had this book about writing fractals in C and I went back and recompiled all my code to use the co-processor instead of the emulation library that came with Turbo C, what a revelation. These days I only buy CPU's with math coprocessors.
Huh, this reminds me my raspberry pi pico has no fpu, being a pair of cortex M0s. Maybe I should buy a recent teensy, which has the cortex M7 with an FPU.
Oh man I used to love BattleTech on the '286! (Yes we had a coprocessor, doubt it mattered).
I kinda wondered why no one made RPG games in the BattleTech universe? The MechWarrior series was fine, but there's so much plot and intrigue that could be explored in this universe, and just _existing_ as a human around all these big machines could be pretty intense.
Another fun fact - I cut my teeth as a little kid hacking my BattleTech (Cresent Hawk Inception) save games in XTree-Gold. I can still remember the ASCII symbols and the rough layout of the save files. I'd max out my teams stats and skills, stick extra weapons on our mechs (they even programmed in powerful ones that weren't actually in the game) and mark the map as explored. EDIT: I even got so much money it would accidentally wrap around when you got some interest from the bank or whatever (it was some small signed integer type) and then you couldn't spend anything, lol.
This is tangential to the article and somewhat meta, but as I remember old video game cover art and ads (and seeing the pictures in the article), it occurred to me that we're finally at the point where (sometimes) the actual game looks as good as the cover art. That's a pretty remarkable achievement!
While playing around with modern NetBSD on a system with just 10 megabytes of memory, I ended up getting and adding an m68881 just so that I could remove the floating point emulation code from the kernel to save a few kilobytes.
OTOH, who doesn't like to toy around with the power to do 100,000 floating point operations a second? ;)
I do hope the author figures out the cause. The issue is an interesting one.
Strange error, why does it say "illegal instruction at ffffffff" but then the dump shows CS:EIP as 71a3:000056e5? Shouldn't the EIP part be :ffffffff or what am I missing?
The person in that photo has a very Moss-esque esthetic ;)
The m68881 and m68882 are very good FPUs, and m68882s have continued to be made all the way through at least 2012, apparently. I recently bought one that was made in 2012 with Motorola, not Freescale, markings.
The Mac Plus could take a 68020 Accelerator board, and mine came without a co-processor, so... I found a 68882 with a missing pin, and soldered one on. It worked like a charm. Wait... Apple SANE did not come out until the Macintosh II... OH! You made a joke. ok. a Cray-X-MP/48 is a math co-processor for a Macintosh.
That's about where it starts to lose coherency. There were dual-core 32-bit chips and so on. I'm also eliding changes in core design such as scalar, superscalar, decomposition into micro-operations, micro-op resequencing, etc. because:
[1] it muddies the waters.
[2] if people can't remember the difference between a 387 and a 487 then this will go way over their heads. :-(
That was probably down to having a Blitter, rather than mathematical performance. This was a memory copy function in one of the support chips (Agnes), that massiveky speeded up things like sprite and window movement and line drawing.
Did the a1000 have hard floating point? I know it had a great f18 flight sim that seems like it would have been difficult with integer math, but people do amazing things with integer math.
That was still true with VLB(VESA Local Bus) and later revisions of the Tseng ET4000 chipset. Which was what made the SpeedStars fly. (At 50Mhz! Harr!)
I had the Maxis game El-fish, and the part of the game where you'd breed fish was almost unplayable on a 486SX because the SX lacked a math coprocessor. I wanted a math coprocessor, but as a kid in pre-internet times, I had no clue how to get one.
Maybe I'll try playing in dosbox and see what I was missing out on.
Technically, you had one on the 486SX, it was just disabled. Probably*
As I recall the "co-processor" slot on those boards was another CPU slot, with an extra pin; and when filled it took over and disabled the original CPU.
My guess is that if there’s any truth to it that was early on before the process was fine-tuned. It’s hard to believe Intel would have tolerated a process producing that many errors since they could use the same die space to make more smaller chips.
Seems perfectly plausible. CPU binning has been being done for years. Made an 8-core chip, but one core is faulty? Disable some cores and sell it as a 6- or 4-core chip. Chip won't run at the frequency expected? Sell it as a lower-spec CPU.
intel used to sell cheap core solos back in the core duo days, which were just duos where one of the cores was faulty so they disabled it.
Same with the F model (no iGPU) chips today. People have done teardowns and found that more often than not its there on the die, just disabled because its faulty.
Good memories. I had a Quantex 386 DX 40 with a math coprocessor. I used to churn out 3D Studio images one rendered block at a time over hours and hours and hours.
And I remember downloading 3D rendered images from BBSes back when I couldn’t produce them myself, was a kid at the time and 3D Studio was way above my abilities or computer power, had an XT then an 286 AT. Good times
Don't ever believe them: I was taking Pascal, and had just switched from a Prime computer to a PC for a large program. I had to finish some major part over the weekend, so I went to my brothers house. He had a co-processor, and Turbo-87 was hell of faster, so back at school, I snuck into the physics lab w/ 8087s and programmed there. When I got my own machine a few years later, I went out of my way to get a 8087 turbo. Lotus 1-2-3 and Turbo pascal ran amazingly fast. Six years later I got a hand me down 33Mhz 386. Upgraded the ram, the processor to 40Mhz, and got the co-processor. (ITT 87-II) again, with the math co processor, amazing speed. Finally got a hand me down 486 to replace the 386, and KaChing! It was not a 486 it was a Pentium Over drive w/ co-processor. Got into AutoCAD at that time, and ... people in the lab were complaining that there were no co-processors. I could not tell them that it ran much faster on my machine at home because they would know where I got the software.
My first computer was a Tandy 486sx from RadioShack. One day I brought home the book "Becoming A Computer Animator". It came with a disc containing a copy of TrueSpace. But I couldn't run it because it required a math coprocessor.
My dad was not a computer person, so he was not very thrilled about us opening up this mysterious box. But, he agreed, and together we installed the chip. And the software worked!
One thing that was amazing back then was the step-function of upgrading your computer. At that point in Moore's Law, big updates weren't at such a ridiculous pace as they became over time, so if you had a 486, you had a 486 for a while. But add a SoundBlaster card (or the AdLib card for us lower-middle class folks), and suddenly your computer came to life in a way you didn't realize was possible.
It's not surprising that the PS/2 model 80 would have MS-DOS games compatibility problems, even if running PC-DOS or MS-DOS rather than OS/2.
The Model 80 was one of the first-gen PS/2 systems (which tried to replace the original IBM PC's fairly open industry standard architecture with things like MCA).
IIRC the Model 80 was also IBM's first '386 PC, though IBM had been beaten to the '386 PC (first by Compaq and Advanced Logic Research, IIRC).
Also, for a long time, MS-DOS games didn't necessarily work out of the box even on more conventional PCs, and you might have to mess with drivers, IRQs, etc.
One of my first paid jobs was in the summer of my college freshman year, 1988, I did some consulting work for an insurance salesman. He had an ibm 8086 based machine and it was taking 15 hours to run an insurance estimate.
I got him an 8087 math coprocessor and it reduced the time to about 10 minutes. I think it cost around $500 at the time.
I made my first $50 in tech, an his business was demonstrably improved. What a thrill!
> Well it’s been no secret, but OS/2 6.123 on my PS/2 model 80, is insanely unstable running simple MS-DOS based games (large EXE’s)
Lost me here. I developed several systems based on OS/2 (both 16 and 32 bit) and don't recall this kind of stability issue. Different use case, I guess. I was using IBM's C/C++ tool chain and did some scripting in REXX, no big DOS games.
I know everyone has super rose tinted glasses when it comes to OS/2, but try it on period hardware, with what shipped in 1987. Its terrible. And yes it runs great on Pentiums or anything new under emulation as clearly the larger fault is 1987 hardware, namely the 386.
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.
I'd suspect PS/2 compatibility problems, or "old machine" problems like dust in the empty socket that no longer makes contact when the socket has been filled with the FPU chip.
PS/2 systems weren't fully "PC compatible", there was lots of stuff they would have trouble with. They had different port ranges and the BIOS had some infelicities as i recall.
AutoCAD for DOS shipped at some point with a cool NASA Space Shuttle demo, I remember seeing it render (can't remember if on a 286 or 386) without a co-processor and it took several minutes, as each line slowly rendered on screen.
The same demo with the same machine now equipped with a co-processor, it took just a few seconds.
As a kid, I knew nothing about FPU nor math co-processors but that incredible speed bump had a long lasting impression on me.
AutoCAD was supposed to require a math co-processor, but there were software co-processor emulators available which could, slowly, do floating point. That's probably what you saw.
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.)
I remember my first Mac lacked a math coprocessor. It was the Motorola LC68040, and it came with Quadra 604. I seem to remember it making Excel slow at doing some calculations. My next Mac was a PowerPC, I don't remember any of those lacking math coprocessors.
A whole range of CPUs have integrated GPUs, but nothing on the high end.
I think there are technical limitations re. die size and heat dissipation if we wanted to integrate a high end CPU and a high end GPU in the same package.
Precisely this. Most modern CPUs would be better called SoCs, with CPU/GPU/XPU cores all on a single package. If you want any sort of stopping power in terms of the number of cores or the clocking speed of said cores, you need massive amounts of cooling, hence why GPUs are sold as bulky PCIe cards.
I've often thought Intel kind of ignored the discrete GPU market for so long because they just assumed they would eventually absorb those functions into the CPU like they did with everything else.
Current CPU vector instruction sets are as good as the ones on GPUs and they also have tensor/matrix instructions comparable to the ones on GPUs.
However, usually CPUs don't have enough cores and execution units to compete with GPUs, because they spend the transistors on out-of-order execution, cache and other features instead.
Intel Larrabee was the only attempt to actually make a CPU with a GPU-sized vector unit and they dropped it.
Wow. This is interesting. It used to be everything had to be on die... then on package... and with recent architectures, multiple dies, multiple processes... things are again exploding.
You read the article which is cool, but Wifi was on chip set during the Centrino days, then WinModems ( blows chunks ), and now we have Wifi/BT/Audio/Kitchen sink on chip.
>> The AC 9560 and 9460 family of wireless (Wi-Fi + Bluetooth) modules are the first generation of CNVi modules.[3] They are only compatible with systems running Intel Gen. 8 or 9 processor on adapted motherboards.
I have my own story of living happily without a math coprocessor for quite some time: from 1992 to 1997, I had an IBM PS/1000 with a "Blue Lightning" CPU which can be best described as a "486SX3" (25 MHz bus clock, 75MHz internal). Then I tried to run the Quake demo and found out that "real" 3D games need an FPU :(