a_whg_bo_bl_090921bc.jpgb_bo_vo_01.jpgbo_vo_03.jpgc_sh_20090810_1219137715a.jpgd_sh_20090810_1884408984a.jpgf_no_kanal_brunsb_01.jpgg_zuletzt_20110323_1260177973a.jpgs_schillig-reede_03.jpg

25.09.2020

Z89 und CP/M - Retrocomputing

1. Vorgeschichte

In den vergangenen Jahren gab es immer wieder Situationen, in denen ich mich an meine intensive private und berufliche Beschäftigung mit den Computern der CP/M-Ära erinnerte und das dringende nostalgische Bedürfnis verspürte, mich damit am realen Objekt noch einmal ausführlich zu beschäftigen. Gelegentliche Versuche mit einem CP/M-Emulator verliefen unbefriedigend. Die Emulatoren funktionieren durchweg recht gut, lieferten mir aber nicht das Erlebnis, das man nur mit einer realen CP/M-Maschine haben kann.

Ende der 70er und Anfang der 80er Jahre des letzten Jahrhunderts war eine Zeit, in der man sich noch Computer selbst zusammenbauen konnte, bzw. musste, wenn man z.B. als Student oder Berufsanfänger nur wenig Geld zur Verfügung hatte. "Auf der Arbeit" waren diejenigen, die über die Ausgabe der Mittel zu bestimmen hatten, eher misstrauisch und vorsichtig, was den Einsatz der neumodischen Mikrokomputer und Mikrokontroller anging, und verließen sich z.T. eher auf die Verwendung von raumfüllenden Rechnern der sog. mittleren Datentechnik mit Terminals in allen Arbeitsräumen und Laboratorien.

Also baute man sich die ersten Mikrokomputer aus "Verbrauchsmaterial" zusammen und stellte deren Nutzen mit praktischen Anwendungen unter Beweis. In diesem Zusammenhang fallen mir durchgeführte Experimente mit der damals noch in den Anfängen stehenden Bildverarbeitung oder mit der Steuerung von komplexen Messeinrichtungen ein. Während die Wissenschaftler unverdrossen auf dem Zentralrechner in Fortran IV programmierten, setzten wir Ingenieure uns mit den Feinheiten des Z80-Assemblers und CP/M auseinander. Noch heute kann ich fast im Schlaf Teile des Z80-Codes zitieren, so tief sitzt die Erinnerung.

Im privaten Bereich nahm mich zu dieser Zeit neben einer fast exzessiven Beschäftigung mit dem Amateurfunk zunehmend auch das Thema Mikrokomputer in Anspruch. Für meinen ersten Rechner zu Hause besorgte ich mir einen 19" Rahmen und stattete ihn mit einer ECB-Busplatine und einem Netzteil aus. Letzteres wurde später durch ein Netzteil des IBM PC AT ersetzt. Somit standen mir mehrere Steckplätze für die benötigten ECB-Europakarten zur Verfügung. Das waren zunächst das CPU-, Speicher-, Video- und Floppy-Disk-Controller-Board. Zum Teil bestückte ich vorgefertigte Platinen mit den benötigten Bauteilen, teilweise fertigte ich aber auch eigene Layouts nach Schaltplan mit der im Betrieb vorhandenen Wire-Wrap-Technik an. Sehr bald bekam ich diesen meinen ersten Z80-Computer mit einem Monitorprogramm ans Laufen. Im Betrieb fertigte ich mir eine 8" CP/M 2.2 -Systemdiskette an. Als Monitor musste zunächst ein portabler Fernseher herhalten, zu diesem Zweck befand sich auf der Videoplatine auch ein Modulator für den Fernsehbereich I. Eine Tastatur aus einer kommerziellen Rechenanlage wurde mittels EPROM auf den CP/M-verträglichen ASCII-Zeichensatz umkodiert. Fehlten nur noch die Floppy-Laufwerke.

Für ein paar Mark konnte ich zwei vormals in einer größeren Rechneranlage eingesetzte 8" Laufwerke erwerben. Das waren noch Laufwerke, die ihren Namen verdienten. Sie wogen pro Stück ca. 15 kg, benötigten jeweils eine 220V-Netzsteckdose und hatten einen ständig laufenden faustgroßen 220V-Induktionsmotor als Antrieb. Die eingelegten Disketten liefen während der gesamten Sitzung ununterbrochen mit. Der Schreib-Lesekopf wurde bei Bedarf mittels eines Elektromagneten mit lautem Klacken an die rotierende Diskette herangezogen und ebenso laut wieder losgelassen. Der riesige Schrittmotor mit nachfolgendem Spindelantrieb diente zur Positionierung des Schreib-Lese-Kopfes und machte Geräusche wie eine alte Nähmaschine. Nach langer Fummelei an den Anschlüssen und am Controller tauchte irgendwann der erlösende CP/M-Prompt A> auf und der CP/M-Rechner war somit betriebsbereit.

Übrigens hatte ich später einmal aus Versehen den Rechner und damit auch die Laufwerke nebst Disketten zwei Tage durchlaufen lassen. Zunächst befürchtete ich, das wäre es mit den Disketten und Laufwerken gewesen. Aber nichts war passiert, die Disketten waren unbeschädigt und trotz tagelanger Rotation lediglich handwarm.

In der nachfolgenden Zeit wurde der Fernseher durch den Monitor eines MS-DOS-Rechners ersetzt, welcher über eine serielle Verbindung die Terminalfunktion übernahm. Für den Austausch von Dateien über die serielle Verbindung hatte ich mir sehr bald in Z80- und 8086-Assembler ein Kommunikationsprogramm geschrieben, was in etwa der Funktionsweise des heutigen und zumindest mir damals noch unbekannten XMODEM-Protokolls entspricht.

2. Das Projekt

Vor ein paar Monaten sagte ich mir "Wenn nicht jetzt, wann dann?" und beschloss, mir einen Einplatinen-CP/M-Computer zuzulegen. Diesen selbst aufzubauen, war mir aus verschiedenen Gründen leider nicht möglich. So stöberte ich u.a. bei Ebay herum und kaufte schließlich einen Zeta Single Board Computer V2 mit 3,5 " Floppy Drive und einem SD-Karten-Adapter. Die Dokumentation der Hardware findet sich hier.

Das Floppy-Laufwerk benötigt keine externe Stromversorgung, sondern erhält diese über einen kleinen 2-Pol-Stecker auf dem Board. Die Kommunikation mit der Umwelt erfolgt über eine RS232-Schnittstelle, die bei meinem Board allerdings nicht mit einem MAX232 Schnittstellen-IC bestückt war. Statt dessen hatte man mit Brücken in der IC-Fassung die invertierten RxD- und TxD-Leitungen vom UART direkt auf die DB9- Buchse geführt zwecks Anschluss eines USB-To-Serial-Konverters. Für den zunächst vorgesehenen Anschluss an einen alten MSDOS-Rechner war aber eine echte RS232-Verbindung erforderlich und so plazierte ich ein MAX232 in die bereits vorhandene IC-Fassung und lötete 5 fehlende 100nF-Kondensatoren ein. Die Schnittstelle funktionierte zunächst nur in eine Richtung, entgegen dem Schaltplan war Pin 2 der Buchse nicht mit Pin 8 des MAX232 verbunden, offensichtlich ein Fehler im Layout. Nachdem ich einen Draht von Pin 2 der Buchse an das hochgebogene Beinchen 8 des ICs angelötet hatte, funktionierte die Schnittstelle in beiden Richtungen einwandfrei.

Wie gesagt, war ich zunächst der Auffassung, den Zeta2 SBC an einem MS-DOS-Rechner betreiben zu müssen. Auf diesem Rechner waren im Dual Boot Windows 98  SE und Debian 10 LXDE installiert. Windows 98 SE deshalb, weil es das letzte Windows mit vollständigem MS-DOS (7.1) war und ich damals einige Anwendungen für die Interaktion von CP/M mit MS-DOS programmiert hatte. Debian 10 LXDE deshalb, weil es ein schlankes, sicheres und aktuelles Linux-Betriebssystem ist und man sich nicht mit den Rressourcen fressenden aktuellen Windows-Versionen mit ihrem Update-Terror herumärgern muss (ständig "Bitte warten...Schalten Sie den Computer nicht aus"). Wenn man im Internet surfen will, kann man das heutzutage nicht mehr vernünftig und sicher mit Windows 98, sehr viele Seiten lassen sich nicht öffnen. Allenfalls geht noch FTP. Auch für den Betrieb des USB-To-Serial-Converters habe ich keine passenden W98-Treiber gefunden.

Wenn man mit dem Rechner, an den der Zeta2 SBC angeschlossen ist, nebenher auch noch das Tagesgeschäft erledigen will, geht einem die notwendige ständige Dual-Booterei auf Dauer mächtig auf die Nerven. Zudem stellte ich nach intensiver Beschäftigung mit der Zeta2-Software fest,, dass es für mich heute keine Notwendigkeit mehr ergibt, auf dem Host DOS laufen zu lassen. Somit konnte ich mich darauf konzentrieren, alle Interaktionen mit dem CP/M-SBC unter Debian 10 LXDE zu bewerkstelligen.

Die Software des Zeta2 SBC befindet sich in einem 512k-NOR-FLASH, welches im laufenden Betrieb neu "geflasht" werden kann, und ist ausgezeichnet dokumentiert.  Man lädt man das aktuelle RomWBW Distribution Package herunter, entpackt es und liest die Dokumentation und die zahlreichen ReadMe-Dateien. Mit den dort verfügbaren Informationen ist es z.B kein Problem, den ROM-Inhalt nach durchgeführten Änderungen im HBIOS neu zu kompilieren und in den Zeta2-SBC zu laden. Dies habe ich einmal mit der Eingabeaufforderung eines Windows 7-Rechners durchexerziert, es klappte wie am Schnürchen. Genau so gut könnte man es auch mit dem LX-Terminal des Debian10-Computers durchführen.

Bei mir erfolgt jetzt die Kommunikation mit dem Zeta2-SBC unter Linux (Debian 10 LXDE) im LX-Terminal mit dem Programm MINICOM. Wenn man einmal das Setup richtig aufgesetzt hat, geht alles ruck-zuck, insbesondere auch die bidirektionale Übertragung von Dateien mit der XMODEM-Funktion von MINICOM auf der Linux-Seite und der Anwendung XM.COM (vormals XMODEM.com) auf der CP/M-Seite. Dabei spielt es übrigens keine Rolle, ob man die serielle Schnittstelle (ttys0) oder den Serial-To USB-Converter  über ttyUSB0 verwendet.

Die 3,5 " Disketten kann man unter CP/M mit FDU.COM formatieren. Dieses Format kann aber weder von DOS, Windows noch von Linux gelesen werden. Wer mag, kann sich unter MS-DOS mit den Anwendungen ANADISK und 22DISK zwecks Analyse, Lesen und Schreiben dieses Disk-Formates auseinandersetzen, ich hatte damit allerdings keinen Erfolg. Zwischenzeitlich habe ich festgestellt, dass im RomWBW-Package die passende Disk-Definition zu finden ist, es hat sich mir aber noch nicht erschlossen, wie genau ich diese in 22DISK zu implementieren habe.

Eine weitere Anwendung, die im RomWBW-Package zu finden ist, lautet FAT:COM und diese lässt sich vom Host mittels XMODEM-Protokoll auf eine Diskette oder SD-Card des CP/M-SBC transferieren. Mit FAT.COM ist es möglich, unter CP/M eine FAT32-Diskettne zu formatieren, lesen und zu beschreiben. Die Disketten können somit ebenfalls unter Windows oder Linux gelesen und beschrieben werden. FAT32-Disketten kann man übrigens im Gegensatz zu CP/M unter Windows und Linux  auch formatieren, wenn sie einem USB-Diskettenlaufwerk stecken.

Zu den weiteren segensreichen, im RomWBW-Package zu findenden Anwendungen, die es damals noch nicht gab, gehört auch FLASH.COM. Einen auf die CP/M-Diskette transferierten RomWBW-Build (512k) habe ich im laufenden Betrieb damit ganz locker ins ROM übertragen. Läuft wie geschmiert und nach dem Reset ist alles neu. Jedenfalls dann, wenn man bei der Modifikation keine Fehler gemacht hat. Ansonsten muss man u.U. den originalen RomWBW-Build mit einem Programmiergerät auf das NOR-FlASH übertragen. Für alle Fälle habe ich das Teil erfreulicherweise noch im Schrank.

 

 

 

 

 

 

 

 Fortsetzung folgt...

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

++

 

 

Template by a4joomla, modified by DL8YCA         Impressum