Don’t waste money on a math coprocessor they said;

You don’t need it they said!

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)

And almost always I’d get this fun error:

SYS0037: The system cannot write to the write-protected c: drive.

Followed by a crash trying to execute code at the top of the memory MAP (ABIOS?)

Illegal instruction at 0xffffffff

Then ending the program will just crash OS/2. Very annoying!

My goto test of v86 mode environments is an old game that I enjoyed as a kid, 1988’s BattleTech the Crescent Hawks inception.

Infocom’s Battle Tech

It’s a great game, that runs on many 8-bit/16-bit systems of the era, and is surprisingly a very well behaved MS-DOS game. I mean if Windows/386 VGA machines can run it in a window using the CGA version, surely a super early OS/2 2.0 beta (6.123) can run it, right? However I found 6.123 to be incredibly unstable, and sadly not up to the task.

I tried to launch BattleTech over and over and had zero success. I couldn’t figure out why it was struggling on my model 80 board, where it runs just great on 86Box. What is going on?

One thing I had stumbled upon was that if I launched an ancient Infocom game in a DOS box, and then launched BattleTech it had a much higher chance of running. But this did not always equate to it working. How is launching an old COM file from the early 80’s excise the ‘devil’ of some 1988 EXE from running?

IIT 3C87-25

I wasn’t sure but I had this weird suspicion that it was that my system was lacking a math coprocessor. When I had the model 60 286 board in the PS/2 case I did spring for an 80287, and one thing I found is that OS/2 1.0 & 1.21 ran great. As a matter of fact I think it ran better than when I used to have a 386sx-16 and then later a 486SX-20. Now it’s been closer to 30 years, so I could have an absolutely false memory of all this, but I wasn’t sure I was onto something. So while shopping around a subscriber offered me a math coprocessor as they seem to be insanely expensive in the UK. I have no idea why the 80287 was so cheap, and no idea how to make any kind of adapter, but pJok was able to score one for super cheap in his homeland and send it to the barren wastelands of Scotland. As I was wrapping up the SSD G5 fun, the coprocessor arrived, and it was time to install it!

Note the purple 80386! It’s what we might call foreshadowing

The PS/2 8580 motherboard is really oddly designed with chip orientation going in every which other direction, and the 80387 socket isn’t keyed by pin, so it’s vital to see the notches on the silkscreen. Otherwise I just used compressed air to blow out the socket, and run the reference disk to add the processor.


The processor was instantly picked up, although I had the crashing issue with the BocaRAM/2 memory card again, which meant I had to remove the RAM card, re-configure with the math coprocessor, then add the RAM card, reconfigure, then run the util to patch the CMOS so it’d boot up. I really dislike this RAM card, but 32bit cards cost far more than this entire endeavor cost so I’m pretty much stuck with it.

Now let’s compare the Landmark scores between the 286/287 and the 386/ITT387

Landmark System Speed Test with the PS/2 model 60 80286/80287

And now the 386:

Landmark System Speed Test with the PS/2 model 80 80386/ITT 80387

The ITT processor is significantly faster than the old 80287, which is pretty amazing. The system bus is running at 16Mhz, although being 32bit vs 16bit yielding a nearly 2x in performance, although the ITT co-processor is so much more efficient.

Booting back into OS/2 6.123, and yeah now it just works! No fussing around, everything is just great.

I’m kind of lost too, as none of this should require the maths coprocessor, but the results speak for themselves. I used to wonder once I got some disk images for this ancient version of OS/2, why didn’t they ship it? Sure that insane fight with Microsoft on refusing something like Windows on OS/2, or even WLO like Windows IN OS/2 from being part of the product killed any hope of running apps, but this version of OS/2 is already caught in the trap that it can run MS-DOS so well, despite DPMI not being a thing right now.

As I’d mentioned it does run just fine in 86Box, so what is the deal? Well that lead me to look back at when it did crash I noticed an odd string 038600b1

OS/2 6.123 crash screen. TRAP 000e

So what does this mean? Well looking back at the CPU let’s try to decode some of it

16Mhz 80386

First, it’s an A80386-16, which really isn’t that hard to figure out it’s a 16Mhz rated 80386. Next is the revision level, S40344. Searching around we can find this table:

S40276 - A1 (but probably 12 MHz as S40277 is 12 MHz)
S40334 - A2
S40336 - B0
S40337 is B0 stepping
S40343 - B1
S40344 is B1 stepping
S40362 - B1 (20 MHz)

So this places it at at the tail end of the introductory line of 386 processors. Checking over at pcjs, we find that there were quite a few more revisions to the 386.

And further that the B1 Errata is actually quite substantial. Maybe this is why the 386 had such a poor reputation for Unix ports in the day, and why it was shunned by CSRG?

As mentioned in the infamous 32bit multiply bug, this processor had been tested and was given the ΣΣ mark of approval. There are numerous issues listed with the presence of a math coprocessor, I have to wonder if beyond issues for using the full 32bit datapath, if there were some electrical issues with utilizing the full datapath as well? Much like an improperly terminated SCSI bus, did the simple presence of the ITT 387 help with signaling and improve system stability? Or am I hitting some weird bug in 32bit math that is simulated due to the lack of a coprocessor, that once one is in the system, the operation is performed on hardware, sidestepping the entire issue? I’m neither an EE or any good at reversing code, so I really don’t know.

The date code 751 does mean that this processor was manufactured in the 51st week of 1987.

Looking at how ancient this CPU is, I have opted to order one that was made in 1990, an SX218 or D1 stepping.

Although it hasn’t arrived yet, I have to wonder if it would make a really big difference in 32bit system stability? I have to wonder if there was such a massive delay in OS/2 2.0 because of the early 386 processors having so many defects that it just added an undue burden to the development, along with the fighting between IBM & Microsoft. While it would be interesting to see the difference between any of the Microsoft versions of OS/2 2.0, none have surfaced as of yet. Which is a shame.

Although it is nice to have this ‘mid’ IBM beta of OS/2, it does suffer from the ever so common issue of not being able to run any shipping 32bit executable, so unless you have source/object files to link, you are pretty much out of luck. The Microsoft Beta 2 tools are 16bit, so thankfully they run on pretty much any version of OS/2, and they ought to be able to run under Phar Lap 286 as well.

Microsoft OS/2 2.0 tee shirt

One thing that did recently surface on eBay, is a Microsoft tee shirt from their OS/2 2.0 group. With a minor bit of sleuthing, the Enterprise is from the 1989 ‘hit’ Star Trek V. Maybe I’m too much of a nerd to have recognized the GIF.

Back some 20+ years ago when I lived in Miami, I did have a loaded out PS/2 model 80 back then, and I ran AIX on it, as I thought it was really cool. But it was also incredibly unstable. I have to wonder now if it was a fault of the processor, or the system? Then again back then I had 6 registered IP’s and of course my PS/2 was on the internet! Although it was also the right height to double as a standing mouse pad.

So I guess this potentially leaves us with some painful lesson that you ought to get the math coprocessor for older systems if you plan on running anything other than DOS/Windows with a DOS extender. While I do have a PS/2 version of Xenix, I haven’t been able to dump them yet as my Power Mac doesn’t like NON FAT disks. One thing is for sure, it made a massive difference in OS/2. I don’t think 16Mhz/6MB of RAM is anywhere near enough to run OS/2 2.00 at any decent speed so I’ll stick with the much lighter 6.123.

9 thoughts on “Don’t waste money on a math coprocessor they said;

    • Im not sure, other than those errata sheets are so large, that I’m hoping that it makes some difference. Another thing is that I do have a MS-DOS 3.3 boot disk with Windows/386 on it, and the Battletech as well (1.44MB used to be so large!) and it refuses to boot on the PS/2!

      I just received a new(er) 386, a SX218, making it a D1 stepping which hopefully is a lot more stable!

  1. I’d thoroughly recommend reading, this will answer many of your questions about OS/2 and 386 steppings.

    Yes, early 386 steppings were horribly flaky, and it did also impact on Unix support. There were many work arounds included in Windows 95 to account for 386 bugs that were later dropped in 98 as the thinking was few people would be using the system any more. However, I don’t think that’s the main issue.

    You’re using a system unsuited for OS/2. OS/2 earlier than v3 needs at least 8MB. v3 will run in 4MB, but not particularly well. You might get away with v3 or v4 with 6MB for light workloads.

    OS/2 was also rather buggy on release, never mind in beta (even if you are running a build later than OS/2 2.0 LA), and it was only by the time it reached OS/2 2.1 with the 2.11 service pack the infrastructure and drivers had dramatically improved.

    • I know it means less than nothing but in 86box under full emulation, it runs fine.

      Back when it was new and exciting I did run the retail version of OS/2 2.0 on a 386sx 16 with CGA graphics & 4MB of RAM. It did run, DOS box in a window and everything, but yeah it was INSANELY SLOW. But it did run.

      I did get a much newer rev d1 CPU from 1990, so I am hoping that this newer processor makes a world of difference.

      • I’d be surprised if the newer processor made that much difference, but who knows, you’re running a very early beta not intended for widespread distribution, and those could have specific hardware requirements.

        For a generally released OS it’s unlikely any OS up to the mid 90s required an FPU, there were too many sales of 486SX systems (or earlier) and all operating systems had to work perfectly on them.

        Back in the day I started my OS/2 journey with 2.1 on a 486DX with 8MB. That was generally usable, but even so it was using some swap immediately.

        What could have been and the ‘extended’ development times of OS/2 are fairly moot. There was all sorts of IBM bureaucracy and politics, but let’s not forget that NT took just as long, if not longer, to be developed (although they got more of the architecture right from day one).

        Also, if they’d have shipped OS/2 without the Workplace Shell, I simply don’t think it’d have gathered the interest of many people, including myself.

        FYI, the compatibility box in OS/2 1.x looks like actual DOS, but isn’t. It’s customised and uses device drivers that run in both real and protected mode. The compatibility box is a horror that frequently switches between actual real mode to run DOS, back to protected mode, something the 286 was never designed to do.

  2. Getting a math co-processor for any 286, 386 or 486SX was a top priority for me. I noticed it made a big difference in processing not only games but the database and spreadsheet dependent programs I was running. Doesn’t matter if a co-processor wasn’t “required” it still made a noticeable difference. Love reading stuff like this even though I don’t have those old systems any more. Cheers!

  3. The later “Type 2” 20Mhz motherboard was a bit faster. It had cache and supported double the onboard memory! If I’m reading the tech refs correctly, it also supported BIOS shadowing. I wouldn’t be surprised if the 16-bit memory card is bottlenecking things too. An added note, the DMA controller in the Model 80 only supports up to 16MB despite being a 32-bit machine.

    PS/2s in general weren’t all that great in the area of performance. IBM shipped WAY too many machines that were basically souped up Model 50s using the 386/486SLC chips (386SX based, so 16MB RAM limit and 16bit bus). Ironic given that one of the big reasons for MicroChannel to exist was to give the PC a true 32-bit bus. Very few models supported 32bit MCA cards as a result.

  4. The Pharlap 286 DOS extender SDK comes with a program called “tellme.exe” that appears to dump some interesting CPU and math coprocessor details. I wonder what it would have to say about this system.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.