Direct Memory Probing

[HOS]

Hi!

I have my stage2 bootloader operating in unreal mode jump to my protected mode kernel. before i make the jump, however, i would like to determine how many megabytes of RAM are present. i wrote the following slice of code:

Code: Select all

checkram:
???mov???dx, 3??????;# of megabytes - assume 3 megs exist
???mov???esi, 0x3FFFFC???;top 4 bytes of the fourth megabyte of ram
???xor???ax, ax
???mov???ds, ax
checkram_loop:
???mov???ebx, [ds:esi]
???mov???dword [ds:esi], "TEST"
???mov???eax, [ds:esi]
???mov???[ds:esi], ebx???;restore mem just in case
???cmp???eax, "TEST"
???jnz???checkram_done

???add???esi, 0x100000???;go to next megabyte
???inc???dx
???jmp???checkram_loop
checkram_done:?????????;dx holds # of megabytes
???ret

on my 256mb real machine, dx is returned with 0xF0 (240), on my vmware emulated machine (set up with 256mb also) dx is returned with 0x0101 (257)

i am wondering if this method of finding out how much memory exists will work correctly, and if it is possible i would be running into any reserved areas or anything... also, is 0x0FFFFC a good offset into the megabyte to use to probe?

Thanks.

[Pype.Clicker]

by any chance, does the "256Mb" of VMWARE consist of "extended" memory (i.e. in addition to the first 1MB of ram available as conventionnal RAM ?)

as any other 'direct probing' method, it has a risk to probe memory-mapped I/O PCI regions (or vesa frame buffer, etc). It may be used as a "fallback" default methods, but you should consider using BIOS services if available (see the FAQ for details)

[RuneOfFire]

I used to use the BIOS services, but on some computers they will give you incorrect values. I tested them on Bochs and two 386 laptops with 4 MB of RAM and got different values for each. One returned 4, one 3, and the other one returned 5 (don't recall which ones).

Edit: I know it wasn't just the memory with the laptops, I switched the memory in them and tested it again. Same results.

[Tim]

The BIOS is the only part of the system which knows the layout of RAM, so you must trust it. You're effectively dealing directly with the motherboard hardware, so you must go through the BIOS (unless you want to write board-specific drivers). Direct probing of memory is like detecting devices by poking bits at I/O ports.

[HOS]

ok, but doesn't the BIOS have a 64mb limit? is there a function that returns RAM sizes for more than 64mb?

also, is there any guarantee that the VESA LFB address is always above the amount of physical RAM? for example, on my computer the LFB base address comes out to be 0xD0000000, obviously more that the amount of RAM i have...

thanks again

[Tim]

ok, but doesn't the BIOS have a 64mb limit?

No.

is there a function that returns RAM sizes for more than 64mb?

Yes, it's AX = E820h, and it's mentioned in the FAQ at this site.

also, is there any guarantee that the VESA LFB address is always above the amount of physical RAM? for example, on my computer the LFB base address comes out to be 0xD0000000, obviously more that the amount of RAM i have...

No! Not at all. The location of the video card's memory is available from the relevant PCI register for the video card, which is where the VESA BIOS will get it from.

[Curufir]

is there a function that returns RAM sizes for more than 64mb?

Another one is int 15, e801 which returns the information in a form that means you can hold of interpreting memory maps for a while longer.

Linux uses e820 if available, then e801 if available, then falls back to the old fashioned 88 (This is the one that's limited to 64mb).

AFAIK Windows uses almost exclusively uses e820 and e801.

I agree with Tim that direct probing is not a very effective method of determining memory size.