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.
Cougar Jumpers
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.
Tracing the connections on the jumpers might help you figure out exactly what they do. It helped me to figure out why someone installed the jumpers “wrong” in one of my boards (they did it to disable NMI so they could use non-parity RAM).
Unrelated, did you ever get the Blue Lightning to cache more than 16MB?
I’ve not tried the cache settings, but I did see your comment about it. I mostly have an Intel 486 or POPD plugged into the board.
And yes tracing the connections is probably the only way. One day I’ll have to do it, because I really can’t fathom why they have the JP7 switch at all.
Sometimes its impossible to RTFM for some things because there isn’t a manual. Many obscure BIOS settings are glossed over in the manual, if they are covered at all. AMI’s old FTP site used to have WordPerfect 5 formatted reference manuals for common options in their BIOS cores and supplemental manuals for many of the chipset specific options.
Even when there is a manual, it might have 1,000 pages and reading the whole thing just in case the answer might be there isn’t practical.
BIOS manuals are my pet peeve. A lot of the time I get the impression that the people writing the documentation knew a lot less than I do. Far too often, there is no explanation what the option does, and no hint as to how it should be set. Knowing what the options do exactly, and reading the chipset datasheets, usually gives one a decent understanding. But that’s not in the BIOS manual.
Well, there it is (see blog post update). Now I know why JP7 must be configured properly, and why it’s kind of redundant. I could probably just wire all the three JP7 pins together.
That leaves me wondering why anyone thought the jumper would be necessary.
Were they expecting a CPU to use both pins at once? Some Cyrix CPUs could do that, but only after software intentionally enabled the extra signal – pin A13 would float otherwise. (Maybe someone thought the SUSPA# output had to be enabled to use suspend-on-halt?)
Or were they just being overly cautious? The Pentium Overdrive relocated six signals, but FERR# is the only one that didn’t move to a completely new Overdrive-only pin.
BIOS manual: “Parameter X has two values: Enabled and Disabled. Putting parameter X to Enabled enables X. Putting parameter X to Disabled disables X. Good luck!”
Was “the Intel OverDrive datasheet” available at the time this board was designed?
And also, did every other 486 compatible CPU manufacturer guarantee that the relevant pins would be either NC or that particular signal?
To me jp7 sounds like some sort of extra precaution from the board manufacturer, perhaps not trusting (possibly preliminary) documentation.
That’s the thing. The OverDrive datasheets were certainly available, including the Pentium ODP (PODP) documentation — but while 486 OverDrives had been on the market since the early 1990s, the PODP was not available until early 1995. The board was almost certainly designed without even engineering samples of the PODP.
The PODP 238-pin socket was documented at least as far back as February 1992, 3 years(!!) before the actual PODP became available. In the older datasheets I can’t find any clear statement about the FERR# pins.
So I’d say the Alaris Cougar designers were probably cautious but not overly so, because most likely the datasheets available to them didn’t make it clear that it’s safe to connect the two possible FERR# pin locations. I doubt they were worried about Cyrix 486s all that much, although the Cx486 was available in late 1993. The board manual makes no mention of CPUs other than Intel (and the onboard IBM Blue Lightning).