Anyone running DOS games encounters the memory question quickly. A game demands a quantity of conventional memory that appears to be available and is not, or wants expanded memory when extended memory is present, or refuses to start on a machine with vastly more RAM than it needs.
These are not arbitrary requirements. They come from a hardware constraint that shaped a decade of PC software design.
The 640K boundary
The original PC architecture could address one megabyte. The lower 640 kilobytes were allocated to programs. The remaining 384 kilobytes were reserved for hardware: video memory, adapter firmware, the system BIOS.
The 640 kilobyte figure was not a mistake so much as a generous allocation that stopped being generous. Programs grew, the boundary did not move, and the entire subsequent history of DOS memory management is workarounds for a limit that could not be raised without breaking compatibility.
Four kinds of memory, doing different jobs
- Conventional memory: the first 640K, where DOS programs actually run. Always the scarce resource.
- Upper memory: the 384K reserved region above it. Unused portions could host drivers, freeing conventional memory.
- Expanded memory: additional memory accessed through a window mapped into the upper region, a page at a time.
- Extended memory: memory above one megabyte, accessible in protected mode but not directly by ordinary DOS programs.
Expanded and extended are the pair that cause the most confusion, and the names do not help. Expanded memory was a bank-switching scheme, originally implemented on add-in cards, that let a program see a small window onto a large pool. Extended memory was simply the memory beyond one megabyte on a capable processor, which required switching the processor’s mode to use.
Later systems provided expanded memory by emulating it using extended memory, which is why a machine can offer either depending on how it is configured, and why a game that demands one may fail on a machine configured for the other.
Why games wanted conventional memory specifically
Game code and its most performance-critical data had to live in conventional memory to be reachable without paging or mode switching. Anything else meant overhead in the parts of the code that could least afford it.
This is why loading a mouse driver, a sound driver and a CD-ROM driver could stop a game running. Each occupied conventional memory. Between them they might take a hundred kilobytes from the 640 available, and the game needed most of what remained.
Hence the era’s characteristic ritual: boot configurations that loaded the minimum set of drivers for a particular game, with everything possible relocated into upper memory. People maintained several such configurations and chose between them at startup.
What this means today
Running these games now usually means an emulated DOS environment, which removes the hardware constraint but reproduces the software model. The 640K limit still applies inside the emulation, because the games depend on it existing.
The practical difference is that resources are no longer genuinely scarce. Emulators can provide expanded and extended memory generously and load drivers into upper memory without the fiddly optimisation the original hardware demanded.
- If a game reports insufficient memory despite plenty being configured, check which type it wants. It is usually asking for conventional memory specifically.
- Load only the drivers a given game needs. A CD driver present for a game that does not use one is pure waste.
- Where a game offers a choice of memory model at install time, the choice is frequently recorded in a configuration file and can be changed without reinstalling.
The underlying skill has not changed much. Working out what a DOS game wants is mostly reading its documentation carefully and believing what it says, because these requirements were documented precisely at a time when getting them wrong meant the software did not run at all.