IBM published the full source code for the BIOS of all of their early PCs. The code is quite easy to find online from various sites today; both in PDF copies of the early Technical Reference manuals (e.g., here's a copy of the IBM 5150 Technical Reference manual; PDF pages "193/393" and following contain the BIOS ROM code listing) and as files containing the actual binary bits extracted directly from the old BIOS chips. In fact, some emulators, such as PCE, actually make use of the original BIOS and ROM BASIC code which is why we can reproduce this error in the first ROM BASIC version. It must be noted that there were at least three "personal computers" available to the public prior to the IBM PC: The Apple II and the Commodore PET (April, 1977, both 6502 CPU based); which actually made use of the term personal computer, and then the TRS-80 (August, 1977, using a Zilog Z80 CPU). Of the three, only Apple published its BIOS code; though later on books by independent authors on the ROM BASIC code of the TRS-80 became available.^[8]

In less than a year after release of the IBM PC in 1981, both Eagle Computer and Corona Data Systems created IBM PC Clones which eventually led to them being sued by IBM early in 1984. Eagle was forced to stop production until eventually rewriting their BIOS. But in the meantime, PC Compatibles such as COMPAQ (using legally designed compatible BIOS code) had far outpaced them. Unable to regain enough sales, Eagle went out of business in 1986. Corona met a different fate: Its founder, Robert Harp, resigned in 1987, after the Daewoo Group acquired 70% of Corona, and by 1993 it was completely phased out. However, in June 1982, Columbia Data Products created the first legally PC compatible BIOS^[9] for their MPC 1600, and in November 1982, came the announcement of Compaq's legally engineered BIOS,^[10] which cost them a Million Dollars! Then in May, 1984, Phoenix Technologies became the first company to announce that they had created a PC compatible BIOS for sale to any PC / motherboard manufacurer. I recommend reading all of this article by the one who wrote that BIOS code and then his How the First BIOS Code was Written article which delves more into the details of BIOS code writing. In 1985, yet another company, DTK Computer, decided to develop its own clean-room PC BIOS.

Following the creation of the Phoenix BIOS, Award Software slowly became a noticeable competitor in the BIOS code market. But, in 1998, it was merged into Phoenix Technologies. The only other major BIOS company, AMI (American Megatrends, Inc.), began producing BIOS software in 1986, among its other products; including motherboards, helping to keep them solvent to this day. They did have some "technical problems" over the decades, such as the "Happy Birthday Trojan" (though that term may not be quite accurate), which on November 13, 1993, caused many PCs with a particular BIOS chip to halt at boot-up and repeatedly play the happy birthday tune through the PC's speaker. However, they are still producing and selling BIOS code with competitive features: Some fairly recent products from Gigabyte Technology (which used Award BIOS in the past) now have UEFI code by AMI in them (e.g., in a 256 Mbit GigaDevice 25Q Series flash chip on their B460M DS3H motherboard).

Programs had Easy Access to BIOS code in the Past

First, some necessary background: For many years after the first IBM PC was shipped, a number of routines in the PC's BIOS code were absolutely critical for every single application or utility program that ever ran under IBM PC DOS or MS-DOS. Assembly code for all such early x86 programs contain what are still called Interrupts for accessing keyboards, Memory, Video routines for the display, floppy drives, speakers and other peripherals. From the beginning, DOS had its own Interrupt calls as well, but as operating systems grew, their developers created more code that ran in between applications and the BIOS code. Eventually, modern OS code, replaced most BIOS Interrupts through the use of what came to be known as drivers, allowing them access to the hardware apart from any BIOS code; increasing the layers between application code and the hardware. However, until that occurred, there were dedicated Memory bus locations that any program could use to by-pass an OS and hand control over to BIOS Interrupt code; for example, to get input from the keyboard or write directly to Memory locations used by a monitor for what was displayed on its screen (or any other hardware that had specific bus output PORTs on the system)!

In the beginning, these Memory (or bus PORT) locations were hardwired to the BIOS chips (via physical Memory address lines in the PC) and were directly accessed by using specific CPU commands. Of the maximum of 1 Megabyte of memory which the first PC's CPU (an Intel 8088) could possibly access, the highest "Memory Address" lines (0xF6000 through 0xFFFFF; exactly 40 KiB;) were connected directly to the BIOS and ROM BASIC chips (the BIOS using only the highest 8 KiB). Thus, for many early versions of DOS, one could quite easily make a binary copy of the whole BIOS using the DEBUG utility to save it to a file! As an example, if you boot an IBM PC (or a true IBM PC emulator) with a 5150 BIOS chip, and have at least 8 KiB of space on a diskette (we'll use the B: drive here for that), you can copy that PC's BIOS contents to the file DUMPBIOS.BIN by executing the following:

Enter today's date (m-d-y): 04-08-2023

The IBM Personal Computer DOS
Version 1.00 (C)Copyright IBM Corp 1981

A>B:
B>A:debug
-N dumpbios.bin       [Name of new file.]
-M F000:E000 L 2000 100
-rcx    [Change value of CX register.]
CX 0000
:2000   [How many bytes in hexadecimal.]
-w      [Write bytes to new file name.]
-q      [Exit DEBUG; Q for 'Quit'.]
B>dir
DUMPBIOS  BIN       8192  04-08-23

The contents of the DUMPBIOS.BIN file will be identical to the bytes copied by some other means directly from the BIOS chip. DEBUG could also be used to copy the IBM BASIC code from its ROM chips: For the BASIC ROM chips in a 5150 PC, you could name the output file "DUMPBAS.BIN" and in the M command, simply substitute "M F000:6000 L 8000 100" for what you see above. You would also need to use a size of 8000 in the rcx command. That will copy all 32 KiB (0x8000) from Memory locations F000:6000 (or 0xF6000) through F000:DFFF (or 0xFDFFF); a length of 0xE000 - 0x6000 = 0x8000 bytes. After comparing DUMPBAS.BIN to a known good and verified ROM file, they were identical. It's a known fact, that for all early IBM PCs and compatibles; though one must be aware of the size and layout of the BIOS code, that identical copies of the ROM chips can be created using DEBUG (or a similar utility) without having to disassemble a PC, remove the chips and read their contents using some electronic device. Although most IBM XT computers have two 32 KiB BIOS chips inside them, only the highest 8 KiB of U19 comprise the BIOS code, so the same steps above could be used to copy its BIOS code (see here for pictures and a list of all the different IBM XT BIOS revisions).

  In order to compare the contents of the two BIOS chips from an IBM PC/AT (5170) (80286 CPU) to a file created by DEBUG, one must first combine the "even" bytes of its U27 chip with the "odd" bytes of its U47 chip;^[11] well, unless you already have access to such a file. Then, in DEBUG; most likely under IBM PC DOS 3.30, since these chips total a length of 64 KiB and DEBUG can only work with files up to 64 KiB minus 256 (0x100), the copy process must be broken into two parts: At the DEBUG prompt, after entering the first filename (which we'll name BIOSDMP1.BIN with the N command), enter: M F000:0,FEFF 100, then set the size to FF00 using the rcx command, followed by w to write 65,280 bytes to that file. Next, write the remaining 256 bytes to BIOSDMP2.BIN (which can be done in the same DEBUG session after using another N command for the new file) then entering: M F000:FF00,FFFF 100 with an RCX of only 100 followed by the w and q commands. Lastly, combine the two files using the COPY command like this: COPY /B BIOSDMP1.BIN+BIOSDMP2.BIN DUMPBIOS.ROM. Upon comparing DUMPBIOS.ROM with the bytes taken directly from the two BIOS chips, they are found to be identical.

However, for many decades now, there has generally been no way for an operating system or its applications, to directly access a BIOS chip's contents. Some motherboard manufacturers have provided customers with specialized utility programs to make backup copies of the BIOS code, but this is nothing like being able to divert full control of a PC to the BIOS code from inside an application as one could do in the early days of DOS (for example, it was possible to enter a single command in DEBUG which would reboot the PC in much the same way as pressing the CTRL + ALT + DEL keys did back then! At a DEBUG prompt, that command is: "g = f000:fff0", or: "g = ffff:0"). This should work under any DOS emulation or virtual machine. But attempting to do so under any Windows NT or XP OS will simply stop the DEBUG program.

  Note: It must be pointed out that the simplest features computer users take for granted today, such as a Real-Time Clock (or RTC), did not exist in the first IBM PC. Thus the reason IBM PC DOS 1.00 and 1.10 required users to enter the date and time! Nor did the BIOS automatically configure such things as the amount of Memory in a PC; which required settings to be made using physical switches inside the chassis. Even the IBM PC/AT with an 80286 CPU and an RTC needed to use a Diagnostics floppy diskette to set up the PC; easy to access BIOS Setup screens did not exist until after some PC Compatible BIOS manufacturers included them. (Some firmware emulators, such as PCem / 86Box, can actually make use of the original IBM or other Diagnostics diskettes in order to set up the time/date and various hardware features in an IBM PC/AT virtual instance.)

The 80286-based IBM PC/AT required users to run a SETUP diskette the first time the PC was powered-on in order to store the time & date and hardware configurations; such as the number of disk drives on the system. Changing hardware, such as a disk drive, or having the CMOS battery die, also required running SETUP again.

BIOS Shadowing and Relocation

What is BIOS shadowing? A simple definition from Phoenix Technologies:

"Shadowing / A technique for improving the speed of ROM-based code. The code is copied from ROM to high-speed RAM at the same address, the ROM is disabled, and the RAM is then write-protected."^[12]

However, making a useful copy of a PC's BIOS from ROM into RAM required more than just a new routine in the code! Note carefully those words above about disabling the ROM and then write-protecting some of the RAM. That couldn't be done until new hardware chips had been designed to carry out those functions, and Chips and Tecnologies (in 1987) was the first company to create a chipset which allowed BIOS code to implement shadowing. That chipset was trademarked as NEAT ("New Enhanced AT").

Here's a definition for a related topic which also required changes in the chipsets:

"Memory Relocation / A technique for redefining redundant RAM memory as extended memory. Some systems contain both ROM and RAM at the same addresses in the range A0000h - FFFFFh, with one or the other disabled. If this address range is not used for EMS or shadowing, the RAM's upper address bits can be set to effectively relocate it to the top of the system's address space."^[13]

Note: There is much more I need to add with references concerning both of these topics. I will also be adding another page of instructions on installing and using the emulator 86Box (based upon PCem). If you need to know more about these topics now, you can email me here.

Some Virtual Machine Labwork:

  Install either VMware Player (see item # 1 under Replacing the VMware BIOS below) or Oracle VM VirtualBox or both. If you do decide to install both, I highly recommend using VMware Player as your primary virtual machine, and do not install any networking for VirtualBox. You may also have some conflicts with USB adapters, etc. when running both a VMware VM and VirtualBox at the same time. Some important quick help: Once you click your mouse cursor inside any VMware virtual machine window, to get it back again for use with your Host OS, you must press both the CTRL and ALT keys at the same time! Under VirtualBox, you must press only the CTRL key on the right side of the keyboard.

The first VM I'd recommend creating would be MS-DOS 6.22; if you don't have your own disk images, you can download them inside a .7z file from here; with SHA1 hashes to check each diskette image file! (Download free 7-Zip program from here.) For whichever VM you're running, execute the DEBUG command I wrote about above. After that, enter  msd  at the DOS prompt and under the "Utilities" menu, choose "Memory Browser ..." and select each of the choices ("ROM BIOS", "Option ROM" and "Video ROM BIOS") to reveal some of the strings you'll find inside that VM's DOS compatible BIOS code. Here is an example from each VM:

  And for those addicted to using a mouse cursor, I've created a diskette image file with a mouse.com mouse driver you can run under DOS; along with some other useful utilities, so download tsrutils.zip now, connect the floppy image under your DOS VMs, copy  mouse.com  and  mouse.ini  to your C:\ drive (or C:\DOS directory); and perhaps add it to the AUTOEXEC.BAT file so it will be installed at boot-up. The image file also includes my BIOSDUMP files (in their own directory) to capture the DOS compatible BIOS code in use by whatever virtual machine program you're using. [Note: Each BIOSDUMP capture will create a .BIN file of 64 KiB (65,536 bytes), so be sure you have enough space on a floppy disk or image file if you run them from there!] However, there's plenty of space (over 1 Megabyte free) on the tsrutils.img  file provided here for the both BIOSDUMP.BIN and VIDEODMP.BIN. Run both Batch programs from the floppy image; use the commands: "a:", "cd biosdump" (where they're located) and then "biosdump" and "videodmp".

  Next, in order to use any Windows tools to examine those files, you need to extract them from the floppy image. The only totally free solution we know of at this time is to install the ImDisk Virtual Disk Driver using the latest download. See our page on Installing and Using ImDisk to complete your lab work.

Where is a PC's BIOS code stored? Various types of BIOS chips.

Over the course of the PC's history, BIOS code has been stored in many different types of non-volatile memory, the first of which was truly Read Only Memory ( ROM), because its programming had to be encoded in the chip at the time it was fabricated. Thus, BIOS chips on early IBM Personal Computers often had lines printed on them which not only indicated the manufacturer's IC type, but also an IBM part number for the code it contained.

In the photo below, the logo for AMD™ (Advanced Micro Devices, Inc.) probably caught your attention first, being on four of the five ICs, but you'll also find the Motorola™ batwing logo (an 'M' inside a small circle) on U30. The first chip on the left (U33), with the lines "1501476 / AM9264DPC / 34146 / 8407VPM," contains the BIOS code for an IBM Model 5150, and its part number (1501476) identifies it as the 3rd version (October 27, 1982) of the code. These are all 24-pin, 8K-word x 8-bit ROMs, the BIOS/POST code being only 8 KiB long. U29 (5000019), U30 (5000021), U31 (5000022) and U32 (5000023) together comprise the 32 KiB ROM BASIC code.

From a 2008 photo, courtesy of Rune Tapper, pc-museum.com. (This particular IBM 5150 had been "Made in Greenock, Scotland,"
some time after week 8 of 1984, since a number of chips soldered to the board had that date code; note the '8408' on U30 and U32.)

As noted above, the ROM chip U33 (IBM # 1501476) contains the 3rd version of the 5150 BIOS code. Take this link for photos and details of some ROM chips for all three BIOS versions used in various IBM 5150 models. Take this link for photos of both ROM and EPROM chips in various IBM 5160 machines, and for photos and part numbers of the BIOS chips used in the IBM PC/AT (5170) machines, take this link.

For testing or even small production runs, PROMs (one time only, Programmable ROM) or EPROMs (Erasable Programmable ROM) may have been used on some early PC Compatibles, since the manufacturer could then test and use revised code and not be left with any ROMs in their stock having either erroneous or obsolete data. Both PROMs and EPROMs usually have part numbers beginning with 27, but an EPROM has a small quartz window on top (often covered by a label), so its memory can be erased with a specific high intensity beam of ultra-violet light; allowing it to be reused.

Here's a 32-pin DIP BIOS chip from "Award Software, Inc. © 1995" (on a Soltek SL-52B2 motherboard), with "PCI/PNP 586" and "S/N:034147973" on its label:

Much later, motherboard manufacturers designed circuitry and utility programs for various types of EEPROMs (Electrically Erasable Programmable ROM; part numbers usually begin with a 28 or 29) that allowed users to reprogram their own PC's BIOS. [This also meant the code could be corrupted if a power-loss occurred during the upgrade process! Of course, having a known-good battery-backup power supply could prevent that.]

If the BIOS chip became corrupted, it required purchasing a pre-programmed replacement chip; unless a user was so unlucky as to find the PC manufacturer had soldered the BIOS chip to the board! Even then, the BIOS chip generally still had 24 rather large pins, and an electronics hobbyist could disable (or cut away) the old chip and solder the new one to the existing legs (pins) without having to unsolder the old chip. Of course, if the cost of a programmed chip was too high, then a better board with more features would win out. The worst class of motherboards in relation to BIOS chips were those that stored the code in a chip soldered onto the board and also required the user to run an upgrade under Windows, without anything else running! So, forgetting to disconnect the Network cable or to use TASK MANAGER to kill all but the essential processes, meant you could easily turn such a motherboard into a useless piece of junk!

PCs with a better design philosophy, had a built-in bootstrap routine that would remain unaltered, thus allowing users to recover from failed BIOS upgrades. And more recent motherboards, may have a Dual BIOS system^[14], so users can re-boot from a secondary BIOS chip that was not in the process of being changed if a power-loss or some other event occurs. When the PC boots-up again, it will use the secondary BIOS and the user can go back to reprogramming the primary BIOS chip. Depending upon how the board manufacturer decided to implement their dual BIOS design, the second chip may be a safety chip that is 'read only' and can never be changed (GIGABYTE's design); which has the solid advantage of having some BIOS code that could always be relied upon, unless it had a hardware failure too. Or, a routine may exist to copy the successfully upgraded chip's contents to the other BIOS chip, after determining there is no problem with the updated code. The BIOS could then check that the copied code matches that of the upgraded chip, before allowing another upgrade (decidedly more difficult to program and might allow a hacker's code to be your new 'backup code').

The photos below show a 2 Megabit (or 256 KiB of 8-bit bytes) Flash Memory BIOS chip in a 32-pin PLCC package made by Eon (Eon Silicon Solution, Inc.; part number "EN29F002NT-70J" with an additional line: "0034G - B6M17") on a "Micro-Star" International (MSI) model "MS-6330" "K7T" "Turbo Ver. 3" motherboard:

The Dell E521 PC also used a 32-pin PLCC chip (SST 49LF040B 33-4C-NHE; a 4 Megabit chip to store up to 512 KiB of BIOS code). Pictured here is an early Gigabyte DualBIOS™ board using two PLCC chips.

But eventually, motherboards were designed to use small 8-pin, Serial Flash BIOS chips (such as the Macronix™ MX25L8005; an 8 Mbit or 1024 KiB chip, with Boot Lock protection), its code being accessed by the board's South Bridge (such as Intel's ICH9; I/O Controller Hub 9) using an SPI bus.

How to Identify your PC's Chipset

The best source of information, if it's available, would be from the engineers who designed your PC's motherboard. ASUS™ and GIGABYTE™ both provide manuals online for most of their products; other motherboard companies may as well. A number of chips on our GIGABYTE boards were listed in these manuals. However, most likely due to the cost of support, most PC manufacturers do not supply you with such details.

But utility programs also exist which will search PC buses for ID bytes that reveal the identity of a number of its ICs. One which we've used for years is called CPU-Z; available in both 32- and 64-bit OS versions; both installable and portable downloads:

CPU-Z (the last version was 2.05. The program's Mainboard TAB window displays whatever it knows about a PC's chipset and BIOS. Below you'll see examples for both a Gigabyte Motherboard and a Dell PC. On the left, most of the data is the same as we found in the manual. However, the data displayed here for the Dell PC (and other name-brand computers) is generally unavailable. Now we at least know it's using a chipset from NVIDIA, and some kind of Super I/O chip from SMSC ("Standard Microsystems Corporation") for its LPC ( Low Pin Count) I/O bus. We had to examine the board to find it was an SCH55140-NS chip; whereas the Gigabyte board's LPC I/O chip from ITE shows it was an IT8718. But neither board's actual BIOS chip is listed here. To see more detailed information about your PC, you could also download PC-Wizard (from the same web site). The Hardware section provides information about the Mainboard, BIOS and Chipset; among many other items. And the data provided by its remaining sections is so detailed, it may overload your brain.

Once you have the Chipset data, you can search a chip manufacturer's site for details on how data in the chip might be accessed; that data can be used by independent utility programmers to show the actual contents of a BIOS chip, as well as by motherboard manufacturers for use in their own BIOS upgrade programs. Some Board manufacturers may even provide a Windows-based utility to make a copy of your BIOS code! [Note: We do not recommend performing a BIOS upgrade, unless you have been assured it will allow your PC to function in some new way you require it to; such as recognizing a larger disk drive, or fixing a problem. We are only pointing out it may be easy to copy the code from your PC's BIOS chip using a software tool; not to use such tools for overwriting BIOS code, without considering the possibility it may become corrupted.] The following shows one such utility running on a PC (we used the PrintScreen key to capture its image; NEVER do this when upgrading!) and added the yellow rectangle and caption:

A screen capture of GIGABYTE's @BIOS™ utility running under Microsoft Windows™ XP.

This utility even shows the type of memory chip being used to store the BIOS code: "MX(IC)25L8005"; as well as its 8 Mbits capacity. Unfortunately, some recent GIGABYTE boards reveal less about the hardware and may not even be able to backup the BIOS to a file!

Note: For anyone wishing to access the BIOS code on a modern PC - without such a utility, you would first need to know how to use Intel's Low Pin Count Specification and any possible variations in the LPC I/O Interface of the different Super I/O chip manufacturers, and then figure out how to communicate with the actual BIOS chip itself; which could be an 8-pin or 32-pin flash chip of a different manufacturer as well.

The Memory Location of a PC's First Instruction

Virtually every PC, since the very first IBM® Personal Computer produced in 1981, to the latest Intel® or AMD® based PC, has had exactly the same Memory address hard-wired into its CPU as a reference for its first instruction!^[15] This means every x86 PC's CPU always begins executing machine code instructions from essentially the same location inside its BIOS chip. That address is:

F000:FFF0 (in Segment:Offset notation)  or: FFFF0h (in Linear notation). You may also find it represented by FFFF:0000 [See Figure 1 below; as listed in IBM's original Technical Reference manual; P/N 6025008], or as just FFFF:0 (in Normalized Segment:Offset notation). [Read Section 3 of our page on Segment:Offset Addressing to understand why FFFF:0 is equivalent to the Segment:Offset pair F000:FFF0.]

IBM® named this address the "Power On Reset Vector " and it always contains a far jump instruction to the beginning of the BIOS chip's Power-on RESET code. Here's a display of what you'd find in that location and the next 11 bytes of an original IBM® PC's BIOS chip:

Offset: 0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F    ASCII chars. 
------ -----------------------------------------------  ---------------- 
0FFFF0 EA 5B E0 00 F0 30 34 2F 32 34 2F 38 31 FF FF EB  .[...04/24/81... 

The first five bytes (shown in green ) comprise the Power-On Reset Far Jump. These 5 bytes disassemble to:

JMP   F000:E05B

As you can see, Segment F000: is embedded inside this instruction, thus the reason its location is often referenced as F000:FFF0. Although the location of this far jump instruction was essentially 'set in stone' for all early PC BIOS, it's not a requirement that where it jumps to next always be the same; yet every IBM PC BIOS or Clone that we've examined for at least a decade after the IBM 5150 always jumped to "F000:E05B". Exceptions increased as time passed, since any other address could actually be used. For example, in an AMI BIOS we found on an ASRock PC dated "06/15/12" (so 2012), its first instruction is: JMP F000:FFAA which also contained a jump there, and the next instruction was yet another jump!

Of the twelve IBM engineers assigned to create the IBM Personal Computer (model 5150), David J. Bradley^[16] developed the code for its BIOS. So he's the one who, among all its other details, decided where in Memory the BIOS would place and execute the code from the first sector of the IBM PC's first floppy diskette's Boot Record. The location he chose was 0x7C00 (or 0000:7C00 in Segment:Offset notation). Unlike the first 'jump address' mentioned above (to F000:E05B), later BIOS authors could not have chosen a different location in Memory for loading the initial bootstrap routines without having their code become incompatible with existing boot diskettes! So IBM (and all the PC-clone companies which followed) continued to use that same location in Memory for their hard disk drive's Master Boot Records (MBRs).

Release Date

The next eight bytes (shown in yellow ) were originally called the "RELEASE MARKER" by IBM; they always contained the release date of the BIOS code (which was 04/24/81 for those first PCs).

Portion of page A-80, Appendix A, "ROM BIOS Listing," in the Technical Reference manual (IBM Part Number, 6025008), First Edition (August, 1981), of the IBM Personal Computer Hardware Reference Library.     (Click on figure above for larger size.)     Figure 1

[ In Figure 1, there's an error in the machine code listing for the location of the Power On RESET code in the "JMP RESET" instruction. This is exactly how the original "IBM Personal Computer Technical Reference Manual," was printed. This should have been listed as: EA5BE000F0 rather than "EA5B0000F0"; if you check the address shown on page A-5, it's obvious "RESET" begins at the address we've specified.]

The practice of including "release dates" at this location in BIOS code was continued for every PC Clone BIOS we've examined, and even for many decades to follow inside the DOS compatible modules of later BIOS code. If you install some version of DOS under VMware Player 17 and run the Dump DEBUG command show below, it will show a release date of "11/12/20".

Anyone running a Microsoft/IBM OS from DOS through Windows™ 7 (32-bit), should be able to enter the following DEBUG commands (Windows users must first click on start —> Programs —> Accessories —> Command prompt to open a 'Command Prompt' window. Windows 7 users may be required to select 'Run As Administrator' next to the Command Prompt icon in order to access DEBUG), and obtain results similar to the following (DEBUG.EXE should already be in your path):

C:\>debug
-d f000:fff0 [To 'dump' the last 16 bytes of memory Segment.]
F000:FFF0  EA 5B E0 00 F0 30 34 2F-31 34 2F 30 33 00 FC 48   .[...04/14/03..H 
-
-u f000:fff0 l5 [The "l5" stands for 'length of 5 bytes.]
F000:FFF0 EA5BE000F0    JMP     F000:E05B
-
-q [To exit DEBUG. This is a Q for 'Quit'.]

ENTER the commands shown in green at the DEBUG prompt ("-"). You can see we have the same Jump instruction as the original Personal Computer on this one, but this BIOS code was released on April 14, 2003 ("04/14/03"). (For more on the use of DEBUG, see our Guide to MS-DEBUG).

Here's a Windows™ 7 (32-bit) Command Prompt using DEBUG to show its PC's BIOS release date of "06/18/09":

On early PCs, RAM was an expensive and limited resource that was used as wisely as possible for the the execution of user's programs. Since the original PC could be purchased with only 16 KiB (16 x 1024 bytes = 16,384 bytes) of memory, we know for a fact it would have been impossible to fit the 32 KiB of ROM BASIC code into memory. But using half the available memory for even the 8 KiB of initial bootstrap code made no sense, since it could be accessed from its own ROM chip just as fast as any code in the dynamic RAM chips; both having a 250 nano second access time^[17]. Once RAM became much faster than ROM or EEPROM ICs and PCs commonly had many megabytes of memory, system engineers had motive enough to first copy bootstrap routines from the BIOS code into memory, then execute it there. This made it possible for BIOS programmers to explore a number of other advantages to having their code shadowed in RAM; which we'll point out in our next section. But first, we need to mention some methods for making copies of whatever BIOS code still remains in memory after a PC boots up:

How to Save BIOS code from the First 1 MiB of a PC

As we mentioned above, for first generation PCs, BIOS code always had to be read directly from its chip(s). Not only when the PC was booting-up, but every time a program used a system Interrupt or needed to access any other BIOS code stored in its ROM (Read Only Memory) chip(s). In those days, the address lines corresponding to the last segment of memory were hard-wired only to locations within the BIOS chip(s). Later on, PCs were made in which the BIOS code was first copied into RAM and then used from there instead of directly from the BIOS chip(s).

Motherboard and BIOS chip designs are now much more advanced and vastly different in how they function before even starting the POST than those early PCs, but it's still possible to examine some of the BIOS code that's copied to the last 64 KiB and other Segments of a computer's first Binary Megabyte of Memory. Although early PCs often revealed an exact duplicate of the code from their BIOS chip(s), what you'll find today, for example, on a PC running Windows XP, will only be a small portion of the full BIOS code that has been copied yet again into a Virtual Memory address space used by the NTVDM program to simulate the first Megabyte and beyond of a computer's physical memory. Nevertheless, these bytes are similar to (possibly even the same as) a small section of all the bytes archived in whatever hardware is actually used to store the PC's BIOS code.

NOTE: The BIOSDUMP program below will not function under 64-bit Windows 7 or later, since it relies on DEBUG, a 16-bit program!

To make a copy of this code on your own PC, simply download and run our BIOSDUMP Batch program which includes a DEBUG script file that uses MS-DEBUG to read all the bytes from F0000h to FFFFFh in memory and write them to the file BIOSDUMP.BIN. Being DEBUG purists, this script file was designed to make sure the first 256 bytes of DEBUG's memory space would not be altered. (Note: This download also includes VIDEODMP.BAT and a script file for dumping the C000: segment; the standard location for VGA video BIOS code.) The scripts cause DEBUG to perform a two-step process that first copies the code to a 65,280-byte file, followed by a 256-byte file. Then the two *.BIN files are combined using the DOS "COPY /b" command; lastly, the intermediate *.BIN files are deleted.
Instructions for using BIOSDUMP.ZIP: Simply extract all 4 files to a Windows or DOS folder of your choice, then double-click on one of the *.BAT files, or enter its name at a DOS prompt to run it. The Batch programs run the associated *.DSF Debug Script so you don't have to type in the DEBUG commands. (If run from a bootable floppy diskette, make sure a copy of DEBUG.EXE is in the same location or in the path.)

In order to quickly skim through the contents of any *.BIN file created by these programs, or to search for either a text string or hex byte pattern, we recommend using the free hex/disk editor, HxD.

BIOS Checksum Bytes

The last location in an early PC's BIOS chip was called its CHECKSUM byte. It was used to help check that none of the chip's bytes had become corrupted (changed values). For example, the Checksum Byte of the first IBM Personal Computer is "EB". This value was computed by first adding together every preceding byte of the PC's 8 KiB BIOS code, two bytes at a time, keeping only the last 8-bits (one byte) of the sum, and finally subtracting that value from 100 hex. Thus, the Checksum Byte ensures that running an "8-bit Checksum operation" on every byte in the BIOS chip will produce a result of zero (0). [ Note: An 8 KiB file full of only FF bytes would also have an 8-bit Checksum of zero, but its 32-bit Checksum would be 1FE000; which is the sum of all 8,192 of its bytes added together (2,088,960 decimal).] In summary, an 8-bit Checksum Byte can be computed as follows (we also show in the table below all checksum data for the original IBM PC's three different BIOS chip versions):

1. When you have finished coding the BIOS, insert a Checksum Byte of 00 (or simply proceed without one).
2. Use a program or utility to compute the 8-bit Checksum of these bytes.
3. Subtract this checksum from 100 hexadecimal; for example, in the table below: 100h - 15h = EB.
4. The result is the 8-bit Checksum Byte for the BIOS; ensuring its final 8-bit Checksum is zero.

If you wish to compute the 8-bit (or 16- or 32-bit) Checksum of a file, you can easily do so using HxD, as shown here:

This BIOS file begins with the part number of its programmed ROM chip (5700051) followed by IBM's
copyright phrase ("COPR. IBM 1981") which some have mistaken as an erroneous spelling of 'Corp.'

What Most Can Find Ain't All There Is!
(Or: There's more to modern BIOS code than most have imagined!)

Although you could boot-up your computer with a DOS boot diskette or a CD-ROM disc so there's no chance of its memory being altered by anything but 16-bit real DOS before dumping its contents, even then there's no assurance (without prior research) this will provide you with a copy of all the bytes actually contained in its "BIOS chip(s)". Why? Because the BIOS code may include features that are never retained in memory; for example, a PC company's splash screen that often appears on the display when a computer is first turned on. Or, for example, this familiar EPA ("Energy Star") Logo:

This bit-map file had to be converted from a special AWARD BIOS Bit-map file ("AWBM") after extracting it from an LHA compressed file named "AwardBmp.bmp" stored within a PC's actual 128 KiB BIOS chip.

To see just how sophisticated modern BIOS code has become; using compression and possibly even encrypting its machine code, we've decided to delve into some of the methods used by BIOS manufacturers for our readers. We want you to see how much BIOS code has changed over the decades.

I wrote those words above way back in 2007; roughly two decades ago! You've likely seen in additions I made to this page far above how various features were added as soon as PC Clones with even an Intel 80286 CPU were being produced.

Feel free to write to me about your own PC's BIOS if you have an interest in determining its contents and where its BIOS code is actually stored.

VMWare and The VMWare Legacy BIOS File: BIOS.440.ROM

-a e753
xxxx:E753 jmp d500
xxxx:E756  [Just press ENTER key here!]
-u e753 e755
xxxx:E753 E9AAED            JMP     D500
            ----

C P / M   B A S I C   I / O    S Y S T E M    (B I O S)
                    COPYRIGHT (C) GARY A. KILDALL
                             JUNE, 1975