VOGONS


First post, by mr.cat

User metadata
Rank Member
Rank
Member

(Cue prof. Farnsworth voice:)
Good news, everyone!

This oughta be interesting to someone (hi, digger!) 😁
First things first: "progress" here simply means results other than black screen, sorry to get your hopes up 😁
And apologies if this is old and boring stuff. If that is the case, please share your experience with SeaBIOS 😁

In the PCem v17 thread, there was a little bit of talk about the possibility of using SeaBIOS for booting.
It's interesting for emus because it has a nice license, so it could be distributed easily (but ofc there are other interesting aspects about it).
Since SeaBIOS supports the 440FX chipset (which is also used by Bochs) that seems like the easiest one to start out with.
PCem does offer Intel VS440FX, but I had no luck with that. So I turned my focus to 86Box next, where there's a bit more variance on the 440fx front.

Yep you guessed it...long story short, it sorta works!
I see some Bochs startup messages, it then bombs out with "Press F12 for boot menu" followed by "FATAL: No bootable device."
So yes some pieces are missing, but to me this was a nice and welcome surprise indeed.
I originally assumed there would be more to this than "just" chipset support (well maybe there is - I don't know what magic goes on behind the scenes).

Here's the guest hw :
Tested virtual mobos: Gigabyte GA-686NX (aka 686nx), Acer V60N, Micronics M6Mi, PC Partner MB600N, ASUS KN97 (others probably work if you get the BIOS files sorted).
Also tested with a i430VX one: Shuttle HOT-557 and that one also works.
Pentium or P2 Overdrive, 8MB
EGA
(PCI Cirrus Logic CL-GD 5430 also works, probably other VGA too)

Note that I didn't do any special trickery here, I just copied the "BIOS-bochs-latest" (MD5SUM: 6e0d2b4b4f64a6a085001139f904e3c3) from Bochs to the roms/machines/686nx directory (replacing the original 6nx.140 BIOS file there). Also if there are related cached files in the "nvr" directory, they need to be removed first.

Btw I'm on Linux which means I have to use Wine to run 86Box, but it seems to work well enough for the purposes of this test.
Now a boot BIOS isn't very useful if it isn't, you know, actually booting. So any progress on this front would be welcome!

EDIT: So I'm late to the party it seems. OK so initialization is an issue, but somehow it isn't an issue for coreboot?
https://github.com/86Box/86Box/issues/120
Also I noticed there's now "Virtual PC 2007" available in 86Box so that's a bit similar to this.

EDIT2: OK some progress thanks to superfury. I think I understand the problem (and the reluctance to add this) a little better now.
There's the difference between virtual/idealized platform and a real (albeit emulated) one that causes problems with the Bochs version of SeaBIOS.
So, CD-ROM boot can be forced by editing rombios.c. If you want to see the various and amusing ways ISO booting can fail, this is the way to do it...
For example NetBSD here, (very) slowly boots up to a black screen, flickers a bit and then does a reset.

Attachments

Reply 1 of 9, by Jo22

User metadata
Rank l33t++
Rank
l33t++

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.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 2 of 9, by BitWrangler

User metadata
Rank l33t
Rank
l33t

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 🤣

2017: Basement full of ancient PC stuff, starting to go through it. 2021: Still starting, heh, many setbacks. So what's this BitWrangler guy's deal ??? >>> Taming the pile, specs to target?

Reply 3 of 9, by RichardG867

User metadata
Rank Newbie
Rank
Newbie

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).

Attachments

  • seabios.png
    Filename
    seabios.png
    File size
    15.98 KiB
    Views
    364 views
    File license
    Fair use/fair dealing exception
  • tianocore.png
    Filename
    tianocore.png
    File size
    48.78 KiB
    Views
    364 views
    File license
    Fair use/fair dealing exception

Reply 4 of 9, by mr.cat

User metadata
Rank Member
Rank
Member

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.

Reply 5 of 9, by doshea

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 6 of 9, by mr.cat

User metadata
Rank Member
Rank
Member
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.

Reply 7 of 9, by BitWrangler

User metadata
Rank l33t
Rank
l33t
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? 🤣

2017: Basement full of ancient PC stuff, starting to go through it. 2021: Still starting, heh, many setbacks. So what's this BitWrangler guy's deal ??? >>> Taming the pile, specs to target?

Reply 8 of 9, by retardware

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 9 of 9, by mr.cat

User metadata
Rank Member
Rank
Member
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 😁