Right, I understand the data segment will potentially change each time i run the program. When I dump the memory at this location it is filled with zeros. Preserving es did not make a difference, and I don't know how to implement the count you were talking about.
Are you doing this on a machine built after the Cold War?
haha, it is just a dos box that i am running the code on
That may be the problem. This int is used almost exclusively for OSes to get extended maps of what memory can and can't be used, something DOS has no reason to do. Therefore, it's not likely that the DOS Box coders would take the time to emulate something that DOS has no reason to use.
Edit: Get a VM(Bochs is a good free one), install DOS on it, then try again.
Last edited by User Name:; 06-18-2010 at 09:36 AM. Reason: I didn't provide a possible solution.
I reject that suggestion
I am going to try a few more things and post an update this afternoon.
Your problem (as User Name: has already pointed out) is that you are attempting something that is valid only in Real Mode. Not all BIOS calls are available in Protected Mode -- which if you're running DosBox I'm assuming that you are either on a Linux or Windows 32/64-bit box.
So, in a Protected Mode OS, these functions are most probably . . . . wait for it. . . . PROTECTED!!!
You're kinda missing the point. DOS Box and VMs emulate real mode(Most VMs also support protected and long, but that's usually not through emulation. Bochs is all emulation though.). VMs just emulate it more accurately. Like I said, DOS couldn't use more than 16mb; why would a real mode emulator for DOS emulate a BIOS call that can be used to gather info on on memory above the 4gb range?Your problem (as User Name: has already pointed out) is that you are attempting something that is valid only in Real Mode.
BIOS calls are completely lost in the transition to protected/long mode, without a DPMI(which most commonly, just switches to real, calls BIOS, and switches back.) It's this way for many reasons, two are: In real mode, interrupt handlers are determined by the IVT, in other modes you have what is called the IDT. And in real mode, there are no CPU exceptions, leaving ints 0-31 open for whatever you, the BIOS, or whatever wants to use them for, in other modes, 0-31 are reserved(by Intel specs) for exceptions.
Ya know, I've used DOS Box a lot. I've had serious problems in the past attempting to allow programs, that make serious PEAK and POKE calls to BIOS, work through it. Those programs (there were 3) would not work on Linux with DOS Box. Games, sure, games work great. To that end, I figured that these EXTENDED DOS functions would probably not work. Even in the games I've played that test for High level memory, I've seen the memory reporting completely wrong -- though I had configure DOSBox to use "himem.sys" and supposedly emulate those memory calls. Maybe I'm wrong. I don't think that DOSBox will allow the OP to access these memory functions since these are most often protected under the watchful eyes of the OS -- AND these memory calls are often pointless since the OS's memory manager already KNOWS how much memory there is and all the statistics for that memory.Originally Posted by User Name:
If the OP gets it working -- or you for that matter, then I'm wrong. I don't think I am right now, though.
I was agreeing with you, I was just explaining why you're right. The OS has nothing to do with ints called from inside DOS Box. "High level memory" for those games means 16mb, e820 reports 4gb+.
[sarcasm]I bet that was fun.[/sarcasm] Sounds hard...though I had configure DOSBox to use "himem.sys" and supposedly emulate those memory calls.
This can be done using a struct. Now I just need to figure out a way to make a struct in C and implement it into my .asm function. Any ideas?
Yes, struct would be helpful in interpreting the memmap, but first, you need the memmap. Did you ever get it to work in DOS box?
Sure didn't, but I need to. I have been advised to use a struct by colleagues who have completed this task. I just don't know how to though.... :/
structs are simple, this site has a fine tut on them. Ask specific questions if you don't understand something. Your function to get a memmap is fine as far as I can tell, all you need to do is keep a count of how many reads you do. I suggest bp, you don't need a stack frame. Just make sure to save and restore it. If real mode calling conventions are similar to protected mode conventions, you return the return value in ax.
The struct is useful in reading the memmap, it allows you to address the fields directly, with a name.
Linux Kernel log output about the e820 memory map:
Code:[This the beginning of the whole log] Jun 16 23:12:56 server kernel: imklog 4.2.0, log source = /proc/kmsg started. Jun 16 23:12:56 server kernel: [ 0.000000] Initializing cgroup subsys cpuset Jun 16 23:12:56 server kernel: [ 0.000000] Initializing cgroup subsys cpu Jun 16 23:12:56 server kernel: [ 0.000000] Linux version 2.6.32-22-generic (buildd@palmer) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #36-Ubuntu SMP Thu Jun 3 22:02:19 UTC 2010 (Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2) Jun 16 23:12:56 server kernel: [ 0.000000] KERNEL supported cpus: Jun 16 23:12:56 server kernel: [ 0.000000] Intel GenuineIntel Jun 16 23:12:56 server kernel: [ 0.000000] AMD AuthenticAMD Jun 16 23:12:56 server kernel: [ 0.000000] NSC Geode by NSC Jun 16 23:12:56 server kernel: [ 0.000000] Cyrix CyrixInstead Jun 16 23:12:56 server kernel: [ 0.000000] Centaur CentaurHauls Jun 16 23:12:56 server kernel: [ 0.000000] Transmeta GenuineTMx86 Jun 16 23:12:56 server kernel: [ 0.000000] Transmeta TransmetaCPU Jun 16 23:12:56 server kernel: [ 0.000000] UMC UMC UMC UMC Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-provided physical RAM map: Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-e820: 00000000000ce000 - 00000000000d0000 (reserved) Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-e820: 0000000000100000 - 000000003f6f0000 (usable) Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-e820: 000000003f6f0000 - 000000003f6fa000 (ACPI data) Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-e820: 000000003f6fa000 - 000000003f700000 (ACPI NVS) Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-e820: 000000003f700000 - 0000000040000000 (reserved) Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved) Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) Jun 16 23:12:56 server kernel: [ 0.000000] BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved) Jun 16 23:12:56 server kernel: [ 0.000000] DMI present. [Lots more here...]
So now my code will place the memory map in memory at a segment offset by 500. But instead of doing this i want to make a structure in C, and fill the structure with the values generated by the memory map function I am running in .asm. I am new to structures so this is difficult for me. I am trying to define the structure in C like this:
and in assembly i am changing the di = 500h to this:Code:struct map { int baseaddress; int length; DWORD type; } my_map; struct map *p = &my_map;
than i want to increase the pointer to the next entry as needed to fill the struct properly.Code:mov di, &my_map ;500h ;point this to structure
clearly what i have does not work. can you provide any suggestions?
