Why would installing a 486DX2 make the system freeze for minutes on boot?

Question

In the mid-1990s, a friend of mine had one of those Compaq Presario desktop PCs that had an integrated CRT SVGA display built in the same cabinet as the CPU, in a similar fashion as the early iMacs. The machine has long since been disposed, and I have no record of the model number, but it was equipped with an 80486DX processor (can't remember the CPU frequency either).

Back in the day, the machine had started to show its age when it came to performance, so my friend and I decided to give it a little life extension by replacing the original 486DX chip with a 486DX2. This was, of course, not officially supported by the manufacturer, and there were no visible mainboard jumpers or BIOS settings for setting a CPU model or clock rate, but the chips were pin-compatible and the bus clock would stay the same, so we expected no trouble and went on with the upgrade.

Of course it wasn't going to be that easy. When the box was put together again and powered on, the system would not boot. The CRT and fans powered up, but there was no picture or disk activity, nor any beeps from the system speaker. The computer was as good as dead.

After a moment of troubleshooting and part-swapping, we established that the machine would still work normally with the original CPU – so at least we hadn't fried anything – but reinstalling the DX2 likewise restored the problem. We thought that the DX2 chip was probably defective, and now someone would have to take it back to the store for a replacement.

Luckily, we didn't care to turn off the power while contemplating our next move, so suddenly we were greeted by the unexpected: after minutes of complete stillness, the screen sprang into action, going through all the usual MS-DOS startup texts followed by a completely normal start of Windows 3.1, which now felt seemingly faster, just as you'd expect with doubled CPU clocks. No error messages anywhere; anything worked just perfectly.

Further testing showed that anything indeed worked as expected, except for the annoying ~3 minute wait before OS entry that was the same with power-on cold starts and Ctrl-Alt-Del reboots. As the performance was notably improved over the original 486DX once the system eventually got up, my friend decided to accept the affair and keep the DX2. Later on, I tried the system with an add-on IDE interface card which had a BIOS of its own, just to see where the delay occurred in time related to the OS entry (the card's BIOS would display a summary of attached HDDs on the screen during boot, which was useful as the computer's own BIOS didn't show any messages – not anything I'd remember, anyway). The result was that a blank screen would show for the first ~3 minutes, after which the add-on card's BIOS messages appeared and the OS was started.

So for the actual question: What could have caused such a long delay before OS entry when a "fully compatible" 486DX2 processor was installed in place of the original 486DX? I assumed – and still do – that the doubling of the core clock in a 486DX2 was accomplished fully internally inside the processor, thus being electrically invisible to the host bus and the rest of the system. I can't think of anything else than an overly assuming BIOS timing loop of some sort banging the CPU, but I'm not sure whether that is a plausible reason considering that there were no error indications of any kind (not even beeps) and the fact that the system eventually did get to proceed past the wait. I never clocked the length of the delay with any accuracy, but it always felt quite the same, and the system never failed to proceed after it.

Answer 1

There might be a timing loop calibration in the BIOS which is responsible for working with different speed CPUs to have similar delays.

Or the BIOS tries to determine the CPU type with the CPUID opcode, and it returns a value that the BIOS does not expect.

This ID may be used without checking to do further processing, like using the value to fetch data from a table. For example, the table might be used to print a CPU type string such as "486DX" and there may be no entry for "486DX2" if it did not exist when the BIOS or the PC was made. Such a table could be used to load some delay calibration values as well, so it might load wrong calibration value or use default, and it just waits for a really long time.

So to support newer and faster CPUs, a BIOS update might be necessary, to properly support a faster or a newer type of CPU.

Regardless of what the actual issue is, it was very common that BIOS or any other code that detects CPU speeds will work wrong or just stop working because it can't handle a faster processor.

Newer and faster processors make the code run at speeds not originally encountered so it is not expected or tested to work with a faster processor.

These kinds of problems can be caused in many ways. Either just hang the machine due to division by zero, or division by a number that makes the result not fit into the result register or variable, so calculated values are simply wrong.

Answer 2

The Compaq Pissario(as we called them) was a stunted home version of the Deskpro(not a great system to begin with). One of the ways that money was saved on them was not providing much if any L2 or even L1 cache on the system board. It really didn't matter how fast the processor you used was because without that cache there was a huge bottleneck between the processor and the memory.

The other issue you could have been seeing is a clock speed issue where you are drastically underclocking the faster processor. Once again these were budget systems and didn't have functions that more flexible motherboards of the time supported. So if you replaced a DX/25 with a dx2/66 you lost about 17% of the expected performance right off the top.

To get functional use of a Compaq Desk Pro, stand two on end, put a door across the top and use it as a table.