Conventional memory

It is the read-write memory directly addressable by the processor for use by the operating system and application programs.

The design of the original IBM PC placed the Color Graphics Adapter (CGA) memory map in UMA.

To maintain compatibility with older operating systems and applications, the 640 KB barrier remained part of the PC design even after the 8086/8088 had been replaced with the Intel 80286 processor, which could address up to 16 MB of memory in protected mode.

One technique used on early IBM XT computers was to install additional RAM into the video memory address range and push the limit up to the start of the Monochrome Display Adapter (MDA).

Assuming the System BIOS still permitted the machine to boot (which is often the case at least with BIOSes for embedded PCs), the video card in a so called headless computer could then be removed completely, and the system could provide a total of 960 KB of continuous DOS memory for programs to load.

Similar usage was possible on many DOS- but not IBM-compatible computers with a non-fragmented memory layout, for example SCP S-100 bus systems equipped with their 8086 CPU card CP-200B and up to sixteen SCP 110A memory cards (with 64 KB RAM on each of them) for a total of up to 1024 KB (without video card, but utilizing console redirection, and after mapping out the boot/BIOS ROM),[13] the Victor 9000/Sirius 1 which supported up to 896 KB, or the Apricot PC with more continuous DOS memory to be used under its custom version of MS-DOS.

These drivers and utilities typically used some conventional memory permanently, reducing the total available for standard DOS programs.

But in many cases a choice had to be made by the computer user, to decide whether to be able to run certain standard DOS programs or have all their favorite drivers and TSRs loaded.

Loading the entire list shown above is likely either impractical or impossible, if the user also wants to run a standard DOS program as well.

Most users used the accompanying EMM386 driver provided in MS-DOS 5, but third-party products from companies such as QEMM also proved popular.

CONFIG.SYS, loading ANSI.SYS into UMBs, no EMS support enabled: AUTOEXEC.BAT, loading MOUSE, DOSKEY, and SMARTDRV into UMBs if possible: The ability of DOS versions 5.0 and later to move their own system core code into the high memory area (HMA) through the DOS=HIGH command gave another boost to free memory.

An unusual aspect of drivers and TSRs is that they would use different amounts of conventional and/or upper memory, based on the order they were loaded.

Later versions of DOS allowed the use of a specific load address for a driver or TSR, to fit drivers/TSRs more tightly together.

For example, the functions of mouse driver, CD-ROM driver, ANSI support, DOSKEY command recall, and disk caching would all be combined together in one program, consuming just 1 – 2 kilobytes of conventional memory for normal driver/interrupt access, and storing the rest of the multi-function program code in EMS or XMS memory.

With a 32-bit DOS extender, a game could benefit from a 32-bit flat address space and the full 32-bit instruction set without the 66h/67h operand/address override prefixes.

This allowed 16-bit real-mode DOS programs to access several megabytes of RAM through a hole in real memory, typically (0xE000–0xEFFF).

Memory areas of the IBM PC family