Transformers
**Im ST-Magazin 9/91 haben wir ein Programm zur Beseitigung von Fehlern in der VDI-Funktion vr_trnfm() vorgestellt. In dieser Ausgabe erfahren Sie, wann Sie den Patch benötigen. **
Das in der September-Ausgabe vorgestellte Fixprogramm »vr_trnfm()«-Fix hat Echo unter den Entwicklern hervorgerufen. Da wurde der Wunsch geäußert, man möge den Fix mit einer Cookie-Installation versehen, anhand derer jedes andere Programm feststellen kann, ob der Patch aktiv ist. Hierzu ist zu sagen, daß dieses Verfahren zwar von manchem Fix praktiziert wird, die Funktion jedoch äußerst fragwürdig ist.
Schließlich ist es von wenig Belang, ob ein Fixprogramm im Speicher liegt - was wirklich interessiert ist, ob die betreffende Betriebssystemfunktion korrekt oder fehlerhaft arbeitet. Im Fall der »vr_trnfm()«-Routine ist dies nicht ganz leicht festzustellen, denn das Ergebnis einer Transformation kann ja beliebig sein - je nachdem, welche Grafikkarte Verwendung findet. Deshalb erscheint uns folgendes Verfahren am sinnvollsten: Ein Programm legt einen ausreichend großen Puffer an. Seine Ausmaße müssen mindestens die Maße fd_wdwidth * fd_h > 64 k überschreiten. Sollte dazu nicht genügend Speicher zur Verfügung stehen, erübrigt sich das Problem, denn auf kleineren Blöcken arbeitet die OS-Funktion auf allen TOS-Versionen ohnehin korrekt. Diesen Puffer füllt das Programm mit einem beliebigen Muster - je komplizierter, desto besser. Es darf sich dabei nicht um ein Zufallsmuster handeln, denn das Ergebnis muß reproduzierbar sein.
Nun muß ein zweiter Block derselben Größe reserviert werden. Für beide Blöcke legt das Testprogramm MFDBs an. Der erste Block wird als Standardformat-Block deklariert, der zweite als Block des gerätespezifischen Formats. Nun transformiert das Testprogramm den ersten Block in den Speicherbereich des zweiten. Bei einer korrekten Umformung liegt nun der komplette Bit-Block im gerätespezifischen Format vor. Ob die Transformation auch tatsächlich korrekt abgelaufen ist, läßt sich an dieser Stelle jedoch nicht feststellen, denn über das gerätespezifische Format sind keine Annahmen gültig. Also bleibt dem Programm nur übrig, den ersten (Standard-) Block zu löschen, d.h., seinen Speicherbereich mit Nullen zu füllen und die Transformation in umgekehrter Richtung durchzuführen. Das Ergebnis der zweiten Transformation muß nun mit dem Muster, mit dem der Bit-Block ursprünglich gefüllt wurde, übereinstimmen. Damit ist aber noch nicht bewiesen, daß »vr_trnfm()« tatsächlich gänzlich korrekt arbeitet. Denn »vr_trnfm()« erlaubt auch Blocktransformationen in gleiche Speicherbereiche, und diese Konstellation ist bislang nicht getestet worden. Zwar nutzt kein uns bekanntes Programm diese Fähigkeit der »vr_trnfm()«-Funktion mit größeren Blöcken, weil die Transformation unter diesen Umständen nämlich schnarchlangsam arbeitet, dennoch muß ein sauberer Test auch diese Falltür umgehen.
Also müßten zwei weitere Teststufen her - nämlich eine, welche die Transformation des Standardformats kontrolliert, und eine zweite, die in umgekehrter Richtung arbeitet. Dazu wäre ein dritter Puffer nötig. Nach jedem Umwandlungsschritt müßte das Testprogramm die Transformationsergebnisse miteinander vergleichen. Dabei müßte außerdem darauf geachtet werden, daß der Block als Mehrplane-Bitmap gekennzeichnet wird, denn im ST-Videosystem sind das gerätespezifische und das Standardformat in den Monochromauflösungen gleich aufgebaut, weshalb sich Konvertierungsfehler bei der Transformation auf gleiche Speicherblöcke nicht aufspüren lassen.
In unserer Testroutine haben wir darauf verzichtet, da eine einzige funktionierende Großtransformation auf einem ST weit mehr als eine Stunde dauert. Das ist auch der Grund, weshalb der »vr_trnfm()-Fix« keinen eigenständigen Test durchführt: Er behebt zwar den Fehler in beiden Umwandlungsroutinen, könnte aber nur eine davon abtesten. Unser Listing zeigt eine passende Testroutine »check_vr_trnfm()«. Sie liefert die Rückgabewerte:
| Wert | Bedeutung |
| <0 |
Ein Fehler ist während des Tests aufgetreten. |
| 0 |
»vr_trnfm()« arbeitet die Transformation in einen anderen Speicherbereich korrekt ab. |
| >0 |
Die Transformation ist fehlerhaft. |
[listings/chk_vrt.zip]
Alte Bekannte
Für unsere Stammleser können wir heute einen ganz besonderen Leckerbissen servieren: Neues vom »wind_update()«-Experten! Im letzten Monat haben wir uns intensiv mit dem TOS der »Mega STE«-Computer auseinandergesetzt. Dabei fiel uns im Desktop erneut ein Fehler im »wind_update()«-Handling auf, der, wie sich später herausstellte, auch im TOS 3.05 der neueren TTs vorhanden ist. Dort ist nämlich ein sehr eklatanter Fehler des 3.01er Desktops behoben worden [1], eine Unschönheit lebt jedoch noch immer. Während der Bootphase erscheint der Mauspfeil, sobald die korrekte Auflösung eingestellt ist. Anschließend lädt GEM seine Accessories und startet den Desktop, der seinerseits mit dem Malen der GEM-Menüleiste beginnt. Dabei benutzt er die Funktion »wind_update()« so unglücklich, daß man es mit etwas übung schafft, ein Drop-Down-Menü herunterklappen zu lassen, während der Bildschirmhintergrund noch weiß ist. Mit etwas Pech malt der Desktop anschließend seinen gerasterten Bildschirm grün. Als Effekt bleibt der Teil des Bildschirms weiß, an dem das Drop-Down-Menü heruntergeklappt ist. Sicher, um solch einen Fehler überhaupt zu bemerken, bedarf es einiger übung, dennoch ist der Fehler existent. Hoffen wir, daß Atari bald zu seiner Beseitigung schreitet.
Literatur:
[1] L. Prüßner, »Nachschlag mit Trick«, ST-Magazin 1/1991, Seiten 118 f., Markt & Technik Verlag.
[2] L. Prüßner, »Happy Burst-Day«, ST-Magazin 8/1991, Seiten 62 f, Markt & Technik Verlag.
Laurenz Prüßner