Many BIOSes today are unreliable when you try to run DOS on them, especially when using ram drives or DPMI extended memory handlers (cwsdpmi, EMM386, etc.).

In my experience, many of these problems are caused by the BIOS not reporting the amount of free memory (RAM) correctly.

An Operating System can determine how much free memory there is by using an IBM compatible BIOS Interrupt 15h routine.

DOS uses Int 15h AX=E801h - this returns the amount of contiguous free memory available up to 4GB - the specification is described here.

XP and later Operating Systems use the more recently defined BIOS call of Int 15h AX=E820h - this reports back a memory map to the Operating System. The map details the location, size and status of the memory areas within the CPU addressable memory map. For instance, if a system had free memory from 0 to 2GB and then from 4 to 6GB, a 64-bit operating system could use both areas of memory.

As nearly all systems and BIOSes are tested very thoroughly on Windows (7/8) before they are released, the Int 15h E820h memory map tends to be accurate. However, the value returned by the Int 15h E801h call is not always correct. This is a shame as most DOS utilities rely on this!

I have written the DOS utility GETMEM.EXE to check what different system BIOSes report back via these two BIOS Int 15h interfaces (E801 and E820).

If you run the DOS utility GETMEM (available in the Beta Downloads page), you will see that it displays the value returned by both calls and checks the values to see if it makes sense.

Note that you must boot to MS-DOS or FreeDOS (or IBM DOS,etc.) without any extended memory handlers loaded as some of these are naughty and patch the Int 15h interrupt hook! See Tutorial 37 for an example of how to make a bootable FreeDos USB drive.

Note: the GETMEM Base and Length translations in the 3rd and 4th columns are rounded down to the nearest 1MiB, but the hex values in the first two columns are reported accurately.

Some GETMEM outputs from different systems are shown below, the first two systems are OK, but the Acer Aspire 7741G notebook appears to have some problems!

You can also use the grub4dos displaymem command to list the Int 15h E820 memory map.

REM ERROR - E801 memory cannot be more than E820 total contiguous memory!

SET E801_64K_COUNT=47976

SET E820_64K_COUNT=47911

REM ERROR - E801 returned more 64K blocks available than E820!

SET ERRORLEVEL=3

You can see that E801 reports 2998MiB of RAM free, but the E820 map shows that only 2994 is actually contiguous (ignoring the lower 1MB area which we are not concerned with when using Himem or EMM386 or DPMI memory handlers under DOS). Something is clearly wrong, If DOS tries to use extended memory in this area, we may be accessing RAM which is actually used by the BIOS and so that area may become corrupted by the BIOS whilst DOS is using the same area for say a RAM Drive or extended memory buffer areas (e.g. cwsdpmi.exe).

Also the 64K available block count does not match, E801 reports 47976 blocks available (assumes all bottom 1MB is available), where as E820 reports only 47911 blocks are available - so which is correct? My guess is that the E820 map is correct because Windows XP+ uses this map, which means that the E801 result is incorrect!

One way to test if this area (in our case 2994 to 2998MiB) is really free to use, is to run a memory test which will test this area. One test I have used for many years and which I have found to be extremely good at finding memory issues under DOS (up to 3.5GiB) is Gregoriev's AleGr MEMTEST.EXE. For this Acer notebook, we need to run the command line:

This will test memory from the 1MiB start position for a length of 2997MiB - if the value returned by Int 15h E801h of this BIOS is correct, then this test should pass (64 passes are needed for a thorough test, but usually 1 pass will be sufficient if an area of memory is actually missing or being corrupted by the BIOS).

OR to just quickly test the top area that is under suspicion, we can use:

MEMTEST 4 2994 /fastdetect

to test base address areas of 2994MB, 2995MB, 2996MB and 2997MB.

Here is an example from an H61 based mainboard (using v1.3 of GETMEM):

You can see that there is a hole at 512MB, so the E801 value correctly reports 512MB, but actually there is 2GB of RAM fitted.

This BIOS returns valid values (except that it did not like ECX=24h when calling Int 15h E820h and I had to change this to 18h to make it work!) - Series 6 chipset boards seem to have a 'hole' at 512MB.

The area around 512MB, 1024MB and 1948MB is most likely used by the on-board memory mapped USB EHCI, Network and Audio adapters which can be mapped in this Series 6 chipset to anywhere within the first 4GB of address space.

This is similar to the H61 result - again memory 'holes' are apparent, but DOS should not complain.

BIOSes can use areas of memory as 'scratchpad' areas, or keep important tables or even code there or map memory-based registers there. For instance, an area of RAM might be used to keep track of the battery status during charging/discharging. In this case, some bytes may be updated only every minute or so, and thus may be hard to detect even when running a memory test as the test fills and reads back each pattern quite quickly. Other uses can be for USB buffers, CPU registers, hard disk and network buffers, PXE code/buffers/scratchpad area, and so on.

Why not put GETMEM and MEMTEST on a DOS bootable USB stick and try them out on different systems (do not load any drivers - i.e. no CONFIG.SYS or TSR's loaded).

See if your BIOS lies to you!

P.S. If you want to test memory above 3.5GB, I recommend the memory test that is part of the Windows 7 Recovery partition (64-bit) or Install DVD. This does test areas above 4GB (unlike some tests such as memtest86+ which look like they do, but actually don't!).