In my quest to understand the intricacies of x87 behavior and especially floating-point exceptions, I pulled out my trusty old Alaris Cougar board. The system board had a 100 MHz Intel OverDrive 486 DX4 plugged in and worked quite well. I could run applications, edit and compile programs, copy files to and from network, run Windows 3.1, that kind of stuff. No problems really.
But when I tried to test how floating-point exceptions behave, I had a bit of a shock: They didn’t happen at all. The machine just blazed through any and all code that was supposed to trigger FPU exceptions without a second glance. There was just nothing, no exceptions.
In an attempt to isolate the problem, I removed the DX4 OverDrive and used the onboard Blue Lightning CPU with the already installed 387 coprocessor (actually a rare Chips & Tech 387 but that doesn’t really matter). Lo and behold, math exceptions did work.
So I unplugged the 387 and put the DX4 OverDrive back. Sure enough, that did change things… but not exactly in a good way. Now any math exception hung the system instead!
Trying to obtain further data points, I plugged in a Pentium OverDrive instead of the DX4. To my great surprise, math exceptions suddenly worked properly. They did get delivered as expected and did not hang the system.
Trying to make sense out of this, I wondered if the board’s manual might perhaps have some useful information…
And of course, it did. In the chapter about installing an OverDrive processor, the manual says the following:
Remove the co-processor (if installed) at position U26 on the system board. THE PENTIUM™ PROCESSOR WILL NOT OPERATE CORRECTLY IF A MATH CO-PROCESSOR IS INSTALLED.
The manual is a little funny because it only talks about a Pentium, but the board can actually take more or less any 5V Intel 486 processor, OverDrive or not.
After looking at the OPTi 82C499 chipset datasheet, I think I know what is going on there. The chipset has a pin called BUSY#/IGERR# which is either an output to a 486 CPU providing the IGNERR# signal (to ignore math errors), or it is an output to a 386 CPU passing through the 387 BUSY# signal.
I’m speculating that having an inactive 387 plugged in permanently drives the BUSY# signal (since the 387 never gets reset). That signal is also connected to the 486’s IGNERR# pin, therefore the 486 CPU will ignore all floating-point exceptions.
Further perusing the Cougar manual I noticed a rather mysterious JP7 jumper which has positions labeled “OverDrive CPU” (the default, and the position the jumper was in) and “i486DX/DX2 CPU”. The manual offers absolutely no clue as to whether for example a 486 DX2 OverDrive processor counts as “OverDrive” or “i486DX/DX2”. Or what function the jumper actually has.
After moving the JP7 jumper to the i486DX/DX2 position, I was not very surprised to find that math exceptions suddenly started working on a 486 DX2 and the DX4 OverDrive processor.
I should also mention that the board has a JP1 jumper which is open by default and tells the system to use the onboard Blue Lightning CPU. It must be closed if a regular 486 is plugged into the ZIF socket, but it does not need to be closed for a Pentium OverDrive to work.
It also does not need to be closed for some 486 OverDrive processors. The explanation can be found in an old blog post: There were two types of Intel 486 OverDrive CPUs, marked ODP and ODPR. The ODPR CPUs had standard 168 pins and were meant to replace a slower chip in a standard socket, while the ODP CPUs had 169 pins (with an additional key pin) and needed an upgrade socket (including Socket 2/3).
Due to the different pinout, the ODP (non-R) CPUs have a special UP# pin (Upgrade Processor pin) which signals the presence of an OverDrive package. The pin can act as a jumper on properly designed boards. I believe that’s exactly the case with the Alaris Cougar; an ODP (not ODPR) CPU, which includes the Pentium OverDrive, is effectively ‘Plug and Play’ and does not require the onboard CPU to be manually disabled.
On the other hand, an ODPR 486 is electrically the same as a regular 486 and requires the same kind of jumper configuration. Needless to say, my DX4 OverDrive is the ODPR kind, and that’s why it needs the jumpers to be set appropriately, whereas a Pentium OverDrive (which has no ODPR variant) does not.
The Cougar manual makes note of this for the JP1 jumper, but in a somewhat cryptic fashion:
NOTE: If using any Intel OverDrive processor that is compatible w/OD specs (i.e. P24, P24C, P24T) jumper need not be closed.
If you’re a regular end user, good luck figuring out if your, say, Intel DX2ODPR66 OverDrive is “compatible w/OD specs” or not.
On the Alaris Cougar board, closing the JP1 jumper unconditionally disables the onboard Blue Lightning processor. Plugging an ODP (not ODPR) CPU has the same effect as closing JP1 and the jumper can be left open. To use the onboard Blue Lightning, JP1 must be open.
I’m much less clear what the JP7 jumper does. The math exception pins are the same on 486, 486 OverDrive, and Pentium OverDrive processors. But JP7 clearly does something related to math exceptions.
Experimentation shows that when JP7 is not in the correct position, math exceptions hang the system (unless a 387 is plugged in, and in that case math exceptions don’t happen at all). That is in fact true for regular 486 CPUs, 486 OverDrive processors, as well as the Pentium OverDrive.
The JP7 jumper must be in the default 1-2 (“OverDrive CPU”) position for the Pentium OverDrive and for 486 ODP processors. JP7 must be moved to the 2-3 (“i486DX/DX2 CPU”) position for 486 ODPR and regular 486 processors. For the onboard Blue Lightning with a 387, the JP7 position does not matter.
I still struggle to understand why JP7 is needed.
What Have I Learned?
I should have really looked at the Cougar board manual sooner. The reason why I didn’t is that, as far as I can tell, the only problem the superfluous 387 chip caused was that math exceptions did not happen. And that is usually simply not noticeable. The opposite problem with math exceptions causing the system to hang is much more noticeable, but still isn’t usually triggered—although it was, for example, provoked by Norton Diagnostics (which hung while testing the FPU IRQ).
I really wish the board documentation were much more clear about what the jumpers do, rather than giving very vague hints about how they should be set. Though I more or less understand why the documentation is written that way.
And I also understand that things were complicated by the fact that the board and manual came out in 1994, but the Pentium OverDrive was only released in 1995. Predicting the future is always difficult.
Update: As I surmised based on experimentation, one lead of the JP1 jumper is connected to the UP# pin on the socket (the other is GND). Thus the JP1 jumper indeed has the same function as the UP# pin, and that is exactly why it must be closed for regular and ODPR CPUs, but can be either open or closed for ODP CPUs.
Pin 1 of the mysterious JP7 is connected to the pin A13 (FERR# output on a regular 486) on the CPU socket. Pin 2 of JP7 is connected to pin 94 (NPERR# input) of the 82C499 chipset. Pin 3 of JP7 is connected to pin C14 on the socket, which is INC (Internally Not Connected) on a regular 168-pin socket.
Thus JP7 connect the chipset’s NPERR# input to either CPU pin A13 (JP7 position 1-2) or to CPU pin C14 (JP7 position 2-3).
But… once again… I should have RTFM sooner. For reasons that have something to do with the ill-fated 487SX, ODP CPUs have the FERR# output on pin C14 and not on A13. And right there, in the Intel OverDrive datasheet (order no. 290436-006), Appendix B notes the different position of the FERR# pin and suggests that boards should simply wire pins A13 and C14 together (as well as certain other pins), because the pin is always INC (internally not connected) on the “opposite” CPU type.
That answers my burning question: Jumper JP7 is needed on the Alaris Cougar board to account for the difference in FERR# pin position on ODP vs. regular and ODPR CPUs, but other boards may not need such a jumper because the alternative FERR# pins can just be wired together on the board.