clb wrote on 2023-07-28, 06:20:

Or does such a thing not exist, and those would then also have 55h AAh and then an immediate CBh - Return Far instruction in the code area (or how do Option ROMs finish executing?)

AFAIK that's the case. Data-only makes little sense, what would it be used for? There has to be some code that expects that data, and therefore:
1) the code is a part of that data, thus it's a code/mixed extension as usual
2) the code is in the BIOS ROM but then the BIOS needs to know where the data is, so the address will be static and it's no longer an optional ROM

You want to create a minimal wrapper for any ROM to tell the system that this memory area is taken, and how much of it. BTW a single RETF would work but possibly not with all BIOSes, the extension should return CF=0 to indicate successful init, and you can't be sure carry was zero'ed on entry. On one hand you don't care (if all the the ROM does is carry data) if the call was "successful" or not, on the other some BIOSes might be unhappy about CF=1 and retry or tell user to press a key - so the boot process might be interrupted somehow.

clb wrote on 2023-07-28, 06:20:

Are there Option ROMs that contain only data?...

Yes. But them aren't called "Option ROMs". Usually BIOS vendors call such option "ROM/Resource Holes". These days them are mostly used to store manufacturing and authentication data shouldn't be available to be modified by users but only very specific tools, like Windows SLP certificates/tatoos, Baseboard coprocessor unlocks, or OEM authenticode/keys/settings/serials to exit manufacturing mode (HP/Lenovo/Dell used this a lot, but them are these days being replaced by "EEPROM partitions").

When you make "ROM Holes" using the appropiate BIOS mod tools, these regions are recognized in the memory map as used, but "reserved". And your code which would use the data can query for such regions/addresses easily.

Taken literally, an Option ROM is indeed guaranteed to be executable and to follow that standard* (of course, like a "non-bootable" floppy disk which is also literally impossible on a fully IBM compatible PC, you could always make it return immediately);

* an ISA option ROM, that is - PCI/Express ones must also be associated with a VID/PID and, I think, are only loaded if the matching hardware is present

But it is perfectly valid to have ROM (generic/literal definition, including its backwards compatible rewritable successors) connected directly to the ISA bus and read it directly like the CPU/DMA does for RAM - indeed that's how IBM Basic is implemented 😀

The classic "consumer product" example would be https://www.youtube.com/watch?v=gKwmrvLedlk but it doesn't count, since apparently it uses I/O address space instead of doing the obvious "just an address decoder" approach described above!

Deunan wrote on 2023-07-28, 11:45:

AFAIK that's the case. Data-only makes little sense, what would it be used for? There has to be some code that expects that data

That is true. The way I thought that would work is that if e.g. a VGA adapter would first have its video BIOS in segment C000h, but then additionally decide to memory map for example an additional Font ROM at another segment. I understand some VGA adapters do that. The Font ROM would not need any executable code, since it would be the Video BIOS that would access it - so I was wondering if there might exist a data-only ROM identification, or if they are reusing the 55h AAh mechanism as well.

Or maybe an Option ROM might live as code only, and then some installable software would access it.

Based on the descriptions above, it does seem though that there will always exist the addresses 55h AAh to identify all ROMs, and all ROMs are executable. So there does not exist, say, a hypothetical header code 66h AAh or something like that which would identify a non-executable Data ROM (or any other header codes beside 55h AAh - that code is always hardcoded(?))

clb wrote on 2023-07-30, 13:40:

a hypothetical header code 66h AAh or something like that

Not that I know of. Every BIOS I've disassembled always looks for the 55 AA signature, then checks the size byte, then calculates the checksum - if everything is well, the code gets executed.

I've seen "split" VGA ROMs but I'm not sure why it's done. Both (it's usually 2) segments appear to have plenty of code in them. There also doesn't seem to be any significan functionality difference (say one part being init and fonts, other being int 10h code / VESA), it's usually mixed. It takes same amount of memory in the end, and the processing time during boot, no matter if it's one ROM segment declared or two. If anything the VGA ROMs I've seen had some dead or duplicated code between the segments so it appears less optimal than it could be.

Deunan wrote on 2023-07-30, 17:39:

I've seen "split" VGA ROMs but I'm not sure why it's done.

There EGA BIOS was just 16K in size, ranging from C000 to C3FF. There seems to be common pattern that VGA chips allow for a 2KB hole in their BIOS between C600 and C67F. (That is: 24KB VGA BIOS, 2KB hole and another 6KB VGA BIOS). There might be some odd 80s hardware that insists on using the C600:0-C600:7FF range for some reasong and doesn't have a changable base address. With EGA cards, this choice of base address was not a problem, but it will conflict with a 32KB VGA BIOS.

Deunan wrote on 2023-07-30, 17:39:

Not that I know of. Every BIOS I've disassembled always looks for the 55 AA signature, then checks the size byte, then calculates the checksum - if everything is well, the code gets executed.

That's basically all the BIOS has to do. The C000-EFFF space (later reduced to C000-DFFF with 128KB mainboard BIOSes) is not meant to only contain option ROMs. It may also contain shared memory buffers of network cards, memory-mapped I/O functionality (although that wouldn't make that much sense on a 8088 IBM PC, as IN/OUT is fast enough for control functionality), or even the EMS page frame. The 55 AA signature is meant to indicate that there actually is an option ROM at the address currently scanned by the BIOS, and that it needs execution during POST. If anything else is found (data ROM, floating bus at FF, random emory contents), that range is ignored. To reduce likelyhood of shared memory actually looking like a valid option ROM, there also is an 8-bit checksum over the whole ROM that needs to match. Furthermore, the choice of 55 AA validates (in 8-bit systems) that the data is not just a random result of a bus that is not driven at all, but that every single data line of that bus is actively toggling from 55 to AA when reading the second byte. This also validates that no data trace between the option ROM and the ISA bus is broken. Detecting (or dealing with) broken traces / loose pins in sockets was a design consideration of the POST processes in the 80s: For example. the IBM EGA card POST for example causes the card to output differntly colored test patterns for a short time and uses a read-back feature to poll the pixel data sent to the monitor to identify that the card is working as intended.

Actually, it might be quite interesting what happens if you put a valid option ROM image into an EMS page and then press Ctrl-Alt-Del to reboot. If you don't hit the reset button, the EMS hardware has no way of knowing that a reset has happened, and thus certainly can't unmap the page that contains the option ROM image from the page frame. So likely that "option ROM" gets executed from RAM. A well-designed EMS card will actually unmap all pages if it receives the RESETDRV signal on the ISA bus, so this issue can only arise on a warm start. Would be a nice way for a virus to persist across warm starts without obviously disturbing the reboot cycle. Some viruses (like Parity Boot) caught Ctrl-Alt-Del, and performed a "hot start" circumventing the complete BIOS POST procedure.