OSDev.org

Marcio wrote: An off-topic (maybe silly) question: can C code be run in real mode?
If yes, is this code for checking the A20 gate status correct?

Of course C code can be compiled to real mode machine code, and I suspect that this has been done for a very long time.. ;D

The mechanism you are using in your code should work, however you can't use 32bit pointers from there. AFAIK, gcc won't be able to handle segments at all, so you have to change the data segment manually to 0xFFFF and back. Maybe this will be easier in ASM anyway.

cheers Joe

@Kemp
Yeah, I must've confused some concepts ;D

[hr]
@JoeKayzA

(...)The mechanism you are using in your code should work, however you can't use 32bit pointers from there. (...)

That's what I really meant to ask: if there were some constraints to the code. Sorry if I wasn't explicit

[hr]
Another question; Multiboot specification says the following about each memory region info (size/structure pairs) in the memory map:

(...) type is the variety of address range represented, where a value of 1 indicates available RAM, and all other values currently indicated a reserved area. (...)

Do you guys know where to find the meaning of all types? (in my pc I get type 0x1, 0x2, 0x3 and 0x4)

Last question on this post; I'm a little confused when trying to interpret the memory map and memory sizes passed by GRUB. Here's how:

memory map (only memory regions with type 0x1 listed here):
- base_addr = 0x0, length = 0x9FC00
- base_addr = 0x100000, length = 0x1FEF0000

memory size:
base = 639 KB
extended = 523200 KB

In the memory map, the first one is the base memory: 0x9FC00 = 639 KB, so it's all ok.
The second is the extended memory: 0x1FEF0000 - 0x100000 = 0x1FDF0000 = 522176 KB
But this one is different from the extended memory size. Now if I add 1024 KB to it: 522176 + 1024 = 523200 KB, it will equal the extended memory size..

This shouldn't happen, right?

http://www.osdev.org/osfaq2/index.php/H ... f%20RAM%3F

Values for System Memory Map address type:
01h memory, available to OS
02h reserved, not available (e.g. system ROM, memory-mapped device)
03h ACPI Reclaim Memory (useable by OS after reading ACPI tables)
04h ACPI NVS Memory (OS is required to save this memory between NVS sessions)

Please check the Wiki first.

Hi,

Marcio wrote:Last question on this post; I'm a little confused when trying to interpret the memory map and memory sizes passed by GRUB. Here's how:

memory map (only memory regions with type 0x1 listed here):
- base_addr = 0x0, length = 0x9FC00
- base_addr = 0x100000, length = 0x1FEF0000

memory size:
base = 639 KB
extended = 523200 KB

This would be:
-base_addr = 0x0, length = 0x9FC00 (0x00000000 to 0x0009FBFF = 639 KB)
-base_addr = 0x100000, length = 0x1FEF0000 (0x00100000 to 0x1FFEFFFF = 523200 KB)

Or to be more specific, you'd have:

0x00000000 to 0x0009FBFF = 639 KB of usable RAM
0x0009FC00 to 0x0009FFFF = 1 KB of EBDA (Extended BIOS Data Area)
0x000A0000 to 0x000BFFFF = 128 KB of video display memory
0x000C0000 to 0x000FFFFF = 256 KB that is reserved for ROM (BIOS, video ROM, etc)
0x00100000 to 0x1FFEFFFF = 523200 KB of usable RAM
0x1FFF0000 to 0x1FFFFFFF = 64 KB possibly NVRAM (can't tell without more info)

As you can see this adds up to exactly 512 MB, and would be a fairly standard memory map for a computer that supports ACPI.

Marcio wrote:The second is the extended memory: 0x1FEF0000 - 0x100000 = 0x1FDF0000 = 522176 KB
But this one is different from the extended memory size. Now if I add 1024 KB to it: 522176 + 1024 = 523200 KB, it will equal the extended memory size..

This is where you're having trouble. The second RAM area is 0x1FEF0000 bytes, not 0x1FEF0000 - 0x100000 = 0x1FDF0000 bytes.


Cheers,

Brendan

@AR
I really don't like when people ask without searching first, and I did it this time... I'm so sorry about that. Thanks anyway.

[hr]
@Brendan
Thanks Brendan, now I get it.