1% RAM missing?

[stonedzealot]

All right. I finally got that whole memory map thing squared away. Here's the thing. The numbers are always 1% off. On a 32MB emulated system (Bochs 2.1) with 32MB, I get exactly 33160192 bytes of OS memory, that's 385k off the mark but almost exactly 99% of a full 32MB. On my dad's computer (with 512), it registers 528063488 bytes exactly or around 503M of RAM on a 512M computer. Again, the deficit is almost exactly 1%.

I was also alarmed to find that when I attempted to count all forms of RAM (reserved and otherwise), the number didn't change in Bochs.

Anyway, the base question is: Am I just losing precision somewhere or is that 1% untouchable or is the memory map broken? I'm sorta worried because the manipulation of qwords is just a tad awkward...

If you need reference: here is the ASM for loading the e820 tables:

Code: Select all

xor ebx,ebx
mov es, bx
mov di, 0x4EC
ramloop:
mov eax,0x0000E820
mov edx,0x534D4150
mov ecx,20
add di,20
int 0x15

jc error
cmp ebx, 00000000h
je read
jmp ramloop

and the code I then use to translate and print it:

Code: Select all

struct mmap
   {
      long long base;
      long long length;
      int type;
   };   
   struct converter
   {
      int top;
      int bottom;
   };
struct mmap *testmap = (struct mmap *) 0x500;
   int i = 0;
   long long totalRAM = 0;
   for (i=0;i<10;i++)
   {
      if(testmap[i].type == 1) ;There was a type, thanks Pype.
         totalRAM += testmap[i].length; 
   }
   struct converter *displayableRAM;
   displayableRAM = &totalRAM;
   k_printf("Displayable RAM:%d + %d", 0, 13, displayableRAM[0].top, displayableRAM[0].bottom);

[Pype.Clicker]

Code: Select all

   if(testmap[i].type = 1)

what's that for a test ? i guess it's a typo: it should rather be

Code: Select all

   if (... == 1 )

[stonedzealot]

Yes, that was a typo, I actually had it set to if (... != 0) before I pasted it in there to test all the RAM, but I just accidentally overlooked that upon changing it.

[Slasher]

You are missing some bytes of memory cause if you check the base returned by bios on each call with the previous call, it does not match.
I.e
previous base + previous length is not equal to current base, which it should.
So what I did was create a table in memory with all entries for type 1 memory where I store the base and length per entry. This is done in the second stage loader
Then in the C memory code i go through this table and add up all the lengths to get memory_total.
Then i divide memory_total by 1,048,576 (1 Megabyte). the result of this division multiplied by 1048576 will give the right total memory.

[Neo]

Anyway, the base question is: Am I just losing precision somewhere or is that 1% untouchable or is the memory map broken?

The "standard memory ranges" are not reported by the int15-e820 interrupt. That is the most probable reason you seem to be 1% off. The standard memory range usually is from address 0xA_0000 - 0xE_0000.
HTH