Für den ATARI ST existieren mehrere Emulatoren, die Soft- oder Hardware dazu bemühen, einen ST auf einer anderen Computerplattform nachzubilden. Besonders bekannt sind die Software- Emulationen MagiCMac für Apple-Computer, Gemulator und demnächst auch MagiCPC für IBM-kompatible PCs. Für den PC gibt es außerdem noch die Janus-Karte, die eine Hardware- Lösung darstellt. Inzwischen ist auch eine Emulation auf Software-Basis für UnixWorkstations ins Rampenlicht gerückt.

STonX nennt sich dieser Emulator und besonders interessant ist, daß die Quelltexte zu dem vollständig in C geschriebenen Programm frei verfügbar sind. Somit ist STonX prinzipiell in jeder Unix-Umgebung einsetzbar, sofern diese die heute üblichen Grundvoraussetzungen bietet. Insbesondere der GNU-C-Compiler und das X-Window-System sind erforderlich, um STonX zu installieren.

STonX emuliert einen ATARI ST mit 68000-Prozessor, bis zu 14 MByte Hauptspeicher und vorzugsweise TOS 2.06 als Betriebssystem. Das TOS kommt dabei in ungepatchter Form zum Einsatz und muß als Datei auf der Unix- Workstation abgelegt werden. Ohne ein geeignetes TOS-Image kann STonX nicht gestartet werden. Wer lediglich im Besitz von TOS 1.0 ist, kann beim Compilieren von StonX eine Kompatibilitätsoption wahrnehmen. Die Verwendung von TOS 2.06 ist jedoch zu empfehlen, um alle Möglichkeiten von STonX wahrnehmen zu können.
Da STonX komplett in C programmiert ist, sind Abstriche bei der Geschwindigkeit der Emulation von vornherein unvermeidlich. Gerade bei einer Prozessoremulation, wie sie den Kern von STonX bildet, lassen sich optimale Ergebnisse nur mit einem in Assembler geschriebenen Programm erzielen. Dennoch ist der Punkt, daß es sich bei STonX um ein reines CProgramm handelt, eher positiv zu werten. Nur so ist es nämlich möglich, STonX ohne Neuprogrammierung wesentlicher Bestandteile auf einer Vielzahl von Plattformen (auch zukünftigen) einsetzen zu können. AssemblerCode dagegen bringt den Verlust von Portierbarkeit mit sich und ist daher für Software, die plattformunabhängig sein soll, ungeeignet. Schließlich dürfte es nur wenige Programmierer geben, die in der Lage sind, den RISC- Prozessor einer Unix-Workstation mit Assembler-Code zu füttern. Dennoch sind in Assembler programmierte Versionen von STonX für bestimmte Plattformen im Gespräch (Alpha, Sparc, Intel).

Für diesen Bericht wurde versucht, STonX in der Version 0.6.5 auf den folgenden Plattformen zu installieren:

- SGI Iris Indy, IRIX 5.3, X11R6
- Sun UltraSparc 1, Solaris 2.5, X11R5
- Sun SparcStation 2, Solaris 2.5, X11R5
- IBM kompatibler PC, Linux 1.3.86, X11R6

Als Compiler kam in allen Fällen GCC 2.7.2 zum Einsatz. Da die Quellen zu STonX spezielle Eigenschaften des GNU-Compilers nutzen, lassen sich andere Compiler nicht verwenden. Dies dürfte aber keine besondere Hürde darstellen, denn GCC läßt sich auf wohl allen Unix-Plattformen installieren. Dazu sind nicht mehr Systemkenntnisse vonnöten als für die Installation von STonX ohnehin erforderlich sind. Wie immer enthalten die READMEs zu diesen Programmpaketen alle erforderlichen Informationen.
StonX ließ sich zwar auf allen aufgeführten Plattformen übersetzen, allerdings lief das Programm lediglich auf der Sun Workstation einwandfrei. Auf der SGI kam es zu einem Absturz während der TOS-Initialisierung, dessen Ursache bisher unbekannt ist. Unter Linux wurden die von STonX benötigten Fonts vom X- Window-System nicht akzeptiert. Da StonX jedoch bei anderen Anwendern unter Linux läuft, handelte es sich hier wohl um ein spezielles Problem der für diesen Test verfügbaren Linux-Installation.

Bei einer Betriebssystememulation sind zwei Aspekte besonders interessant. Wichtig sind die Kompatibilität zum emulierten System sowie die Geschwindigkeit der Emulation. Allgemein darf man davon ausgehen, daß sich ein System um so besser emulieren läßt, je ähnlicher die Hardware des Wirtssystems dem emulierten System ist. MagiCMac zeigt auf Apple Computern mit 68K Prozessor, daß bei halbwegs vergleichbarer Hardware eine hohe Kompatibilität bei hoher Geschwindigkeit erreicht werden kann. Auf Power Macs dagegen ist die relative Performance von MagiCMac in Anbetracht der Prozessorleistung der Power-PC-Prozessoren geringer. Dies liegt daran, daß hier der 68K-Prozessor emuliert werden muß, wobei Geschwindigkeitseinbußen unvermeidlich sind.
Unix-Workstations sind sowohl hinsichtlich ihrer Hardware als auch vom Betriebssystem her meilenweit von einem ATARI unter TOS entfernt. Sauber programmierte Anwendungs-Software für den ATARI ist inzwischen allerdings weitgehend hardwareunabhängig ausgelegt, sofern es sich nicht um systemnahe Programme handelt. Viele ATARIs sind inzwischen nicht mehr nur mit der ATARI-typischen Hardware ausgestattet, sondern weisen diverse Erweiterungen wie Grafikkarten oder Prozessorkarten auf. Die schon länger verfügbaren Emulationen, insbesondere MagiCMac, haben ein übrigens dazu getan, daß Software für den ATARI mehr und mehr auf das gezielte Ansprechen ATARI- spezifischer Hardware-Komponenten verzichtet.
Es ist daher zu erwarten, daß Software, die sich ausreichend an die üblichen Richtlinien für die Programmierung auf dem ATARI richtet, auch mit ungewöhnlicher Hardware klarkommt. Und in der Tat erweist sich diese Einschätzung in bezug auf STonX als zutreffend.

Die Installation von STonX wird dadurch erleichtert, daß ein Konfigurations- Script die vorhandene Plattform analysiert und dabei Vorbereitungen für den nachfolgenden Compiler-Lauf trifft. Compiliert wird mit einer besonders hohen Optimierungsstufe, um die Prozessorleistung später optimal auszunutzen. STonX unterstützt eine ganze Reihe von Startoptionen, die einerseits die Geschwindigkeit der Emulation in einem gewissen Rahmen beeinflussen, darüber hinaus aber auch für die Einbindung von Unix-Systemressourcen in die ATARI- Umgebung sorgen. So läßt sich festlegen, welche Unix-Verzeichnisse als Festplatten-Partitionen in die TOS-Umgebung gespiegelt werden sollen. (Bei Verwendung von TOS < 1.04 besteht diese Möglichkeit nicht.) Wer seine komplette ATARI-Systemumgebung unter STonX verfügbar machen will, braucht lediglich für jede Partition ein Unterverzeichnis anzulegen und alle Dateien der korrespondierenden Partition in dieses Verzeichnis zu kopieren. Wie schön, wenn man eine große Festplatte besitzt ... Lange Dateinamen, wie sie unter Unix und auch bei einigen Desktops für den ATARI möglich sind, werden bisher nicht unterstützt.
Die serielle und die parallele Schnittstelle des emulierten ST lassen sich auf beliebige Unix-Schnittstellen abbilden. Auf diesem Weg ist es möglich, aus STonX heraus Daten an einen an derworkstation angeschlossenen Drukker zu schicken. Für die direkte Ansteuerung der Unix-Schnittstellen, wie sie von STonX vorgenommen wird, müssen allerdings ausreichende Zugriffsrechte auf die korrespondierenden Gerätedateien vorhanden sein. Modems lassen sich aus STONX heraus mit RUFUS und CONNECT ansteuern, wobei die Schnittstellenparameter allerdings unter Unix eingestellt werden müssen und nicht unter STonX.
Die Umgebung von STonX in Form des GEM-Desktop wird in einem X11-- Fenster dargestellt. Die Bildschirmauflösung für das Desktop läßt sich beim Start von STonX frei wählen. Es sind also nicht nur die von einem "richtigen" ATARI her bekannten Auflösungen möglich, sondern auch beliebige andere. Hier hat STonX einem ATARI ST und selbst einem TT oder Falcon also einiges voraus. Die Darstellung kann unabhängig von der gewählten Auflösung in Monochrom oder in Farbe erfolgen. Selbst der Blitter wird von STonX emuliert. Sogar eine eingeschränkte ATARI-Sound-Routine stellt STonX zur Verfügung. Auf den gewohnten Tastaturklick muß man also nicht verzichten. Sound-Sampies lassen sich in der Regel allerdings nicht abspielen, da STonX nicht alle Timer des ST unterstützt.

Beim ATARI werden die Daten, aus denen sich der Bildschirminhalt aufbaut, von der Videologik direkt aus dem Hauptspeicher ausgelesen. Dies hat dazu geführt, daß einige Programme für den ATARI die Grafikdaten unter Umgehung des Betriebssystems direkt in diesen Speicherbereich schreiben, anstatt die hierfür vorgesehen Systemroutinen des VDI und AES zu benutzen. Solche Programme erweisen sich für STonX ähnlich problematisch wie für ATARIs mit Grafikkarten. Damit die Daten im Bildschirmspeicher des ATARI im X11-Fenster sichtbar werden, aktualisiert STonX periodisch die im Fenster dargestellten Grafikinformationen. Je häufiger dies geschieht, um so flüssiger wird der Grafikaufbau, aber umso langsamer wird die Emulation.
Um die Performance im Grafikbereich zu verbessern, hat sich der Autor von STonX etwas einfallen lassen. Alle grafischen Oberflächen bieten einen gewissen Vorrat an grafischen Grundfunktionen an, so auch GEM und das X-Window- System. Da GEM und X11 nicht verwandt miteinander sind, besitzen beide Systeme allerdings recht unterschiedliche Schnittstellen, was die Grafikprogrammierung angeht. Das hindert dennoch nicht daran, Aufrufe des ATARI-VDI auf äquivalente X11-Aufrufe umzulenken. Genau das geschieht bei STonX optional und führt zu einer deutlichen Beschleunigung der Grafikdarstellung von STonX, die die Emulation nicht unnötig verlangsamt. Sofern unter StonX Programme zum Einsatz kommen, die ihre Grafik sauber über das VDI des ATARI ausgeben, profitieren diese von der Umsetzung der Grafikroutinen auf Xll. Alle Grafikausgaben, die über diese Schnittstelle laufen, erscheinen in einem eigenen VDI-Fenster. Die so erreichte Geschwindigkeit läßt vergessen, daß es sich bei STonX eigentlich um eine Software-Emulation handelt. In der aktuellen Version von STonX gab es hin und wieder noch kleine Fehler in der Darstellung der Daten innerhalb des VDI-Fensters, die hoffentlich bald ausgeräumt werden.
Programme, die ihre Daten direkt in den Bildschirmspeicher des ATARI schreiben, profitieren natürlich nicht von diesem intelligenten Mechanismus. So kommt es, daß beispielsweise Tempus Word keine Ausgaben innerhalb des VDI- Fensters tätigt, sondern ausschließlich den "normalen" Emulations-Bildschirm anspricht. Wordplus hingegen stützt sich ausschließlich auf die Routinen des VDI und profitiert so vom VDI-Fenster. Ein Teil dieses Artikels wurde übrigens mit Wordplus und STonX geschrieben. Es ist schon ein eigenartiges Gefühl, einerseits die gewohnte Unix-Umgebung vor Augen zu haben, andererseits aber durch einen Wechsel des Fensters unter STonX in die Tasten hauen zu können.

Läßt sich die Geschwindigkeit der Grafikdarstellung unter STonX durch die VDI- Option auf jeder Wirtsplattform merklich steigern, gilt dies nicht für die eigentliche Prozessoremulation. Die Geschwindigkeit der eigentlichen Emulation hängt direkt von der Rechenleistung der Workstation und in einem gewissen Rahmen auch vom verfügbaren Hauptspeicher ab. Ist nur wenig Hauptspeicher vorhanden, so daß es unter STonX dazu kommt, daß Daten auf die Festplatte ausgelagert werden, läßt sich die Emulation nicht sinnvoll einsetzen. Mindestens 32 MByte Hauptspeicher sollte die Workstation aufweisen, damit ein Arbeiten mit STonX möglich ist.
Auf die Messung von Benchmarks habe ich bewußt verzichtet. Selbst bei "echten" ATARIs ist umstritten, welcher Stellenwert welchem Benchmark-Programm beizumessen ist. Bei einer Software-Emulation läßt sich noch weniger eine brauchbare Aussage über die Performance machen. Die Hardware der Unix- Workstation kann das Ergebnis in jede beliebige Richtung verfälschen. Es gibt nahezu beliebig viele Kombinationen zwischen Betriebssystemen, Prozessoren, Taktfrequenzen, Speicherausbau, Caches und Grafikkarten. Auf einer Sun UltraSparc 1 erschien STonX schneller als ein mit 8 MHz getakteter ST. Eine SparcStation 2 eignet sich weniger als Plattform für STonX und erreicht eine Geschwindigkeit, die in etwa dem entspricht, was man für einen mit 4 MHz getakteten ST erwarten dürfte. In allen Fällen spielt es eine große Rolle, ob man die Option zur Grafikdarstellung im VDI-Fenster nutzt oder auf die Standard- ausgabe angewiesen ist.

Wenn es darum geht, die Kompatibilität von STonX auf den Prüfstand zu stellen, wird man bekannte Programme für den ATARI nehmen und diese unter der Emulation starten. Dabei wird einem bewußt, daß das SoftwareAngebot für den ATARI auch weiterhin nicht zu verachten ist. Daher konnte es bei den durchgeführten Kompatibilitätstests nur bei Stichproben bleiben. Software, die keine unsauberen Tricks verwendet und sich der dokumentierten Systemaufrufe bedient, bereitet STonX kaum Probleme. Eine recht umfangreiche Kompatibilitätsliste ist per WWW verfügbar (s.u.). In dieser Liste sind neben textorientierten Anwendungen auch Spiele aufgeführt, wobei sich nurdie wenigsten mit STonX vertragen. Der Grund hierfür ist leicht zu nennen: Gerade bei Spielen wird besonders tief in die Trickkiste gegriffen, und das Betriebssystem wird in der Regel vollständig umgangen. Denkbar schlechte Voraussetzungen also für eine Emulation, egal ob per Hard- oder Software.
Allgemein fiel auf, daß manche Programme unter STonX selbst dann nicht von den Vorteilen des VDI-Fensters profitieren konnten, wenn es sich nicht um systemnahe Anwendungen handelte. (Für systemnahe Software kommt die Benutzung des VDI nicht immer in Frage.) Hier trennt sich wieder einmal die Spreu vom Weizen, und es zeigt sich, daß sich das Umgehen von Systemroutinen früher oder später rächt. So mancher Programmierer wäre heute sicherlich froh, hätte er gar nicht erst zu irgendwelchen Tricks gegriffen, die ursprünglich "genial" erschienen und nun dafür sorgen, daß seine Software sich nicht mit MagiC, MagiCMac oder auch STonX verträgt.
Bei manchen Programmen zeigten sich kleine Unstimmigkeiten, beispielsweise Redraw-Fehler im VDI-Fenster, die darauf hindeuten, daß noch einige Bugs in STonX zu beseitigen sind. So konnte PURE C 1.1 nicht korrekt auf den Inhalt von Header-Dateien zugreifen, das Desktop Thing hatte leichte Probleme bei der Darstellung von Datum, Uhrzeit und Dateilänge in den Fenstern des Desktops. Wordplus, Edison, Papilion und Interface hatte keine offensichtlichen Probleme. Systemnahe Programme wie SYS-MON oder Tempelmon akzeptieren STonX nicht. Der Pure Debugger dagegen zeigte sich weniger kritisch, auch wenn es hier noch zu Fehlern bei der Bildschirmdarstellung kam.

Da die C-Quelltexte von STonX frei verfügbar sind, dürfte sich STonX unter Linux nicht nur auf IBM-kompatiblen PCs, sondern auch auf einem ATARI compilieren lassen. Somit hätte man das, auf das viele bereits seit längerem warten: Die Möglichkeit nämlich, TOS-Software auch unter Linux auf dem ATARI zu verwenden. So vielversprechend dies auch klingen mag, STonX ist dafür nicht die geeignete Lösung. Die Abstriche, die man bei der Geschwindigkeit der Emulation machen muß, lassen ein ernsthaftes Arbeiten in dieser Umgebung nicht als sinnvoll erscheinen. Ein TT ist schlichtweg zu langsam, um unter Linux vernünftig mit STonX arbeiten zu können. Hier wird man also weiterhin auf eine TOS-Emulation warten müssen, bei der der Prozessor nicht durch C-Code emuliert wird, sondern direkt TOS-Programme ausführt. Mit Sicherheit keine leichte Aufgabe.
Wer nun neugierig geworden, aber nicht sicher ist, ob seine Hardware einen sinnvollen Einsatz von STonX erlaubt, sollte dies einfach ausprobieren. Selbst wenn sich zeigt, daß die eigene Hardware zu schwachbrüstig ist, um eine vernünftige Geschwindigkeit für die Emulation zu erreichen, muß das nicht lange so bleiben. So sehr die Schnellebigkeit im Computerbereich auch von Nachteil ist, in bezug auf STonX kann sie nur von Vorteil sein. Von jedem schnelleren Prozessor wird die Emulation direkt profitieren. Dabei stellt die freie Verfügbarkeit der Quelltexte von STonX sicher daß sich ein ATARI auch auf viele zukünftigen Unix-Plattformen emulieren lassen wird. Somit präsentiert sich StonX trotz einiger Schwächen als ein faszinierendes Programm, dem man unbedingt Beachtung schenken sollte.

Kontakt Artikel-Archiv