The Place to Start for Operating System Developers
http://f.osdev.org/
All of the information needed can be found here. ES:DI is the pointer to the entry data structure; ECX is the sizeof(entryDataStructure). EDX must be 0x534D4150. EBX must be 0. The BIOS INT writes to ES:DI - so you define where to store the information at.Still... I have no idea how it works or even where this map it creates is located.
neon wrote:Hello,
All of the information needed can be found here. ES:DI is the pointer to the entry data structure; ECX is the sizeof(entryDataStructure). EDX must be 0x534D4150. EBX must be 0. The BIOS INT writes to ES:DI - so you define where to store the information at.
On first call, EBX should be 0 for first memory map entry. The call sets EBX to another value. Call the interrupt again with the new value to get the 2nd entry. Continue until return EBX is 0 again.
Code: Select all
proberam:
xor ebx, ebx ; ebx must be 0 to start
xor bp, bp ; keep an entry count in bp
mov edx, 0x0534D4150 ; Place "SMAP" into edx
mov eax, 0xe820
mov [es:di + 20], dword 1 ; force a valid ACPI 3.X entry
mov ecx, 24 ; ask for 24 bytes
int 0x15
jc short .failed ; carry set on first call means "unsupported function"
mov edx, 0x0534D4150 ; Some BIOSes apparently trash this register?
cmp eax, edx ; on success, eax must have been reset to "SMAP"
jne short .failed
test ebx, ebx ; ebx = 0 implies list is only 1 entry long (worthless)
je short .failed
jmp short .jmpin
.e820lp:
mov eax, 0xe820 ; eax, ecx get trashed on every int 0x15 call
mov [es:di + 20], dword 1 ; force a valid ACPI 3.X entry
mov ecx, 24 ; ask for 24 bytes again
int 0x15
jc short .e820f ; carry set means "end of list already reached"
mov edx, 0x0534D4150 ; repair potentially trashed register
.jmpin:
jcxz .skipent ; skip any 0 length entries
cmp cl, 20 ; got a 24 byte ACPI 3.X response?
jbe short .notext
test byte [es:di + 20], 1 ; if so: is the "ignore this data" bit clear?
je short .skipent
.notext:
mov ecx, [es:di + 8] ; get lower dword of memory region length
or ecx, [es:di + 12] ; "or" it with upper dword to test for zero
jz .skipent ; if length qword is 0, skip entry
inc bp ; got a good entry: ++count, move to next storage spot
add di, 24
.skipent:
test ebx, ebx ; if ebx resets to 0, list is complete
jne short .e820lp
.e820f:
mov [mmap_ent], bp ; store the entry count
mov eax, [es:di]
mov [mmap], eax
mov si, [mmap]
clc ; there is "jc" on end of list to this point, so the carry must be cleared
ret
.failed:
stc ; "function unsupported" error exit
ret
mmap_ent times 20 db 0
mmap times 20 db 0
This might explain the confusion. ES:DI are used to refer to a segment and an offset within that segment in real mode. Please read up on real mode addressing.What I don't understand is how es:di works.
Thanks for the link. That cleared up the whole ES:DI thing. Or at least what it does.neon wrote:This might explain the confusion. ES:DI are used to refer to a segment and an offset within that segment in real mode. Please read up on real mode addressing.What I don't understand is how es:di works.
Note that this interrupt returns a data structure. It does not return a value so am uncertain where you have gotten "29156" from.
How do I point ES:DI at the destination buffer (Just create a variable and copy it into that variable?) and why would I do that first? I thought I would do that last.For the first call to the function, point ES:DI at the destination buffer for the list. Clear EBX. Set EDX to the magic number 0x534D4150. Set EAX to 0xE820 (note that the upper word of EAX should be set to 0). Set ECX to 24. Do an INT 0x15.
Code: Select all
mov eax, [es:di]
mov [mmap], eax
Code: Select all
mov [mmap_ent], bp ; store the entry count
mov di, 01h
mov si, [es:di]
what's the physical location of your buffer?How do I point ES:DI at the destination buffer (Just create a variable and copy it into that variable?) and why would I do that first? I thought I would do that last.
That table could be a little misleading, in that the size of the EBDA is not fixed. For example the EBDA could be 1 KiB (and the RAM from 0x00080000 to 0x0009FBFF may be usable); but the EBDA could also be 16 KiB (and only the RAM from 0x00080000 to 0x0009BFFF might be usable), or the EBDA could be any other size that is a multiple of 1 KiB (e.g. 1 KiB, 2 KiB, 3 KiB, ... ). Ancient software may have assumed that RAM up to 0x00080000 is usable and therefore (because backward compatibility is excessive on "PC compatible" computers) it's extremely unlikely that the EBDA will ever be more than 64 KiB, which means the RAM up to 0x0007FFFF is (almost) guaranteed to be free for your use.David2010 wrote:Also you said that I shouldn't test all the way to 0x0009FC00 but where should I stop testing at because "http://wiki.osdev.org/Memory_Map_%28x86%29#.22Low.22_memory_.28.3C_1_MiB.29" says I should stop testing for RAM at 0x0009FBFF.
In general, the method you're using to calculate "used memory" is complete bullshit. For an example, imagine you turn the computer on and the BIOS uses 100 KiB of "usable RAM" in this area during initialisation, then the BIOS stops using this area, then starts your boot loader. Your boot loader counts "non-zero bytes" and decides that most of that 100 KiB that the BIOS used is still in use, even though it's not. For some computers RAM is not filled with zeros during reset (and remembers what was there before the reset), so in this case you could determine that 600 KiB of RAM is being used when it isn't.David2010 wrote:Being as the OS itself is only a little over 1 KB large I find these results to be WAY off. :-/