FreeDOS and BIOS INT 13h: CHS, LBA Extensions, and Safe Disk Access

On a classic x86 PC, BIOS interrupt INT 13h provides firmware disk services to boot code and real-mode software. DOS programs can reach it directly, but doing so is not the same as opening a DOS file. A raw BIOS read or write addresses sectors below the filesystem layer; an active DOS cache, an open file, or a resident driver may hold a conflicting view of those sectors.

The interface evolved from cylinder/head/sector (CHS) requests to Enhanced Disk Drive (EDD) extensions that use logical block addresses. The two styles have different parameter formats and limits. A utility should probe the extensions it intends to use, validate every returned status, and prefer DOS file and block APIs whenever it is working with an ordinary mounted volume.

CHS calls carry geometry assumptions

The classic read and write services use geometry fields packed into registers: a cylinder, head, starting sector, sector count, and BIOS drive number. The BIOS and controller translate that geometry into device operations. The encoding is historically constrained, BIOS implementations differ, and requests that cross track or transfer-buffer boundaries have compatibility pitfalls.

The drive number in DL is a firmware identifier, not a DOS drive letter. Common conventions assign floppy and hard-disk ranges differently, and option ROMs or boot managers may alter which device is presented first. Do not convert C: into a guessed DL value. Query or preserve the firmware-provided drive number for the device the program actually booted from.

CHS limits are also why larger disks need extension support or a driver that understands the device. A partition table may describe sectors that old BIOS calls cannot address. Seeing a volume in DOS does not prove that a direct CHS call can safely reach every sector on it.

Probe EDD before using LBA functions

EDD defines a capability check through INT 13h with AH=41h, a signature in BX, and the target drive in DL. A successful response clears carry, returns the complement signature, and reports supported extensions in CX. The caller must verify those values rather than assuming all BIOSes implement the same extension set.

An assembly outline of the signature test is:

mov ah, 41h
mov bx, 55AAh
mov dl, [bios_drive]
int 13h
jc no_edd
cmp bx, 0AA55h
jne no_edd
test cx, 0001h
jz no_edd
; The advertised extended disk-access bit is present.

Extended reads and writes use AH=42h and AH=43h with a Disk Address Packet (DAP) addressed through DS:SI. The common DAP form contains a size byte, a reserved byte, a sector count, a transfer-buffer offset and segment, and a 64-bit starting LBA. The data buffer and packet must satisfy the BIOS and platform’s real-mode memory constraints. Preserve the packet layout exactly; do not pass a compiler-packed structure unless its size and offsets have been checked.

Carry and the returned status register are part of the result. A call that returned to the next instruction is not proof of successful I/O. On failure, capture the BIOS status and use the documented reset or retry policy only when safe. Retrying a write blindly can repeat a partially completed change.

Never bypass DOS casually

DOS owns filesystem semantics, open-file state, and sometimes a disk cache. A raw write to a sector that belongs to a mounted FAT volume can make on-disk metadata disagree with cached metadata in memory. Resident caching software may intercept BIOS calls, but another driver or direct controller path can bypass that cache. Sector writes should be limited to specialized utilities with exclusive access, a verified image or backup, and an explicit recovery plan.

For normal application data, use DOS file functions. They know about paths, current directories, handles, sharing, and the mounted volume. For partitioning, recovery, boot-sector repair, or imaging, work from a controlled boot environment where the target volume is not mounted for ordinary use. Write an image or backup first and verify it before changing the original disk.

Testing should include a device without EDD support, an LBA beyond the old CHS range, an invalid drive ID, a short transfer, and a read-only or write-protected medium when available. Emulator success is useful but not universal evidence: test real firmware or the exact virtual BIOS that the program is expected to support.

INT 13h remains important for understanding boot chains and legacy utilities, but it is a hardware-facing compatibility interface rather than a safe substitute for a filesystem API. Probe capabilities, keep writes isolated, and report the firmware status needed to reproduce failures.

Related:

Sources:

CHS calls carry geometry assumptions

Probe EDD before using LBA functions

Never bypass DOS casually

Comments