Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: KtmnjjpfjsFvzG am 02. February 2013, 15:26
-
Ich hab ehrlich gesagt keine Ahnung davon, aber mich interessieren folgende Dinge:
- Was ist, wenn man statt einem BIOS UEFI hat? Funktioniert das dann auch noch?
- Was ist mit anderen Auflösungen, als denen, die in der Liste stehen? Wie ist es überhaupt möglich, z.B. 1920x1080 Pixel darzustellen?
- Wie kann man, falls vorhanden, eine Grafikkarte dazu ausnutzen, die Pixel zu berechnen?
-
- Was ist mit anderen Auflösungen, als denen, die in der Liste stehen? Wie ist es überhaupt möglich, z.B. 1920x1080 Pixel darzustellen?
Mit VESA alles außer FULL HD.
Vllt schreib ich mal en rudimentären Radeon oder Geforce Treiber der en FULL HD modus einstellt aber davon bin ich momentan ziemlich weit weg. Dafür müsste man mit Reverse Engineering die Specs aus den fglrx und nouveau Treibern rauslesen oder debuggen. Rauslesen eher weniger weil die meiste moderne HW von Linux nicht unterstützt wird und sie ziemlich unlesbar sind.
Meine ROADMAP
VMM Heap;
x64;
DMA, PCI;
AHCI;
FAT32;
SMP, SSE;
AHCI oder VESA 2.0
- Wie kann man, falls vorhanden, eine Grafikkarte dazu ausnutzen, die Pixel zu berechnen?
Normalerweise sendet die Hardware einfach nur den Framebuffer an das Display über DVI oder HDMI. Hardware beschleunigung dass du die GPU dies und das ausrechnen lässt ist schwer
-
Hmm OK, dann muss also erstmal die CPU die Pixel berechnen...
Wenn man so einen Treiber hat, ist es denn dann egal, welche Geforce man hat? Gibt da doch hunderte verschiedene^^
-
Wenn man so einen Treiber hat, ist es denn dann egal, welche Geforce man hat? Gibt da doch hunderte verschiedene^^
Wenn du bloß VESA nutzt ja. Wenn du Spezifischeres schreibst z.b FULL HD Auflösungen setzt dann is das nicht mehr egal.
-
Ja, und VESA kann ja kein Full HD, also würde ich dann nicht VESA nutzen und bräuchte für jede Grafikkarte einen eigenen Treiber, oder?
-
Wo habt ihr das her, dass VESA 1920x1080 nicht unterstützt?
-
Von hier: http://www.lowlevel.eu/wiki/VESA_BIOS_Extensions
Allerdings lese ich hier gerade
Mit VBE 2.0 hat man sich allerdings dafür entschieden, dass die Grafikkartenherrsteller einfach nur eine Funktion bereitstellen, die alle von der Grafikkarte unterstützten Modi auflistet. Den Zeiger auf diese Liste erhält man mit dem VBE Info Block (4F00h). Diese Liste ist eigentlich nur ein WORD-Array, also eine Hintereinaderreihung von 16-Bit-Nummern. Diese repräsentieren die von der Grafikkarte unterstützten Grafikmodi. Die Liste wird terminiert durch den Eintrag 0xFFFF. Es wird empfohlen, sich nicht auf die o. g. Standardmodi zu verlassen, sondern durch Abfragen des Modeinfoblocks die Auflösung und anderen Eigenschaften der Modi aus der Modeliste herauszufinden.
Bedeutet das also, dass auch 1920x1080 geht?
-
Wenn der Grafikkartenhersteller das so will, dann geht das.
-
Gibt es irgendwo Infos darüber, wie ich die verfügbaren Modi auslese?
-
Du hast in deinem vorletzten Post die Beschreibung wie das geht zitiert.
-
Ehrlich gesagt bin ich etwas zu doof dafür, das umzusetzen...
WORD* vesa=(WORD*) 0x????;
int i = 0;
for(; vesa[i] != 0xffff; i++){
echo("%x",vesa[i]);
}So in etwa? Was muss ich bei "????" schreiben ^^
-
Die VESA BIOS Funktionen sind Real Mode-Funktionen. Die einfachste Möglichkeit diese Funktionen aus dem Protected Mode aufzurufen ist der Virtual 8086 Mode (http://www.lowlevel.eu/wiki/Virtual_8086_Mode). Im Artikel sind Tutorials verlinkt. Das sollte dich die nächsten paar Tage gut beschäftigen.
-
Brauche ich dazu zwingend multitasking-unterstützung?
-
Nein, Multitasking brauchst du nicht. Du musst das nicht unbedingt als Task implementieren, sondern du kannst im Kernel einfach kurz in den VM86 wechseln und hoffen, dass der zeitnah wieder zurückkehrt. Wenn du irgendwann Multitasking implementierst, musst du allerdings schon irgendwie Rücksicht auf den VM86 nehmen oder du nutzt ihn nur bevor du Multitasking aktiviert hast.
-
Also, wenn ich permanent im Grafikmodus sein möchte, muss ich nicht permanent im VM86 sein?
-
Also, wenn ich permanent im Grafikmodus sein möchte, muss ich nicht permanent im VM86 sein?
Nein das brauchst du nur zur Iniitialisierung des Linear Frame Buffer auf den kannst du auch später zugreifen.
-
Wobei man den LBF doch auch von GRUB 2 laden lassen kann? Wo steht wie das geht?
-
Irgendwo in den Dokumentationen. Ist aber nicht anzuraten:
- GRUB-spezifisch, Erweiterung zu Multiboot
- Auflösung wechseln im Betrieb nicht möglich
- Autoerkennung / besten Modi afaik schwer implementierbar (im Falle von GRUB2 wohl nen kleines Script was dadrin läuft)
Grundsätzlich, kümmer dich erst um die Grundlagen - Grafik ist nen Kapitel für sich, da will man sich nicht parallel mit irgendwas anderem rumplagen.
-
Also mach ich es selbst im System, dann ist man nachher nicht auf GRUB angewiesen, sondern kann auch einen anderen Bootloader nutzen...
Es würde also so ablaufen:
1. in VM86 schalten
2. Liste der möglichen Auflösungen auslesen
3. für eine Auflösung entscheiden
4. irgendwie die entsprechende Speicheradresse sichern
5. VM86 wieder ausschalten
6. in die Speicheradresse aus Punkt 4 Pixel reinschreiben
oder?
-
Grundsätzlich, kümmer dich erst um die Grundlagen - Grafik ist nen Kapitel für sich, da will man sich nicht parallel mit irgendwas anderem rumplagen.
Hast du meene Roadmap gesehen?;)
@KtmnjjpfjsFvzG bist du so unhöflich oder siehst du meine PMs vllt gar nicht^^?
http://forum.lowlevel.eu/index.php?action=pm (http://forum.lowlevel.eu/index.php?action=pm)
-
Hallo,
Was ist, wenn man statt einem BIOS UEFI hat? Funktioniert das dann auch noch?
Ein normales System-BIOS enthält maximal Treiber für MDA (Text, 720x350) und CGA (max. 640x200). Alles höhere, einschließlich der VESA BIOS Extensions, liefert die Grafikkarte in ihrem Video-ROM mit. Wenn dein UEFI also noch ein BIOS emuliert, sollte es gehen.
In einem reinen UEFI-System benutzt du allerdings den Treiber der Firmware. Der benutzt keinen Real Mode-Code mehr.
Was ist mit anderen Auflösungen, als denen, die in der Liste stehen? Wie ist es überhaupt möglich, z.B. 1920x1080 Pixel darzustellen?
Andere Auflösungen, als in der Liste stehen, funktionieren nicht. Allerdings verbietet dem Hersteller niemand, 1920x1080 in die Liste zu schreiben... gelegentlich wird das angeboten.
Wie kann man, falls vorhanden, eine Grafikkarte dazu ausnutzen, die Pixel zu berechnen?
Nicht mit einem VESA-Treiber. Du kannst die Ausgabe allerdings beschleunigen, wenn du eine Kopie des Framebuffers im RAM hältst und nur die Teile, die sich geändert haben, in die Grafikkarte schreibst ("ShadowFB").
@Martin Erhardt: Du musst keinen Link auf die PM-Inbox setzen. Man sieht oben im Forum, ob da eine neue Nachricht angekommen ist oder nicht.
Gruß,
Svenska
-
@Svenska: Ich wusste das da noch nicht und hab daher gar nicht auf "Meine Mitteilungen" geachtet, daher hat er mir das verlinkt ^^ Ist mein Fehler^^
-
Hmmm... ich suche also nach der Adresse des LFB, wenn ich das richtig verstanden habe, und muss dafür in den vm86... brauch ich dafür assembler oder reicht C?
-
Wenn du es in C schaffst, korrekten 16-Bit-Code für den VM86 zu erzeugen (also den Interrupt auszulösen und die Daten einzusammeln), dann reicht auch C. Ob es das wert ist, kann ich nicht einschätzen.
-
Ja, ich glaube, das ist es :) Danke. Ich versuchs.
-
Bin ich doof? "Die Funktionsnummer wird in AX übergeben".
Was ist denn bitte AX?
-
Was ist denn bitte AX?
Die letzten 16 bit von EAX
Ich habs auch schon vergessen :oops: :
http://forum.lowlevel.eu/index.php?topic=3166.msg36761#msg36761 (http://forum.lowlevel.eu/index.php?topic=3166.msg36761#msg36761)
-
Okay, hm, und wie "übergebe" ich etwas in AX? Ich dachte so: outb(???, FUNKTIONSNUMMER); ...
-
Konkret bei den VBEs
/*
* BLABLA BLa werte in dx di usw. verschieben
*/
mov funktionsnummer, %%ax
int 0x10
-
Svenska meint, es reicht auch C...
-
C ist schön aber bei den VBEs wird im Realmode die Funktionsnummer in AX verschoben und über SW Interrupt 0x10 das BIOS aufgerufen das geht nu ma so ganz explizit nur in ASM. In C kann man ohne inline ASM oder Intrinsics (im Userland) keine interrupts auslösen und zeug nach AX verschieben sprich: es läuft auf das gleiche raus.
-
Ja also sowas
asm volatile("int $0xa");oder?
-
0xA ist aber Interrupt 11 wir wollen Interrupt 16 bzw 0x10 steht jedenfalls im Wiki ... .
Verwende lieber Assembler für VM86 du machst sowieso alles in ASM oder inline ASM und sonst KANNST du gar nichts anderes machen mit C in VM86 weil gcc sich auf den 32bit Registersatz verlässt und daher an dieser stelle invalid opcode erzeugt. Du müsstest dieses zeug in ein Bootmodul auslagern das du mit bcc kompilierst und das ist es definitiv nicht wert.
Ich hoffe ich konnte zur Abwechslung mal wirklich helfen.
-
Ich mach es jetzt in ASM.
Also nochmal zusammenfassend: Folgende Informationen habe ich:
Informationen zu einem Grafikmodus: 4F01h
Man durchläuft also die obige Liste der unterstützten Modi und prüft dann mit folgender Funktion, welche Eigenschaften der entsprechende Grafikmodus besitzt:
AX = 4F01h
CX = Nummer des Grafikmodus
Außerdem soll der Interrupt 0x10 aufgerufen werden, um die Funktion aufzurufen.
Ich mach also das, bevor es in den Protected Mode geht:
mov 0x4f01, %ax
mov 1, %cx
int $0x10 //<- Warum "$"? Anders compilert es nicht...
Naja, es passiert eigentlich etwas ganz logisches: Es erscheint mein "Bluescreen", weil er denkt, Interrupt 0x10 wäre die Exception Nummer 16...
Also was mach ich falsch?
-
Ohne $ wird das ein Speicherzugriff. Das heißt, deine ersten beiden Zeilen tun nicht das, was du denkst, weil das $-Zeichen vor den Zahlen fehlt und sie Speicher auslesen. Dein Handler für die Exception wird aufgerufen, weil du nicht in den VM86 wechselst, sondern immer noch im Protected Mode bist. Selbst wenn du irgendwie in den VM86 wechselst, kannst du nicht einfach so beliebigen Assemblercode ausführen. Ich glaube in diesem Thread wird das ganze so dargestellt, als müsstest du nur ein, zwei Kleinigkeiten machen und schon kannst du den Grafikmodus setzen. Das ist nicht der Fall. VM86 ist relativ kompliziert, und ich würde dir raten, erstmal ohne Grafik auszukommen.
-
Ohne Grafik funktioniert ja schon alles Problemlos...
Ich hab das so verstanden, dass ich mir auch die Adresse des LFB besorgen kann, BEFOR ich in den Protected Mode wechsle... Insgesamt sieht das nämlich so aus:
_start:
// Stack initialisieren
mov $kernel_stack, %esp
call init_gdt
call init_intr
// VESA
mov $0x4f01, %ax
mov $1, %cx
int $0x10
call init_vesa
//protected mode
mov %cr0, %eax
or %eax, 1
mov %eax, %cr0
// C-Code aufrufen
call init
// Falls wir jemals aus init zurueckkommen sollten, sperren wir die Interrupts und
// halten einfach den Prozessor an. (man braucht ihn ja nicht unnötig heißlaufen lassen.)
_stop:
cli
hlt
// Sollte es doch weitergehen, probieren wir erneut die CPU schlafen zu lassen
jmp _stop
-
Wenn du dein System mit einem Multiboot-Bootloader lädst, bist du bereits im Protected Mode. Die Zeilen, die den Protected Mode aktivieren sind also wirkungslos.
-
Svenska meint, es reicht auch C...
Nein, meinte ich nicht. Ich schrieb, wenn du es schaffst, das in C hinzukriegen. Ich wüsste nicht, wie.
Lerne die Grundlagen. Bitte.
-
OK also ich schaffs nicht, das in C hinzukriegen.
Ich bin doch grad dabei, die Grundlagen zu lernen ^^!
-
Hallo,
du schreibst gerade ein OS und lernst die notwendigen Grundlagen quasi nebenbei. Ich vermute aber, dass dir der Blick aufs Ganze fehlt, du dir also nur das zusammenstückelst, was du gerade brauchst. Das ist dann weniger schön, irgendwann wirst du es brauchen. :-)
Wenn einem Wissen fehlt, kann man es nachschlagen. Wenn man aber nichtmal weiß, wo einem Wissen fehlt, wird das mit dem Nachschlagen sehr viel schwieriger (siehe die Frage mit dem Doppelpunkt). Dafür braucht es einen Überblick und den findet man in Büchern, die alle Themen mal anfassen und dabei nichts auslassen. Wikis und Tutorials sind gute Nachschlagewerke und Anleitungen, wenn man grob weiß, was man suchen muss.
Du wirst in deinem Betriebssystem ohne Assembler nicht auskommen, auch wenn du nicht viel davon benutzen wirst. Gehe mal in deine örtliche (Uni-/FH-/Stadt-)Bibliothek und suche dir ein Buch zum Thema x86-Architektur und -Assembler aus. Du musst es weder aufessen noch vollständig wochenlang durcharbeiten, aber wenn du da durch bist, wird dir einiges viel klarer sein als vorher.
Gruß,
Svenska