Werner's Seiten - Computer

25.11.2018

Zunächst sollte natürlich die Hardware vervollständigt und getestet werden. Die Ladeschaltung ist endlich eingetroffen, damit werden die Lipo-Zelle im optimalem Betriebszustand gehalten. Besser als die damals einfachen Vorwiderstände zum NC-Akku - schauen wir mal wie das in 20Jahren aussieht ;-). Nur irgendwie verhält sich die CPU-Karte wie ein altes Dampfradio, nach einer längeren Aufwärmphase lief das System ordentlich - Fehlersuche.

Im Bereich der Jumper für die Speicherbestückung gab es schlechte Lötstellen, die Jumper neu Handverdrahtet und schon funktioniert es wieder einwandfreil.

Jetzt kann die Software angepasste werden ...

Im HEX-Monitor V5.5 gibt es die Funktionen 2 und 3 für die Aus- Eingabe über die Anschlüsse SOD und SID. Eigentlich für das alte Kasetteninterface aber schon mit einfachen V24-Treibern ausgestattet. Die hierzu erforderlichen Betriebsspannungen +-12Volt stellt ein kleiner Schaltregler zur Verfügung. Damit sind die grundsätzlichen Vorraussetzungen für die "Nabelschnur" hergestellt.

Da SOD/SID keinerlei Hardwareunterstützung in Form von Aus-, Eingangsschieberegister oder Baudrategenerator haben, muss das Timing und Protokoll in Software erfolgen.
Hier beginnt nun die Herausforderung, als erstes benötigt man einen Timer für die halbe Bitdauer,
bei 600Bd (für den 1.Test) sind das 833µs. Die halbe Bitdauer ist für das Abtasttheorem beim Empfang der Bits erforderlich, im Hex-Monitor beträgt diese 1ms, also nicht normgerecht für die gewählte Baudrate. Also Taktzyklen für die einzelnen Befehle aufadiert und den Schleifenzähler ermittelt (HTIME) und daraus einen neuen Timer programmiert:

Als Berechnungsgrundlage dient natürlich der Quarz von 6,144Mhz, das ganze halbiert (wg. dem Oszilator) ergibt das eine Zykluszeit von rund 0,325µs. Die # zeigt die Taktzyklen pro Befehl, das ergibt rechnerisch 178 Schleifendurchläufe mit jeweils 14 Taktzyklen. Nach der Messreihe hat sich schließlich der Wert für HTIME 174 ergeben, damit wird die Baudrate von 606Bd erzeugt - genau genug. Für 2400Bd konnte der Wert nicht einfach durch halbieren ermittelt werden, da dann die aufrufenden Befehle einen größeren Anteil an die Verzögerungsroutine bekommen. Ich hoffe das das Ganze schließlich mit 1200Bd im Empfangsmodus sicher funktioniert - schauen wir mal...

Damit das ganze einfach und mit ausreichendem Komfort getestet werden kann, ist der CP/M-Moppel mit dem provisorischem SOD/SID Interface ausgestattet. Mit dem Hex-Lader können die "Programme" einfach geladen und getestet werden - sich selber an der Haaren aus dem Sumpf ziehen funktionier nur bei Münchhausen ...

Die erzeugten Zeiten mit dem Oszilloskop gescheckt und anschließen mit einem einfachem Sendeprogramm ausführich für die drei Baudraten getestet und dem LogikSniffer fein abgestimmt.

Senden ist ja noch einfach, der Empfang deutlich schwieriger da für den Handshake ja auch noch das RTS-Signal generiert werden muss. Hier bietet sich der SOD-Ausgang an, wenn der Moppel Empfangsbereit ist muss RTS auf Low gesetzt werden. Damit bietet diese Software V24 halbduplex mit manueller Umschaltung von Senden auf Empfangen an. Suboptimal aber für den Einsatzzweck "Bootloader" ausreichend.

Nebendran ein paar Bilder vom Timing und "Messaufbau" -->>>>

Die grundsätzlichen Ein- Ausgaberoutinen sind auf Basis FCT2/3 aus dem Monitor V5.5 erstellt und getestet. Der Empfang funktioniert sogar mit 2400Bd - hätte ich nicht gedacht, aber nur wenn der Moppel alles sofort zum Buffer schieben kann. Grund ist der FIFO im PC, der trotz gesetztem RTS noch ein/zwei Bytes sendet.

So kann kein Zeilenbuffer für den Intel-Hex-Lader realisiert werden, sondern nur noch mit einem "großen" Buffer wo der komplette Code reinpasst, sehr unschön, zumal ja das Dateiende erst im HEX-Interpreter ermittelt werden kann. Aber dort kommt das Programm erst garnicht hin da die CPU auf das nächste Startbit wartet und

... und es klappt doch !
In der Warteschleife ein Timeoutzähler eingebaut. Zunächst eine Taktanalyse durchgeführt ob die zusätlichen Bytes den Abtastzeitpunkt nicht zu weit nach hinten legen. Bei maximal 30µS Ver-zögerung ist das selbst bei 2400Bd (Bitzeit=420µs) noch OK.

Der Timeout wird aber über ein Flag erst nach dem 1. empfangenen Byte aktiv. So wartet nun die Empfangsroutine bis ein Byte empfangen wurde, sobald der Datenstrom aufhört, greift der Timeout nach ca. 1 Sekunde und das aufrufende Programm erhält wieder die Kontrolle zurück. Das ist erstmal ein guter Kompromiss.

Es wartet aber ein noch größeres Problem auf Lösung.
In den vorhandenen PC's kann der FIFO nicht vollständig abgeschaltet werden, es trudeln immer noch ein/zwei Bytes ein obwohl RTS schon lange gesetzt ist. Mit Hilfe von IRQ-Routinen kein Problem, die stehen hier aber nicht zur Verfügung. Entweder ich schaufel die Intel-Hex-Datei in einem Rutsch in einem recht großen Buffer oder die Übertragung muss über den CP/M-Moppel erfolgen, denn der UART 6850 hat kein FIFO.

Die zuerwartenden Testroutinen, dafür soll der ganze "Quatsch" ja sein, kommen wohl mit den 2kByte RAM als Eingangspuffer (ab 2000h) aus. Das fertige Testprogrämmchen kann dann in dem 2800er Bereich unterkommen.

schauen wir mal ob das so Funktional ist ...

Das FIFO-Problem habe ich hinten angestellt, die einfachste Lösung ist erstmal ein großer V24-Eingangsbuffer. Dieser übernimmt die einlaufenden Bytes komplett entgegen, so kommt die Datenübertragung nicht aus dem Tritt. Erst wenn alles hübsch im Speicher ruht macht sich der Intel-Hexinterpreter an die Übersetzung. Hier ist, wie bei meinen anderen Versionen auch ein Zeilenbuffer zwischengeschaltet, eigendlich nicht nötig aber es soll ja noch der Softwarefifo kommen und der Hex-Interpreter ist es so gewohnt ;-) ...

Das ganze habe ich erstmal mit dem CP/M-Moppel ausprobiert, da hier die Nabelschnur und und das Drumherum deutlich comfortabler ist. Für den Moppel-4 müssen die Bildschirmmeldungen noch HEX-Display gerecht aufbereitet und auf den Adressbereich angepasst werden.

beim Basteln benötige ich manchmal einfach einen Zähler, Adressdecoder oder nur einen Datenport.
Hab ich bisher immer auf dem Steckbrett zusammengestrickt, sollte doch einfacher gehen - so per Software ...

Im Fundus liegt ja noch eine weiter CPU-Karte nebst HEX-Display und Tastatur, war ja schon bei der Inbetriebnahme diverser Karten erfolgreich im Einsatz. Ein schönes Gehäuse gab es auch noch,
also alles eingebaut. Die Stromversorgung ist mit einem Steckernetzteil recht einfach zu lösen.

Für den Datenaustausch hat die Karte ja eine einfache V24-Schnittstelle, die +-12V erzeugt ein kleiner Spannungswandler. Für Testzwecke ist der Systembus ist rausgeführt, hier kann eine EC-Bus Karte mit zwei Steckplätzen angefügt werden.

Der 3. Steckplatz(FDC-Routinen) ist mit einem 2. SRAM bestückt, so stehen insgesammt 4kByte SRAM (2000h-2FFFh) mit Batteriepufferung zur Verfügung. Die Ladeschaltung für die LIPO-Zelle ist noch irgendwo auf Hoher See ...

Als Softwaregrundlage dient das Monitorprogramm im 1.Steckplatz, damit ich das ganze mit den Testroutinen beschicken kann, muss der "Intel-Hex Interpreter" angepasst werden, so dass er als "Boot-Loader" dient ...

Für die Datenübertragung, stellt man den Programmcounter ([ADR] mit dem Hex-Monitor) auf 1000h und startet mit der Taste [RUN] siehe Bild 1. Am Entwicklungsrechner startet man die zu übertragende Datei und los gehts (Bild 2).

Keine überhastete Eile dabei, denn der Moppel wartet bis das erste Byte eintrifft. Sobald er das alles hübsch in HEX in den Speicher ab 2800h gelegt hat, gibt es noch eine schlichte Meldung ob das auch funktioniert hat (Bild 3). Mit der Taste [NXT] springt er zurück zur Startadresse (Bild 4). Dort kann das geladene Programm dann einfach mit [RUN] gestartet werden.

Der Vollständighalber hier Übersicht der Rückmeldung:

; Err-0 alles OK
; Err-1 Uebertragungsfehler
; Err-2 kein ASCCI-Zeichen
; Err-3 keine Startmarke im Hexfile gefunden
; Err-4 Pruefsumme falsch
;

Damit ist die "Nabelschnur" zum Moppel 4 erstmal funktionstüchtig und muss nun in der Praxis zeigen ob es eine Hilfe im Sinne des o.g. Gedanken darstellt. Hierzu bedarf es natürlich noch eine ECB-Karte mit vielen Ein- und Ausgängen - Platine liegt schon bereit ...

Den Quellcode findet ihr in den Dokumentationen (HEX-Lader)

In meinem Fundus lag noch eine schöne leere Platine für das Parallelinterface, ideal zum Experimentieren. damit komme ich der Einleitung wieder etwas näher.

Material zusammengesucht und ergänzt, nach kurzer Zeit lag sie fertig auf meinem Basteltisch. So lose konnte es nicht bleiben, denn die Gefahr von unliebsamen Kurzschlüssen ist beim Experimentieren doch zu groß. Ein Gehäuse oder ähnliches musste da noch drum, glücklicherweise hatte ich die Leerplatine noch auf den Scanner gelegt. So brauchten die vielen Bohrungen nicht mühsam ausgemessen werden. Als Hintergrundbild in der CAD-Software gelegt und den Rest als 2.Layer draufgelegt. Anschließend das Hintergrundbild löschen und die Zeichnung durch CAM-Programm und Fräse schieben. Beim Zusammenbauen ist mir aufgefallen, das der 8255 nur nach kompletten Zerlegen zu wechseln wäre. Also die Fräse nochmals bemüht und den Ausschnitt nachgearbeitet ...

Und das ist dabei rausgekommen.

Die Karte hat leider keinen ECB-Anschluß, so musste sie noch mit einem Adapter Anschluß finden, hier fehlt noch eine Zugentlastung damit die Drähte Kontakt halten. Die Ausgänge sind über Pfostenstecker ausgeführt damit eine Einfache Kontaktierung zum Experimentier-Board möglich ist.

Fürs erste Experiment eine kleine Routine geschrieben, die mir ein Taktimpuls (2ms), einen 8bit Zähler sowie 8 Schalter bereitstellt. Die Bilder 2 und 3 zeigen das erhoffte Ergebnis.

Das ganze kann natürlich mit den heutigen Mitteln, z.B. mit einem kleinen AVR, deutlich einfacher, billiger und schneller aufgebaut werden. Aber solche schönen Microcontroller gab es in den 80er noch nicht. Ja - Intel hatte die 8048 Familie bereits 76 an den Start gebracht, waren aber in erster Linie Maskenprogrammiert, also direkt bei der Herstellung wurde das Programm eingebaut, nichts für uns Hobbybastler.

Hier haben wir es ja mit einem Oldtimer zu tun (älter als 30 Jahre;-) das fühlt sich einfach besser an ! Schauen wir mal wie offt er zum Einsatz kommt ...

Mit ein paar kleinen Testroutinen die den 8255 initialisieren und Datenmuster an den drei Ausgangskanälen anlegen, lässt sich der Moppel wunderbar einsetzen - Hier die CF-Karte für den Prof180x.

Für Z80 IO-Karten benötigt man aber noch eine Signalanpassung, z.B. IO/M vom 8085 als /IORQ für den Z80 bereit gestellt wird.