Das Jahr des Falken

Der Falcon ändert allerhand für die Programmierer. Zwar tröpfeln Dokumentationen spärlich, doch ist vieles bereits auf den ersten Blick anders.

Als erster Rechner von Atari verfügt der Spatz über einen Videospeicher, der die Farbbestimmung nicht mehr ausschließlich über Lookup-Tables vornimmt, sondern im sogenannten »Direct Color Mode« arbeiten kann, den Atari gern »True Color Mode« nennt. Unter »True Color« wollen wir aber weiterhin eine Farbauflösung von mindestens 16 Millionen verschiedenen Farbtönen bezeichnen - und davon ist der Falcon mit seinem 16-Bit-Videomodus weit entfernt.

Die Integration dieser neuen Hardware ins bestehende VDI besorgt eine Pseudo-Color-Lookup-Table (Pseudo-CLUT), in die beim »vs_color()« eingetragen oder beim »vq_color()« ausgelesen wird. Bei jedem Ausgabebefehl liest das VDI diese Pseudo-CLUT aus und verwendet die darin enthaltenen Farbwerte zum Blitten in den Bildschirmspeicher. Mit dem Effekt, daß sich ein »vs_color()«-Aufruf nicht mehr sofort auf den Bildschirminhalt auswirkt, sondern erst beim Neuzeichnen eines VDI-Farbstiftes neue Farben gezeichnet werden.

Die erste Veränderung gedieh der Funktion VS-coloration. Während die konventionellen Ataris nämlich ihre Farben über eine Color-Lookup-Table (CLUT) bestimmen, die beispielsweise im TT-Low-Modus 256 Einträge besitzt, bieten die direct-Color-Modes des Falcon 030 eine solche Möglichkeit nicht mehr kein Wunder, sie müßten bis zu 64k Einträge umfassen.

Deshalb benutzt Ataris NTC-VDI »virtuelle« CLUTS mit 256 Einträgen, die jedoch nur im RAM bestehen und keine Hardwareregister beeinflussen. Bei jeder VDI Ausgabefunktion sieht das OS in dieser »virtuellen« CLUT nach und errechnet die in den Videospeicher zu schreibenden Werte anhand dieser Tabelle. Das hat tiefgreifende Auswirkungen.

Zum einen wirft es das Konzept sämtlicher konventioneller Farbskalierer über den Haufen, weil diese nun nur noch RAM-Tabellen verändern, auf den aktuellen Bildinhalt jedoch keinen Einfluß mehr haben. Was auf dem Bildschirm mit der VDI-Farbe »WHITE« gezeichnet wurde, verändert seine Farbe beim »Herumsliden« im Farbkontrollfeld nicht mehr. Erst beim Neuzeichnen, ausgelöst durch eine Redraw-Meldung, wird die neue Einstellung übernommen. Das kann zu äußerst unschönen Effekten führen. Das Beta-VDI, das mit den ersten Entwickler-Falcons nach Deutschland kam, verhielt sich darüber hinaus sehr eigenartig beim Ertragen der aktuellen Farbeinstellung via »vq_color()«: Bis zur VDI-Farbintensität 500 funktionierte alles einwandfrei, danach lieferte » vq_color()« für den Rotanteil negative Werte zurück.

Ein anderes Problem ist die Funktion »vr_daten()«, die nun erheblich mehr Pixel-Schiebereien zu erledigen hat und entsprechend langsamer arbeitet. Sie war im Beta-VDI fehlerhaft, was uns an dieser Stelle jedoch nicht zu beunruhigen braucht.

Schwierig funktioniert nun auch die Betrachtung der VDI-Schreibmodi. Der »XOR«-Modus arbeitet momentan bitweise im Video-RAM, was zu Verwirrungen führt. So ergab »WHITE XOR BLACK« bislang immer die VDI-Farbe »BLACK« und »BLACK XOR BLACK« immer die VDI-Farbe »WHITE«. Nun muß die VDI-Farbe »WHITE« jedoch nicht immer Weiß sein, sie kann durch das Kontrollfeld einen anderen physikalischen Farbwert zugewiesen bekommen haben, beispielsweise ein helles Blau. Bei einem bitweisen XOR wird »BLACK XOR BLACK« jedoch nicht das Hellblau der VDI-Farbe »WHITE« ergeben.

Zur Zeit der Drucklegung war nicht entschieden, ob dieser ernsthafte konzeptionelle Fehler noch beseitigt werden wird. Wer jedoch bedenkt, welche unschöner Effekte sich allein schon beim Aufziehen einer Dragbox auf dem Desktop ergeben können, wird sich dies sehr wünschen.

Viel extremer erscheinen die Probleme bei der Realisation der VDI-Rasterkopierfunktionen. Atari hat mit VDI eine große Vielfalt von Kopiermodi zur Verfügung gestellt, die nun Probleme bei der Realisation unter einem direct-color-VDI bereiten dürften.