Sourcecode Fortschritt
-
0.0.1.81 - Rev: 650
Zwischenstand: VideoRam wird in Qemu korrekt geladen
Das ist aber auch das letzte
-
0.0.1.82 - Rev. 651
etwas besser, aber noch ziemlich kaputt
-
0.0.1.83 - Rev: 652
zunächst mal "repariert".
Problem: ckernel.c, zeile 132 ff.
setVideoMemory(); initGraphics(640, 480, 8); printf("\nSTOP vor switchToVideoMode"); waitForKeyStroke(); switchToVideomode(); printf("\nSTOP nach switchToVideoMode"); waitForKeyStroke();
schaltet nicht in den gewünschten video mode
-
0.0.1.84 - Rev: 653
... geht wieder!
Umbau in vidswtch.asm hat geholfen
Bochs (E0000000), Qemu (F2000000), VMWare (D0000000)
VBox: klappt nicht mit Grafik (zeigt seltsamen phys base ptr)
-
0.0.1.85 - Rev: 654
0x100 in ckernel. c und comments bei waitFor...
-
Version 0.0.1.86:
- Doku nach documentation gelegt, Syscalls.odt ergänzt, enthält die geplanten Syscalls
- abs und sgn wie in vbe.c gewünscht nach util.c gelegt
- strg+t-Problem behoben
- Aufräumarbeiten (Codestyle)
-
0.0.1.87 - Rev: 656
scheduler/task-log überarbeitet
Übersicht über Tasten-Kommandos:
strg + t : Task-Übersicht
strg + s : Screenshot auf Floppy
strg + u : Screenshot auf USB-MSD
ESC + h : Heap-Aufbau (Verwendung der Regions)
-
0.0.1.88 - Rev. 657
bitmap-darstellung etwas verbessert (Versuch)
void bitmap() { uintptr_t bitmap_start = 0x2400 + sizeof(BitmapHeader_t); uintptr_t bitmap_end = bitmap_start + 256*128; uint32_t i = bitmap_end; for(uint32_t y=0;y<256;y++) { for(uint32_t x=0;x<128;x++) { SCREEN[ x + y * mib->XResolution * mib->BitsPerPixel/8 ] = *(uint8_t*)(i * mib->BitsPerPixel/8 + bitmap_start); i--; } } }
-
0.0.1.89 - Rev: 658
ein anfang
-
0.0.1.90 - Rev: 659
- bitmap schon besser sichtbar
- bitmap() mit variablenUnser erstes "Bitmap" (320*200, 256 Farben) mit PrettyOS soll hier mal festgehalten werden:
http://www.henkessoft.de/OS_Dev/Bilder/0_0_1_90_bitmap.PNG
-
Wenn auch weniger sichtbar, auch der Scheduler hat zuletzt große Fortschritte gemacht
Version 0.0.1.91:
- waitForTask eingebaut
- waitForKeyStrokes durch waitForTasks ersetzt -> wesentlich weniger Keystrokes nötig
- Syscalls.odt aktualisiert
- Kleinigkeiten
-
Version 0.0.1.92 - Rev. 661
VgaInfoBlock_t überarbeitet
http://www.delorie.com/djgpp/doc/ug/graphics/vesa.html
-
Version 0.0.1.93 - Rev. 662
Zwischen schritt:
Beim ersten Durchlauf zum Holen der vga- und mib-Daten Einstieg ohne switchToVideo.läuft damit wieder auf VBox, Bochs, Qemu
Man sieht den mapping Vorgang.
Problem: Bild noch versetzt, Palette falsch.
RealPC:
<Cuervo> hab 3 getestet, einer kommt bis zur Shell, einer startet direkt neu und einer macht in einer Endlosschleife invalid opcode
-
Version 0.0.1.94 - Rev. 663
ablauf in vidswtch.asm:
- vga, mib
(video ram mappen) - switch
Nun wird das Bild auch auf realPC angezeigt (phys. base ptr: B000000 wird mit 256 MB nach virtuell E0000000-F0000000 gemappt)
- vga, mib
-
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!