The BIOS Diskette Parameter Table at INT 1Eh

The legacy IBM PC diskette parameter table is a compact firmware data structure reached through the interrupt vector at INT 1Eh. It tells compatible BIOS floppy code about controller parameters, sector sizing, track layout, formatting values, head settling, and motor startup. It is not a partition table, not a DOS filesystem structure, and not a universal hardware description. The most important operational fact is ownership: the BIOS or resident floppy driver that performs I/O must agree with the table currently in use.

This article covers the 11-byte table documented in IBM’s PC/PS/2 BIOS interface reference. Later controllers and diskette drivers can implement additional behavior. An ordinary DOS application should use DOS or BIOS diskette services rather than patching the table while a driver is active.

INT 1Eh is a pointer, not a service call

The interrupt vector table stores a far pointer for each interrupt. The vector for interrupt 1Eh is at physical offset 1Eh * 4 = 78h, or 0000:0078 in real-mode notation. That vector points to the diskette parameter table; executing INT 1Eh is not the ordinary mechanism for reading sectors. This distinction matters because tools that assume every interrupt vector points to executable code can misinterpret a data-table vector.

Do not assume that the pointer always targets a fixed ROM location. Historical BIOS and DOS implementations can use a writable copy in RAM, and a driver may temporarily replace the pointer while performing a specialized operation. Read the live far pointer through a carefully bounded diagnostic, validate that the pointed-to bytes are readable in the current environment, and record the machine or emulator before interpreting them. A far pointer that is valid on an original PC is not automatically meaningful in a protected-mode process.

The documented 11-byte layout

IBM’s table assigns one byte to each of these fields: first Specify byte, second Specify byte, motor-off delay in timer ticks, bytes-per-sector code, sectors per track, gap length, data length (DTL), format gap length, format fill byte, head-settle time in milliseconds, and motor startup time in eighths of a second. The bytes-per-sector field uses codes 00h through 03h for 128, 256, 512, and 1024 bytes. A motor-start value of 8 represents one second in the documented unit.

These are not all interchangeable “geometry” values. Sectors per track and bytes per sector help describe a diskette operation, while Specify bytes and timing fields affect how the floppy controller is commanded. The format gap and fill byte belong to a format operation. A report should preserve the raw bytes as well as decoded fields because conventions can vary across controller or BIOS generations.

Avoid inferring a physical drive’s complete media capabilities from one table. The table reflects a BIOS path’s operating parameters, not necessarily every format recognized by a later DOS driver or every capability of an attached USB bridge. Conversely, a DOS volume can operate through a driver that uses parameters not represented in the table you inspected.

Read-only inventory pattern

A safe inventory tool should treat the pointer as untrusted platform state. First capture the vector bytes, then decode segment:offset using the current mode’s address rules, check for overflow while computing the effective address, and copy exactly the documented 11 bytes into a private buffer if they are accessible. Do not write through the pointer. Do not read an assumed 32-byte structure merely because another firmware table has that length.

Pseudocode for the intent:

far_pointer = read_IVT_vector(0x1E)
if pointer_is_unreadable_or_unmapped(far_pointer):
    report "INT 1Eh target unavailable in this execution mode"
else:
    raw = bounded_copy(far_pointer, 11)
    decode fields using IBM layout, preserving raw bytes
    record BIOS, DOS driver, controller, and media context

The checks should reject a pointer crossing a memory boundary that the program cannot access, not silently wrap the segment offset. A 16-bit offset can wrap within a segment; the physical address calculation and memory model need explicit handling. Under a DPMI host, use the host’s documented real-mode memory access rather than assuming a C far pointer maps the low-memory address.

Why runtime patching is dangerous

Changing the table can alter how subsequent BIOS diskette requests configure a controller or format a track. A DOS floppy driver may have copied the original bytes and use that private copy; another may consult the live vector; a cache or TSR may maintain additional state. Patching one table therefore may have no effect, may affect only part of the stack, or may make one component disagree with another.

If a driver intentionally hooks INT 1Eh, it should preserve the previous pointer and document the exact operation it is changing. Installation order and chain ownership matter. A second TSR can replace the same vector, and blindly restoring an old value during uninstall can disconnect a newer owner. Use the driver’s documented API or configuration option if one exists. Do not use a general-purpose DOS application to experiment on mounted media.

Formatting is especially sensitive. A mismatched sectors-per-track, DTL, gap, or fill value can produce a disk that appears to format but has incompatible sector layout or controller behavior. A media descriptor or BPB also has its own filesystem-level meaning; changing an INT 1Eh byte does not automatically update an existing filesystem’s BPB or make a volume safe to mount.

Diagnose by layer

When a floppy operation fails, separate the BIOS data from the driver and device path. Record the vector pointer and 11 raw bytes, the BIOS INT 13h status, the DOS block-device driver and version, diskette type, controller model, emulator profile, and whether a cache or redirector is loaded. Compare the observed table with the target BIOS documentation, not a value copied from a different PC clone.

If only formatting fails, inspect format-specific fields and the driver’s media-type selection before blaming the filesystem. If reads fail after swapping media, inspect the driver’s change-detection and reset behavior; the table alone cannot prove that media change was observed. If the BIOS table looks reasonable but DOS behaves differently, the driver may be using internal state rather than the live table.

Acceptance checks for a diagnostic

Use a VM snapshot or read-only test environment. Verify that the tool reports the vector and exactly eleven bytes, labels the byte units correctly, and never modifies low memory. Test an invalid or unmapped pointer in a harness and confirm that the program exits with a useful diagnostic rather than faulting. Compare a known IBM-compatible BIOS against its reference, then repeat on a distinct emulator or machine before claiming broader compatibility.

Do not test by changing controller bytes on the only copy of a disk. If an intentional driver experiment is required, use disposable media or an image, record the original vector and bytes, change one parameter through the driver-supported path, and restore via a clean reboot. Verify the filesystem after the experiment and retain the before/after image hashes.

Keep an explicit distinction between a BIOS parameter-table byte and the DOS block driver’s own media descriptor or BPB. They can describe related parts of the same diskette path but are maintained by different layers and need not be byte-for-byte identical. A useful bug report includes both when available, together with the driver version and the INT 13h result code. That evidence helps determine whether the problem is firmware geometry, controller timing, DOS media recognition, or filesystem interpretation instead of encouraging blind table edits.

The INT 1Eh table is valuable because it exposes part of the classic BIOS floppy contract. It is not a public configuration API for every driver. Treat it as firmware-owned shared state, distinguish controller timing from media geometry, and prefer a read-only report unless the exact driver documentation authorizes a change.

Related:

Sources: