I have an old, circa 1994 IBM ThinkPad 750C (with a 33MHz Intel 486SL processor) which used to work but now refuses to boot with error I9990303. The error prevents the laptop from booting normally and also prevents it from entering the BIOS setup program, which is fairly unusual—many other errors forcibly enter the BIOS setup.
Note “booting normally”. The ThinkPad can still boot from a specially marked floppy, such as IBM’s maintenance or BIOS update disks. From such a disk, it can boot to DOS, access the internal hard disk or PC Cards, or run Windows 3.1. In other words, there does not appear to be anything too wrong with the laptop.
However, the inability to run the BIOS setup prevents the laptop from being properly configured. This (presumably) also causes the PS2 utility to fail, among other things. So what does this error mean?
The IBM Hardware Maintenance Manual for the ThinkPad 750 says that error I9990303 indicates a faulty system board. It also contains this curious note: I9990303 errors can be caused by exposure to strong magnetic fields.
For newer ThinkPads (e.g. 760), error I9990303 is documented as “Bank–2 flash ROM check
sum error”. It is possible, even likely, that the error means the firmware is partially corrupted. If the run-time BIOS is fine but the ROM setup and diagnostics are corrupted, that would explain why this error prevents the BIOS setup from being entered.
The obvious fix would be to re-flash the BIOS. But… nope, that doesn’t work. The BIOS flash utility requires a charged battery, which I don’t have. However, it does not even get that far—it fails with an error message saying that The system power management is disabled. That is quite likely the same underlying problem as the one preventing the PS2 utility from working. In other words, the BIOS update does not even get as far as checking the battery state, it fails before getting to that point.
And there’s the Catch-22: A non-critical part of the BIOS flash storage is corrupted, which is something that re-flashing the BIOS would almost certainly fix. But the IBM BIOS update tool does not work because of the error caused by the flash being corrupted.
Get Me Out of Here
Is there a way around it? On some systems, there may be way to run the firmware update utility directly, without any checks. No such luck on the ThinkPad 750C: Although the update floppy is just a bootable DOS disk with a custom shell (COMMAND.COM replacement that directly runs the update utility), the UPDTFLSH.EXE tool has no obvious knobs to tweak.
The utility checks all the preconditions and performs the actual flashing. As far as I can tell, it takes no command-line arguments, does not look at any environment variables, and there is no apparent way to control its behavior.
The obvious solution is to modify the update utility to skip the checks. This is of course risky, the checks are there for a reason. Then again… have you ever flashed the BIOS on a desktop machine that didn’t have a sufficiently charged battery? Probably yes, and it worked just fine.
Old systems with BIOS in flash memory typically have no safety, no “boot block BIOS”, and if a BIOS update fails (e.g. due to power outage), the system will be bricked. That’s why laptops often insist on a charged battery, because it is a useful safety in case power is lost (the most likely cause of a failed BIOS update).
But I decided that since the laptop is already broken, trying to fix it is worth the risk. I disassembled the UPDTFLSH.EXE utility, and found it to be doing lots of poorly documented and entirely undocumented things. Luckily, the error messages gave me fairly good clues as to what the code was doing.
The ThinkPad 750C uses a 486SL processor and appears to use SMM (System Management Mode) to implement power management. It uses an interface that is (very) partially documented on Ralf Brown’s Interrupt List. UPDTFLSH.EXE calls INT 15h/5380h with BH=7Eh. This reportedly returns the “SL control port” in BX.
The utility then sets CH, CL, and BL to 49h, 42h, and 4Dh—the letters ‘I’, ‘B’, ‘M’ in ASCII.
AX is (again) set to 5380h and BH to F0h, and then the SL control port returned from the previous call is written via ‘OUT DX, AX’. This is presumably some kind of a presence check.
I am guessing this is the interface to the power management BIOS. It works much like a software interrupt, but it’s triggered by an I/O port write because the processing runs in SMM, in a separate address space.
If the OUT instruction does not set the carry flag (I said it works just like software interrupts!), the presence checks succeeded and the flash utility proceeds to issue further power management requests.
These check whether the ThinkPad is in an expansion unit (for some reason that’s a no-no for BIOS flashing, perhaps because then a power outage can’t be overcome by a battery), and there are other routines which check whether the laptop has a battery installed, and if the battery has enough charge.
As an aside, the ThinkPad 750C is technically a PS/2 machine, much like earlier IBM portables—although it does not use Microchannel like the ThinkPad 700/720 and older IBM laptops did. The model byte of the 750C is F8h (the submodel is 61h), which is a value used by all 32-bit PS/2 systems. It is not the same model byte (FCh) used by PC/AT compatibles, which was in fact also used by the ThinkPad 760 and later models. ISA based PS/2 models are not unheard of (e.g. Model 30), and there were other machines such as the PS/2 E (model 9533) which were 32-bit ISA based PS/2 systems.
But back the flash utility. I just decided to effectively patch out the entire routine at offset CC4h in the first code segment by always returning zero in AX, copy the hacked utility to the BIOS update disk, boot up the laptop and see what happens. The utility was EXEPACKed so it had to be unpacked and re-packed, but that’s boring.
The hacked up BIOS update utility did in fact avoid the power management related error and let me start the flash update process. I let it run, not at all sure what would happen.
After the flashing was done, the laptop rebooted itself and greeted me with this familiar error screen:
A success! The I9990303 error is gone, the BIOS setup can be entered, and the laptop boots normally again. The BIOS can configure everything, getting rid of errors 161 and 163 caused by the loss of CMOS contents. The PS2 utility also works again.
Summary
The I9990303 error on mid-1990s ThinkPads almost certainly indicates corrupted flash memory. EPROMs/flash don’t necessarily last forever and sometimes “forget” a bit here and there. This can usually be fixed by rewriting the contents; unfortunately in the case of the I9990303 error, the problem which would be fixed by flashing the BIOS actually prevents the BIOS from being flashed at all, which is almost certainly an unintentional side effect.
Using a hacked UPDTFLSH.EXE utility allows bypassing the check and flashing the BIOS. Successful flashing eliminates the I9990303 error.
Update (Oct 23, 2026)
Not much later I ran into another patient suffering from the I9990303 problem, a Japanese ThinkPad 750C. This was a tougher nut to crack because for reasons I do not understand, the laptop would not attempt to boot from the floppy drive at all.
That is to say… the floppy activity indicator on the laptop lit up, and the activity LED on the drive itself also lit up, but the drive made no attempt to spin up the disk or move the head or anything like that. I tried a different drive, but it made no difference.
Eventually I remembered that I had a Port Replicator allowing the attachment of an external floppy drive. After plugging in the Port Replicator with an external 2.88 MB drive (the first I could find) connected, the laptop decided that booting from the external drive is fine. I used the previously prepared disk, re-flashed the firmware, and the I9990303 error was gone.
Let’s be charitable and agree that in the mid 1990’s programmers couldn’t think of everything. (In the 2020’s we couldn’t either but we had much more experience to fall back on and perhaps should have anticipated more). This sounds like who ever wrote the code didn’t anticipate corrupted Eproms or corrupted flash.
I believe the full list of ISA-based PS/2 machines is models: 25, 30, 33 (PS/2E), 35. A funny quirk about the PS/2E is that its onboard XGA/2 is implemented on the ISA bus instead of MCA meaning that its implementation is not exactly as fully fledged as when it operates on MCA if memory serves. I have one, been awhile since I’ve done anything with it. I got one of the rare math co-processors to put in it, but, I mixed up the orientation on the thing and some day need to try and figure out how it all goes back together without blowing it up. Even funnier is that its ISA interposer connects to the motherboard –I mean planar!– with an MCA connector.
Regarding bitrotting firmware ICs, it’s been a thing on my mind as well. There are many ICs aside from the BIOS with firmware on them that aren’t dumped (i.e. all of the random ones in the PS/2 Model 95 and its various complexes) which will fail and nobody will have a dump for. Of course… for those ones you have to use an external programmer or desolder them which is dramatically more work.
They did and they didn’t — if the firmware did not anticipate the possibility of a corrupted ROM (however implemented), why would it bother with checksumming?
I am guessing (really just a guess) that the assumption was that if the ROM checksum is bad, the board is toast. They probably did not anticipate the possibility that it could be actually a relatively easily fixable problem.
That list is missing ThinkPads—at least ThinkPad 750 and 755 are also ISA-based PS/2 machines (BIOS model F8h). Unsurprising, as they’re pretty close relatives of the PS/2 E. All the later ThinkPads report themselves as AT compatibles (model byte FCh). I don’t have the full list but while the first ThinkPads (700/720) were real MCA PS/2 systems, the next generation was ISA PS/2. I believe 760 was the first non-PS/2 ThinkPad. ThinkPads 355 and 360 were almost certainly PS/2 as well.
Did you get a backup dump of the BIOS before flashing, to compare and determine if there were indeed bit flips (and how many)?
I didn’t, I was too focused on getting it fixed. I wonder if this guy still has the board with the same problem: https://ret.rocks/index.php/thinkpad-2-3-5-6-7-8xx/700-series/750-series/repairing-a-thinkpad-750-mono
Any idea who was first to market with in-system PC motherboard Bios reflasing?
Recently on Vogons someone popped up with weird (POST codes over LPT, two Bios chips) ICL CL386S system stuck before POSTing. I disassembled smaller payload and it turned out to be an emergency bootblock on UV EPROM accompanying 128KB Intel EEPROM containing main+vga bioses.
BootBlk runs CRC over main Bios and will beep a lot and start trying to load files from floppy if checksum doesnt match. Funnily enough it doesnt run any checksums over VGA part of the flash chip, maybe main bios is clever enough to signal something to the user.
1991 seems pretty early for flashable bios. On the other hand ICL got this computer line together with Espoo factory from Nokia in 1991, who in turn bought Ericsson Group in 1988, and in fact I was able to trace this Bios lineage all the way to Ericsson 6573 from 1988 🙂 I was little disappointed it didnt go further back to Saab who originally sold its
Linköping Datasaab to Ericsson in 1981 :]
Link to BootBlk disassembly under my nickname.
My memory is that mainstream boards with BIOS in flash became common circa 1994, primarily Pentium boards.
I checked IBM because the data is mostly easy to find. IBM rolled out laptops (ThinkPad 750) and desktops (PS/2 E, PS/2 Model 53, updated Model 95 and Server 85) with BIOS in flash in mid-1993. PS/2 Server 295 was not originally an IBM design but it had BIOS in flash and was available in October 1992.
I don’t know about other OEMs but 1991 is definitely quite early for a flashable BIOS.
I have faint memories of reading somewhere than the first Motherboard with reprogrammable Flash ROM was the Intel reference Pentium Motherboard, Batman (PREMIERE/PCI). It does have a Jumper for write protecting the Flash ROM:
https://stason.org/TULARC/pc/motherboards/I/INTEL-CORPORATION-Pentium-PREMIERE-PCI-P5-PCI-BATM.html
Not sure if it is the first, but at least it is the first I know of when I was looking for that info.
Can’t pull out the manual for that board because most retro sites that hosted that are down due to preparing for some critical PHP vulnreability. How is OS/2 Museum doing?
I updated PHP to the patched version a little while ago.
The Intel Classic/PCI (Batman) board definitely had flash BIOS. I can’t quite pin down the release date but it looks like mid-1993, given that “Preliminary Version 0.1” of the Technical Product Summary is dated April 1993 (and it’s certainly unfinished). IBM released systems with flash BIOS at more or less the same time.
Perhaps worth mentioning that Intel was a major flash memory vendor; they certainly had interest in promoting the technology.
I suspect ISA PnP ESCD, possibly interwoven with Designed for Windows 95 logo requirements, is what nudged generic clone baby AT boards to get flash BIOSes as well.
For what it’s worth, it is often possible to reflash the bios with an external programmer. I have only had to do it once but can advise that if using a chip clip, get a good one. I had no success with a cheap one, so happy to name drop pamona electronics as the one that worked.
Possible. EISA machines used additional NVRAM (basically “CMOS”, battery-backed just like the NVRAM in the RTC). I believe that’s where PnP ESCD idea came from. There may have been machines with a separate EEPROM for the ESCD, I guess it was cheaper than EISA style NVRAM at that point. I’m not sure how much flash played into this except that on systems that already had BIOS in flash, it was logical to set aside some flash storage for the PnP ESCD because it basically saved the cost of an additional chip.
I also suspect that at some point flash got as cheap or cheaper than PROMs, and it took less space on the board, so it was attractive to use for its own reasons.
I don’t know about EISA, but I recall than the IBM PS/2 series had an extra battery backed 2 KiB SRAM chip to act as supplementary NVRAM to the 64 Bytes of RTC SRAM (Or 128 Bytes in later RTCs, but the Motorola MC146818 was 64 Bytes total, less than that actually usable by system due to being shared with timekeeping). You sure the “additional NVRAM” was also present on the EISA platforms and not confusing it with the PS/2?
Sure, read the EISA 3.1 spec (can be found on this site). Although the spec does not mandate exactly how it should be implemented, it requires at minimum about 4KB of non-volatile storage for config data.
Dallas DS17485/DS17487 is an example of a chip I believe I saw on EISA boards, it’s an RTC with additional 4K NVRAM.
That circa 1993 Micronics EISA VL/2 board I sent you has a flash BIOS. Too bad Micronics never released any updates.
Looking at my EISA boards, one has a DS1387 and the other a DS1488. Both have the same chipset, so no clue why the RTCs with differing NVRAM.
Did the boards have a different number of EISA slots perhaps? More slots mean higher NVRAM capacity requirements.
Same number of slots on both boards. Both even have the same AMI Hiflex BIOS.
And no onboard devices? The EISA spec requires 340 bytes of NVRAM per device, where each expansion slot counts as one device, the board itself counts as one device, and there can be onboard EISA devices and/or “virtual devices”.
In practice, I suspect the storage requirement was typically less than 340 bytes per device, maybe even much less. Most likely a system with under-spec NVRAM size would work just fine… until a user plugged in several EISA adapters that needed close to the maximum NVRAM storage.
I also assume that OEMs could cheat and not provision the full 340 bytes for the board itself and any onboard devices, since they knew how much NVRAM space those needed and had that under control. But for open EISA slots the NVRAM storage requirement depended entirely on what the user plugged in.
No onboard devices, they are standard Baby AT motherboards with just a keyboard port. The base CFG files for the motherboards are pretty bare.
Also, another early board with flash would be Intel’s Professional Workstation 486 (aka LP486). Being EISA it jogged a memory. The manual has 1991 dates in it, so maybe one of the first from a machine with a ton of firsts. The weird Ethernet and SCSI controllers kind of hold it back (poor driver support) but maybe Claude can fix that like it has so many other things these days. 😛