Programmiererecke: Fertig - oder nicht?
Man mag es kaum glauben: MultiTOS und SpeedoGDOS werden seit Ende April tatsächlich verkauft - zum erfreulich niedrigen Preis.
Doch die Freude darüber wird durch einige Wermutstropfen getrübt. Das MultiTOS 1.0, das Atari mit MiNT 1.04 ausliefert, ist erwartungsgemäß kein wahrer Sprinter.
Das ist nicht weiter verwunderlich: mehrfach schon hat Atari darauf hingewiesen, daß MultiTOS auf Rechnern mit 68000er-Prozessoren so langsam arbeitet, daß der Hersteller selbst von der Verwendung abrät.
Auf schnelleren Rechnern wie beispielsweise dem TT oder dem Falcon 030 ist zwar ein erfreulicher Performancegewinn zu verzeichnen. Wer jedoch die enorme Geschwindigkeit eines Systems wie »Mag!x« gewohnt ist, wird feststellen, daß ein handcodierter Assembler auf CISC-Prozessoren eben doch um vieles schneller arbeitet.
Optimierbedarf bei MultiTOS
Die unter Unix-Programmierern verbreitete Attitüde, sinnvoll erscheinende Erweiterungen ins System zu implementieren, ohne sich dabei über die Geschwindigkeit Gedanken zu machen, findet hier jedoch ihr rasches Ende: Hersteller wie »Sun« oder »DEC« begegnen dieser Angst um die Systemperformance mit immer schnellerer Hardware.
DEC hat unlängst auf der CeBIT PCs mit dem RISC-»Alpha«-Chip vorgestellt, der mit einem Takt von 150 MHz arbeitet. Atari dagegen bietet seit Jahren an der High-End-Front nichts schnelleres als den TT. Ein schnelleres System wäre aber zumindest für die High-End-User wünschenswert, ist jedoch nicht absehbar.
SpeedoGDOS hingegen ist ein für den Alltag hilfreiches Tool, das gemessen am Erstversuch »FSMG-DOS« eine ungeahnte Geschwindigkeit an den Tag legt, was das Programm auch für Benutzer älterer STs und STEs attraktiv macht.
Leider hat Atari auch dieses, prinzipiell sehr gute System, nicht ganz zuende entwickelt.
Zunächst trägt das ausgelieferte SpeedoGDOS ein Erstellungsdatum vom Januar 1993. Es bleibt die Frage, weshalb nicht neuere Versionen ausgeliefert werden; vor allem, da das Januar-Speedo zumindest einen deftigen Fehler enthält, der in späteren, Entwickler zugänglichen, Versionen beseitigt wurde.
Es gibt aber noch weitere kleine Fehler und Bugs, die innerhalb kurzer Zeit hätten beseitigt werden können: Zum Beispiel verwendet SpeedoGDOS zur Bildschirmausgabe grundsätzlich die Line-A-Blitroutinen. Diese Routinen werden jedoch nicht von allen Bildschirmtreibern unterstützt. Weiterhin hätten die entsprechenden VDI-Funktionen von Systemen wie »NVDI« weitgehend beschleunigt werden können, im Falle der Line-A-Funktionen hält sich diese Beschleunigung jedoch in Grenzen.
Das Argument, man müsse durch die Verwendung der Line-A-Routinen keine Texteffekt-Routinen in Speedo einbauen, ist schwer verständlich, zumal selbst lasch codierte Effektroutinen kaum mehr als drei bis vier Kilobytes groß sein dürften.
Es ist, wie bereits in der letzten Ausgabe berichtet, kein klares Konzept zur Verwaltung von Bitmap-Fonts erkennbar. Die alten Treiber werden nicht automatisch erkannt, ID-Doppelbelegungen werden nicht vermieden und das Namenskonzept ist unausgereift.
Rasterfonts im Intel-Format mag SpeedoGDOS gar nicht - sie verursachen einen Absturz.
Speedo-Fonts mit unbekannten Encryptions ziehen unter Umständen ebenfalls Abstürze oder verwirrende Fehlermeldungen nach sich.
Die Druckertreiber und »MEMORY.SYS« kommen nicht mit Farbausgaben zurecht und unterstützen weder Multicolor-Patterns noch Rasterfunktionen. Zumindest letzteres ist aber dokumentiert und somit kein echter Bug.
Manche Treiber können nicht resident gehalten werden.
Schließlich lädt Speedo bei jedem Aufruf von »vst_load_fonts()« die komplette Font-Liste aus der »EXTEND.SYS«-Datei - sie könnte sich verändert haben.
Wildes Nachladen
Das geschieht aber in der Praxis nur alle Jubeljahre und selbst wenn, könnte SpeedoGDOS noch immer einen Vergleich der bereits geladenen Fonts mit den abonnierten durchführen.
Stattdessen lädt Speedo alle Font-Header bei jedem »vst_load_fonts()«, was bei 200 Fonts zweieinhalb(!) Minuten dauert. Insbesondere unter MultiTOS, wo ständig Prozesse Fonts nachladen, nervt dieses Vorgehen sehr.
Schon bei mehr als 20 Fonts macht sich dieses Nachladen beim Start jedes Programmes unangenehm bemerkbar.
Und schließlich wünscht man sich ein reentrantes VDI oder gar AES, damit zumindest während eines solchen »vst_load_fonts()«-Aufrufes nicht das ganze System angehalten würde.
Ob Atari sich nun an die Arbeit am System macht? Noch bleibt Zeit, um bis zum Weihnachtsgeschäft alle Kritikpunkte zu bereinigen.
Trickreiche Schleichwege
Schon in den vergangenen Monaten haben wir immer wieder beklagt, daß der MEMORY.SYS-Treiber sich nicht resident halten läßt.
Daran hat sich unseres Wissens nach wie vor nichts geändert, jedoch weisen wir an dieser Stelle auf ein Verfahren hin, mit dem die Größe der bereits geöffneten Drucker-Workstation nachträglich geändert werden kann [1].
In der VDI-Dokumentation werden fünf erweiterte Betriebssystem-Aufrufe vorgestellt, die die Arbeit mit einigen, speziellen Treibern erleichtern.
1. Übergabe einer neuen Auflösung beim Öffnen einer Druckerschnittstelle.
Diese Funktion ist nur für Matrixdrucker dokumentiert, sie findet sich jedoch auch in anderen Treibern.
Ein modifizierter »v_opnwk()«-Aufruf gestattet es, x- und y-Auflösung an den Treiber zu übergeben.
Die Belegung der Parameterfelder (Achtung, die fett erscheinenden Felder haben sich geändert):
contrl[0] := 1
contrl[1] := 1
contrl[2] := 6
contrl[3] := 11
contrl[4] := 45
contrl[6] := handle
intin[0..10] := work_in[0..10]
ptsin[0] := x-Auflösung
ptsin[1] := y-Auflösung
VDI-Aufruf
intout[0..44] := work_out[0..44]
ptsout[0..11] := work_out[45..56]
2. Übergabe eines neuen Puffers an den Druckertreiber.
Diese Funktion ist dokumentiert für alle Treiber. Sie gestattet es dem Programmierer, einen eigenen Puffer per »Malloc()« zu belegen und ihn als Ausgabepuffer dem Treiber zur Verfügung zu stellen.
Dazu dient ein modifizierter »v_updwk()«-Aufruf. Die Parameterfelder (auch hier haben sich Änderungen ergeben, sie erscheinen fett):
contrl[0] := 4
contrl[1] := 1 Puffer Löschen? 1: Nein, 0: Ja
contrl[2] := 0
contrl[3] := 2
contrl[4] := 0
contrl[6] := handle
intin[0] := High-Word der Pufferadresse
intin[1] := Low-Word der Pufferadresse
ptsin[0] := x-Auflösung
ptsin[1] := y-Auflösung
VDI-Aufruf
3. Erfragen des momentan gesetzten Printerpuffers.
Dokumentiert ist dieser Zusatz nur für den »SLM 804« Lasertreiber, vorhanden ist er jedoch auch in anderen Treibern.
Der unmodifizierte »v_opnwk()«-Aufruf liefert in »contrl[0]« und »contrl[1]« einen Zeiger auf den benutzten Speicherbereich zurück.
Do it yourself
Achtung: einige Bindings, insbesondere die von »Pure C«, löschen vor dem Aufruf der nächsten VDI-Funktion die High-Bytes in den Words des »contrl []«-Feldes nicht ordnungsgemäß. Es ist deshalb dringendst zu empfehlen, dieses Feld unmittelbar nach dem Auslesen explizit zu löschen.
Die Parameterfelder, ähnlich wie oben:
contrl[0] := 1
contrl[1] := 0
contrl[2] := 6
contrl[3] := 11
contrl[4] := 45
contrl[6] := handle
intin[0..10] := work_in[0..10]
VDI-Aufruf
intout[0..44] := work_out[0..44]
ptsout[0..11] := work_out[45..56]
contrl[0] := High-Word der Adresse des vom Treiber angeforderten Puffers
contrl[1] := Dazugehöriges Low-Word
4. »Escape 2000«-Funktion.
Mit ihr lassen sich Mehrfachkopien der zuletzt auf dem Drucker ausgegebenen Seite erzeugen. Da sie nur für Atari-Laser dokumentiert ist und von Matrix-Druckertreibern ignoriert wird, ist der Wert dieser Funktion zweifelhaft. Die Feldbelegung:
contrl[0] := 5
contrl[5] := 2000
intin[0] := Anzahl der gewünschten Duplikate
VDI-Aufruf.
Es muß ein »v_updwk()«-Aufruf folgen, um den Druckvorgang zu starten.
5. Status des Druckers erfragen.
Der SLM 804-Treiber gibt nach jedem »v_updwk()«-Aufruf den Status des Druckers zurück. Diese Funktion ist offiziell nur in diesem Treiber implementiert. Wir haben sie bisher auch nur dort aufgespürt. Falls es jemandem doch gelungen sein sollte, diese Funktion auch auf anderen Treibern zu lokalisieren, nehmen wir Hinweise gern entgegen.
Nach dem »v_updwk()«-Aufruf befindet sich der Fehlerstatus in intout[0].
Bislang sind folgende Werte dokumentiert:
0 Kein Fehler
2 Drucker kaputt/nicht aufgeheizt/Klappe geöffnet
3 Toner leer
5 Papier ausgegangen
Es sei an dieser Stelle darauf hingewiesen, daß nicht alle SLM-Drucker wirklich die korrekten Fehlercodes zurückliefern. Es scheint, als ob das nur bestimmte Laserinterfaces (SLM C804) tun. Auskunft gibt bei manchen Laser-Interfaces ein auf der Unterseite angeklebter grüner Punkt (!), ein runder grüner Aufkleber. Also: Ausprobieren und auf den grünen Punkt achten.
uw
Literatur:
(1] »GEM Programmer’s Guide, Volume 1: VDI«, Atari Corp. Sunnyvale, Third Edition, 1989, J-15, »New, Added Features Of Drivers«.
Laurenz Prüßner