4. Sourcecode Fortschritt

Sourcecode Fortschritt

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

    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 units

    dementsprechend vgaDebug(...); angepasst und die Anzeige der Videomodes korrigiert.

    printPalette(...); Funktioniert jetzt, leider noch mit der SET_DAC_C funktion.

    0
  • E
    Mod

    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

    0
  • M

    Version 0.0.1.113:

    - Ein paar Syscalls implementiert
    - Userfunktionen eingebaut
    - Aufräumarbeiten

    0
  • M

    Großer Umbau der Verzeichnisstruktur. Bitte momentan nicht comitten, da mergen nahezu unmöglich ist. Ich plane, diesen Morgen fertig zu werden.

    0
  • E
    Mod

    Momentan: Commit-Sperre wegen Umbauarbeiten (MrX)

    MrX wird das Repo wieder frei geben

    0
Anmelden zum Antworten