Der schnellste Z80 Rechner

Bevor ich als Nächstes einen weiteren Artikel über die Clusterung – diesmal dem sinnvollsten Einsatz bei einer Schwerlastrakete bringe, sei mir ein nostalgischer Artikel vergönnt. Es geht um Computer, und was noch wichtiger ist, nicht heutige Computer, sondern die aus den Achtzigern. Dies als Vorwarnung. Alle die das nicht interessieren sollten nun woanders hin gehen.

Ich kam auf das Thema, weil ich seit einer Woche, den schnellsten Z80 Rechner besitze, der heute technisch möglich ist, und wahrscheinlich der auch in Zukunft schnellste Z80 Rechner der Welt.

Es ist ein Min-eZ von Bill McMullen, der es auf Tindie anbietet. Ich habe von ihm schon vor zwei Jahren ein ähnliches System auf Basis eines Z180 gekauft. Bei Tindie gibt es zahlreiche Retro-Computer Kits und auch Add-Ons dafür wie Grafikkarten oder I/O Karten. Als Grobmotoriker mit einer Sehschwäche kenne ich meine Grenzen. So wkam ein Bausatz nicht infrage. Für dieses Kit spricht für mich die kleine Bauform und die „Ready to use“ Philosophie.

Der Rechner ist wirklich winzig und geht auch als über großer USB-Stick durch. Hier mal die reinen technischen Daten:

• eZ80 Prozessor mit 50 MHz
• 256 KB internes Flash-ROM
• 32 KB internes RAM
• 2 MB externes RAM
• 16 MB Flashspeicher
• Ethernet-Port

SD-Karte als Massenspeicher

Das ganze kostet, wenn man Versand und Zoll, MWST dazurechnet, in der Summe 200 Euro. Viel Geld für eine Plattform, die jahrzehntealt ist. Dafür bekommt man zwei Raspberry-Pis mit SD-Karte und Netzteil. Aber ich wollte nach dem Mini-C System einfach diesen Rechner haben.

Das erste waren daher Benchmarks, die ich laufen lies, wobei ich meine eingerosteten Assemblerkenntnisse aufwärmen musste. Alles in Assembler programmieren wollte ich nicht, aber bei CP/M – das ist das Betriebsystem unter dem er läuft, hat Turbo Pascal als meine Lieblingssprache so wenige systemnahe Funktionen, das noch viel in Assembler einbinden muss. Minimal waren einige Zeilen Code für das Holen der Uhrzeit aus der Echtzeituhr nötig. Den integrierten Watchdog Timer habe ich außen vor gelassen, da hätte ich eine eigene Interrupt-Serviceroutine schreiben müssen.

Das sieht dann so aus:

procedure Rawtime;

begin

inline(

{

days extern

clock equ 46h

ld c,0

call clock

ld de,(days)

ld bc,5

ldir

ret

}

);

end;

Meein Asembler sucht nach inline Statements und partst dann alles was darin steht, die anderen Zeilen gibt er einfgach an die Ausgabe wieder. Die Kommentarzeichen sind ein kleiner Kniff damit man dne Quelltext ohne den Assemblercoe kompilieren kann er macht dann dies draus:

procedure Rawtime;

begin

inline(

{days extern}

{clock equ 46h}

$0E/$00/ {ld c,0}

$CD/$46/$00/ {call clock}

$ED/$5B/DAYS/ {ld de,(days)}

$01/$05/$00/ {ld bc,5}

$B0/$ED/ {ldir}

$C9/ {ret}

$C9);

end;

{Symbols}

{CLOCK: $0046, DAYS: $FFFF}

Kenner werden das überflüssige RET erkennen. Das ist ein Workaround, weil Turbo Pascal sonst am letzten Slash in der Zeile vorher moniert, der automatisch erzeugt wird. Es ist doppelt unnötig, denn Turbo Pascal fügt selbst noch ein Ret ein.

Dafür hatte ich schon vor zwei Jahren einen Z80 Assembler in Pascal, den ich im Internet fand so umgeschrieben, dass er Inlinecode für Pascal erzeugt. Da Turbo Pascal 3.02 auch unter DOS verfügbar ist und inzwischen gemeinfrei ist, kann ich so Programme erst unter Lazarus entwickeln, dann unter DOS oder einem CP/M Emulator auf Kompatibilität testen. Was nicht geht, ist natürlich den Assemblercode so zu testen.

Das Mini-eZ System

Das System wird über ein Mini-USB Kabel an den PC angeschlossen. Darüber läuft die Kommunikation. Installieren muss man einen COM-Treiber, der es erlaubt, die USB-Schnittstelle als reine COM-Schnittstelle über welche die Daten mit 115.200 Baud übertragen werden zu nutzen, andere Datenraten funktionieren nicht.

Es bootet dann ein CP/M 2.2 mit der Startmeldung:

eZ80F91 @ 50MHz, PCB V1.2XM, S/N=43

2MB RAM, 256B EEPROM, 16MB Serial_Flash+32KB MRAM

Ethernet: IP address=192.168.40.53, MAC=FC-C2-3D-30-83-C6

A: RAMdisk 1944 KB

B: ROMdisk 224 KB

C: SD_card 8192 KB

O: Ser_FL_1 8192 KB

P: Ser_FL_0 8192 KB

CP/M 2.2 63K (56K [+2K CCP] TPA) – BIOS V0.3 THU MAR 14/2024 7:57:50

A>

Damit ist man schon im Retrozeitalter. Es laufen alle CP/M Programme. Der Autor hat CP/M 2.2 adaptiert, nicht CP/M 3.0 das Banking unterstützt und noch ein paar Kilobyte in der TPA mehr freischaufelt, aber 56 K für die TPA sind okay, Das Min-C System hatte noch 1 KB mehr, aber das ist mehr als die meisten CP/M Rechner hatten, die hatten typisch nur eine 52 oder 54 K TPA. Die 256 KB Flash ROM des EZ80 werden als RAM Disk benutzt, der Benutzer hat dann noch die Wahl, ob er weiteres SRAM oder MRAM haben will. Bei mir waren 16 MB Flash mit aufgelötet, obwohl das eigentlich eine Upgrademöglichkeit ist, die 16 MB Flash und die SD-Karte werden als 8 MB große Festplatten angesprochen. Mehr geht unter CP/M 2.2 nicht. Für junge Blogleser: CP/M 2.2 erschien 1979, da waren die bezahlbaren Festplatten nicht größer. Bei CP/M 2.2 ohne Banking ist zudem ein Hindernis, dass die FCB eines Massenspeichers im RAM gehalten werden. Kein Problem bei einer Diskette, die 128 oder 256 FCB hat, doch hier sind es 768 pro Partition und in meinem Falle drei Partitionen. Das alles geht vom wertvollen Hauptspeicher ab.

Nun zum eZ80. Der ist der letzte und wahrscheinlich auch endgültige Z80, denn er erschien schon 2001. Wie sein Pendant 6502 wurde der Z80 ständig weiter entwickelt. Es erschien von Hitachi der HD64180 als Nachfolger in den Achtzigern, der zahlreiche Peripheriebausteine integriere und eine integrierte MMU hatte. Er wurde sogar von Zilog übernommen als Z180. Mein zweites System von McMullen setzt einen 33 MHz Z180 ein. Der eZ80 kann linear 16 MB adressieren, hat einen integrierten Ethernetport (der bei einem CP/M aber nutzlos ist, weil man natürlich nicht den Speicher hat um die ganzen oberen Schichten mit den Protokollen zu implementieren). Für die Geschwindigkeit wichtig ist, dass es nicht nur mit 50 MHz läuft, sondern durch eine Pipeline auch dreimal schneller als ein gleichzeitig getakteter Z80 sein sollte.

Der Vergleich für mich ist mein CPC, der einen mit 4 MHz getakteten Z80 hatte. Real lief er aber mit 3,2 MHz, da damit es keine Konflikte mit dem ASIC gab welches unter anderem auch die Videosignale erzeugte und gleichzeitig auf den Speicher zum Auslesen der Daten für den Videoausgang zugriff, alle Befehle auf ein Vielfaches von 4 Takten gestreckt wurden. So konnte das ASIC immer in der zweiten Hälfte des Taktzyklus einer Z80 wenn diese nicht auf den Speicher zugreift, die Daten auslesen.

Ich habe zwei Benchmarks laufen lassen. Ein Hochsprachenbenchmark der Zeitschrift ct’ von 1987 von dem ich auch Tests bis in die Neunziger Jahre habe und der Sieve Benchmark von Byte aus dem Jahre 1981. (Originaldokument, Warnung 25 MB groß). Bei diesem war das schnellste System – der Benchmark erschien in mehreren Programmiersprachen und diente auch dazu Compiler zu überprüfen (schon damals lief das schnellste Programm in 14 Sekunden und das langsamste brauchte 5115 Sekunden für den Benchmark – der schnellste Compiler war ein PL/I Compiler von Digital Research, der langsamste Microsoft Cobol). Hier wurde das Programm in 0,46 Sekunden abgearbeitet, 30-mal schneller als das schnellste System, das war ebenfalls ein 4 MHz Z80. Gespannter war ich auf das Benchmark der ct’

Hier das Ergebnis eingeordnet in eine Liste anderer Systeme:

Typ Integer Realzahl Trilog Text Grafik Speichern Index

—————————————————————————–

CPC 464 7.9300 67.590 117.000 39.65 2.380 40.41

IBM XT 1.2300 39.110 56.390 64.20 4.780 24.09

PC 8088 8 Mhz 0.8300 27.300 39.440 45.97 4.780 18.33

PC 8086 8 Mhz 0.7100 15.820 22.190 29.71 4.780 13.24

MiniZ-C 0,690 5.800 10.100 2.10 0.20

IBM AT 6 Mhz 0.2200 10.220 10.890 32.84 1.060 7.12

Min-eZ 0.1200 1.300 2.200 2.10 0.20

AT 80286 10 Mhz 0.1100 6.070 9.070 13.62 1.260 4.50

80386 SX 16 Mhz 0.1000 5.050 7.240 14.00 0.900 3.84

80386 SXL 16 Mhz 0.0750 2.580 2.604 9.28 2.160 3.80

80386 DX 33 Mhz 0.0270 1.414 2.300 9.50 0.800 2.18

80386 DX 40 Mhz 0.0346 1.260 1.329 4.01 0.302 1.06

80486 SX 33 Mhz 0.0170 0.550 0.604 3.13 0.313 0.78

80486 DX 33 Mhz 0.0176 0.390 0.609 3.08 0.126 0.56

80486 DX 50 Mhz 0.0116 0.368 0.409 1.93 0.165 0.46

80486 DX 50 Mhz VLB 0.0126 0.368 0.401 1.21 0.241 0.47

AMD486 DX/4 100 0.0060 0.182 0.208 2.14 0.055 0.32

AMD486 p-75 150 VLB 0.0039 0.126 0.143 2.13 0.176 0.42

AMD486 p-75 133 PCI 0.0044 0.138 0.153 1.43 0.067 0.25

Dell Pentium 75 0.0083 0.121 0.130 1.71 0.131 0.34

Dell Pentium 90 0.0061 0.099 0.126 1.48 0.028 0.21

Vobis Pentium 90 0.0093 0.148 0.187 1.76 0.038 0.26

Thinkpad 365(P100) 0.0057 0.090 0.108 5.14 0.035 0.56

Artist P-133 0.0041 0.066 0.083 1.26 0.017 0.16

Media Markt P150 0.0038 0.060 0.071 1.49 0.017 0.18

Lion K6-2-350 0.0009 0.033 0.036 1.43 0.093 0.24

Athlon 750 Mhz 0.0004 0.013 0.001 1.49 0.093 0.24

Ich habe auch das MinZ-C System (33 MHz Z180) eingeordnet, wobei ich mich an den Integer-Benchmarks orientiert habe. Ich habe dann noch einige Ergebnisse markiert, bei Computern, die nahe am Min-eZ liegen und die teilweise viel schneller sind.

Also ich erkläre mal. Der erste Benchmark umfasst 10.000 Ganzzahlberechnungen (16 Bit) mit Addition, Subtraktion, Division und Multiplikation. Hier ist die 8 Bit CPU gegenüber allen anderen Systemen die mindestens 16 Bit verarbeiten aus zwei Gründen benachteiligt: Sie hat zwar Befehle für 16 Bit Addition und Subtraktion, aber die brauchen erheblich länger als 8 Bit Rechnungen weil sowohl das Laden wie Berechnen immer in 8 Bit Portionen erfolgt. Noch gravierender ist, dass alle anderen CPUs Multiplikationen und Divisionen in der Hardware ausführen können. Hier sortiert sich das Min-eZ System in der Region eines 8 MHz 80826 ein.

Der Vorsprung wird größer bei den Fließkommazahlen Benchmarks, einmal wieder einfache Rechnungen und einem Transzendente Funktionen (Sinus, Loarithmus) denn diese berechnen auch 16 Bit CPUs (damals noch ohne Coprozessor) nicht in der Hardware und da wird weniger multipliziert und dividiert als vielmehr Bits geschoben, addiert und subtrahiert. Da sah auch schon der CPC 464 besser aus. Hier erreicht das System schon die Performance eine 80386 DX mit 33 bis 40 MHz, was fast der CPU Taktfrequenz der eZ80 entspricht. CP/M kennt keine Grafik und ich kommuniziere mit dem Rechner über ein Terminal, deswegen fällt der Grafikbenchmark weg.

Bei den beiden letzten Benchmarks für Textausgabe und Speichern eines Textes auf Disk sind sowohl das Min-EZ wie MinZ-C System gleich schnell, das verwundert nicht, denn hier ist nicht der Prozessor das Limit. Zuerst: warum ist die Textausgabe so schnell, auf dem Niveau eines 486-ers mit 50 bis 150 MHz?

Die frühen Pc hatten keine Grafikkarten mit einem Prozesssor, die die Ausgabe und das Rendern übernehmen, was wie man an der Tabelle sieht, dann auch je nach Fähigkeiten der Karte zu starken Unterscheiden führt, als diese einzogen. Alles geht ohne eine Grafik-GPU gut, solange bis der Text die unterste Zeile erreicht, dann muss gescrollt werden. Das heißt, der ganze Inhalt des Text/Grafikspeichers muss umgewälzt werden. Hier sind sogar Systeme, die nur reinen Text ausgeben im Vorteil, denn ihr Speicher ist typisch nur 4 KB groß. Beim CPC und IBM PC war er dagegen 16 KB groß. Und um 16 KB zu kopieren (für eine Zeile) braucht eine Z80 CPU mit 4 MHz mindestens 0,112 Sekunden. Man konnte den damaligen Systemen beim Scrollen zusehen, damals glaubte ich noch, als ich unter BASIC programmierte das wäre ein Feature, weil man so den Text mitlesen und abbrechen konnte, wenn die Stelle angezeigt wurde, die man editieren wollte.

Dagegen kommunizieren die Min-Rechner mit einem Terminal, das ist für die Textausgabe verantwortlich und da ist dann die Geschwindigkeit der Schnittstelle (115,2 kbaud), die bei beiden Systemen gleich hoch ist, das Limit. Der eZ80 könnte auch 230 kbit senden, aber dann steigt nach McMullen das Fehlerrisiko, weshalb er es beschränkt hat.

Die gleiche Tatsache ,das nicht der Prozessor für die Geschwindigkeit verantwortlich ist hat man beim Speichern Benchmark. Hier musste eine Textdatei auf Diskette, später Festplatte geschrieben werden, da werden Schreib-Leseköpfe bewegt, die Geschwindigkeit einer Diskette oder Festplatte ist auch konstant und zumindest bei den neueren Rechnern viel langsamer als der Prozessor die Daten liefern könnte. Beim Min-eZ wird dagegen auf Flash-ROM gespeichert. Kleines Detail am Rande: der CPC den ich damals hatte, hatte auch eine RAM-Disk, weil er auf 576 KByte aufgerüstet war, dorthin schrieb er in 1,34 Sekunden was dann den beiden System schon sehr nahe kam.

Okay, ich habe nun den schnellsten Z80-Rechner der Welt, wie gehts weiter? Ich habe ein neues Softwareprojekt, den „Bernd Commander“, der Name lehnt sich an den Norton Commander an, den wohl jeder kennt, der mal unter DOS gearbeitet hat, ohne ihn wird es mühsam, wenn man kopieren, umbenennen oder löschen muss. Unter CP/M gab es so was nie, was daran liegt, dass man dafür eine Cursorsteuerung braucht und die war bei jedem CP/M Rechner anders. Doch das ist ein neues Thema, dass ich nächstes Mal anspreche. Der Knackpunkt wird sein, dass ich 14 Bytes für jeden Verzeichniseintrag brauche, den ich verarbeite und bei zwei Laufwerken mit maximal je 768 Einträgen bin ich schon bei 21.504 Bytes oder 21 Kbytes, rund 40 % des Hauptspeichers denn ich noch habe, die RTL von Pascal abgezogen, bleiben nur noch 27 KByte für das ganze Programm.