High memory area
|This article does not cite any sources. (December 2016) (Learn how and when to remove this template message)|
In real mode, the segmentation architecture of the Intel 80286 and subsequent processors identifies memory locations with 16-bit segment and 16-bit offset, which is resolved into a physical address via (segment) x 16 + (offset). Although intended to address only 1 Megabyte (MB) (220 bytes) of memory, segment:offset addresses at
FFFF:0010 and beyond reference memory beyond 1 MB (
FFFF0 + 0010 = 100000). So this mode can actually address the first 65520 bytes of extended memory as part of the 64 KB range starting 16 bytes before the 1 MB mark—
FFFF:0000 (0xFFFF0) to
FFFF:FFFF (0x10FFEF). The Intel 8086 and Intel 8088 processors, unable to handle more than 1 MB of memory because they had only 20 address lines, wrapped around at the 20th bit, so that address
FFFF:0010 was equivalent to
In order to allow running existing DOS programs which relied on this feature on their newer IBM PC AT computers, IBM added special circuitry on the motherboard to simulate the wrapping around. This circuit was a simple logic gate which could disconnect the microprocessor's 21st addressing line, A20, from the rest of the motherboard. This gate could be controlled, initially through the keyboard controller, to allow running programs which wanted to access the entire RAM.
So-called A20 handlers could control the addressing mode dynamically, thereby allowing programs to load themselves into the 1024–1088 KB region and run in real mode. The first user of the HMA among Microsoft products was Windows/286 2.1 in 1988, which introduced the HIMEM.SYS device driver. Starting with versions 5.0 of DR-DOS (1990) and of MS-DOS (1991), parts of the operating system could be loaded into HMA as well, freeing up to 46 KB of conventional memory. Other components, such as device drivers and TSRs, could be loaded into the upper memory area (UMA).
- DOS memory management
- Conventional memory
- Upper memory area
- Extended memory
- Expanded memory
- Unreal mode
- Paul, Matthias (2002-02-02). "Treiber dynamisch nachladen (Intra-Segment-Offset-Relokation zum Laden von TSRs in die HMA)" [Loading drivers dynamically (Intra-segment offset relocation to load TSRs into the HMA)]. de.comp.os.msdos (in German). Retrieved 2017-07-02. (NB. Gives a comprehensive overview on the history and "nature" of the HMA and the non-obvious design constraints to be observed when developing resident system extensions to be loaded into the HMA. It also describes how to address these issues using stubs, backdoors, and intra-segment offset relocation, a method used by DR-DOS drivers capable of relocating into the HMA and similar to a (more sophisticated) method used as the basis for the dynamic dead code elimination in the author's FreeKEYB driver.)
- Paul, Matthias (2002-04-10). "[fd-dev] HMA access from TSR".
[…] MS-DOS 7.0+ adds INT 21h/AX=4A03h and INT 21h/AX=4A04h. RBIL61 INT 21h/AH=52h has some info on the MS-DOS 7.0+ HMA MCB chain […] HMA relocation for TSRs makes much sense for DR-DOS: Although you can load large parts of the BIOS and BDOS, the resident part of the shell, the BUFFERS, and DR-DOS TSRs like SHARE, KEYB, and NLSFUNC (and in some issues parts of TASKMGR and NWCACHE) into the HMA, there is usually still free space available, typically around 10 Kb (up to ca. 20 Kb when you use a 3rd party shell). It also makes sense for MS-DOS 5.0 - 6.22 and PC DOS up to 2000, which typically leave 4 - 7 Kb of the HMA memory unused (SHARE, KEYB, and NLSFUNC cannot load into the HMA, but DBLSPACE and HIMEM can to some extent). Available HMA space can be rather tight with MS-DOS 7.0+, since this issue introduced a new and for the most part undocumented RMD data structure usually located in the HMA. The kernel collects and records configuration and Real Mode Driver data during boot (type of driver, interrupts hooked by driver, CONFIG.SYS line of invocation, etc.) and stores this information in an […] complicated […] and […] growing data structure. Presumably this info is meant to be used by the Windows core to get a better picture of the loaded Real Mode drivers instead of treating DOS as a monolithic block, or even […] attempt to unhook or unload some of them, however, it is only used to a very limited extent (for example you can see some of the info reflected in the log files created on Windows 9x startup, and some parts of the Windows configuration manager also make use of it), leaving room for speculation much beyond the technical side - in particular because nothing of the interesting stuff is documented... […]