Der verrückte Mülleimer: Das fünfte Gimmick-Programm
Kennen Sie Trashy? So heißt der Kobold, mit dem Sie ein bißchen Abwechslung in den grauen Berufsalltag Ihrer Kollegen und Kolleginnen bringen.
Trashy befindet sich auf der TOS-Diskette im Archiv »GIMMICK« und nennt sich »TRASHY.ACC«. Aber normalerweise lebt unser Kobold im Mülleimer des Desktops, von wo aus er seine Streiche spielt. Um ihn dort hineinzustecken, kopieren Sie das Accessory auf Ihre Bootdiskette bzw. -partition und führen einen Reset durch. Beachten Sie bitte, daß das Accessory nur mit den den TOS-Versionen 1.0, 1.2, 1.4 und 1.6 funktioniert. Mit anderen TOS-Versionen läuft das Accessory zwar, aktiviert sich aber nicht. In diesem Fall müssen Sie das Accessory selbst an Ihre TOS-Version anpassen. Wie das geht, erkläre ich später. Ansonsten treibt Trashy seine Späße in allen Grafikauflösungen.
Nach dem Start schläft unser Kobold zunächst eine kurze Weile. Das kann bis zu zwei Minuten dauern. Aber dann wacht er auf und macht sich durch Klopfen an die Innenwand des Mülleimers bemerkbar. Manchmal schaut er auch aus dem Mülleimer heraus oder springt damit zur Seite. Hier muß man aufpassen, damit Trashy den Mulleimer nicht ganz aus dem Bildschirmbereich herausschiebt, und der verdutzte Benutzer plötzlich keine Dateien mehr löschen kann.
Modulumgebung
Wie die vorherigen Gimmicks entstand auch dieses Gimmick mit dem Megamax Modula-2-System. Allerdings besteht der größte Teil aus Assembler, so daß eine Übertragungaufein anderes Assembler-Entwicklungssystem keine Schwierigkeiten bereiten sollte. Für eine Portierung müssen Sie wissen, daß Megamax-Modula-2 das Register A3 als Para meterstack nutzt, wobei der A3-Stack von unten nach oben wächst, also genau anders herum als der A7-Stack.
Unser heutiges Gimmick ist nicht - wie die vorherigen Gimmicks - ein Autostartprogramm, sondern ein Accessory. Für ein Accessory benötigen wir eine andere Modulinitialisierung als bei einem Autostartprogramm. Anstatt des sonst benutzten Moduls MS INIT.MOD verwenden wir nun das Modul MS INITAC.MOD. Vor dem Linken müssen Sie also das Modul M2INIT.MOD durch MSINITAC.MOD unter dem Menü »Parameter/ Linker...« ersetzen. Die Module MSSYSTEMS und MSSOUNDS sind ja schon von den anderen Gimmicks her bekannt. Den Quelltext zu Trashy finden Sie in der Datei TRASHY.TXT. Bei BLACKHOL.TXT handelt es sich um eine Variante des Gimmicks, bei der ein sich drehendes schwarzes Loch den Papierkorb ersetzt.
Warum als Accessory?
Der Grund, warum es sich bei diesem Gimmick um ein Accessory und nicht um ein Autostartprogramm handelt, ist, daß wir diesmal mit dem AES Zusammenarbeiten. Das AES läßt sich aber nicht von einem Interrupt heraus aufrufen; der alte Trick mit dem VBL-Interrupt funktioniert hier nicht mehr. Aber eine regelmäßige Aktivierung unseres Gimmicks läßt sich auch mit einem Accessory realisieren. Die EVENT_ TIMER-Funktion des AES erlaubt uns, ähnlich wie mit einem Interrupt zu arbeiten. Der Unterschied ist, daß nicht das laufende Programm unterbrochen wird um unser Gimmick zu bedienen, sondern daß wir unser Gimmick unterbrechen, damit die anderen Anwendungen zum Zuge kommen.
Bewegte Icons
Zugegeben: Das GEM ist nicht die ideale Umgebung für rasante und flackerfreie Animationen. Zumindest sahen die Entwickler dies nicht vor, und es gelingt nur mit illegalen Tricks. Es ist jedoch sehr reizvoll, etwas auszuprobieren, was andere bisher noch nicht gemacht haben. Und das Ergebnis ist zumindest beim TOS 1.6 und 1.0 man glaubt es kaum zufriedenstellend. Mit den anderen TOS-Versionen funktioniert die Animation zwar auch, jedoch ist dort ein Programmierfehler in der Funktion FORM_DIAL vorhanden, der die Animation ggf. stark verlangsamt. Doch dazu später mehr.
Um nun die Objekte des Desktops zu manipulieren, müssen wir auf sie zugreifen. Das Betriebssystem stellt uns hierzu keine Funktionen zur Verfügung. Also müssen wir uns den Desktop-Objektbaum selbst im Speicher suchen (siehe Tabelle 1).
Die Variable mit einem Zeiger auf den aktuellen Desktop-Objektbaum ermittelte ich für die verschiedenen TOS-Versionen. Offiziell gab Atari diese Variable nicht bekannt. Sollten Sie eine andere TOS-Version besitzen, müssen Sie die Variablenadresse selbst heraussuchen.
Aber wie finden Sie diese Variablenadressen? Am einfachsten durchsuchen Sie den Speicher des ST mit dem »Templemon«. Dieses Shareware-Monitorprogramm eignet sich sehr gut für diese Aufgabe. Sie finden es auf der aktuellen TOS-Diskette. Um es zu starten, drücken Sie einfach im Desktop die Tastenkombination <Alternate Help>.
Der Objektbaum beginnt mit der Bytefolge FF FF 00 01. Mit »Fl 0 100000 FF FF 00 01« suchen Sie nach dieser Bytefolge. Als Ergebnis erhalten Sie eine ganze Reihe von Adressen, bei denen diese Bytefolge gefunden wurde. Am wahrscheinlichsten ist die zuletzt gefundene Adresse. Nehmen wir an, die Adresse lautet $2825A. Dann können wir mit »F1 0 10000 00 02 82 5A« nachschauen, ob diese Adresse irgendwo im Variablenbereich des Betriebssystems gespeichert ist. Finden Sie eine Adresse, können Sie mit großer Sicherheit davon ausgehen, daß es sich um den gesuchten Zeiger handelt. Sie müssen ggf. die Suche für alle zuvor gefundenen Adressen durchgeführen.
Mit diesem Zeiger sind nun den Desktop-Manipulationen Tür und Tor geöffnet. Es ist interessant zu wissen, daß der Zeiger den Wert 0L enthält, wenn die Desktop-Objekte nicht aktiv sind. Dies ist z. B. beim Start einer Applikation der Fall. Unser Gimmick führt während dieser Zeit keine weiteren Aktionen aus.
Enthält der Zeiger einen anderen Wert als Null, dann ist der Desktop-Objektbaum aufgebaut und wir können uns auf die Suche nach dem Mülleimer-Objekt begeben. Der Mülleimer ist ein Icon-Objekt. Icon-Objekte haben die Typenkennung $1 F. Zufällig ist der Mülleimer das erste Icon-Objekt im Objektbaum des Desktops, so daß wir nur nach der Bytefolge FF FF 00 1F suchen müssen. Die Adresse dieser Bytefolge minus 4 ist die erste Adresse des Mülleimer-Objekts. Die Struktur eines Objekts sehen Sie in Tabelle 2.
SPEC zeigt bei unserem Objekt auf eine Icon-Block-Struktur, von der uns im Moment nur die ersten beiden Einträge interessieren: PMASK und PDATA. Dies sind zwei Zeiger auf die Bilddaten. Das Mülleimer-Icon ist 32 mal 32 Pixel groß. Ein anderes Aussehen schaffen wir einfach durch Überschreiben des alten Bildes (PROZEDUR SetTrashlcon). Damit ist zwar das Bild des Icons geändert, jedoch noch nicht das Bild auf dem Monitor. Mit der Funktion FORM___DIAL müssen wir das AES erst dazu anweisen, den Mülleimer neu zu zeichnen. Vor und nach dem FORM__DIAL-Aufruf informiert die Funktion WIND___UPDATE das AES über eine durchzuführende Änderung des Bildschirminhalts. Anderenfalls entsteht ein regelrechtes Chaos auf dem Monitor, wenn zur gleichen Zeit auch andere Prozesse den Bildschirminhalt verändern wollen.
FORM___DIAL restauriert einen vorgegebenen Bildschirmbereich. Der in unserem Fall zu restaurierende Bildschirmbereich ist durch die Ausmaße des Mülleimer-Objektes vorgegeben. Dort erhalten wir die notwendigen Parameter für den FORM___DIAL-Aufruf.
Wollen wir das Mülleimer-Objekt verschieben, so müssen wir die Objektstruktur direkt ändern. Dann müssen wir allerdings aufpassen, daß der zu restaurierende Bildschirmbereich sowohl den alten als auch den neuen Bereich des Objekts umfaßt.
Wie schon erwähnt, ist die Funktion FORM___DIAL in den TOS-Versionen 1.2 und 1.4 fehlerhaft. Egal welchen Bildschirmbereich wir zürn Restaurieren angeben, der Rahmen des aktuellen Fensters wird immer neu gezeichnet. Probieren Sie es am Desktop aus: Öffnen Sie ein Fenster, schieben Sie es in eine Ecke und rufen Sie den Menüpunkt »DESKTOP INFO« auf. Nachdem die Info-Box mit ABBRUCH entfernt wurde, zeichnet GEM das aktuelle Fenster neu, obwohl es nicht unterhalb der DESKTOP-INFO-Box lag. Dieser Fehler verhindert zuverlässig eine flüssige Animation. Der einzige Weg, dies zu unterbinden, ist, alle Fenster während einer Animation zu schließen.
Die globale Tabelle »icons« enthält die verschiedenen Bilder für die Mülleimeranimation. Jedes Icon benötigt 128 Byte (4 Byte je Zeile). Die jeweiligen Daten für die Icon-Maske befinden sich direkt dahinter, so daß ein Bild insgesamt aus 256 Bytes besteht. Trashy verwendet zur Animation zehn Bilder.
Nach der Initialisierung über die APPI_INIT-Funktion legen wir die Variable mit dem Zeiger auf den Desktop-Objektbaum anhand der TOS-Version an. Daraufhin initalisieren wir die Felder für die einzelnen Animationszyklen (Lookjump und Knock) und geben die Samplefrequenz für die Tonausgabe an. Anschließend folgt eine Endlosschleife, wie es bei jedem anderen Accessory auch üblich ist. Sie beginnt mit einem EVENT_TIMER-Aufruf, bei der die Kontrolle vorerst wieder an das AES abgibt. Je nach dem gerade aktuellen Verhalten des Kobolds (Warten, Klopfen, Schauen oder Springen) rufen wir nach der Rückkehr aus dem EVENT-TIMER-Aufruf eine Prozedur auf, welche die notwendigen Aktionen ausführt. Die Variable MustDrawIcon signalisiert dabei, daß sich das Icon-Bild geändert hat und der Bildschirminhalt erneuert werden muß. Dies geschieht nachfolgend mit den AES-Aufrufen WIND__UPDATE (BEGIN), FORM____DIAL und WIND___UPDATE (END).
Die Copyright-Meldung von Trashy erscheint erst nach einiger Zeit. Dann nämlich, wenn der Kobold schon seine ersten Späße gemacht hat. Wir wollen den ahnungslosen Benutzer ja nicht vorwarnen. Der Einfachheit halber geben wir unsere Meldung mit der FORM_ ALARM-Funktion des AES aus (Prozedur Copyright).
Um das Flimmern bei der Animation halbwegs in Grenzen zu halten, synchronisiere ich den FORM_ DIAL-Aufruf mit dem Monitorbild über die Prozedur LineSync. Wenn die Grafikausgabe über den eingebauten Videochip läuft, wartet das Programm darauf, daß der Strahl in der Bildröhre sich unterhalb des Icons befindet. So richtig funktioniert das allerdings nicht, da die AES-Funktionen viel zu langsam sind. Trotz vieler Versuche gelang es mir nicht, eine wirklich flimmerfreie Animation darzustellen. Einen Weg, den ich aber wegen des großen Aufwandes noch nicht probierte, ist, den Mülleimer als Benutzerobjekt umzudefinieren. Dann führt man den eigentlichen Zeichenvorgang selbst durch. Aber dafür ist eine eigene spezielle Bit-Block-Kopierroutine notwendig. Dies scheint mir dann doch erheblich zu aufwendig, zumal der Erfolg nicht garantiert ist. Wer will, kann diese Idee ja mal umsetzen und ausprobieren.
Eigene Variationen
Selbst wenn Sie keine Animationen wie in diesem Gimmick entwickeln wollen, bietet sich doch vieles an, das man mit den Desktop-Objekten anstellen könnte. So verschaffen Sie auf diese Weise z. B. allen Objekten ein neues Aussehen. Anstatt dieser merkwürdigen Karteikästen würden Laufwerk-Icons dann wie normale Disketten aussehen. Ist ein solches Disketten-Icon angewählt, wäre es möglich, daß sich das Icon nicht einfach invertiert, sondern z. B. in eine Diskette mit einem geöffneten Schieber verwandelt.
In Verbindung mit dem Gimmick PHYSICAL-CURSOR gelingt es sogar, die diversen Desktopobjekte zu magnetisieren, da sich die Position der Objekte jetzt abfragen läßt.
In der nächsten TOS stelle ich Ihnen das vorerst letzte Gimmick dieser Serie vor. Dabei wird es, dem Monat Dezember entsprechend, sehr weihnachtlich und winterlich zugehen.
| TOS-Version | Adresse |
| 1.0 | $A0C4 |
| 1.2 | $C942 |
| 1.4 | $71E2 |
| 1.6 | $6E7C |
| Name | Bytes | Beschreibung |
| NEXT | 2 | Zeiger auf das nächste Objekt |
| HEAD | 2 | Zeiger auf das erste Kind des Objekts |
| TAIL | 2 | Zeiger auf das letzte Kind des Objekts |
| TYPE | 2 | Objekttyp (z.B. Icon $1F) |
| FLAGS | 2 | Darstellungsattr bute des Objekts |
| STATE | 2 | Status des Objekts (z.B. Bit 0 = Objekt ist selektiert) |
| SPEC | 4 | Ze ger auf zusätzliche Spezifikation z.B. Icon-Block |
| X | 2 | X-Position des Objekts |
| Y | 2 | Y-Position des Objekts |
| WIDTH | 2 | Breite des Objekts |
| HEIGHT | 2 | Höhe des Objekts |
Tabelle 2. Der Aufbau einer GEM-Objektstruktur
Meinolf Amekudzi