26.1.2000 Neues vom LGP-30
("Nr. 4 lebt")

Die defekten Befehle Y und R.

Zunächst sah es so aus, daß der Y-Befehl (Adressenersatz) und der R-Befehl (Returnadresse speichern) gar nicht funktionieren.
Durch Experimentieren fanden wir heraus, daß das so nicht stimmt: Beide Befehle schreiben zwar den Adreßteil auf die Trommel, allerdings nicht in die von den Befehlen adressierte Zelle, sondern in die physikalisch übernächste auf den Befehl folgende Zelle. Bei Messungen mit dem Logikanalysator zeigte sich, daß bei diesen Befehlen die Phase 3, in der der adressierte Operand gesucht wird, genau wie bei den beiden Sprungbefehlen nur eine Wortzeit lang ist, und dann beendet wird. Bei den Sprungbefehlen ist das so in Ordnung, bei den Y- und R-Befehlen führt das zu dem oben beschriebenen Fehler. Leider half diese Erkenntnis bis jetzt nicht, das für diesen Fehler verantwortliche Bauteil zu finden.

Am 18. Januar war dann jedoch schon wieder Weihnachten: Das Schelztor-Gymnasium in Esslingen stellte dem Computermuseum die Reliquien seines LGP-30 zur Verfügung:

• Die Trommel
• Das Logic-Board
• 3 Röhrenmodule
• Eine große Anzahl von Lochstreifen, auf denen sich praktisch die gesamte für den LGP-30 existierende Software befindet:
  ~ ACT-V, alle wichtigen Bibliotheksprogramme (9.0, 10.4 u.v.a.m)
• jede Menge Dokumentation

Auf dem Logic-Board waren einige Dioden zerbrochen. Wir haben sie mutig gegen 1N4001 (peinlich) ausgetauscht und dann das Schelztor-Board in den Rechner gesteckt. Und siehe da: Mit dem Schelztor-Board funktionieren Y und R.
Um den Rechner zu testen, haben wir einige der Lochstreifen eingelesen, das Black-Jack-Programm, das 5*5-magische Quadrat-Programm und das Pi-Programm. Auf den ersten Blick scheinen sie alle zu funktionieren. Die Spielregeln von Black-Jack kennen wir leider nicht, so daß der Rechner immer siegt, die Quadrate sehen sehr magisch aus und Pi wurde trotz der gewünschten 50 Stellen auf 60 Stellen richtig berechnet. Nr. 4 gab nach den 60 Stellen zwar immer noch nicht auf, die Berechnung war jedoch leider falsch.

Damit ist klar, daß der Y-R-Fehler auf dem Originalboard liegt, wo wir ihn hoffentlich auch noch finden werden.

Weil jetzt alles so schön funktionierte und wir soviel Software zum Ausprobieren haben, haben wir am vergangenen Donnerstag (20.1.) versucht, den Highspeed-Papertape-Reader in Betrieb zu nehmen. Leider klemmte es da schon wieder: Der Leser als solcher funktioniert zwar, d.h. die Zeichen werden korrekt in den Akkumulator des Rechners gelesen, aber danach stört der Leser alle nachfolgenden Befehle, die gar nichts mit der Ein-/ Ausgabe zu tun haben, derartig effizient, daß das ganze Programm in den Wald läuft. Offensichtlich ist die Phase 2, "Kopieren der gefundenen Zelle in das Befehlsregister" gestört.