The Fixed Disk Parameter Table, or FDPT, is a structure primarily used by the BIOS in IBM compatible computers, but is also of critical importance to some (especially older) operating systems which do not use the BIOS.
The FDPT was introduced in the IBM PC/XT as a necessity in implementing hard drive (aka fixed disk) support; however, I’ll skip the PC/XT specific details. The IBM PC/AT redefined the FDPT format, but the purpose remained the same: Define the physical characteristics of a hard disk so that the same BIOS ROM could be used with more than a single drive model. Most importantly, the FDPT contained the disk geometry—the number of cylinders, heads, and sectors per track.
Why was all this information necessary? The old, pre-IDE hard disk subsystems in the IBM PC/AT did not support any discovery mechanism. Rather than inquiring the characteristics from the hard drive directly, as is the standard with modern disks, the BIOS had to know its physical characteristics. All disk commands used cylinder/head/sector (CHS) addressing, so the BIOS had to know the disk geometry. Further complicating matters was the fact that the hard drive and the disk controller were physically separate devices.
The disk controller itself needed to know the disk geometry in order to support multi-sector operations. When a multi-sector command was started, the user (that is, the BIOS or an operating system) programmed the initial CHS address into the controller, but the controller needed to know when to switch to the next head or seek to the next cylinder. The Set Parameters command was used to program the drive geometry into the controller.
Even SCSI disks, which only address logical sectors by number instead of a cylinder/head/sector address, had to present some kind of more or less faked geometry to the BIOS and the OS. However, it should be noted that the FDPT does not apply to SCSI disks, only to ATA disks (including IDE and EIDE).
The original IBM PC/AT BIOS supported only a few drive types. The disk parameter tables for all supported models were hardcoded in the BIOS ROM and the non-volatile CMOS memory stored an index into the table. During initialization (POST), the BIOS set up the corresponding vectors in the interrupt table to point to the appropriate entries in ROM.
In mid to late 1980s, BIOSes began to support user-defined drive types. There were so many different drive types on the market that a table built into the BIOS ROM was no longer adequate. Disk geometry was stored in the CMOS memory and copied to the FDPT during the POST process. In some cases the FDPT was stored at address 0:300h and 0:310h (for the first and second fixed disk, respectively), effectively overwriting 4 interrupt vectors per FDPT. These interrupt vectors (C0h-C3h and C4h-C7h) were reserved for the IBM ROM BASIC and therefore could be reused on non-IBM systems with no ROM BASIC. Some newer systems stored the FDPT in the Extended BIOS Data Area (EBDA), but that may cause problems if a memory manager (such as EMM386) relocates the EBDA and fails to update the corresponding vectors in the interrupt table.
On machines with ROM shadowing (standard at lease since the mid-1990s), the BIOS built the FDPT in the shadowed ROM area, without needing any RAM area potentially conflicting with other users. That has been the standard method for 486 and later systems.
Since the mid-1990s, operating systems typically did not care about the FDPT because information about attached storage devices is discovered through IDE commands or another hardware-specific protocol. However, for older operating systems, the FDPT was still critical. Typical FDPT users apart from the BIOS were operating systems such as OS/2, Xenix, or other PC UNIX variants.
These operating systems typically chose not to use the BIOS for performance reasons because they ran in protected mode, and in some cases (such as 286 Xenix), only switched to protected mode once during initialization and never switched back as Intel intended. Such systems therefore could not use the BIOS at all. With pre-IDE AT-compatible disk subsystems, the FDPT was the only way for an OS with no BIOS access to determine the disk geometry (and hence size) which was key for the OS’s disk driver. The drive type information in the CMOS was not sufficient because the drive types were not necessarily consistent across BIOS implementations and the OS had no reliable way to locate the predefined disk parameter tables in the BIOS ROM, especially when add-on disk adapters were involved. Likewise with user-defined drive types, there was no standardized method to store the information in CMOS memory.
As long as hard drive sizes stayed under about 500 MB, the FDPT was an adequate method to discover ATA fixed disk information. The only minor issue was with a few old operating systems that inadvertently overwrote the FDPT for user-defined drive types stored in RAM (either in the interrupt vector table or the EBDA) and failed to find the disk(s); this affected at least 286 Xenix version 2.1.3, and possibly old versions of Novell NetWare and other operating systems.
When disks larger than 500 MB appeared, the FDPT became problematic. When the BIOS translated the disk geometry (regardless of whether CHS addressing or LBA was used on the hardware level), the FDPT no longer matched the geometry used on the ATA interface level. That was a problem for operating systems like Xenix which assumed that the FDPT geometry matched the ATA geometry.
Around 1995, Phoenix defined a new FDPT, now called the Device Parameter Table, with a special signature and a checksum. This DPT provided information about both the logical and physical geometry. However, that did not help existing operating systems which relied on the FDPT. For that reason, BIOS setup programs typically offer several choices of disk handling for large IDE disks. The default is normally suitable for DOS and operating systems such as Windows, Linux, or OS/2. Another translation method (often called “Large”) is provided for operating systems such as SCO UNIX or older versions of NetWare.
The “Large” method stores physical geometry information in the FDPT. That breaks operating systems which read the FDPT and then use the BIOS INT 13h interface to access the disk. However, an operating system which reads the FDPT and accesses the disk directly can obtain the expected information that way.
When working with virtualization, the most effective solution for old operating systems is usually creating virtual disks smaller than 504 MB. In that case, no translation is needed and the FDPT contains the expected information regardless of whether the OS uses the BIOS or its own driver to access the disk.