Software zur Nutzung für die EAE Erweiterung


Die EAE Erweiterung für die pdp8/e genauer genannt EXTENDED ARITHMETIC ELEMENT KE8-E, besteht aus den beiden Platinen M8340 und M8341, welche in die pdp8/e integriert werden. Um sie nutzen, müssen sie über eigene Opcode Befehle angesprochen werden. Diese können der POCKET REVERENCE CARD entnommen werden.

So ohne weiteres tut das aber keine Software, so dass ich eine Weile auf der Suche nach passender Software dazu war. Da die Option das Rechnen schneller macht, ist es natürlich ein tolles Mittel um Formeln zu beschleunigen! Die Option finde ich daher für Rechner, zum Rechengebrauch, recht wichtig.


29.01.2020 Zuerst hatte ich kennengelernt, daß der Fortran4 Compiler unter OS/8 beim Kompilieren prüft, ob eine rechenunterstützende Option eingebaut ist (EAE oder FPP), und diese dann nutzt, sofer  vorhanden. Das klappt! Der Geschwindigkeitsvorteil bei meinem kleinen Apfelmännchen ist fast Faktor 2 höher mit EAE.. 

Aber weitere Software zu finden, die diese Option nutzt, erschliesst sich nicht leicht auf Anhieb. Mittlerweile habe ich etwas gefunden und will es hier kurz vorstellen.


OS/8 Basic

Da dies Basic sehr weit verbreitet ist, hatte ich gehofft es auch mit der EAE Option nutzen zu können. Und das ist auch möglich, wenn man es entsprechend einrichtet! Das BASIC besteht aus mehreren Files. Eines ist die Laufzeitbibliothek mit Namen BRTS.SAV. Wie der Name sagt ist es ein gesichertes Speicherabbild. Man erhält es, wenn man die Sourcen compiliert und in den Speicher lädt. Dann kann man die entsprechenden Speicherbereiche mit dem Befehl SAVE aus dem Speicher als Datei ablegen. Dazu muss man aber wissen welche Bereiche das sind. Und genau diese Details stehen in folgendem Dokument: "OS/8 Basic System Build Instruction" Der Vorgang ist in Kapitel 4 beschrieben und funktionierte bei mir sofort. Zuerst wird BRTS mit einem Schalter versehen, der beim Kompilieren EAE berücksichtigt. Danach wird das Ergebnis in den Speicher geladen und die entsprechenden Files gesichert. Fertig ist die angepasste Installation. Hat man die Sourcen zum kompilieren nicht gefunden, kann man auch die Datei EABRTS.BN laden und in die notwendigen Files sichern.


Die BASIC Dateien findet man im Web an vielen Stellen, zum Beispiel auch beim PiDP8 Projekt bei Tangentsoft.

Auch hier finde ich einen Geschwindigkeitsvorteil von etwa Faktor 2.


U/W FOKAL

Das Focal der Universität Washington ist auch beim PiDP8 Projekt an Board. Bisher dachte ich das sei defekt, weil ich keinerlei vernünftige Ausgaben beim Rechnenn erhalten habe, nun weiss ich warum, es nutzt die EAE Option zwingend. Dies ist einer Text Datei zu entnehmen. EAE ist also bei der PiDP8 einzuschalten (set cpu eae).

U/W FOCAL ist gegenüber den originalen DEC FOCAL Versionen erweitert. Einige Funktionen sind hinzugekommen und auch die EIN/Ausgabe überarbeitet. 


FOCAL69

08.02.2020 Die bisher genannten Programme laufen unter OS/8, für Demonstrationszwecke hätte ich aber auch gerne ein paar Programme, die ohne OS/8 eigenständig  funktionieren. Auf meiner Suche habe ich in der Dokumentation zum FOCAL69 ( ADVANCED FOCAL DEC-08-AJBB-DL) im Kapitel 3.5.7 den 8 Worte kurzen Patch (s.o.) gefunden. In diesem Patch wird in den Code  zum Multiplizieren der EAE Opcodes (MQL MUY) 7425 eingebracht. Das scheint sehr einfach aber auch effektiv zu sein. Es wird also als einziges das Multiplizieren gepatched. Dieser Patch ist aufgrund seiner überschaubaren Größe schnell von Hand in das geladene Programm einzugeben. 

Focal69 kann durch Hinzuladen von Overlaydateien um weitere Funktionalitäten ergänzt werden. Eine davon verändert den Umgang mit Zahlen, und nutzt dann 4 Worte zum abspeichern von Zahlen. Entsprechend erhöht sich die Darstellungsgenauigkeit:

Das Ergebnis von 1/7 Ist somit entweder: 0.142857 oder mit patch (4word dec-08-aj1e) 0.1428571429E+00.

Aber unabhängig davon funktioniert der EAE Patch. Egal welche Zahlengenauigkeit man wählt, die Geschwindigkeit beim rechnen gewinnt mit dem Patch!

mit der einfachen Rechenschleife habe ich die Geschwindigkeitsunterschiede ermittelt:

01.10 FOR N=0,1,1000; S X=FSIN(N/500)

Jeweils wird weniger Zeit benötigt, wenn die EAE mit eingebunden war. Ein voller Erfolg! Wobe zu beachten ist, das FOCAL als Interpreterstprache nicht die Geschwindigkeit erzielt wie eine Compilersprache. Aber auch hier gab es einen deutlichen Gewinn von etwa 30% an Geschwindigkeit.  

Die Testzeiten an der lab8/e:

FOCAL69                                            34s

FOCAL69 EAE Patch                         27s

FOCAl69 4WORD Patch                    50s

FOCAl69 4WORD + EAE Patch        35s

FOCAl69 4WORD + EAE_DECUS    19s


Bei DECUS gab es noch effektivere EAE Anpassungen:

FOCAL8-283

FOCAL8-284

Leider konnte ich die bisher nicht finden. Aber es gibt einen weiteren Patch seitens DECUS:

focal8-313 (EAE Patches for FOCAL)  Dieser Patch lässt sich kompilieren und laden. Er beschleunigt durchaus erheblich stärker, so dass man beim FOCAL69 mit 4Word und diesem EAE-Patch die Zeile in nur 19s rechnet!


FOKAL71

Die Version, welche ich gefunden habe, ist an den entsprechenden Adressen identisch zum Focal69. Daher funktioniert auch hier der oben angegbene Patch! Focal 71 hat einen etwas erweiterten Funktionsumfang, da habe ich bisher nicht genug gespielt, um zu sehen, ob es noch Seiteneffekte gibt. 

Aber die Testzeile funktionierte wie erwartet.


FOKAL68

Vom FOCAL68 habe ich zwei Dateien, die ein lädt gar nicht, die andere klappt nur mit bestimmten Voraussetzungen im simh. Für das Fokal68 habe ich keine Dokumentation oder irgendeinen Hinweis gefunden zur Nutzbarmachung der EAE Option. Daher habe ich mal in die Binärdaten geschaut und entdeckt, dass es etwas verschoben zu den Adressen vom FOCAL69 eine sehr ähnliche Sequenz gibt. Angepasst an deren Adressen und Speicherplätze, habe ich für den Bereich den Patch folgendermaßen angepasst: EAE Patch für FOCAL68 (DEC-08-AJAD):

7241 3244

7242 1272

7243 7425

7244 0

7245 3266

7246 7501

7247 3270

7250 5265

Nach Anpassen der Speicheradressen funktioniert eine einfache Testschleife zum Berechnen eines Sinuswertes deutlich schneller als vorher.  Allerdings scheint die Rechengenauigkeit vom Sinus deutlich gelitten zu haben, eventuell ist das noch nicht ganz in Ordnung so. Die Testzeile benötigt 32s oder mit Patch 25s. Aber mit den Rechenergebnissen ist der Patch so nicht nutzbar.

Die FOCAL68 Datei bekomme ich an der lab8/e nicht zum Laufen. Da scheint es Probleme mit der seriellen Ansteuerung zu geben. Das wird noch zu untersuchen sein. Aber wenn ich im simh erst das FOCAL69 gestartet hatte, und dann das Focal68 darüber lade, dann startet es. Es scheinen also ein paar Worte, in den Bereichen ausserhalb des Codes der geladen wird, dafür verantwortlich zu sein. Diesem Umstand bin ich nachgegangen und habe den Speicher aus dem simh herausgeschrieben. Leider funktioniert der dump Befehl nicht, aber mit examine 0/7777, wird der Speicher ausgegeben. Mit cut+paste und etwas anpassen, bekomme ich einen Code, den ich mit Palbart zu einem BIN compilieren kann. Das Ergebnis startet auch auf der lab/8. Damit sind die Messungen oben dann gemacht worden.

Aus dem Netz habe ich drei verschiedene Files (Länge) vom FOCAL68 gefunden. Wenn ich die genauer anschaue sind zwei davon identisch, bezüglich dessen was in die PDP8 geladen wird. Das dritte File ist nur stellenweise und etwas versetzt identisch, das halte ich für defekt. 

Durch Vergleich des Speicherinhaltes des FOCAL68 mit dem des überlagerten Startenden, finde ich nach einigem Probieren eine Adresse, deren Inhalt geändert werden muss, damit das FOCAL68 auch auf der lab8/e anläuft und in einer frischen simh Session: 0176 2741 (war 4400).

Zusammenfassend eignet sich FOCAL68 so leider nicht für die Nutzung mit der EAE, aber mag ja noch kommen….