AOH :: EXT-RAM.TXT|
An explanation of Extended vs Expanded memory
Subject: Re: Extended Memory
From: (Raymond Dunn @ Philips Electronics Ltd. - St. Laurent P.Q., Canada)
Memory up to 1 Megabyte:
MSDOS is designed around the 8088 CPU which can address up to 1 megabyte of
In "industry standard" IBM PC architecture, this memory is organized in the
1M +-------------+ FFFFF
| | System BIOS ROM
960K +-------------+ F0000
| | Option ROM and RAM
816K +-------------+ CC000
| | XT Hard Disk Controller BIOS ROM
800K +-------------+ C8000
| | Video BIOS ROM and option ROM and RAM
768K +-------------+ C0000
| | Video RAM space - various video types
| | have different requirements and starting
| | locations.
640K +-------------+ A0000
| | Base system RAM
1286 +-------------+ 506
| | Interrupt vectors and BIOS data area
0 +-------------+ 0
MSDOS expects this architecture, and assumes that the RAM up to 640K is
its resource to manage.
Although MSDOS will not expect to find any RAM above 640K except video RAM,
even though there actually may be some which it could use, e.g. unused on a
video card, on a special option card etc, it *will* however use any memory
immediately above 640K if the BIOS specifies it is available. This is
communicated to MSDOS at boot time by BIOS setting the memory size in location
413H of the BIOS data area.
As an example of this, the Philips P3345 386SX based machine allows the system
to be configured so that 64K is allocated at 640K to give a total of 704K of
"base" system RAM. This is *only* legal if an EGA/VGA video card is not
present, as this has video RAM at this address.
Some option cards provide RAM at other locations in the map. Applications
programs may use that RAM in a proprietary way. It is not normally considered
a DOS resource.
An example of this is the Philips P3105 XT system. It is more convenient on
this machine to provide 768K of RAM using all 256K chips rather than be
involved with 64K chips to provide 640K. This "extra" 128K of RAM can be
enabled if required at D0000. A ramdisk driver is provided to use this
Extended and Expanded Memory:
Extended memory is an intrinsic part of the architecture of the Intel
processor family, expanded memory is only defined in the architecture of the
*Extended* memory is memory directly in the CPU memory address space, above
the 1 megabyte address.
It is "extended" because the 8088 can only access 1 meg. Thus "extended
memory" is part of the "extended memory addressing" of the 80286 & 80386
*Expanded* memory is paged memory which can be addressed through a Page Frame
within the first 1 megabyte, and is thus accessible on all processors, even the
8088. Expanded memory can be provided in a number of ways (see below).
The mnemonic is easy, it is in the meaning of the words:
-> -> -> Extended is longer. <- <- <-
-> -> -> Expanded is fatter. <- <- <-
When you buy an 80286, 80386 or 80386SX based machine which has more than 640K
of RAM, that extra memory must be mapped somewhere, because *normally*, in the
architecture of the PC, the area between 640K and 1M is used for video RAM,
option card ROM and RAM, and the BIOS ROM.
Some machines map the 384K from this hole on top of any *other* extended
memory above 1M. I.e. if the machine has 1M memory, the 384K is mapped at
1M. If the machine has 2M memory, the 384K is mapped at 2M etc.
Some machines just map the memory away out of trouble at say 16 or 24Meg.
Some machines use all or part of it to "shadow" the system BIOS, and
sometimes a proprietary Video BIOS. Thus during system initialization, these
BIOSes are copied from ROM into the fast (16-bit or 32-bit) RAM,
write-protected, and the BIOS from then on executes from there. This
obviously requires motherboard hardware support.
Some machines allow all or part of the extended memory to be used as
expanded memory. This is achieved either by hardware support or software
emulation as described below.
*Some* machines allow all sorts of permutations of the above! This is an
area where manufacturers of clones can *add value*.
As *MSDOS* assumes an 8088 and can thus only address the first 1 Megabyte of
the address space, extended memory on a 286 or 386 has limited use with DOS.
It is most commonly used as a RAM disk, because this involves only *block*
access to the memory and is a nicely self-contained application, but it
could also be used for caching, directly by an application, or to implement
some *Expanded* Memory Scheme (EMS).
An 80286 has a 24 bit address space, i.e. 16 megabytes (1 meg plus 15 meg of
An 80386 has a full 32 bit address space (work it out yourself!). Most AT
architecture implementations using an 80386 use a private memory address bus
which limits the addressing to 16 or 24 or 32 Megabytes.
Extended memory is not generally used in the MSDOS environment other than by
RAM disk programs, disk caches, and expanded memory emulations, for several
- It is not available on 8088 machines so *applications* which wish to be
compatible across the whole product line stay away from using it directly.
- It is not a standard resource, so there is no proper management of it for
co-existing software (but see MSDOS 4.0 below).
- It is very slow and a pain in the neck to access because MSDOS runs the
80286 in native mode (i.e. as an 8088). To access above 1 meg the 80286 must
be switched into protected mode. This is fine, but there is no way to switch
it back to native mode (this is one of the reasons that the 80286 is regarded
as a brain-dead processor)!! So, the trick used is to get the keyboard
controller to RESET the CPU, and the BIOS reset code recognizes this and
continues! Thus it is really only good for some sort of *block* access to the
memory, and there is an INT15 function in the BIOS which does this for you.
All of this can be done more easily on an 80386, using its virtual 86 mode,
but there are other problems running DOS in this mode (you have to trap I/O
etc) and I wont go into that here. There are also the usual "how does the DMA
interact with logical addressing" type problems.
The good news is that Unix and OS/2 make *full* use of extended memory, as
they run the machine in protected mode.
With release 4.0, MSDOS recognizes extended memory for the first time as
more than just a RAM disk resource. In addition to RAMDRIVE.SYS and a disk
caching program, SMARTDRV.SYS, a device driver, HIMEM.SYS, is provided to
manage the extended memory according to XMS 2.0 specification.
XMS is an eXtended Memory Specification standard defined jointly by
Microsoft, Intel, Lotus and AST (not to be confused with LIM, see below).
This specification is available from them. XMS 2.0 allows extended memory
to be used by co-resident software, and, for example, allows TSR's to be
positioned in extended memory.
Very few applications are currently written to make use of this standard -
it is somewhat ironic that the provided RAM disk and disk caching routines
RAMDRIVE.SYS and SMARTDRV.SYS do *not* use the XMS management routines when
using extended memory, but *do* use LIM 4.0 when using expanded memory (see
XMS 2.0 also formally makes the first 64K of extended memory available as a
non protected mode memory resource using the overflow into A20 trick.
There have been several standards for expanded memory. Currently this has
settled down into the LIM 4.0 standard (_L_otus _I_ntel _M_icrosoft in
LIM 4.0 describes the following architecture:
PC MAIN MEMORY LIM EXPANDED MEMORY
. Extended .
. Memory .
. up to . /+-------------+ 32M
. 16M on the . // | |
. '286, . / / | |
. 4096M on . / / | Expanded |
. the '386 . / / | Memory |
| | / / | |
1M +-------------+ / / | Divided |
| | / / | into 16K |
960K +-------------+ / | logical |
| Page Frame | / | pages |
| 12*16K | / | |
| Physical | / | |
| Pages | / | |
768K +-------------+\ / . .
| | / . .
640K +-------------+/ \ . .
| Page Frame | \ . .
| 24*16K | \ | |
| Physical | \ | |
| Pages | \ | |
| | \ | |
256K +-------------+ \ | |
| | \ \ | |
| | \ \ | |
| | \ \ | |
0 +-------------+ \ \ | |
\ \ | |
\ \ | |
\ \| |
The expanded memory gives you up to 32M to map into up to 36 16K pages in
the positions shown above.
The page frame below 640K which allows the existing RAM to be shadowed are
usually regarded as being for the use of operating systems/environments.
The page frame above 640K, in the video RAM and "PROM" area, is for
applications. Code can be run or data stored interchangably in any of these
30 functions are defined using int 67H, to allocate, map, swap etc these
pages. These are provided, depending on the implementation, as a loadable
driver (usually), an extension to the motherboard BIOS, or on a PROM on a LIM
4.0 option card (not usual).
The number of actual pages available in the page frame depends on the
implementaion, and how much of the address space is already occupied by
option card ROMS (and perhaps RAM's) in the machine.
Applications which use LIM 4.0 can thus have a very large physical memory
available to them, but must access it by manually switching pages as
required (come back Z80 systems, all is forgiven!!)
LIM 4.0 can be implemented in many ways:
- as an option card with memory and page registers etc as I/O hardware to
provide the mapping etc, and an on-board BIOS PROM to provide the
- as a pure software emulation in a .SYS or TSR driver:
- using extended memory and virtual 86 mode on an 80386 so that the
memory is mapped using the MMU into any of the physical LIM pages.
- *copying* into the RAM pages existing below 640K, either from extended
memory (if other than 8088), or from, say, disk. This is much slower as
pages are swapped using copying rather than just updating page registers.
- using extended memory and mapping and page register logic built into the
motherboard ASICs or logic on an 80286 or 80386 machine. Philips has two
machines using this approach, the 80386SX based P3345 using the NEAT chipset,
and the 80286 based P2230 using the G2 chipset.
- combinations of the above etc.
LIM 4.0 management is handled by its BIOS only in so far as the application
can ask it what pages are free, how much memory is free to map etc., and to
perform the actual mapping. The actual use of this paging is left up to the
application. Neither LIM 4.0 nor DOS demand pages or anything remotely like
that, nor do they support an application's use of LIM in any other way. Two
or more co-existing applications can share the LIM quite happily if they are
well behaved (i.e. use LIM *only* through the BIOS calls).
Functionality is provided to allow the saving and restoring of the page
registers etc, so that even interrupt routines can safely be written to use
LIM memory, assuming they allocate all their requirements up front.
Whether or not LIM memory will be useful to you is *application* dependant.
Check to see if the applications you propose to use can take advantage of
Release 4.0x of MSDOS *does* recognize LIM 4.0's presence, and allows buffers
and fastopen file names etc to be allocated in LIM pages, and DEBUG now
"understands" LIM. In no way is LIM *integrated* into the operating system
though. A driver, EMM386.SYS, is provided in DOS 4.0 to emulate LIM 4.0 using
the *extended* memory of a 386 based machine.
The RAM disk and disk caching routines RAMDRIVE.SYS and SMARTDRV.SYS can be
configured to use extended memory, *or* expanded memory under the control of
The "Lotus/Intel/Microsoft Expanded Memory Specification Version 4.0"
(published by, you guessed it, Lotus, Intel and Microsoft), is the
definitive manual, and is available from them.
Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347
The entire AOH site is optimized to look best in Firefox® 3 on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986- AOH
We do not send spam. If you have received spam bearing an artofhacking.com email address, please forward it with full headers to email@example.com.