Ram größe festellen ?

Hi Leute !

LordHoto und Ich verwenden NASM und Turboc für unser OS,
leider geht mein Ram größe Rausfinder nich

Hier mal der Code

UINT* pStartMem = (UINT*)0x1FFFFC;    //Start at top of 1mb (2mb - 4bytes) as we already know we must have 1mb
    const UINT uiMBOfMem = 0x100000;      //Amount of bytes to make up 1mb, define as const as this doesn't change

    const UINT uiTestDWORD = 0x506E6978;  //Test DWORD to write = Pnix, for Phoenix, define as const for speed up
    UINT uiTotalMemory = 0x100000;        //We know we have 1mb already

    //Write to the Highest DWORD in each megabyte to test for amount of memory available
    do
    {
        //Calculate next memory address    
        pStartMem = (UINT*)(uiMBOfMem + (UINT)pStartMem);

        //Write the test DWORD to top of this 1Mb of Memory
        *pStartMem = uiTestDWORD;

        //Calculate the Amount of Physical Memory now available 
        uiTotalMemory += uiMBOfMem;

    }while(*pStartMem == uiTestDWORD);

    //Store the result from the memory test in the Total Amount of Pages
    //Shift amount of mem left by 12 to give amount of pages
    //uiTotalPages = uiTotalMemory >> 12;

    printf("TotalMemory (RAM) is : %u",uiTotalMemory);

Ach ja, wir haben ne eigene printf !

Thx

cya

Nobuo T

Hi.

Mal ne ganz doofe Frage: Warum nhmt ihr nicht einfach das BIOS, um die Groesse des RAM zu bestimmen? Im RM tut euch das selbige via int 15h (ah=88h oder ax=E801) noch zuverlaessig erzaehlen tun.

Falls ihr aber wirklich an eurem Code haengt:
1. Das ganze in ASM waer net schlecht (disassemblierung des Compilierten codes)
2. Was funktioniert an dem code nicht?

Was nich geht ?
Der steckt in ner Endlos schleife !

Warum kein BIOS ?
Weil wir vielleicht PMode nutzen wollen ?

cya

Nobuo T

Original erstellt von <ghostbustor>:
Warum kein BIOS ?
Weil wir vielleicht PMode nutzen wollen ?

Das schliesst sich doch gegenseitig nicht aus. AFAIK startet so ein PC doch immernoch im RM. Da kann man dann ungestoert mit dem BIOS rumspielen, bevor man in den PM wechselt. (Sonst gibt es auch immernoch den V86)
Ich denke auch nicht, dass sich die Menge des zur Verfuegung stehenden Speichers veraendert, waehrend der PC noch in Betrieb ist... Auch nicht, wenn ihr vom RM in den PM wechselt.
Sehr interessant ist da auch die Funktion E820h - die wird angeblich sogar von Windows verwendet...

BTW: Was ist mit dem ASM code...?

TriPhoenix

Ne nette alternative: Macht das OS Multiboot-kompatibel, damit GRUB es laden kann. Der gibt die Speichergröße biem Startup mit.

Ansonsten schaut euch mal http://my.execpc.com/~geezer/osd/ram/index.htm#size

an, dort sind ein paar Mechanismen genannt. Eine der Dinge die genannt werden:
"You should not attempt to 'probe' memory size. It's difficult to write robust code that will do this correctly and safely on all PCs."

Ich persönlich halte Memory Probing auch imemr für brutal, vor allem wiel man unbewisst plötzlich mal in mapped memory eines Gerätes reintreten könnte. Die BIOS calls zum init des OS, die CMOS Area oder GRUB sind schon vernünftige Lösungen.

[ Dieser Beitrag wurde am 23.04.2003 um 00:34 Uhr von TriPhoenix editiert. ]

das mit dem grub aber nicht :p

TriPhoenix

Original erstellt von <:EW>:
das mit dem grub aber nicht :p

Was ist mit dem Grub. Steht da nicht?

Von der Seite:

The GRUB bootloader will determine memory size and layout for you. Use GRUB and you don't have to worry about probing, 16-bit BIOS calls, or BIOS bugs.

ich finde es dumm wenn man sich eine unnötige abhängigkeit hat. warum soll ein betriebssystem an einen bestimmten bootloader angewiesen sein? aber grub ist doch open source da kann man sich doch einfach das stück code für die memory erkennung rausholen

TriPhoenix

Original erstellt von <:EW>:
ich finde es dumm wenn man sich eine unnötige abhängigkeit hat. warum soll ein betriebssystem an einen bestimmten bootloader angewiesen sein? aber grub ist doch open source da kann man sich doch einfach das stück code für die memory erkennung rausholen

Bei GRUB hat das shcon seinen Sinn. Denn GRUB ist ein Multiboot-Loader und man bindet sich nicht an einen Bootloader, man implementiert nur den Multiboot-Standard. Damit ist das OS dann Problemlos in jeden Multiboot-Standard-Bootloader problemlos einbindbar und ich perösnlich finde es recht gut, wenn ich mit 2 Zeilen in einer Textdatei einen neuen Kernel einbinden kann.

Scheiss auf Grub !

Eigener Bootloader rult

TriPhoenix

Original erstellt von <ghostbustor>:
**Scheiss auf Grub !

Eigener Bootloader rult :D**

DAS ist Ansichtssache Ich hab mich einige Zeitlang damit rumgeqüalt nen eigenen Bootloader zu schreiben. Mein Fazit: Diskettenlaufwerk suxx. Variable Sektorenzahl die man brutal ausprobieren muss. Eventuelle Dateisysteme parsen (wenn mans später richtig haben will). A20 aktivieren (mit je nach geschmack 3-21 Methoden). Das sind Sachen auf die ich verzichten kann GRUB macht das schon fein für mich, so kann ich mich auf die interessanten Sachen an ienem OS konzentrieren