As a quick aside, on my exploring early OS/2 betas I thought I’d try to emulate the machine that I’d clearly lay the blame as to why OS/2 was fundamentally a failure, the IBM PS/2 model 60.
So IBM machines don’t use built in ROM config programs, but rather you need the reference disk. And this being a Microchannel PS/2 machine you also need the config files to support things like more than 2MB of RAM, the ESDI controller, or even an AdLib/SoundBlaster card.
Adding in the RAM card, and a sound blaster adds the following cards:
However it’s worth noting that the default ESDI config/driver on the MCA confg disk won’t work on 86box. You will need an updated version.
So inside the diag disk the config will appear like this:
I’ve uploaded the reference disk on archive.org here: 86box PS/2 Model 60 Reference Disk : IBM : Free Download, Borrow, and Streaming : Internet Archive.
Unfortunately, at this moment 86Box’s PS/2 model 60 can’t run OS/2. The model 80 however has much better luck. But for anyone who want’s to play Wolf3D on an emulated 10Mhz 286, well this is your big chance.
Reading about IBM PC history, I always found strange that the PS/2 series didn’t had a BIOS Setup built-in ROM, which would end up becoming a rather big convenience in third party BIOSes from Phoenix and AMI for PC clones (And these could even work in the original IBM PC/AT). But hey, IBM didn’t thought highly about the Reset Button, either…
My understanding is that in the MCA based PS/2 models, you had an original Reference Disk that shipped with the system, which was pretty much the equivalent of the BIOS Setup plus Firmware-level Drivers for first party (IBM) MCA expansion cards, which could configure resources like MMIO, IRQ and DMA Channel. IBM keep releasing updated versions of the Reference Disk with support for newer PS/2 systems and MCA cards.
The system configuration data went into a battery-backed 2 KiB SRAM chip, that served as a capacity expansion for the RTC SRAM, which fulfilled the role of storing BIOS settings in the IBM PC/AT in a mere 64 Bytes. However, if for some reason the system configuration data was lost, like due to a dead battery, you had to insert the Reference Disk again to reconfigure the system, since MCA PS/2 systems required to be fully configured during POST or otherwise they refused to boot.
Now, the problem was when you added in third party MCA cards. Those also required to be configured during POST since otherwise the PS/2 would not boot, but they weren’t supported out-of-the-box by the IBM Reference Disk. Instead, what you had was a procedure where you customized your system Reference Disk with those third party Drivers (Sounds very similar to slipstreaming hotfixes or Drivers into a Windows install ISO), then you used that customized Reference Disk to configure your system. At that point, your Reference Disk was unique for your specific PS/2 system.
However, if for some reason you lose this disk and you need to reconfigure the system (Changing Hardware setup, dead battery, whatever), you had to get another Reference Disk, the disk with the Firmware Drivers of your MCA Card, then customize again the Reference Disk, to be finally able to fix your system. And the more third party MCA Cards you had, the more convoluted the process was. Now, imagine a business where you had a fleet of PS/2 computers with slight configuration differences, each one requiring to keep track of its own customized Reference Disk for potential recovery… Seems like a logistical nightmare.
Buy hey, the good thing is that PCI may have learned a thing or two of MCA early attempt at Plug and Pray (ISA PnP was several years later). It uses an always-visible Vendor ID and Device ID identifier unique for each device model much like MCA Cards do with the 4 hex characters string, but the resource configuration is totally generic by nature, so you don’t need explicit support for each different PCI Card type to be able to configure the card basic resources, completely fixing the need for the customized PS/2 Reference Disk.