flat assembler
Message board for the users of flat assembler.

Index > OS Construction > How to find existence of memory?

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
milind



Joined: 15 Feb 2004
Posts: 33
milind
How can we find if a physical memory exits in a particular location or not. I mean can we get a memory map of the available memory addresses or do we have to test each and every byte by read write to test its presence??
Post 02 Mar 2004, 11:15
View user's profile Send private message Visit poster's website Yahoo Messenger Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
Post 03 Mar 2004, 16:00
View user's profile Send private message Visit poster's website Reply with quote
anton



Joined: 08 Apr 2004
Posts: 17
Location: Moscow, Russia
anton
You may get memory map using PNP BIOS (It presented as system device).
Post 13 May 2004, 13:31
View user's profile Send private message Reply with quote
Gomer73



Joined: 29 Nov 2003
Posts: 151
Gomer73
Looked at the program to probe for memory.
Since it was mainly in asm, it is too bad he didn't make it all in asm, would have been easier to understand.
Post 13 May 2004, 18:28
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
does't really matter if there's asm or C there - you should directly probe the memory, it's not very healthy if you accidentally hit memory mapped devices.
Post 13 May 2004, 21:19
View user's profile Send private message Visit poster's website Reply with quote
Gomer73



Joined: 29 Nov 2003
Posts: 151
Gomer73
Can you give some examples?
Are you talking about stuff that would be above the 1meg area?
Otherwise you could just start at 1 meg and have no worries.
Post 13 May 2004, 22:08
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Yes, the 'interesting' memory-mapped stuff will be way above 1meg. I guess it depends on BIOS setting - if you have the bios "pnp resources" set to "pnp os" (the names of both these items may vary), then resources might not be assigned to PCI devices by the BIOS. But as we all should know, especially older BIOSes did things "their own way".

I might just be talking out my a$$, but I think the best thing is to test for extensions, and eventually fall back to the old "max 64meg" way of getting amount of memory in the system - if the BIOS is old enough to not detect more memory than that, there's a very good chance the system doesn't have more memory. For the very few borderline cases, you could always supply some argument to your kernel to specify the real amount of memory.

Better keep it safe for the majory of systems, and require the people with "weird hardware" to do some extra fiddling - they should be used to it anyway Smile
Post 14 May 2004, 01:23
View user's profile Send private message Visit poster's website Reply with quote
Gomer73



Joined: 29 Nov 2003
Posts: 151
Gomer73
I see what you mean, here is a memory map of my computer, first number is decimal, second number is hex.

Base: 0, 0
Size: 654,336, 9FC00
Type: 1, 1

Base: 654,336, 9FC00
Size: 1,024, 400
Type: 2, 2

Base: 983,040, F0000
Size: 65,536, 10000
Type: 2, 2

Base: 1,048,576, 100000
Size: 133,156,864, 7EFD000
Type: 1, 1

Base: 134,205,440, 7FFD000
Size: 8,192, 2000
Type: 3, 3

Base: 134,213,632, 7FFF000
Size: 4,096, 1000
Type: 4, 4

Base: 4,294,901,760, FFFF0000
Size: 65,536, 10000
Type: 2, 2

The last two sections of memory would be not good if I overwrote them.
It is interesting that it doesn't deal with my video memory which is at E2000000, video card doesn't use system memory, but still.
Here's the code in case somebody else wants to check out the memory in their system, board won't let me attach it as a file.

org 100h
use16
mov ebx,0
mem_loop:
mov eax,0xe820
mov edx,534d4150h
mov ecx,200h
mov edi,the_data
push cs
pop es
int 15h
jc done
push ebx
call print_cs
db "Base: ",0
mov eax,[the_data]
push eax
call print_dec
call print_cs
db ", ",0
pop eax
call print_hex_big
call print_cs
db 13,10,"Size: ",0
mov eax,[the_data+8]
push eax
call print_dec
call print_cs
db ", ",0
pop eax
call print_hex_big
call print_cs
db 13,10,"Type: ",0
mov eax,[the_data+16]
push eax
call print_dec
call print_cs
db ", ",0
pop eax
call print_hex_big
call print_cs
db 13,10,13,10,0
pop ebx
cmp ebx,0
jne mem_loop
done:
call print_cs
db "All finished",13,10,0
int 20h

print_dec_nc:
push word 0
mov ecx,1000
jmp print_dec.loop
print_dec:
push word 0
.zero_loop:
mov ecx,3
.loop:
xor edx,edx
mov ebx,10
div ebx
or dl,30h
push dx
or eax,eax
jz .end_numb
loop .loop
push word ','
jmp .zero_loop
.end_numb:
pop dx
or dx,dx
jz .end
mov ah,2
int 21h
jmp .end_numb
.end:
ret

print_hex:
push ax
xor eax,eax
pop ax
print_hex_big:
push word 0
.loop:
push eax
and al,0fh
cmp al,10
cmc
adc al,30h
daa
mov bl,al
pop eax
push bx
shr eax,4
or eax,eax
jz print_dec.end_numb
jmp .loop

print_cs:
pop si
push ds
push cs
pop ds
.loop:
lodsb
or al,al
jz .end
mov ah,2
mov dl,al
int 21h
jmp .loop
.end:
pop ds
jmp si
align 16
the_data:
Post 14 May 2004, 23:55
View user's profile Send private message Reply with quote
bogdanontanu



Joined: 07 Jan 2004
Posts: 403
Location: Sol. Earth. Europe. Romania. Bucuresti
bogdanontanu
Thanks, pretty Interesting for SolOS Wink
Post 15 May 2004, 12:56
View user's profile Send private message Visit poster's website Reply with quote
Gomer73



Joined: 29 Nov 2003
Posts: 151
Gomer73
anton wrote:
You may get memory map using PNP BIOS (It presented as system device).


For Anton, can you tell me how to get a memory map using PNP BIOS in code? Not too sure how to do it.
Post 15 Jun 2004, 02:56
View user's profile Send private message Reply with quote
Gomer73



Joined: 29 Nov 2003
Posts: 151
Gomer73
OK, anybody then, does anybody know how to get a memory map using PNP BIOS?
Post 16 Jun 2004, 15:29
View user's profile Send private message Reply with quote
Geek



Joined: 01 Jun 2005
Posts: 26
Geek
It might be more efficiant to use a process of elimination.

for (a very simple) example:

You have the base address of VRAM,
You have the address location of your OS,
You also have a basic idea of the 1st. 1MB,
And any other devices that may need addresses,

You may be able to piece together a vague memory map
that you can go by.

Cool Cool Cool

_________________
Death is not the opposite of life, rather, it is the absence of it.
Post 07 Jun 2005, 14:01
View user's profile Send private message Reply with quote
Scanner



Joined: 14 May 2005
Posts: 7
Scanner
Easy

Days of 64MB memory modules are over. So scan for memory in 64MB increments by writing to a location, and then reading from it for the value you wrote. As soon as the value you read does not match the value you wrote, the last location written to is the max memory you can access.

I think that is a fair test.
Post 07 Jun 2005, 19:20
View user's profile Send private message Yahoo Messenger Reply with quote
Endre



Joined: 29 Dec 2003
Posts: 212
Location: Budapest, Hungary
Endre
Scanner wrote:
Easy

Days of 64MB memory modules are over. So scan for memory in 64MB increments by writing to a location, and then reading from it for the value you wrote. As soon as the value you read does not match the value you wrote, the last location written to is the max memory you can access.

I think that is a fair test.
I don't think it is always a good idea. It's because when booting your bios may already have mapped any of your devices (not speaking about the BIOS itself) into the memory. Thus if you just write the memory in such crazy way you may damage the hardware. As mentioned before int 0xe820 does generally the job for you. It returns a list containing usable and unusable memory ranges. Unusable ranges must not be written by your programs.
Post 08 Jun 2005, 05:28
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
I agree with Endre - scanning for memory in the way suggested by Scanner is a bad idea.
Post 08 Jun 2005, 12:24
View user's profile Send private message Visit poster's website Reply with quote
THEWizardGenius



Joined: 14 Jan 2005
Posts: 382
Location: California, USA
THEWizardGenius
Simple: If your computer starts up, you have at least 1 byte of memory installed. If no memory exists, it won't startup properly. Very Happy
Post 17 Jun 2005, 04:27
View user's profile Send private message AIM Address Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
isn't there just some BIOS call which returns amount of memory in Kb? can't remember number, maybe some int 15h
Post 17 Jun 2005, 08:52
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
THEWizardGenius



Joined: 14 Jan 2005
Posts: 382
Location: California, USA
THEWizardGenius
INT 12h does this, however it only returns the base memory- that is,
MIN (640, total_memory). In other words, if you have more than 640k (and I bet you do!) it returns 640k. INT 15h may have something that returns other things, however, here's how you find total memory size:
CMOS! However, the maximum you'll find is 66175K.

It should be stored in CMOS in bytes 15h-18h. Simply add bytes 15h and 16h (a word value equal to the base memory size, which once again is usually 640k. 15h is the LSB, 16h is the MSB.) to bytes 17h and 18h (a word value equal to the base memory subtracted from the total installed memory. 17h is the LSB and 18h is the MSB). The result will be total memory installed, in KB. If you have more than 66175K or so, I have no idea how to find that.

Besides, I bet if you try to read/write to memory that isn't there (for example, if you try to read the byte at 0FFFFFFFFh and you have less than 4G memory installed) then an error will occur, in the CPU or somewhere else. But I dunno, never tried this.
Post 17 Jun 2005, 16:47
View user's profile Send private message AIM Address Reply with quote
UCM



Joined: 25 Feb 2005
Posts: 285
Location: Canada
UCM
I'm pretty sure, that if you try to write to nonexistent memory, the CPU won't complain, just that if you try to retrieve it again, you'll either get 0 or an error.

_________________
This calls for... Ultra CRUNCHY Man!
Ta da!! *crunch*
Post 18 Jun 2005, 15:39
View user's profile Send private message Reply with quote
smiddy



Joined: 31 Oct 2004
Posts: 559
smiddy
Here is a screen capture of how I do memory detection:

Code:

smiddy's OS (C) 2004, 2005. All Rights Reserved.
Version 1.00.00.000000AB
CPU: CPUID Instruction: GenuineIntel Pentium III (Coppermine)
A20 Gate: Init KBC: 1st Test: A20 memory address line enabled...
E820: 1,073,741,824 bytes.
E801: 1,073,741,824 bytes.
88xx: 16,777,216 bytes.
CMOS: 67,108,864 bytes.
Entering UnReal Mode...
Probe: 1,073,741,824 bytes.
Mapping Memory 1: 1,073,741,824 installed: E820:
Mapping Memory 2: Bitmap Initialized at 14MB: 1,056,964,608 bytes free for use.
    


I use INT 15h AX=E820, then AX=E801, then AH=88, followed by CMOS and finally I probe the memory at the top of each 1 MB chunk.

UCM, my experience is that you can write to non-existent memory, but you won't retrieve what you wrote. The address lines are available, but they aren't connected to anything.

TheWizardGenius, up around 080000000h (2 GB) you run into areas where PCI devices place buffers. In your example, 0FFFFFFFFh, if you back that off to 0FFFFFFF0h, and jump to that location, you'll reboot the machine because BIOS is up there. I don't know all the specifics but I imagine too, that you can get the BIOS date starting at 0FFFFFFF5h...check your and see. You can read all day at every location...you just have to watch where you write to, PCI information is up near 0FC000000h too, with all the configuration registers etcetera.
Post 19 Jun 2005, 04:07
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.