4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    Version 0.0.1.92 - Rev. 661

    VgaInfoBlock_t überarbeitet
    http://www.delorie.com/djgpp/doc/ug/graphics/vesa.html

    0
  • E
    Mod

    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

    0
  • E
    Mod

    Version 0.0.1.94 - Rev. 663

    ablauf in vidswtch.asm:

    1. vga, mib
      (video ram mappen)
    2. switch

    Nun wird das Bild auch auf realPC angezeigt (phys. base ptr: B000000 wird mit 256 MB nach virtuell E0000000-F0000000 gemappt)

    0
  • M

    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

    0
  • I

    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

    0
  • E
    Mod

    version 0.0.1.97

    Zwischenstand zum Experimentieren mit den Paletten in SCREEN und BMP

    0
  • E
    Mod

    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
  • E
    Mod

    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. 😉

    0
  • E
    Mod

    Rev. 0.0.1.100:

    - setPalette an Funktion 4F08h angepasst (Seite 53 vbe3 spec)
    - Komprimierung auf 6:6:6 eingestellt

    typedef 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, 6

    in vidstwch.asm, zeile 89 gehts auch nicht

    mein Fazit: weg mit diesem Paletten Blödsinn, hin zu 24 bit colors! 😃

    0
  • I

    version 0.0.1.101 - Rev: 670

    - get/set VgaInfoBlock/ModeInfoBlock abgeändert

    0
  • E
    Mod

    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
    0
  • I

    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
  • E
    Mod

    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
  • E
    Mod

    0.0.1.105 - Rev: 674

    - Aufbau in ScreenPal (jetzt bei 0x1600) wird gezeigt und stimmt
    - setPalette kann man nun endlich ausführen

    Wirkung noch nicht wie gewünscht

    0
  • I

    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...

    0
  • I

    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(...);

    0
  • E
    Mod

    Buch: http://books.google.de/books?id=gZ5SDTpMR-MC&printsec=frontcover#v=onepage&q&f=false

    0
  • E
    Mod

    Version 0.0.1.108 - Rev: 677

    set_DAC_C verwendet die Ports:
    http://wiki.osdev.org/VGA_Hardware#VGA_Registers

    Frage: 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
  • E
    Mod

    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
  • E
    Mod

    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. 😉

    0
Anmelden zum Antworten