Filename: MEM-CONV.TXT
WWW URL: http://www.firmware.com/support/bios/mem-conv.htm
FTP URL: ftp://ftp.firmware.com/text/mem-conv.txt
Revision: 07/23/96 TLS Micro Firmware Technical Support
Summary: Explanation of why DOS MEM command may report less than 640K
total conventional memory - normally due to EBDA for PS/2
mouse or due to virus present in memory.
The DOS MEM command will report 640K or 655,360 bytes of total conventional memory on most systems. Issuing the command as just MEM will show the total as 640K, issuing the command as MEM/C/P will show the total as 655,360 bytes.
If the BIOS has set up an Extended BIOS Data Area (EBDA or XBDA), then 1KB (1024 bytes) at the top of base memory will be allocated for the EBDA. This will cause the MEM command to report 639K or 654,336 bytes of total conventional memory.
If EMM386 (or certain other memory managers) is loaded, it will automatically relocate the EBDA to within the first 64KB of base memory (unless the NOMOVEXBDA parameter is used), which will cause the MEM command to report the full 640K or 655,360 bytes as the total amount of conventional memory. Windows 95 seems to automatically relocate the EBDA even if VMM32 is not loaded. There is no memory gained by relocating the EBDA - all that is changed is its location and whether DOS or the BIOS is keeping track of it.
The presence of an onboard PS/2 mouse port is one reason why an Extended BIOS Data Area would be used.
The following Micro Firmware BIOS upgrades use an EDBA to support the onboard PS/2 mouse:
I4GS10 I4HS10 M4GS45GP M4HS45GC M4HS45GP M4GS50 M4HS50 M4HS60 P4HS00 P4HS10Also the following Micro Firmware BIOS upgrades use an EBDA for other reasons:
M3GS20 due to need to disable shadowing with over 16MB M3GS30 due to need to disable shadowing with over 16MB M4GS30 due to need to disable shadowing with over 16MB M4GS20 due to need to disable shadowing with over 16MB M4GS25 due to need to disable shadowing with over 16MB M4GS45 due to need to store some setup parameters in flash chip M4GS45G due to need to store some setup parameters in flash chip M4GS45GP due to need to store some setup parameters in flash chip M4HS45 due to need to store some setup parameters in flash chip M4HS45G due to need to store some setup parameters in flash chip M4HS45GP due to need to store some setup parameters in flash chipOn the M4GS45, M4GS45G, and M4GS45GP we set up an EBDA on the way into setup so that certain CMOS parameters stored in the flash chip (due to space limitations in CMOS RAM) can be kept in the EBDA temporarily to avoid excessive writes to the flash chip. Since this EBDA is only allocated on the way into CMOS setup and the system is rebooted on the way out of setup, this EBDA will not ever be present after booting to an OS. Note that the M4GS45GP will still have an EBDA set up for the PS/2 mouse.
Current versions of M4HS45, M4HS45G, and M4HS45GP set up an EBDA during the POST phase both for the same reason as the M4GS45/G/GP parts and also to be used for temporarily storing hard drive parameters if a drive type has been set to AUTO. Since this would always be needed if the AUTO drive type has been used, this EBDA is always allocated during POST, not just on the way into setup. We would have to specifically de-allocate it to get rid of it. This was not done on early revisions of these parts. M4HS45GP de-allocates the second EBDA starting with revision 4.05.08, released 07/23/96. We will fix this on M4HS45 and M4HS45G in future revisions.
The M4HS45GP is a special case. It has an EBDA allocated during POST and then has an additional EBDA allocated later for the PS/2 mouse. On current versions, both of these are present after booting. EMM386 (at least the MS-DOS 6.22 version) is confused by the presence of the 2 EBDAs taking up 2KB of RAM and does not relocate it as it normally would. So the MEM command run on a system with the M4HS45GP BIOS would normally show 638KB or 653,312 bytes of total conventional memory.
Any of the above findings may vary on individual systems for any number of reasons, including DOS version, memory manager used, various specific hardware, etc.
If the MEM command does report 639K as the total amount of conventional memory, the DEBUG command can be used to determine whether this is due to the use of an Extended BIOS Data Area.
Type DEBUG at the DOS prompt. This gives a dash prompt. Then type D 40:0. This will display several rows of pairs of hex characters. The last two pairs of the top row are a pointer to the EBDA. This pair of hex values is reversed, it represents a segment (or paragraph) address. The values will be C0 9F (9FC0:0000) if there is an Extended BIOS Data Area present at the top of conventional memory. These values will differ if the EBDA has been relocated. 32 0D (0D32:0000) is a typical value for the relocated EBDA. 80 9F (9F80:0000) indicates that the EBDA begins at 2K under the top of 640K. These values should be 00 00 if no EBDA has been allocated.
Another reason why less than 640K may be reported as the total amount of conventional memory is the presence of certain viruses in memory. Virus infections are very common and the most common PC viruses are boot sector infectors which load into memory every time the system is booted from an infected hard drive or floppy disk. To test for a virus, boot clean from a known uninfected, write-protected boot disk and run a good anti-virus utility such as F-PROT or McAfee's VIRUS-SCAN (see VIRUS.TXT).
Another reason for less than 640K to be reported would be the presence of certain expansion cards, such as hard drive controller cards, which have not only a ROM BIOS Extension but also the need to store information such as hard drive parameters in system RAM. Some such cards may allocate 1K or more of conventional memory for their own use. A network adapter card with a boot ROM may do this also. To test for this, remove the card and run the MEM command again.