Thema: Pixel malen

[bitmaster]

Fast richtig! Für VBE sind nur einige Videomodi (bis 0x120 oder so) fest definiert, der rest ist Herstellerabhänging. Das Beste ist wirklich, sich zu jeder Mode-Nummer die Daten geben zu lassen (auf eine Liste unterstützter Modi zeigt ein Pointer im VBE Info Block). Allzuviele Mode-Nummern gibt es übrigens auch nicht, weil nur die unteren 9 bit eine ModeNummer darstellen und die restlichen Bits für gewünschte Eigenschaften stehen. Und da in Abgrenzung zu VGA Modi die VBE Modi erst bei 0x100 starten, ist der Bereich auf 0x100 bis 0x1ff beschränkt.
Das der Base Pointer bei LFB außerhalb des eigentlichen Speichers liegt ist auch ganz normal, weil man dann den Arbeitspeicher der GraKa anspricht und dieser halt woanders gemappt ist.

OK, gut dann werde ich also alle Mode's von 100h bis 1FFh auf 1024*768*32 testen. Ach so, habe ich mir schon so gedacht das dann der Speicher der Grafikkarte genutzt wird. Nur wieso geht das nicht mit stos und muss direkt mit mov kopiert werden?

bitmaster

[n3Ro]

Komisch, müsste eigentlich gehen, schonmal auf nem RealPC probiert? Außerdem, mit:

Code: [Auswählen]


mov   edi,   [VbeModePhysBasePtr]
mov   ecx,   640 * 480
mov   eax,   0xCC
rep   stosd

schießt du über das Ziel hinaus;) , da du mit stosd immer gleich 4 bytes beschreibst. Also in dem Bsp. würde ich stosb nehmen, und zur Sicherheit auch noch vorher ein CLD machen, damit das Ganze auch sicher in die richtige Richtung geht. Wenn MOV geht muss auch STOSx gehen, das iist meine Meinung dazu.

[bitmaster]

Komisch, müsste eigentlich gehen, schonmal auf nem RealPC probiert? Außerdem, mit:

Code: [Auswählen]


mov   edi,   [VbeModePhysBasePtr]
mov   ecx,   640 * 480
mov   eax,   0xCC
rep   stosd

schießt du über das Ziel hinaus;) , da du mit stosd immer gleich 4 bytes beschreibst. Also in dem Bsp. würde ich stosb nehmen, und zur Sicherheit auch noch vorher ein CLD machen, damit das Ganze auch sicher in die richtige Richtung geht. Wenn MOV geht muss auch STOSx gehen, das iist meine Meinung dazu.

Tja, nur leider geht das nicht. Und mit stosb schon gar nicht, weil stosb es:di und nicht es:edi nimmt. Aber wenn ich 640*480/4 schreibe funktioniert es auch nicht. Leider funktioniert der 1024*768*32 Bit Modus mit VMware nicht. Mit Bochs darf ich nur 3 Bytes beschreiben (obwohl der sagt das es 32 Bit also 4 Byte Modus ist). Und wenn ich die Bytes einzelt hintereinander schreibe, geht es auch nicht, nur mit ein dword aufeinmal. Hmm.... Verstehe das ganze nicht so...

bitmaster

[bitmaster]

Cool, ich habs jetzt. Vergesst alles was ich gesagt habe. Ich hatte zwar den Modus auf 1024*768*32 getestet, dann aber vergessen den Wert bzw. die Nummer des Modus von cx nach bx zu kopieren um den dann nacher zu aktivieren. Deswegen lief alles falsch. Aber jetzt habe ich es gemacht, und es funktioniert auf Bochs, VMware und allen meinen PCs (außer auf dem 486er ).

bitmaster

[n3Ro]

Schön, dass es jetzt geht ^^

Und mit stosb schon gar nicht, weil stosb es:di und nicht es:edi nimmt.

Stimmt wieder nicht so ganz. Ob es:di oder es:edi benutzt wird hängt einzig und allein vom Adressmodus ab: 16bit = es:di und 32bit = es:edi. Der einzige unterschied zwischen den Befehlen ist der Teil von eax, der an die Speicherstelle geschrieben wird und die größe um die edi erhöht wird: b=al & edi+1 , w=ax & edi+2 ,  d =eax & edi+4 und q= rax & rdi+8 (64bit).

[bitmaster]

Stimmt wieder nicht so ganz. Ob es:di oder es:edi benutzt wird hängt einzig und allein vom Adressmodus ab: 16bit = es:di und 32bit = es:edi. Der einzige unterschied zwischen den Befehlen ist der Teil von eax, der an die Speicherstelle geschrieben wird und die größe um die edi erhöht wird: b=al & edi+1 , w=ax & edi+2 ,  d =eax & edi+4 und q= rax & rdi+8 (64bit).

Echt? Das wusste ich gar nicht. Ich dachte stosb und stosw nehmen immer es:di und lodsb und lodsw immer ds:si. Also gilt das alles nur für den RM? Na ja, mit stosd etc. klappt es ja nicht deswegen mache ich es mit:

mov [es:edi],eax

Und damit klappt es bei allen PCs die ich habe und bei Bochs und VMware. Also sollte das so schon richtig sein. KA warum das mit stosd nicht geht. Na ja, hat es denn bei einen von euch mit stosd funktioniert?

bitmaster

[bitmaster]

Ach ja, noch etwas. Wenn ich in eax den Wert für die Farbe habe, werden die letzten 8 Bit irgendwie ignoriert. Wenn ich z.B. weiß haben will, dann ist es egal ob ich: 00FFFFFFh oder 55FFFFFFh oder FFFFFFFFh etc. schreibe. Es werden also nur 24 Bit berücksichtigt, obwohl ich im 32 Bit Modus bin. Was ist denn mit den letzten 8 Bit? Ist das nur für die Helligkeit etc. zuständig?

danke!!!

[kevin]

Das letzte Byte ist dann der Alphakanal, würde ich sagen, und hat auf die Darstellung keine direkte Auswirkung.

[bitmaster]

Das letzte Byte ist dann der Alphakanal, würde ich sagen, und hat auf die Darstellung keine direkte Auswirkung.

Aha, also kann ich den einfach immer schön auf Null lassen?

[n3Ro]

Ja, aber im Prinzip kannst du damit machen, was du willst. Das eine Byte dient nur als Platzhalter, weil sich an 4byte ausgerichtete Werte schneller und einfacher auslesen lassen als an 3byte ausgerichtete Werte. Das ganze nennt sich auch 8:8:8:0, das heißt, dass es 4 Teile gibt von denen nur 3 a 8bit benutzt werden, im Gegensatz zu 8:8:8 (24bit modus), 5:6:5 (16bit modus) oder 5:5:5:1 (15bit modus, da ist nur das mit der 1 komisch) .

[bitmaster]

Ja, aber im Prinzip kannst du damit machen, was du willst. Das eine Byte dient nur als Platzhalter, weil sich an 4byte ausgerichtete Werte schneller und einfacher auslesen lassen als an 3byte ausgerichtete Werte. Das ganze nennt sich auch 8:8:8:0, das heißt, dass es 4 Teile gibt von denen nur 3 a 8bit benutzt werden, im Gegensatz zu 8:8:8 (24bit modus), 5:6:5 (16bit modus) oder 5:5:5:1 (15bit modus, da ist nur das mit der 1 komisch) .

OK, gut. Dann habe ich es ja so wie ich will. danke!!!

[bitmaster]

Mist, ich hatte was falsch gemacht. Jetzt geht es auch mit (rep) stosd.

bitmaster