Skip to content
FreeDOSDeep Dive Published Updated 7 min readViews unavailable

BIOS INT 11h and 12h: Read Legacy Equipment and Conventional Memory

Interpret the BIOS equipment word and INT 12h memory figure as legacy hints, not a complete inventory or modern physical memory map.

Two tiny BIOS calls often appear in old DOS utilities because they are simple and broadly compatible: INT 11h returns an equipment-list word, and INT 12h returns the amount of contiguous conventional memory beginning at physical address zero. They are useful for compatibility checks and historical diagnostics. Neither is a comprehensive probe of installed hardware, and neither should be used as a modern memory allocator’s capacity report.

Their apparent simplicity is exactly why they are easy to misuse. INT 11h returns a bitfield whose meaning depends on the original machine family and later compatibility conventions. INT 12h reports a conventional-memory boundary in kilobytes, not all physical RAM. A program that interprets either value as ground truth can reject valid virtual hardware, misreport equipment, or overwrite memory reserved by firmware and drivers.

; Query the BIOS equipment word.
xor     eax, eax        ; clear the high word before using EAX on 386+
int     11h
mov     [equipment], ax

; Query contiguous conventional memory in kilobytes.
int     12h
mov     [conventional_kb], ax

The example assumes an assembler that accepts 32-bit register names while running in a suitable mode. On an 8086-only build, clear AX as required by that assembler and do not inspect a nonexistent high word. Save returned values before another BIOS call if the caller needs them later.

The equipment word is a historical contract

The AX result from INT 11h encodes a machine’s configuration in a compact word. Bits describe fields such as the initial video mode, serial and parallel port counts, game port presence, and legacy diskette information. The interpretation changed across IBM PC, XT, AT, PS/2, and compatible systems. Some bits are reused or documented as model-specific; they are not a universal inventory schema.

An equipment bit means the BIOS reports a capability in its compatibility structure. It does not prove that a peripheral is physically connected, working, or available to the current DOS program. A virtual machine may deliberately report a floppy device backed by an image, or emulate an equipment word for a guest operating system. Some BIOS implementations have known reporting defects. For floppy presence, for example, historical compatibility notes recommend validating through disk BIOS services rather than trusting a potentially incorrect bit alone.

Treat reserved or unknown bits as unknown. Mask only the specific field your application understands, preserve the raw word in diagnostic output, and avoid “fixing” firmware state based on an interpretation from another PC model. Before testing 386-and-later high bits in EAX, clear its high word before the interrupt because older BIOSes only return a 16-bit value and do not know to clear the upper half.

INT 12h is not installed-memory size

INT 12h returns AX as kilobytes of contiguous memory starting at absolute address 00000h. Historically this corresponds to the conventional-memory top reported in the BIOS Data Area at 0040h:0013h. On an original PC or XT, switches could determine the value. On later systems, firmware calculates or initializes it according to its memory map and compatibility policy.

The result does not describe extended memory above the conventional region, address holes, device memory, memory remapped above 4 GiB, or RAM reserved for firmware. It can be lower than the machine’s physical RAM because conventional DOS memory is a constrained region. A DOS program should not multiply this value by 1024 and allocate that many bytes at the top of conventional memory: DOS, the BIOS Data Area, interrupt vectors, device buffers, and resident programs already occupy or reserve portions of the region.

The equipment word is similarly not a modern “device tree.” Its floppy count occupies bits 7-6 only when bit 0 indicates floppy equipment, while other bits describe the machine family’s legacy configuration. A clone BIOS can set fields for compatibility even when the physical board uses different hardware. A virtual machine can expose a floppy image as a virtual drive, and some BIOS revisions have been observed to report a floppy bit incorrectly. Display the raw word in hexadecimal and decode only fields whose platform applicability is known. This is more honest than printing a definitive list of installed devices from a single 16-bit number.

When comparing BIOS values with DOS state, be precise about which layer produced each value. INT 11h returns the BIOS equipment word, while INT 12h returns the conventional-memory figure stored by the BIOS. DOS drivers may reserve resources later, and a TSR can change other tables. A disagreement can reflect a legitimate layer boundary, stale firmware data, or a bug. It is not safe to overwrite the BIOS Data Area to make the report “match” a preferred value.

Do not confuse this call with INT 15h/AH=88h, E820 memory-map enumeration, XMS, EMS, or DPMI allocation. E820 returns typed physical ranges; XMS and EMS provide their own manager APIs; DPMI gives protected-mode clients a host-managed address space. Each answers a different question. If a diagnostic tool needs an installed-memory map, E820 is the more appropriate BIOS interface when supported. If an application needs usable memory, ask the relevant memory manager rather than infer it from the BIOS total.

Use cases that remain legitimate

These calls are still useful when reproducing software that intentionally checks the original IBM-compatible environment, reporting what firmware told a legacy guest, or teaching the relationship between BIOS data and DOS startup. An installer may use the equipment word as one weak clue before asking the user or probing a documented device API. A memory diagnostic can display the INT 12h boundary beside the E820 map to show why the numbers differ.

The calls are poor choices for security decisions, device authorization, driver selection without fallback, or memory-safety boundaries. An equipment flag is not authentication. A conventional-memory size is not proof that a region remains free. A hypervisor, compatibility BIOS, or TSR can influence guest-visible state without changing physical host hardware.

Diagnostic procedure

When a report looks wrong, capture the raw AX value from INT 11h, the AX result from INT 12h, the BIOS or emulator identity, and the DOS memory-manager configuration. Compare INT 12h against the BIOS Data Area word only as a consistency check, not an independent truth source, because both may be initialized from the same firmware state. If present, compare E820 ranges and the DOS/XMS/DPMI manager’s own reported availability. Explain the difference between installed, firmware-reported, conventional, and allocatable memory in the report.

Test under at least one legacy BIOS and one modern emulator configuration if the utility claims broad compatibility. Include a machine with a small conventional-memory boundary, one with extended memory, and virtual hardware with a deliberately configured device set. Ensure the program handles zero or implausible values as diagnostics rather than indexing memory or issuing an unsafe I/O operation.

The operational rule is simple: preserve these calls as compatibility observations. INT 11h is a dated equipment bitfield; INT 12h is a conventional-memory limit. They are not replacements for typed resource discovery, driver capability negotiation, or managed allocation.

Example reporting format

A useful inventory line might say: “BIOS equipment word 0x0021; legacy bits indicate a reported floppy configuration. INT 12h reports 640 KiB conventional memory. These are firmware compatibility values and do not represent installed physical memory or current DOS free memory.” Pair it with E820 output when available, and show the DOS memory manager’s report separately. If INT 12h is unexpectedly small, investigate memory-manager configuration, firmware reservations, adapter memory, or firmware setup instead of assuming a DIMM has failed.

For a program that only needs to decide whether to show a legacy-device warning, make the decision advisory and allow the user to continue. For a memory-sensitive executable, use the DOS allocator or memory-manager APIs and handle allocation failure. That keeps compatibility diagnostics from becoming an unsafe substitute for resource management.

Related:

Sources:

Comments