using int 15h to detect memory

[bradd]

Hey guys, I'm using int 15h, ax = 0xe820 to detect memory.. here's my code:

Code: Select all

detect_mem: ; 0x7e0:0 is dword # of entries, first entry starts at 0x7e0:4
  mov eax, 0x7e0
  mov gs, eax
  mov es, eax
  mov [gs:0], dword 0
.loop:
  mov eax, [gs:0]
  mov ebx, 20
  mul bx
  add ax, 4
  mov di, ax
  mov ebx, [gs:0]
  mov edx, 0x534d4150
  mov eax, 0x0000e820
  int 0x15
  jc .error

  cmp ebx, 0
  je .done

  mov [gs:0], ebx
  jmp .loop

.error:
  mov ax, -1
  ret

.done:
  mov ax, 0 
  ret

Now I parse the table in my C code which is running in protected mode.. I get 7 entries (at dword 0x7e00), but only
the first 3 contain vailid data.. My results are:

[pre]
Base 0 Length 654336 Available
Base 654336 Length 1024 Reserved
Base 1048576 Length 32505856 Available
(the next 4 are Base 0 Length 0)
[/pre]
(I have 32mb in my test system)
My questions:
why are the last 4 entries empty?
how many entries can I put at 0x7e04 (at 20 bytes each)
(I was hoping this little pgm would tell me, but it only reports the above 3 areas..)

[Pype.Clicker]

i'm not exactly an 'int 15h guru', but i don't see anything that looks like an array index in your ASM code. You're always accessing GS:0, but never something like GS:<some_counter>, so i hardly see how you can have the array filled ...

[bradd]

i'm not exactly an 'int 15h guru', but i don't see anything that looks like an array index in your ASM code. You're always accessing GS:0, but never something like GS:<some_counter>, so i hardly see how you can have the array filled ...

each iteration I multiply 20 (the size of an entry) by what index to read, add 4 (the size of the dword holding the # of entires) then mov that value to di then [es:di] indexes the next buffer..
I'm pretty bad at asm, I'm sure this code can be optimized alot.. but for now..

[Pype.Clicker]

doh .. my ASM is more rusty than i thought.
I would not be surprized if your BIOS had kept those for something that isn't present on your hardware (AGP cards, for instance) and always offer a 7-slots table, whatever the table contains...

As 0-typed slots should be treated as 'reserved', i don't see anything that transgresses the interrupt list...

[ASHLEY4]

" The BIOS can use the AddressRangeReserved address range type to block out various addresses as "not suitable" for use by a programmable device.

Some of the reasons a BIOS would do this are:

The address range contains system ROM.
The address range contains RAM in use by the ROM.
The address range is in use by a memory mapped system device.
The address range is for whatever reason are unsuitable for a standard device to use as a device memory space."

ASHLEY4.