Wer spielt mit ?

Wo klappt BasiCode nicht ?!

Ist BasiCode eigentlich wirklich für alle BASICs der Computer von vor 40 Jahren oder noch früher geeignet? Untersuchen wir doch exemplarisch ein paar davon und beginnen mit MBASIC (oder BASIC-80) für CP/M. ^[1]

Damals dominierten die Grünmonitore, was schon ein Fortschritt gegenüber den davor genutzten Teletypes war. Bilder konnte man allenfalls aus Zeichen des hardwareseitig vorgegebenen Zeichensatzes erstellen, deswegen wollen wir hier nur vom Standard BasiCode-2 ausgehen, also Arbeit mit Dateien sowie Sound, Pixelgrafik und Farben außen vor lassen. Wir vergleichen auch nur die ersten drei Funktionen der Bascoder sowie das Arbeiten mit Zeichenkettenvariablen.

MBASIC (auch als BASIC-80 bekannt)

      GOSUB 100 (Löschen des Bildschirms)

Ein Befehl wie z.B. CLS war nicht enthalten, man musste (vgl. Mallard Basic auf Amstrad PCW) einen Steuercode verwenden.

      GOSUB 110 (Positionieren des Textcursors)

Mit POS konnte die Position innerhalb der Zeile gewählt werden, VPOS oder dergleichen für Auswahl der Zeile gab es nicht als BASIC-Befehl, also heißt die Lösung ebenfalls Steuercode.

      GOSUB 120 (Ermitteln der aktuellen Cursorposition)

Hierfür gibt es auch keinen unmittelbaren BASIC-Befehl, wohl auch keine Steuercodes – im Bascoder werden hier lediglich zu große Eingaben auf die vereinbarte Grenze korrigiert.

Die Codierung der Zeichen nach ASCII (vgl. EightyOne-Screenshot im Abschnitt ZX81) und die Befehle für die String-Verarbeitung (vgl. letztes Drittel im Abschnitt ZX81) entsprechen in MBASIC dem heute Gewohnten.

Fazit: sehr einfache Programme ^[2] (DIGIKLOK ^[3] ist ein Beispiel) können mit Abstrichen genutzt werden. BasiCode-Programme, die inverse Textausgabe und Zurücklesen von Zeichen aus Bildschirmpositionen verlangen (wie z.B. Tetris), sind erst in Version 3 von BasiCode nutzbar – aber wir wollten ja ohnehin nur Standard 2 betrachten.

Sinclair Basic des ZX81

      GOSUB 100

Der Befehl CLS ist vorhanden.

      GOSUB 110

Wird über “PRINT AT“ umgesetzt.

      GOSUB 120

Erfolgt mit Nutzung von PEEKs.

Einige Besonderheiten müssen beachtet werden.

Die Zeichencodierung ist nicht mit ASCII identisch, dass A unmittelbar auf die 9 folgt, stellt bei der Umrechnung von und in Hex-Zahlen andererseits einen Vorteil dar.

Das BASIC des Nachfolgers ZX Spectrum verwendet dann übrigens bereits ASCII.

Jede Zeile kann nur einen Befehl enthalten, der Doppelpunkt ist zwar vorhanden, doch kann er nur innerhalb von Textausgaben verwendet werden.

LET darf bei der Zuweisung von Werten an Variablen nicht weggelassen werden.

IF … THEN zeilennummer ist unzulässig – IF … THEN GOTO zeilennummer ist vorgeschrieben.

Der Name von Laufvariablen (FOR ... TO ... NEXT) darf nur aus einem Buchstaben bestehen, ebenso der von Zeichenkettenvariablen.

DATA und READ gibt es auf dem ZX Spectrum, auf dem ZX81 müssen die beiden Befehle auf anderem Wege nachempfunden werden (vgl. BC2-Manual ^[4]).

Zeichenketten-Funktionen haben eine völlig anderere Syntax als allgemein in den späteren BASICs (hier ein Vergleich zu MBASIC). Im Spectrum-BASIC verhält es sich genauso.

Es steht recht wenig Arbeitsspeicher zur Verfügung, die Maschinencode-Routinen zum Übersetzen des Textes in BASIC-Token verringern den verfügbaren Arbeitsspeicher noch weiter. Doch mittlerweile können Programme als Listings auf dem PC entworfen und mit Tools aus dem Umfeld von Emulatoren übersetzt und in die Emulation oder sogar in den realen ZX81 übertragen werden, wodurch heute eine größere Programmlänge nutzbar wird.

Viele, auch aufwendigere, BasiCode-Programme (hier BOKA-EI ^[5]) können auf dem ZX81 zum Laufen gebracht werden, eine Einschränkung ergibt sich aus der Länge des Programms und dem RAM-Bedarf für die Variablen.

(8-bit-)Atari-Basic

(gilt auch für das Turbo-Basic, das die gleichen sowie zusätzliche Token verwendet)

      GOSUB 100

Den Befehl CLS gibt es nur für den Grafik-Modus, im Textbetrieb wird das Zeichen mit dem Code 125 verwendet.

      GOSUB 110

X- und Y-Wert werden mittels POKE in den Speicher geschrieben.

      GOSUB 120

Die Koordinaten werden mit PEEK aus dem Speicher übernommen.

Auch hier gelten Besonderheiten.

Die Zeichencodierung stimmt nicht vollständig mit ASCII überein – Buchstaben und Ziffern sind aber wie in ASCII codiert.

Eine Zeichenkette muss vor dem ersten Verwenden dimensioniert sein, aber für das Ermitteln der Länge werden nur die tatsächlich genutzten Zeichen berücksichtigt (erstes Beispiel).

Das Zusammenfügen zweier Strings (letztes Beispiel) erfolgt nicht mit “+“ wie beim ZX81, sondern sozusagen als Überschreiben/Hinzufügen ab der genannten Position, auf die Länge entsprechend der Dimensionierung muss geachtet werden.

Es gibt Folgen (eindimensional) und Felder (zwei Dimensionen) numerischer Variablen, aber keine Folgen oder Felder von Stringvariablen. K$(m,n) aus einem BasiCode-Programm wird also nicht als Element aus Zeile m+1 und Spalte n+1 interpretiert, sondern als Teilstring ab Position m mit der Länge n.

Insbesondere wegen der Kommunikationsprobleme infolge der letztgenannten Einschränkung ist BasiCode auf der Grundlage des Atari-Basic einfach nicht realisierbar bzw. nur sehr wenige Programme (wie z.B. TIMER555 ^[6]) würden mit den wenigen umsetzbaren Funktionen laufen können. Deswegen schrieb Andreas Graf ein eigenes BASIC ^[7] (ähnlich wurde bei den DDR-Computern Z1013 und AC-1 verfahren).

In diesem BASIC funktionieren die BasiCode-Programme uneingeschränkt, lediglich die Verwendung von Farben ^[8]) in Version 3C lässt Wünsche offen, im Grafik-Modus mehr als im TextModus.

Nebenbei   löste sich ein altes Rätsel: beim Ausprobieren mit dem Programm BOKA-EI störte mich wie immer bisher, dass manche Spielsituationen nicht richtig ausgewertet wurden. Diesmal habe ich die Ursache gefunden ... zwei Werte wurden falsch zugewiesen:

Thomas Rademacher . August 2026