Does your BIOS lie to you?

I have found, reported and got fixed quite a few issues with BIOSes incorrectly reporting the amount of free memory available to DOS and DOS appllications over the years.
The worst case is where the BIOS Int 15h interface reports that the system has more free RAM than is actually free! As a result, you can get corrupt ramdrives, corrupted EMM386 buffer areas, corrupted smartdrive buffers or crashing cswdpmi utilities, because these are using an area of RAM that is also being used by the BIOS at the same time.

If you are interested in seeing how your system reports what RAM areas are free to use by the OS, have a look here and try out the small DOS utility that I have written to check this. You can also use the grub4dos command displaymem (but it does not check or interpret values for you much).
I would also welcome any feedback and reports, as this is the first version of this utility and has not yet been tested on a large number of systems. It may have some bugs.
The GETMEM utility does not affect your system in any way and it does not interfere with any upper/extended memory or BIOS hooks, it merely calls the Int 15h interface a few times to retrieve the register values and interpret them.
I would also be interested to know if anyone can think of another way to test this extended RAM under DOS - e.g. by using cwsdpmi and a utility to do a pattern test on ALL available ram that the cswdpmi interface thinks it has the use of. Are there any such tests/utilities out there?

Here is an example report from GETMEM run on an Acer Aspire 7741G notebook:

REM GET AND CHECK MEMORY MAP (INT 15h E820 and E801) v1.0 2011-08-08 [SSi]
REM =======================================================================
REM BIOS call to Interrupt 15h AX=E801 returns amount of memory (max 4GB).
REM Interrupt 15h AX=E820 returns a map (base address and length of blocks)
REM DOS needs a contiguous block, it cannot cope with 'holes' in the memory
REM DOS uses AX=E801, Windows uses AX=E820
REM So the amount of contiguous memory reported by E801 should match or be
REM less than that reported by E820 - if not then DOS programs which use
REM extended memory may crash.
REM If ERRORLEVEL=0 then all is OK, if not then check output.
REM =======================================================================
REM BASE ADDRESS (H) LENGTH (BYTES) Base Add(MB) Length(MB)
REM ================ ================ ============ ============
REM B=0000000000000000 L=000000000009C400 B= 0MB L= 0MB
REM B=0000000000100000 L=00000000BB17C000 B= 1MB L= 2993MB
REM B=00000000BB282000 L=0000000000162000 B= 2994MB L= 1MB
REM B=00000000BB40F000 L=0000000000060000 B= 2996MB L= 0MB
REM B=00000000BB70F000 L=0000000000008000 B= 2999MB L= 0MB
REM B=00000000BB71F000 L=000000000005E000 B= 2999MB L= 0MB
REM B=00000000BB79F000 L=0000000000041000 B= 2999MB L= 0MB
REM B=00000000BB7FF000 L=0000000000001000 B= 2999MB L= 0MB

SET E801=2998
SET E820_TOTAL=2996
SET E820_CONTIG=2994
REM INT 15h E801 should be same as INT 15h E820 = ***** FAIL *****
SET RMEMTEST_PARAM=1 2997
REM ERROR - E801 memory cannot be more than total memory!
SET ERRORLEVEL=2

Thanks! Are you thinking about sharing the source code, by any chance?

If you go through DOS, you are using the limitations of that OS, and how DOS handles large numbers. While ye might be getting different answers from bios, it has to go through ibmbio.com, which means that you are looking at this too.

One should note that a proggie like loadfix is designed to get around proggies that can't cope with the wrap-around at A20, which means that the trick of FFFF0 + say 710 = 100700, but the program might see only the last 5 hex digits 00700, and write there. Loadfix loads the program above this wrapping.

It's like DOS looking at cdroms: seeing blocks of 2048 bytes, some DOS proggies return the cdrom size as 64k such sectors, or 128 MiB, rather than the correct size. This is one of the reasons that mscdex is a hacked network redirector, rather than a file system.

If you really need to see lots of memory, you should use some sort of real test to see these things.

I will put it on my codeshop99 website when I have tested it all and am happy with it. It is written in assembler. I still have a few tweaks to do. At the moment it only compares results to the nearest 1MiB, I am going to change it to check it compares the results to the nearest 64K.
Interestingly the QEMU BIOS also has the E801 bug...

If you go through DOS, you are using the limitations of that OS, and how DOS handles large numbers. While ye might be getting different answers from bios, it has to go through ibmbio.com, which means that you are looking at this too.

One should note that a proggie like loadfix is designed to get around proggies that can't cope with the wrap-around at A20, which means that the trick of FFFF0 + say 710 = 100700, but the program might see only the last 5 hex digits 00700, and write there. Loadfix loads the program above this wrapping.

It's like DOS looking at cdroms: seeing blocks of 2048 bytes, some DOS proggies return the cdrom size as 64k such sectors, or 128 MiB, rather than the correct size. This is one of the reasons that mscdex is a hacked network redirector, rather than a file system.

If you really need to see lots of memory, you should use some sort of real test to see these things.

No, I don't go through DOS, I call the BIOS directly.
New chipsets - e.g. Intel Series 6, no longer support GateA20. i.e. A20 is always ungated so DOS will always see a 'flat' memory map.

The whole point of protected mode memory, is that each VMM sees a block of contiguous memory, even if this is not so. It's the role of a protected mode memory mode (be it QEMM or OS/2 or Windows), to make a fragmented memory appear contiguous to every VMM, just as a file system makes it appear that a scattered fragments appear contiguous to a program that wants to read it.

Both OS/2 and NT use DOS 5, himem 2.77 etc. So you're not getting any fancy features from DOS 6 or DOS 7. DOS may simply not handle int 15 func E820. Various different DOS versions add support for different functions. The function may not make it all the way to bios, but might be handled in NTIO.SYS or NTDOSVM.EXE.

The 16 megabyte thing sounds like six hex digits, which turns up as a limit in some earlier versions of DOS. So there may well be more than 16 MB, but a throttle in DOS is preventing this from passing through this interrupt.

One should note that hdd calls through int 13 and other int calls (25) are of the same nature. Int 25 (the old one) can not see LBA, but is limited to CHS, and its inglorious limitations.

The whole point of protected mode memory, is that each VMM sees a block of contiguous memory, even if this is not so. It's the role of a protected mode memory mode (be it QEMM or OS/2 or Windows), to make a fragmented memory appear contiguous to every VMM, just as a file system makes it appear that a scattered fragments appear contiguous to a program that wants to read it.

Both OS/2 and NT use DOS 5, himem 2.77 etc. So you're not getting any fancy features from DOS 6 or DOS 7. DOS may simply not handle int 15 func E820. Various different DOS versions add support for different functions. The function may not make it all the way to bios, but might be handled in NTIO.SYS or NTDOSVM.EXE.

The 16 megabyte thing sounds like six hex digits, which turns up as a limit in some earlier versions of DOS. So there may well be more than 16 MB, but a throttle in DOS is preventing this from passing through this interrupt.

One should note that hdd calls through int 13 and other int calls (25) are of the same nature. Int 25 (the old one) can not see LBA, but is limited to CHS, and its inglorious limitations.

GETMEM is simply a test of the BIOS. If one BIOS interface reports x amounts or contiguous memory are available, and a slightly different BIOS interface reports y amounts of contiguous memory is available, then this is a BUG in the BIOS. Nothing to do with any OS!

Now different OS's will use this BIOS information in different ways (for extended memory handling, etc.). In DOS, and DOS utilities which handle extended memory, this can cause problems and can lead to crashes. As I said, I have over the years, discovered many such buggy BIOSes which have caused issues under DOS and also issues with memory tests failing because DOS or a DOS helper/utility believes what the BIOS says are 'contiguous' areas of RAM, but actually they are being used by the BIOS!

I work with technical contacts from Intel, Compal, HP/Compaq, Pegatron, Asus, FoxConn, MSI, Gigabit, AOpen, etc. etc. and have pointed out and got fixed many of the BIOSes that we use in our mainboards and notebook products.

If I run GETMEM on my Asus EeePC or my Dell Inspiron 530, it passes and the memory reports match. When I run it on an Asus Aspire 7741G, I get the errors reported above because that BIOS is buggy! Now the bug is probably in the E801/DOS interface call and so won't affect NT based OS's or linux(?) OS's which use E820 to get a memory map. But it may well affect DOS, as typically DOS and DOS utilities don't 'know' about the relatively new E820 call and so rely on E801 to return correct information.

P.S. New version v1.1 available which checks the 64K block count rather than the 1M count and so is more accurate.

HTH
S