Dec 122017
Memory access manager, version 1.08. Manages UMB's, EMS, and XMS.
File MAM109.ZIP from The Programmer’s Corner in
Category Utilities for DOS and Windows Machines
Memory access manager, version 1.08. Manages UMB’s, EMS, and XMS.
File Name File Size Zip Size Zip Type
MAM.DOC 86182 26644 deflated
MAM.EXE 68452 33517 deflated
ORDER.FRM 4327 1557 deflated

Download File MAM109.ZIP Here

Contents of the MAM.DOC file


Memory Allocation Manager (MAM) is a small DOS utility with power.
MAM provides the functionally of Quarterdecks Manifest (MFT) program
with additional features like that found in the MARK and RELEASE
programs. Specifically designed to be small but thorough it provides at a
glance all the information required about the PC's current memory use and
hardware state. MAM is invaluable in identifying potential memory or system
conflicts. Features include:

o Complete and flexible DOS memory usage display, choose
between many different memory displays including:

- Quick display of currently loaded programs, hooked
interrupt vectors and free base, upper (UMB), EMS and
XMS memory.

- Complete display of all memory in the PC from address
0 to end of extended memory including system memory,
device drivers, video areas, installed ROMs, EMS page
frames, system BIOS, HMA area and XMS handles.

- Display of just base (below 640Kb) memory or just
upper memory.

- Display of loaded programs including either full path
name or program arguments.

o Mark memory position and restore later (similar to the popular
MARK and RELEASE programs). Memory marks are written to
a file and occupy no memory space. Marks need only be made
once and used multiple times. All memory areas are restored
including base, upper (UMB), HMA, XMS and EMS memory.

o Store CMOS settings on disk and use later to restore CMOS or
just to compare to current settings.

o Quick test and display of hardware status including serial/parallel
ports and maths co-processor. MAM identifies the UART type
and comms settings of each serial port.

o Invaluable as a trouble-shooter, MAM can identify problems such
as viruses, memory conflicts, interrupt clashes, faulty ports or
maths co-processors.

o Works on any CPU from 8088 to 80486 and any DOS version
from 2.1 upwards. Extensively tested with most popular software
including DOS 6, DR-DOS, QEMM, 386MAX, NETROOM,
NOVELL Netware, OS/2 1.x and 2.0, Windows 3.x, 4DOS, etc.


MAM is share-ware. All rights are reserved. You are free to copy or
distribute the program but not to sell it. If you are a personal user you
may use the program for a free 30-day trial period, afterwards you are
required to register it or delete all your copies of the program.
Governmental, institutional or commercial users must register (site
licenses are available). MAM may not be distributed together with any
other commercial software or product or without this documentation file
without the specific permission of the author.


Registration costs $20 (twenty US dollars) for personal users, when
used on one computer only. Site licenses are $100 (one hundred US
dollars) and allow the unlimited copy and use of the program
throughout your company, organisation or government agency. Note
that site licenses include only one copy of the program and
documentation. Special licenses will be granted to schools and
universities (please contact me).

Registered users will receive a registered copy of the program and one
free upgrade of the software when it is updated. By registering you are
helping me to keep up development with MAM in the ever changing
world of DOS memory management. In addition registered users will
receive support via CompuServe. My CIS number is 76040,1420. My
address for mail is Marc Mulders, c/o CCS, 160 Summit Ave, Montvale,
NJ 07645, USA but since communication via mail is slow please send
messages via Compuserve if you can.


Now for the (unfortunately necessary) legal stuff. All warranties are
hereby disclaimed. The author makes no warranties on the software
either express or implied. The author is only liable to refund the
registration fee paid by you and no more. In no event will the author
be liable for any consequential, special, incidental or indirect damages
of any kind arising out of the delivery, performance or use of the
software. The author does not attest the software is error-free or that
the documentation is completely accurate.


MS-DOS and Windows are trademarks of Microsoft Corporation.
IBM, IBM PC, XT, AT, PS/1, PS/2, OS/2 and IBM-DOS are
trademarks of International Business Machines Corporation.
Intel is a registered trademark of Intel Corporation.
Desqview, QEMM, QEMM-386 and QRAM are trademarks of
Quarterdeck Office Systems.
386^MAX is a trademark of Qualitas, Inc.
DR-DOS is a registered trademark of Digital Research.
Netware and Novell are registered trademarks of Novell, Inc.
CompuServe is a registered trademark of CompuServe Corporation.
4DOS is a registered trademark of JP Software Inc.
Trademarks of other companies mentioned in this documentation appear
for identification purposes only and are the property of their respective




1.1 The default display 2
1.1.1 The status line 3
1.1.2 Loaded programs 3
1.1.3 Main and Upper memory availability 6
1.1.4 EMS memory display 7
1.1.5 Extended memory display 7
1.2 The /s display 9
1.2.1 The memory map 11
1.2.2 Other parts of the system display 16
1.3 Other memory displays and arguments 17
1.4 The device driver display 18


2.1 Adding a comment to a MARK 22
2.2 Creating and viewing MARK files 22
2.3 Restoring from MAM MARKs 23
2.4 Erasing MARK files 24
2.5 Hints and tips for MARK/RESTORE 24
2.6 Errors encounter with MARK/RESTORE 25


3.1 Saving and restoring CMOS settings 26
3.2 Comparing CMOS settings 27
3.2.1 Using a batch file to do a CMOS compare 27




Welcome, thanks for giving MAM a try! MAM is a DOS utility
which will allow you to view memory allocation, diagnose memory
conflicts and remove memory resident software. It was written to
provide me with all the diagnostic information I need in my everyday
work of supporting complex PC setups, and in particular 386 and 486
PC's with memory managers like QEMM, 386^MAX or DOS's
HIMEM and EMM386. I could have written several programs to
provide this diagnostic information - one for memory mapping, one
for hardware summary display, one to remove resident programs, etc.
Instead MAM become several utilities in one.

Besides DOS itself, MAM can be used under DOS sessions with
operating systems such as Windows or OS/2. Due to the fact that
MAM doesn't rely on the presence of any proprietary memory
manager and uses no product-specific interrupts or entry points,
MAM is regularly used in a variety of PCs, running a variety of
DOS and Windows software. This also means MAM should work
with future software products. Furthermore MAM is updated
regularly as requirements arise.

Manual Conventions: Although many memory and PC based
concepts are explained as appropriate, this manual would be longer
than a telephone directory if I attempted to give complete
explanations of it all. Instead I will assume for the most part a basic
knowledge of DOS and the PC. Absolute beginners should learn the
basics of the program here but for a more complete introduction to
these subjects I can best refer you to the many excellent DOS and
programmers reference books.

Various conventions are used throughout this manual:

- Memory address are almost always expressed in hexadecimal
(base 16). Hexadecimal numbers can be recognised by the
suffix "h" (except in the MAM listings where all addresses are
in hex).

- Byte quantities are expressed in decimal, sometimes in
kilobytes or megabytes. A kilobyte is used here to mean 1024
(not 1000) bytes and is abbreviated "Kb". A megabyte is 1024
x 1024 = 1048576 bytes and is abbreviated "Mb".

- The word "PC" is used loosely here to cover any 80x88/86
based CPU except in the context of a specific model of PC
such as the IBM PC.

- The upright bar symbol "|" is thoughout the manual to
seperate items in a display line when several choices exist.
The choices are enclosed in square brackets, e.g. "[DOS |
BIOS]" indicates a display showing either "DOS" or "BIOS".

- Various sample MAM listings occur, usually with example
command line syntax preceded with "C:\> ".

- The manual is best understood from front-to-back; if unsure
of a term or acronym, look to see if it's defined in the pages


1.1 The default display

The simplest use of MAM is to display the currently loaded
programs and provide a summary of memory usage and availability.
Try MAM without command line arguments:

C:\> MAM

MEMORY ALLOCATION MANAGER (c) 1990-1993 Marc Mulders - MAM V1.09
MS-DOS 5.00 on 80486 AT (Virtual Mode) with 640K and VGA display

--- ----- ---- ---- -----------------
0B70 0008 14000 Config
0EDC 0EDD 4704 COMMAND 22-24 2E
1009 100A 2032 CLOCK 08 09 10 13 28
108A 108B 6736 SHARE 2F
A000 ----------- DOS Memory End [640k] ------------------------
C800 C801 9776 GMOUSE 0C 33

Main memory has 580,848 bytes available
Upper memory has 32,656 + 88,544 + 8,176 byte blocks available

Enhanced Expanded Memory (EEMS V4.0) found at segment(s) : 1000 E000
40 (16K) EMS pages, 1 active handle(s), 7120K bytes free (7696K bytes total)
Handle Size Name
------ ---- ----
0 576K Reserved

Extended Memory (XMM V3.00 [V6.03] found)
7424K bytes reported (all under XMM management)
7056K bytes reported free by XMM

1.1.1 The status line

The first line displays the MAM version. The second line, which is
present is all MAM displays regardless of which command line
arguments are used, gives a brief summary of the machine setup, i.e.

- which DOS version is loaded. MAM displays the DOS version
number and if possible the DOS manufacturer - MAM detects
OS/2. If MAM is executed in a DOS window under Microsoft
WINDOWS or under Quarterdeck's Desqview, the word
"(Windows)" or "(Desqview)" is displayed.

- the CPU type is detected and displayed. MAM detects 8088,
8086, NEC V20, NEC V30, 80186, 80286, 80386, 80486SX and
80486DX chips. 80386SX CPUs are not detected as I have yet
to find a reliable and quick test for them. If MAM detects that
the CPU type found is being emulated and may not be the actual
CPU type, the word (Emulated) is added.

- the PC type is displayed. MAM retrieves this from the machine
BIOS - this may be PC, XT, AT or PS/2 model number.

- the chip mode (real, virtual or protected) is displayed for 80286
CPUs and greater. Many 386 memory managers such as
QEMM386 or DOS's EMM386 put the CPU into Virtual-86

- the amount of base memory is detected and displayed. MAM
does not rely on BIOS settings or motherboard switches but
detects base memory directly.

- finally the type of video display adapter is detected and
displayed. MAM detects monochrome display adapters (MDA),
Hercules Graphics Adapters (HGA), CGA, EGA, VGA and XGA

1.1.2 Loaded programs

Next follows the display of DOS's memory allocation chains showing
loaded programs and TSRs (Terminate-and-Stay-Resident programs),
one program per line. DOS maintains allocation chains to keep track
of memory usage. One memory allocation chain is always maintained
in main memory (below the 640Kb boundary, called normal or low
memory). MAM first displays any programs found in this chain. In
addition program memory may exist above main memory (called upper
or high memory) in further allocation chains. Any programs found in
upper memory are shown separated by a line denoting the DOS memory
end. For example, in the above display the program SHARE is loaded
into low memory and the program GMOUSE is loaded into upper
memory (sometimes known as "loaded high").

Note that upper memory is only available on some PC models, and only
if a suitable memory manager is installed. MAM has been tested to
work with most memory managers including QRAM, QEMM386,
386MAX, NETROOM and the MS-DOS and DR-DOS versions of
EMM386. MAM uses a heuristic method to determine the presence of
high memory chains and does not rely on any particular memory
manager to obtain its display. If MAM finds no upper memory the line
"--- DOS Memory End ..." is not displayed. Note also machines with
less than 640Kb base memory or machines which use the video pages
to obtain more than 640Kb base memory are correctly handled by
MAM - the DOS Memory End will be displayed lower or higher than
the conventional 640Kb.

The loaded program display as shown in 1.1, is sorted into columns:


The first column displays the segment address in hexadecimal where the
program starts in memory, e.g. in the above listing the program CLOCK
is loaded at address 1009:0000h. Some important memory segment
address to watch are A000h (640Kb boundary) and 10000h (1Mb
boundary). For most programs the SEG column will display the
segment address of the Memory Control Block (MCB). The MCB is
a 16-byte area which is allocated by DOS for all programs that use
memory. It records DOS information about that memory. The MCB
proceeds the actual memory space allocated for the program, that begins
16 bytes later.

If a memory area is not allocated to a program but is instead used by
the BIOS, the video display, an EMS page frame, etc. the SEG column
will report the starting segment address of the area.


As discussed above, DOS allocates a MCB to preceed each memory
area that is to be used by a program. The MCB contains various
information fields such as the memory block size, the program name,
etc. DOS also records a two byte "Process ID" in each MCB. This
Process ID is what is displayed under the owner column. The Process
ID is the starting segment address where the program's code actually
begins in memory - that is usually directly after the MCB itself, i.e. 16
bytes or one segment after the MCB address.

Not all memory areas associated with a program are used to hold
program code:

- DOS allocates an area of memory for each program to store it's
environment. Program environment blocks will be discussed

- Programs often request memory directly from DOS to store
their own data.

For those memory blocks that contain environment or program data,
DOS will usually set the Process ID to the segment address of the
program code.

Sometimes DOS will allocate memory for its own purposes, if so, it
usually sets 0008h or 0009h as the owner (why these numbers ? - I
don't know).

If an area of memory is free and not allocated, DOS will set the owner
field to 0000h. MAM does not display the zero, instead leaving the
owner column blank.


The size column shows the (decimal) byte size of the loaded program.
The size includes all contiguous memory MAM has found to belong to
the program. The minimum size will always be 16 bytes since this is
the size of the Memory Control Block (MCB) which always precedes
any allocated memory.


The name column shows any name that MAM has been able to find for
the program or memory area. Here MAM must do some detective
work. For example, the names of some programs which have executed
and then remained resident (TSRs) are not always available later.
Similarly memory allocated by a program subsequent to its load can be
difficult to track. Briefly for those interested in the technicalities,
MAM assigns names to memory users chiefly based on:

- the program environment block (under DOS 3.x and above).

- the name field in the MCB (under DOS 4.x and above).

- the MCB's owner or parent address, if it points to a MCB for
which MAM has already found a name.

However these places where program names are usually stored are often
trashed by software or not used at all. Assigning a name to each entry
in the MAM listing is by necessity done heuristically and MAM is
sometimes going to get it wrong - some names which appear might be
complete nonsense. A lot of work has gone into getting it right so your
indulgence is entreated when it occasional gets it wrong (please don't
send me letters asking why the name "gG%#JdR" or something like it
appeared in your MAM listing yesterday).

Some names in the name column are not retrieved from actual programs
but are assigned by MAM. They are usually shown in mixed case to
distinguish them from program names shown in upper case, e.g.
"Config" refers to memory used by config.sys. The name column is left
blank is no name could be assigned.


The last column displays the interrupt vectors (in hexadecimal) which
MAM has determined are pointing into the memory area occupied by
the program. The significance of these vectors varies. An full
explanation of what an interrupt vector is and what it is used for is
beyond the scope of this documentation (nice way of saying "Oh No! -
please don't make me explain that too") - if confused just think of them
as program entry points used by both the hardware and software of your

The PC has 256 interrupt vectors, 00h to FFh. If an interrupt number
appears opposite a program name it means that program has "hooked"
the interrupt, i.e. if the interrupt were to be called by software (or raised
by hardware) execution, control would pass to a point somewhere in
that program. Certain interrupts are more important that others, in
general the first 48 (30h) are the most consequential. Some interrupt
numbers to take note of are (hex):

08h (timer tick) - in most systems called by hardware 18.2 times a
second. The interrupt 1Ch is used in a similar way.

09h (keystroke) - called whenever a key is pressed.

0Bh, 0Ch - usually used by the serial ports COM1 and COM2.

10h (video) - called by programs to write to or in some way manipulate
the screen.

13h (disk) - called by programs to read and write to disk. The
interrupts 25h, 26h and 40h are sometimes also used for this.

16h (keyboard) - called by programs to retrieve keystrokes.

21h (DOS) - the main entry point for programs to DOS services.

So in the MAM listing 1.1, we can tell that the program CLOCK has
something to do with the timer tick (makes sense doesn't it ?) and the
program GMOUSE handles one of the serial ports.

Often interrupt vectors next to a program mean a lot less or nothing.
Some interrupts, like those above vector 90h are usually not used and
are liable to point just about anywhere.

In the interrupt vector listing, successive interrupts are grouped
together with a dash (-), e.g. in the listing in 1.1 interrupts 22h,
23h and 24h are all pointing to COMMAND (the COMMAND.COM DOS shell).

1.1.3 Main and Upper memory availability

The amount of free memory in both main memory and upper memory
is given (in decimal) after the loaded program display. Free main
memory is shown as the size of the largest available main memory
block. Free upper memory is shown as one or more free block areas.
Upper program memory is rarely contiguous due to video display areas,
system BIOSes and EMS page frames which also occupy space between
the 640Kb and 1Mb boundary. Upper program memory (RAM) is
therefore usually divided into one or more areas (sometimes called
regions). Usually a program wanting to load into upper memory must
fit completely into one of the free areas. So for the example memory
display in 1.1, a program with a maximum size of 88000 bytes may be
loaded high.

1.1.4 EMS memory display

Expanded memory or EMS is the oldest form of extra-memory used by
today's PCs. Expanded memory is essentially bank-switched memory.
This extra memory, which is usually larger that the normal address
space available in real mode (1024 Kb) is divided into small
independent blocks, called pages, each of 16Kb. However the memory
is not directly addressable - instead a EMS page must be mapped into
the 1Mb real-mode address space before it can be accessed and mapped
out later to allow access to other pages. The EMS manager provides
a set of services for access and control of this memory. The area in
memory where these pages are mapped is called the page frame, usually
64Kb (4 pages) in size. On machines which support the LIM EMS 4.0
standard, multiple page frames of almost any size may exist. Programs
access EMS memory through the use of memory handles.

If MAM detects EMS memory support, a brief summary is reported:

- the type and version of EMS.

- the starting segment address(es) of the page frame(s) are
displayed (hex).

- the total amount of EMS pages.

- the amount of active handles.

- the amount of EMS memory free for use (Kb).

- the total amount of EMS memory is shown in Kb.

- lastly a list of all active handles is shown - the handle number,
number of 16Kb pages allocated and the name of the owner is
displayed. The owner name is retrieved by a call to the EMS
management system, this name may be set by the program when
it requests EMS memory, if not MAM with leave the Name field

Note that handle zero is reversed for use by the EMS management
software - this is often used by 386 memory managers to map the lower
640Kb (actually usually less, about 576Kb) for use by multitaskers such
as Desqview or Windows.

1.1.5 Extended memory display

Extended memory is the term for memory above the 1Mb boundary.
This is only found on machines with more that 1Mb of total memory
which are based on the 80286 CPU or higher. Memory above 1Mb can
not be accessed by the PC in real mode, instead a CPU switch to
protected mode is required.

Although real mode addressing usually only allows the use of 20
address lines (A0-A19), most PC's today may be configured to provide
an additional address line (A20) to access an extra 64Kb while
remaining in real mode. This area from the 1Mb boundary to 1088Kb
is known as the High Memory Area (HMA).

MAM reports on the size and availability of extended memory and the
HMA. At least three methods exist for the access, allocation and
control of extended memory:

- the BIOS INT 15h functions. The designers of the original IBM
PC/AT built access functions to extended memory into the ROM
BIOS (INT 15h) and this has been duplicated in every 80286 (or
higher) based machine since. However only two functions are
provided, one which copies data to and from extended memory
and one which reports on the amount of extended memory
available. A primitive method for a program to allocate extended
memory and then mark it as used (ensuring other programs don't
attempt to use it too) sprung up. Programs call INT 15h to
discover the amount of extended memory available, then allocate
memory for themselves from the top of extended memory down.
The program then hooks INT 15h so as to intercept future calls
by other programs to which it reports memory availability
reduced by the amount it has allocated. Future program are
thereby fooled into believing there is less (or no) extended
memory. They in turn hook into INT 15h and so on. This
method of memory usage is from the top down - MAM will
report usage as "(Used from top)". If MAM is able to detect
which program (or the last program which) has allocated by this
method, the name will be displayed.

- the VDISK method. VDISK.SYS is a ramdisk device driver
which was originally supplied by IBM. It used a technique of
extended memory access and management which has since been
widely copied by other programs. Programs which use this
method allocate extended memory from the 1MB boundary
upwards and record their usage in two places. A table is created
at the 1MB boundary. A further table is created in conventional
memory and the INT 19h vector is used to point to it. Future
programs who wish to use extended memory should then inspect
both INT 19h and the 1Mb boundary and allocate memory above
that already used, recording their usage in these tables. This
method of memory usage requires cooperation between programs
and sometimes gets tricky - often the two different VDISK tables
are not both maintained and end up reporting conflicting
extended memory usage. MAM will check both tables and will
report only the greater memory usage as "(Used from bottom)".
Once again, if MAM is able to detect which program has
allocated by this method, the name will be displayed.

- the extended Memory Specification (XMS). XMS refers to a
software interface standard set up by among others, Microsoft
and Intel, to access and control extended memory and the HMA.
This standard provides a full set of functions to query, allocate
and free extended memory and the HMA - similar services to that
provided by EMS. MAM reports on the existence of an XMS
manager and issues calls to the interface to determine the amount
of free XMS memory, the presence and availability of the HMA
and the number and size of the active XMS handles. A summary
of the information is shown here. However the individual XMS
handles size and location is shown in the /s (system display, see

Note that often all three methods are used simulatenously, indeed this
is good programming practice. For example if DOS 5 is loaded HIGH,
it allocates the HMA via XMS calls, but also records its use with
VDISK tables as well as the INT 15h method. Furthermore most XMS
managers intercept the INT 15h vector and report only the extended
memory not under their control (often reporting no available extended

1.2 The /s display

Besides the default display explained in 1.1, various other command
line arguments can be used with MAM to show different memory views
or to show more of memory.

The /s display (or "system" display) is the opposite of the default
display. All memory from the first byte at address 0000:0000h to the
last byte of extended memory above the 1MB boundary at 10000:0000h
is displayed. This is the most comprehensive of MAM memory
displays, detailing all memory and not only the DOS allocation chain(s).
All memory users are shown, whether it is a loaded program, DOS,
BIOS or PC system usage, video card space, memory not used at all,
etc. MAM does an in-depth investigation to discover which program
or sub-system is using each region of memory. It uncovers memory not
in use as well as memory used for more than one purpose. Any clashes
in memory allocation - two or more memory users unwittingly using the
same area are also detected. The various memory boundaries - top of
DOS main memory and end of CPU real mode addressing space are
demarcated in the display. As with the default display any interrupt
vectors which are vectored into a memory region are display in the
right-hand column.

C:\> MAM/S

MEMORY ALLOCATION MANAGER (c) 1990-1993 Marc Mulders - MAM V1.09
MS-DOS 5.00 on 80386 AT (Virtual Mode) with 640K and VGA display

---- ------- ---- --- ------------------- -------
0000 - 003F 1K Sys Interrupt Vector Table 60-66 78-E9 F6
0040 - 004F 256 Sys BIOS Data Area F8
0050 - 006F 512 Dos DOS Data Area 1E
0070 - 0128 2960 Sys BIOS Interface (IO.SYS) 01 03 04 0F 1B 29
0129 - 026B 5168 Dos DOS Kernel (MSDOS.SYS) 00 20 27 2A-2D 32-3F
026C 0008 15616 *** Config 02 0A-0E 4B 67 70
72-74 76
@ 026E 1184 Drv HIMEM
@ 02B9 8400 Drv EMM386 4B 67
@ 04C7 2672 Dos 45 Files
@ 056F 256 Dos 4 Fcbs
@ 0580 512 Dos 0 Buffers
@ 05A1 624 Dos Drive List
@ 05C9 1856 Dos Stacks=9,128 02 0A-0E 70 72-74 76
063D 0008 64 *** DOS Data
0642 0643 2368 Psp COMMAND (Active Shell) 22-24 2E
06D7 64 *** Free
06DC 0643 704 Env Active Environment
0709 320 Env Free
071E 071F 7632 Psp SHARE /L:100 2F EE F1 F3 FA FD
@ 08C0 950 Dos 16 Fcbs
08FC 618528 Psp Free 30 EC EF F5 F7 F9
1000 - 9FFF 576K EMS frame - 36 page(s)
9682 - 9FFE 38864 Dos Command (Transient part)
9FFF 0008 16 *** DOS Data
A000 ------------- End DOS Memory End [640k] ------------------------
A000 - AFFF 64K VGA graphics buffer F4 FB
B000 - B7FF 32K --- Unused ---
B800 - BFFF 32K RAM VGA color text buffer
C000 - C7FF 32K ROM VGA BIOS 1F 43
C800 C801 16 *** UMB
C801 0008 464 *** DOS Data
@ C803 448 Drv SETVER
C81F 176 Env Free
C82B C82C 26976 Psp SMARTDRV 3072 08 10 13 15 19 21
25 26 28
@ CA29 Drv A: - F:
CFC1 66528 *** Free
E000 - EFFF 64K EMS frame - 4 page(s)
F000 - FFFF 64K ROM System BIOS 05-07 11 12 14 16-18
1A 1C 1D 31 40-42
44-4A 4C-5F 68-6F
71 75 77 EB
10000-10FFF 64K HMA Used (by DOS, 6K free) FE FF
@109BD 16492 Dos 31 Buffers
10000 ------------ End Real Mode Adr End [1088k] ----------------------
11000-83FFF 7360K RAM Used (from top)
11000-71CFF 6196K EMB Handle A716h (unlocked)
71D00-83EFF 1160K EMB Handle A71Ch (unlocked)

Expanded Memory (EMS V4.0) found at segment(s) : 1000 E000
EMS supports Alternative Map Register sets: 16 Total, 16 Available
40 (16K) EMS pages, 1 active handle(s), 6000K bytes free (6576K bytes total)
Handle Size Name
------ ---- ----
0 576K Reserved

Extended Memory (XMM V2.00 [V2.77] found, has 2 active handle(s))
7424K bytes found (all under XMM management)
64K bytes used (from bottom)
4K bytes reported free by XMM

1.2.1 The memory map

Various columns not found in the default (abbreviated) memory map are
added or changed in the system display:


The OWNER column is now labelled as OWN/TOP and serves three
purposes. For MCB's the column still displays the owner segment field
retrieved from the MCB. However since the system display shows
more than just loaded programs the column serves to show the end (or
top) segment address of memory blocks used for system or other use.
For these non-MCB blocks a memory range is displayed - the start
segment address in shown in the SEG column and separated from the
end segment address with a dash (-). For example in the display above
the system Interrupt Vector Table occupies segment addresses 0000h to
003Fh inclusive.

The column is put to a third use for memory uses displayed within
other memory blocks - if device drivers, DOS files or buffers, etc. are
discovered within a loaded program or memory region used principle
for something else. In this case the SEG column is blank and the
starting segment address of the sub-user is displayed with an at-sign
(@) prefix in this column. If the sub-user's memory area does not
begin on a segment (16-byte) boundary the closest boundary, rounded
down, is reported here.

Note that the dual use of a memory region or the presence of drivers,
etc. within other code is usually quite legitimate, and need not represent
a conflict. (MAM shows memory conflicts with a question mark prefix
in the NAME column). As an example of what is quite probably valid
use, in the display shown above, 16 Fcbs (DOS File Control Blocks)
were found in the memory space occupied by the SHARE program.


This column shows for each memory region the type or kind of user.
A three letter abbreviated is used and may be one of the following:

MCB Indicators: "Psp", "Env" and "***" - these are the only types
displayed for MCBs and correspond to memory used by a loaded
program with the DOS allocation chain(s):

"Psp" - (Program Segment Prefix). A program loaded by DOS
is immediately prefixed with a table, known as the PSP. The
table is 256 bytes long and is holds address and other settings
used by DOS in the control of the program. Among other uses,
the command line arguments with which the program was
invoked are stored in the table, any files opened by the program
are recorded here with a file "handle" and a pointer to the
program's environment block is placed here. MAM detects
MCBs as "Psp" by scanning the first 256 bytes directly after each
MCB, if a PSP is found this becomes the block "type", i.e. the
memory holds program code.

"Env" - A memory area in addition to that of the program code
is allocated by DOS for each program. When DOS (actually the
shell COMMAND.COM) loads a program into memory, it first
allocates a small amount of space to hold the program's
environment. This environment is used to hold DOS settings that
are in force just before the program executed. These are the
settings that are displayed when the DOS command SET is used
at the command line without arguments, and typically hold the
PATH, command PROMPT and other user SET's. Note that
although all programs receive an Environment block, most
programs don't use it - some TSRs choose to deallocate (release)
their Environment blocks if unused since it would otherwise be
wasted. In the display above, the program SMARTDRV is an
example. MAM marks MCB's as "Env" under two circumstances
- if it finds an environment pointer in a PSP in the memory chain
which points to that MCB's address or, heuristically, if it
determines the MCB memory's block to consist mostly of ascii

"***" - MAM marks MCBs this way if it can't determine the
memory region to start with a Program Segment Prefix or to hold
an Environment block. This often represents areas of memory
allocated by programs themselves with a "allocate memory" DOS
call. Another origin of these memory areas is DOS itself, the
MCB can be used to hold device drivers, memory chain
maintenance information, etc.

BIOS/DOS Indicators: "Sys", "Dos" and "Drv" - these type indicators
are displayed by MAM for memory used by DOS or the PC BIOS.
These areas are not MCBs and are not part of the DOS memory
allocation chain(s):

"Sys" - displayed for all memory allocated for system use - it
may be by the BIOS or due to the architecture of the CPU.

"Dos" - displayed for all memory directly used or allocated by
DOS or the command shell (usually COMMAND.COM). This
incudes buffers, files, file control blocks (fcb), stacks and drive
list space.

"Drv" - displayed for all device drivers. This type is shown
within other memory areas, usually MCB's. MAM scans each
memory region it displays for the presence of device drivers. If
found they are listed with their approximate starting segment
address in the OWN/TOP column prefixed with "@". If MAM
is able to determine the size the driver occupies this is also
displayed (if not the size column is left blank).

Extended Memory Indicators: "HMA" and "EMB" - these type
indicators are used for memory above 1Mb, usually under the control
of an Extended Memory (XMS) Manager.

"HMA" - displayed for the High Memory Area, the 64Kb area
between 1024Kb and 1088Kb. This area can only exist on 286
or greater PC's. The HMA is created by enabling the A20
addressing line. A Extended Memory (XMS) Manager, if loaded
will assume control of the area. If so, MAM will report in the
NAME column whether the XMS interface accounts the area as
used or free. DOS versions 5 and greater can use the HMA to
load part of their system code above main memory (if a
"DOS=HIGH" statement is in CONFIG.SYS).

"EMB" - this type indicator is used for allocated extended
memory areas under the control of the XMS Manager. Programs
request extended memory from the XMS interface in blocks,
called Extended Memory Blocks (EMB's). XMS returns a
"handle" to the program which it then uses to access the memory
allocated. MAM queries XMS for the handle number and size
of each EMB allocated, the size is reported in the SIZE column
and the handle number in the NAME column. A "segment"
address in reported in the SEG column (this is simply the
physical address divided by 16). However it is important to note
that initially the EMB has no address - no fixed physical address
exists and programs access the EMB by using its handle. The
use of a handle rather than an physical address allows the XMS
interface more freedom to move areas, merge free areas, etc. If
a physical address is desired the EMB must be "Locked" in
position. Locking is done though a call to the XMS interface at
which time an address for the EMB is returned. MAM therefore
determines an address for each EMB by first issuing a call to
"Lock" followed by an "Unlock". Of course this address is only
meaningful if the EMB was locked before - MAM reports this in
the NAME column as "(unlocked)" (no fixed address) or

Architecture Indictors: "ROM", "RAM", " " and "End" - these type
indicators are used to demarcate areas of memory which do not contain
MCB's and which are not allocated by DOS, BIOS or any program.

"ROM" - displayed if MAM detects a adapter ROM (Read Only
Memory) area or system BIOS in the memory region. The
system BIOS is contained in a ROM area, usually at segment
F000h. In addition, various adapter cards plugged into the PC
may map their ROMs into the memory addressing space, e.g.
most VGA cards have a ROM area which is mapped at segment
C000h. MAM scans any ROM areas found for the presence of
RAM (Random Access Memory, or read/write memory) - if the
entire ROM area contains RAM the type is changed to "RAM"
and the word "(Shadowed)" is appended in the NAME column.

"RAM" - displayed if MAM detects a memory region to contain
RAM. This is also shown for BIOS's which have been
"Shadowed" (copied by the system into RAM for faster access)
or for EMS page frames which are all currently mapped.

" " - a blank type is shown for system memory regions which
do not contain ROM or RAM. This type is usually shown for
the video graphics buffer and for EMS page frame areas.

"End" - this indicator is merely a place marker in the display and
does not represent a memory block. End indicators are used in
two places to demarcate:

- the end of DOS main memory. This is usually at 640Kb
but may be lower for PC's with less physical RAM or
higher when the video buffer areas are sacrificed for more
main memory.

- the real-mode addressing boundary. This is the
maximum address that can be accessed without changing
the CPU into protected mode (usually at 1024Kb but may
be shifted to 1088Kb if the A20 addressing line is
currently enabled, i.e. the HMA exists).


As in the default display this column displays the name of the program
using each memory region. This column can be used to show the
program name and program arguments (as in the system or argument
display, see 1.3) or to display the full path (drive, directory and name)
of the program (see 1.3).

However since the system display reports more than just program
memory use, names are attributed to all memory regions and shown in
this column. Upper case names which appear in this column are
usually obtained directly from the program in memory it describes.
Mixed case names in this column are labels assigned by MAM. These
labels include:

"Free" :- The area is unused but may be allocated (through calls to
DOS, XMS, etc.).

"--Unused--" :- The region is unused and usually cannot be allocated or
not at least without re-booting or re-mapping of system software.

"--Rammable--" :- The region is part of a large ROM or BIOS but
MAM has determined it to be used. Most memory managers will allow
RAM to be mapped into this area so that it may support UMBs (upper
memory blocks).

"EMS frame - n pages" :- The area is a EMS page mapping frame (see

"Handle nnnnh ([un]locked)" :- The area is a EMB (see Extended
Memory Indicators above).

"Used (from [bottom|top])" :- An extended memory region which MAM
has determined to be used (see 1.1.5).

"[Used|Free] (XMM Management)" :- A extended memory region under
XMS Manager control (see 1.1.5).

"ExtBIOSDataArea" :- The Extended BIOS Data Area (XBDA) is an
small area sometimes present at the top of DOS main memory. It is
used by the BIOS to store system settings. An XDBA is found on most

"Fixed Disk Param Table(s)" :- A table usually at the top of DOS main
memory used to hold the parameters for the fixed disk.

"?virus" and "????????" :- An area at the top of DOS main memory
which is not part of the DOS memory allocation chain and which MAM
cannot explain. MAM warns in some cases that this could be a virus
since many partition and boot virus hide in a similar way. Don't panic -
MAM's test is a very primitive one and this is by no means the definite
presence of a virus. (On the other hand I have detected many a virus
on clients machines with MAM and this simple test). Run a good virus
detection package before taking any action.

"Graphics Buffer" and "Text Buffer":- These are the memory mapped
areas used to hold the video text and video graphics buffers. Bytes
written into these buffers are translated into characters on the video
screen. The size and address of these buffers will depended on the kind
of video adapter, e.g. CGA, VGA, etc.

"Interrupt Vector Table" :- This is the first 1K of memory which is used
as a table to store the 256 system interrupt vectors.

"BIOS Data Area" and "DOS Data Area" :- These are two system areas
of fixed size used to hold BIOS and DOS settings.

"BIOS Interface" :- This is the first system file (usually IO.SYS or
IBMBIO.COM) which is loaded into memory by the system bootstrap
at startup.

"DOS Kernel" :- This is the second of the hidden system files (usually
MSDOS.SYS or IBMDOS.COM). It is loaded into memory by the
BIOS Interface.

"Config" :- Memory used by DOS to hold CONFIG.SYS.

"Dos Data" and "[Buffers|Fcbs|Files|Stacks|Drive List]" :- Areas used
by DOS for system tables, buffers, files, etc. and usually contained with
the memory area used by CONFIG.SYS. The number of buffers, files,
fcbs, etc within the region is also reported.

"Command" : See below.

Memory used by the Shell:- The shell is the program which accepts
command line input at the DOS prompt and which latches commands
or DOS programs. This is usually COMMAND.COM but may be
another shell program such as 4DOS. The shell allocates many memory
areas for it own use.

Firstly memory is used to hold shell code - if MAM detects a program
to be a shell the word (Shell) is appended to its name. Many shells
may be loaded on top of each other - MAM marks the shell currently
running as (Active Shell).

In addition the shell allocates space for a Root Environment (the SET
settings at boot time) and the Active Environment (the master copy of
the environment, copied into each program's environment block just
before its execution). MAM attempts to find and label these
environment blocks. Often the Root and Active environments occupy
the same space - if so it is labelled the "Active Environment". The size
of the Active or Master environment is set with the "/e" argument to the
"shell=" command in CONFIG.SYS.

Further memory is used by the shell COMMAND.COM to hold
transient code. This is an area of memory at the top of DOS main
memory (usually at 640Kb). Although COMMAND uses this memory
for its code it is not formally allocated - indeed it is often overwritten
by executing programs. COMMAND code in lower memory detects
any corruption and re-loads the code if necessary. MAM reports this
transient code memory use as "Command (Transient part)".


As described before (the default display), the last column in the system
display exhibits for each reported memory region, the system interrupts
which are vectored to point into that region. The system display shows
the entire memory map and not just loaded programs and accordingly
the vectors for each region are reported whether the region is a
program, BIOS, RAM, unused or the Interrupt Vector Table itself.
Interrupt Vectors consist of a real mode segment and offset address and
as such can only point below the real-mode addressing boundary. In
MAM listings no vectors will be ever be found in the columns of
reported memory above the real-mode addressing boundary.

As mentioned before, the significance of each vector's current address
differs from vector to vector. Many are uninitialised and point just
about anywhere. Other are initialised to zero, e.g. the vectors which
are shown in the vectors column for the Interrupt Vector Table itself are
probably unused (contain address 0000:0000).

1.2.2 Other parts of the system display

Unlike the default display, summary information about main and upper
DOS memory availability is not reported in the /s display. However
summaries of EMS and Extended Memory are included after the
memory map. These are identical to that shown with the default
display, except:

The EMS display reports on the presence of Alternative Mapping
Registers (AMRS) and how many are used/free. These registers
are used by multi-tasking software to improve task-switching

If a Virtual Control Program Interface (VCPI) is found it is
reported, along with the VCPI version number and reported
memory availability.

If a Dos Protected Mode Interface (DPMI) is found it is reported,
along with the DPMI version number and entry point.

1.3 Other memory displays and arguments

Besides the default and system memory displays five other memory
displays can be selected with the command line arguments:

The /f (full path) argument directs MAM to display only and all loaded
Memory Control Blocks (MCBs). In the NAME column the full path
(drive, directory, file name and extention) of each program is displayed
if possible, i.e. the location on disk from where the program was
executed. MAM retrieves each programs path from its environment
block. However many programs release (free up) their environment
blocks before going resident and so these programs can not be
displayed with their full path.

The /a (arguments) parameter directs MAM to display only loaded
PSPs. Here the NAME column is used to display the command line
arguments (if any) with which each program was invoked.

The /b (below) arguments shows only the MCBs located in DOS main
memory (e.g. below 640Kb).

The /f, /a and /b argument displays don't report on EMS/XMS.

The /u (upper memory) argument displays the memory map above the
DOS main memory end.

The /n (no program) argument provides a memory display with no
MCB's - just the system, BIOS, EMS, video buffer, etc. regions in the
memory map are displayed.

Although each of the above arguments selects a different display, two
arguments control all output listings by MAM and are intented to be
combined with other display arguments:

- the /p (page) arguments forces a display pause and wait for a
key press after each screen of information. Press escape while
paused to abort MAM.

- the /q (quiet) argument suppress all screen output. This should
be used instead of re-directing console output to nul (using

1.4 The device driver display

The /d argument is used to display device drivers. These drivers are
commonly loaded with CONFIG.SYS with a "device=" command.
Device drivers control access to a "device" (e.g. serial port or expanded
memory). DOS maintains a chain of device drivers and this is used
whenever a device is accessed.

There are two basic types of device drivers - character devices and
block devices. Character devices are byte-oriented devices such as
serial or printer ports, screen or keyboard, etc. - all communication with
the device occurs on a character-by-character basis. Each time a file is
opened, DOS firsts scans the device driver chain. If the name of a
character device matches that of the file name requested to be opened,
that device is opened instead of the file. Block devices on the other
hand, process blocks of data at a time (e.g. disk or tape drives). The
devices they control are assigned drive letters and become one of the
system's logical drives (e.g. C:, D:, etc).

MAM's /d argument, when used without the above memory display
arguments produces a display of the device driver chain.

C:\> MAM/D

MEMORY ALLOCATION MANAGER (c) 1990-1993 Marc Mulders - MAM V1.09
MS-DOS 5.00 on 80486 AT (Virtual Mode) with 640K and VGA display

------- ---- --- ---- ---- --- ----
0129:0048 NUL 1 0DC6 0DCC 8004 CharDev
D011:20C2 A: - F: 6 01B2 0252 08C2 BlocDev, 32bitSec, GIOCTL, OpClRmovM
B477:0000 CON 1 00F0 00FB 8053 CharDev, Stdin, Stdout, Int29, GIOCTL
0330:0000 SETVERXX 1 006C 00D8 8000 CharDev
026E:0000 EMMXXXX0 1 0051 0064 C000 CharDev, IOCTL
0070:0023 CON 1 06F5 0700 8013 CharDev, Stdin, Stdout, Int29
0070:0035 AUX 1 06F5 0721 8000 CharDev
0070:0047 PRN 1 06F5 0705 A0C0 CharDev, GIOCTL, OutBusy
0070:0059 CLOCK$ 1 06F5 0739 8008 CharDev
0070:006B 6 06F5 073E 08C2 BlocDev, 32bitSec, GIOCTL, OpClRmovM
0070:007B COM1 1 06F5 0721 8000 CharDev
0070:008D LPT1 1 06F5 070C A0C0 CharDev, GIOCTL
0070:009F LPT2 1 06F5 0713 A0C0 CharDev, GIOCTL
0070:00B8 LPT3 1 06F5 071A A0C0 CharDev, GIOCTL
0070:00CA COM2 1 06F5 0727 8000 CharDev
0070:00DC COM3 1 06F5 072D 8000 CharDev
0070:00EE COM4 1 06F5 0733 8000 CharDev

MAM scans the device driver chain from the head down and reports for
each driver in the chain, its name, entry points and attributes:


This is the address of the device driver header and is displayed in
hexadecimal segment:offset format.


The name of the device is shown here - this is the name as set by the
device itself and may not correspond to the file name used in
CONFIG.SYS. Usually only character devices have names - if a file
is opened with this name the device driver will be accessed. DOS
always uses the first device in the chain with that name. For example,
above, if a write operation is made to the file "CON" (the console) the
device driver at address B477h:0000h will be called, the driver at
0070h:0023h will be ignored. For block devices the NAME column
displays the system logical drive letters controlled by the driver
(e.g. the driver at address D011h:20C2h controls drives A: though F:).


This column reports the number of devices controlled by the device
driver. Only block device drivers may control more than one device.


This column display the first of two device driver entry points, the
strategy routine offset. These two entry points are used by DOS to
invoke the device driver. The strategy offset address is shown in
hexadecimal and is relative to the segment address shown in the
ADDRESS column - for the example above, the address of the strategy
entry point for the NUL device driver is at 129h:DC6h.


The second driver entry point, the interrupt routine offset is reported
here. Once again the offset is relative to the segment address in the
ADDRESS column.


This column display the device driver attributes - the driver
characteristics. First the attribute word, as found in the device driver
header is displayed in hexadecimal. This 16-bit word describes the
capabilities of the driver (according to the bits which are set). After
this word MAM displays a decoding of the attribute bits:

CharDev - the driver is a character device driver.

BlocDev - the driver is a block device driver.

Stdin - the (character) device is a standard input device.

Stdout - the (character) device is a standard output device.

Int29 - the device supports interrupt 29h, the fast console output

32bitSec - the (block) device driver can handle 32 bit sector
numbers (i.e. for DOS 4+, logical disk partitions greater that

GIOCTL - the driver supports generic I/O control commands
(control strings which are passed to the driver).

OpClRmovM - the driver supports the OPEN/CLOSE/Removable
media driver calls

Non-FAT - the (block) device driver does not support the IBM
block device File Allocation Table (FAT).

Network - the (block) device is a network device.

IOCTL - the driver supports I/O control comands.

OutBusy - the (character) device can accept output continiously
until it becomes busy.

When MAM is invoked with the /d argument together with one of the
memory map display arguments (i.e. /b, /u, /f, /a or /n) the device driver
chain is not displayed. Instead the appropriate memory map is
displayed with device drivers added to the display and reported at their
respective addresses. For example "MAM /u/d" displays loaded
programs and device drivers in upper memory.


MAM includes more than just the ability to display memory usage and
loaded programs. Using the MARK and RESTORE feature, users can
remove loaded programs (TSRs), device drivers, EMS/XMS allocations,
etc. and restore all memory and hardware status back to a previous load
point. Its simple:

First use MAM to make a memory MARK before any programs
or TSRs have loaded:

MAM /m

Later when you want to remove resident programs or memory
used since the MARK, use MAM with RESTORE:

MAM /r

MAM's memory MARK take up no space in memory and can be used
(restored to) as often as necessary. This is because each MARK is
written to a hidden file on the root directory of the current drive.
Provided the memory allocation before this MARK doesn't change the
same MARK can be used over and over. Many users make a memory
MARK as the last line of their AUTOEXEC.BAT file and use this to
restore their machines to what they were at boot-up time - this is much
quicker than re-booting.

More than one memory MARK may be made and restored to. After the
/m argument specify a number between 0 and 999. For example in the
following sequence:

C:\> MAM /m1


C:\> MAM /m2


Here two different MARKs are made, 001 and 002. The DOS
programs SHARE and PRINT are executed and remain resident in
memory. If the following command is used, PRINT is removed
(unloaded) from memory:

C:\> MAM /r2

To unload both PRINT and SHARE use:

C:\> MAM /r1

If no number is specified after the /m argument as in the first example,
the MARK is made with or restored from default MARK number 000.

2.1 Adding a comment to a MARK

Users may optionally add a comment to each memory MARK as it is
made. For example in AUTOEXEC.BAT:

MAM /m100 Use this to restore memory to boot settings

MAM stores the comment with the MARK in the MARK file but
otherwise ignores the comment. MARK file comments can be viewed
with the /l option (described later). Note that the comment starts
straight after the MARK number - the space is unnecessary. To freshen
(recreate) a MARK with the latest memory settings but keep the
comment intact, use a semicolon ";" instead of a new comment, e.g.

C:\> MAM /m100;

rewrites MARK number 100 but retains the comment line (note their is
no space before the semicolon). Comments are especially useful for
MARKs created to store CMOS settings (see section 3).

2.2 Creating and viewing MARK files on disk

As explained before the MARK file is written to a hidden file in the
root directory of the current disk drive. In fact any available disk drive
may to used, e.g.

C:\> MAM d: /m111

makes a MARK number 111 on drive D:. Similarly

C:\> MAM e: /r3

restores from MARK 003 on drive E:.

MARKs are written to a hidden file called "SNAPxxx.MAM" where xxx is
the MARK number. These files are never more than about 4000 bytes in
size. To view which MARKs are stored on a drive (together with their
comments) the /l argument is used, e.g.

C:\> MAM /l

MEMORY ALLOCATION MANAGER (c) 1990-1993 Marc Mulders - MAM V1.09
MS-DOS 5.00 on 80286 AT (Virtual Mode) with 640K and VGA display

MAM memory marks available :

222 At the start of AUTOEXEC.BAT [12:22 20May93]
041 [14:15 16May92]
061 [14:13 16May92]
111 With CMOS settings for my 386-33 with AMI BIOS [12:22 20May93]
000 [ 0:05 28Apr93]
601 Before SHARE [ 1:44 13Mar93]

Here six MAM MARK's were found on the default drive. Note that
MARKs made by a previous version on MAM are incompatible with
the current version and can't be restored to (however the CMOS settings
may be restored from these files, more on this later). If the MARK file
was made by a different version of MAM this is reported after the
comment in . Above we see the MARKs 41, 61 and
601 were made by older MAM versions. Lastly MAM shows the date
and time when each MARK was made in square brackets.

2.3 Restoring from MAM MARKs

The /r argument directs MAM to restore memory allocation and
hardware status from a previous MARK file. MAM can only remove
loaded programs and memory users, it doesn't reload programs which
are not loaded now but were loaded at the time of the MARK.
Specifically the following are removed if they were loaded or allocated
after the MARK was made:

- programs loaded in main (below 640Kb) and upper memory

- EMS, XMS and HMA allocations.

- Virtual Control Program Interface (VCPI) allocations.

- device drivers.

Also the following are restored:

- logical drive letters added or changed by device drivers loaded
after the MARK.

- open files which were owned by programs which are unloaded
are closed.

- network resident code and drive letters added by programs such
removed if loaded after the MARK.

- interrupt vectors, IRQs and serial port UART and parallel ports
interrupts and control lines are restored to their state at the time
of the MARK.

- serial and parallel port I/O addresses in the BIOS data area are

The DOS environment (DOS PATH, PROMPT and SET's) is not
restored by the /r argument. Instead use /v followed by the MARK
number, e.g.

MAM /v35 c:

directs MAM to restore BOTH memory status and environment settings
from MARK number 035 on drive C:

2.4 Erasing MARK files

MARK files may be refreshed (overwritten) by newer MARKS of the
same number, e.g.

C:\> MAM /m12

overwrites any previous MARK number 012 with new (current)
memory settings. MAM MARK files may also be deleted when no
longer desired with any utility capable of deleting hidden, read-only
files. However since this can be tricky MAM provides a option to
erase the MARK files. Either one or all the files on a specific drive
can be erased, e.g.

C:\> MAM /e0

erases MARK file number 000 while

C:\> MAM a: /e

erases all MARK files found on drive A:. The /e argument and be used
after the /r or /v argument to restore memory and then erase the MARK
file, e.g.

C:\> MAM /v333 /e333 /q

will restore memory status and environment settings from MARK file
333 on the current drive and then erase the file. Here the /q argument
is used to suppress all MAM screen output.

2.5 Hints and tips for MARK/RESTORE

Although MAM has been designed to mark and release most programs
or memory users, some precautions are advised:

- MAM can't restore (reload) programs which were loaded at the time
of the MARK but are not resident now.

- Avoid using out of date MARK files - if your memory setup changes
frequently, use batch files to remake MARKs. MAM can not restore
memory from a file made by another version of MAM. Although old
MARK files can still be used to restore CMOS settings (see section 3)
the /r or /v arguments can't be used with these files.

- Memory can be marked or restored within a DOS batch file but avoid
both marking and restoring within the same batch file. A lot of work
has gone into getting MAM's mark/restore feature to work within batch
files but its still not ideal. The main reason is that the batch file
reserves some memory for itself and this cannot be released by MAM.
This does not apply to 4DOS, a command shell (COMMAND.COM)
replacement program. If possible use aliases (provided by among
others, the DOS program DOSKEY) instead of batch files.

- MAM works in a DOS session under MS Windows or OS/2 but don't
try releasing MS Windows or OS/2 itself (be serious). Instead try the
ultimate memory restore, type "MAM /boot".

- MAM can not restore memory allocated by some specialised programs
using the DOS Protected Mode Interface (DPMI). MAM can restore
memory allocated via the Virtual Control Program Interface (VCPI).

- MAM can't restore environment settings of more that 2Kb.

2.6 Errors encounter with MARK or RESTORE

MAM performs some checks on memory MARKs before restoring from
them. This is to ensure that the MARK file is valid and not outdated,
i.e. that the memory setup before the MARK was made is the same. If
you change your default memory setup often (i.e. change the programs
loaded in your CONFIG.SYS and AUTOEXEC.BAT) its best to add a
line in your AUTOEXEC.BAT to remake the MARK file at each boot.
MAM reports the following errors if it is unable to restore from a
MARK file:

"No such MAM mark file found" - the mark file with the specify
number doesn't exist on this drive - use /l to view available MARK

"Version x.xx restore file specified - incompatible" - MAM can't restore
from a MARK made by a older MAM version.

"Can't restore to mark - CPU/mark Virtual Mode conflict" - the CPU
was in real mode at the time of the MARK and is now in virtual mode
(or visa-versa).

"Bad MAM mark (config) used for restore - memory not restored" -
programs loaded in CONFIG.SYS or AUTOEXEC.BAT have changed
since the MARK was made.

"Bad MAM mark (MYPSP) used for restore - memory not restored" -
a program was loaded at the time the MARK was made in the address
space MAM is now currently occupying.

"Bad MAM mark (# MCB) used for restore - memory not restored" -
more programs (MCBs) were loaded at the time of the MARK than are
loaded now. MAM can't restore (reload) programs loaded previously.

"Bad MAM mark (EMS) used for restore - memory not restored" - the
EMS memory subsystem has changed (different or no EMS manager,
different EMS memory or handle total, etc).

"Bad MAM mark (ALT_MAP_REG) used for restore - memory not
restored" - the EMS Alternative Map Registers Set (AMRS) count total
has changed (see above).

"Can't use console re-direction if MARK option required, see /q option"
- the /m argument was specified together with console re-direction, e.g.
"MAM /m >nul". This is not allowed, use "MAM/q" instead.

"Mark file appears corrupt" or "Error on file write - disk full ?" - an
disk error occurred while MAM was reading (restoring) or writing
(marking) to a MARK file. Check the free space on the file disk and
erase corrupted files (use the /e option).


MAM's /m option does more than store the memory, interrupt and I/O
port settings. In addition the CMOS settings are written to the MARK
file automatically. MAM does not interpret the CMOS settings but
instead dumps the entire CMOS RAM contents (usually 128 bytes) to
the MARK file. Later the current CMOS may be compared or restored
from the MARK file. (Note that the time and date CMOS settings are
not saved or restored.)

3.1 Saving and restoring CMOS settings

To save the current CMOS settings make a MARK as before, e.g.
C:\> MAM a: /m600

This will create a MARK file number 600 on disk A: (a MARK file
comment is often useful here). Both the memory and CMOS state are
written each time /m is used. However the CMOS settings are only
restored at specific user command and not by the /r or /v arguments.

If the CMOS is later incorrectly changed or gets corrupted, all the
settings can be restored. To restore the CMOS from the MARK file
use /z, e.g.

C:\> MAM /z600

When MAM uses a MARK file to restore CMOS settings, the rest of
the file (i.e. the memory, serial/parallel port settings, etc.) is
ignored. Also, although the CMOS includes the PC's date and time
settings, these are not restored by MAM. Furthermore MAM can restore
the settings from any MAM MARK version file and not just from a MARK
file made by its current version.

After the CMOS settings have been restored the computer must be re-
booted in order for them to take effect - add the /boot argument to
allow MAM to do this automatically:

C:\> MAM /z600 /boot

Remember the CMOS settings include the hard disk(s) parameters - if
your CMOS gets corrupted you may be unable to boot from your hard
disk. Therefore it is best to save settings on a floppy disk so that
they can always be accessed, e.g.

C:\> MAM a: /m999This has the CMOS for my 386-33

MAM CMOS restore can also be used to copy CMOS settings from one
computer to the another, provided both have the same BIOS
manufacturer and BIOS date. MAM's CMOS saving and restoring
options are ignored on a PC or XT model computer which has no

3.2 Comparing CMOS settings

Saved CMOS settings may also be compared to current settings either
to check if a restore is necessary, to simply determine if settings have
changed since a MARK file was written or to compare the CMOS
settings of two different computers. The /c option compares the CMOS
settings in a MARK file to the current settings (excluding time and date
settings), e.g.

C:\> MAM /c600

reports either that no change exists or the offset of the first CMOS
RAM byte that differs. This sort of output is probably not very
meaningful for most users but is done for a reason - the layout of
CMOS memory differs substantially between different BIOSes. MAM
makes no attempt to interpret the CMOS settings so as to work with
any BIOS. For most machines the use of the first 64 (40h) bytes of
CMOS RAM is the same. This layout is pretty much standardised on
that first used in the IBM AT and is widely documented. However
most modern BIOSes use 128 (80h) bytes of CMOS. The second 64
bytes is used without any standards and is usually undocumented,
although some PC manuals or motherboard booklets do offer some
detail. A general rule of thumb for the CMOS layout which can be
used to interpret MAM's /c option report is:

- the first 9 bytes contain real-time clock date and time settings
and are ignored by MAM.

- bytes 19 to 63 (9 to 3F hex) contain floppy and hard disk type
and size settings and memory size settings and are the most

- bytes 64 to 127 (40 to 7F hex) are either unused or are used for
additional special BIOS settings such as shadow RAM, wait
states, boot sequences, BIOS passwords, etc. If you have no
documentation for your PC and need to know the layout of these
bytes, my only advise is ... experiment.

3.2.1 Using a batch file to do a CMOS compare

MAM sets the DOS errorlevel on exit after a /c option and this can be
tested in a batch file if necessary. The errorlevel is 0 if no change if
found or 9 if the current CMOS differs from that stored in the file. The
CMOS settings can be checked each time the PC boots by adding the
following to your AUTOEXEC.BAT:

MAM /c900 /q
if errorlevel 9 echo WARNING! CMOS SETTINGS CHANGED!
MAM /m900Last line in AUTOEXEC.BAT/q


Although MAM is primarily a memory management utility a additional
option is provided to give a brief hardware summary display. MAM
checks and reports on the I/O channel bus type, interrupt request lines
(IRQs), serial and parallel ports and maths co-processor:

C:\> MAM /h

MEMORY ALLOCATION MANAGER (c) 1990-1993 Marc Mulders - MAM V1.09
MS-DOS 5.00 on 80486 AT (Virtual Mode) with 640K and VGA display


I/O Channel Type: ISA

IRQ 0-15 lines enabled: 0 1 2 6 8 9 13 14

Serial Ports (4):
COM1 @ Port: 03F8h UART:16450 UART Ints: Disabled [ 1200n71]
COM2 @ Port: 02F8h UART:16550A UART Ints: Disabled FIFO: OFF [38400n81]
COM3 @ Port: 03E8h UART:16450 UART Ints: Disabled [ 2400e81]
COM4 @ Port: 02E8h UART:16550A UART Ints: Disabled FIFO: OFF [ 2400n82]

Parallel Ports (2): 0378h 0278h Found: LPT1 LPT2 INTS enab:

Maths Co-Processor: On-Chip 486 FPU

First the I/O channel type is reported. This is the architecture of the
peripheral bus used for the expansion cards (e.g disk controller, serial
port, etc.). MAM detects and displays PC/XT bus (used in most
8088/86 PCs), MCA (Micro-Channel Architecture, used in most IBM
PS/2s), ISA (Industrial Standard Architecture, used in the IBM AT and
most 286+ clones) and EISA (Enhanced Industrial Standard
Architecture, used in some higher performance file servers, etc.).

Next MAM display the enabled Interrupt Request lines (known as IRQs
or hardware interrupts). Most PC and XT have 8 IRQs while 80286 or
better AT-type machines have 16 IRQ's. These interrupt request lines
are typically used by hardware devices such as the hardware timer, the
keyboard, serial and parallel ports, disk controllers, etc.). When
enabled, the IRQs allow devices to signal hardware events to the CPU.
MAM displays the number (in decimal) of those IRQs which are
currently enabled. A more complete description of the IRQ lines is
available in most hardware technical references.

MAM scans the BIOS for the reported serial and parallel ports installed.
In the case of serial ports MAM reports the following:

- MAM displays the number of serial ports and the I/O port
address (in hexadecimal) for each port as reported in the BIOS
data area.

- MAM detects the presence and the type of the UART (chip)
type for each serial port. The serial ports used in most earlier PC
were based on the 8250 UART but more modern machines
usually have serial ports use the faster 16450 UART. Recently
the 16550AN UART has been installed in many PCs used with
high-speed modems. The 16550AN chip is able to handle faster
baud rates due to it's 16 byte FIFO receive and transmit buffers.
The UART type test done by MAM is thorough - MAM will also
detect most defective UARTs and will display "" as the
UART type. If the UART is a 16550AN, MAM displays
whether the UART's FIFO buffer is currently enabled - this is
usually so with modern communications resident software.

- MAM reports if the UART has enabled its interrupts with
"UARTS Ints:". UART interrupts, if enabled allow serial port
processing to occur on an interrupt rather than polled basis.

- The current serial port baud rate and bit settings are shown
with square brackets in the form:

[baud parity data_bits stop_bits]

The parity is shown as "n" (none), "o" (odd), "e" (even), "s"
(space) or "m" (mark). For example above, port COM2 is
configured at 38600 baud, no parity, 8 data bits and 1 stop bit.

The parallel port display shows the following:

- the number of printer ports and their respective I/O port
addresses as reported by BIOS.

- As with the serial ports, MAM does a brief check for the
physical existence of each port, this is reported as "Found: LPTx
..". In the above example, both LPT1 and LPT2 were found to
be present.

- MAM reports the number of any printer port which has
interrupts enabled with "INTS enab:". Printer port interrupts
allow printing to occur on an interrupt basis, this is important for
some programs or operating systems (e.g. OS/2).

Note that under MS Windows and OS/2 the serial and parallel ports are
virtualized and the results of MAM's tests are unreliable - if MAM
detects either of these operating systems the physical tests on these
ports are skipped.

Finally MAM does a test to detect the type of maths co-processor
installed. MAM does not rely on BIOS for the FPU (Floating Point
Unit) detection, instead testing the FPU directly with FPU instructions.
Furthermore MAM detects the co-processor type independently from the
CPU type, it can detect a 80287 FPU installed with a 80386 CPU, etc.
If MAM detects a FPU which is not physically present but is being
emulated by software this is also reported.


Version 1.9 Updated for DOS 6. Added mark/restore of VCPI memory
(not with EMM386 though). Now displays DPMI entry
point address. Added mark/restore of HMA allocation.
Added mark/restore of FPU simulators. Fixed mark/restore
of some disk caches when used with device drivers such as
Stacker and DoubleSpace. Separated DOS Kernel to show
BIOS Interface. Fixed bug which sometimes occurred in
display of interrupt vectors in the F0h-FFh range. Now
displays DOS's "SC" and "SD" MCBs as "DOS Data".

Version 1.8 Enhanced /l display. Added Bus architecture and serial
port baud, bits, etc. display to /h option. Improved
detection and display of XBDA. Moved serial/parallel port
and FPU tests to occur only when /h argument used - this
to avoid upsetting timing sensitive comms or modem
downloads. Now uses DOS 5 sub-chains to determine size
of and to display device drivers, files, buffers, etc in
CONFIG.SYS. Display DOS 5's use of HMA and free
space. Improved display of EMB's in memory map and
fixed bug that sometimes reported 0KB size. Fixed
incorrect drive letter displays for some device drivers.
Fixed bug causing bomb in DOS session under Windows
3.1. Fixed delay while checking serial/parallel ports under
OS/2 2. Fixed bugs with MARK/RESTORE in batch files
and also with 386MAX. Updated MAM to check for real
System BIOS ROM address and size (confusion caused to
MAM by QEMM's Stealth technique, among others was
fixed). Many small bugs fixed and small changes made to
some displays.

Version 1.7 Now mark/restores XMM handles and memory too.
Supports HIMEM.SYS, QEMM XMM manager, etc. Full
support for MS-DOS 5 added. Displays programs loaded
with DOS 5's LOADHIGH. Works with Windows 3.0 in
real, standard and enhanced modes. Works with programs
using DPMI or VCPI memory interfaces. Fixed bug with
reporting on serial ports and in particular with 16550AN
UART chip. Fixed some small bugs/errors in memory

Version 1.6 First shareware release. Includes support for QEMM,
386-to-Max, QRAM, DESQview, all known EMS
managers, etc.

 December 12, 2017  Add comments

Leave a Reply