Sourcecode Fortschritt
-
Version 0.0.1.95:
- Syscalls umsortiert. Sämtliche Syscalls haben neue Nummern. Das erfordert, das alle Userprogramme neukompiliert werden. Das wurde in dieser Revision für alle Beiliegenden getan.
- Syscall.h/.c aufgeräumt, DEFN_SYSCALL und DECL_SYSCALL haben sich als überflüssig herausgestellt -> Entfernt, da unnützer Wartungsaufwand. (Relikt aus dem Tutorial von JM, der den Header aus dem kernel wohl auch im userspace includieren wollte.)
- Syscalls für Dateizugriff angelegt, sollte funktionieren. Die file_t-Struktur ist allerdings noch nicht (vollständig) implementiert, deren Member können aus dem Userspace nicht genutzt werden
-
version 0.0.1.96 - Rev: 665
- SCREEN mit der vermutlich fehlenden Farbpalette (im moment 256 Farben) gerade gerückt.
- Bitmap funktion um positionierung erweitert
-
version 0.0.1.97
Zwischenstand zum Experimentieren mit den Paletten in SCREEN und BMP
-
0.0.1.98 - Rev: 667
Bitmap wird wieder angezeigt.
Folgender Code in bitmap(...) ist extrem kritisch und wurde daher nach einigen erfolglosen Versuchen auskommentiert:
if(mib->BitsPerPixel == 8) { BMPInfo_t* bmpinfo = (void*)0x2400; for(uint8_t j=0; j<256; j++) { ScreenPal[j].red = (bmpinfo->bmicolors[j].red) >> 6; ScreenPal[j].green = (bmpinfo->bmicolors[j].green) >> 6; ScreenPal[j].blue = (bmpinfo->bmicolors[j].blue) >> 6; } waitForTask(create_vm86_task(VM86_SETPALETTE)); // OK }
waitForTask(create_vm86_task(VM86_SETPALETTE)); <--- unkritisch
Vielen Dank übrigens an MrX für die Schaffung der Funktion waitForTask!
-
0.0.1.99 - Rev: 668
Unglaublich, aber mit 255 anstelle 256 geht es.
Keine Ahnung, was da genau passiert.Die Palette verändert sich übrigens nicht durch die durchgeführte Aktion.
Falls jemand weiß wie man die beiden Paletten abgleicht, bitte um Nachhilfe oder Link. Ansonsten empfiehlt es sich wohl, auf höhere Farbenauflösungen umzusteigen und die 256-Farben-Welt zu verlassen.
-
Rev. 0.0.1.100:
- setPalette an Funktion 4F08h angepasst (Seite 53 vbe3 spec)
- Komprimierung auf 6:6:6 eingestellttypedef struct { uint8_t blue : 6; uint8_t green : 6; uint8_t red : 6; uint8_t reserve : 6; } __attribute__((packed)) RGBQuadPacked_t;
klappt aber noch nicht
auch nach Korrektur
mov bx, 6in vidstwch.asm, zeile 89 gehts auch nicht
mein Fazit: weg mit diesem Paletten Blödsinn, hin zu 24 bit colors!
-
version 0.0.1.101 - Rev: 670
- get/set VgaInfoBlock/ModeInfoBlock abgeändert
-
version 0.0.1.102 - Rev: 671:
SetDacPalette: mov ax, 0x4F08 mov bl, 0 mov bx, 6 int 10h jmp exitvm86 GetDacPalette: mov ax, 0x4F08 mov bl, 1 int 10h jmp exitvm86 SetPalette: mov ax, 0x4F09 ; Set/Get DAC Palette Format mov bl, 0 ;=00h Set palette data mov bx, 6 ; ?? mov cx, 0xFF xor dx, dx xor ax, ax mov es, ax mov di, 0x1500 int 10h jmp exitvm86
-
version 0.0.1.103 - Rev: 672
- set/getDACPalette funktionen definiert.
- setPalette(RGBQuadPacked_t* RGB); Funktion.
- getPalette() in ckernel.c eingefügt, liefert noch 0 werte.
- setPalette(ScreenPal); in bitmap(); erstmal wieder auskommentiert.
-
0.0.1.104 - Rev: 673
- Reihenfolge der Paletteneinträge in BMP gezeigt Aufbau: umgekehrt und BGR0
(leider hat unser Bild nicht die Standardpalette mit den ersten 16 Farben)
- SetPalette führt noch zu einem seltsamen "Textbild" mit niedriger Auflösung, daher auskommentiert
-
0.0.1.105 - Rev: 674
- Aufbau in ScreenPal (jetzt bei 0x1600) wird gezeigt und stimmt
- setPalette kann man nun endlich ausführenWirkung noch nicht wie gewünscht
-
version 0.0.1.106 - Rev: 675
- Neue SetDAC(...); Funktion (32bit protected mode)
- bitmap(...) Funktion um "if(mib->DirectColorModeInfo == 1)..." erweitert
mit der SetDAC(...); Funktion wird jetzt die palette gesetzt, aber noch nicht mit dem gewünschten ergebnis...
-
version 0.0.1.107 - Rev: 676
- DAC Funktionen zum testen hinzugefügt
void Write_DAC_C_Palette(...);
void Set_DAC_C(...);
void Read_DAC_C_Palette(...);
void Get_DAC_C(...);- Zum anzeigen der Palette im VideoMode
printPalette(...);
-
-
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