BASIC und die Heimcomputer

Heute geht es um die Geschichte der BASIC und einer versäumten Chance diese Sprache wirklich zu etablieren. Auf ZDF Info habe ich kürzlich die mehrteilige Dokumentation „Geheimnisse der digitalen Revolution“ angeschaut, die sehr zu empfehlen ist und da ZDF Info viel wiederholt auch jetzt noch anzuschauen ist. Dabei werden auch viele Leute interviewt, wobei ich aber die meisten nicht kenne. In einer der Folgen über die PC- und Heimcomputerszene kamen dann auch C64 User dran, die damals noch Jugendliche waren. Nach den Aussagen hat man die nur zum Spielen gekauft. Einer meinte er hätte das Geld bei der Oma losgeleiert, weil er damit angeblich programmieren lernen wollte, aber nur gezockt.

Ich muss die Ausnahme gewesen sein, denn ich habe meine Rechner wirklich gekauft, um zu programmieren. Beim zweiten, einem CPC 464 bin ich allerdings nach etwa einem Jahr auf Pascal umgestiegen. An meine BASIC-Programme kann ich mich daher kaum erinnern. Ich habe mich mal an einer Tabellenkalkulation versucht und einen Assembler/Disassembler geschrieben, den allerdings aus einer Vorlage in einem Data Becker Buch aufgebaut.

Einmal bei Pascal angekommen, wollte ich nicht zurück. Es war so viel komfortabler und leistungsfähiger. Dabei waren die Möglichkeiten von Turbo Pascal nominell gar nicht so viel besser als bei BASIC. Stringvariablen waren auch nur 255 Zeichen lang. Der Befehlsvorrat eher kleiner. Aber die Möglichkeiten eine Aufgabe zu strukturieren durch Prozeduren und Funktionen sowie mehr Variablentypen war überlegen. Vor allem bei großen Programmen verlor man sich nicht im Spaghetticode und neue Variablen durch Schreibfehler gab es auch nicht. Dabei war Turbo Pascal nicht mal groß und belegte 31 KByte Speicher. Der BASIC-Interpreter bei mir belegte auch schon 16 KByte, da ist der Unterschied also nicht so groß.

Warum gab es trotzdem in jedem Heimcomputer einen BASIC-Interpreter, sogar als Bestandteil von DOS das „GW BASIC“?

Die Anfänge: Microsoft BASIC

Alles fing mit dem Altair an, als Bill Gates und Paul Allen das erste Microsoft Basic schufen. Das sollte in der kleinsten Version nur 4 KByte Speicher belegen. BASIC wurde gewählt, weil es die einzige Sprache war, die auf solche Speicheranforderungen heruntergeschrinkt werden konnte, trotzdem war auch diese Version nur rudimentär. Es gab dann noch zwei größere Versionen von 8 KByte Umfang mit mehr Befehlen und Fließkomma und Ganzzahlen und eine mit 16 KByte die auch das Betriebssystem für Diskettenlaufwerke beinhaltete.

Startscreen CPC 464 mit BASIC Interpreter
Startscreen CPC 464 mit BASIC Interpreter

Als dann 1978 die ersten „echten“ Heimcomputer erschienen die alle Komponenten vereinigt hatten, begrüßte den Benutzer in allen Systemen ein BASIC Interpreter, der auf dem Standard von Kenemy/Kurtz aufbaute von 1968. Der hatte einen kleinen Sprachkern und verwandte nur Zeilennummern als Sprungziele für GOTO und GOSUB. Damit waren auch alle Zeilen durchnummeriert. Der Vorteil dieses BASIC war, das man praktisch keinen Editor brauchte. Es konnte nur eine Zeile editiert werden, die man mit EDIT aufrief. Nach dem Druck auf die Enter Taste wurde die veränderte Zeile wieder abgespeichert und dafür brauchte man auch die Zeilennummern – um eine Zeile direkt anzusprechen. Pascal kennt keine Zeilennummern und so braucht man einen Bildschirmeditor und Speicher für den aktuellen Bildschirminhalt. Beides macht zwar das Programmieren komfortabler braucht aber auch mehr Speicher.

So wurden BASIC Interpreter zwar immer größer aber dann kamen nur mehr Kommandos hinzu. Das Basic auf meinem Rechner kannte zyklisch aufgerufene Routinen durch Timer (Events), Warteschlangen für Sound, Fenster, zahlreiche Grafikroutinen etc.

Eine vergebene Chance

Ich finde es im Nachhinein schade, dass man zumindest bei der 64-KByte-Generation nicht die Chance für ein bedienungsfreundliches Basic nutzte. Denn dieses sklavische Festhalten an Zeilennummern ist eigentlich nur eine Notlösung. Sie erlaubte es schon beim Urbasic auf einen Bildschirm zu verzichten und mit einer Fernschreiber an dem Minicomputer zu kommunizieren. Später gab es ja Basic Interpreter, die ohne Zeilennummern auskamen, Prozeduren kannten, Bildschirm-Editoren hatten. So was gab es auf dem Sinclair QL, Amiga und Atari ST. Doch da war auch schon die Hochzeit von BASIC vorbei.

Beim Sinclair QL passte das entsprechende BASIC mit Betriebssystem in ein 48 KB großes ROM. Bei meinem Rechner waren Betriebssystem und BASIC zusammen 32 KByte groß. Bedenkt man das 68000-er Code allgemein länger ist, so schwindet der Unterschied noch stärker. Warum nur bei der 64 K (RAM) Generation? Nun 32 oder 48 KByte für ein Basic bei den vorherigen Rechnern abzuzweigen, hätte den Arbeitsspeicher stark reduziert. Schließlich konnten die 8 Bitter nur 64 KByte Adressieren. Doch alle Rechner mit 64 KByte RAM nutzten Bankswitching. Denn sie hatten ja noch ROMs für Betriebssystem und BASIC Interpreter und wenn auch der Grafikprozessor einen Teil des RAMS abzwacken musste, die CPU zumindest auf den zugreifen, um Daten dort hineinzuschreiben, er musste also adressierbar sein. Wenn ich aber Bankswitching habe, um zwischen ROM und RAM zu wechseln, dann ist es eigentlich, egal ob das ROM etwas größer ist, zumal maskenprogrammierte ROM Bausteine in Großserien wirklich billig waren.

Solche Versäumnisse zeigten sich dann auch als die 64 K Maschinen dann als Speicher noch billiger wurden zu 128 KByte Maschinen wurden so der Sinclair Spectrum, Armstrad 6128 oder Commodore 128. Die zusätzlichen 128 KByte Speicher wurden meist nur unzureichend genutzt als RAM Floppy oder Bildspeicher. Nur der C 128 hatte da ein besseres Konzept. Ich hätte mir, da Programme sowieso auf maximal 64 KByte auch mit Bankswitchung begrenzt waren eher gewünscht, dass man die Bildschirmauflösung oder Farbzahl hochtreibt. Das Erste schied wahrscheinlich aus, wenn man den Computer an den Fernseher anschließt. Das Zweite wäre aber möglich gewesen. 320 x 200 Punkte, eine damals übliche Auflösung wäre dann z.B. mit 256 Farben anstatt 4 möglich gewesen. Zumindest der, in meinem Rechner verbaute, MC 6845 konnte auf Karten beim IBM PC erheblich mehr Speicher ansprechen bis zu 512 KByte.

Resümee

So aber waren die BASIC-Interpreter wirklich nicht nützlich, um damit wirklich gut Programmieren zu lernen, vielmehr führten sie zu einem schlechten Programmierstil, was Kenemy und Kurtz dann auch in einem Interview bedauerten. Ihr 1985 erschienenes „True BASIC“ ohne Zeilennummern konnte sich auf jeden Fall nicht mehr durchsetzen.

Ich weiß nicht ob das die Kids davon abgehalten hätte ihre Heimcomputer nur zum Spielen zu kaufen und einzusetzen, aber vielleicht hätte der eine oder andere vielleicht auf ihnen doch programmiert, wenn die Sprache für größere Programme geeignet wäre oder auch zu einer anderen Sprache weitergeleitet. Immerhin hat ja Linus Torvalds auf einem dieser besseren BASIC Dialekte auf dem Sinclair QL mit dem Programmieren angefangen. Zumindest beim C64 konnte ich den Befragten verstehen. Bei dem war der BASIC-Interpreter selbst für die damalige Zeit extrem rudimentär. Der Computer hatte tolle Chips an Bord, doch die konnte man nur mit Peek und Poke also dem Abfragen von Speicheradressen und dem Ablegen von Daten an Speicheradressen ansprechen. So etwas wie Befehle wie Draw für Linien oder Sound für Töne, die schon weniger leistungsfähigere Rechner hatten, kannte der nicht.

Heute wirkt das Konzept so antiquiert, dass ich eine Zeitlang damit spielte in der ersten Vorlesungsstunde einen alten CPC mitzubringen und den hinzustellen und zu sagen „Jeder der in 5 Minuten hier ein Programm schreiben kann das von 1 bis 10 zählt und auf dem Bildschirm ausgibt bekommt eine Eins und muss nicht mehr zum Unterricht erscheinen“. In Zeit wo man eine grafische Benutzeroberfläche startet kommt ein Rechner der nur „Ready“ ausgibt und schon eine Eingabe wie „Explorer“ nur mit einem „Syntax Error“ quittiert wohl wie aus einer anderen Zeit vor. Nichts veraltet so schnell wie Computertechnik, denn dieselben Leute hätten wohl kein Problem ein Auto aus den achtzigern zu fahren.

One thought on “BASIC und die Heimcomputer

  1. Ich war so ein „Kid“. 😉 Im zarten Teenageralter schaffte ein Vater einen C64 an, um darauf ein spezielles, und damals sehr teures Programm zu nutzen. Ich durfte in der Freizeit den Rechner nutzen, und habe relativ schnell das Spielen seingelassen, und mit Basic-Programmierung angefangen. Nach einigen Jahren des Lernens und einem Umweg über Forth bin dann auf Assembler umgestiegen, da nur damit Grafik und Sound programmierbar waren.
    Der nächste Rechner war dann bereits ein 286er, auf dem ich nach ersten Gehversuchen mit Turbo-Assembler und QickBasic dann ebenfalls begeisterter Turbo-Pascal-User wurde. Man konnte dort direkt in den Hochsprachen-Code Assembler-Code einbetten, was die Arbeit extrem erleichterte. Danach war ich Delphi-Entwickler der 1. Stunde, und als ich im Studium dann plötzlich Java nutzen musste, kam mir dies vor wie in Rücksturz in die Steinzeit.
    Bei meinem 1. Arbeitgeber habe ich dann weiterhin Delphi eingesetzt, aber mit dem Dotnet-Framework kam dann irgendwann die nächste technologische Revolution, und so habe ich gewechselt. Heute entwickele ich in C# und F#. Vor einem Jahr musste ich ein Delphi-7 Projekt auf Delphi Xi portieren, zwecks Windows-7-Kompatibilität. Und wieder kam es mir wie ein Rücksturz in die Steinzeit vor.
    Ich denke also nicht, dass Basic den Entwickler „verhunzt“ oder zu einem schlechten Stil erzieht. Vielmehr ist Basic ein erstklassiges Werkzeug seiner Zeit gewesen. Und genau wie ich heute meine Werkzeuge mit Verstand einsetzen muss, musste ich das damals auch.
    Ich bin heute noch erstaunt, wie viel wir „Kids“ der 80er aus dem Brotkasten rausgeholt haben. Und auch ein wenig stolz. 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.