It is fairly obvious that Compaq’s Deskpro 386 changed the PC hardware and was probably one of the major reasons why we aren’t using PS/2 compatibles today. It may be less obvious that CEMM, an offshoot of the Deskpro 386 better known in its later incarnation as EMM386, also significantly shaped the PC software landscape.
When the Deskpro 386 appeared, it faced an interesting problem: There was no popular operating system capable of utilizing the advanced features of the i386 processor. Compaq marketed the Deskpro 386 simply as a very fast (and quite expensive) PC compatible designed for running DOS applications. Even after the first UNIX ports appeared, DOS was so popular and ubiquitous that users did not feel sufficiently enticed to switch. That was compounded by the fact that RAM was very expensive and systems with more memory than DOS could handle were rare around 1987.
CEMM/EMM386 ensured that DOS could handle quite a lot of memory. CEMM, or Compaq Expanded Memory Manager, was a very innovative piece of software. By utilizing the virtual 8086 (V86) mode of the i386, CEMM could provide 8086-compatible expanded memory (EMS) to existing DOS applications without requiring special hardware (as an 8086 would).
The idea was simple in principle, but quite complex in its implementation. The V86 mode requires the CPU to be in protected mode, but DOS is not a protected-mode operating system. Therefore, EMM386 had to include a miniature 32-bit protected-mode operating system; that was a necessity, not a feature. One of the most important tasks of this mini-OS was setting up page tables and enabling paging, a major new feature of the i386 CPU
Paging was how EMM386 did its magic. Swapping memory blocks in an out of the EMS page frame (located in the first megabyte of RAM and directly accessible by real-mode DOS applications) was accomplished by reprogramming the page tables and thus controlling which physical memory pages mapped to a given linear address. No memory copying was involved and the mechanism was very similar to how 8086 EMS boards worked, but used only the CPU’s built-in memory management facilities instead of relying on external hardware.
EMS support was very important in the late 1980s and early 1990s when software using EMS could run on anything from 8088 PCs up to the latest and greatest 486s. An alternative to EMS, called XMS (eXtended Memory Specification), had several drawbacks. XMS required at least a 286. Worse yet, real-mode programs could not access XMS memory directly; blocks had to be constantly swapped in an out of the first megabyte of RAM and the memory had to be physically copied.
EMM386 had another feature which was in the long run perhaps even more important than EMS support: UMBs, or Upper Memory Blocks. Most PCs had about 100-200 KB of unused space in the region between 640 KB and 1 MB. Some of this memory was taken by the BIOS, video memory, and adapter ROMs, but something like 180 KB RAM was a significant chunk compared to the grand total of 640 KB conventional memory. EMM386 used its paging magic again to remap extended memory (RAM above 1 MB) into the DOS-accessible UMB region.
This feature became extremely important when DOS machines started supporting networks, CD-ROMs, and numerous TSRs. All those goodies took up precious memory and without EMM386, a fully configured DOS system might easily end up with perhaps 350-400 KB of free conventional memory. That was a big problem because many applications simply refused to run if less than 400-450 KB memory was available. With EMM386, the drivers and TSRs could be moved into upper memory, and the difference between 350 KB and 500 KB of free conventional memory was huge.
Newer EMM386 versions could provide UMB support only, without also providing EMS, thus freeing up additional memory in the lowest megabyte. This became very important in the early to mid-1990s. By that time, relatively few applications required EMS; many supported XMS, either exclusively or as an option. Most applications requiring large amounts of memory (that is, several megabytes) used DOS extenders and avoided the 640 KB barrier entirely. But DOS extenders did not help with all the drivers and TSRs. EMM386 made it possible to load drivers for mice, networking, SCSI, CD-ROMs, sound cards, and still have a reasonable amount of free conventional memory left.
This probably prolonged the useful life of DOS as a mainstream operating system by several years. Without EMM386, DOS users couldn’t utilize all their hardware in DOS because the drivers would left no room for applications. They would be forced to run Windows 3.x with all its ugly warts, or switch to a full protected-mode operating system such as OS/2 2.x with its increased memory requirements. EMM386 slowed down the adoption of 32-bit protected-mode operating system by making DOS a viable environment into the mid-1990s.
Needless to say, EMM386 was neither the only nor the best program in its category. Quarterdeck’s QEMM and Qualitas’s 386MAX offered numerous additional features, but EMM386 set the industry standard and made 386 memory managers a force to be reckoned with.
Pingback: Original CEMM Unearthed | OS/2 Museum
Just a few comments:
” That was a big problem because many applications simply refused to run if less than 400-450 KB memory was available”
In my recollection it was even worse. I recall programs (games) requiring 590K of conventional memory to run (see e.g. https://www.dosgames.com/forum/viewtopic.php?t=2875). ! 450K wasn’t hard to obtain even without memory managers (maybe unless you used networking) but 590K required memory managers, especially if you also needed mouse and CD-ROM drivers etc.
Another thing:
“Most applications requiring large amounts of memory (that is, several megabytes) used DOS extenders and avoided the 640 KB barrier entirely. But DOS extenders did not help with all the drivers and TSRs.”
I’m not sure what this means because as far as I know/remember DOS extenders meant that it wasn’t really relevant how much conventional memory was available to the program, meaning there was then plenty of room for TSR’s. However, even then I think there were some dos extenders that worked even for TSR’s meaning they themselves could use the full memory of the machine while leaving a small footprint in conventional memory. I suppose in theories it would even be possible for such extended programs to run without any footprint in conventinal memory provided that a VM (e.g. EMM386) is installed that can properly reflect the interrupts, since then even the interrupt routines can reside >1MB.
Yes, games liked to require very large amounts of free conventional memory. But they were in a somewhat separate category, and game vendors solved that by providing utilities to create optimized boot disks. And yes, even with that, getting the required amount of free memory with mouse and CD-ROM drivers loaded was not always easy.
The game that sticks in my memory is Ultima VII which required lots of conventional memory and no V86 mode, i.e. no memory manager.
Yes, some DOS extenders supported TSRs. But the usage was somewhat rare because TSR vendors did not want to require a DOS extender with its associated compatibility issues. Also reflecting interrupts is not enough, buffers in conventional memory are usually required. Novell’s DPMS was probably the most complete solution, but my recollection is that it was never widespread enough to make a real difference (I used it, and it worked reasonably well with the few DPMS-enabled TSRs).
Although the 80386 CPU made emm386 ubiquitous, the reverse was also true.
What Intel implemented in the 386, other semiconductor companies were already implementing in the motherboard chipset — their half of the PC ecosystem. If you wanted to use more memory, you bought a 286 compatible CPU and a 286 MB with expanded/extended memory management, and the DOS/Windows drivers to manage it.
That market died when emm386 came standard as part of DOS. Why buy a third-party CPU and MB chipset with EMS/XMS, when, out of the box, your OS supported only the Intel386 hardware?
The 386 memory model was Intel’s Existing hardware equivilents were available as