12

For PC/AT, 80386, and 80486 machines from the late-1980s through early 1990s (e.g. retro machines, not modern), can you expect to pull a BIOS ROM from one machine and have it work fine in a different machine? What things need to be the same between the two machines for such a transplant to be successful? (Ignore the obvious, such as the ROM's need to be the same capacity, pinout, package type)

Another way of answering might be to explain what things were typically customized by a 'circa 1990 OEM when preparing a BIOS from a vendor like AMI, Award, or Phoenix to work in the OEM's specific machine.

Improve this question
11
  • 2
    Basically no. This is why coreboot.org exist.
    – Thorbjørn Ravn Andersen
    Commented Jun 23, 2020 at 21:45
  • 6
    There is such a thing as a BIOS because machines are not all compatible.
    – dave
    Commented Jun 23, 2020 at 23:56
  • 4
    BIOS idea was inherited from CP/M. CP/M BIOS was the part of the operating system which was responsible for low level functions controlling the actual hardware components. Providing an abstraction layer for the rest of the operating system. While the other parts of CP/M remains almost standart among various machines, BIOS portion was to be adapted to the particular hardware. In summary, BIOS is the hardware specific software designed to provide a standard interface to the rest of the system.
    – wizofwor
    Commented Jun 24, 2020 at 15:59
  • 1
    @Raffzahn Note: when this happens, it'd be great if you could post a question / answer pair – by convention, the question in such cases only has to be a couple of lines. There's a tick box at the bottom of the "ask question" box for this purpose.
    – wizzwizz4 ♦
    Commented Jun 26, 2020 at 11:53
  • 1
    @wizzwizz4 It would be better to have a Blog for such interesting musings.
    – Brian H
    Commented Jun 26, 2020 at 13:10

2 Answers 2

Reset to default
20

How interchangeable was PC BIOS?

Usually not interchangeable at all. Keep in mind, there is no single PC-BIOS, but a machine BIOS. Different CPUs, chips sets and additional hardware need specific initialisation. And, at least for generic DOS, specific drivers.

To start with, plug-in-compatible bios was only a thing for 100% hardware clones, something only true for early PC, PC-XT and PC-AT. Everything else had to have a specific BIOS anyway.

Already during the late 80s AT class 286 machines diverted from IBM hardware. Examples are Chips&Technologies NEAT chisets or Opti's AT-Controller. While they may look as simple VLSI integration of various (Intel) peripherals into a few new chips, they also added more functionality not found before. For example ROM shadowing (for speed), embedded LIM controllers and more.

In the beginning it might still have worked with some generic BIOS, due default values, guaranteed by hardware - except these usually rendered the additions useless. With more advanced memory controllers, even that will no longer work, as here each chip designer went for his own game.

Heck, it already starts with accessing the BIOS itself. With the inclusion of a BIOS setup (*1) the address space needed soon exhausted the address space provided by default. So ROM switching was added. Of course there was no IBM standard to be copied, so chip manufacturers came up with their own ways.

It is the BIOS job to bring all on board hardware into a working state. Set memory speeds, bank interleaving, burst access and more - just for memory that is. And improvements didn't end with memory.

It has become a bit less diverse since more and more components have been moved into the CPUs, so BIOS will find the same 'I/O' hardware on all boards featuring the same CPU (*2), unifying much of the hardware initialisation (again). Then again, While CPU manufacturers provide default designs to Motherboard manufacturers, they do not simply produce them, but tweek it with additional functions, better routing to allow some overclocking or alike. All of this needs to be reflected in BIOS.

In addition, modern BIOS need to provide a (somewhat) compatible UI interface - the well known BOIS screens. Here even more all hardware needs to be considered, as they have to support many modern media alike.

Long story short: BIOS were already not interchangeable back in the days of 8088/286 computers and they are even less today.

Now, for the additions:

"Obviously No! For it could be no other way." That is plainly incorrect.

But it is the way it is. For any other way, some machine independent way of storing configuration details would be needed - but there is none.

BIOS is just code, and code can be data driven. Configuration code is often data driven, and that's not a recent invention.

To be data driven, the data has to be accessible and supplied from external. Neither of this is true, as a BIOS is self contained and uses at maximum external indicators.

Data for hardware configuration was there in the very beginning (IBM PC Model 5150) as simple DIP switches and/or jumpers. This was followed shortly after with the more sophisticated concept of settings stored in battery-backed CMOS memories, with sensible defaults pre-programmed.

Neither DIP-switches not the CMOS did give sufficient data for configuration. They only held parameters for the BIOS to act on, not description of the hardware features and how to handle them.

For example, already with the original IBM-PC the meaning of the SW2 block varied with the BIOS used and had to be checked/changed according to what BIOS to be put into the ROM slots - in so far my above claim of interchangeability for the original PC is already false.

It didn't change with the introduction of the CMOS storage. Here the content was as well depending on BIOS version and on manufacturer. For example Bit 1 of byte 11h was (just a list from my BIOS scratchbook from back in the days)

  • IBM PC-AT: Undefined
  • IBM PS/2: Fixed disk type (whole byte), except if ESDI or SCSI
  • Award AT BIOS: Typematic setting (whole byte)
  • Award BIOS: Password needed for BIOS or BOOT
  • AMI Flex BIOS: Typematic setting (whole byte)
  • AMI Advanced BIOS: Password needed for BIOS or BOOT
  • AMI BIOS: NumLock state after boot
  • (something) NEAT BIOS: Map Memory above 640Ki to above 1 Mi
  • AMI WinBIOS: NumLock state after boot (but other bits differ from above)
  • ... the list goes on for almost a page.

The same is true for many other bytes in there.

Long story short, the CMOS isn't a data enabling device and BIOS independent configuration, but simply a scratchpad used by each BIOS in its own way to keep proprietary settings across a power-off state.

So, a rather fully portable BIOS was always possible, in theory, across machines that were broadly compatible but requiring slightly different hardware configuration or interfacing.

No, as this information was neither part of the 'data' stored in switches or CMOS RAM. They are merely markers and depend on each BIOS.

Bottom Line: Neither DIP-switches nor CMOS contains (standardized) machine, device and BIOS independent information. Their content is only valid for a certain BIOS and a certain chipset compiled by a certain manufacturer.

Doing such would require a storage that describes the machine (like what chips at which ports should perform which operation) in a standardized way and lists the needed BIOS capabilities. But there isn't. all of this information is hard coded within each BIOS image, which makes it only be usable or exactly one setup.

There is a reason that modern OS bring their own basic drivers ... and just think about the huge complexity there is in Linux or Windows, and all of it doesn't help, there's still a need for configuration in multiple steps. It's an illusion that a hard coded system like a BIOS can do this for more than one configutation.

Now, there is some agnostic way (modern) BIOSes operate. For one, they contain way more device initialisation code than their grandfathers and much of this is stored in data tables and run in full or part by generic installation functions, but these tables are not only vendor specific, but also within the BIOS code, so again not independent, external configuration. It only simplifies BIOS coding.

The amount of tables (and code) is configured by the board vendor to suit his needs. So a BIOS from one vendor may not fit a basically compatible board from the same or another vendor. In addition, the core module is as well tailored to a specific CPU or CPU family. So no chance to move a Ryzen BIOS to an Athlon board and even less to some Intel Core something.

As said, that's today's BIOSes with their huge sizes and hidden storage - In the area rewuested the situation was more tight and equally diverse.

*1 - IBM's original PC/XT BIOS didn't need any setup, only the AT introduced changeable defaults - which was done by booting a dedicated setup-disk (or later using some DOS utilities). Clone maker added this as on board functions.

*2 - That's BTW the reason why it's so important to get a BIOS update with new CPU's - they are essentially the whole computer in one module.

Improve this answer
3
  • Actually modern motherboards would be much better candidates for interchangeable BIOS, both because of the switch to UEFI which added a much needed standardisation and by the fact that chipset are now only provided by CPU manufacturers. The only thing lacking would be a plugable subsystem driver. Audio, network, disk controllers ROM code is all bundled in the UEFI by the motherboard vendor, but if it was to be user installable, I don't see why a common UEFI OS couldn't be used.
    – werfu
    Commented Jun 26, 2020 at 11:51
  • @werfu true, but then again, they are still tailored to a certain CPU family and subfamily.
    – Raffzahn
    Commented Jun 26, 2020 at 15:07
  • with retro-compatibility on some socket, it mostly comes down to micro-code updates and signaling configuration. I see sockets as non-crossable generation gap. But, even then, some with some hacking there's been examples of various adaptability. AMD and Intel dont reinvent the wheel every time they produce a new CPU. Most changes are iteration over previous generation. The gap between AMD and Intel won't be bridged though.
    – werfu
    Commented Jun 26, 2020 at 15:41
22

No reason to expect it works at all.

So if the CPU can even start executing the code, the moment where it goes wrong is when there are instructions for a newer CPU, or some chipset-specific initializations are done.

The BIOS is tailored for the specific motherboard, which will have a certain chipset for a certain CPU class, and therefore it also expects certain class of CPU to be present. Sometimes you even need to upgrade the BIOS to support newer CPUs, so it won't work even if you can physically fit the CPU in the socket.

The chipset will need different configuration settings depending on how it is connected to surrounding circuitry, e.g. two 486 motherboards could have different Multi I/O controller (for floppies, serial and parallel ports), or the memory subsystem could have different memory socket types, or different amount of PCI slots, or different amount of IDE interfaces.

Sometimes you even have two revisions of same motherboard, with only minor differences that are not visible to user, like different Multi I/O or clock PLL chip. If they cannot fit the support for all of the differences in the BIOS, then user has to be extra careful to check which revision motherboard it is to flash a correct BIOS image.

Improve this answer
8
  • 1
    That's basically what I was afraid of. If it was common practice in that time period to hard code very specific hardware details into the BIOS code, then any sort of BIOS maintenance is very difficult once the OEM has dropped support for the machine. Right?
    – Brian H
    Commented Jun 23, 2020 at 20:21
  • 2
    @BrianH exactly. It's the worst kind of closed source possible ... hidden deep under many layers of special hardware.
    – Raffzahn
    Commented Jun 23, 2020 at 20:35
  • 2
    I'm not sure the answer to this is quite as much "no" as others have indicated. My hazy memory is in the early days of PC clones (I'm talking 8086, 80286), and the early days of AMI BIOS, you could (a) move from a Phoenix BIOS to an AMI BIOS, and (b) it was the same AMI BIOS that ran on most cheap clones as they all de-facto had the same chipset - or at least sufficiently compatible that AMI ran. My hazy memory also suggests that various cheap clone makers liked AMI BIOS because they ... um ... could "forget" to pay anyone for the BIOS.Once chipsets became more diverse, this changed.
    – abligh
    Commented Jun 24, 2020 at 6:25
  • 2
    @JeremyP It is likely that a BIOS meant for a 286 motherboard contains opcodes that are available on the 286 but not available on a 8086. It is also very common that BIOS tests how much memory is installed, and testing how much memory is available above 1MB is not possible in real mode either. I find it unlikely that any manufacturer would waste valuable EEPROM memory space for a single unified BIOS that supports multiple CPU types, as each CPU type would need the chipset specific code as well.
    – Justme
    Commented Jun 24, 2020 at 8:09
  • 4
    I vaguely remember motherboards (by MSI, late-90's?) that supported both AMI and Award BIOSs, and you could download and flash either one. Still, both the AMI and Awards were tailored to the specific motherboard versions.
    – Jonathan
    Commented Jun 24, 2020 at 12:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .