In VESA-Modi Pixel setzen 컴컴컴컴컴컴컴컴컴컴컴컴� Tja, ich habe lange 갶erlegt, ob ich hier eine Routine f걊 einen speziellen VESA-Modus vorstellen soll, so zum Beispiel f걊 den 640x480x256-Modus (101h), oder ob ich eine Routine bringen soll, die f걊 jeden Grafikmodus benutzt werden kann. Dabei stellte sich mir allerdings die Frage, ob so eine Routine a) 갶erhaupt m봥lich ist, ohne ganz billig einfach abzufragen, in welchem Modus man sich befindet, und dann verschiedene Prozeduren einfach anspringt und dort die Punkte setzt b) ob es sinnvoll ist, solch eine Prozedur zu schreiben, da man schlie�lich einiges an Rechenzeit verschwenden wird, wenn man immer erst unterscheiden mu�, in welchem Modus man ist und dem entsprechend verschieden verfahren mu�. Ich bin darauf gekommen, eine Routine zu schreiben, die bei allen 256-Farben Modi funktioniert. Dabei mu� ich nicht allzu viel f걊 die verschiedenen Prozeduren ver꼗dern, habe EINE Routine f걊 alles und bin noch relativ schnell weg. Allerdings: Wenn man eine optimale Routine haben will, sollte man sie sich tats꼊hlich ganz speziell f걊 den gew걆schten Modus schreiben, alles Andere kostet einfach zuviel Zeit. Also: 256 Farben Modi, was sagt uns das? In einem solchen Modus nimmt ein Pixel immer genau 1 Byte ein, das hei�t: Der Adresse A000h:0000h steht immer f걊 den links oben erscheinenden Pixel, die Adresse A000h:0001h immer f걊 den rechts daneben stehenden usw. Da ein Byte genau 256 verschiedene Werte aufnehmen kann (2^8 = 256 / 0 - 255), sollte dieses klar sein. Der einzige Unterschied: Die Anzahl der Zeilen und Spalten sind anders. Im Modus 101h habe ich 640 Spalten und 480 Zeilen, im Modus 103h hat 800 Spalten und 600 Zeilen und der Modus 105h hat 1024 Spalten und 768 Zeilen. Daraus ergibt sich, da� nat걊lich mehr Speicher f걊 den Modus 105h als f걊 den Modus 103h und dieser mehr als f걊 den Modus 101h ben봳igt. Das wiederum hei�t, da� ich, wenn ich den aller letzten Punkt in jedem Modus setzen will, ich bei den h봦eren Modi das 'Videofenster' in den Videospeicher der Grafikkarte weiter verschieben mu�, als in den niedrigeren. Aber dazu sp�- ter noch mehr. Was uns nun besch꼎tigen soll, ist: Wie finde ich heraus, in wel- chem Modus ich mich befinde, wenn ich mich innerhalb meiner 'SetzePunkt' Prozedur befinde und nicht extra angeben will, welcher Modus es ist (was zwar auch m봥lich ist, doch w꼛e das sicherlich nicht so 'elegant', als w걊de diese Info die Pro- zedur alleine herausfinden). Daf걊 gibt es eine ganz einfache L봲ung: Die Unterfunktion 01h des VESA-Treibers, der 갶er die Funktion 4Fhh des Video-Interrupts 10h angesprochen wird, liefert einem eine ganze Menge an Informationen 갶er einen angegebenen Modus zur갷k. Unter anderem auch die x/y-Aufl봲ung. Allerdings ist dies leider keine Pflicht f걊 jeden Treiber. Doch ist mir bisher keine andere M봥lichkeit bekannt, die Aufl봲ung dann doch zu erhalten. Das einzige, was wir daf걊 noch ben봳igen, ist der Modus selber, und den erhalten wir mit der Unterfunktion 03h. Also: Zuerst fragen wir in unserer Routine die aktuellen Video- modus ab, indem wir die Unterfunktion 03h befragen. Der Modus wird uns in BX zugeteilt. Hier sollten wir dann kurz 갶erpr갽en, ob der Modus 101h, 103h oder 105h ist, und ansonsten die Pro- zedur (eventuell mit einem Fehlercode) beenden. Diesen Wert m걌sen wir dann ins CX-Register laden und die Unter- funktion 02h aufrufen. Gleichzeitig m걌sen wir aber mit ES:DI einen 29 Byte gro�en Puffer gekennzeichnet haben. Nun k봭nen wir im Bit 1 (das 2. Bit) des Offsets 0 im Puffer ablesen, ob die optionalen Informationen (darunter auch die Angabe 갶er die x/y-Aufl봲ung) mitgeliefert wurde. Wenn ja, ist das Bit 1 ge- setzt. Ansonsten m걌sen wir wiederum die Prozedur verlassen. Nungut, wir haben jetzt die x/y-Aufl봲ung des gesetzten Modus. Im Puffer an dem Offset 12h steht die x-Aufl봲ung, und an dem Offset 14h finden wir die vertikale (y-) Aufl봲ung. Was nun? Der Prozedur sollte die x und die y Koordinate des gew걆schten Punktes sowie dessen Farbe 갶ergeben werden. Um nun an die ge- w걆schte Offsetadresse im Videosegment bei A000h zu kommen, mu� man die y-Koordinate mit der x-Aufl봲ung multiplizieren und dann die x-Koordinate hinzu addieren. Beispiel: Modus 101h: x-Aufl봲ung : 640, y-Aufl봲ung : 480; x-Koordinate : 56, y-Koordinate : 60. yK * xA = 60 * 640 = 38400. 38400 + xK = 38400 + 56 = 38456. Der Pixel mu� also an die Adresse A000h:38456d bzw. A000h:9638h geschrieben werden. Nimmt man aber nun das Beispiel xK = 56 und yK = 400, dann w걊de als Offset die Zahl 256056d bzw. 3E838h herauskommen. Nicht schlimm? Doch! Denn dieser Offset w걊de schon in einem ganz an- deren Segment liegen! Man mu� also einen Wert erhalten, der innerhalb der Segmentgrenzen liegt, also gr붳er oder gleich 0 und kleiner oder gleich 65535 sein mu�. Nun wird es kompliziert: Liegt der bestimmte Offset au�erhalb dieser Schranken, dann mu� er in dieser 'hereingeschoben' werden. Das hei�t, er mu� verringert werden. Aber nicht ohne Ausgleich! Um den gleichen Wert, um den der Offset verringert wird, mu� gleichzeitig die Adresse des Videofensters vergr붳ert werden. Zur Erinnerung: Das Videofenster dient als Zeiger in den Grafik- speicher der Grafikkarte. Es wird beim Segment A000h im Haupt- speicher eingeblendet. Da dieses Fenster im Allgemeinen auch nur maximal 64 Kilobyte gro� ist (also ein Segment umfa�t), mu� es im Videospeicher der Grafikkarte verschoben werden, um Modi, die mehr als 64 Kb Speicher verbrauchen zu adressieren. Wenn ich also zum Beispiel im Modus 101h den Pixel mit der 'Offsetadresse' 65536 setzen will, so m곢te ich das Videofenster ersteinmal z.B. auf da� zweite Segment im Speicher der Grafikkarte setzen (es zeigt nun also auf die Pixel 65536-131071) und dann an die Off- setadresse 0000h den Pixel plazieren. Ich k봭nte das Videofenster aber auch so verlegen, da� es auf die Pixel 32768-98303 zeigt und dann die Offsetadresse 32767 einen Punkt plazieren. Der Effekt w꼛e der gleiche. ABER: WENN IHR DAS JETZT NICHT VOLLST랲DIG ODER VIELLEICHT NICHT EINMAL ANSATZWEISE VERSTANDEN HABT: MACHT NIX! LEST ES NOCH 50 ODER 60 MAL, VIELLEICHT BLEIBT DANN ZUMINDEST ETWAS H랲GEN... (Ich hoffe nur, da� ich mich bei den Zahlen nicht verrechnet habe). Was aber auf jeden Fall nun klar sein sollte: Ich kann nicht ein- fach den ermittelten Offset verringern, wenn ich nicht gleich- zeitig das Videofenster nach 'rechts' verschiebe, also dessen Lage im Grafikspeicher der Karte auf eine um den gleichen Wert erh봦ten Offset setze. Wie gehe ich nun dabei vor? Das einfachste ist, wenn man nun die Granularit꼝 ermittelt, mit der das Fenster verschoben werden kann. Sie steht an der Offsetadresse 04h des Puffers. Zu beachten ist, da� diese in Kb angegeben ist, man mu� den Wert also noch mit 1024 multiplizieren, um auf die Byteanzahl zu kommen. Man kann sich aber auch die beliebte bin꼛e Logik als Brainstorming an tun, und die dort angegebene Zahl einfach um 10 Bits nach links verschieben - geht schneller und ist sch봭er... Also: Granularit꼝 nehmen und um 10 Stellen nach links shiften. Das Ergebnis nehmen, und wenn der Offsetwert gr붳er als die oben angegebenen Grenzen sein sollten, diese solange um das 'Granularit꼝sergebnis' (das so eben berechnete, um 10 Stellen nach links geshiftete Ergebnis) verringern, bis es innerhalb der genannten Grenzen liegt. Dabei mu� man sich aber unbedingt die Anzahl der Abz갾e merken. Nun nehme ich diese Anzahl, stecke sie ins DX-Register, und verschiebe das Videofenster mittels der Unterfunktion 05h. Nun ist fast alles geschafft! Ich mu� jetzt nur noch an die neue (eventuell verringerte) Offsetadresse (A000h:Offset) den Wert der Farbe schreiben, die zuvor der Routine 갶ergeben wurde. Beispiel: xA : 1024, yA : 768; xK : 376, yK : 677. Ermittlung des 'PseudoOffsets': yK * xA = 677 * 1024 = 639248. 639248 + xK = 639248 + 376 = 639624 = PseudoOffset. Nun schaue man im Puffer nach und hole sich die Granularit꼝. Granu z.B. = 32. 32 * 1024 = 32768. Offset Anzahl 컴컴컴컴컴컴컴컴컴컴컴컴컴 639624 0 606856 1 574088 2 541320 3 508552 4 475784 5 443016 6 410248 7 377480 8 344712 9 311944 10 279176 11 246408 12 213640 13 180872 14 148104 15 115336 16 82568 17 49800 18 Man mu� das Videofenster also um 18 multipliziert mit der Granu- larit꼝 verschieben (hier : um 589824 Bytes). Hat man das getan, l꼋t man an die Adresse A000h:49800d bzw. A000h:C288h den Wert der Farbe und darf sich gl갷klich sch꼝zen. Nat걊lich mu� man den Wert der Granularit꼝 nicht unbedingt jedesmal abziehen. Man kann den 'PseudoOffset' auch die die Granularit꼝 teilen, das Videofenster um das ganzzahlige Ergebnis multipliziert mit der Granularit꼝 verschieben, und den Rest der Division als neuen Offset benutzen. Geschmackssache! Tja, nun. Ich glaube, da� war relativ schwierig. Auch f걊 mich. Wahrscheinlich verstehe ich beim n꼊hsten durchlesen selber nicht mehr, was ich da alles meinte. Pech! Das gute: Ich werde gleich ersteinmal ausprobieren, ob die Sachen 갶erhaupt stimmen... Weitere Ergebnisse bekommt Ihr dann in der Assembler und vielleicht auch noch in der Pascalrubrik zu sehen. Schaut mal rein, wenn Euch die Theorie nicht schon ganz abgeschreckt hat. Vielleicht versteht Ihr im Programm dann ja auch dies oder das noch besser. Mein Tip: Unbedingt noch einmal lesen! Nun noch eine Komplett갶ersicht, die Euch als Zusammenfassung dienen soll: Um einen Pixel in einem der Modi 101h, 103h oder 105h zu setzen, sind folgende Schritte zu tun: - Man multipliziert die y-Koordinate mit der x-Aufl봲ung und addiert zum Ergebnis die x-Koordinate. Das Ergebnis wird im folgenden PseudoOffset genannt. - Man finde die Granularit꼝 heraus, und multipliziere sie mit 1024 = GRANU. - Man ziehe vom PseudoOffset GRANU sooft ab, bis dieser innerhalb der Schranken von 0 bis 65535 liegt. - Man merke sich gleichzeitg aber, wie oft man GRANU abgezogen hat = ANZAHL. - Man verschiebe das Videofenster mittels der Unterfunktion 05h der VESA-Treiber um ANZAHL*GRANU (ANZAHL wird ins DX-Register geladen). - Offset = eventuell verringerter Pseudooffset. Man lade die Farbe an die Adresse A000h:Offset und freu sich 갶er einen neuen Klecks am Monitor. Kemil * Hier ein paar Dinge, die eventuell behilflich sein k봭nten: - Lest den Text, in dem die VESA-Treiber-Funktionen erl꼞tert werden (ein Button 갶er diesem!). - Die Koordinaten reichen immer von 0 bis zu ihrer Aufl봲ung-1! Das hei�t: Aufl봲ung 640x480: xK von 0 bis 639, yK von 0 bis 479. - 2^10 = 1024 - Schnelle Punkte setzen in einzelnen Modi erst in der n꼊hsten Ausgabe - Es gibt (k?)ein Leben nach dem Selbstmord! PS: Ich habe hier auch irgendwo gesagt, da� die Unterfunktion 01h einen Zeiger ES:DI braucht, der auf einen 29 Byte gro�en Puffer zeigt (daf걊 sind Zeiger schlie�lich da...). Nun reichen diese 29 Byte aber irgendwie einfach nicht aus. Daher: nehmt einen Puffer mit einer Gr붳er von 256 Byte. Das klappt (zumindest bei mir).