Community hub
Recent from talks
Contribute something
Nothing was collected or created yet.
Expanded memory
View on Wikipedia
 | This article needs additional citations for verification. (October 2025) |
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).
Expanded memory is an umbrella term for several incompatible technology variants. The most widely used variant was the Expanded Memory Specification (EMS), which was developed jointly by Lotus Software, Intel, and Microsoft, so that this specification was sometimes referred to as "LIM EMS". LIM EMS had three versions: 3.0, 3.2, and 4.0. The first widely implemented version was EMS 3.2, which supported up to 8 MiB of expanded memory and uses parts of the address space normally dedicated to communication with peripherals (upper memory) to map portions of the expanded memory. EEMS, an expanded-memory management standard competing with LIM EMS 3.x, was developed by AST Research, Quadram and Ashton-Tate ("AQA"); it could map any area of the lower 1 MiB. EEMS ultimately was incorporated in LIM EMS 4.0, which supported up to 32 MiB of expanded memory and provided some support for DOS multitasking as well. IBM, however, created its own expanded-memory standard called XMA.
The use of expanded memory became common with games and business programs such as Lotus 1-2-3 in the late 1980s through the mid-1990s, but its use declined as users switched from DOS to protected-mode operating systems such as Linux, IBM OS/2, and Microsoft Windows.
Background
[edit]
The 8088 processor of the IBM PC and IBM PC/XT can address one megabyte (MiB, or 220 bytes) of memory. It inherited this limit from the 20-bit external address bus (and overall memory addressing architecture) of the Intel 8086. The designers of the PC allocated the lower 640 KiB (655360 bytes) of address space for read-write program memory (RAM), called conventional memory, and the remaining 384 KiB of memory space is reserved for uses such as the system BIOS, video memory, and memory on expansion peripheral boards.
Even though the IBM PC AT, introduced in 1984, uses the 80286 chip that can address up to 16 MiB of RAM as extended memory, it can only do so in protected mode. The scarcity of software compatible with protected mode (no standard DOS applications can run in it) meant that the market was still open for another solution.[1]
To make more memory accessible, a bank switching scheme was devised, where only selected parts of the additional memory is accessible at any given time. Originally, a single 64 KiB (216 bytes) window of memory, called a page frame, was used; later this was made more flexible. Programs are written in a specific way to access expanded memory. The window between conventional memory and expanded memory can be adjusted to access different locations within the expanded memory.
A first attempt to use a bank switching technique was made by Tall Tree Systems with its JRAM boards,[2] but these did not catch on.[1] (Tall Tree Systems later made EMS-based boards using the same JRAM brand.)
Expanded Memory Specification (EMS)
[edit]Lotus Development, Intel, and Microsoft cooperated to develop the EMS standard (aka LIM EMS). The first publicly available version of EMS, version 3.0 allows access of up to 4 MiB of expanded memory.[citation needed] This was increased to 8 MiB with version 3.2 of the specification. The final version of EMS, version 4.0 increased the maximum amount of expanded memory to 32 MiB and supports additional functionality.
Microsoft thought that bank switching was an inelegant and temporary, but necessary stopgap measure. Slamming his fist on the table during an interview Bill Gates said of expanded memory, "It's garbage! It's a kludge! … But we're going to do it". The companies planned to launch the standard at the Spring 1985 COMDEX, with many expansion-card and software companies announcing their support.[3][4] AST Research, STB Systems, Persyst, Quadram, and Tecmar quickly designed EMS-compliant cards to compete with Intel's own Above Board expansion card. By mid-1985 some already called EMS a de facto standard.[5]
The first public version of the EMS standard, called EMS 3.0 was released in 1985; EMS 3.0, however, saw almost no hardware implementations before being superseded by EMS 3.2. EMS 3.2 uses a 64 KiB region in the upper 384 KiB (upper memory area) divided into four 16 KiB pages, which can be used to map portions of the expanded memory.[1]
Quadram, AST, and Ashton-Tate created the Enhanced EMS (EEMS) standard. EEMS, a superset of EMS 3.2, allows any 16 KiB region in lower RAM to be mapped to expanded memory, as long as it was not associated with interrupts or dedicated I/O memory such as network or video cards. Thus, entire programs can be switched in and out of the extra RAM. EEMS also added support for two sets of mapping registers. These features are used by early DOS multitasker software such as DESQview. 1987's LIM EMS 4.0 specification incorporated practically all features of EEMS.[1]
A new feature added in LIM EMS 4.0 was that EMS boards can have multiple sets of page-mapping registers (up to 64 sets). This allows a primitive form of DOS multitasking. The caveat is, however, that the standard does not specify how many register sets a board should have, so there is great variability between hardware implementations in this respect.[6]
The Expanded Memory Specification (EMS) is the specification describing the use of expanded memory. EMS functions are accessible through software interrupt 67h. Programs using EMS must first establish the presence of an installed expanded memory manager (EMM) by checking for a device driver with the device name EMMXXXX0.
Expanded Memory Adapter (XMA)
[edit]IBM remained silent as the industry widely adopted the LIM standard.[5] The company developed its own memory standard called Expanded Memory Adapter (XMA); the IBM DOS driver for it is XMAEM.SYS. Unlike EMS, the IBM expansion boards can be addressed both using an expanded memory model and as extended memory.[7] The expanded memory hardware interface used by XMA boards is, however, incompatible with EMS,[8] but a XMA2EMS.SYS driver provides EMS emulation for XMA boards.[7] XMA boards were first introduced for the 1986 (revamped) models of the 3270 PC.[8]
Implementations
[edit]Expansion boards
[edit]
This insertion of a memory window into the peripheral address space could originally be accomplished only through specific expansion boards, plugged into the ISA expansion bus of the computer. Famous 1980s expanded memory boards were AST RAMpage, IBM PS/2 80286 Memory Expansion Option, AT&T Expanded Memory Adapter and the Intel Above Board. Given the price of RAM during the period, up to several hundred dollars per MiB, and the quality and reputation of the above brand names, an expanded memory board was very expensive.
Motherboard chipsets
[edit]Later, some motherboard chipsets of Intel 80286-based computers implemented an expanded memory scheme that did not require add-on boards, notably the NEAT chipset. Typically, software switches determined how much memory should be used as expanded memory and how much should be used as extended memory.
Device drivers
[edit]An expanded-memory board, being a hardware peripheral, needed a software device driver, which exported its services. Such a device driver was called expanded-memory manager. Its name was variable; the previously mentioned boards used REMM.SYS (AST), PS2EMM.SYS (IBM), AEMM.SYS (AT&T) and EMM.SYS (Intel) respectively. Later, the expression became associated with software-only solutions requiring the Intel 80386 processor, for example Quarterdeck's QEMM, Qualitas' 386MAX or the default EMM386 in MS-DOS, PC DOS and DR-DOS.
Software emulation
[edit]Beginning in 1986, the built-in memory management features of Intel 80386 processor freely modeled the address space when running legacy real-mode software, making hardware solutions unnecessary. Expanded memory could be simulated in software.
The first software expanded-memory management (emulation) program was CEMM, available in September 1986 as a utility for the Compaq Deskpro 386. A popular and well-featured commercial solution was Quarterdeck's QEMM. A contender was Qualitas' 386MAX. Functionality was later incorporated into MS-DOS 4.01 in 1989 and into DR DOS 5.0 in 1990, as EMM386.
Software expanded-memory managers in general offered additional, but closely related functionality. Notably, they allowed using parts of the upper memory area (UMA) (the upper 384 KiB of real-mode address space) called upper memory blocks (UMBs) and provided tools for loading small programs, typically terminate-and-stay-resident programs inside ("LOADHI" or "LOADHIGH").
Interaction between extended memory, expanded-memory emulation and DOS extenders ended up being regulated by the XMS, Virtual Control Program Interface (VCPI), DOS Protected Mode Interface (DPMI) and DOS Protected Mode Services (DPMS) specifications.
Certain emulation programs, colloquially known as LIMulators, did not rely on motherboard or 80386 features at all. Instead, they reserved 64 KiB of the base RAM for the expanded memory window, where they copied data to and from either extended memory or the hard disk when application programs requested page switches. This was programmatically easy to implement, but performance was low. This technique was offered by AboveDisk from Above Software and by several shareware programs.
It is also possible to emulate EMS by using XMS memory on 286 CPUs using 3rd party utilities like EMM286 (.SYS driver).
Decline
[edit]Expanded Memory usage declined in the 1990s. New operating systems like Linux, Windows 9x, Windows NT, OS/2, and BSD/OS supported protected mode "out of the box". These and similar developments rendered Expanded Memory an obsolete concept.
Similar concepts
[edit]Other platforms have implemented the same basic concept – additional memory outside of the main address space – but in technically incompatible ways:
- Expanded storage was a feature on IBM mainframes providing additional memory outside of the main system memory, first introduced with the IBM 3090 high-end mainframe series in 1985.[9] Expanded storage could not be directly addressed by applications; an MVS feature known as "window services" enabled applications to allocate movable windows to expanded storage within their own address space. There was also a "data mover" feature which could be invoked to move data between main memory (central storage) and expanded storage; later, an "Asynchronous Data Mover Facility" (ADMF) was introduced, which enabled applications to request data to be moved between the two in the background, while they performed other processing. By the mid-1990s, expanded storage had ceased to be a physically separate memory, and had become merely a logical division within the system memory enforced by firmware; but it was not until the November 2016 release of z/VM 6.4 that IBM finally removed all support for expanded storage from its mainframe operating systems.[10]
- Address Windowing Extensions (AWE) is a conceptually similar feature in Microsoft Windows, used to enable 32-bit applications to access more memory than the 2–4GB that can fit in a 32-bit address space. Although still supported by current versions of Windows, its use has been superseded by 64-bit applications, which can access >4GB of memory directly.
- Virtual memory creates the illusion of available memory using, for instance, disk storage.
See also
[edit]- Conventional memory
- DOS memory management
- Extended memory (XMS)
- High memory area (HMA)
- Overlay (programming)
- Upper memory area (UMA)
- Global EMM Import Specification (GEMMIS)
- x86 memory segmentation
- Address Windowing Extensions (AWE)
- Physical Address Extension (PAE)
- Sideways address space on the Acorn BBC Micro home computer
References
[edit]- ^ a b c d Mendelson, Edward (1989-12-12). "A Slot Full of RAM". PC Magazine. Vol. 8, no. 21. Ziff Davis Publishing Co. pp. 169–. Archived from the original on 2020-02-08. Retrieved 2020-02-08.
- ^ "Tall Tree Systems Product Datasheet" (Broschure). Tall Tree Systems. October 1983.
- ^ Machrone, Bill (1985-05-14). "Memory Scheme Breaks 640K". PC Magazine. Vol. 4, no. 10. Ziff Davis Publishing Co. p. 33. Retrieved 2013-10-28.
- ^ "The Most Memorable Tech Flops". PC Magazine. January 2008. pp. 88–89. Retrieved 2020-09-05.
- ^ a b Maremaa, Tom (1985-06-17). "Board Makers Flock to New Standard". InfoWorld. Vol. 7, no. 24. pp. 30–34. Retrieved 2025-05-01.
- ^ Rosch, Winn L. (1989-12-12). "EMS 4.0: The Standard That Wasn't". PC Magazine. Vol. 8, no. 21. Ziff Davis Publishing Co. pp. 174–175. Archived from the original on 2020-02-08. Retrieved 2020-02-08.
- ^ a b "A General Tutorial on the Various Forms of Memory". Microsoft. Archived from the original on 2012-10-22.
- ^ a b Welch, Marc J. (1986-04-14). "3270 Demand Not Expected To Rise". InfoWorld. Vol. 8, no. 15. InfoWorld Media Group, Inc. p. 5. ISSN 0199-6649. Archived from the original on 2020-02-08. Retrieved 2020-02-08.
- ^ Sakaki, M.; Samukawa, H.; Honjou, N. (1988). "Effective utilization of IBM 3090 large virtual storage in the numerically intensive computations of ab initio molecular orbitals". IBM Systems Journal. 27 (4): 528–540. doi:10.1147/sj.274.0528. ISSN 0018-8670.
- ^ "IBM: Configuring Storage". www.vm.ibm.com. 2006-08-29. Retrieved 2023-05-03.
Further reading
[edit]- "Expanded Memory Specification". Version 4.0. Lotus, Intel, Microsoft. October 1987. 300275-005. Archived from the original on 2020-02-08. Retrieved 2020-02-08.
- Tischer, Michael (1989). PC System Programming for Developers. Abacus. ISBN 1-55755-036-0.
- Borrett, Lloyd Robert (January–February 1989). "Understanding EMS 4.0". Technical Cornucopia. Archived from the original on 2020-02-08. Retrieved 2020-02-08.
Expanded memory
View on GrokipediaBackground
DOS Memory Architecture
The MS-DOS memory architecture was fundamentally shaped by the limitations of the Intel 8086 and 8088 processors, which operated in real mode and featured a 20-bit address bus capable of addressing up to 1 MB (1,048,576 bytes) of physical memory, from address 00000h to FFFFFh.[4] In this segmented addressing scheme, memory was divided into 64 KB segments, with effective addresses calculated as segment × 16 + offset, allowing access to the full 1 MB but constraining individual segments to 64 KB without explicit management.[4] This design, inherited from the original IBM PC in 1981, allocated the lower portion for general use while reserving the upper regions for essential hardware functions, creating inherent constraints for MS-DOS applications.[5] Conventional memory, also known as base memory, comprised the first 640 KB (addresses 00000h to 9FFFFh), which was the primary space available to MS-DOS programs and the operating system itself for loading executables, data, and runtime stacks.[6] This limit arose because the upper 384 KB (A0000h to FFFFFh) was reserved for hardware-specific purposes, preventing contiguous RAM allocation beyond 640 KB without specialized techniques.[5] The IBM PC Technical Reference specified that conventional memory could be expanded up to 640 KB on the system board and via expansion slots, but practical usability was dictated by these fixed reservations, which MS-DOS could not directly repurpose.[5] The upper memory area (UMA), spanning 640 KB to 1 MB, consisted of non-contiguous blocks dedicated to ROM firmware, adapter cards, and peripheral devices, further fragmenting the address space.[6] Key reservations included 128 KB for video RAM at A0000h–BFFFFh, used by display adapters such as the Color Graphics Adapter (CGA) for on-screen buffers in text or graphics modes.[5] Another 128 KB at C0000h–DFFFFh was allocated for adapter ROMs and expansion cards, like those for hard disks or network interfaces, while E0000h–EFFFFh (64 KB) accommodated optional ROM modules.[6] The highest block, F0000h–FFFFFh (64 KB), housed the system ROM containing the BIOS routines for I/O operations, power-on self-test, and the BASIC interpreter, with the final 16 bytes (FFFF0h–FFFFFh) reserved for the reset vector.[5]| Address Range | Size | Allocation |
|---|---|---|
| 00000h–9FFFFh | 640 KB | Conventional memory (RAM for programs and OS) |
| A0000h–BFFFFh | 128 KB | Video RAM (display adapters) |
| C0000h–DFFFFh | 128 KB | Adapter ROMs and expansion cards |
| E0000h–EFFFFh | 64 KB | Optional ROMs |
| F0000h–FFFFFh | 64 KB | System ROM (BIOS and BASIC) |
Origins of the EMS Standard
In the mid-1980s, the IBM PC and compatible systems running MS-DOS faced severe memory constraints, with conventional memory limited to 640 KB, which increasingly hampered the performance of sophisticated business applications. To address this growing bottleneck, Lotus Development Corporation, Intel Corporation, and Microsoft Corporation formed the Lotus-Intel-Microsoft (LIM) consortium in 1985. This collaboration aimed to establish a standardized method for accessing additional memory beyond the DOS limit, enabling software vendors to develop programs that could handle larger datasets without crashing or requiring cumbersome workarounds.[7][8] The catalyst for this initiative was the rapid evolution of productivity software, particularly spreadsheet programs like Lotus 1-2-3, whose second release in 1985 demanded more than 640 KB to manage expansive worksheets and complex calculations. Early proposals emerged from hardware innovations, such as Intel's Above Board expansion card introduced in 1985, which demonstrated the feasibility of bank-switched memory access but lacked a unified standard, leading to compatibility issues across vendors. The LIM group responded by releasing the initial Expanded Memory Specification (EMS) version 3.0 later that year, announced at the Spring 1985 COMDEX trade show by Lotus and Intel, providing a framework for up to 4 MB of expanded memory through a dedicated page frame in upper memory.[9][2][10] Software vendors played a pivotal role in driving the standard's adoption, particularly for memory-intensive applications. This consortium effort not only resolved immediate shortages for business tools but also laid the groundwork for broader memory management strategies in the PC ecosystem.[7]Technical Specifications
EMS Page Mapping System
The EMS page mapping system enables access to expanded memory beyond the 1 MB limit of DOS by dynamically swapping 16 KB pages of expanded memory into a fixed 64 KB page frame located in the upper memory area, typically a 64 KB block such as from D0000h to DFFFFh to minimize conflicts with video memory and other hardware mappings.[11][12] This page frame, often starting at a segment address like D000h, consists of four contiguous 16 KB physical pages, providing a "window" through which applications can read and write data as if it were conventional memory.[13] The system relies on bank switching rather than direct addressing, allowing up to several megabytes of expanded memory to be managed efficiently within the constraints of real-mode addressing.[12] Logical pages from the expanded memory pool are mapped to these physical pages using four mapping registers, one for each 16 KB slot in the page frame.[13][12] Each register holds a value specifying which logical page (a 16 KB block identified by a zero-based page number) is currently visible in that physical slot, enabling selective swapping without affecting the entire memory space.[11] The expanded memory is organized into a large array of such logical pages, with the total number depending on the hardware capacity, and mappings ensure that only the requested portions are accessible at any time to prevent address space fragmentation.[12] Applications allocate blocks of logical pages via an EMS handle, a unique identifier (ranging from 1 to 255) assigned by the EMS manager, which is typically the EMM.SYS device driver loaded under DOS. Handles are numbered from 0 to 255, with 0 reserved for the operating system, leaving 1 to 255 for applications.[13][12] This handle represents ownership of a contiguous set of logical pages, and the EMS manager oversees the swapping process by updating the mapping registers in response to application requests, ensuring thread-safe access and preventing overlaps between multiple programs.[11] Deallocation occurs by releasing the handle, freeing the pages back to the pool for reuse.[13] DOS applications interact with the EMS page mapping system through software interrupt 67h, where the AH register specifies the function code.[13] Key functions include AH=43h to allocate pages and obtain a handle (with BX specifying the number of 16 KB pages requested), and AH=44h to map a logical page to a specific physical page (AL for physical page 0-3, BX for logical page number).[13][12] The return value in AH indicates success (00h) or error (e.g., 80h for insufficient memory), allowing programs to manage mappings dynamically during execution.[13] The physical address within the page frame for a mapped logical page is calculated as follows: \text{[Physical address](/page/Physical_address)} = (\text{mapping register value} \ll 14) + \text{offset within 16 KB segment} Here, the mapping register value is the logical page number, the left shift by 14 multiplies by 16 KB (2^{14} = 16384 bytes), and the offset (0 to 16383) provides the byte position within the page; this is added to the base address of the target physical slot in the frame.[12][11] This mechanism ensures precise, low-overhead access to expanded memory contents.[13]Version Evolutions and Features
The Expanded Memory Specification (EMS), developed by Lotus, Intel, and Microsoft (LIM), evolved through several versions to address limitations in memory capacity, stability, and support for advanced operating environments. The initial EMS 3.0 standard, released in 1985, provided basic bank-switching capabilities for up to 4 MB of expanded memory using a fixed 64 KB page frame in the upper memory area.[6] EMS 3.2, introduced in 1986, represented a minor evolution focused on stability improvements and enhanced error handling, while doubling the maximum supported expanded memory to 8 MB. This version refined the page mapping mechanism to reduce conflicts in the 64 KB window, allowing more reliable allocation of up to 128 handles, each representing a variable number of 16 KB pages that could be paged into the frame. These changes addressed early issues with page frame placement and handle management, making the system more robust for DOS applications without altering the core architecture.[6][12] In 1987, EMS 4.0 marked a significant advancement, expanding support to 32 MB of expanded memory and introducing features for better multitasking compatibility on 80286 processors. A key addition was the Virtual Control Program Interface (VCPI), which enabled protected-mode operation by allowing DOS extenders to query and allocate memory regions without disrupting real-mode EMS access, facilitating smoother transitions for applications in multitasking environments like DESQview. Additionally, EMS 4.0 added functions for saving and restoring page map states (INT 67h functions 47h and 48h), permitting applications to preserve mapping configurations during context switches, which improved performance in shared-memory scenarios. The specification also supported larger configurable page frames up to 256 KB and mapping into conventional memory below 640 KB, enhancing flexibility over the single 64 KB frame of prior versions.[12][14][15] Parallel to the LIM standard, AST Research developed the Enhanced Expanded Memory Specification (EEMS) in 1986 as a proprietary variant, emphasizing faster access through improved bank switching. EEMS allowed mapping expanded memory pages directly into the conventional memory range below 640 KB and supported a larger, configurable page frame up to 256 KB, reducing the overhead of frequent page swaps compared to LIM EMS 3.x. This variant was backward-compatible with LIM software but offered superior performance for EEMS-aware applications, such as Ashton-Tate's dBase, by enabling direct access without exclusive use of the upper memory area. Many EEMS features, including flexible mapping and larger frames, were later integrated into LIM EMS 4.0 to unify the market.[17] Version evolutions introduced compatibility challenges, particularly between EMS 3.0 applications and later hardware or drivers compliant with EMS 4.0. Software written for EMS 3.0 often assumed a fixed 64 KB page frame and lacked support for multiple frames or VCPI, leading to allocation failures or mapping errors on EMS 4.0 systems without emulation modes. For instance, EMS 3.0 programs might not recognize the expanded handle limits or protected-mode interfaces in EMS 4.0, requiring updated drivers or compatibility shims to ensure functionality. These issues were mitigated in later drivers, but they highlighted the need for standardized backward compatibility in evolving memory architectures.[6][18]Hardware Implementations
Discrete Expansion Cards
Discrete expansion cards were standalone hardware add-ons designed to provide expanded memory (EMS) compliance on IBM PC-compatible systems, primarily through the Industry Standard Architecture (ISA) bus. These cards addressed the 640 KB conventional memory limit of DOS by implementing the Lotus/Intel/Microsoft (LIM) EMS standard, allowing programs to access additional RAM via a page frame in the upper memory area (UMA). Introduced in the mid-1980s, they were essential for memory-intensive applications on 8086, 286, and early 386 systems, where onboard memory expansion was limited or absent.[6] The Intel Above Board, released in 1984, was the first commercially available card to conform to the LIM EMS specification, enabling PC and XT users to break the 1 MB address space barrier. It supported up to 2 MB of expanded memory using DIP-packaged DRAM chips (such as 64 KB or 256 KB modules), with configurations allowing backfill of conventional memory up to 640 KB. Later variants, such as the Above Board Plus 8, extended support to up to 8 MB under EMS 3.2, while the Above Board 286 provided up to 2 MB and was compatible with 16-bit 286 systems, though early models were 8-bit only. These cards included diagnostic utilities like CHKMEM for installation verification and featured piggyback daughterboard connectors for additional expansion.[19][6] Quadram offered multi-function EMS cards that integrated memory expansion with peripheral ports, such as the Quadboard series. Models like the Quadboard-AT supported up to 3.5 MB and the Quadboard PS/Q up to 4 MB of EMS-compliant RAM (in revisions conforming to EMS 4.0), combined with a parallel printer port, serial RS-232C port, and battery-backed real-time clock. These were popular for business applications requiring both memory and I/O expansion on 286-based PCs.[20][21] Other notable models included the AST RAMpage series, offering up to 4 MB of EMS in the mid-1980s, with enhancements like multiple page frames that influenced the evolution to LIM EMS 4.0, and the STB Memory Board, which provided EMS functionality with capacities up to 4 MB in the late 1980s, often using bank-switched DRAM for compatibility with LIM 3.2. STB cards gained traction in the market alongside Intel and Quadram offerings, contributing to the widespread adoption of EMS in professional and gaming software during that era. Common across vendors, these cards supported memory ranges of 1-8 MB, tailored to early 286 and 386 systems where total system RAM rarely exceeded 4 MB.[6][20] Typical installation involved inserting the card into an available 8-bit or 16-bit ISA slot on the motherboard, followed by configuration using onboard DIP switches to set the EMS page frame address—commonly at E0000h-EFFFFh to avoid conflicts with video ROM or other UMA residents—and the I/O port base (often 0208h). No additional power connectors were required, as these cards drew operating current directly from the ISA bus's +5V rail, typically consuming 5-10 W depending on populated memory, which was manageable within the standard 200-300 W power supplies of 286/386 PCs. Once installed, a device driver like EMM386 or vendor-specific software (e.g., Intel's SETBOARD) was loaded in CONFIG.SYS to enable EMS access.[22][23][6]Integrated Motherboard Solutions
Integrated motherboard solutions for Expanded Memory Specification (EMS) emerged in the late 1980s as manufacturers sought to embed memory expansion directly into PC chipsets and motherboards, eliminating the need for separate expansion cards. One early example was the Chips and Technologies SCAT (82C235) chipset, released in 1989, which provided onboard support for LIM EMS 4.0, enabling access to up to 16 MB of expanded memory alongside shadow RAM capabilities.[24] This integration allowed 286-based systems to utilize EMS without occupying ISA slots, streamlining hardware configurations for OEMs building compact PCs.[24] BIOS implementations from vendors like American Megatrends Inc. (AMI) and Phoenix/Award further facilitated EMS integration by incorporating configuration options directly into the CMOS setup utility. In AMI BIOS, users could configure the EMS page frame through Advanced Chipset Setup, selecting base address options such as C0000h or D0000h for pages 0-3, along with I/O port addresses for page registers like 208h/209h.[25] Similarly, Award BIOS setups included provisions for EMS memory swapping within the 1 MB address space, defining the 64 KB page frame location above the 640 KB conventional memory limit, often in conjunction with chipset-specific drivers.[26] These features enabled seamless page mapping—typically allocating a 64 KB window in the upper memory area (UMA) from D0000h to EFFFFh—without requiring external hardware adjustments.[26][25] During the 386 and 486 eras, numerous motherboards incorporated soldered or socketed RAM specifically for EMS, often leveraging chipsets from Acer Labs Inc. (ALi) such as the M1429 for 386SX systems or later 486-compatible variants. These designs allowed up to several megabytes of onboard EMS RAM, populated via DIP sockets or surface-mount chips, providing direct memory expansion tied to the system's Micro Channel Architecture (MCA) or ISA bus. A notable example is the IBM PS/2 Model 50 Z, which offered an optional 386 processor upgrade kit allowing memory expansion to 4 MB or more, compatible with EMS via appropriate drivers and MCA expansion cards supporting LIM standards.[27] Compared to discrete expansion cards, these integrated solutions reduced reliance on precious ISA or MCA slots—freeing them for other peripherals—and improved overall system stability by minimizing potential bus conflicts and signal integrity issues from additional card insertions.[28]Software Implementations
EMS Device Drivers
EMS device drivers are software components loaded during the DOS boot process to manage access to expanded memory hardware, enabling applications to utilize the Expanded Memory Specification (EMS) through standardized interfaces. These drivers typically reside in the CONFIG.SYS file and handle tasks such as initializing the EMS page frame, allocating memory handles, and intercepting interrupts for page mapping operations. By providing a consistent API via interrupt 67h, they allow DOS programs to request and manipulate expanded memory without direct hardware interaction.[12] Microsoft's EMM386.EXE, introduced with MS-DOS 5.0 in 1991, serves as the standard EMS device driver for systems with 80386 or higher processors. Loaded via the CONFIG.SYS directiveDEVICE=EMM386.EXE [options], it emulates expanded memory using extended memory and supports upper memory block (UMB) allocation for device drivers and TSRs. Common options include RAM to enable UMB usage, NOEMS to disable EMS emulation while retaining UMB support, and FRAME=E000 to specify the 64 KB page frame address in the upper memory area, ensuring compatibility with LIM EMS 4.0 standards.[29][30]
EMM386.EXE manages EMS functionality by allocating logical handles to applications, each representing a set of 16 KB pages that can be mapped to the physical page frame as needed. It intercepts INT 67h calls to perform operations like page allocation (AH=43h), mapping (AH=47h), and deallocation, returning status codes in AH to indicate success (00h) or errors such as insufficient pages (87h) or invalid handles (83h). Troubleshooting common issues involves verifying hardware compatibility and configuration; for instance, failure to detect sufficient extended memory may result in messages like "Unable to set page frame address," often resolved by adjusting the FRAME option or excluding conflicting memory regions with the X= switch.[12][30][31]
Third-party drivers, such as Quarterdeck's QEMM386 introduced in 1988, offered enhanced EMS management with optimized memory allocation to maximize available conventional RAM. Configured similarly in CONFIG.SYS as DEVICE=QEMM386.SYS [options], QEMM386 provides EMS support alongside advanced features like Stealth mode to relocate ROM shadows into extended memory, allowing more efficient use of the upper memory area compared to EMM386. It allocates EMS handles and manages interrupts in alignment with the EMS specification but includes optimization tools like the OPTIMIZE utility to analyze and relocate drivers/TSRs, potentially freeing up to 600 KB of conventional memory in complex setups.[32]
Software-Based Emulation
Software-based emulation of expanded memory (EMS) enabled compatibility with EMS-dependent applications on systems lacking dedicated EMS hardware, by simulating the page-mapping mechanism using available system resources such as extended memory or disk storage. This approach was particularly valuable during the late 1980s and early 1990s, when many DOS programs required EMS support but hardware upgrades were not always feasible. Emulation relied on device drivers and third-party utilities that intercepted EMS calls and managed memory access through software, often at the cost of performance compared to hardware implementations.[33] The most prominent software emulator was EMM386.EXE, introduced by Microsoft in MS-DOS 5.0 in 1991, which leveraged the virtual memory features of the Intel 80386 processor and later CPUs to simulate EMS using extended memory above the 1 MB boundary. EMM386 allocated portions of extended memory—specified via the RAM= switch—for EMS page frames, mapping 16 KB pages into a 64 KB window in the upper memory area (between 640 KB and 1 MB) to mimic the LIM EMS 4.0 standard. This emulation required a 64 KB contiguous block in upper memory for the page frame and utilized the 80386's paging unit to handle address translations without hardware assistance. The NOEMS switch disabled EMS simulation, reserving extended memory solely for extended memory specification (XMS) access and upper memory blocks (UMBs), but when enabled, EMM386 provided seamless compatibility for legacy EMS applications. However, this method was incompatible with 80286 systems, which lacked the necessary virtual memory extensions for efficient page simulation, limiting 286 users to partial memory management without full EMS support.[34][35][36][37] For systems with insufficient RAM, disk-based swapping served as a fallback to emulate EMS functionality, though it introduced significant latency. Utilities like VDISK.SYS, included in IBM PC-DOS since version 3.3, created virtual disks that could utilize extended or expanded memory for temporary storage, allowing EMS-aware programs to offload data to disk or a RAM disk when physical RAM was exhausted. This approach allowed low-memory configurations—such as those under 1 MB total—to run EMS-aware programs by using the virtual disk for swapping, but access times were orders of magnitude slower than RAM-based methods due to I/O bottlenecks.[38] Third-party tools expanded on these capabilities, with Qualitas' BlueMAX (version 6.00, released in 1991) providing advanced EMS support for IBM PS/2 386 systems by dynamically remapping extended memory into EMS-compatible pages. BlueMAX optimized memory allocation, creating virtual EMS banks from extended memory through BIOS compression and upper memory block management, often yielding higher effective memory utilization than stock drivers. Such tools were essential for maximizing DOS performance on upgraded PCs without EMS cards.[1][28] Despite these innovations, software-based EMS emulation suffered from inherent limitations, including reduced performance due to CPU overhead in handling page mappings and interrupts, which could degrade application speed by 20-50% compared to hardware EMS in memory-intensive tasks. On 286 systems lacking 80386 paging, compatibility was further restricted, often requiring hybrid drivers like EMM286.EXE for basic UMB access but no true EMS simulation, forcing users to rely on disk swaps or forego EMS features entirely. These trade-offs highlighted the emulation's role as a bridge technology rather than a full replacement for dedicated hardware.[39][40]Applications and Impact
Adoption in DOS Programs
Expanded memory (EMS) saw widespread adoption in DOS programs during the late 1980s and early 1990s, particularly as software developers sought to overcome the 640 KB conventional memory limit imposed by MS-DOS. By enabling access to additional memory through a page-mapping system, EMS allowed applications to handle larger datasets and more complex operations without requiring a full transition to protected-mode architectures.[29] In the gaming sector, EMS was instrumental for creating expansive virtual environments and efficient asset management. For instance, Wing Commander (released in 1990 by Origin Systems) utilized EMS to load graphical and audio assets dynamically via EMS handles rather than relying solely on conventional memory. This approach enabled the game to maintain detailed missions and interactive elements that would otherwise exceed DOS memory constraints, making EMS a key requirement for optimal performance.[41] Productivity software also embraced EMS to enhance data handling capabilities. Lotus 1-2-3 version 3.0 (1989) incorporated support for expanded memory, permitting worksheets to exceed the 640 KB limit through dynamic allocation of EMS pages for calculations and storage. This feature was essential for business users managing large spreadsheets, as it allowed seamless expansion of data ranges without frequent disk swapping or memory reconfiguration.[42] Programmers accessed EMS functionality through the LIM API, primarily via software interrupt 67h (INT 67h), which provided functions for allocation, mapping, and deallocation of memory pages. The following example in QuickBASIC demonstrates querying available EMS and allocating a handle (adapted for clarity; multiply page counts by 16 KB for total size):DECLARE SUB GetEMSInfo ()
DIM SHARED EMSHandle AS INTEGER
DIM SHARED TotalPages AS INTEGER, FreePages AS INTEGER
SUB GetEMSInfo
' Get total and free pages (INT 67h, AH=42h)
AX = &H4200
INT86 &H67, REG, REG
TotalPages = BX
FreePages = DX
' Allocate 10 pages (160 KB) (INT 67h, AH=43h)
AX = &H4300
BX = 10
INT86 &H67, REG, REG
IF AX = 0 THEN
EMSHandle = DX ' Save handle for mapping
PRINT "Allocated 10 EMS pages (160 KB)"
ELSE
PRINT "Allocation failed"
END IF
END SUB
DECLARE SUB GetEMSInfo ()
DIM SHARED EMSHandle AS INTEGER
DIM SHARED TotalPages AS INTEGER, FreePages AS INTEGER
SUB GetEMSInfo
' Get total and free pages (INT 67h, AH=42h)
AX = &H4200
INT86 &H67, REG, REG
TotalPages = BX
FreePages = DX
' Allocate 10 pages (160 KB) (INT 67h, AH=43h)
AX = &H4300
BX = 10
INT86 &H67, REG, REG
IF AX = 0 THEN
EMSHandle = DX ' Save handle for mapping
PRINT "Allocated 10 EMS pages (160 KB)"
ELSE
PRINT "Allocation failed"
END IF
END SUB
#include <dos.h>
#include <stdio.h>
union REGS regs;
void allocateEMS(int pages) {
regs.h.ah = 0x43;
regs.x.bx = pages;
int86(0x67, ®s, ®s);
if (regs.x.ax == 0) {
printf("Allocated %d EMS pages (handle: %d)\n", pages, regs.x.dx);
} else {
printf("EMS allocation failed\n");
}
}
int main() {
allocateEMS(10); // Request 10 pages (160 KB)
return 0;
}
#include <dos.h>
#include <stdio.h>
union REGS regs;
void allocateEMS(int pages) {
regs.h.ah = 0x43;
regs.x.bx = pages;
int86(0x67, ®s, ®s);
if (regs.x.ax == 0) {
printf("Allocated %d EMS pages (handle: %d)\n", pages, regs.x.dx);
} else {
printf("EMS allocation failed\n");
}
}
int main() {
allocateEMS(10); // Request 10 pages (160 KB)
return 0;
}
Performance and Limitations
Expanded memory (EMS) offered significant performance advantages over traditional disk-based overlay methods in DOS applications, primarily due to its hardware-accelerated page mapping mechanism, which allowed rapid access to additional memory without relying on slower disk I/O operations. In hardware implementations, page swaps—typically involving 16 KB logical pages mapped into a 64 KB page frame—occurred nearly instantaneously via bank switching, enabling efficient data access for memory-intensive tasks.[36][12] However, in software-emulated EMS environments, such as those using EMM386 on 386 processors, page swaps incurred some overhead from CPU mode transitions, which could impact real-time applications like games requiring frequent memory paging.[45][46] The theoretical maximum capacity of EMS under the LIM 4.0 specification was 32 MB, divided into up to 2048 logical 16 KB pages, allowing substantial expansion beyond the 640 KB conventional memory limit. In practice, however, hardware implementations were often constrained to 8-16 MB due to motherboard address space limitations and the availability of expansion cards, with few DOS programs fully utilizing beyond 4-8 MB for data storage rather than code execution.[12][17] A key limitation arose from potential conflicts in the upper memory area (UMA), where the 64 KB EMS page frame (typically located between 640 KB and 1 MB) could overlap with address spaces reserved for peripheral devices, such as network interface cards, video ROMs, or other option ROMs, necessitating manual reconfiguration or relocation of the frame to avoid mapping errors and system instability.[47][48] Benchmark comparisons demonstrated clear performance gains; for instance, memory-intensive DOS applications like spreadsheets or multitasking environments (e.g., DESQview) achieved faster execution times when using EMS for data paging compared to disk overlay files, as RAM-based swaps reduced load times from seconds to milliseconds.[49] EMS accessibility was inherently restricted to real-mode DOS applications, providing no native support in protected-mode environments like Windows 3.x, where only limited emulation for DOS sessions was possible, further confining its utility to legacy DOS computing scenarios.[50]Decline and Legacy
Factors Leading to Obsolescence
The advent of the Intel 80386 microprocessor in 1985 introduced 32-bit protected mode operation, which supported linear addressing of up to 4 GB of memory and virtual memory paging, obviating the need for EMS's complex bank-switching to access additional RAM beyond the 1 MB limit.[46] This capability was further enhanced by the 80486 processor in 1989, which integrated faster memory management and caching, enabling DOS applications to utilize extended memory more efficiently through standards like XMS without relying on EMS hardware or drivers.[51] Operating systems transitioned toward extended memory support, diminishing EMS's relevance. Windows 3.1, released in 1992, primarily leveraged extended memory via the HIMEM.SYS driver and XMS in its 386 Enhanced mode, allowing up to 256 MB of addressable RAM while providing only limited compatibility for EMS, as the OS directly managed extended memory for better performance in multitasking environments.[52] Similarly, OS/2 2.0 in 1992 emphasized extended memory for its 32-bit architecture, sidelining EMS page-frame requirements that conflicted with protected-mode operations.[53] In protected-mode programming, the Virtual Control Program Interface (VCPI), which supported EMS-style memory allocation, saw limited adoption after 1989, as the DOS Protected Mode Interface (DPMI)—introduced by Microsoft and standardized in 1991—offered a more versatile framework for 32-bit DOS extenders and applications under Windows, effectively supplanting VCPI for memory services.[54] Economic pressures accelerated EMS's fadeout, as DRAM prices plummeted from around $300 per MB in 1985 to under $25 per MB by 1995, driven by increased manufacturing scale and technological advances, making abundant extended memory viable on standard hardware without costly EMS expansion cards.[55] EMS usage peaked in the late 1980s amid high RAM costs but declined sharply by the early 1990s, as affordable larger systems rendered its specialized paging unnecessary.[56]Related Memory Technologies
The Extended Memory Specification (XMS), jointly developed by Lotus Development Corporation, Intel Corporation, Microsoft Corporation, and AST Research, Inc., and released on July 19, 1988, established a standard for accessing memory beyond the 1 MB address boundary on 80286 and later processors.[57] Implemented via the HIMEM.SYS device driver, XMS enabled applications to allocate and manipulate large, contiguous blocks of extended memory directly, without the paging overhead inherent in EMS, which targeted the upper memory area (UMA) between 640 KB and 1 MB for bank-switched access.[58] This approach facilitated more efficient data handling for DOS programs, supporting up to 64 MB initially and later expanding to 4 GB under XMS 3.0 in 1992.[58] Shadow RAM, a performance optimization technique prevalent in 1980s and early 1990s PC BIOS implementations, worked by copying the contents of the slower ROM-based BIOS into faster system RAM during boot.[59] The BIOS address space (typically F0000h–FFFFFh) was then remapped to this RAM shadow, allowing subsequent BIOS calls—such as video and disk I/O operations—to execute at RAM speeds rather than ROM speeds, which could be 10–20 times slower.[60] By accelerating BIOS routines, shadow RAM reduced contention in the UMA, effectively freeing memory blocks for DOS applications without the need for EMS emulation or additional hardware, though it consumed a small amount of RAM (usually 32–128 KB).[59] Subsequent evolutions in DOS memory management included DOS extenders like DOS/4GW, introduced by Rational Systems in the early 1990s, which shifted programs into 32-bit protected mode to access up to 4 GB of extended memory.[61] These extenders adhered to the DOS Protected Mode Interface (DPMI), a standard that allowed seamless transitions from real mode while leveraging the 80386's paging and segmentation features, thereby circumventing both the 640 KB conventional limit and EMS's bank-switching constraints entirely.[61] DOS/4GW, in particular, became widely adopted for resource-intensive applications like games, enabling direct manipulation of extended memory blocks via a client-server model with the host DPMI server.[61] Outside the IBM PC ecosystem, analogous memory management strategies appeared in other platforms. AmigaOS, for example, incorporated memory paging in its Exec kernel to map virtual addresses to physical memory, particularly in versions from AmigaOS 4 onward, where a dedicated swap partition extended available RAM beyond hardware limits through demand-paged allocation.[62] Similarly, classic Macintosh systems under System 7 (introduced in 1991) implemented virtual memory via the Virtual Memory Manager, which used hard disk space as a backing store for paging inactive memory pages out of RAM, transparently expanding the effective address space for applications without hardware-specific banking.[63] Key differences between EMS and XMS are summarized in the following table:| Aspect | EMS (Expanded Memory Specification) | XMS (Extended Memory Specification) |
|---|---|---|
| Access Mechanism | Bank-switched 16 KB pages mapped into the UMA (A0000h–FFFFFh) | Linear, contiguous blocks accessed above 1 MB |
| Operating Mode | Real mode (8086/8088 compatible) | Real mode with preparation for protected mode (80286+) |
| Memory Focus | Emulated expansion within the 1 MB boundary | Direct utilization of extended memory (>1 MB) |
| Allocation Granularity | Small pages (up to 32 MB total, in 16 KB units) | Large handles (up to 64 MB initially, in variable blocks) |
References
- https://files.support.[epson](/page/Epson).com/pdf/psb/psb.s-0047c.pdf