Skip to content
FreeDOSDeep Dive Published Updated 7 min readViews unavailable

FreeDOS Memory Management: Conventional, Upper, and Extended Memory

A source-backed guide to FreeDOS conventional memory, UMBs, the HMA, XMS and EMS, with safe Jemm and Himem configuration and troubleshooting practices.

FreeDOS inherits the segmented, real-mode address space of the IBM PC. That history matters because “free RAM” is not one interchangeable pool: an application that needs conventional memory cannot automatically use megabytes of XMS, and a driver loaded below 640 KiB reduces the largest block available to the next program. Memory managers improve the layout, but they do not turn DOS into a protected-mode virtual-memory system.

Conventional memory is the scarce application workspace

In the conventional PC map, addresses from zero through the region below segment A000h normally provide as much as 640 KiB of conventional memory. The area from A0000h through FFFFFh is the upper-memory region. Video RAM, adapter ROMs, system firmware, and memory-mapped devices occupy parts of that upper range.

DOS loads its kernel data, device drivers, command interpreter, environment blocks, and resident programs into addressable memory. A conventional .COM or real-mode .EXE also needs a sufficiently large free conventional block. Consequently, “550 KiB free” and “550 KiB in the largest executable block” are not always equivalent: fragmentation can leave several holes whose total looks healthy while no single hole satisfies a large program.

FreeDOS MEM reports the installed memory categories and can attribute conventional or upper-memory use to loaded components. Treat its output as a measurement of the current boot, not a guarantee that another configuration will have the same layout:

C:\>MEM
C:\>MEM /C /P

The exact switches supported by a packaged MEM build should be confirmed with its help screen. Redirecting the report to a file before and after a configuration change makes comparisons reproducible.

The HMA is not the same thing as upper memory

The High Memory Area is the first 64 KiB minus 16 bytes immediately above the one-megabyte boundary. On an 8086, a 20-bit address wraps at one megabyte. Later processors can expose the extra addresses generated by combinations such as FFFFh:0010h when the A20 address line is enabled.

An XMS manager coordinates A20 and arbitrates use of the HMA. The FreeDOS kernel can move an eligible portion of itself there when configured with DOS=HIGH. This can recover conventional memory, but the HMA is a single special region; it is not a collection of UMBs and cannot hold arbitrary amounts of drivers.

The configuration directive combines kernel placement with use of upper-memory blocks:

DOS=HIGH,UMB

HIGH can only succeed when an appropriate XMS service is available. UMB tells DOS to link available UMBs into its allocation chain; a memory manager still has to provide those blocks.

XMS exposes memory above one megabyte through an API

Extended memory is RAM beyond the real-mode one-megabyte address space. An XMS manager such as HimemX provides a standardized interface for allocating handles, locking or moving extended-memory blocks, querying capacity, and controlling A20. A real-mode application does not gain a flat pointer to all that RAM merely because the manager is loaded; it calls the XMS entry point and follows the XMS contract.

HimemX is derived from FreeDOS Himem and exists in HIMEMX and HIMEMX2 variants. Its own documentation explains that the variants differ mainly in allocation strategy when firmware reports scattered extended-memory ranges. That distinction should be chosen because of an observed compatibility issue, not because the second filename sounds newer.

An external XMS manager may be paired with Jemm386:

DEVICE=C:\FREEDOS\BIN\HIMEMX.EXE
DEVICE=C:\FREEDOS\BIN\JEMM386.EXE NOEMS
DOS=HIGH,UMB

Paths vary by installation. More importantly, Jemm386 requires an external XMS manager, whereas JemmEx includes one. Do not copy both patterns into the same boot file:

DEVICE=C:\FREEDOS\BIN\JEMMEX.EXE NOEMS
DOS=HIGH,UMB

These are alternative examples. Confirm the executable names and supported options shipped with the installed FreeDOS release.

UMBs reuse holes in the adapter and ROM region

Upper Memory Blocks are usable ranges inside the upper-memory region, not all addresses between 640 KiB and one megabyte. A manager must avoid video memory, active ROM, and device mappings. Jemm can map extended RAM into suitable holes while the processor operates in virtual 8086 mode. Once DOS has linked those UMBs, DEVICEHIGH can request that a configuration-time driver be placed there and LOADHIGH or LH can request the same for a command or TSR.

DEVICEHIGH=C:\FREEDOS\BIN\DISPLAY.SYS CON=(EGA,,1)
C:\>LH C:\FREEDOS\BIN\DOSKEY.COM

Neither keyword promises success. If a driver is larger than the available block, has initialization constraints, or refuses high loading, DOS may leave it low or report an error. Load order matters because an early component can consume the only UMB large enough for a later one.

Jemm supports include and exclude ranges, but its manual explicitly warns that forcing a range which is not actually free can cause trouble. Guessing I= ranges from a generic online configuration is unsafe on real hardware. Start with automatic detection, measure, and change one range at a time only when the machine’s map is known.

EMS is bank-switched memory, not another name for XMS

Expanded Memory Specification software exposes memory through an interrupt API and, for classic EMS use, a 64 KiB page frame divided into four 16 KiB windows. An application maps selected logical EMS pages into those windows. The mechanism originated before broadly usable extended memory, but an expanded-memory manager can emulate it using XMS-backed RAM.

Jemm supplies EMS, UMB, VCPI, and related services. Its NOEMS option disables EMS when only UMBs or other services are wanted. That can avoid reserving an EMS page frame, but old applications which require EMS will then fail. Conversely, enabling EMS is not useful merely because the machine has abundant RAM; the foreground application must actually use the EMS API.

Jemm386 uses 80386 virtual-8086 facilities and is therefore inappropriate for an 8086 or 80286 system. Older CPUs need a configuration and manager compatible with their processor. This is one reason FreeDOS offers multiple installation media and memory configurations rather than a universal “best” recipe.

Protected-mode extenders add another layer

DOS extenders let a program switch into protected mode and address more memory while retaining DOS services through a host interface. DPMI and VCPI are not synonyms for XMS or EMS, although a manager may provide several of them. A game can require EMS, a compiler can use XMS for swapping, and a protected-mode application can require DPMI; the presence of one does not prove the others are available.

Virtualization also affects compatibility. A memory manager manipulates CPU modes, page tables, and low-level address mappings, so an option that works on a physical 486 can behave differently under an emulator. Jemm documents compatibility switches and troubleshooting guidance; apply them in response to a specific symptom rather than enabling a collection of folklore options.

Optimize with a reversible boot-and-measure loop

Before editing FDCONFIG.SYS, preserve a known-good copy and ensure the boot menu offers a minimal configuration. FreeDOS can bypass or trace startup processing with its boot keys, which is essential when a new manager or high-loaded driver hangs before the shell starts.

A disciplined tuning sequence is:

  1. Boot a minimal configuration and save MEM /C output.
  2. Add the XMS/EMS manager appropriate for the CPU, then reboot and measure.
  3. Enable DOS=HIGH,UMB, reboot, and verify that the services actually appeared.
  4. Move one driver or TSR high at a time.
  5. Run the real workload, not only MEM, because available kilobytes do not prove application compatibility.
  6. Revert the last change if stability, DMA, sound, networking, or disk access regresses.

The goal is not the largest possible “free” number. It is the largest stable conventional block that still supplies the APIs and drivers the workload needs. A configuration that saves three kilobytes but makes a firmware utility or network driver unreliable is worse, not better.

Related:

Sources:

Comments