The Upper Memory Area (UMA) is a design feature of IBM PC-compatible x86 computers that was responsible for the 640 KiB barrier.
Contents |
Reserved memory space
IBM reserved the uppermost region of the PC memory map for ROM, RAM on peripherals and memory-mapped input/output (I/O, also MMIO). This region is called the UMA and lies above conventional memory, between 640 KiB and the 1 MiB maximum addressable limit of the original PC's 8088 CPU. For example, the monochrome video memory area runs from 0xB000 to 0xB7FF. However, even with video RAM, the ROM BIOS and I/O ports for expansion cards, much of this 384 KiB of address space was unused - even when a 64 KiB window was reserved for the expanded memory "frame" address into which EMS RAM was bank-switched.
Usage in DR-DOS
The next stage in the evolution of DOS was for the OS itself to become aware of UMBs and the High Memory Area. This occurred with the release of DR-DOS 5.0 in 1990. DR-DOS' built-in memory manager, EMM386.EXE, could perform most of the basic functionality of QEMM and comparable programs. Where DR-DOS scored over the combination of an older DOS plus QEMM was that the DR-DOS kernel itself and almost all of its data structures could be loaded into high memory, plus all of its associated components into UMBs. This left virtually all the base memory free, allowing configurations with up to 620 KiB out of 640 KiB free. Configuration was not automatic - free UMBs had to be identified by hand, manually included in the line that loaded EMM386 from CONFIG.SYS, and then drivers and so on had to be manually loaded into UMBs from CONFIG.SYS and AUTOEXEC.BAT. This configuration was not a trivial process. As it was largely automated by the installation program of QEMM, this program survived on the market; indeed, it worked well with DR-DOS' own HMA and UMB support and went on to be one of the best-selling utilities for the PC.
Usage in MS DOS
This functionality was copied by Microsoft with the release of MS-DOS 5.0 in June 1991. Eventually, even more DOS data structures were moved out of conventional memory, allowing up to 631 KiB out of 640 KiB to be left free. For a period in the early 1990s, manual optimisation of the DOS memory map became a highly-prized skill, allowing for the largest applications to run on even the most complex PC configurations. The technique was to first create as many UMBs as possible, including remapping allocated but unnecessary blocks of memory, such as the monochrome display area on colour machines. Then, DOS' many subcomponents had to be loaded into these UMBs in just the correct sequence, as to use the blocks of memory as efficiently as possible, allowing for the fact that some TSR programs required additional memory while loading, which was freed up again once loading was complete. Fortunately there were few dependencies amongst these modules, so it was possible to load them in almost any sequence. Exceptions were that to successfully cache CD-ROMs, most disk caches had to be loaded after any CD-ROM drivers, and that the modules of most network stacks had to be loaded in a certain sequence, essentially working progressively up through the layers of the OSI model.
Usage with multitasking
With the addition of a DOS multitasker such as Quarterdeck's DESQview, multiple sessions could be started at once, each with 600-odd K of free memory and all sharing access to DOS and its associated drivers and facilities.
Usage in Windows
The increasing popularity of Windows 3.0 made this less relevant, as Windows applications were not affected by DOS' base memory limits, but DOS programs running under Windows (with Windows itself acting as a multitasking manager) were still thus constrained. With the release of Windows 95, it became less relevant still, as this version of Windows provides much of the functionality of the DOS device drivers to DOS applications running under Windows, such as CD, network and sound support; the memory map of Win95 DOS boxes was automatically optimised. However, not all DOS programs could execute in this environment. Specifically, programs that tried to directly switch from real mode to protected mode, wouldn't work as this wasn't allowed in the virtual 8086 mode it was running in (actually, this point is now being addressed by upcoming virtualization technologies such as Vanderpool and Pacifica for the x86 CPUs). Also, programs that tried making the switch using VCPI API (which was introduced to allow DOS programs that needed protected mode to enter it from the virtual 8086 mode set up by a memory manager, as described above) didn't work in Windows 95. Only the DPMI API for switching to protected mode was supported.
Upper Memory and shadow RAM
On many systems including modern ones it is possible to use memory reserved for shadowing expansion card ROM as upper memory. Many chipsets reserve up to 384 KiB RAM for this purpose and since this RAM is generally unused it may be used as real mode upper memory with a custom device driver.
Upper Memory on the IBM XT
On IBM XT computers, it was possible to add more memory to the motherboard and use a custom address decoder PROM to make it appear in the upper memory area [1]. As with the 386-based upper memory described above, the extra RAM could be used to load TSR files, or as a RAM disk.
x86 PC systems lacking an UMA
The existence of the Upper Memory Area and thus the 640 KiB barrier are artifacts of the design of the IBM PC and thus any computer compatible with it - in other words, all IBM PC Compatible systems. However, there have been many other computers based on Intel or other x86 processors which were not compatible with the PC and thus did not have an upper memory area and no 640 KiB barrier.
