Home

Computer

PC Hardware

Site Map

Der "ideale Z80 Heimcomputer"

Nachdem ihr im Blog schon etliche Aufsätze über hypothetische Raketen gelesen habt, möchte ich nun mal einen Artikel über einen hypothetischen Computer schreiben. 1984 neigte sich die Blütezeit der 8 Bit Rechner schon dem Ende zu. Die ersten 16 Bit Rechner rückten in bezahlbare Regionen vor. Der Sinclair QL erschien, ein Jahr später Atari ST und Amiga. Aber in dem Jahr erschienen auch neue 8 Bit Prozessoren wie der Toshiba HD64180 und die Speicherpreise fielen, sodass man mit einem 8-Bit-System gut arbeiten konnte und trotzdem mit den ersten 16 Bittern mithalten konnte.

Ich möchte heute einen Computer beschrieben, den ich entworfen hätte, wenn ich es denn könnte. Er lehnt sich eng an dem Amstrad CPC 6128 an, der schon dem Ideal sehr nahe kommt, aber wegen der Komparabilität zu den vorherigen Modellen (CPC 464/664) nicht ganz. Es soll ein Rechner zum Arbeiten sein (CP/M Plus, 80 Zeichendarstellung, Floppies) wie auch für Spiele. Den damals üblichen BASIC-Interpreter habe ich weggelassen, denn wer wirklich ernsthaft programmieren will, wechselte bald von BASIC auf C oder Pascal und die 16 Bitter hatten auch kein BASIC in der Basisausstattung mehr. Ursprünglich wollte ich den CPC nur als Basis nehmen und plante einen viel leistungsfähigeren Rechner. Doch die Basistechnologien wie man sie Bankswitching, gleichzeitigen Grafik- und speicherzugriff braucht sind ja gegeben und ich habe sie mir am Beispiel des CPC vertieft, wobei auch ein Artikel über den Computer entstand. Sehr bald erkannte ich das man so viel mehr gar nicht machen kann, wenn der Rechner finanzierbar sein soll und nicht so teuer wie ein billiger 16 Bitter wie der Atari ST werden soll. So wurde schließlich daraus ein Artikel über einen optimierten CPC-Rechner.

CPU und Taktfrequenz

Ich habe die Z80 gewählt, aus naheliegenden Gründen. Zum einen kenne ich mich mit ihr am besten aus. Zum anderen ist sie etwas schneller als ein 6502 - wenn man reale Implementierungen nimmt, bei gleicher Taktfrequenz natürlich nicht, aber die Z80 ist auch mit höherem Takt verfügbar. Als Alternative habe ich noch die HD64180 vorgesehen, dazu später mehr.

Die Taktfrequenz kann man nicht beliebig hochschrauben. Es gibt Nebenbedingungen. Zum einen muss das RAM einen Zyklus durchführen können in der minimalen Zeit, die eine Z80 für einen Maschinenzyklus benötigt. Ebenso muss die Zugriffszeit für einen Fetch und die Zugriffszeit des RAM passen. Die Zeit für einen Fetch beträgt bei einer Z80 bei Opcodes 1,5 Takte, bei Daten 2,5 Takte. Die 1,5 Takte sind das kleinere Maß. Zu dieser Zugriffszeit muss man noch die Zeit für den Flankenabfall und die Haltezeit für das Mreq Signal subtrahieren, die so aussehen:

Hier die Daten gängiger RAMs aus dieser Zeit:

Damit sollte es möglich sein, bei 120 ns RAMs eine HD 64180 CPU mit 8 MHz beitreiben zu können. Bei einem Z80 müsste man die Taktfrequenz leicht absenken auf 7,8 MHz.

Das Zweite sind die Peripheriebausteine. Deren Timing ist unkritischer, auch weil die meisten von ihnen sowieso mit niedrigerem Takt arbeiten, man kann ihren Takt durch Teilung des Mastertaktes erzeugen.

Z80 DMA

Der sinnvollste Peripheriebaustein ist wohl die Z80 DMA. DMA steht für Direct Memory Asccess. Bei der Z80 muss jedes Byte, das transferiert wird, die CPU passieren, egal ob diese die Daten verarbeitet oder nicht. Das entspricht bei einer Z80 z.B. folgender Befehlssequenz:

ld a,(hl)

ld (de),hl

Ohne das man die Register DE und HL inkrementiert, damit man das nächste Byte lesen kann, (meist wird man noch ein weiteres Register als Zählregister nutzen) benötigt man dafür schon 14 Takte. Mithin wird man bei 4 MHz niemals mehr als 286.000 Bytes/s transferieren können. Mit den speziellen Blockkopierbefehlen LDIR und LDDR sind es 195.000 Bytes/s, wobei dann aber auch das Inkrementieren der Quell- und Zielregister und des Zählregisters mit dabei ist.

Das ist schnell, aber in vielen Situationen nicht ausreichend. Wie noch zu erläutern, reicht die Zeit die vergeht, wenn eine Diskette rotiert und man die Lücke zwischen zwei Sektoren passiert, nicht aus auch nur bei 250 kbit/s, einen Sektor zu kopieren. Als Folge muss man ihn überspringen und so die Datenrate des Diskettenlaufwerks halbieren. Bei Laufwerken mit zwei Schreib-/Leseköpfen (500.000 bit/s) gilt das auch für die höchste mögliche Z80 Taktfrequenz

Eine zweite Einsatzmöglichkeit einer DMA liegt im Scrolling. Ich habe einen reinen Grafikmodusbetrieb vorgesehen, wie dies beim CPC auch der Fall war. Muss nun gescrollt werden, d.h. fällt eine Textzeile oben weg und kommt unten eine neue hinzu, so muss praktisch der gesamte Bildschirminhalt kopiert werden. Bei den vorgesehenen 32 KByte Bildschirmspeicher bedeutet das, dass selbst mit LDIR man so maximal 6 Zeilen pro Sekunde scrollen kann.

Als Drittes gäbe es noch bei Programmen sehr oft den Fall, das Kopieraktionen aber auch Suchaktionen im Speicher nötig sind. Kopieraktionen benötigt man, wenn man eine Variablenzuweisung macht und es um Felder geht. Bei BASIC aber auch bei der Garbage Collection. Suchaktionen sind typisch für Textverarbeitungsprogramme, wo ein Wort oder Test in einem Dokument gesucht wird.

Eine Z80 DMA ist spezialisiert solche Aktionen schnell durchzuführen, da sie die CPU praktisch umgeht. Sie hat mehrere Betriebsarten, in denen sie zum einen selbstständig einen Transfer durchführen kann, aber auch ein Byte an die CPU übergeben kann und dann stoppt oder nur ein Byte transferiert und dann auf Anweisung der CPU wartet. Das benötigt man für Suchaktionen. Dabei ist sie sehr viel schneller als die CPU. Eine Z80A DMA mit 4 MHz erreicht folgedne Datenraten:

• Blocktransfer: 1 MByte/s (CPU: 0.195 MByte/s)

• Bytetransfer in die CPU: 2 MByte/s (CPU: 0,57 MByte/s)

Sie ist also um den Faktor 3 bis 5 schneller als die CPU. Aufgrund des vergrößerten Bildschirmspeichers, der die Scrollrate bei gleichem Takt halbieren würde und dem Einsatz von DS/DD Laufwerken habe ich eine DMA vorgesehen, aber nur eine Z80A DMA um Kosten zu sparen. Würde man auf sie verzichten so würde man die Geschwindigkeit eines Laufwerks mit mehr als 500 Kbyte Kapazität nicht ausnutzen und das Scrollen wäre sehr langsam.

Problem Videospeicher

Für einen gemeinsamen Zugriff des Gate Arrays auf den Videospeicher ist auch die Zykluszeit des RAM von Belang. Beim CPC war dies so, das das Gate Array immer im letzten Takt eines Maschinenzyklus auf das RAM zugriff. In einer Mikrosekunde, das waren 4 Takte, griff sie zweimal auf den Speicher zu. Das bedeutete, dass ein Zyklus des RAM nach 2 Takten beendet sein musste. Bei dynamischen RAM ist die Zykluszeit dann der begrenzende Faktor.

Es gibt mehrere Lösungsmöglichkeiten für diese Problematik. Eine ist es, das Video-RAM separat zu haben. Das bedeutet primär hat der Videocontroller und die Logik zur Ausgabe des Signals Zugriff, auf das Video-RAM haben. Der Videokontroller generiert nur die aktuelle Adresse des RAM, das gerade ausgelesen werden muss, das Auslesen selbst und die Interpretation des Inhalts macht eine angeschlossene Schaltung, die in einem ULA steckt. Die CPU blendet das VideoRAM lediglich ein, wenn sie in diesen Speicherbereich schreiben muss. Dann und nur dann muss der Zugriff abgesprochen werden, sonst nicht. Idealerweise macht man das Schreiben in den Videospeicher synchronisiert, wenn gerade keine Ausgabe erfolgt. Es gibt unsichtbare Zeilen nach dem Vsnyc Signal und unsichtbare Spalten nach dem Hsync Signal. Dann kann man das Gate Array anhalten und die CPU kann ungebremst auf das RAM zugreifen. Diese Ausgabe in den Austastlücken ist auch so gang und gäbe, da es sonst Bildstörungen gibt. Bei der CGA-Karte des IBM PC war dies möglich und man sprach von "Schnee", der so entsteht. Selbst wenn man dieses Feature nicht nutzt und Wartetakte einführt, so sind diese nur nötig wenn es einen Bildschirmzugriff gibt, aber nicht wenn auf den restlichen Speicher zugegriffen wird.

Die Zweite Möglichkeit ist es das die CPU in ihren Taktzyklus Wartetakte einführt. Bei der Z80 dauert ein Taktzyklus immer 4 Takte, nur beim Ende einer Instruktion können die letzten Takte entfallen, wenn sie vorher beendet ist. Speicherzugriffe finden immer während des ersten Teils eines solchen Zyklus statt. Bei meinem Rechner war das daher so gelöst, dass der 6845 immer im zweiten Teil des Zyklus auf den Speicher zugriff. Da der 6845 mit 1 MHz getaktet war, bedeutete das, das alle Zyklen von Z80 Befehlen ein vielfaches von 4 Takten haben mussten. Das war bei vielen einfachen Befehlen sowieso der Fall. Bei anderen, wie Sprüngen oder 16 Bit Transfers kamen dann Wartetakte hinzu. Im Instruktionsmix benötigt ein Z80 normalerweise 6,8 Takte für einen Befehl, das vergrößerte sich durch die Wartetakte so, sodass in Benchmarks der Rechner mit 3,2 anstatt 4 MHz arbeitete, also im Mittel 8 Takte benötigte. Dies kann man beibehalten (entsprechend einem 25 % Geschwindigkeitsverlust und zwar in jedem Falle, auch ohne Bildschirmausgabe).

Eine 6 MHz Z80B ist dann nur 4,8, eine Z80H nur 6 MHz schnell vergleichen mit einer Architektur ohne Bildschirmzugriff.

Die dritte Möglichkeit ist Dual Ported RAM, das ab 1983 verfügbar ist. Es hat zwei Ports, einen für die CPU für den wahlfreien Zugriff und einen Zweiten für die Videoausgabe, in der 256 Bytes sehr schnell abgerufen werden können - die Bytes einer Zeile liegen ja direkt hintereinander im Speicherchip. Das reduziert nach Herstellerangaben die den Zeitverlust durch Wartetakte von 25 % auf 2 %. Da dieses RAM mehr kostet, wird man es aber nur beim Videospeicher einsetzen, der dann wie bei statischem RAM separat ist. Alternativ nimmt man für den Videospeicher statische RAM, die haben keinen Speicherzyklus, können also nach der Zugriffszeit sofort wieder Daten liefern und SRAM haben eine niedrige Zugriffszeit. Das 6264 in der Tabelle z.B. eine Zykluszeit von 100 bis 150 ns. Da das 6264 RAM 8-Bit weise organisiert ist, kann man den Bildschirmspeicher in Vielfachen von 8 KB auslegen.

Z80 oder HD64180

Eine Alternative zur Z80, die Zilog schließlich sogar unter der Bezeichnung Z180 ins Sortiment aufnahm, ist der Hitachi Prozessor HD64180. Er bietet folgende Plus-Möglichkeiten:

• Integrierte DMA, 2 Kanäle

• Integrierte SIO, 2 Kanäle asynchron und Synchron

• Integrierte Timer, (2)

• Integrierter DRAM Kontroller mit Refresh und Waitstategenerierung

• Interruptcontroller für 12 Quellen

• Memory Management Unit

Das heißt der Baustein integriert nicht nur mehrere Peripheriebausteine (SIO, CTC, DART, DMA) sondern er bietet auch eine bequeme Erweiterung des Arbeitsspeichers durch eine MMU an. Kleine Goodies sind, dass die Befehle generell weniger Taktzyklen benötigen und es einige zusätzliche Befehle gibt wie für Multiplikation oder das Durchsuchen des Speichers nach einem Byte (Stringverarbeitung!). Ein HD64180 mit 8 MHz war in etwa so schnell wie eine Z80 mit 10 Mhz. Durch die dynamische Einfügung von Wartetakten durch den DRAM Kontroller muss man auch nicht mit dem obigen Performanceverlust durch Strecken der Instruktionszyklen leben. Ich habe im Folgenden aber trotzdem in der Konzeption mit der Z80 gearbeitet. Für den HD64180 gäbe es weitergehende Möglichkeiten, die ich aber nicht nutze. Die DMA wäe nützlich, kostet als eigener Baustein aber weitaus weniger, als eine HD64180 mehr kostet. Die SIO benötigt man für serielle Schnittstellen, die zumindest in Deutschland mit teuren, nur von der Bundespost zugelassenen Modems, aber wenig Sinn machten. Für einen Bürocomputer, der keine zeitkritische Messwerte abfragt, benötigt man keine Interruptcontroller. Die MMU würde ein flexibleres Bankswitching, nicht nur in 16 KByte Schritten, mit festen unteren und oberen Bereichen erlauben. Sie wäre der Hauptvorteil, neben der höheren Geschwindigkeit. Ich habe mich gegen den HD64180 entschieden, da in dem Projekt seine Vorteile kaum genutzt werden, er aber deutlich den Rechner verteuert: Anfang 1986 kostete ein HD 64180 im Einzelhandel 119 DM, eine Z80B CPU aber nur 7,10 DM. Die Z80H liegt 27,90 € dazwischen.

Massenspeicher

Ich habe als Standard Diskettenlaufwerke vorgesehen und damit auch als Standardbetriebssystem CP/M. Festplatten wurden erst Jahre später bezahlbar. Sie kosteten 1985/86 ein Vielfaches eines kompletten Z80 Rechners. Zudem war CP/M nicht geeignet für größere Datenträger. Es hatte keine Möglichkeit Unterverzeichnisse zu definieren, lediglich über die USER Funktion konnte man 16 Unterbereiche ansprechen. Daneben war durch die Verwaltung die Größe von Partitionen bei CP/M 3.0 bei 512 Byte Sektoren auf 32 MByte beschränkt.

Doch schon Floppylaufwerke haben Datenraten die eine 8 Bit CPU durchaus in Probleme bringen können. Man muss hier zwei Fälle unterscheiden:

• Die CPU muss ein Byte vom Floppy-Controller lesen, bevor dieser das nächste Byte transferieren will.

• Die CPU muss, wenn ein Sektor gelesen wurde, diesen aus einem temporären Puffer kopieren.

Eine Routine um ein Byte von vom Floppykontroller zu lesen wäre z.B. folgende:

lenbuffer equ 0

lenbuffer2 equ 2 ; 2 x 256 Byte = 512 Bytes/sektor

startadresse equ 1000H

FDCBytePort equ DF06H

FDCStatusport equ DF07H

Init: LD B,Lenbuffer

LD D,lenbuffer2

LD C,FDCBytePort

LD HL,startadresse

Loop1: in a,(fdcstatusport)

or a ; Flags setzen

jp nz,Loop1

INI ; Byte an HL lesen, HL erhöhen, B deckrementieren

JP nz,Loop1

DEC D

JP NZ,Loop1

ret ; 512 Byte gelesen

Diese Routine benötigt pro Byte 65 Takte, bei auf 4 Takte gestreckten Befehlen 72 Takte. Daraus kann man die maximale Anzahl an Bytes berechnen, es sind 15,3 KByte/MHz. Schaut man sich nun die Standarddatenraten von Diskettenlaufwerken an, so erhält man folgende Tabelle:

Der CPC hatte ein SS/DD Laufwerk und konnte dessen Datenrate auch transferieren. Fremdfloppies anderer Hersteller, die auch als DS/DD verfügbar waren konnten, die Datenrate nicht voll ausnutzen und lasen die Spuren nicht parallel ein, sondern abwechselnd obere und untere Seite. Eine Erhöhung des Takts auf mindestens 5 MHz erlaubt einen DS/DD Betrieb.

Das zweite ist dann das Kopieren des Sektors aus einem temporären Puffer dorthin, wo das Anwendungsprogramm ihn haben will.

Bei 9 Sektoren pro Spur mit 512 Bytes pro Sektor man für einen 512-Byte-Transfer etwa 2,65 ms Zeit. Beim CPC gab es einen GAP des CPC von 83 Bytes zwischen den Sektoren. Im günstigsten Fall kopiert die CPU mit dem Befehl LDIR bei 4 MHz und Strecken des Maschinenzyklus auf 4 (effektiv 3,2 MHz) während das 83 Bytes unter dem Schreib-/Lesekopf vorbeirauschen 442 Bytes. Also weniger als ein Sektor Daten umfasst. Bei dem CPC 6128 reichte das nicht aus. Es musste ein Skew (auch Interleave genannt) eingebaut werden, der die Datenrate halbierte. (Bei einem Skew folgt auf den ersten Sektor nicht der Zweite, sondern ein anderer und erst der übernächste Sektor ist dann der zweite benötigte). Dabei hatte der CPC nur ein einseitiges Laufwerk, bei zwei Leseköpfen verdoppelt sich die Datenrate. Daher fiel auch die Wahl auf die 8-MHz-Z80 Variante. Sie sollte die doppelte Datenrate auch beim Lesen vom Floppy Kontroller schaffen. Leider aber nicht beim Kopieren von Sektoren. So muss man bei doppelseitigen Laufwerken einen Interleave von 2 definieren, benötigt also zwei Umdrehungen um eine Spur zu lesen. Immerhin verdoppelt sich die Datenrate gegenüber der 4-MHz-Version. Daher setzte ich eine Z80 DMA an, die man wegen der rund 5-fachen Geschwindigkeit bei Speichertransfers auch mit 4 MHz takten kann. Sie kostete im Einzelhandel im Januar 1986 14,20 €, Verzichtet man auf die DMA, so bietet es sich an bei DS/DD Laufwerken die Sektorzahl von neun auf acht zu reduzieren. Das vergrößert den Gap zwischen zwei Sektoren von 83 auf 168 Bytes und damit hat man auch bei niedrigem Takt genügend Zeit für einen Transfer. Der Nachteil ist, dass die formatierte Kapazität so von 720 auf 640 KByte sinkt.

Hier eine Übersicht wie hoch die CPU getaktet werden muss, damit sie die Spuren ohne Skew transferieren kann:

1985 hatten sich die Double Sided / Double Density Laufwerke schon breit durchgesetzt und waren nur wenig teurer als Single Sided und/oder Single Density. Der HD Standard für 5,25 Laufwerke wurde von IBM 1984 eingebaut und orientierte sich am Standard für 8 Zoll Laufwerke. Beide Disklaufwerke waren aber für einen Heimcomputer zu teuer.

Ich setze auf den 3,5 Zoll Standard, auch wenn anfangs noch etwas teurer als 5,25 Zoll Laufwerke. Aber die Disketten sind handlicher, robuster und kleiner. So kann man zwei Laufwerke neben dem Monitor in einem gemeinsamen Gehäuse unterbringen, wie es beim Joyce der Fall war. Ein Riesenfehler von Amstrad war, dass er damals auf den 3 Zoll Standard gesetzt hat, angeblich weil der Hersteller der Laufwerke diese billig anbot. Das war eine Insellösung und die Disketten sehr teuer.

Der Diskettenkontroller ist gleich integriert (das war beim CPC 6128 auch so), in einem Monitorgehäuse sind problemlos zwei Laufwerke hochkant einbaubar. Ich sehe in der Basiskonfiguration ein Laufwerk vor, der Schacht hat aber die Stromversorgung und den Anschluss für ein zweites Laufwerk. Das senkt zum einen die Kosten, zum anderen kann der Anwender so entscheiden, ob er ein zweites Laufwerk will oder braucht und welches das ist (bei genügend großem Schacht auch ein 5,25-Zoll-Laufwerk als Zweites). Der Einbau ist wegen der genormten Steckern relativ unproblematisch und auch von Laien durchführbar. Auf ein zweites Laufwerk kann man verzichten wenn man die RAM / ROM-Ausbauvariante wählt.

Systemarchitektur

Ich habe mir zuerst eine Erweiterung der Architektur des CPC 6128 vorgenommen, der schon relativ viele der gewünschten Features hat. Er bot unter anderem ein CP/M 3.0 mit 61 K TPA, war aber auch für das Spielen geeignet. Es gab nur ein Problem: ich wollte einen größeren Bildschirmspeicher. Der CPC hatte maximal 640 x 200 Punkte bei 80 x 25 Zeilen. Dieses extreme Seitenverhältnis hat er gut kaschiert (bei einem ⁴/₃ Seitenverhältnis, wie sie der Monitor hatte, hätten es für eine seitenrichtige Darstellung 640 x 480 Pixel sein müssen) indem die Grafikoperationen mit 400 Zeilen arbeiteten. Zudem waren die Ränder groß. Bei einer Druckausgabe merkte man es aber, außer man verdoppelte auch hier die Zeilen. Mehr Speicher bedeutet aber auch bei Spielen, eine höhere Auflösung oder bei reduzierter Auflösung mehr Farben.

Der im CPC eingesetzte 6845 wurde auch woanders eingesetzt. Er hat in der Hercules Karte eine Auflösung von 720 x 350 Punkten geboten. Das wären dann bei 8 x14 Matrix 90 x 25 Zeichen für die Textdarstellung ideal. Für Spiele fällt die starke Abweichung vom Monitorformat von 4/3 auf. Für Spiele ideal wäre die 640 x 480 Pixel, die Auflösung die die VGA-Karte hat. Nur belegt dann der Bildschirmspeicher 37,5 KByte. Das ergibt bei einem 8 Bitter ein Problem, denn so müssen bei den standardmäßig 16 KByte großen Banks drei Bänke gewechselt werden, das lässt, wenn man unten noch ein 16 KByte großes ROM hat, keinen Platz für notwendige Verwaltungsinformationen: man braucht Puffer für den Datenaustausch, man benötigt Sprungvektoren ins Betriebssystem und Routinen fürs Bankswicthing die immer errichtbar sein müssen. Diese belegten beim CPC auch einige Kilobyte Speicher. Mit nur 8 KByte großen Bänken wäre dieser Bildschirmspeicher nutzbar. Das steigert aber den Verwaltungsaufwand deutlich, da die Zahl der Kombinationen beim Banksitching steigt. Man wird aber die aktuelle Konfiguration in einem Register haben wollen. Daher blieb ich bei 16 KByte großen Banks und damit war der Bildschirmspeicher maximal 32 KByte groß. Ich entschied mich für 640 x 400 in monochrom als höchste Auflösung, immerhin eine Verdopplung zum CPC.

Hier folgte eine Tabelle der Babyausstattung mit 128 KByte Speicher, die man noch erweitern kann. Die Nummer entspricht jeweils der RAM-Bank. Es gibt 6 RAM Bänke und zwei Bänke für den Bildschirmspeicher.

Damit das Bankswitching funktioniert, muss ein Bereich immer aktiv sein. Das ist in diesem Fall Bank 1 in den obersten 16 KByte. In ihren obersten 3 KByte stecken Sprungvektoren für CP/M, BIOS, BDOS und Betriebssystem, dazu Puffer für den Datenaustausch zwischen den Bänken. Die restlichen 13 KByte sind frei und können in Konfiguration 1 von Anwendungen genutzt werden.

Beim Start ist Konfiguration 2 aktiv. Bei jedem Z80 Rechner beginnt die Ausführung bei Adresse 0 so wird das Betriebssystem gestartet. Es bootet CP/M 3.0 von Disk und übergibt die Kontrolle an CP/M. Es wechselt auf Konfiguration 1.

Sie stellt das RAM (bis auf die Umschaltroutinen in den oberen 16 K) zur Verfügung. Eine 61 K TPA ist so möglich. Der CCP befindet sich dann in Bank 6. Das ist die Konfiguration bei CP/M, wenn das Kommandoprompt aktiv ist. Für Grafikausgaben wird auf Konfiguration 2 gewechselt. Für Diskettenzugriffe wird das OS/ROM durch ein DiskROM ersetzt.

Die elementaren Routinen des Betriebssystems stecken im OS-ROM. Für die Textausgabe benötigt man ein TextFont-ROM, das einen Font in 4 Schnitten zur Verfügung stellt. Dieses ROM wird nur genutzt, um an eine Stelle am Bildschirm die Zeichenmatrix auszugeben. Die dafür nötige Routine belegt nur wenige Bytes und kann in den permanent verfügbaren 3 KByte in RAM-Bank 1 untergebracht werden. Daher kann man für diese Spezialaufgabe das OS-ROM ausblenden.

In der Architektur ist dies daher ein CP/M Rechner, keiner, der mit einem BASIC Interpreter startet. Wer programmieren will, lädt dann eine Programmiersprache von Diskette. In der Summe hat man dann genauso viel Speicher wie bei meinem CPC (61 KByte für Interpreter/Compiler und Programm, der BASIC-Interpreter belegte 16 KByte, sodass 45 KByte übrig sind - beim CPC waren es 43 KByte). Spiele sind dann ebenfalls CP/M COM Files. Sie können wie beim CPC über Sprungroutinen in den obersten KByte das OS/ROM einblenden und dann grafische Routinen des Betriebssystem nutzen. Sie können sogar über 16 KByte mehr Speicher verfügen als beim CPC, wo immer in den oberen 16 K der Bildschirmspeicher steckte.

Der Rechner hat so 128 KByte RAM und 48 KByte ROM - genauso viel wie der CPC 6128 nur anders organisiert.

Bildschirmansteuerung

Die Bildschirmauflösung und Verwaltung war ein Problem. Das kleinere war noch die Größe des Bildschirmspeichers. Ich wollte einen größeren Bildschirmspeicher als beim CPC haben, das extreme Missverhältnis von Zeilen und Spalten beseitigen. Gegen 640 x 480 Pixel sprach die dafür benötigte Bandbreite. Der CPC hatte eine Datenrate von 2 MByte/s beim Auslesen des RAMs bei 200 Zeilen und 50 Hz. Bei 480 Zeilen wären dies bei sonst unveränderten Parametern 4,8 MByte/s, entsprechend einer Zykluszeit von 104 ns bei gleichzeitigem Zugriff von CPU auf den Bildschirmspeicher und 208 ns ohne diesen. Deutlich unterhalb dessen, was dynamische RAM zu dieser Zeit schafften.

Ich beschränkte mich auf 32 KByte, was eine Auflösung von 640 x 400 Pixel maximal bedeutet. Ich zog andere Auflösungen wie 720 x 350 (8 bzw. 9 x 14 Punktmatrix der Herculeskarte) in Betracht. Für einen reinen CP/M Rechner ergäbe diese eine schönere Textdarstellung und gängige CP/M Programme sind ja textbasiert. Für Spiele wäre die Auflösung von Nachteil, weil dann die Diskrepanz zwischen vertikaler und horizontaler Auflösung relativ groß ist.

Man kann, indem man die relativ großen Ränder des CPC verringert, die benötigte der Datenrate etwas verbessern. Auf die Ränder entfielen beim CPC 60 % der Datenrate (310 Linien zu 200 sichtbaren, 63 Zeichen/Zeile zu 40 sichtbaren). Beim PAL-Standard betragen die Ränder 12 % horizontal und 8 % vertikal, entsprechend 22 % nicht sichtbarer Bereich. Wendet man dies an, so kommt man auf brutto 720 Pixel horizontal, 440 Zeilen entsprechend bei 50 Hz einer Datenrate von 2 MByte/s, entsprechend 263 ns Zykluszeit, die von 120 ns RAM des Typs 41256 erreicht werden. Den leichten Unterschied zum echten ⁴/₃ Verhältnis kann man kaschieren, indem man die horizontalen Ränder auf das Minimum reduziert (720 übertragende Spalten = 90 Zeichen im Modus des CRT), aber vertikal 540 Zeilen (anstatt minimal 440) überträgt mit großzügigen Rändern oben und unten. Man benötigt dann bei 50 Hz eine Bandbreite von 2,43 MByte/s. Real sind mit bezahlbaren 100 ns 41256 RAM maximal 2,8 MByte/s möglich, entsprechend 22,5 MHz ULA und 7,5 MHz CPU Takt.

Was bei diesem Konzept bleibt ist der Geschwindigkeitsverlust durch den gleichzeitigen Zugriff der CPU und der ULA auf den Speicher. Zuerst dachte ich daher an eine zweite Z80

a CPU, die nur für die Grafikoperationen zuständig ist. Eine Z80A war damals so billig, dass dies die günstige Lösung ist. Die erste CPU würde die zweite mol den Grafikoperationen beauftragen und dazu Funktionsnummern und Befehlsparameter in einen gemeinsamen Speicher schreiben, der von der Bild-CPU periodisch auf neue Aufgaben gescannt wird. Nur: bei Spielen ist die Grafikausgabe die Hauptaufgabe. Da wird dann das System recht langsam, da die zweite CPU ja nur mit 4 MHZ läuft. Zudem ist die Architektur unnötig kompliziert.

Ich habe mich für folgende Grafikmodi entschieden:

Der letzte Modus ist programmtechnisch etwas komplexer als beim CPC, bei den anderen beiden muss man nur den Inhalt eines Bytes unterschiedlich interpretieren. Mit 160 x 400 als logisch nächsten Modus wäre das Bild aber sehr gestaucht. Die Vorgehensweise der ersten beiden Modi entspricht dem des CPC, bei dem eine Zeile immer 640 Bytes entsprach, nur eben mit 640, 320 Bildpunkten.

Ich habe keinen Textmodus vorgesehen. Ein Textmodus hätte zwei Vorteile. Zum einen erlaubt er Attribute wie fett, kursiv, invers, blinkend. Zum anderen ist das Scrollen schneller - es müssen weniger Daten bewegt werden. Allerdings war beim CPC in Benchmarks schneller als PC im Textmodus, da er das Hardwarescrollen des 6845 effizient einsetzte. Zudem habe ich ja eine DMA vorgesehen. Zu den Attributen noch später mehr. Speicher spart ein Textmodus keinen, weil man sowieso den Speicher für den Grafikmodus benötigt.

Auch dachte ich an den Modus der Hercules-Karte, also 720 x 350 Pixel. Das verkompliziert aber die Darstellung. Mit einem 9 x 14 Font ist es so, dass jedes Zeichen auf einer anderen Adresse beginnt und das ermöglicht nicht eine einfache Adressberechnung über ein dreifaches Shift wie bei einem durch 8 teilbaren Font. (Natürlich wäre ein 8 x 14 Font gegangen, doch da war mir das Seitenverhältnis zu extrem). Ich schaute daher nach, wie ein Zeichen beim Druck ausgegeben wird. Es sollte schließlich so aussehen wie beim Druck. Bei einem Matrixdrucker ist ein Zeichen 1/6 Zoll hoch und 1/8 Zoll breit, also ein 4/3 Verhältnis. Dasselbe Verhältnis auf den Monitor übertragen entspricht 8 x 12 Pixeln. Dadurch ergibt sich die obige Zeilenzahl im Textmodus. 12 Pixels in der Höhe ermöglichen gut sichtbare Unterlängen bei Buchstaben. Für den letzten Modus und Beschriftungen von Grafik, die das Verhältnis der Grafik haben sollen, gibt es noch einen 8x8 Font. Das Font-ROM belegt so bei drei Attributen (Fett, Kursiv, Fett-Kursiv) 14 Kbyte (4 x 3 KByte für 8 x 12 Pixel + 1 x 2 KByte für 8 x 8 Pixel).

Für die Textdarstellung wird die Zeichenmatrix einfach ins Grafik-RAM aus dem ROM kopiert.

Wie schon gesagt hängt die Bildschirmauflösung auch mit der Zykluszeit des RAM zusammen. Entfällt der letzte Zugriff eines Maschinenzyklus auf das Auslesen der Information aus dem Bildschirmspeicher, so verlangsamt dies nicht nur alle Z80 Befehle auf vielfache von 4 Takten. Es diktiert auch, wie schnell das RAM sein muss. Bei Beibehaltung der Parameter des CPC 6128, nur verdoppelter Zeilenzahl errechnet sich die Datenrate zu:

Datenrate = 50 Hz * 620 Zeilen vertikal x 63 Zeichen x 2 horizontal = 3.906.000 Bytes/s.

Die 63 Zeichen x 2 ergeben sich daraus das technisch der CRTC mit Modus 1 arbeitet (40 Zeichen pro Zeile), dort aber wegen vier Farben pro Pixel ein Zeichen zwei Bytes belegt (oder eben eine Zeile 80 Bytes in Monochrom im Modus 2). Wie oben erläutert kommt man auch mit minimalen Rändern nicht auf 2 MByte/s die Datenrate beim CPC (genau 2 Bytes alle 4 Takte). Es ist sogar noch schlimmer. Strebt man für die CPU 8 MHz an, so gibt es alle 4 Takte (500 µs) folgende Zugriffe:

• einen von der CPU

• zwei von dem Gate Array (bei 4 MByte/s)

Damit benötigt man RAM mit einer Zykluszeit von 166 ns. Weil man die beiden Gate Array Zugriffe auf die zweite Hälfte des Zyklus verortet sind, es sogar 125 ns. Wie man bei Tabelle 1 sieht, hat kein dynamisches RAM diese Zykluszeit. Es gibt wie bei der CPU mehrere Lösungsmöglichkeiten:

• Begrenzen des CPU-Takts auf 6 MHz, entsprechend 3 MByte Videobandbreite (reicht bei verkleinerten Rändern aus): 222 ns Zykluszeit erforderlich, erreichbar mit 120 ns dynamischem RAM.

• Grafikspeicher als statisches RAM: 4 x 6264 mit 150 ns Zykluszeit. Das hätte den Vorteil, dass die CPU auch bei normalen RAM nicht Wartezyklen für das Gate Array einlegen muss, macht aber eine deutlich komplexere Verschaltung nötig, auch wegen der byteweisen Architektur der Speicherchips.

• Zwei RAM-Banke, eines für die geraden und eines für die ungeraden Adressen. Das Videoarray liest immer nacheinander den ganzen Block aus, die CPU meist auch. Im Extremfall gibt es pro 500 ns maximal einen Zugriff des Videoarrays und der CPU, dann reicht eine Zykluszeit von 250 ns die 120 ns Zugriffszeit entsprechen. Dann wäre jedoch, selbst wenn man Kombisockel für 64/256 KBit RAM vorsieht, nur Konfigurationen mit 128, 320 und 512 KByte RAM möglich.

Da das Begrenzen des Takts nicht so toll ist, wenngleich es auch den Vorteil einer kleineren Videobrandbreite hat, mit der man mit kleineren Rändern auskommen würde und die weniger Aufwand beim Gate Array macht, bleiben zwei Möglichkeiten deren Vor- und Nachteile ich hier vorstellen will:

Textdarstellung

CP/M ist ein textbasiertes Betriebssystem und die meisten Textverarbeitungsprogramme produzieren auch nur Text. Schön ist es, wenn der Bildschirm dann auch den Text zumindest ansatzweise so wiedergibt, wie er gedruckt wird. Systeme mit reinen Textdarstellungen haben daher noch einen Attributspeicher, ein Attribut kann z.B. folgende Statusbits enthalten:

• Fette Darstellung

• Schräge Darstellung

• Unterstreichen

• Invers

• Blinkend

Diese Attribute kann man noch kombinieren. Benötigt werden nur vier Fonts. Verzichtet man auf "Blinkend" so kann man das aber gut auch im Grafikmodus nachbilden:

Man benötigt die Fonts:

• Normal

• Fette Darstellung

• kursive Darstellung

• fett/kursive Darstellung.

Je nach gesetztem Bit kopiert man dann einfach die Matrix aus einem der vier Fonts in den Bildschirmspeicher.

Unterstreichen macht man, indem man das Bitmuster der Basislinie, z.B. Zeile 7 in jeder Spalte konstant auf 1 setzt. Invers, indem man die Pixelmatrix Xor-t. Ist einmal die Matrix gesetzt, so ist es normale Grafik, das erlaubt es auch Text in Grafik an beliebiger Stelle einzufügen. Der Nachteil dieser Methode ist, das diese Fonts zusätzlichen Speicher belegen.

ROM

Ich habe mich bei dem Design am CPC orientiert, der hatte ein 16-KByte-ROM für das DOS und 16 KByte für das OS. Beide ziemlich voll belegt. Es entfallen bei diesem Design einige Routinen, die dieser Rechner nicht braucht, so für die Kassettenrekorderansteuerung, die mathematischen Routinen für den BASIC-Interpreter, die RSX-Befehle für die Diskette. Wirft man die obigen Routinen aus dem ROM, so spart man rund 4,8 KByte ein, jedoch braucht man auch weitere Routinen für die Textdarstellung und des neuen niedrigauflösenden Modus. In der Summe sollte es reichen.

Das BASIC Interpreter ROM entfällt, stattdessen gibt es das Font-ROM. Es liefert neben den Fonts weitere 2 KB die man für die Kopierroutinen der Textdarstellung nutzen kann. Das Disk ROM steckt wiederum in einem eigenen ROM. Es kann auf 32 KB des RAMs zugreifen, die sonst in keinem Modus auftauschen. Dort kann man das CP/M BIOS/BDOS unterbringen. Alternativ kann der RAM Bereich als Druckerspooler oder Puffer für Diskettensektoren oder das Verzeichnis dienen. Bei separatem Grafikspeicher hat man in jedem Falle genügend Speicher für einen Spooler.

ROM-Erweiterungen

Wenn man CP/M als Standardbetriebssystem vorsieht, stellt sich die Frage, ob man es nicht gleich CP/M und Anwendungen in ein ROM ablegt. Außer dem Betriebssystem könnte man auch häufige Standardprogramme wie STAT im ROM unterbringen. Ich denke hier an ein Programm für das Diskettenformatieren und einen File Manager (ja den gab es auch für 8 Bitter). 8 Bit Programme sind recht klein, reserviert man jeweils für ein Programm eine 16 KByte Bank, die dann einfach zum Start in die ersten 16 KByte der TPA kopiert werden. Bei größeren Programmen wie einer Textverarbeitung entsprechend mehrere Bänke. So kann man auch eine für den Computer geeignete Softwaresuite anbieten. Ich würde für zwei Standardprogramme: Supercalc und Dbase und eine eigene Textverarbeitung plädieren, die die Fonts nutzt. Eine ROM-Erweiterung bringt dem Anwender viel, der Rechner ist schneller einsetzbar und sie belegt keinen Speicher auf der Disc, zudem spart er kosten für den Softwarekauf. Für den Hersteller ist es relativ billig. Selbst wenn man eine neue Textverarbeitung programmieren lässt, verteilen sich die Kosten doch auf Tausende verkaufte Computer. ROMs sind zudem billig, billiger als DRAM, die Anfang 1985 bei 36 DM Kosten für 16 KByte liegen und dann rasch billiger wurden. Ein Jahr später kosteten 16 KByte nur noch 5,60 DM.

Es gibt zwei mögliche Umsetzungskonzepte. Das eine ist das einer ROM-Disk: Sie präsentiert sich als ein verbautes Diskettenlaufwerk, das nicht beschrieben werden kann. Der Benutzer kann so unter Umständen auf ein zweites Diskettenlaufwerk verzichten. Dieses Konzept ist das elegantere für CP/M.

Das zweite ist es das ein Modul, das Steckplätze hat, die feste ROMS / EPROM aufnehmen. Dazu benötigt man dann noch einen Selektions-, oder Startmechanismus, wie einen Schalter. Dieses Konzept wäre besser geeignet für eigene Erweiterungen, so könnte man eigene CP/M Programme in ein EPROM brennen und dann so starten oder ein gekauftes Programm in ein EPROM transferieren. Dieses Konzept ist zwar flexibler, aber teuer wegen der nötigen Sockel. Das dürfte aber nur für den ambitionierten Hobbyisten interessant sein.

Spiele als ROM-Module sind mit beiden Konzepten möglich: entweder man startet zuerst ein Minimal-CP/M (dann geht auch CP/M 2.2, das belegt rund 9 KByte) und lädt dann automatisch ein COM-File mit dem Spiel, das dann die Kontrolle über den Rechner übernimmt, oder es wird automatisch ein Programm an den Beginn der TPA bei 100H geladen und gestartet. Diese "Diskettenemulation" belegt in diesem Falle wegen CP/M und Verwaltungsinformationen etwa 12 KByte mehr.

RAM-Erweiterungen

Ich hatte einen CPC 464 aufgerüstet mit einer Vortex Speichererweiterung. Der zusätzliche Speicher von 512 KByte wurde unter CP/M als Druckerspooler (32 KByte) und RAM Disk (448 KByte) genutzt. Eine RAM-Floppy ist echt praktisch, doch wenn man die wichtigsten Programme im ROM hat (und das ist billiger als RAM), muss man diese nicht auf die RAM-Floppy kopieren. Eine kleine RAM-Floppy um Zwischendaten aufzunehmen wäre aber ganz nützlich. Wordstar schriebt z.B. alle 2 KByte in eine Zwischendatei, Compiler erzeugen bei jedem Übersetzen ein neues Com File. Ich denke eine RAM-Floppy muss nicht groß sein, 64 bis 128 KByte halte ich für adäquat, wenn darauf nur Arbeitsdateien landen. Nimmt man die Adresscodierung der CPU als Basis, so bieten sich 128 KByte an. Der Gesamtarbeitsspeicher beträgt dann 256 KByte.

Ich halte als sinnvollste Einsatzmöglichkeit nur ein Basismodell anzubieten und zwei Erweiterungssteckplätze. Eines für RAM-Module (mit verschiedenen Kapazitäten) und eines für ROM-Module. Das kann auch mit Leerplätzen angeboten werden, z.B. acht Sockel für EPROM. Dann könnte der Anwender es selbst mit Eproms belegen. So könnte man auch Spiele anbieten.

Die Alternative ist es, schon intern mehr Speicher vorzusehen. Beim Konzept des Grafikspeichers auf zwei Bänken hat der Rechner sowieso mindestens 128 KByte Speicher. Sieht man hier Sockel für 41256 RAM aus, in die auch 4164 passen so kann man den Rechner mit 128 (64 + 64 K Bank), 320 (64+256 K Bank) oder 512 (2x 256 K Bank) anbieten bzw. der Benutzer kann die RAM selbst auswechseln. Das entspräche 192 bzw. 384 KByte RAM Disk und ist in der Herstellung der billigere Weg.

Spiele

Auch wenn für mich der Haupteinsatzgebiet des Computers die Nutzung von Anwendungen wäre, so weiß ich doch, das die meisten ihren Heimcomputer nur zum Spielen gekauft haben. Mit der Grafikauflösung, dezidiertem Grafik-CPU und Sprites wäre er sogar eine attraktive Spielplattform. Wie kann man das umsetzen?

Nun zum einen durch die erwähnten ROM-Module, die auch einen Pin nutzen können, damit der Computer den Modulinhalt beim Start lädt und nicht CP/M. Zum anderen, indem das Spiel zuerst einmal ein normales CP/M Programm ist, dann aber sobald es geladen ist die volle Kontrolle über das System übernimmt. Für erneuten CP/M Betrieb müsste man dann einen Soft- oder Hardreset machen.

Für mich sind Spiele nicht die primäre Ausrichtung des Rechners, schon wegen des Monochrommonitors und dem hochauflösenden Bildschirmmodus, aber man könnte auch einfach einen PAL-Konverter, das ist eine relativ einfache Schaltung auf das Board löten, der dann eben den hochauflösenden Modus nicht unterstützt.

Kostenabschätzung

Bisher habe ich nur diskutiert, nun geht es darum, konkrete Umsetzungen zu machen. Doch auch hier will ich erst mal die verschiedenen Konfigurationen diskutieren. Erneut nehme ich als Basis den CPC 6128. Diesmal nur mit Monochrommonitor. Ich nehme an, das wer spielen will, dann billiger fährt, wenn er einen RGB-PAL-Adapter wie er auch beim CPC angeboten wird, einsetzt. Gegenüber diesem benötigt der Rechner mindestens mehr:

• 1 x Z80B/C CPU

• 1 x Z80A DMA

• diverse Treiber und Decoder der 74xx Serie

• 1 Laufwerk mit 1 MByte unformatiert anstatt 250 KByte unformatiert

Die restlichen Bausteine, inklusive RAM und ROM Ausbau sind identisch. Man benötigt aber schnellere Bausteine. Basierend auf den Preisen in Computerzeitschriften Anfang 1986 errechne ich Mehrkosten von etwa 90 DM, der Großteil von 70 DM entfällt auf das Diskettenlaufwerk. Verdoppelt man diese Summe, der Hersteller will ja auch noch was verdienen, so ist man bei rund 1.780 DM für einen Rechner mit Monochrommonitor, 720 KByte 3,5 Floppy, 128 KB RAM und 48 KB ROM und einer hochauflösenden Darstellung. (Ausgehend von 1.598 DM für einen CPC 6128 mit Grünmonitor).

Ein zweites 3,5 Zoll Laufwerk kostete damals für den Endkunden je nach Kapazität und Typ zwischen 280 und 420 DM.

Die nächstschnellere Konfiguration setzt die Z80H ein, mit 8 MHz, Sie erfordert immer zwei RAM-Bänke, wäre also nur mit 128, 320 und 512 KByte lieferbar. Die Mehrkosten sind überschaubar:

• 10,40 DM für schnellere RAM (120 anstatt 150 ns Zugriffszeit)

• 20,80 DM Aufpreis Z80H CPU

• 84,00 DM Aufpreis für 192 KByte (Austausch 4164-120 durch 41256-120).

Verdoppelt man auch dies, so erhält man für 70 DM Mehrpreis ohne Speicherausbau und 250 DM beim Ausbau auf 320 KByte.

Die letzte Konfiguration hat ein separates Grafik-RAM aus 6264-LP15 Bausteinen. Dazu benötigt man vier Bausteine zu je 10 DM, mit Verdopplung des Preis also 80 DM Mehrkosten.

Hier eine Übersicht der Systeme und ihrer Vorteile

Was das Optimum ist, darüber kann man diskutieren. Zieht man den Mehrpreis für das Diskettenlaufwerk ab, so sind die Aufpreise relativ gering: 40 DM bei der Z80B CPU, 70 DM bei der Z80H und 80 DM beim separaten Grafikspeicher. Hinsichtlich mehr MHz pro mehr DM ist also die kleinste Konfiguration am besten. Bezieht man dies jedoch auf den Gesamtpreis, so kommt man auf folgende Werte in DM pro MHz:

• CPC 6128: 500 DM/MHz

• Z80B Option: 370 DM/MHz

• Z80C Option: 290 DM/MHz
  Z80C Grafikspeicher: 242 DM/MHz

Die letzte Option liefert also die 2,5-fache Geschwindigkeit für nur 25 % Mehrpreis. Sie ist damit die preislich alterativste.

Weiterhin kann der Benutzer auch noch Geld sparen, denn wenn für das zweite Laufwerk nur eingesteckt werden, muss anstatt das man es mit eigenem Gehäuse verkauft, wie das Schneider/Amstrad tat: ein Laufwerk mit 250 KByte Kapazität kostete damals 280 bis 350 DM, wurde von Armstrad aber für 500 DM verkauft.

In der Summe ist also die am besten ausgestattete Option die attraktivste. Für CP/M User, die normalerweise mit zwei Laufwerken arbeiten müssen, wird die beste Option es sein, nur ein Laufwerk einzusetzen und die 4164 RAM durch 41256 zu ersetzen. Die kosteten im Einzelhandel im Januar 1986 um 13 DM, mit 16 Stück hat man dann einen Rechner mit 512 KByte RAM, davon 384 als RAM-Floppy nutzbar. Auf die kopiert man beim Start alle Daten der Startdiskette und arbeitet dann mit der RAM-Floppy und nutzt das interne Floppylaufwerk für die bearbeiteten Daten (Texte, Tabellen, etc), die ja nicht bei Absturz verloren gehen dürfen. Das kostet 208 DM, ein 1 MB 3,5 Zoll Laufwerk aber 420 DM.

Der Z80 Heimcomputer heute

Eine Inspiration für den Artikel war auch die Vorstellung eines Retrocomputers auf Basis de Z80. Das leistungsfähigste Exemplar, das ich fand, war der SC131 auf Basis der Z180. Es gibt ihn in mehreren Versionen, hier eines im Gehäuse. Er kommt mit nur wenigen Chips aus:

• Der Z180 CPU

• Ein 512 KByte ROM

• Ein 512 KByte RAM

• Ein 74139 Adressdecoder

• Ein 74259 Adressdecoder

Es sind so wenige, weil die Z180 schon viele Zusatzbausteine integriert hat. So adressiert sie 1 MByte Speicher der unterteilt ist in 512 KByte ROM und 512 KByte RAM. Die gesamte Kommunikation erfolgt durch eine serielle Schnittstelle, die ebenfalls integriert ist und mit einem Chip die Signale auf das USB-Protokol wandelt. Die beiden Adressdecoder einer mit Speicherfunktion, einer ohne, erlauben es RAM und ROM zu unterscheiden und jeweils in den 512 KByte die richtige Bank anzusprechen, denn auch die Z180 kann nur 64 KByte am Stück adressieren. Das sind dann in etwa so viele Chips, wie sie auch ein ZX81 von Sinclair hatte.

Er ist aber nicht mit einem echten Heimcomputer vergleichbar, denn er ist nicht selbstständig lauffähig. Man kann ihn nicht an einen Monitor anschließen, auch nicht an eine Tastatur. Er wird vom Hostcomputer aus über eine serielle Schnittstelle angesprochen, überträgt an diesen den Bildschirminhalt (nur Textdarstellung) und empfängt alle Kommandos. Der PC ist also so was wie ein besonders gutes Terminal. Grafikchips, Soundchip, I/O Chip für Anschlüsse, das alles fehlt. Natürlich auch die Peripherie, also Tastatur, Floppylaufwerk, Monitor. Will man den Rechner nur an einen Monitor anschließen, so geht das nur über Umwege. In dem Falle, dass man einen Raspberry Pi Zero dazu missbraucht und über seine GPIO-Pins die Daten für die Monitordarstellung überträgt - grafikfähig ist er aber auch dann nicht. Man kann den Rechner durch Boards aufrüsten - es gibt alle Erweiterungen auch Grafikprozessor und Soundprozessor, doch dann wird es teuer.

Die Taktfrequenz der Z180 beträgt 18,4 MHz, mehr als doppelt so hoch wie bei der Z80H, aber bedenkt man das seitdem über 30 Jahre vergangen sind, wenig. Allerdings ist die Taktfrequenz dem RAM geschuldet. Damit man mit möglichst wenigen Zusatzbausteinen auskommt, musste man ein RAM einsetzen das relativ viele Pins hat, wie sie sie ein Z80 System erwartet, heute haben SRAM ein serielles Protokoll mit viel weniger Pins. Das verwendete RAM ist ein statisches RAM (wie die 6264) mit 55 ns Zugriffszeit = der Kehrwert von 18,4 MHz. Die Z180 wäre bis 32 MHz taktbar, wenn man ein geeignetes RAM findet.

Es gibt heute eine Reihe dieser Retrocomputer, auch mit Z80 CPU. Alle muss man aber selbst zusammenbauen, d.h. die Bauteile in die Platine einlöten. Wer Interesse hat, sucht einfach nach RC2014 und Retro Computer" bei Google. Komplette Bausätze werden bei Tindler angeboten.

Artikel verfasst am 26.1.2020

Zum Thema Computer ist auch von mir ein Buch erschienen. "Computergeschichte(n)" beinhaltet, das was der Titel aussagt: einzelne Episoden aus der Frühzeit des PC. Es sind Episoden aus den Lebensläufen von Ed Roberts, Bill Gates, Steve Jobs, Stephen Wozniak, Gary Kildall, Adam Osborne, Jack Tramiel und Chuck Peddle und wie sie den PC schufen.

Das Buch wird abgerundet durch eine kurze Erklärung der Computertechnik vor dem PC, sowie einer Zusammenfassung was danach geschah, als die Claims abgesteckt waren. Ich habe versucht ein Buch zu schreiben, dass sie dahingehend von anderen Büchern abhebt, dass es nicht nur Geschichte erzählt sondern auch erklärt warum bestimmte Produkte erfolgreich waren, also auf die Technik eingeht.

Die 2014 erschienene zweite Auflage wurde aktualisiert und leicht erweitert. Die umfangreichste Änderung ist ein 60 Seiten starkes Kapitel über Seymour Cray und die von ihm entworfenen Supercomputer. Bedingt durch Preissenkungen bei Neuauflagen ist es mit 19,90 Euro trotz gestiegenem Umfang um 5 Euro billiger als die erste Auflage. Es ist auch als e-Book für 10,99 Euro erschienen.

Mehr über das Buch auf dieser eigenen Seite.

Hier geht's zur Gesamtübersicht meiner Bücher mit direkten Links zum BOD-Buchshop. Die Bücher sind aber auch direkt im Buchhandel bestellbar (da ich über sehr spezielle Themen schreibe, wird man sie wohl kaum in der Auslage finden) und sie sind natürlich in den gängigen Online-Plattformen wie Amazon, Libri, Buecher.de erhältlich.

Sitemap

Kontakt

Impressum / Datenschutz

Neues

Hier werben / advertisment here

Buchshop

Bücher vom Autor