It's easier if your motherboard accepts an over sized ROM, like if your motherboard accepts a 27C512 chip, but only uses a 32KB of it. Not sure about the pci portion of things though.

Here are some threads that might help--
Adding XT-IDE option ROM to Asus P3B-F BIOS
IBM ROM Basic - option ROM for PC clones
CGA game on option ROM

Edit … Here is where someone put XTide on a pci capable bios
Re: FIC 486-VIP-IO try to patch BIOS 4.27

Have you thought about adding the .com files to autoexec.bat so they load before windows starts? Less painful than running them after windows starts, and injecting it into a BIOS.

Trick I used a couple times "back in the day" - I had some network cards which accepted a boot ROM .. put code there to autorun by bios.

Can't tell you much more... It has been years.

MikeSG wrote on 2025-12-27, 10:40:

Have you thought about adding the .com files to autoexec.bat so they load before windows starts? Less painful than running them after windows starts, and injecting it into a BIOS.

Yeah, but the point is to have it work on any OS (including Linux/BeOS/etc)

jheronimus wrote on 2025-12-27, 12:34:

MikeSG wrote on 2025-12-27, 10:40:

Have you thought about adding the .com files to autoexec.bat so they load before windows starts? Less painful than running them after windows starts, and injecting it into a BIOS.

Yeah, but the point is to have it work on any OS (including Linux/BeOS/etc)

Don’t bios routines get ignored once the operating system switches to protected mode? So even if you get the code loaded into a realmode upper memory block, it is going to be hard to use it in Win95, Linux, OS/2 etc. without forcing the cpu back into real mode first. Maybe it would be available to a virtual x86 session?

There are challenges with real mode operating systems too. The program that you load might have some trouble if it tries to use dos int 21h calls before DOS loads.

https://sites.google.com/site/pinczakko/advan … 4-51-pg-hacking

To the code to be executed as PCIrom, PСIR (dev and vendor ID) must be present in the header so that the BIOS can match the PСIrom module to the detected device.
As for ISA and other options, I don't know, I wasn't interested.
There are some source codes in the PLOP boot manager.
https://download.plop.at/files/bootmngr/plpbtrom-0.6.zip
https://www.plop.at/en/bootmanagers.html

jheronimus wrote on 2025-12-27, 12:34:

MikeSG wrote on 2025-12-27, 10:40:

Have you thought about adding the .com files to autoexec.bat so they load before windows starts? Less painful than running them after windows starts, and injecting it into a BIOS.

Yeah, but the point is to have it work on any OS (including Linux/BeOS/etc)

put the PCI register writes in the boot sector, they only take a couple bytes

Sebastian-vgns just posted this today, maybe it can help you out.
Script to insert option ROM (like XTIDE) into the BIOS ROM chip

Oh wow, guys, thanks fo the links, I'll give it all a look. This is my first time doing something like this, so it will take some time

douglar wrote on 2025-12-27, 14:00:

jheronimus wrote on 2025-12-27, 12:34:

MikeSG wrote on 2025-12-27, 10:40:

Have you thought about adding the .com files to autoexec.bat so they load before windows starts? Less painful than running them after windows starts, and injecting it into a BIOS.

Yeah, but the point is to have it work on any OS (including Linux/BeOS/etc)

Don’t bios routines get ignored once the operating system switches to protected mode? So even if you get the code loaded into a realmode upper memory block, it is going to be hard to use it in Win95, Linux, OS/2 etc. without forcing the cpu back into real mode first. Maybe it would be available to a virtual x86 session?

There are challenges with real mode operating systems too. The program that you load might have some trouble if it tries to use dos int 21h calls before DOS loads.

In Windows you can open a full screen DOS box to turn the system back into real mode. Once switched into protected mode again the settings stay. Can overclock the memory speed on VGA cards this way.

MikeSG wrote on 2025-12-31, 13:40:

In Windows you can open a full screen DOS box to turn the system back into real mode. Once switched into protected mode again the settings stay. Can overclock the memory speed on VGA cards this way.

Hmm. Not sure that's right.

My understanding is that in Win9x, "Restart into Dos mode" puts you into real mode (+ himem.sys which switches back and forth) but if you do a full screen DOS session while in Windows, you are actually in Vx86 mode where Windows makes a virtual address space that emulates real mode, but all of the int calls that normally go to the BIOS or DOS in real mode are intercepted by windows and handled by protected mode drivers. So it's not real mode, even though Win98 lets the DOS session act like real mode in it's own sandbox. Win98 you tinker with some things that newer operating systems would prohibit as unsafe, so you can still crash things if you know where to poke around.

Anyway, looking back on this thread, it should probably be my new year's resolution to read posts more carefully before replying. Looks like all the OP wants to do is set a couple PCI registers before any OS starts, and doesn't care if the rom is accessible after that, so my posts in this thread were tangential at best.

douglar wrote on 2025-12-31, 14:44:

Hmm. Not sure that's right. […]
Show full quote

MikeSG wrote on 2025-12-31, 13:40:

In Windows you can open a full screen DOS box to turn the system back into real mode. Once switched into protected mode again the settings stay. Can overclock the memory speed on VGA cards this way.

Hmm. Not sure that's right.

My understanding is that in Win9x, "Restart into Dos mode" puts you into real mode (+ himem.sys which switches back and forth) but if you do a full screen DOS session while in Windows, you are actually in Vx86 mode where Windows makes a virtual address space that emulates real mode, but all of the int calls that normally go to the BIOS or DOS in real mode are intercepted by windows and handled by protected mode drivers. So it's not real mode, even though Win98 lets the DOS session act like real mode in it's own sandbox. Win98 you tinker with some things that newer operating systems would prohibit as unsafe, so you can still crash things if you know where to poke around.

Anyway, looking back on this thread, it should probably be my new year's resolution to read posts more carefully before replying. Looks like all the OP wants to do is set a couple PCI registers before any OS starts, and doesn't care if the rom is accessible after that, so my posts in this thread were tangential at best.

The call to program hardware in plain C is "outp(address, value)". It's not a call as such, it's a direct base level instruction to a chip (VGA chip, chipset, etc). The only 'safety check' is the address space. It's blocked in win95 normal mode but in full screen DOS it's allowed and works. I don't think it's virtual, although I'm sure it is in later versions of windows.

MikeSG wrote on 2026-01-01, 12:18:

douglar wrote on 2025-12-31, 14:44:

Hmm. Not sure that's right. […]
Show full quote

MikeSG wrote on 2025-12-31, 13:40:

In Windows you can open a full screen DOS box to turn the system back into real mode. Once switched into protected mode again the settings stay. Can overclock the memory speed on VGA cards this way.

Hmm. Not sure that's right.

My understanding is that in Win9x, "Restart into Dos mode" puts you into real mode (+ himem.sys which switches back and forth) but if you do a full screen DOS session while in Windows, you are actually in Vx86 mode where Windows makes a virtual address space that emulates real mode, but all of the int calls that normally go to the BIOS or DOS in real mode are intercepted by windows and handled by protected mode drivers. So it's not real mode, even though Win98 lets the DOS session act like real mode in it's own sandbox. Win98 you tinker with some things that newer operating systems would prohibit as unsafe, so you can still crash things if you know where to poke around.

Anyway, looking back on this thread, it should probably be my new year's resolution to read posts more carefully before replying. Looks like all the OP wants to do is set a couple PCI registers before any OS starts, and doesn't care if the rom is accessible after that, so my posts in this thread were tangential at best.

The call to program hardware in plain C is "outp(address, value)". It's not a call as such, it's a direct base level instruction to a chip (VGA chip, chipset, etc). The only 'safety check' is the address space. It's blocked in win95 normal mode but in full screen DOS it's allowed and works. I don't think it's virtual, although I'm sure it is in later versions of windows.

It’s not true “real mode”, it’s “virtual 8086 mode” in a “virtual dos machine”, aka VDM. It acts like real mode, and has exclusive access to a lot of resources when in full screen, but if you run a dos program that tries to switch to protected mode in a full screen dos session , it will tell you that the system is already in protected mode. Protected mode dos stuff can still run if it follows DPMI, but windows is still in charge in the background and windows has control of “ring 0” and the cpu is definitely in protected mode, even if it emulates real mode for some processes. “VDM” has been around in windows since “Windows/386” came out in ‘87.

edit: thinking back farther to the 286 days, windows 3.x in standard mode and windows 2.x could only run one dos session at a time and they would drop back to real mode to do full screen DOS because those processors didn’t have a virtual 8086 mode. So if that’s what you were thinking of, then yes, those versions of windows would drop out to real mode to do a single full screen DOS window.

MikeSG wrote on 2026-01-01, 12:18:

The call to program hardware in plain C is "outp(address, value)". It's not a call as such, it's a direct base level instruction to a chip (VGA chip, chipset, etc). The only 'safety check' is the address space. It's blocked in win95 normal mode but in full screen DOS it's allowed and works. I don't think it's virtual, although I'm sure it is in later versions of windows.

There is an I/O permissions bitmap under protected/V86 mode which specifies whether I/O ports can be accessed normally or if the attempt will cause an exception. This is controlled by the OS and drivers. That's how a full screen DOS process can be allowed to fiddle with things that other user-mode Windows programs can't. When you run a DOS program under Windows, there are also cases where the port I/O is trapped but OS/driver code steps in to emulate the hardware functionality that the DOS is program is expecting.