mr.cat wrote on 2022-04-04, 16:17:OK here's how to make SeaBIOS to execute the VGA optrom, so that we actually get to see something on VGA.
I noticed that in the […]
Show full quote
OK here's how to make SeaBIOS to execute the VGA optrom, so that we actually get to see something on VGA.
I noticed that in the old SeaBIOS versions there's this switch called CONFIG_OPTIONROMS_DEPLOYED, that's needed to run optroms in old qemu versions (and Bochs).
The switch was removed in commit 9d691ace (2016-04-01), so for this test I used the last commit that still has it (8ef686f6).
There's a small adjustment needed for new compilers: stacks.c fails to compile with new gcc versions unless -fno-pie is added to COMMONCFLAGS (in Makefile).
Then launch "make menuconfig" and enable the config option mentioned above in the "BIOS interfaces" section (it's called "Option roms are already at 0xc0000-0xf0000" there).
It seems 256kB images don't work(?) so some stuff needs to be disabled to get the resulting rom image size down to 128kB.
When that's done, save and exit, and run make. If all goes well the romfile will then end up in out/bios.bin.
Note that any OPTROM*.BIN files in UniPCemu's ROM directory will all be run automatically (and will also show up in the boot menu).
This can be controlled via pci-optionrom-exec option (see docs/Runtime_config.md).
It might be best to rename or remove them while doing the testing.
EDIT: ...and here's a patch for SeaBIOS to undo commit 9d691ace. This is against the latest git.
OK.
Also, if you're deleting all ROMs for different architectures to remove their functionality, you can also specify a ROM with a size of 0 bytes (en empty file) to effectively remove them for the specified architecture only (when UniPCemu hits it in the priority chain of filenames, it will count the ROM as unexisting and not continue parse the chain). This is now mentioned in the manual. That's also the method I use with architectures past the Compaq Deskpro 386, to make the option ROMs for the Compaq disappear on newer models, if needed (depending on used ROMs for said architecture and it's chain used of course).
The current commits also support some new motherboards, namely i450gx, which is i450gx/i440fx>i430fx>PS2 etc. and 85C496/7 > PS2 etc.
Edit: Just changed it up a bit. Now i450gx/i440fx/i430fx/85C496/7 don't have each other as a priority anymore. Missing ROMs for those have been added. The i4x0 ROM has been added for i430fx/i440fx/i450gx instead of the old i430fx priority below it to provide generic ROM replacements for those BIOSes. 85C496 doesn't use such a generic ROM, as it's the only architecture of it's kind that's implemented.
Also, the current commits have a 85C496 northbridge only (without southbridge) on the Compaq/PS2 architectures now. This is mainly to support the PCI IRQ requirements on said architectures (a small hack to make improved PCI support). Stuff like the southbridge of the 85C496 (the 85C497) on those architectures aren't emulated (currently only the BIOS/option ROM PCI/ISA/RAM mapping, ESC chip and it's related architecture-specific components), because those are already implemented the Compaq way.
The 85C496/7 architecture is mostly implemented, except it's specific ESC functionality (of course including SMM) other than register storage (it's I/O ports are emulated though). PCI is now fully functional, like on the Compaq chipsets, as is the BIOS ROM support and required basic motherboard functionality (like CPU resets, PCIRST#, INIT support and extended memory DMA support).
One nice thing about PCI now being fully functional is that stuff like IRQs and memory(unused) are now fully mappable by the OS.
One thing to note is that the i450gx as i440fx setting doesn't affect the BIOS ROM loading. It just adds a i440fx compatibility layer to the i450gx chipset. It can use a i440fx ROM loaded as a i450gx ROM that way, while keeping the i450gx motherboard functionality active (allowing up to 8GB RAM and some of it's more advanced features to be used, using a translation layer between the two chipsets).