Conventional memory

In DOS memory management, conventional memory, also called base memory, is the first 640 kilobytes of the memory on IBM PC or compatible systems. It is the read-write memory directly addressable by the processor for use by the operating system and application programs. As memory prices rapidly declined, this design decision became a limitation in the use of large memory capacities until the introduction of operating systems and processors that made it irrelevant.

640 KB barrier

0-block	1st 64 KB	Ordinary user memory to 64 KB
1-block	2nd 64 KB	Ordinary user memory to 128 KB
2-block	3rd 64 KB	Ordinary user memory to 192 KB
3-block	4th 64 KB	Ordinary user memory to 256 KB
4-block	5th 64 KB	Ordinary user memory to 320 KB
5-block	6th 64 KB	Ordinary user memory to 384 KB
6-block	7th 64 KB	Ordinary user memory to 448 KB
7-block	8th 64 KB	Ordinary user memory to 512 KB
8-block	9th 64 KB	Ordinary user memory to 576 KB
9-block	10th 64 KB	Ordinary user memory to 640 KB
A-block	11th 64 KB	Extended video memory
B-block	12th 64 KB	Standard video memory
C-block	13th 64 KB	ROM expansion
D-block	14th 64 KB	other use
E-block	15th 64 KB	other use
F-block	16th 64 KB	System ROM-BIOS and ROM-BASIC

The 640 KB barrier is an architectural limitation of IBM PC compatible PCs. The Intel 8088 CPU, used in the original IBM PC, was able to address 1 MB, since the chip offered 20 address lines. In the design of the PC, the memory below 640 KB was for random-access memory on the motherboard or on expansion boards, and it was called the conventional memory area. The first memory segment of the conventional memory area is named lower memory or low memory area. The remaining 384 KB beyond the conventional memory area, called the upper memory area, was reserved for system use and optional devices. UMA was used for the ROM BIOS, additional read-only memory, BIOS extensions for fixed disk drives and video adapters, video adapter memory, and other memory-mapped input and output devices. The design of the original IBM PC placed the Color Graphics Adapter memory map in UMA.
The need for more RAM grew faster than the needs of hardware to utilize the reserved addresses, which resulted in RAM eventually being mapped into these unused upper areas to utilize all available addressable space. This introduced a reserved "hole" into the set of addresses occupied by hardware that could be used for arbitrary data. Avoiding such a hole was difficult and ugly and not supported by DOS or most programs that could run on it. Later, space between the holes would be used as upper memory blocks.
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. The 1 MB barrier also remained as long as the 286 was running in real mode, since DOS required real mode which uses the segment and offset registers in an overlapped manner such that addresses with more than 20 bits are not possible. It is still present in IBM PC compatibles today if they are running in real mode such as used by DOS. Even the most modern Intel PCs still have the area between 640 and 1024 KB reserved. This however is invisible to programs on newer operating systems that use virtual memory, because they have no awareness of physical memory addresses at all. Instead they operate within a virtual address space, which is defined independently of available RAM addresses.
Some motherboards feature a "Memory Hole at 15 Megabytes" option required for certain VGA video cards that require exclusive access to one particular megabyte for video memory. Later video cards using the AGP bus can have 256 MB memory with 1 GB aperture size.

Additional memory

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. Sometimes software or a custom address decoder was required for this to work. This moved the barrier to 704 KB or 736 KB.
Memory managers on 386-based systems could achieve the same effect, adding conventional memory at 640 KB and moving the barrier to 704 KB or 736 KB. Only CGA could be used in this situation, because Enhanced Graphics Adapter video memory was immediately adjacent to the conventional memory area below the 640 KB line; the same memory area could not be used both for the frame buffer of the video card and for transient programs.
All Computers' piggy-back add-on memory management units AllCard for XT- and Chargecard for 286/386SX-class computers, as well as MicroWay's ECM add-on-board allowed normal memory to be mapped into the A0000–EFFFF address range, giving up to 952 KB for DOS programs. Programs such as Lotus 1-2-3, which accessed video memory directly, needed to be patched to handle this memory layout. Therefore, the 640 KB barrier was removed at the cost of hardware compatibility.
It was also possible to use console redirection to direct output to and receive input from a dumb terminal or another computer running a terminal emulator. Assuming the System BIOS still permitted the machine to boot, 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 for a total of up to 1024 KB, 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.

DOS driver software and TSRs

Most standard programs written for DOS did not necessarily need 640 KB or more of memory. Instead, driver software and utilities referred to as terminate-and-stay-resident programs could be used in addition to the standard DOS software. These drivers and utilities typically used some conventional memory permanently, reducing the total available for standard DOS programs.
Some very common DOS drivers and TSRs using conventional memory included:

ANSI.SYS - support for color text and different text resolutions
ASPIxDOS.SYS, ASPIDISK.SYS, ASPICD.SYS - all must be loaded for Adaptec SCSI drives and CDROMs to work
DOSKEY.EXE - permits recall of previously typed DOS commands using up-arrow
LSL.EXE, E100BODI.EXE, IPXODI.EXE, NETX.EXE - all must be loaded for NetWare file server drive letter access
MOUSE.EXE - support for mouse devices in DOS programs
MSCDEX.EXE - support for CDROM drive access and drive letter, used in combination with a separate manufacturer-specific driver. Needed in addition to above SCSI drivers for access to a SCSI CDROM device.
SBCONFIG.EXE - support for Sound Blaster 16 audio device; a differently-named driver was used for various other sound cards, also occupying conventional memory.
SMARTDRV.EXE - install drive cache to speed up disk reads and writes; although it could allocate several megabytes of memory beyond 640 KB for the drive caching, it still needed a small portion of conventional memory to function.

As can be seen above, many of these drivers and TSRs could be considered practically essential to the full-featured operation of the system. 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.
In some cases drivers or TSRs would have to be unloaded from memory to run certain programs, and then reloaded after running the program. For drivers that could not be unloaded, later versions of DOS included a startup menu capability to allow the computer user to select various groups of drivers and TSRs to load before running certain high-memory-usage standard DOS programs.

Upper memory blocks and loading high

As DOS applications grew larger and more complex in the late 1980s and early 1990s, it became common practice to free up conventional memory by moving the device drivers and TSR programs into upper memory blocks in the upper memory area at boot, in order to maximize the conventional memory available for applications. This had the advantage of not requiring hardware changes, and preserved application compatibility.
This feature was first provided by third-party products such as QEMM, before being built into DR DOS 5.0 in 1990 then MS-DOS 5.0 in 1991. Most users used the accompanying driver provided in MS-DOS 5, but third-party products from companies such as QEMM also proved popular.
At startup, drivers could be loaded high using the "DEVICEHIGH=" directive, while TSRs could be loaded high using the "LOADHIGH", "LH" or "HILOAD" directives. If the operation failed, the driver or TSR would automatically load into the regular conventional memory instead.
CONFIG.SYS, loading ANSI.SYS into UMBs, no EMS support enabled:
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE NOEMS
DEVICEHIGH=C:\DOS\ANSI.SYS
AUTOEXEC.BAT, loading MOUSE, DOSKEY, and SMARTDRV into UMBs if possible:
LH C:\DOS\MOUSE.EXE
LH C:\DOS\DOSKEY.EXE
LH C:\DOS\SMARTDRV.EXE
The ability of DOS versions 5.0 and later to move their own system core code into the high memory area through the DOS=HIGH command gave another boost to free memory.