Conventional memory

Last updated

Memory areas of the IBM PC family IBM PC Memory areas.svg
Memory areas of the IBM PC family

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.

Contents

640 KB barrier

IBM PC, PC/XT, 3270 PC and PCjr memory blocks [1] [2]
0-block1st 64 KBOrdinary user memory to 64 KB (low memory area)
1-block2nd 64 KBOrdinary user memory to 128 KB
2-block3rd 64 KBOrdinary user memory to 192 KB
3-block4th 64 KBOrdinary user memory to 256 KB
4-block5th 64 KBOrdinary user memory to 320 KB
5-block6th 64 KBOrdinary user memory to 384 KB
6-block7th 64 KBOrdinary user memory to 448 KB
7-block8th 64 KBOrdinary user memory to 512 KB
8-block9th 64 KBOrdinary user memory to 576 KB
9-block10th 64 KBOrdinary user memory to 640 KB
A-block11th 64 KBExtended video memory (EGA)
B-block12th 64 KBStandard video memory (MDA/CGA)
C-block13th 64 KBROM expansion (XT, EGA, 3270 PC)
D-block14th 64 KBother use (PCjr cartridges, LIM EMS)
E-block15th 64 KBother use (PCjr cartridges, LIM EMS)
F-block16th 64 KBSystem 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 (220 bytes), 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 (64 KB) 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 (UMA), 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 (CGA) 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" (or several holes) 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 (UMBs).

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. [3] [4] This however is invisible to programs (or even most of the operating system) on newer operating systems (such as Windows, Linux, or Mac OS X) 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. [5]

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 (PCI memory space) 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 (MDA). Sometimes software or a custom address decoder was required for this to work. This moved the barrier to 704 KB (with MDA/HGC) or 736 KB (with CGA). [6] [7]

Memory managers on 386-based systems (such as QEMM or MEMMAX (+V) in DR-DOS) could achieve the same effect, adding conventional memory at 640 KB and moving the barrier to 704 KB (up to segment B000, the start of MDA/HGC) or 736 KB (up to segment B800, the start of the CGA). [7] Only CGA could be used in this situation, because Enhanced Graphics Adapter (EGA) 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- [8] [9] and Chargecard [10] for 286/386SX-class computers, as well as MicroWay's ECM (Extended Conventional Memory) add-on-board [11] allowed normal memory to be mapped into the A0000–EFFFF (hex) 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. [10]

It was also possible to use console redirection [12] (either by specifying an alternative console device like AUX: when initially invoking COMMAND.COM or by using CTTY later on) 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 (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.

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 (TSRs) 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:

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 (UMBs) in the upper memory area (UMA) 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 EMM386 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 (HMA) through the DOS=HIGH command gave another boost to free memory.

Driver and TSR optimization

Hardware expansion boards could use any of the upper memory area for ROM addressing, so the upper memory blocks were of variable size and in different locations for each computer, depending on the hardware installed. Some windows of upper memory could be large and others small. Loading drivers and TSRs high would pick a block and try to fit the program into it, until a block was found where it fit, or it would go into conventional 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. This could be used to advantage if the programs were repeatedly loaded in different orders, and checking to see how much memory was free after each permutation. For example, if there was a 50 KB UMB and a 10 KB UMB, and programs needing 8 KB and 45 KB were loaded, the 8 KB might go into the 50 KB UMB, preventing the second from loading. Later versions of DOS allowed the use of a specific load address for a driver or TSR, to fit drivers/TSRs more tightly together.

In MS-DOS 6.0, Microsoft introduced MEMMAKER , which automated this process of block matching, matching the functionality third-party memory managers offered. This automatic optimization often still did not provide the same result as doing it by hand, in the sense of providing the greatest free conventional memory.

Also in some cases third-party companies wrote special multi-function drivers that would combine the capabilities of several standard DOS drivers and TSRs into a single very compact program that used just a few kilobytes of memory. 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.

DOS extenders

The barrier was only overcome with the arrival of DOS extenders, which allowed DOS applications to run in 16-bit or 32-bit protected mode, but these were not very widely used outside of computer gaming. 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. 32-bit DOS extenders required compiler support (32-bit compilers) while XMS and EMS worked with an old compiler targeting 16-bit real-mode DOS applications. The two most common specifications for DOS extenders were VCPI- and later DPMI-compatible with Windows 3.x.

The most notable DPMI-compliant DOS extender may be DOS/4GW, shipping with Watcom. It was very common in games for DOS. Such a game would consist of either a DOS/4GW 32-bit kernel, or a stub which loaded a DOS/4GW kernel located in the path or in the same directory and a 32-bit "linear executable". Utilities are available which can strip DOS/4GW out of such a program and allow the user to experiment with any of the several, and perhaps improved, DOS/4GW clones.

Prior to DOS extenders, if a user installed additional memory and wished to use it under DOS, they would first have to install and configure drivers to support either expanded memory specification (EMS) or extended memory specification (XMS) and run programs supporting one of these specifications.

EMS was a specification available on all PCs, including those based on the Intel 8086 and Intel 8088, which allowed add-on hardware to page small chunks of memory in and out (bank switching) of the "real mode" addressing space (0x0400–0xFFFF). This allowed 16-bit real-mode DOS programs to access several megabytes of RAM through a hole in real memory, typically (0xE000–0xEFFF). A program would then have to explicitly request the page to be accessed before using it. These memory locations could then be used arbitrarily until replaced by another page. This is very similar to modern paged virtual memory. However, in a virtual memory system, the operating system handles all paging operations, while paging was explicit with EMS.

XMS provided a basic protocol which allowed a 16-bit DOS programs to load chunks of 80286 or 80386 extended memory in low memory (address 0x0400–0xFFFF). A typical XMS driver had to switch to protected mode in order to load this memory. The problem with this approach is that while in 286 protected mode, direct DOS calls could not be made. The workaround was to implement a callback mechanism, requiring a reset of the 286. On the 286, this was a major problem. The Intel 80386, which introduced "virtual 8086 mode", allowed the guest kernel to emulate the 8086 and run the host operating system without having to actually force the processor back into "real mode". HIMEM.SYS 2.03 and higher used unreal mode on the 80386 and higher CPUs while HIMEM.SYS 2.06 and higher used LOADALL to change undocumented internal registers on the 80286, significantly improving interrupt latency by avoiding repeated real mode/protected mode switches. [14]

Windows installs its own version of HIMEM.SYS [15] on DOS 3.3 and higher. Windows HIMEM.SYS launches 32-bit protected mode XMS (n).0 services provider for the Windows Virtual Machine Manager, which then provides XMS (n-1).0 services to DOS boxes and the 16-bit Windows machine (e.g. DOS 7 HIMEM.SYS is XMS 3.0 but running 'MEM' command in a Windows 95 DOS window shows XMS 2.0 information).

See also

Related Research Articles

<span class="mw-page-title-main">Intel 8086</span> 16-bit microprocessor

The 8086 is a 16-bit microprocessor chip designed by Intel between early 1976 and June 8, 1978, when it was released. The Intel 8088, released July 1, 1979, is a slightly modified chip with an external 8-bit data bus, and is notable as the processor used in the original IBM PC design.

A terminate-and-stay-resident program is a computer program running under DOS that uses a system call to return control to DOS as though it has finished, but remains in computer memory so it can be reactivated later. This technique partially overcame DOS's limitation of executing only one program, or task, at a time. TSRs are used only in DOS, not in Windows.

Real mode, also called real address mode, is an operating mode of all x86-compatible CPUs. The mode gets its name from the fact that addresses in real mode always correspond to real locations in memory. Real mode is characterized by a 20-bit segmented memory address space and unlimited direct software access to all addressable memory, I/O addresses and peripheral hardware. Real mode provides no support for memory protection, multitasking, or code privilege levels.

<span class="mw-page-title-main">A20 line</span> Signal in the system bus of an x86-based computer system

The A20, or address line 20, is one of the electrical lines that make up the system bus of an x86-based computer system. The A20 line in particular is used to transmit the 21st bit on the address bus.

<span class="mw-page-title-main">DESQview</span> Text mode multitasking operating environment

DESQview (DV) is a text mode multitasking operating environment developed by Quarterdeck Office Systems which enjoyed modest popularity in the late 1980s and early 1990s. Running on top of DOS, it allows users to run multiple programs concurrently in multiple windows.

<span class="mw-page-title-main">DOS memory management</span> Techniques employed to give applications access to more than 640 kibibytes

In IBM PC compatible computing, DOS memory management refers to software and techniques employed to give applications access to more than 640 kibibytes (KiB) of "conventional memory". The 640 KiB limit was specific to the IBM PC and close compatibles; other machines running MS-DOS had different limits, for example the Apricot PC could have up to 768 KiB and the Sirius Victor 9000, 896 KiB. Memory management on the IBM family was made complex by the need to maintain backward compatibility to the original PC design and real-mode DOS, while allowing computer users to take advantage of large amounts of low-cost memory and new generations of processors. Since DOS has given way to Microsoft Windows and other 32-bit operating systems not restricted by the original arbitrary 640 KiB limit of the IBM PC, managing the memory of a personal computer no longer requires the user to manually manipulate internal settings and parameters of the system.

<span class="mw-page-title-main">Extended memory</span>

In DOS memory management, extended memory refers to memory above the first megabyte (220 bytes) of address space in an IBM PC or compatible with an 80286 or later processor. The term is mainly used under the DOS and Windows operating systems. DOS programs, running in real mode or virtual x86 mode, cannot directly access this memory, but are able to do so through an application programming interface called the Extended Memory Specification (XMS). This API is implemented by a driver (such as HIMEM.SYS) or the operating system, which takes care of memory management and copying memory between conventional and extended memory, by temporarily switching the processor into protected mode. In this context, the term "extended memory" may refer to either the whole of the extended memory or only the portion available through this API.

<span class="mw-page-title-main">Expanded memory</span> System of bank switching in DOS memory management

In DOS memory management, expanded memory is a system of bank switching that provided additional memory to DOS programs beyond the limit of conventional memory (640 KiB).

<span class="mw-page-title-main">High memory area</span>

In DOS memory management, the high memory area (HMA) is the RAM area consisting of the first 65520 bytes above the one megabyte in an IBM AT or compatible computer.

Quarterdeck Expanded Memory Manager (QEMM) is a memory manager produced by Quarterdeck Office Systems in the late 1980s through the late 1990s. It was the most popular third-party memory manager for the MS-DOS and other DOS operating systems.

In x86 computing, unreal mode, also big real mode, flat real mode, or voodoo mode is a variant of real mode, in which one or more segment descriptors has been loaded with non-standard values, like 32-bit limits allowing access to the entire memory. Contrary to its name, it is not a separate addressing mode that the x86 processors can operate in. It is used in the 80286 and later x86 processors.

EMM386 is the expanded memory manager of Microsoft's MS-DOS, IBM's PC DOS, Digital Research's DR-DOS, and Datalight's ROM-DOS which is used to create expanded memory using extended memory on Intel 80386 CPUs. There also is an EMM386.EXE available in FreeDOS.

LOADALL is the common name for two different, undocumented machine instructions of Intel 80286 and Intel 80386 processors, which allow access to areas of the internal processor state that are normally outside of the IA-32 API scope, like descriptor cache registers. The LOADALL for 286 processors is encoded 0Fh 05h, while the LOADALL for 386 processors is 0Fh 07h.

<span class="mw-page-title-main">Upper memory area</span> Physical memory region on IBM PC compatibles

In DOS memory management, the upper memory area (UMA) is the memory between the addresses of 640 KB and 1024 KB (0xA0000–0xFFFFF) in an IBM PC or compatible. IBM reserved the uppermost 384 KB of the 8088 CPU's 1024 KB address space for BIOS ROM, Video BIOS, Option ROMs, video RAM, memory-mapped I/O, and obsoleted ROM BASIC.

HIMEM.SYS is a DOS device driver which allows DOS programs to store data in extended memory according to the Extended Memory Specification (XMS). The memory beyond the first 1 MB of address space is required by Windows 9x/Me in order to load; therefore, these versions of Microsoft Windows require HIMEM.SYS to be loaded to be able to run.

In computing, LOADHIGH is an internal DOS command in COMMAND.COM that is used to load a program into the upper memory area (UMA) instead of conventional memory.

<span class="mw-page-title-main">DOS</span> Family of IBM PC-compatible operating systems

DOS is a family of disk-based operating systems for IBM PC compatible computers. The DOS family primarily consists of IBM PC DOS and a rebranded version, Microsoft's MS-DOS, both of which were introduced in 1981. Later compatible systems from other manufacturers include DR-DOS (1988), ROM-DOS (1989), PTS-DOS (1993), and FreeDOS (1998). MS-DOS dominated the IBM PC compatible market between 1981 and 1995.

The maximum random access memory (RAM) installed in any computer system is limited by hardware, software and economic factors. The hardware may have a limited number of address bus bits, limited by the processor package or design of the system. Some of the address space may be shared between RAM, peripherals, and read-only memory. In the case of a microcontroller with no external RAM, the size of the RAM array is limited by the size of the integrated circuit die. In a packaged system, only enough RAM may be provided for the system's required functions, with no provision for addition of memory after manufacture.

DOS Protected Mode Services (DPMS) is a set of extended DOS memory management services to allow DPMS-enabled DOS drivers to load and execute in extended memory and protected mode.

References

  1. Norton, Peter (1986). Inside the IBM PC, Revised and Enlarged, Brady. ISBN   0-89303-583-1, p. 108.
  2. U.S. patent 4,926,322 - Software emulation of bank-switched memory using a virtual DOS monitor and paged memory management, Fig. 1
  3. Yao, Jiewen; Zimmer, Vincent J. (February 2015). "White Paper: A Tour beyond BIOS Memory Map Design in UEFI BIOS" (PDF). Intel Corporation. Archived from the original (PDF) on 2015-09-30. Retrieved 2016-08-25.
  4. Russinovich, Mark Eugene; Solomon, David A.; Ionescu, Alex (2012). Windows Internals. Vol. Part 2 (6th ed.). Microsoft Press. p. 322. Note the gap in the memory address range from page 9F000 to page 100000...
  5. Richter, Jeffrey. Programming Applications for Microsoft Windows. pp. 435 ff.
  6. Atkinson, Cy (2001). "What is High Memory, why do i care, and how can I use it?". San Jose, CA, USA. Archived from the original on 2016-03-03. Retrieved 2017-03-13.
  7. 1 2 Paul, Matthias R. (1997-07-30). NWDOS-TIPs — Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds [NWDOSTIPs — Tips & tricks for Novell DOS 7, with special focus on undocumented details, bugs and workarounds]. MPDOSTIP (in German) (3 ed.). Archived from the original on 2016-06-06. Retrieved 2016-06-06. (NB. NWDOSTIP.TXT is a comprehensive work on Novell DOS 7 and OpenDOS 7.01, including the description of many undocumented features and internals. It is part of the author's yet larger MPDOSTIP.ZIP collection maintained up to 2001 and distributed on many sites at the time. The provided link points to a HTML-converted older version of the NWDOSTIP.TXT file.)
  8. Petzold, Charles (1986). "More Options For Enlarging the Dimensions of Memory". PC Magazine . Vol. 5, no. 11. ISSN   0888-8507.
  9. "AllCard review". Personal Computer World . September 1986. p. 138.
  10. 1 2 Zerbe, Klaus (November 1987). Burgwitz, Andreas (ed.). "Speicher-Kredit - All Chargecard für ATs". c't - magazin für computertechnik . Prüfstand (in German). Vol. 1987, no. 11. Verlag Heinz Heise GmbH & Co. KG. pp. 58, 60. ISSN   0724-8679.
  11. Petzold, Charles (1986-09-16). "Number Smasher/ECM". PC Magazine . Accelerator Boards. Vol. 5, no. 15. pp. 148, 150. ISSN   0888-8507. Archived from the original on 2020-03-03. Retrieved 2020-03-03.
  12. Kontron User's Guide - COMe-cBTi6R. Document Revision 1.0. Kontron. 2021. pp. 37, 60, 64. Archived from the original on 2023-09-23. Retrieved 2023-09-23. (89 pages)
  13. Paterson, Tim (2007-11-24). "The First DOS Machine". DosMan Drivel. Archived from the original on 2021-09-18. Retrieved 2021-12-23. IBM also reintroduced memory limitations that I had specifically avoided in designing the 8086 CPU [card]. For S-100 computers, a low-cost alternative to using a regular computer terminal was to use a video card. The video card, however, used up some of the memory address space. The boot ROM would normally use up address space as well. SCP systems were designed to be used with a terminal, and the boot ROM could be disabled after boot-up. This made the entire 1 MB of memory address space available for RAM. IBM, on the other hand, had limited the address space in their PC to 640 KB of RAM due to video and boot/BIOS ROM. This limitation has been called the "DOS 640K barrier", but it had nothing to do with DOS. Microsoft took full advantage of the SCP system capability. In 1988, years after SCP had shut down, they were still using the SCP system for one task only it could perform ("linking the linker"). Their machine was equipped with the full 1 MB of RAM – 16 of the 64 KB cards. That machine could not be retired until 32-bit software tools were developed for Intel's 386 microprocessor.
  14. "HIMEM.SYS, unreal mode, and LOADALL | OS/2 Museum".
  15. "Overview of Memory-Management Functionality in MS-DOS". Support.microsoft.com. 2003-05-12. Retrieved 2012-08-13.

Further reading