Atarium: Atari mit neuem Schwung

Noch im letzten Monat ließ ich an gleicher Stelle meiner Enttäuschung über die mangelnde Pflege der ST-Serie durch Atari freien Lauf. Nun ist die CeBIT zu Ende und der Autor dieser Kolumne — hauptberuflich Atari-Fan mit Leib und Seele — wieder ein bißchen zufriedener. Woher dieser Sinneswandel?

TOS 1.4 hoffentlich bald allgemein erhältlich

Nun, auf das neue Paradepferd TT muß die Atari-Gemeinde wohl noch bis zur Düsseldorfer Atari-Messe warten. Immerhin bekamen ausgesuchte Besucher eine Entwicklungsmaschine zu sehen — noch im abstoßend häßlichen AT-Gehäuse. Auch einige der auf dem Atari-Stand vertretenen Softwareanbieter erhielten kurz Gelegenheit, ihre eigenen Produkte auf dem TT-TOS auszuprobieren. Zu diesem Thema später mehr.

Alle anderen angekündigten Neuigkeiten waren jedoch zu sehen. Und das Beste: Alle gezeigten Geräte sollen bis zum Sommer lieferbar sein.

Ataris neue Hardware

Da wäre beispielsweise der neue 19-Zoll-Monitor »SM 194«, basierend auf der Grafikkarte des amerikanischen Herstellers Moniterm, die Wechselplatte »Megafile 44«, mit dem bereits von Fremdanbietern bekannten Syquest-Innenleben, und das CD-ROM, für das es tatsächlich demnächst auch Software geben soll. Selbst der Laptop wurde gezeigt — zwar noch mit einem provisorischen LC-Display — in der endgültigen Version soll das Display weiß und von hinten beleuchtet sein. Der Preis und das nicht eben geringe Gewicht wird zwar vielen Interessenten schwer im Magen liegen. Aber immerhin, zusammen mit »Aladin« oder »Spectre 128« kauft man damit bei Atari den preiswertesten portablen Mac. Durch ein Versehen ist es glücklicherweise bei der Bezeichnung »Stacy« geblieben... Schluß mit den kryptischen Produktbezeichnnungen!

Auch von der Systemsoftware-Front sind Fortschritte zu vermelden. Nach langer Pause gibt es eine neue Beta-Testversion von »TOS 1.4«, die nach Aussagen von Atari die »letzte vor der endgültigen« sein soll. Anderer Meinung waren einige Vertreter von Atari Deutschland, die bereits diese Version für die fertige hielten. Auf jeden Fall kann keine Rede davon sein, »TOS 1.4 sei nicht offiziell gezeigt worden«. Offensichtlichste Neuerung: Im Farbmodus wird das Atari-Symbol der Copyright-Meldung von einem Regenbogen durchlaufen. Neues auch beim Festplatten-Treiber: In der auf dem Messestand laufenden Version kam er absolut problemlos mit dem Wechseln der Platte in der Megafile 44 zurecht. Und die leidige Vier-Partition-Schranke ist angeblich auch weggefallen. Auf ein neues GDOS mit Font-Swapping (Benutzer eines Laserdruckers oder eines 24-Nadel-Druckers benötigen es dringend) muß man wohl noch eine Weile warten: Die meisten Atari-Offiziellen konnten sich bislang noch nicht für eine Weiterentwicklung von »AMCG-DOS« begeistern. Wer Interesse hat, schreibe doch einen Brief an Atari in Raunheim — vielleicht hilft’s.

Von vielen Laser-Besitzern schon dringend erwartet, soll es nun auch bald »Ultrascript« (Ataris Postscript-Emulation) geben. Unbestätigten Gerüchten zufolge sind bei diesem Projekt auch eine Reihe schicker GDOS-Fonts abgefallen.

Als Vertreter der Software-Entwicklung waren dieses Mal Leonard Tramiel (TOS 1.4) und Roy Good (UNIX) auf der Messe vertreten. In einer beeindruckenden Rede nahm Tramiel während einer Aussteller-Konferenz zum aktuellen Stand der Software-Entwicklung auf dem ST Stellung. Hier eine Zusammenfassung der wichtigsten Punkte:

— Tramiel gab seiner Enttäuschung darüber Ausdruck, daß sehr viele deutsche Programmierer unsauber programmieren. Dazu gehört in erster Linie, daß fast alle professionellen Programme ausschließlich im hochauflösenden Modus laufen, was einen Erfolg auf dem amerikanischen Markt praktisch verhindert. Ebenso würden viele Programme, die wie ordentlich programmierte GEM-Anwendungen aussehen, auf dem TT-TOS nicht laufen. - Zum Vorwurf, im TOS seien viele Routinen nicht gerade eben optimal programmiert: Die Platzprobleme im ROM erlauben es nicht, jede Optimierung auch zu implementieren. Ferner sei es nur an wenigen Stellen möglich, schnellere Routinen mit gleicher Flexibilität (Stichwort: Proportionalschrift und BitBlt-Routinen) zu schreiben. Und schließlich seien auch die Atari-Systemprogrammierer nur Menschen mit Fehlern — daher nehme Atari jeden Optimierungsvorschlag gerne entgegen. - Besonders erbost zeigte sich Tramiel darüber, daß immer wieder die wenigen bestehenden Programmierregeln gebrochen werden. »Wären wir gemein, dann hätten wir bei jeder neuen TOS-Version alle nicht-dokumentierten Eigenschaften geändert — aber wir sind ja nicht gemein.« Folgende drei gute Gründe zum Schreiben sauberer fensterorientierter Programme führte Tramiel an: den neuen 19-Zoll-Monitor von Atari, die Matrix-Farbgrafikkarte und schließlich die drei neuen Auflösungen des TT, denn wer möchte schon einen 68030-Computer nur mit den ST-Auflösungen nutzen?. Diese Liste läßt sich noch leicht verlängern: Kompatibilität mit »BigScreen«, »Protos« und unsere Hyper-Screen-Umrüstung (siehe diese Ausgabe). Ob Tramiel wohl das »offizielle Atari-Basic« von Atari Deutschland kennt. Ein bißchen Vorbildrolle könnte wirklich nicht schaden, Atari!

Portabilitätsprobleme

Vom neuen Wind aus der Atari-Spitze beflügelt, machte ich mich auf den Weg durch das Getümmel auf dem Atari-Stand, um endlich der brachliegenden GEM-Zwischenablage zum Durchbruch zu verhelfen. Nur wenige Softwarehäuser zeigten sich überhaupt nicht kooperativ. Zweimal wurde mir sogar vorgeworfen, dieses Engagement könnte nur durch eigene finanzielle Interessen zu erklären sein: Traurig, daß manche Menschen offenbar nur innerhalb ihres Profitdenkens handeln. Vergessen wir die Unbelehrbaren und kommen zu den Pionieren des neuen »Back-to-GEM«-Trends:

Die Firma SciLab präsentierte einen Hybrid zwischen Geschäftsgrafik- und Zeichenprogramm (natürlich voll unter GDOS). Für die endgültige Fassung wurden feste Im- und Exportfunktionen für Metafiles und Textinformationen über die Zwischenablage zugesagt. Thomas Tempelmann (»Megamax Modula«) und Peter Viczena (»SPC-Modula«) versprachen jeweils für die neuen Versionen ihrer Editoren die Unterstützung der Zwischenablage für Textinformationen. Bei SPC-Modula ist übrigens auch eine Integration von »Turbo-C« in die Modula-Umgebung in Arbeit. Bavariasoft kündigte an, das Clipboard in künftigen Programmversionen an allen sinnvollen Stellen zu nutzen. Clipboard-Unterstützung für Bildausschnitte gibt es auch in den kommenden Versionen von »Creator« und »Imagic« (Application Systems). Weitere feste Zusagen erhielt ich von Heimsoeth für den Turbo-C-Editor und von Victorsoft für künftige Versionen von »1st Adress«.

Hinzu kommen natürlich die wenigen Programme, die bereits jetzt die Zwischenablage nutzen: die Testversion von »1st Word Plus« und »Interlink« von Bela.

Für den Anfang ist dies sicherlich eine beeindruckende Liste — besonders angesichts der Tatsache, daß wir aus Zeitmangel nicht mal alle Programmierer fragen konnten. Je mehr Programmierer sich diesem Standard anschließen, desto größer wird der Druck auf den verbleibenden Rest!

Nachdem seit der ersten Ankündigung ein Jahr vergangen ist, stellte die süddeutsche Firma X/Software ihr X-Window-System für den ST vor. »X/ST/Window« macht den ST zum extrem preiswerten Terminal für UNIX-Workstations unter dem Grafik-Standard »X-Windows«. Besonders Universitäten nutzen den ST häufig als Text-Only-Terminal. Wir berichten ausführlich, sobald wir X/ST/Window testen können.

Schließlich hat sich auch mal wieder etwas auf USENET (dem UNIX-Rechnernetz) getan. Ken Badertscher (Softwareentwicklung bei Atari Sunnyvale) hat mit nun fast zwei Jahren Verspätung einige der neuen Systemvariablen aus dem Blitter-TOS halboffiziell dokumentiert [1] — wie heißt es doch so schön: »Beta late then never«. Eine Zusammenfassung des kurzen Textes finden Sie in unserem Textkasten.

Weiterhin wurde darauf hingewiesen, daß das Format der DESKTOP.INF-Datei nie dokumentiert wurde und »subject to sudden change« ist, sich also jederzeit ändern kann. Programmierer sollten also darauf verzichten, aus der DESKTOP.INF-Datei Informationen zu entnehmen oder diese gar zu verändern. Weiterhin sind natürlich auch die AES-Aufrufe »shel_get()« und »shel_put()« (zum Auslesen und Ändern des AES-Buffers für DESKTOP.INF) davon betroffen. Meine Meinung dazu: Es wäre besser gewesen, das Format endlich offiziell zu dokumentieren und in Zukunft unter Wahrung der Kompatibilität zu erweitern - man denke an diejenigen, die abwechselnd mit mehreren Betriebssystemversionen arbeiten möchten.

Ferner hat sich Mr. Badertscher endlich der Diskussion über ein Standardformat zur Übergabe erweiterter Kommandozeilen angenommen. Bereits vor fast einem Jahr [3] hatten wir das von Dale Schumacher und Allan Pratt (Systemprogrammierer bei Atari) favorisierte »xArg«-Verfahren vorgestellt. Leider war die Resonanz bis heute recht gering — die etabliertere »PBP/ARGV«-Methode, die von Mark Williams und Beckemeyer Development Tools benutzt wird, hat hier den Fortschritt gebremst. Die »xArg«-Methode hat zumindest den unbestrittenen Vorteil, daß sie das Environment nur auf saubere Art und Weise nutzt. Mit dem Streit soll nun bald Schluß sein - nach erfolgreicher Diskussion auf USENET will Atari endlich einen verbindlichen Standard formulieren und dann auch unterstützen. Egal wie dieser am Ende aussieht: Besser eine mittelmäßige Methode, die von allen benutzt wird, als lauter Programme, die gar nicht zueinander passen.

Auch Allan Pratt (GEMDOS-Programmierer) hat wieder wichtige Informationen veröffentlicht [2]. Wer schon immer wissen wollte, wie man aus Interrupts BIOS- oder XBIOS-Aufrufe bewerkstelligt, betrachte ebenfalls den Textkasten. Hoffen wir, daß der neue Schwung bei Atari anhält. (uh)

Literaturnachweis:

[1] Ken Badertscher, Info-Atari16, Issue 78/89

[2] Allan Pratt, Info-Atari16, Issue 61/89

[3] Julian Reschke, »Schranken durchbrechen«, ST-Magazin 7/88

BIOS-IO-Vektoren BIOS- und XBIOS-Aufrufe aus Interrupts

GEMDOS nimmt sämtliche Zeicheneingaben und -ausgaben über das BIOS vor. Das BIOS hat eine im RAM liegende Vektortabelie für die einzelnen Routinen, die es benutzt.

Ab Adresse $51E finden sich je vier mal acht Vektoren für die Zeichenoperationen:

xconstat: .ds.l 8 ; ($51e) console status vectors
xconin: .ds.l 8 ; ($53e) console input vectors
xcostat: .ds.l 8; ($55e) console output-status vectors
xconout: .ds.l 8 ; ($57e) console output vectors

Jede dieser vier Strukturen besteht aus den Adressen der Routinen, die die BIOS-Geräte bedienen (PRT (0), AUX (1), CON (2), MIDI (3), IKBD (4), RAWCON (5); Geräte 6 und 7 sind reserviert). Die »Output Status«-Routinen für MIDI und IKBD sind vertauscht Das war schon immer so und wird aus Gründen der Kompatibilität so bleiben.

Entgegen anderslautender Behauptungen sind die BIOS- und XBIOS-Funktionen im TOS »reentrant«, das heißt, man darf sie auch innerhalb von Interrupts aufrufen. Dazu bedient man sich der Systemvariable »savptr« ($4a2), die auf den Speicherbereich zeigt, in dem der Trap-Dispatcher die Register des aufrufenden Programms zwischenspeichert. Jeder TRAP überschreibt die 46 auf diese Anfangsadresse folgenden Bytes.

Beim Aufruf aus Interrupts muß man also genau diese Konstante zunächst von »savptr« subtrahieren, um sie dann nach dem TRAP wieder zu addieren.


Julian F. Reschke
Links

Copyright-Bestimmungen: siehe Über diese Seite
Classic Computer Magazines
[ Join Now | Ring Hub | Random | << Prev | Next >> ]