Cool! I'm always fascinated by such things! 😎

SeaBIOS, which can be loaded as a payload, could be a workaround for future UEFI-only systems.
Maybe it could be modified as a wrapper for legacy OSes, not sure.

A bit like DDO overlays in the 90s, maybe.
You know, like EZ-Drive etc.

Thanks for your efforts!
Getting a modern BIOS like SeaBIOS to run in emulators may also lead to other cool results.
So custom "VMs" can be created that match the needs of Win98/XP etc in a better way
or provide rare features not found in most recent proprietary BIOSes.

I see your Farnsworth and raise you a Burns. "Excellent"

We're catching up, still need to find some mug to write a TPM emulation into DOSbox though ready for the big new OS release 🤣

I was working on adding support for the 440BX ports of coreboot to 86Box a long time ago, specifically for the ASUS P2B-LS and P3B-F, two motherboards which were added to the emulation roster in their original Award BIOS form with the intention of adding coreboot versions later. Running coreboot allows for a proper SeaBIOS implementation, with hardware initialization performed by the coreboot side. The Virtual PC BIOS works because it does perform hardware initialization, something SeaBIOS from QEMU or Bochs does not.

The main problem with coreboot is something called "cache as RAM". The early CPU init code uses a feature introduced on P6 CPUs (MTRR) to set aside a small block of cache as a temporary scratchpad RAM, to store the stack and heap for the bootblock C code which then initializes RAM proper. Cache is not emulated because doing so is a huge performance hit to any emulator (we've seen and worked around a fair amount of cache abuse by SiS 496 BIOSes in particular, and so has Dolphin with some Wii games for instance), and therefore a workaround was required to get coreboot past its first C functions, which otherwise read FFFFFFFF from the stack when returning and end up going nowhere. Cache as RAM is also used for BIOS shadowing, as modern coreboot is used to modern northbridges and CPUs which use cache-based instead of RAM-based shadowing.

I could come up with a custom build of coreboot which still performs hardware initialization but uses a dummy "we're an emulator, all RAM is ready immediately" raminit code, but the goal here is to run unmodified builds for those two motherboards. My workarounds (there were a few more, particularly for syncing floppy drive types to SeaBIOS) were ultimately shelved indefinitely because I never got around to discussing a better implementation of the MTRR workaround with the 86Box maintainer; it also wasn't perfect, last I checked there was an initramfs corruption issue with some Linux distros. Now that there is user interest in bringing SeaBIOS to 86Box, this effort may as well come back, but no promises.

coreboot would also allow for running TianoCore UEFI, and I have attempted that, but it required a hack to the machine definition to increase its BIOS size (256 KB is not enough), a hack to TianoCore itself to disable local APIC probing (86Box doesn't do APIC just yet), and a video card capable of 32-bit color such as the S3 Trio64V2/DX or Voodoo 3 (TianoCore assumes 32-bit color no matter which mode you select, and if you select a non-32-bit one, the colors get messed up as seen on tianocore.png below).

Thank you, nice to have something a bit more concrete than just my guesstimates about it 😁
For emulators, there are a couple of other considerations:

• I might be wrong but SeaBIOS doesn't seem very DOS/Win9x oriented. The original BIOSes *should* be a safe bet in terms of compatibility
• The original BIOSes have that sentimental vibe about them (look-and-feel)
• BIOS setup. Okay not much point doing overclocking in an emulator 😁

Btw in addition to emulators, there's the ao486 core of MiSTer that is making use of this BIOS too.
Idk what changes they've made (if any) but I'm sure DOS game compatibility is a concern there.

mr.cat wrote on 2021-09-10, 18:51:

I might be wrong but SeaBIOS doesn't seem very DOS/Win9x oriented. The original BIOSes *should* be a safe bet in terms of compatibility

I wouldn't be surprised if I heard that the SeaBIOS developers aren't all that interested in DOS/Win9x, but I can't recall too many problems with Qemu + SeaBIOS where I had any proof the issue was the BIOS. Do you know of anything it does wrong?

BIOS setup. Okay not much point doing overclocking in an emulator 😁

It does have a mechanism for configuration: https://www.seabios.org/Runtime_config However, it's not interactive - it reads the settings from the fw_cfg device which Qemu presents to it. https://wiki.osdev.org/QEMU_fw_cfg has some information about how you tell Qemu what settings to include and how guest software can read from the device, so you can imagine how another emulator could add support for the device. Another emulator could potentially provide a GUI allowing those settings to be configured, or they could be read from a file, which is certainly not how PCs worked historically, but the nice thing is you can automate it. For example with PCem I could imagine writing a script that generates a machine configuration file, and I already have scripts which can create hard disk images and put software in them which is installed automatically on boot, but I have to manually go into the BIOS setup on first boot before the OS can boot.

Edit: And in fact I would like to add some more settings to SeaBIOS myself, because it provides USB and SCSI support (i.e. interrupt 13h support/boot support) - at least for some of the devices that Qemu provides - which I'd like to be able to turn off.

Anyway thanks, this is interesting work, I have imagined in the past that it'd be nice if some of these emulators could be distributed with free BIOSes.

doshea wrote on 2021-09-18, 08:27:

mr.cat wrote on 2021-09-10, 18:51:

I might be wrong but SeaBIOS doesn't seem very DOS/Win9x oriented. The original BIOSes *should* be a safe bet in terms of compatibility

I wouldn't be surprised if I heard that the SeaBIOS developers aren't all that interested in DOS/Win9x, but I can't recall too many problems with Qemu + SeaBIOS where I had any proof the issue was the BIOS. Do you know of anything it does wrong?

No, not really but it'd be nice to know if there are any real issues (and why) - any ao486 users around?
They'd be among the first ones to know about any breakage I think.

doshea wrote on 2021-09-18, 08:27:

It does have a mechanism for configuration: https://www.seabios.org/Runtime_config However, it's not interactive - it reads the […]
Show full quote

BIOS setup. Okay not much point doing overclocking in an emulator 😁

It does have a mechanism for configuration: https://www.seabios.org/Runtime_config However, it's not interactive - it reads the settings from the fw_cfg device which Qemu presents to it. https://wiki.osdev.org/QEMU_fw_cfg has some information about how you tell Qemu what settings to include and how guest software can read from the device, so you can imagine how another emulator could add support for the device. Another emulator could potentially provide a GUI allowing those settings to be configured, or they could be read from a file, which is certainly not how PCs worked historically, but the nice thing is you can automate it. For example with PCem I could imagine writing a script that generates a machine configuration file, and I already have scripts which can create hard disk images and put software in them which is installed automatically on boot, but I have to manually go into the BIOS setup on first boot before the OS can boot.

Edit: And in fact I would like to add some more settings to SeaBIOS myself, because it provides USB and SCSI support (i.e. interrupt 13h support/boot support) - at least for some of the devices that Qemu provides - which I'd like to be able to turn off.

Anyway thanks, this is interesting work, I have imagined in the past that it'd be nice if some of these emulators could be distributed with free BIOSes.

Yes, good points. In a real physical hardware, the size of flash storage is also quite constrained (with 64kB there's not much room for maneuvering).
In emulators this shouldn't be that much of a problem, so you could have all kinds of emulator specific niceties built-in.
I don't see much sense in trying to approximate the "look and feel" of the old BIOSes, but that's also a possibility.

mr.cat wrote on 2021-09-18, 13:55:

I don't see much sense in trying to approximate the "look and feel" of the old BIOSes, but that's also a possibility.

Whaddaya mean you don't want lurid green and purple menus? 🤣

OT

BitWrangler wrote on 2021-09-18, 20:43:

mr.cat wrote on 2021-09-18, 13:55:

I don't see much sense in trying to approximate the "look and feel" of the old BIOSes, but that's also a possibility.

Whaddaya mean you don't want lurid green and purple menus? 🤣

Please, don't forget their double drawing bug for a truly authentic experience [*] 😉

[*] At least some of these color BiOSes had a double-drawing bug. Everything was painted twice: one time painted, then cleared, then painted again. On particularly slow graphics cards like the S3 86C911 this was kind of a hassle, waiting until the screen painting has finished, before being able to proceed.

BitWrangler wrote on 2021-09-18, 20:43:

mr.cat wrote on 2021-09-18, 13:55:

I don't see much sense in trying to approximate the "look and feel" of the old BIOSes, but that's also a possibility.

Whaddaya mean you don't want lurid green and purple menus? 🤣

I actually think that from a purely aesthetic pov it could be great (consider the talent in the demoscene!), it's just a lot of work for not much practical gain.
The current minimalist approach works quite well and it's fast, too.
But if someone wants to do it, they'll do it I'm sure 😁