Ein Computerfreund wandte sich unlängst mit einer Frage an mich. In einem Programm sollten auch numerische Daten als Strings eingelesen werden, was nach den BasiCode-Vereinbarungen nicht zugelassen ist, bei READ A$ MUSS an der betreffenden Stelle in den DATAs eine Stringvariable stehen, bei READ A eine numerische. Unter dem Java-Bascoder von Jens Müller wurde dementsprechend auch mit einer Fehlermeldung abgebrochen.
Ich testete die Situation als erstes im online-Browser von Rob Hagemans – doch dort funktionierte es, ohne einen Fehler zu melden:
Nun war meine Neugier geweckt, und ich probierte es in unterschiedlichen Emulationen aus.
Im Atari-Basic, erinnerte ich mich, werden in DATA-Zeilen Zeichenketten nicht in Anführungszeichen gesetzt, das Basic kann sie selbständig von numerischen Variablen unterscheiden. Verwendet man dennoch Gänsefüßchen, werden sie Bestandteil der Variablen.
Wie sieht es auf unserer Joyce aus?
Unter dem BasiCode welches Computers wurde das Programm geschrieben? Auf einem Commodore 64. Hier die Tests mit dem C64 und dem C plus/4:
Der erste Computer, der etwas zu bemängeln fand, war der ZX Spectrum ... das Manual erklärt: "C Nonsense in BASIC. Der Test des Stringarguments stellt keinen zuverlässigen Ausdruck dar."
Im Amiga-Basic ist es wieder wie bei den meisten vorherigen:
Hier noch Beispiele von zwei MSX-Computern und vom Amstrad CPC:
Offenbar ist es entscheidend, welches Basic auf dem betreffenden Computer UNTER dem Bascoder liegt, nach diesem richtet sich das Verhalten. Um die Übertragbarkeit, das vordergründige Anliegen von BasiCode, sicherzustellen, sollte man also streng darauf achten, dass die BasiCode-Festlegungen eingehalten werden, sonst kann es eben passieren, dass ein Programm zwar auf meinem Computer funktioniert, aber auf dem eines Anderen nicht.
Entsprechende Sachen hatten wir schon einmal, es ging um unterschiedliches Verhalten bei der VAL-Funktion und um das Verwenden der Funktion LN(x).
Thomas Rademacher . März 2026
