17

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.

2
  • 1
    (1) How did your add-in card, with its own BIOS, take over the ISA bus? Or did it? (2) The BIOS goes through a bunch of steps. Back then, there were pretty standard codes that were written to an I/O port as the BIOS proceeded. You can get a tiny card with 7-seg displays to show where the BIOS is at. Did you ever use such a card to write down the BIOS step numbers as they proceeded? (3) BIOS, at that time I believe, may have had to size and configure DRAM in the chipset. It's possible the internal vs external bus CLK may lend confusion and therefore delay in configuring. I don't know, tho.
    – jonk
    Sep 18 at 22:56
  • 2
    Likely because the CPU is unrecognized, the BIOS does not enable the cache. This will easily cause it to "freeze" for minutes (or worse!) during boot. I once debugged a Win95 machine the owner thought was dead, which turned out to have had cache disabled in the BIOS setup. Before finding that, it finally showed the Windows boot screen after about 45 minutes sitting with a blank screen, and at that point I knew what the problem was and fixed it right away. Sep 20 at 3:34

1 Answer 1

14

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.

6
  • 5
    Minor quibble: a BIOS written for a 486DX (even DX2) wouldn’t use CPUID since that wasn’t available on those CPUs. The id is available in EDX on reset but it’s difficult to use (when the system starts, there’s no usable memory in which to store the value). Sep 19 at 6:16
  • 2
    True, the CPUID instruction was not available on early 486 CPUs, including various DX2 models, but it is available on later 486 CPUs, including various DX2 models. And some BIOSes, such as on IBM PS/2 computers, are reportedly capable of storing the CPUID reset signature for later use.
    – Justme
    Sep 19 at 6:41
  • 2
    I once encountered a machine built with a 486DX, where the dealer had dropped in a DX2 before selling it. The machine worked, but was very unreliable. Since it was only used to run the software I supported, the software got the blame, after the dealer and the manufacturer had been unable to fix the problem. That particular AMI BIOS ran the ISA bus at a fraction of the CPU clock. It was set up for a DX/33, but fitted with a DX2/66, and was trying to run the ISA bus at 16.67MHz. The disk controller was on the ISA bus, so the surprise was that it worked at all. A BIOS reset fixed it. Sep 19 at 15:49
  • 3
    @JohnDallman Interesting, as both the DX/33 and DX2/66 run at exactly same FSB speed of 33 MHz so ISA should run at 16.67 MHz in both cases. Likely the IO wait states got increased after restoring default settings.
    – Justme
    Sep 19 at 16:37
  • 1
    @RonJohn It is unfortunate you find it unsatisfactory, but that's the point, any code with a timing loop can fail spectacularly when you run the code faster than any programmer has defined/determined/tested it to run. I find it plausible, and I don't claim it is 100% sure, because you would need to disassemble the BIOS to see what the issue is. Same with how adding larger than expected hard drive can hang the machine, for a stupid reason how it calculates the drive size for printing it as a human readable ASCII string. Which means, newer hardware causes new cases not expected before.
    – Justme
    Sep 22 at 10:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.