Das MiniZ-C System
Genau einen Tag vor Weihnachten kam der in Kanada bestellte CP/M Rechner an. Wie üblich zu einer Uhrzeit wo ich nicht da war, so das ich am 24.sten noch zur nächsten Postfiliale musste und Zoll und Auslagen bezahlen.
Zuerst hat das Ding nicht funktioniert. Ein Zettel wies mich darauf hin, von der beiliegenden Micro-SD Karte ein Backup zu machen, doch das funktionierte nicht. Währenddessen verabschiedete die SD-Karte sich und wurde fort-hin nicht einmal mehr als SD-Karte erkannt. Mittels der spärlichen Dokumentation im Internet konnte ich immerhin die Treiber für den COM-Port installieren und nach einigen Versuchen auch eine Verbindung herstellen. Spätestens jetzt ist ein Wort fällig, wie diese Selbstbau-Retrorechner funktionieren. Der komplette Nachbau eines Rechners aus den achtziger Jahren ist auch heute für Amateure praktisch nicht möglich. Der Knackpunkt ist die Bildschirmdarstellung. Dafür müsste ein ASIC oder Grafikprozessor laufen der laufend den Speicher ausliest und die Pixel auf den Monitor ausgibt. Das gibt es nicht frei verfügbar und wenn dann nur in niedriger Auflösung wie den TMS 9928/8 der immer noch produziert wird.
Stattdessen nehmen die meisten Rechner ein CP/M, das im Quelltext frei verfügbar ist und passen den Quellcode an. Dieser nutzt dann ROM-Flash oder eine Mikro-SD Karte als Datenspeicher – das ist sogar einfacher, als die Unterstützung von Disketten da das zeitkritische Auslesen während die Scheibe rotiert entfällt. Wenn der Z180 oder seine Nachfolger verwendet werden, dann braucht man nicht mal einen weiteren Baustein um das Board an den PC anzuschließen. Da dieser eine SIO (serielle Schnittstelle) eingebaut hat. Eine USB Schnittstelle liefert nicht nur den Strom, sondern dient auch als Kommunikationsport.
Auf PC Seite braucht man einen Treiber der die Roh-Ports als Com-Ports behandelt, den Treiber fand ich nach Lesen des Minimanuals schnell anders als behauptet installierte Windows selbstständig keine Treiber.. Nach einigen Probieren gab es auch eine Verbindung mit einem Terminalprogramm. Ich habe nach einigem Ausprobieren mich für TeraTherm entscheiden.
Für den MiniZ ist es so, das er alles, was auf dem Bildschirm erscheint, über die serielle Schnittstelle ausgibt, alle Tastatureingaben von der seriellen Schnittstelle annimmt. Die Entwickler haben sich also die komplette Verwaltung des Bildschirms gespart. Ebenso müssen sie nicht die Tastatur abfragen. Es dauerte etwas, bis ich die Konsequenzen dessen begriff. So gibt es natürlich etliche CP/M Programme jenseits kleiner Utilitäres, die visuell arbeiten, also den Cursor ansteuern. Ich programmiere in Turbo Pascal und da geht das nur so. Codes für die Verwaltung des Screens werden dann benötigt. Ich habe lange Zeit versucht Turbo Pascal anzupassen. Das Problem: Die ANSI Sequenz, die man dort als System auswählen kann, schaltet nicht nur Highlight um, sondern wechselt auch die Schriftart. Trotz intensiver Suche und zig Versuchen fand ich nicht eine Sequenz die das nicht tat. Frustrierend. Die Sequenzen funktionieren, wenn ich sie isoliert ausgebe, aber nicht beim Start von Turbo Pascal, da bleibt es im Highlight-Mode stecken.
Man kann Teraterm beibringen auch die PC-Keys zu unterstützen, nun ja teilweise, denn das Markieren mit Shift gab es bei keiner CP/M Anwendung. Doch auch hier Frustration. Die Backspace Taste kann ich so einstellen, dass sie entweder in Turbo Pascal richtig funktioniert oder in CP/M. Unterschieden werden eben die Codes Del (127) und Backspace (7). Das könnte man lösen, wenn man die ganzen Controlcodes in Tinst nochmal eintippt, doch bei über 40 Positionen mache ich immer Fehleingaben.
Überhaupt ist das Entwickeln schwer. Man ist den Rückschritt in der Enzwicklung von IDE über 40 Jahre gar nicht mehr gewohnt. Mache ich heute einen Fehler, so bekomme ich eine Meldung, er wird abgefangen. Unter CP/M stürzt bei gravierenden Fehlern CP/M oder zumindest Turbo Pascal ab, bei kleineren bekommt man einen wenig aussagenden Runtime error und eine Adresse. Ein Beispiel ist das einfache Bestreben die Zeit zu messen. Braucht man für jeden Benchmark. Das System hat eine Echtzeituhr, die man mit Call 46h abfragen kann, dann bekommt man einen Zeiger in HL auf den Block, wo die Daten stehen. In Assembler ist dann das Kopieren in Variablen ganz einfach:
clock equ 46h
org 100h
start: ld c,0
call clock
ld b,(hl)
inc hl
ld c,(hl)
ld (days),bc
inc hl
ld a,(hl)
ld (hours),a
inc hl
ld a,(hl)
ld (minutes),a
inc hl
ld a,(hl)
ld (seconds),a
ret
days db 00
hours db 00
minutes db 00
seconds dw 0
end
Das funktioniert auch in DDT so, nur muss man in Turbo Pascal das als Inline Assembler schreiben. Dort funktionierte es nicht. Da ich mir nicht sicher war, das ich alle Codes als Hexadezimalziffern korrekt übertragen hatte und ich auch noch später Inline Assembler brauchte – schließlich fehlt in Turbo-Pascal 3 einiges, was man sonst so braucht, wie die Möglichkeit sich über das Filesystem zu informieren. Suchte ich nach einer Möglichkeit direkt aus Assembler Quelltext Inline Code zu erzeugen. Nach etwas Suche fand ich einen Z80 Assembler in Pascal, denn man mit Turbo 3 übersetzen konnte. Nur war der grauenhaft programmiert. Nach einem halben Tag hatte ich ihn so modifiziert, dass er als Ausgabe Inline Code produzierte. Als Nebenprodukt erzeugt eine zweite Version nun auch direkt Com-Files weil die ursprüngliche Ausgabe in Hex Ziffern unbrauchbar war, da inkompatibel mit dem Intel Hex Format.
So merkte ich bald, dass der Fehler nicht an mir lag, sondern an Turbo Pascal. Nach Verlassen der Funktion waren die Werte in den Variablen nun andere und ich experimentierte – mit globalen Variablen. Integer Typ für die Byte-variablen, nichts half. Schließlich hatte ich eine Lösung, wenn auch eine schlechte. Ich entdeckte das HL immer auf die Adresse FE3Ch zeigte und setzte nun die Variablen auf genau diese Speicherstellen. Nun lief es immerhin so weit das die Variablenwerte korrekt waren. Es vergingen nur noch Stunden um aus vier Variablen im BCD Format (wie kommt auf so eine Idee!) einen Realwert zu machen. Ewig lang hielt mich auf das es einen bedeutsamen Unterschied von Turbo Pascal 3 zu heutigem Pascal gab – der Rückgabewert ist früher der Funktionsname, heute die Variable Result. Während man Result aber auch rechts einer Zuweisung als Variable nutzen kann, führt das bei Turbo Pascal 3 zu einer Rekursion, sprich Endlosschleife. Schließlich funktionierte es, wenn auch nur mit 1 Sekunde Zeitauflösung. Die Idee einen der integrierten Timer für die Messung zu verwenden verwarf ich nach Konsultation des Zilog Manuals. Der wird alle 20 Takte dekrementiert, es ist ein 16 Bit Wert. Das heißt nach rund 1,3 Millionen Takten, das sind weniger als 40 ms bei 33 MHz Takt, muss ein Programm ihn auslesen und neu setzen. Das schafft an nicht mit einem Pascal Programm, da müsste ich eine eigene Interrupt Service Routine implementieren. Immerhin, nun konnte ich den HL-Benchmark der Ct laufen lassen und vergleichen:
| Benchmark | CPC 464 | MiniZ-C | Faktor |
|---|---|---|---|
| Integerrechnungen | 7,93 s | 0,6 s | 13,2 |
| Fließkommarechnungen | 67,59 | 5,8 s | 11,65 |
| Transzendente Funktionen | 117 s | 10,1 s | 11,58 |
| Textausgabe | 39,65 | 2,1 s | 18,88 |
| Speichern | 1,34 RAMdisk, 16,48 3 Zoll Disk | 0,2 s (RAM Disk), 0,3 s (SD-Karte) | 6,7 (RAM-Disk) |
Zur Einordnung: Die Integerrechnungen sind schneller als bei einem 8086 mit 8 MHz, die Fließkommarechnungen und Trigonometrie liegen auf dem Niveau eines 8 MHz 80286. Unübertroffen ist die Textausgabe, da keinerlei Arbeit seitens des MiniZ zu erledigen ist. Um alles, auch das vor allem so zeitintensive Scollen kümmert sich der Hostcomputer. Hier erreicht der Rechner das Niveau eines 386 DX mit Super-VGA Karte, das Speichern liegt auf dem Niveau schneller 386 oder 486 mit Festplatte. Der CPC-464, den ich hier als Vergleichsmaßstab nehme, weil ich die Daten von ihm noch habe, war nominell mit 4 MHz getaktet, aufgrund des gleichzeitigen Zugriffs des Videochips auf den Speicher wurden alle Maschinenzyklen aber auf ein Vielfaches von 4 Takten gestreckt, was ohne diese Maßnahme einem Takt von 3,2 MHz entspricht. Der Z180 benötigt etwas weniger Takte als ein Z80 und soll 10 bis 15 Prozent schneller sein, so würde man bei Berechnungen, bei denen sonst nichts vom System beteiligt ist, einen Gewinn um mindestens den Faktor 11,4 erwarten den man auch bei zwei Benchmarks sieht. Dabei nutzt das alte Turbo Pascal 3.02A nicht mal die in der Z180 implementierten CPU Befehle für Multiplikation. Den größten Sprung gibt es beim Speichern, allerdings nur, solange man nicht mit einer RAM-Disk vergleicht, die hatte ich schon beim CPC mit Vortex Speichererweiterung und nun ist es nur noch der Faktor 6,7 das entspricht nicht mal dem Zuwachs an Taktfrequenz (offensichtlich waren die Programmierer bei Vortex besser als der Ersteller des MiniZ-C Systems).
Ich wechsele derzeit viel zwischen Entwicklung auf dem PC und MiniZ. Manchmal frustrierend, weil ich dann die Tastenkombinationen verwechsele – die Wordstar Codes hatte ich schnell wieder drauf, leider reagiert eine moderne Entwicklungsumgebung nicht auf STG-KD … Am Problematischsten war für mich, das das MinZ-System oft beim Transfer von Files hängt. Kommt das einmal vor, dann kann man nur Terminal Programm schließen und die Stromversorgung trennen. Der Resetknopf des MiniZ hilft nicht, der ist nur ein Soft-Reset der nicht mal den Inhalt der Ram Disk löscht, also kein Warmboot. Lediglich CP/M meldet sich erneut mit dem Kommandprompt und A:> – das ist die RAM Disk, also kommt man nicht umher, beim Einschalten die Dateien vom Flash ROM P: zu kopieren. Ich habe das in einer autoexec.sub gemacht.
Es ist ein 2.2 CP/M mit einer 57 K TPA – unter Turbo Pascal sind mit Meldungen noch 26.349 Bytes frei – das ist viel für ein CP/M 2.2. Ich hätte mir ein CP/M 3.0 gewünscht. Nicht wegen der etwas größeren TPA (beim CPC 6128 waren es 28.761 Bytes also nur 2,4 KByte mehr), sondern weil der Bedienkomfort etwas größer ist.
Auf der SD-Karte legt das System eine 8 MB große Partition am Ende an. Ich fand das anfangs etwas klein, waren 8 MB schon in den Achtzigern nicht viel. Meine erste Festplatte fasste 30 MB. CP/M 3 könnte auch größere Partitionen verwalten. Auf der anderen Seite kennt CP/M keine Verzeichnisse. Ordnen kann man die Dateien nur durch das umständliche User Konzept. Es gibt 768 Directory Einträge. Derzeit sind 920 KByte mit 71 Dateien belegt. Also größere Partitionen machen wenig Sinn, aber warum nicht vier dieser 8 MB Partitionen? Das Utility legt leider nur eine an. Doch da ich den Quelltext habe denke ich über eine Anpassung nach.
Etwas komisch ist auch das das System mit 1 MByte RAM, aber nur 512 KByte Flash-ROM auf dem die Systemdateien liegen kommt. Das Laufwerk P: ist übrigens dem CP/M Utility P: unbekannt bis man explizit nach ihm fragt. Gut, das interne Flash ROM ist nicht zum dauernden beschrieben gedacht, aber ewig hält eine SD-Karte auch nicht. Es gibt auch ein anderes Konzept bei dem man die „Festplatte“ als eine normale Datei auf einer FAT32 Partition anlegt. Das hat mehrere Vorteile – man kann sie einfacher sichern und man kann unter Windows mit Utilitys dort Programme unterbringen. Der Transfer über das Terminal mit Xmodem ist sehr langsam, etwa 1-2 KByte pro Sekunde, trotz nominell 115.200 Baud. Es gibt auch eine übertaktete Version mit 36,4 MHz die dann 230 KBaud erreichen soll, doch die Datenrate dürfte sich wie die 115 KBaud auf das Terminal beziehen. Nachteillug ist auch das der Autor sein eigenes System kreiert hat. Es gibt bei Tindie auch andere Retrocomputer, ein zweiter wartet noch auf mich. Die muss man aber alle selbst zusammenlöten, dafür ist das System offen, man kann CP/M 2.2, 3.0 oder ZDOS einsetzen sowie andere Systeme. Das dazugehörige System ROMWBW ist Quelloffen und hat eine breite Unterstützung, wird auch von vielen Retrocomputern eingesetzt. Demgegenüber bekommt man dieses System fertig montiert. Es ist dafür etwas teurer. Vom Hersteller gibt es auch weitere Kits mit eZ80 (bis 50 MHz) und Z180 Prozessoren, die man wenn man will auch selbst zusammenbauen kann.
Das ganze hat natürlich relativ wenig Sinn. Der Computer hat ja prinzipiell keinen Kontakt zur Außenwelt. Es gibt außer dem Micro-SD Slot und USB-Port für Stromversorgung und Terminal keine Ports. Er hat damit noch weniger direkten Nutzen als ein Raspberry Pi. Aber es ist eben was für Leute die noch CP/M kennen. Verglichen mit den damaligen Rechnern ist er enorm schnell. Und man kann ihn nutzen für mehr oder weniger sinnvolle Projekte. So plane ich, da es so was für CP/M nicht gibt einen einfachen Norton Commander Clone zu bauen. Ich habe nach einem gesucht, aber nur einen mit Anpassungen für einen ostdeutschen Rechner gefunden. Es hat natürlich Gründe, warum es so was bisher nicht gibt – der würde wegen der visuellen Markierung der Dateien einen ziemlichen Aufwand für die Anpassung an verschiedene Systeme mit verschiedenen Bildschirmcodes voraussetzen oder man beschränkt es eben für ein System und er läuft woanders nicht.