Nascom Journal

  

Mai 1982 · Ausgabe 5

Preiswertes PASCAL

von Michael Bach

Angeregt durch einen Review im letzten INMC-News habe ich mir in England das „Blue Label Software Pascal“ bestellt, da ich es recht preisgünstig fand (57 Pfund) und mal Pascal lernen wollte. Da ich einen Blanko-Ver­rech­nungs­scheck beilegte, ging die Lieferung sehr schnell​(1 Woche). Ich hatte die Kassetten-Version (1000H-4000H) bestellt, sie wird in 1200Bd im Kansas-City Format geliefert. Es gibt auch eine Eprom-Version von D000H-FFFFH. Tatsächlich gelang es mir nach einigen Versuchen, die Daten fehlerfrei einzulesen.

Das Pascal-System besteht aus 4 Teilen: Ein „Runtime-Package“, ein „Betriebssystem“, ein Editor, und der Compiler. Vom Betriebssystem aus können Programme (Quellkode oder Objekt) mit Namen geladen und abgespeichert und die weiteren Funktionen aufgerufen werden: Ein guter cursororientierter Editor, der auch Zeilen mit mehr als 48 Zeichen zuläßt (dann rutscht der ganze Bildschirminhalt nach links); er ist zwar nicht so komfortabel wie der vom UCSD-Pascal aber besser als Naspen sowieso. Der Compiler ist sehr schnell und verarbeitet Standard-Pascal mit Ausnahme von Set’s Type’s und Record’s. Dafür bietet er einige Erweiterungen in Richtung Grafik, Stringverarbeitung und direkten Speicherzugriff, d.h. er kann alles, was man von Basic kennt und mehr. Insbesondere ist auch der Datentyp REAL vorhanden mit 11 sicheren Stellen. Wenn beim Compilieren ein Syntaxfehler gefunden wird, springt das System in den Editor und der Cursor blinkt (meistens) genau an der fehlerhaften Stelle (z.B. Semikolon vergessen). Der Compiler erzeugt Z80-Kode (also keinen P-Code), und die Programme laufen daher sehr schnell. Das ist einer der Gründe, warum dies Pascal für mich Basic und Assembler vollständig ersetzt: Es ist so schnell wie Assembler, und es ist komfortabler als Basic. Für Spiele mit Grafik z.B. ist Basic immer zu langsam, und in Assembler dauert das Programmieren viel länger. Pascal-Objektprogramme können für jeden Adressbereich kompiliert werden und sind auch Epromfähig, wenn das Runtime-Package ebenfalls im Speicher ist. Wenn bei der Programmausführung ein Fehler auftritt (z.B. Division durch 0, Index-Bereichsüberschreitung), kann man in den Editor springen, und der Cursor blinkt wieder an der Fehlerstelle. Nachteile:

1. Die Tastatur-Routine des Pascal funktionierte bei meinem Nascom1 nicht einwandfrei, was sich aber beheben ließ, indem ich die vom Pascal vorgenommene Änderung der Input Tabelle verhinderte. Beim Nascom2 gibt’s diese Probleme nicht.

2. Bei Pascal braucht man die rechteckigen Klammern (für indizierte Zahlenfelder). Das sind aber bei mir die Buchstaben „Ä“ und „Ü“. Das führt zu sehr unleserlichen Programmen. Aber beim erneuten Lesen der Handbücher (2 Hefte Din A5 zusammen 60 Seiten) fand ich, daß diese auch durch die Kombination „(.“ und „.)“ ersetzbar sind. Für Kommentare kann ja sogar in Standard-Pascal statt der geschweiften Klammern die Kombination „(*“ eingesetzt werden. Dieses Pascal ist in Dänemark implementiert worden, wahrscheinlich sind dort auch die eckigen Klammern durch nationale Sonderbuchstaben belegt.

Insgesamt kann ich sagen, daß ich von dem Pascal-System regelrecht begeistert bin und wahrscheinlich nächstens Basic und Assembler durch Pascal im Eprom ersetzen (oder zumindest umschalten) werde. Die Sprache Pascal selbst empfinde ich als sehr viel angenehmer als Assembler oder Basic oder Fortran oder Algol oder Forth. Genug des langen Redens, am meisten sagt vielleicht das Beispiel-Programm: Ein Spiel bei dem auf dem Schirm eine Rennbahn gemalt wird (Grafik erforderlich), durch die 2 Spieler ihren Punkt steuern können durch Vorgabe von Beschleunigung und Fahrtrichtung (die Prozedur GET­MOVE liest die Stellung eines Tipp-Knüppels ab, dies ließe sich auch über die Tastatur machen (wie bei dem Spiel „Doppelwurm“). Das Spiel ist sehr spannend, weil man leicht aus der Kurve rausfliegen kann und für größte Geschwindigkeit wirklich die Idealkurve fahren muß. Für die trigonometrischen Berechnungen war selbst Pascal zu langsam (beim reinen „Zahlen zerkleinern“ sind Interpreter und Compiler ja gleichschnell), deshalb werden für SIN/​COS in simpler Weise vorher Tabellen angelegt.

Ich hoffe, daß damit noch einige Leute mehr

Seite 21 von 32