You've come to this page because you've asked a question similar to the following:
What is the boot process employed by old-style PC/AT and PC98 firmwares?
This is the Frequently Given Answer to such questions.
Bootstrapping on systems with old PC/AT and PC98 firmwares involves two types of boot record. A boot record comprises a small program that is stored in a fixed sector of a disc. The two boot records are a Master Boot Record and a Volume Boot Record.
From the firmware's point of view, there is only one type of boot record. The firmware loads sector #0, the very first sector of the disc, into memory at a fixed location, physical address 0x00007C00, and executes it. On floppy discs, which are not partitioned but are single volumes spanning the whole disc, this boot record is a Volume Boot Record that immediately invokes the boot loader for the system installed in that volume, be it an operating system or a boot manager program such as IBM Boot Manager or the TAU Boot Manager. On partitioned discs, however, this boot record is a Master Boot Record, whose function is to scan the disc's partition table, and overlay itself with a Volume Boot Record from a partition on that disc, chain loading it as if it were invoked directly by the firmware.
The Plug and Play BIOS Specification, published by Compaq, Intel, and Phoenix in 1994, purports to specify the initial execution environment of the bootstrap code in a boot record. It specifies the following register values upon entry to the boostrap program, which starts at the first byte of the sector:
DLES:DI$PnP" firmware data structure
In fact, no current or historical operating system actually adheres to
this specification. The volume boot records for most versions of Windows
NT and MS-DOS immediately overwrite the contents of the ES
register, for example. Most newer VBRs merely accept the firmware drive
number in the DL register.
A 2010 extension to the Plug and Play BIOS Specification, by Rob Elliott of Hewlett Packard and entitled the EDD-4 Hybrid MBR boot code annex, purports to specify further standard register values upon entry to a boot record, in addition to the ones already specified and building upon a de facto partition table entry pointer. These are:
DS:SIEAX
In fact, there is no such de facto partition table entry pointer. The
values in the DS:SI register pair are accidental, and are the
results of how IBM's and Microsoft's Master Boot Record code, supplied by
older versions of OS/2, MS-DOS, PC-DOS, and Windows NT, happened to be
written. The volume boot records for all versions of Windows NT,
OS/2, and MS-DOS immediately overwrite the contents of the DS
register, at startup, without saving the prior value somewhere. The final
nail in the coffin, for the notion that this de facto standard exists to
be built upon in the first place, is that since the advent of Windows NT
6.0 in 2007 it isn't actual practice at all and VBRs don't
receive that register pair upon entry. The Windows NT 6.0 Master Boot
Record code now uses the DS:BP register pair for the same
purpose, breaking anything that relies on the supposed de facto standard.
Of course, nothing did rely upon the purported de facto standard,
and no operating system boot record expects a partition table pointer in
DS:SI any more than operating system boot records expected a
PaP table pointer in ES:DI. These standard registers exist
only in the pages of specification documents and not in reality. The idea
of this pointer to a partition table entry was to provide the boot record
code with a means of locating the rest of the partition, whose boot record
it is, on disc. The "first sector" field in the partition table entry
(purportedly) pointed to provides a 32-bit absolute sector number. Adding
that base sector number to a volume-relative block number yields a
disc-relative sector number, allowing the bootstrap code to locate the
rest of the boot loader program and load it from disc.
But real bootstrap programs in Volume Boot Records don't operate that way. Instead, they rely upon the fact that the VBR contains, embedded within it, a BIOS Parameter Block. One of the fields of this BPB, Microsoft's and many others' claims to the contrary notwithstanding, is alive and well and in constant use by boot record code. This is the "hidden sectors" field, that, for a primary partition at least, records the number of "hidden" sectors between the start of the disc and the start of the volume whose BPB it is. It is that value that bootstrap code adds to volume-relative block numbers to yield disc-relative block numbers. (It is the 32-bit nature of this "hidden sectors" BPB field that imposes one of the 2TiB limits on PC/AT bootable disc volumes.)
The "hidden sectors" field of the BPB is one of two things that are part of a protocol for VBRs that is a de facto standard, but that isn't documented outwith the Frequently Given Answers and some Usenet discussions. The other part of the protocol is the "chkdsk flags" field of the BIOS Parameter Block. Together, these form an undocumented protocol between boot manager utilities and operating systems that are capable of being directly bootstrapped from secondary partitions in a PC/AT MBR partition table. As a boot manager loads the VBR of a partition into memory, preparatory to running it, it adjusts the "hidden sectors" and "chkdsk flags" field:
The "hidden sectors" is adjusted from the value on disc (which, thanks to the quirks of MS-DOS that every operating system since has had to inherit, isn't the offset from the start of the disc for secondary partitions — the reason that secondary partitions cannot be bootstrapped directly from disc without a boot manager as an intermediary) to the actual offset from the start of the disc.
The "chkdsk flags" field becomes the "drive letter" field for an in-memory boostrap BPB. It indicates the drive letter that the operating system loader should assign to the bootstrapped volume. If bit #7 is zero, no drive letter is being forced by the boot manager, and the boot loader is free to calculate one of its own. If bit #7 is one, then the drive letter, starting from 0 meaning 'C' (it not being possible to assign drive letters 'A' and 'B', sadly) is in bits 0 to 6.
Effectively there are no secondary partitions in the EFI partitioning scheme. To ensure adherence to the de facto PC/AT and PC98 bootstrap protocol, operating systems that understand the EFI partition table should write BPBs to volumes as if every EFI partition were a primary PC/AT MBR partition. And utilities that "slide" (i.e. move) partitions around on disc must update the "hidden sectors" field of the on-disc BPBs to reflect their new offsets from the start of the disc. Without either of these, partitions on EFI partitioned discs will not be bootable via their Volume Boot Records.
PC/AT and PC98 firmwares don't know anything about partition tables. They just load and run sector #0. On partitioned discs, the bootstrap code within the Master Boot Record knows about partition tables. It is expected to pick the "active" partition, and load and run its Volume Boot Record. (For those used to IBM terminology, this is the "startable" flag.)
In a PC/AT (a.k.a. MBR) partition table, the "active" flag is a byte field in a partition table entry, the "status" byte. The MBR bootstrap code knows that in the PC/AT partition scheme, the partition table entries for the four so-called "primary" partitions are embedded within the Master Boot Record itself. The MBR bootstrap code thus simply scans the four partition table entries within itself, looking for the first one with the "active" flag set. (Some MBR bootstraps are quite strict about this flag, even enforcing a requirement that exactly one, no fewer and no more, of the four primary partitions have this flag set.)
This MBR partition table status byte originally had just two defined values: 0x00 for "inactive" and 0x80 for "active". But some people got quite confused about this, thinking that these were firmware disc numbers (even though the value 0x00 most definitely does not indicate a floppy disc), and flag values of 0x81 and above ended up being stored in status bytes. So nowadays, the "active" flag is simply bit #7 of that byte, set to 1 if the partition is "active" and set to 0 if it is not.
For several years, because the boot process for fully fledged EFI systems does not involve any of these boot records at all, there was no equivalent to the "active" flag for the EFI partition table scheme. But now, as of version 2.3.1 of the UEFI Specification, global attribute bit #2 is defined as an "active" flag for EFI partition table entries. This permits the EFI partition table scheme to be used on systems that don't have modern EFI firmwares, but that still boot in the old PC/AT and PC98 way. The code in sector #0 of an EFI-partitioned disc contains a Master Boot Record that understands the EFI partition table rather than the PC/AT MBR one. Its operation is exactly analogous to that of the MBR boostrap code for the PC/AT MBR partition table scheme: It scans the EFI partition table entries, looking for one with the "active" attribute set, and loads and runs the Volume Boot Record of that partition, as if it were a "primary" partition in the PC/AT MBR scheme, and with the conventional registers set up upon entry.
There are, at the time of writing, two tools that will deploy
EFI-partition-table-aware Master Boot Record bootstrap code and thereby
make an EFI partitioned disc bootable in the old PC/AT and PC98 way: the
MBR bootstrap installed by
the NEWMBR command in the DASDPART utility
from the TAU System Utilities and the experimental "GPT" MBR in SYSLINUX.