I'm running a Dell EISA box with 32 MB.  The routine to determine the amount
of extended memory (machdep.c) reads the CMOS at locations 0x17 and 0x18.
Unfortunately, Dell believes that location can be at most 16MB per IBM's
original spec (read below), and that determining memory beyond that must
be obtained from an interrupt.

The possibilities I see are:
	1. Probe memory again. (Breaks old 386's)
	2. Use interrupt. (I'm not sure of all the implications here)
	3. Leave only or get Dell to change.

I mention 3, but don't believe it's possible.  I don't fully understand
2, so I can't judge it's worth.  Perhaps, one could probe memory only
when the arch is not a 386, and read CMOS otherwise.

Comments and or help?

			Thanks, bill

============================================================
Bill Arbaugh					215-573-3639
waa@aurora.cis.upenn.edu
============================================================

Forwarded message from Dell Tech support.
>      
>      Bill -
>      
>      >> According to the IBM tech manual says that bytes 0x17 and 0x18 hold
>      the low order and high order bytes of extended memory, respectively. <<
>      
>      That's true. Remember, though, that when IBM defined these, the upper 
>      limit of extended memory was (and still is, really) 16M. Ports 0x17, 
>      0x18, 0x30, and 0x31 are limited (in a BIOS that sticks with the 
>      original definitions of these ports) to reporting up to 15M of 
>      extended memory.
>      
>      `Course, there are some companies that have chosen to modify their 
>      BIOS so that these ports contain the amount of real installed extended 
>      memory. Dell has chosen not to do so, for the reason that I'll outline 
>      below.
>      
>      >> My interpretation of this info is that there is currently a bug in 
>      the
>      bios that is not setting the proper CMOS value for the detected memory 
>      size. <<
>      
>      Reasonable interpretation, but incorrect.
>      
>      The proper method of determining the real amount of installed extended 
>      memory, on an EISA system, is through INT15, D8h. If you happen to 
>      have a copy of the Phoenix System BIOS reference book, here's a quick 
>      snippet of a section in there:
>      
>      "EISA CMOS RAM is accessed via INT 15h Function AH=D8h Access EISA 
>      System Information. EISA extended CMOS RAM is accessed by the 
>      subfunctions of this function and should be the only method used to 
>      access extended CMOS RAM in an EISA system."
>      
>      Rather than mod our BIOS to pop the real extended memory values in 
>      0x30 and 0x31, we're sticking with IBM's original definition of INT15, 
>      88h (which simply reports back 0x30 and 0x31) and counting on 
>      developers to use INT 15h function D8h. This is the CORRECT thing to 
>      do.
>      
>      Unfortunately, there are still OS's and memory managers out there that 
>      aren't doing a check to see if the system is an EISA box, and, if so, 
>      use INT15 D8h for the memory count. Most commercial environments don't 
>      have this problem anymore.
>      
>      There's nothing that Dell can do for you here. To modify the BIOS as 
>      you've requested would mean going outside IBM's definition of INT15h 
>      88h. We won't do that, as there's another *proper* way to get the 
>      correct memory amount.
>      
>      You'll need to get the NetBSD developers to rethink their memory 
>      reporting algorithm. It looks like they're assuming that all NetBSD 
>      systems are ISA boxes.
>