Autor Thema: Wie die BDA auslesen  (Gelesen 8914 mal)

OSLiga

  • Beiträge: 12
    • Profil anzeigen
Gespeichert
« am: 14. April 2014, 15:26 »
Hallo,
ich habe möchte die BDA (BIOS Data Area) auslesen, weil ich in meinem kleinen OS nun eine Funktion programmieren will, mit der man Informationen über den PC sehen kann. Das ganze möchte ich mit C++ machen, unter Assembler gibt es ja CPUID.
Aber wie kann man denn die ganzen Adressen vom BIOS ansprechen um an die Information zu kommen?
Meine Idee ist mit *p auf die Adresse zu zeigen.

LG
OS in Arbeit

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 14. April 2014, 15:49 »
Hi,

Aber wie kann man denn die ganzen Adressen vom BIOS ansprechen um an die Information zu kommen?
Meine Idee ist mit *p auf die Adresse zu zeigen.

Genau das ist der Ansatz. Ich nehme an, dass du im Protected Mode bist. Dann kannst du beispielsweise die Größe des konventionellen Speichers, die sich an Offset 0x13 befindet, wie folgt auslesen:

char *bda;
unsigned short lowMem;

bda = (char *)0x400;
lowMem = *(unsigned short *)(bda + 0x13);

Beachte, dass ich da den Zeiger nach unsigned short * caste, bevor ich ihn dereferenziere, weil der Wert als WORD, also 2 Bytes, abgespeichert ist. Manche Sachen sind nur 1 Byte groß, die müsstest du dann nicht casten (bzw. auf unsigned char *). Das ganze kannst du natürlich nach deinen Vorstellungen von gutem Codestil auch anders schreiben.

Du klingst so, als hättest du eine Auflistung der Sachen, die man aus der BDA rauskriegt bereits gefunden. Ansonsten gibt es hier noch eine Liste, siehe auch Weblinks unten.

Das ganze möchte ich mit C++ machen, unter Assembler gibt es ja CPUID.
CPUID gibt übrigens nur Informationen über die CPU selbst aus (Hersteller, welche Features unterstützt werden, ...), nicht über die Hardware des PCs. Für das Auslesen unter C++ kannst du vielleicht sowas wie diesen Code verwenden: http://wiki.osdev.org/CPUID#Using_CPUID_from_GCC (dword = unsigned int). (Die BDA gibt übrigens auch nicht viel über die Hardware des PCs her. Auf dem PCI-Bus spielen sich heutzutage die interessanten Dinge ab.)
Dieser Text wird unter jedem Beitrag angezeigt.

OSLiga

  • Beiträge: 12
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 14. April 2014, 15:52 »
Ich hab jetzt mal eine blöde Frage:
Wo ist der Unterschied zwischen Real Mode und Protected Mode? Ich versteh das einfach nicht...
OS in Arbeit

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 14. April 2014, 16:09 »
Ah, kleiner Geschichtsunterricht. Früher gab es mal die 8086-CPU, die halt 16-Bit-Register hatte und mittels Segmentierung immerhin 1 MB Speicher ansprechen konnte. (Technische Details hier). Ein paar Jahre später waren 1 MB nicht mehr genug, und Intel musste sich was einfallen lassen. Ich überspringe einfach mal die 286er und mach bei der 386er-CPU weiter. Diese CPUs waren endlich 32-Bit-CPUs und konnten damit bis zu 4 GB Speicher verwalten. Aber eine komplett neue CPU würde ja heißen, dass die alten Programme darauf nicht mehr laufen, also hat Intel sich was einfallen lassen. Wenn eine 386er-CPU gestartet wird, läuft sie zunächst in einem Modus, der kompatibel zu den 8086-CPUs ist. Dieser Modus heißt Real Mode. Das heißt die CPU kann zwar auch nur 1 MB Speicher verwenden, aber das BIOS und DOS und der ganze andere alte Mist aus den 80ern läuft darauf problemlos. Modernere 32-Bit-Betriebssysteme, die gerne 4 GB RAM nutzen wollen, schalten die CPU in den Protected Mode um. Dann funktionieren einige Dinge anders (zum Beispiel, die Bytes, die die CPU-Befehle kodieren haben jetzt eine leicht andere Bedeutung), und die Software muss entsprechend dafür geschrieben bzw. kompiliert sein, damit sie auch funktioniert, beispielsweise sind Zeiger 32-Bit groß statt 16-Bit.

Wir bewerben hier immer den Protected Mode gegenüber dem Real Mode, weil 4 GB RAM besser als 1 MB sind, Paging mehr kann als die Real-Mode-Segmentierung, das BIOS fast gar nichts cooles kann, was man nicht auch selbst im Protected Mode hinkriegt, es moderne 32-Bit-Compiler gibt, und Multitasking ohne Kopfschmerzen möglich ist. Wenn du einen Multiboot-fähigen Bootloader wie GRUB verwendest, befindet sich dein Kernel übrigens bereits im Protected Mode.
Dieser Text wird unter jedem Beitrag angezeigt.

OSLiga

  • Beiträge: 12
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 14. April 2014, 16:12 »
Okay, wieder was gelernt. Danke für die Erklärung. Hab trotzdem noch ne Frage:
Beachte, dass ich da den Zeiger nach unsigned short * caste, bevor ich ihn dereferenziere, weil der Wert als WORD, also 2 Bytes, abgespeichert ist.
Was ist "casten"? Hab mir zwar das OS-Tutorial angeguckt, aber irgendwie komm ich mit den ganzen Begriffen nicht zurecht.
Und manche Adressen sind größer als 2 Bytes z.B. 0x49, was macht man dann mit der?
« Letzte Änderung: 14. April 2014, 16:20 von OSLiga »
OS in Arbeit

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 14. April 2014, 17:16 »
Ein Typecast ist eine Typüberschreibung. Wenn du in C (oder C++) eine Variable deklarierst, dann hat die einen Typ (sowas wie "int", "struct datensatz_s", "uint32_t" usw). Mit einem Typecast kannst du den Compiler zwingen, an einer Stelle einen anderen Typ zu benutzen, weil du es besser weißt. In den meisten Fällen ist es schlechter Stil oder eine elegante Abkürzung, aber bei hardwarenaher Programmierung kommt man daran nicht immer vorbei.

Ein "unsigned short" hat 2 Byte. Für den Eintrag an Adresse 0x49 müsstest du dir einen Typ (oder eine Struktur) mit 30 Byte definieren, auf die du dann casten kannst, also etwa in der Art:
struct vinfo_s {
  unsigned char mode;
  unsigned short cols;
  unsigned short pagesize;
  ... /* hier der rest */
} __attribute__((packed));

Es ist übrigens hilfreich, wenn du C einigermaßen beherrschst, auch wenn du C++ verwenden möchtest.

OSLiga

  • Beiträge: 12
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 14. April 2014, 17:19 »
Okay, ich glaub ich muss noch mal Begriffe lernen  :-D
Stimmt C lernen für C++ *facepalm*, ich lern erstmal richtig viel  :-D
Aber Danke, viele hätten jetzt geschrieben: "Lern erstmal programmieren"  :-)
OS in Arbeit

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 14. April 2014, 19:41 »
Ein "unsigned short" hat 2 Byte.
Ein unsigned short ist ein Datentyp, der Zahlen von 0 bis mindestens 2^16-1, optional aber auch mehr darstellen kann. Es gibt manche Plattformen, darunter gcc auf i386, auf denen diese Anforderungen mit einem 16-Bit-Datentyp erfüllt wird. Garantiert ist das aber nur mit uint16_t.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.


kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 15. April 2014, 10:05 »
Wenn es eine Frage wäre, in der wir uns wirklich uneinig wären, wie jetzt C tatsächlich funktioniert (und das haben wir hier bei anderen Fragen immer wieder mal), dann würde ich zur Klärung eher nicht auf irgendein Wiki verweisen, sondern auf Kapitel 5.2.4.2.1 im C11-Standard.

Du solltest dich daran gewöhnen, offizielle Standards und Dokumentationen zu lesen, wenn du Dinge genau wissen willst. Auch wenn sie am Anfang gewöhnungsbedürftig zu lesen sind. (Okay, erstmal C lernen, aber sobald du das einigermaßen kannst dann... ;))
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

OSLiga

  • Beiträge: 12
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 15. April 2014, 10:23 »
Dann muss ich heute in die Bibliothek  :-D
OS in Arbeit

 

Einloggen