Sourcecode Fortschritt
-
0.0.1.75 - Rev: 644
qemu: 0xF2000000
mib korrigiert: in asm und vbe: 0x1200 (dennoch kommen keine daten in qemu)
-
0.0.1.76 - Rev: 645
vidswtch.asm
- erweitertvbe.c/vbe.h
- erweitertfont.bin
- erneuert
-
Zwischenstand Grafik:
0.0.1.77 - Rev: 646
zur korrekten abfrage des mib gehört die übergabe des video mode in cx:
ModeInfoBlock: xor ax, ax mov es, ax mov ax, 0x1200 mov di, ax mov ax, 0x4F01 mov cx, 0x0101 int 10hDie notwendige VideoRam-Größe findet man hier:
http://www.pcmag.com/encyclopedia_term/0,2542,t=VESA+modes&i=53780,00.aspvidswtch.asm etwas ausgeräumt
-
0.0.1.78 - Rev: 647
bei #define _FLOPPY_DIAGNOSIS_ noch motor on/off signalisiert. Vielleicht findet jemand den Grund, warum die Floppy-lampe (bochs) nach dem Laden eines Programms eingeschaltet bleibt.
Bei bochs übrigens: 0xE0000000 als video ram für video mode 0x0101
-
0.0.1.79 - Rev: 648
Grafik initalisierungsreihenfolge geändert so dass, mib->PhysBasePtr in SetVideoMemory() benutzt werden kann.
-
0.0.1.80 - Rev: 649
Zwischneschritt:
- vidswtch.asm umgebaut
- automatisches Holen von TotalMemory und PhysBasePtr
-
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
