EduBat wrote on 2026-02-18, 19:52:

I looked around but could not find any practical way to get the BIOSes from my computers into files. The programs I found were e […]
Show full quote

I looked around but could not find any practical way to get the BIOSes from my computers into files.
The programs I found were either too complicated (flashrom) or simple (romdumpr.)
The problem with flashrom is that it needs to be aware of the chipset and tries to get that by querying the PCI bus. A 486 computer without PCI will not work.
On the other hand, romdumpr just gets whatever is on the F000:000 segment at the time it runs. This presumes that the BIOS at the top of the 4Gbyte address space has a mirror image at that segment, which is not always correct. Most BIOSes run from the top of the 4Gb address space and then dynamically decompress themselves to RAM memory at F000:0000. (aka shadow ROM.)

Frustrated with this I decided to write my own generic BIOS dumper and the results are attached.
It should work on any computer with at least a 386 processor.
The only limitation is that it does not auto detect the BIOS size, which needs to be provided.
(Testing / comments are welcome.)
It runs on DOS (any version above 3) but should also work in FreeDOS (not tested,) in which case it can be placed on a Rufus formatted bootable memory stick and ran from there.

Great little utility. Any chance there is an updated version with BIOS size detection?

zuldan wrote on 2026-04-25, 05:49:

EduBat wrote on 2026-02-18, 19:52:

I looked around but could not find any practical way to get the BIOSes from my computers into files. The programs I found were e […]
Show full quote

I looked around but could not find any practical way to get the BIOSes from my computers into files.
The programs I found were either too complicated (flashrom) or simple (romdumpr.)
The problem with flashrom is that it needs to be aware of the chipset and tries to get that by querying the PCI bus. A 486 computer without PCI will not work.
On the other hand, romdumpr just gets whatever is on the F000:000 segment at the time it runs. This presumes that the BIOS at the top of the 4Gbyte address space has a mirror image at that segment, which is not always correct. Most BIOSes run from the top of the 4Gb address space and then dynamically decompress themselves to RAM memory at F000:0000. (aka shadow ROM.)

Frustrated with this I decided to write my own generic BIOS dumper and the results are attached.
It should work on any computer with at least a 386 processor.
The only limitation is that it does not auto detect the BIOS size, which needs to be provided.
(Testing / comments are welcome.)
It runs on DOS (any version above 3) but should also work in FreeDOS (not tested,) in which case it can be placed on a Rufus formatted bootable memory stick and ran from there.

Great little utility. Any chance there is an updated version with BIOS size detection?

I tried, but I'm unable to come up with way to do it. When you try to read an area of the address space which has nothing assigned to it you get random data, which is indistinguishable from BIOS code, so I gave up for now.

EduBat wrote on 2026-04-26, 17:53:

I tried, but I'm unable to come up with way to do it. When you try to read an area of the address space which has nothing assigned to it you get random data, which is indistinguishable from BIOS code, so I gave up for now.

NSSI is able to do a BIOS dump without asking for the size. Not sure how it’s doing it.

https://www.navsoft.cz/products.htm

Maybe this will help

1#include <stdio.h>
2#include <dos.h>
3
4#define BIOS_SEGMENT 0xF000
5
6int main() {
7    unsigned char far *bios;
8    unsigned int size_blocks;
9    unsigned long size_bytes;
10
11    bios = (unsigned char far *)MK_FP(BIOS_SEGMENT, 0x0000);
12
13    /* Check signature */
14    if (bios[0] != 0x55 || bios[1] != 0xAA) {
15        printf("No valid BIOS signature found at F000:0000\n");
16        return 1;
17    }
18
19    size_blocks = bios[2];          // size in 512-byte units
20    size_bytes = (unsigned long)size_blocks * 512;
21
22    printf("Detected BIOS size: %lu bytes (%lu KB)\n",
23           size_bytes, size_bytes / 1024);
24
25    return 0;
26}

If you wanted to get more than just the motherboard BIOS

- Scan the upper memory area (0xC0000–0xF0000)
- Detect all option ROMs (video BIOS, network boot ROMs, etc.)
- Detect the system BIOS
- Validate each ROM via checksum
- Dump each ROM to its own file

1#include <stdio.h>
2#include <dos.h>
3
4#define START_SEG 0xC000
5#define END_SEG   0xF000
6#define STEP      0x80      /* 2 KB steps (0x80 paragraphs) */
7
8unsigned char far *make_ptr(unsigned int seg) {
9    return (unsigned char far *)MK_FP(seg, 0x0000);
10}
11
12int check_signature(unsigned char far *ptr) {
13    return (ptr[0] == 0x55 && ptr[1] == 0xAA);
14}
15
16int checksum_valid(unsigned char far *ptr, unsigned long size) {
17    unsigned long i;
18    unsigned char sum = 0;
19
20    for (i = 0; i < size; i++) {
21        sum += ptr[i];
22    }
23
24    return (sum == 0);
25}
26
27void dump_rom(unsigned char far *ptr, unsigned long size, int index) {
28    char filename[20];
29    FILE *fp;
30    unsigned long i;
31
32    sprintf(filename, "rom%d.bin", index);
33
34    fp = fopen(filename, "wb");
35    if (!fp) {
36        printf("Error creating %s\n", filename);
37        return;
38    }
39
40    for (i = 0; i < size; i++) {
41        fputc(ptr[i], fp);
42    }
43
44    fclose(fp);
45
46    printf("  Dumped to %s\n", filename);
47}
48
49int main() {
50    unsigned int seg;
51    int rom_index = 0;
52
53    printf("Scanning for ROMs...\n");
54
55    for (seg = START_SEG; seg <= END_SEG; seg += STEP) {
56        unsigned char far *ptr = make_ptr(seg);
57
58        if (check_signature(ptr)) {
59            unsigned int size_blocks = ptr[2];
60            unsigned long size = (unsigned long)size_blocks * 512;

61
62            printf("\nROM found at %04X:0000\n", seg);
63            printf("  Size: %lu bytes (%lu KB)\n", size, size / 1024);
64
65            if (checksum_valid(ptr, size)) {
66                printf("  Checksum: VALID\n");
67            } else {
68                printf("  Checksum: INVALID\n");
69            }
70
71            dump_rom(ptr, size, rom_index++);
72
73            /* Skip ahead to avoid re-detecting same ROM */
74            seg += (size / 16) - STEP;
75        }
76    }
77
78    printf("\nScan complete. %d ROM(s) found.\n", rom_index);
79    return 0;
80}

- Starts at 0xC0000 (where VGA BIOS usually lives)
- Moves in 2 KB increments (standard ROM alignment)
- Looks for the 0x55AA signature
- Reads the size byte
- Verifies checksum (sum of all bytes = 0)
- Dumps each ROM as:
rom0.bin
rom1.bin
etc.

All processors from the 386 and above start running code 16 bytes below the 4GBytes address so the chipsets need to map the EEPROM(s)/FLASH containing the BIOS to the space just below the 4Gbytes.
Some older chipsets also mirror the last 64Kbytes (or 128Kbytes) before the top of the 4Gbytes onto the last 64Kbytes (or 128Kbytes) of the first megabyte of address space.

What almost all BIOSes do is decompress code&data from the EEPROM/Flash to the RAM at the end of the first 1Megabyte. What we have here is already the result of this decompression stage. They can also decompress "option ROMs" onto the RAM at the space between C000:0000 and E000:0000 if needed.

Programs like romdumpr and NSSI only extract and save these 64Kbytes (or 128Kbytes) "System BIOSes" and "Option ROMS" onto files as we can see in the code you posted. The reason for this is that they are real mode programs running in pure DOS.

BIOSDUMP is a protected mode program running with the 32 bit DPMI DOS extender provided with DJGPP. It is able to see the whole 32bit address space and is able to get the BIOS at the top of the 4Gbytes and save it. It gets the code before any decompression takes place and is exactly what you would get if you took the chip out of the motherboard and read it on an hardware programmer.

Relatively modern BIOSes can be quite big. As examples my Gigabyte GA-7N400 Pro has a BIOS of 512Kbytes and my asus P5Q has a BIOS of 1Mbyte.
On the GA-7N400 Pro depending on whether you want to use the RAID controller or not or the SATA controller or not the BIOS will decompress the respective "option ROMs" to RAM or not.

BIOSDUMP can work on all computers that can run DOS, from a 386SX up to whatever modern computer that still has "legacy BIOS" support (a.k.a. CSM)
I have no way of knowing, a priori, if a computer has a 64K,....512K,.....1M,.....12M....etc BIOS and so far have not been able to find any way to guess it.

Example "modern" PC memory map:

This free book provides a lot more details:
https://github.com/pinczakko/BIOS-Disassembly … jutsu-Uncovered

Apparently the SMBIOS specification https://en.wikipedia.org/wiki/System_Management_BIOS defines a field in the BIOS structure that indicates the size of the BIOS itself. The main problem is that these specs only became a thing around 1999 or so. I'm not sure if there is interest in developing an automation that will only work on computers from this era onward or if it's ok to leave the program as is. Feedback and/or ideas are welcome.

Dumping the F0000...FFFFF range is fine for many 486 and older things but at some point during 486 era, the BIOSes started to decompress + shadow themselves and in the process what you read there will not match what is actually on the BIOS chip, and burning such an image on a BIOS chip will not work either. This is why FLASHROM and UNIFLASH are chipset aware, so that it can actually dump the actual chip rather than what is shadowed into memory.

Tiido wrote on 2026-08-03, 14:12:

Dumping the F0000...FFFFF range is fine for many 486 and older things but at some point during 486 era, the BIOSes started to decompress + shadow themselves and in the process what you read there will not match what is actually on the BIOS chip, and burning such an image on a BIOS chip will not work either. This is why FLASHROM and UNIFLASH are chipset aware, so that it can actually dump the actual chip rather than what is shadowed into memory.

Correct. That is why my program gets the top "n" Kbytes from the 32 bit address space. (Where "n" is the input parameter to the program.)
So, as an example, instead of dumping the 000F0000...000FFFFF range, it gets the FFFF0000...FFFFFFFF range. (For a 64Kbyte chip.)
I understand my program may not work all the time, particularly on more modern computers with partitioned flash chips which need a program like FLASHROM or UNIFLASH, but it's a reasonable compromise.

Try scanning down from the top of memory until you get all 0's or 255's. That should be the beginning of the ROM.

Hi, some BIOSes use/support Cloaking technology.
https://en.wikipedia.org/wiki/DOS_Protected_M … rvices#CLOAKING

Hi all,

I went ahead and created a version where I find the size of the BIOS from the SMBIOS/DMIBIOS tables in the BIOS itself.
That functionality should work fine for computers from around 1999 and above.
For all the older ones it will also work but you need to pass the size of the BIOS as an argument to the program.

The zip includes source code, in case anyone is interested to see how it was done.

I would really appreciate any feedback, particularly regarding any failures, so that I can investigate the issues and fix them.

Thanks!

After a lot more testing I have now fixed a few bugs that prevented the program from working properly on newer computers and am therefore releasing a new version.

1BIOSDUMP.EXE is a program that allows you to extract the BIOS of your
2x86 PC compatible computer to a file.
3
4Writen by Eduardo Batalha on 8-Aug-2026.
5Distributed under the WTFPL license.
6Feel free to do whatever you want with this code as long as you do
7not misrepresent me.
8
9This is the third version with a reasonably amount of testing.
10It was compiled with DJGPP, it is a protected mode program that
11uses the DPMI facilites provided by the CWSDPMI.EXE server
12and needs at least a 386 machine.
13This version adds auto detection of the EEPROM size by using the
14SMBIOS/DMIBIOS tables from the BIOS itself.
15It is not a UEFI program, it runs from DOS. The best way to test it
16on newer computers is to use a Freedos formatted USB memory stick and
17boot the computer from it, then run BIOSDUMP from it. Rufus is a
18utility that can create such a USB drive.
19The program creates a file called BIOS.BIN in the same folder where
20it lives. After running the program just rename this file to whatever
21you want.
22
23Tested on:
24- Unicorn ENDAT-486AL - Working, the user needs to input BIOS size
25- Gigabyte GA-7N400 Pro - Working, ROM size found by DMI
26- Compaq N610c - Working, ROM size found by DMI
27- Asus P5Q - Working, ROM size found by DMI
28- Lenovo T430s - Working, ROM size found by DMI. If you use Freedos to test
29     do not load himemx to prevent the program from crashing
30- Lenovo T450s - Working, ROM size found by DMI
31
32Still to be tested are 386 computers and computers with SMBIOS/DMIBIOS
33version equal to or higher than 3.1.
34
35It works by extracting the values present at the top of the 32bits memory
36space, where firmware needs to exist in order for any x86 processor to
37start. The program should run well on any computer with a 386 processor
38or above up to systems where the chipset partitions the BIOS chip, the
39so called "Descriptor mode" in intel documentation. On these later systems,
40the data in the EEPROM chips is divided into blocks, each dedicated to its
41own controller. Besides the block for the main processor, you will have
42another for the ME controller, another for the Ethernet controller, etc.
43The chipset may hide the data for these other controllers from being
44accessed by the main processor without prior chipset programming.
45BIOSDUMP is not chipset aware and will make no attempt to unlock access to
46these blocks.
47
48The program was compiled with:
49gcc -g -o dumper.o dumper.c
50gcc -o dumper.exe dumper.o
51strip dumper.exe
52exe2coff dumper.exe
53copy /b cwsdstub.exe+dumper biosdump.exe
54

I have also now tested it on an HP Elitebook 850G5, which uses DMI version 3.1. It worked fine (slowly, since it's a 32Mbyte BIOS) but I had to disable HimemX in Freedos.
The only thing pending now is a test on a 386 class machine.

Seems like the autodection is a bit wonky. On my Dell i5 Inspiron laptop with an InsydeH2O BIOS and i5-8250u CPU, the program writes a 16384kb file (executed in baremetal DOS on MS-DOS 7.1). Over 50% of this is 0xFF bytes (the initial 8 mb or so). Is it possible to have a 16MB BIOS and half of it would be "empty"?

I believe that searching the top of RAM for all 255's is a pretty reliable method to determine where the actual ROM begins. Try it.