Omikron.Basic 4.0 - TT erwünscht?

center

OMIKRON.BASIC kennen wohl die meisten ATARIaner. Als die Sprache, die seit Jahren jedem ATARI kostenlos beiliegt (ST) oder als Ärgernis, dessen, besonders im PD-Bereich, doch recht verbreitete Erzeugnisse nicht auf dem Computer laufen (TT). Dies soll nun anders werden, versprach OMIKRON., das Ergebnis testen wir hier.

Noch zunächst ein Wort zur Produktpolitik der Fa. OMIKRON. Lag der Interpreter jedem ST noch kostenlos bei, mußte der Compiler extra nachgekauft werden. Ein einträgliches und auch sinnvolles Geschäft, von dem sowohl ATARI und OMIKRON. als auch der Kunde profitieren. Mit dem Erscheinen der Turbokarten stellte dann die glückliche Minderheit der Beschleunigten fest, daß das BASIC selbst, aber leider auch dessen Compilate, auf Prozessoren neuer als 68010 nicht liefen. Das BASIC war einfach zu unsauber programmiert. Mit Erscheinen des TT, der zum einen mit einer 68030er-CPU, zum anderen auch mit neuen Grafikmöglichkeiten versehen war, sahen sich OMIKRON. gezwungen, ihr BASIC anzupassen, um diesen Zukunftsmarkt nicht zu verlieren. Der erste Schritt dorthin war die Auslieferung einer Version 3.5. Deren Compilate liefen zwar auch auf dem TT, das BASIC selbst jedoch verwies mittels Alertbox am Anfang auf die TT-Version, die für Computer mit 68020 und größer zwingend vorgeschrieben sei. Mit einigem Verzug erschien dann jedoch die Version 4.0, die zusätzliche Unterstützung der TT-Hardware versprach. Diese baut direkt auf der Version 3.5 auf.

OMIKRON.BASIC? OMIKRON.BASIC!

Über OMIKRON.BASIC als solches (die alten ST-Hasen mögen diesen Absatz bitte übersehen): OMIKRON.BASIC ist wie die meisten BASIC-Varianten eine Interpreter-Sprache. Der komplette Programmcode wird während der Laufzeit des Interpreters Zeile für Zeile immer neu 'interpretiert', d.h. der Interpreter schaut sich den gewünschten Befehl an und führt dafür eine entsprechende Maschinenroutine aus. Der Programmierer hat dadurch jederzeit die volle Kontrolle über sein Programm. Er kann es an beliebiger Stelle unterbrechen, sich Variableninhalte, Ergebnisse oder den aktuellen Befehl ansehen und dann das Programm einfach weiterlaufen lassen. Ist das Programm fertig, kann es compiliert werden, d.h. der Programmcode wird komplett übersetzt in die wesentlich schnellere, aber auch sehr viel schwerer zu programmierende Maschinensprache. Eine reine Compiler-Sprache (z.B. C oder Pascal) compiliert den Programmtext stattdessen vor jedem möglichen Lauf in Maschinensprache, was die Fehlersuche entsprechend langwieriger gestaltet (Editieren->Compilieren->Testen->Editieren). Der Anwender hingegen kann nicht unterscheiden, in welcher Sprache das Programm geschrieben wurde. Er sieht nur das compilierte Endprodukt. Das OMIKRON.BASIC ist eine moderne Programmiersprache. Neben der Tatsache, daß es zu 99% aufwärtskompatibel zum Microsoft BASIC (dem BASIC- Urvater) ist und damit das gleichzeitige Programmieren in der DOS-Welt erleichtert, hat es auch viele Eigenschaften, die es von einem Staudard- BASIC positiv abheben. So wird auf Wunsch die ansonsten typische Zeilennumerierung weggelassen, und dem Pascal entlehnte Schleifenkonstrukte gestalten den Programmtext wesentlich übersichtlicher als der sicherlich zurecht verrufene 'Spaghetti-Code'. Große Beliebtheit er- freut sich OMIKRON.BASIC bei den im ST-Bereich sehr zahlreich vertretenen Mathematikern und Physikern, da die Sprache in einer Genauigkeit von bis zu 19 Stellen rechnet.

Die Austattung

Im Lieferumfang enthalten sind:

Das Neue

Doch kommen wir zur Version 4.0. Während die Coprozessor-Library für die ST- Serie fertig ist und mitgeliefert wird, war zum Zeitpunkt des Testes die entsprechende Library für den Coprozessor des TT noch nicht fertig. Auf die Geschwindigkeit der mathematischen Funktionen wird deswegen bei diesem Test nicht eingegangen. Zum Erscheinungstermin dieser Ausgabe müßte sie jedoch schon lieferbar sein.

Die erste Einschränkung trifft den stolzen TT-Besitzer allerdings schon beim Start. In der jetzigen Version 4.06 funktioniert der Interpreter nur im ST-RAM (auch da geloben die Programmierer Änderung). Zur Erklärung: Im TT existieren zwei verschiedene Arten des kostbaren Speichers, das DUAL-PURPOSE-RAM (auch ST- RAM genannt) und das SINGLE-PURPOSE-RAM (auch TT- oder FAST-RAM). Das ST-RAM, auf das die CPU und die Customchips Zugriffsberechtigung haben (was sich besonders im Falle des Videoshifters verlangsamend bemerkbar macht) liegt in Größen von 2-4 MByte in jedem TT vor, das wesentlich schnellere und wichtigere TT-RAM (nur die CPU hat Zugriffsberechtigung) kann z.Zt. jedoch nur 4-128 MByte umfassen. Zwar behaupten die Programmierer, daß dieser Umstand eigentlich keine Einschränkung darstellt, davon kann jedoch keine Rede sein. Da die meisten TT-Besitzer nun einmal genug Speicher haben, wird er auch gerne mit Accessories, Utilities, Cache und anderen 'Speicherfressern' verbraucht. Daß ein eventuell angeschlossener ATARI-Laserdrucker beim Grafikdruck ebenfalls 1 MByte ST-RAM benötigt, können wir dabei schon fast außer acht lassen. Daß sich aus internen Gründen der Speicherverwaltung des TT in Verbindung mit der eines Interpreters Probleme ergeben, ist durch die Struktur bedingt. Für Abhilfe muß dennoch schnellstens gesorgt werden. Eine Abkehr vom starren 'Alles oder nichts'- Prinzip hin zum 'Ich alloziere nur soviel Speicher, wie ich im Moment wirklich brauche', wäre sehr zu begrüßen, ist es doch eines der Hauptnachteile gegenüber einer Compilersprache. Wie dem auch sei, der BASIC-Compiler und dessen Compilate laufen auch im TT-RAM.

Eine Befürchtung galt der Grafik, einem besonderen Knackpunkt in der Version 3. Doch dies war unbegründet. Obwohl der Editor kein GEM unterstützt, sondern eine Art TOS-Umgebung mit eigener Menüzeile hat, läuft er auf allen Standardauflösungen des TT. Aber selbst Grafikkarten konnten ihn nicht zum Absturz bringen. Es sind zwar keine Geschwindigkeitsgründe, die die Programmierer dazu brachten, auf GEM zu verzichten, denn zumindest in den TT-Grafikmodi ist die Ausgabegeschwindigkeit einem gut programmiertem GEM-Editor unterlegen. Allein das dadurch leichtere Debuggen von GEM-Programmen war der Grund. Der Interpreter benutzt dabei zwei Darstellungsarten. Eine schnelle Ausgabe, bei der direkt in den Bildschirm geschrieben wird, und, sollte dies nicht funktionieren, eine langsamere Ausgabe über das VDI. Da aber zu jeder Grafikkarte auch ein VDI-Treiber gehört (GEM würde sonst nicht laufen), dürfte auch für zukünftige Grafikkarten (Stichwort: Truecolor) die Funktion gewährleistet sein. Auch das Verwalten mehrerer Bildschirme funktioniert tadellos. Das BASIC berechnet aus den dem GEM bekannten Werten den Speicherbedarf eines Bildschirmes, so daß man mit dem SCREEN-Befehl mühelos zwischen bis zu drei Bildschirmen swappen kann. Dabei wird die BITBLT-Routine des VDI verwendet.

Auch der Farbbefehl COLOR greift sauber auf die VDI-Register zu. Es gilt aber zu beachten, daß, je größer und je bunter der Bildschirm wird, desto mehr knappes ST-RAM verbraucht wird. Also muß man hier gegebenenfalls einen eigenen Puffer im TT-RAM anlegen.
Eine weitere Überraschung war, daß der Interpreter in Maßen mit anderen Programmen gleichzeitig aktiv im Speicher sein konnte. Ein Test unter MULTIGEM zeigte, daß der Interpreter nicht wie befürchtet, sofort abstürzte. Allerdings läuft er nicht mit jedem Programm. Er muß als letzter Prozeß gestartet werden, jedes Programm nach ihm schickt den Interpreter in das Nirwana. Da, wie schon erwähnt, der Interpreter keinen GEM-Editor enthält, kann man natürlich kein echtes Multitasking erwarten. Vielmehr existiert ein Menüpunkt, mit dem man auf eine GEM-Menüleiste umschalten kann. Diese enthält allerdings nur die Auswahl an Accessories und die Möglichkeit, wieder auf den Editor-Bildschirm zurückzuschalten. Da es mit dem MULTIGEM bereits eine Multitasking-Erweiterung gibt, die angesichts der Hardware eines TT bei dessen Besitzern auch recht beliebt ist, ist es umso unverständlicher, daß OMIKRON. hier nicht die entsprechenden Änderungen vorgenommen hat. Zwar weisen Entwickler bei unsauberer Programmierung in der Regel darauf hin, daß das Programm auf dem offiziellen Betriebssystem läuft und auf nicht von ATARI autorisierte Zusätze keine Rücksicht genommen werden kann, jedoch gibt es auch für ATARI-GEM Programmierrichtlinien. Mit der offiziellen Ankündigung des multitaskingfähigem Betriebssystems MultiTOS auf der diesjährigen CeBit für Ende diesen Jahres ist der nächste Konfliktpunkt bereits vorprogrammiert. Will OMIKRON. etwa wieder bis ein Jahr nach Erscheinen des neuen TOS warten, um dann endlich eine voll lauffähige Version 5.0 vorzustellen? Es bleibt in der Verantwortung jedes einzelnen, dafür Sorge zu tragen, daß die Erzeugnisse auch auf zukünftigen Rechnergenerationen der TOS-Familie funktionieren. Dies gilt aber im ganz besonderen Maße für Entwickler von Programmiersprachen, da sie als Multiplikatoren fungieren. Das extrem schlechte Vorbild des alten OMIKRON.BASIC hätte den Entwicklern Anstoß sein sollen, auch in diesem Punkt den Editor komplett neu zu entwickeln.

Funktioniert auch auf Großbildschirm und (bedingt) mit MultiGEM

Und jetzt die Werbung

Halten wir uns die Werbung von OMIKRON. vor Augen, so heißt es dort: Beide Compiler, 3.5 und 4.0, können Code für ST und TT erzeugen. Den speziell auf den TT optimierten Code, der alle Leistungsreserven ausschöpft, erzeugt jedoch nur der Compiler 4.O.' Solcher Art beeinflußt, erwartet natürlich das naive Gemüt des Testers, daß Programme mit Version 4.0 compiliert schneller ablaufen als ihre mit Version 3.5 erzeugten Pendants. Also ein schönrechen- und schleifenintensives Programm ausgesucht und ausprobiert. Als Test dient ein Programm, das ein Apfelmännchen erzeugt (X -0.7 bis 2. 1, Y - 1 bis 1, Rechentiefe 25). Es wurde mit den jeweiligen Compilern und Libraries getrennt voneinander compiliert. Die Compilate liefen zum einen im TT-RAM mit eingeschaltetem Cache und TOS im TT- RAM (beschleunigt die Betriebssystemaufrufe) und zum anderen auf einem ST mit TOS 1.04, jeweils im monochromen ST-Modus:

TT mit 4.0: 6 min 48 sec
TT mit 3.5: 6 min 48 sec

ST mit 4.0: 28 min 52 sec
ST mit 3.5: 28 min 52 sec

Dies ist weder ein verspäteter Aprilscherz, noch ein Druckfehler. Zwar ist es nicht weiter überraschend, daß der TT um einiges schneller rechnete (auch ohne Unterstützung durch den Coprozessor), aber daß die Version 3.5 gegenüber der Version 4.0 trotz der Werbeaussage (s.o.) nicht schneller ist, war doch mehr als überraschend. Vielmehr erzeugen beide Compiler exakt den gleichen Code. Hieran dürfte sich wohl spätestens mit Erscheinen der 4.0-FPU-Lib etwas ändern, wenngleich festzuhalten ist, daß ohne den Coprozessor, man denke nur an die Vielzahl der Turbokartenbesitzer, durch die Version 4.0 kein Geschwindigkeitsgewinn gegeben ist.
Als Entschuldigung führte OMIKRON. rechtliche Probleme mit ATARI an, die eine Option auf eine TT-Version hätten. Sollten diese beseitigt werden, wolle man eine auf dem 68030 lauffähige Version 3.5 präsentieren. Jedoch wird man erst mit der Fertigstellung der TT-FPU-Library feststellen können, wie stark diese Sprache sich auf dem TT von anderen Programmiersprachen unterscheidet. Der um den Faktor 4,5 beschleunigte Programmablauf läßt da schon hoffen.

center
Das Apfelmännchen diente zum Geschwindigkeitsvergleich

Fazit

OMIKRON.BASIC ist eine in der Ausführung sehr schnelle, genau rechnende und leicht zu programmierende Sprache. Wäre dies ein Test über die Version 3.5 gewesen, wäre er unzweifelhaft positiver ausgefallen. Aber die Neuerungen der Version 4.0 rechtfertigen keinen so hohen Sprung der Versionsnummer, Version 3.6 oder 3.5TT wäre da angebrachter gewesen. Vertragliche Probleme sollen und können schließlich nicht auf dem Rücken der Käufer ausgetragen werden. Der Kunde sollte zurecht bei solchen Sprüngen Verbesserungen in der Substanz und nicht ein Umgehen der bekannten Probleme auf niedrigem Niveau erwarten können. Der große Sprung der Versionsnummer läßt sich eigentlich nur durch die gänzlich andere Art der TT-Coprozessorprogrammierung erklären (die ja zum gegenwärtigen Zeitpunkt noch gar nicht gegeben ist). Da aber schon die alte Version Coprozessorunterstützung bot und sich damit auch zurecht aus der Menge der BASIC-Interpreter hervorhob, sollte die Unterstützung des Gespannes 68030/ 68882 bzw. des 68040 mit seiner internen FPU, eher als notwendige Update-Pflicht des Programmierers gesehen werden. Daß eine solche Version etwas mehr kostet, egal ob neu gekauft oder als Update, kann man, muß man aber nicht in Frage stellen. Außerdem benötigt ein Kunde für ein komplettes OMIKRON.Entwicklungssystem noch mindestens ein Resource Construction Set. Wir können dann folgende Rechnung aufstellen: OMIKRON.BASIC 4.0 für 698 DM + OMIKRON.Easy GEM-Lib für 99 DM + Hüthig OMLib Professional für 129 DM. Das macht zusammen 926 DM. Dann noch einen Shareware-Assembler dazu, und wir sind beim doppelten Preis der Kombination C/Assembler + Interface RCS + 'Vom Anfänger zum GEM-Profi'. Damit wird auch für den Hobby- und Gelegenheitsprogrammierer, der bislang mit dem alten OMIKRON.BASIC programmierte, entweder ein Wechseln der Sprache oder ein weiteres Programmieren auf dem ST interessant. Wo also ist der Markt für so eine teure und als Entwicklungssystem unvollständige Programmiersprache? Eindeutig im bereits erwähnten naturwissenschaftlichen Bereich, wo OMIKRON.BASIC-Programme und Tools bereits existieren und man wegen der rechenstärkeren Hardware auf TT umgestiegen ist. Vielleicht spricht es sich bis zu den Firmen OMIKRON. und ATARI ja noch herum, daß auch 'normale User' durchaus verstärkt auf TT oder Beschleunigerkarten umsteigen. Wir werden Sie auf jeden Fall über weitere Neuigkeiten informieren ...


Oliver Schildmann
Aus: ST-Computer 05 / 1992, Seite 15

Links

Copyright-Bestimmungen: siehe Über diese Seite