Sourcecode Fortschritt
-
Version 0.0.1.108 - Rev: 677
set_DAC_C verwendet die Ports:
http://wiki.osdev.org/VGA_Hardware#VGA_RegistersFrage: warum wird die BMP-Palette nicht richtig ausgelesen/übertragen?
Alle structs und Konstanten überprüfen, notfalls roll-back.
Hauptvorteil ist ja nun das richtige Setzen der palette mittels set_DAC_C.
Nun muss die bmp-palette wieder richtig hingeschoben werden.
-
0.0.1.109 - Rev: 678
Paletten-Thema gelöst!
In die BMPInfo_t war ein Fehler (ein kleines Sternchen!) rein geraten, so ist es richtg:
typedef struct { BitmapHeader_t bmiheader; RGBQuad_t bmicolors[256]; } __attribute__((packed)) BMPInfo_t;... und die Reihenfolge ist bei beiden Paletten "umgekehrt".
Leider findet man so etwas nicht richtig beschrieben (selbst in der vbe3 spec nicht).Nun muss man nur noch die eigentlichen Bitmap-"Daten" korrekt platzieren.
Läuft auf qemu-EHCI.
-
0.0.1.110 - Rev: 679
... auch im else-zweig beide umgekehrt. Dort hilft es aber leider noch nicht zur richtigen Palette. Nun hat man aber ein gutes Vorbild im if-Zweig und kann dort mal nachschauen, was da anders läuft.
-
version 0.0.1.111 - Rev: 680
ModeInfoBlock_t erweitert (vbe 2.0):
uint32_t OffScreenMemOffset; // pointer to start of off screen memory
uint16_t OffScreenMemSize; // amount of off screen memory in 1k unitsdementsprechend vgaDebug(...); angepasst und die Anzeige der Videomodes korrigiert.
printPalette(...); Funktioniert jetzt, leider noch mit der SET_DAC_C funktion.
-
0.0.1.112: korrekte Geometrie! korrekte Farben!
- bitmap(...) verbessert: mehrere bitmaps gleichzeitig, vereinfacht (ohne if/else)
- bitmaps werden direkt geladen (nicht mehr über 0x2400)kernel.bin (mit zwei bmp-files): 219.296 Bytes (den kernel habe ich versuchsweise schon über 300K aufgepustet, wurde brav geladen vom BL2)
ok: qemu, VBox, VMWare, Bochs
nicht ok: Test-PC (offenbar BL2-Ladeproblem)Hier noch eine Alternative: http://img837.imageshack.us/i/previewu.png/ (einfach in 256-farben-bmp umwandeln)
Aber ein png-Loader wäre echt gut
-
Version 0.0.1.113:
- Ein paar Syscalls implementiert
- Userfunktionen eingebaut
- Aufräumarbeiten
-
Großer Umbau der Verzeichnisstruktur. Bitte momentan nicht comitten, da mergen nahezu unmöglich ist. Ich plane, diesen Morgen fertig zu werden.
-
Momentan: Commit-Sperre wegen Umbauarbeiten (MrX)
MrX wird das Repo wieder frei geben
-
Version 0.0.1.113 - Revision 683:
- Großer Verzeichnisstrukturumbau: Treibertypen nun in Ordnern zusammengefasst/gruppiert. /include-Ordner weggemacht
Committen wieder freigegeben, bin fertig
-
Erhard, bist Du mein Echo?
-
0.0.1.114 - Rev: 684
Bit-Array RGBQuadPacked_t umgebaut, damit diese GCC 4.4 Meldung verschwindet
-
version 0.0.1.115 - Rev: 685
- font.bmp 1D gestalltet, alte font in font_layout.bmp umbenannt
- draw_char(...); Funktion
- vbe.c/.h aufgeräumt
-
-
Meine aktuelle Variante von void draw_char(char font_char, void* bitmapMemStart)
Läuft allerdings auch nocht nicht korrekt. Vielleicht hilft es aber weiter.
-
version 0.0.1.116 - Rev: 686
-vbe.c/h
draw_char(...), gibt jetzt zeichen aus, allerdings noch spiegelverkehrt.-kernel/video/font.h
hinzugefügt
-
0.0.1.117 - Rev: 687
- Buchstaben jetzt richtig herum
- Parameter bei draw_char und draw_string ergänzt
- draw_string "laufend" gemacht und beispielhaft eingesetzt
-
version 0.0.1.118 - Rev: 688
- data.asm
font.bmp kernel include via incbin gelöscht. (kernel größe verkleinern)- ckernel.c
Bitmap Palette Entries, Debug meldung erstmal wieder auskommientiert- Source/tools/font2bin.exe
gelöscht
-
Hier mal ein Screenshot zur Dokumentation:
http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_118_drawstring_bitmap.PNG
-
version 0.0.1.118 - Rev: 689
vbe.c/.h
- aufgeräumt
- starte umsetzung von getDisplayStart()
-
version 0.0.1.119 - Rev: 690
- getDisplayStart() funktionierend gemacht (Werteübergabe an 0x1300 u. 0x1302)
- netzwerk etwas überarbeitetFunktioniert auf meinem Test-PC.
