Difference between revisions of "DOS memory management"
D1stortion (Talk | contribs) m |
|||
Line 3: | Line 3: | ||
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favourite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice. | This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favourite games and programs running. If you really want to understand how this all works, see the Wikipedia article on [http://en.wikipedia.org/wiki/DOS_memory_management DOS memory management], or use your web search engine of choice. | ||
− | |||
== Types of memory == | == Types of memory == | ||
Line 41: | Line 40: | ||
(todo: expand) | (todo: expand) | ||
− | |||
== Software == | == Software == | ||
(todo: list of memory managing software?) | (todo: list of memory managing software?) |
Revision as of 02:48, 8 April 2013
With modern operating systems, all memory management you need to do is installing enough RAM. And that's it. The OS determines how to use it, and you usually don't need to worry about it at all. In DOS, this is different. If you have ever tried DOS without paying attention to how your memory is organized, you may have noticed many programs fail to load with an 'Out of memory' error message. Even if you have four gigabytes of it! To use your RAM effectively in DOS you'll need to know how the x86 architecture splits up RAM in separate regions, what these different regions are for, and what you can do with them. Optimizing your system to reserve as much free space as possible for your programs is called memory management.
This page will try to explain, in simple language, all the technical terms you will encounter in DOS memory management, and provide you with practical information to get your favourite games and programs running. If you really want to understand how this all works, see the Wikipedia article on DOS memory management, or use your web search engine of choice.
Contents
Types of memory
Conventional memory
Conventional memory, or base memory, is the most useful type of memory. All programs and TSRs load in conventional memory. Problem is, you only have 640KB of it. (todo: expand)
Upper memory
The upper memory is all memory between the first 640KB and 1MB. It is normally marked as reserved memory for hardware, but memory management software can determine which parts are actually used and which are not, and enable you to access the unused areas as more-or-less 'normal' RAM. The unused parts of the upper memory area are referred to as Upper Memory Blocks.
High memory area
HMA is the first 64KB above the 1MB limit. This can be a bit confusing if you're just getting started in memory management, since the name is similar to upper memory area and is usually referred to in the same context as upper memory. They are in fact separate regions, where the upper memory is below the high memory area. If you really want to know how this became a separate region, use your favourite search engine. All you really need to know is that you can load parts of DOS into it by specifying DOS=HIGH(,UMB) in your config.sys file. Using HMA requires a driver that enable the A20-gate to gain access to memory beyond the 1 MB barrier like HIMEM.SYS.
Expanded memory
EMS (todo)
Extended memory
XMS (todo)
Memory management
Getting more conventional memory
A challenging aspect of DOS memory management can be to free enough conventional memory. Often games require a high amount of free conventional memory and sometimes also free EMS or XMS. To achieve this you have to use memory managers that allow e.g. enabling of UMBs and installation of APIs for XMS and EMS access. The availability of memory types depends on CPU and chipset.
On 286 CPUs special chipset support is required to enable UMBs. Rather well supported is the NEAT chipset. The HIMEM.SYS driver takes control of the A20-gate, makes HMA available and installs a XMS API. It is also possible to emulate a EMS page frame with the EMM286 driver.
386 and later CPUs feature an protected mode extension called Virtual 8086 mode that allows mimicking a 8086 memory layout for applications. With MS-DOS 5 a second memory manager was included called EMM386.EXE that uses the advanced features of 386 CPUs. It is loaded after HIMEM.SYS and enables UMBs and EMS emulation. This allows to load TSRs to UMBs freeing conventional RAM. The corresponding load statement in config.sys is DEVICEHIGH= and in autoexec.bat LOADHIGH which can be shortened to LH. EMM386 switches the CPU to Virtual 8086 mode.
(todo UMBPCI)
Generally memory managers must be loaded first. As rule of thumb TSRs taking more memory should be loaded before small TSRs to prevent memory fragmentation. Some drivers require a specific load order e.g. SMARTDRV.EXE after MSCDEX.EXE if the CD-ROM should be read cached. Some TSRs do not work correctly when loaded to upper memory, resulting in crashs or erratic system behavior. If you notice any instability in your DOS system, try to move TSRs back into conventional memory to find the culprit. You may look for driver alternatives or in worst case need to change hardware. Mainboard BIOS, graphic card BIOS and also additional cards as mass storage controllers or network cards use the memory area between 640K and 1 MB sharing space with UMBs. Especially newer graphic cards and mainboards are not designed with DOS in mind and are delivered with large BIOSes (> 32 kB). This can reduce available UMBs considerably. A classic DOS system has about 128 kB to 192 kB free UMBs for TSRs. Using EMS emulation requires a 64 kB area between 640K and 1 MB where the page frame of a virtual EMS card is mapped. If not required EMS emulation can be disabled freeing 64 kB of UMBs.
(todo: expand)
Software
(todo: list of memory managing software?)