Bernd Leitenbergers Blog

Der Schneider / Amstrad CPC 6128 und das Joyce – man hätte mehr draus machen können.

Bernd Leitenberger

Die ct‘ hat dieses Jahr zwei Retro-Ausgaben herausgebracht, die sich mit alten Computern wie dem C64, Spectrum, Amiga oder Atari ST beschäftigten. Das hat mich dazu gebracht mich wieder mehr mit alten Computern zu beschäftigen. Ich dachte zuerst daran einen Artikel über das Bankswitching und wie es im CPC 6128 funktionierte zu schreiben, doch bei der Recherche dafür entdeckte ich das es da schon genügend gute Quellen gibt. Aber es hat mich dazu inspiriert, mal einen „Retro-Wir-Wissen-es-besser“ Aufsatz zu schreiben. Gut ist aus der Retroperspektive immer möglich, aber ich denke meine Ideen sind zumindest diskutabel.

Aber fangen wir mal mit etwas Persönlichem an. Das Vorgängermodell CPC 464 war mein zweiter Computer. Mein erster war ein Ti 99/4A. Von ihm trennte ich mich bald, zum einen weil ich ihn als langsam empfand, was dann beim Lesen von Tests bestätigt wurde, vor allem, aber weil zweimal kurz nacheinander der Tuner meines Fernsehers zum Totalschaden wurde und das Einzige was ich anschloss war eben dieser Computer. Alle 1-2 Monate einen neuen Tuner konnte ich mir nicht leisten.

Ich habe dann über zwei Jahre gewartet mit einem Neukauf, weil ich mit keinem der angebotenen Modelle zufrieden war. Entweder waren sie zu teuer oder billig verarbeitet wie der Spectrum oder mit einem spartanischen BASIC wie der C64. Der CPC überzeugte mich sofort. Er hatte einen Monitor mit dabei, 80 Zeichendarstellung, was bei Heimcomputern die absolute Ausnahme war, einen guten Grafikmodus, 64 K RAM, von dem viel mehr nutzbar war als bei der Konkurrenz und er war bezahlbar. Ich gönnte mir nach dem schriftlichen Abitur sogar die Version mit Farbmonitor. Recht bald kamen dann noch ein Diskettenlaufwerk und ein Drucker dazu. Später eine Doppelfloppy von Vortex (die von Amstrad hatten das ungewöhnliche Format 3 Zoll und die Disketten waren sehr teuer) und später ebenfalls von Vortex eine Speichererweiterung auf 512 kb, die mir unter CP/M eine komfortable RAM Floppy ermöglichte und damit bequemes Arbeiten. Mein Arbeiten verlagerte sich auch nach einem Jahr von BASIC auf CP/M. Ich nutzte Word-Star und Dbase und programmierte in Turbo Pascal und Assembler. Ich habe selbst als der CPC kaputtging mir nicht das Nachfolgemodell gekauft, sondern den gleichen Rechner wieder. So benutze ich ihn bis zum Ende meines Studiums, das war 1993, also über acht Jahre – so lange wie seitdem keinen Rechner.

Den CPC 6128 habe ich nie besessen. Rationaler Grund war das mir die Aufteilung des Tastenfelds nicht gefiel und das kurze Design, zudem fand ich konnte man die 128 KB nur unzureichend nutzen. Sie sind deswegen auch Aufhänger für den Artikel. Wenn ich ehrlich bin: ich habe mich wohl geärgert: Ich zahlte im Februar 1985 1398.- für den Rechner und 899.- für die Floppy. Zusammen also 2297.- Wenige Monate später erschien der CPC 664 mit integrierter Floppy für 1998.- Schon 300 DM billiger und wieder einige Monate später der CPC 6128 mit verdoppeltem Speicher für 2098.- Immer noch billiger und unter CP/M mit einer TPA (Transistent Program Area – der Speicher der für Anwendungsprogramme übrig blieb), die für alle Programme, die es gab, ausreichte. Bei den vorherigen Modellen war sie wegen des 16 KByte großen Bildschirmspeichers relativ klein, reichte aber trotzdem für Wordstar, Multiplan und Dbase aus.

Aber das Design des CPC 6128 basiert auf dem CPC 464 und deswegen kann ich drüber schreiben. Es geht über das Bank Switching und wie es clever genutzt wird. Die grundlegende Technik ist bei allen Rechnern die gleiche, nur die Umsetzung variiert. Ein 8-Bit-Prozessor wie der 8080, Z80, 6502 oder 680x kann mit 16 Adressleitungen maximal 64 KByte adressieren. Will man mehr Speicher adressieren, so benötigt man eine zusätzliche Schaltung. Das kann entweder ein dafür spezialisierter Zusatzbaustein sein, eine MMU (Memory Management Unit) das ist die beste und flexibelste, aber auch teuerste Lösung. Der C128 hatte eine solche MMU an Bord. Alternativ realisiert man dies mit Zusatzbausteinen. Das kann geschehen mit Bausteinen der 74xxx Serie. Flipflops können einen Zustand speichern – man wird die Bank mit einem Befehl wechseln, aber dann muss der Zustand auch aufrechterhalten werden. Ein Element wie das 74138 kann aus drei Eingansadressleitungen dann ein Signal auf einem von 8 Ausgangsleitungen erzeugen. Das nutzt man, um bis zu acht Chips anzusprechen. In der Regel wird man aber eine eigene Schaltung dafür entwickeln. So auch beim CPC 464 bis 6128. Die 74xxx Lösung verwenden aber Bastelprojekte, so die Zeitschrift ct‘, die den 6128 von 128 auf 512 kb aufbohrte und zur Selektion der Bank ein 74138 nutzte. Technisch geht dies so, das jeder RAM-Chip aber auch jedes ROM eine Reihe von Steuerleitungen hat, über die ihm der Prozessor signalisiert das er von ihm etwas will. Ansonsten reagiert es nicht auf Daten am Datenbus oder Adressbus. Für einen Lesezugriff muss er die Read-Leitung aktivieren, für einen Schreibzugriff die Write Leitung. Doch das alleine reicht nicht aus. Nur wenn eine weitere Leitung – auf CPU Seite heißt sie Chip Select (CS), auf Speicher Seite Memory Request (Msel) aktiv ist, fühlt sich der Baustein auch angesprochen. So kann man in einem System viele Speicherbausteine verbauen und über eine Schaltung, die CS jeweils zur richtigen Msel Leitung zieht, wird dann nur ein Speicherbaustein (hoffentlich der richtige) angesprochen. Bank Switching ist nichts anderes als mehr dieser CS-MSel Verbindungen herzustellen, als der Prozessor von Natur aus hat.

Aber kommen wir mal zur Speicherarchitektur des CPC 464. Was ich erst nach dem Kauf erfuhr: die war sehr ausgeklügelt. Ich wusste zwar damals schon von der 64 K Grenze, ging aber davon aus, das ein Hersteller alles tut, um dem Nutzer die 64 K RAM vollständig zur Verfügung zu stellen. Das bei vielen Rechnern wie dem C64 oder der MSX Serie das ROM Teile des Arbeitsspeichers verdeckte und der nur mit Assemblerprogrammen nutzbar war, wusste ich damals nicht. Am schlimmsten war das bei den MSX Rechnern, bei denen es keinen Unterschied zwischen 32 und 64 K RAM unter BASIC gab.

Beim CPC 464/664 sah die Speicher aufteil so aus:

Adresse ROM RAM Erweiterung
0000 – 3FFFF Betriebssystem BASIC Programm
4000 – 7FFF BASIC Programm
8000 – BFFF BASIC Programm / reseverierter Bereich
C000 -FFFF BASIC Interpreter Bildschirmspeicher RSX-ROM

Der Speicher war in vier Banks von je 16 KB Größe aufgeteilt. Ein Schreibzugriff ging immer in das RAM. Beim Lesezugriff hing es von der selektierten Bank ab.

Da der Z80 bei Anlegen der Stromversorgung bei Adresse 0 das Programm ausführt, war da beim Einschalten das Betriebssystem ROM aktiv. Es enthielt die grundlegenden Routinen für das Ansprechen der anderen Bausteine, Interrupts, Speichern auf Kassette, Bildschirmausgabe und den Editor sowie den Zeichensatz. Parallel dazu lag der Bereich, bei dem ein BASIC-Programm abgelegt wurde, mit Ausnahme der ersten Bytes. Dorthin kopierte der BASIC-Interpreter sieben Restartroutinen. Restarts sind beim Z80 Routinen auf festen Adressen (0-56 in 8 Byte Schritten), die mit einem Opcode aufgerufen werden können. Diese Routinen hatten bis auf eine, die vom Nutzer belegt werden konnten, alle mit dem Bankswitching zu tun. So konnte eine Routine aus den untersten 16 KByte das Betriebssystem aufrufen, obwohl das im selben Speicherbereich lag. Sie waren auch auf Erweiterungen ausgelegt. So gab es die Möglichkeit im oberen Speicher weitere ROM hinzuzufügen und ein ROM konnte über einen Restart eine Routine in einem anderen ROM davor oder dahinter aufrufen. So waren Programme möglich die mehrere ROMS benötigten.

Die nächsten 16 K waren immer aktiv und nahmen ebenfalls das BASIC-Programm auf, wie der untere Teil des nächsten Blocks. Oben in dem dritten Block befanden sich aber der Stack, Puffer und eine Sprungleiste zu Betriebssystemroutinen, die automatisch das Betriebssystem einblendeten, dann konnte, jedes obere ROM beginnend mit dem BASIC Interpreter, darunter eigene Puffer anlegen und die Speicherobergrenze erniedrigen. In der Retroperspektive fand ich einige Buffer recht großzügig dimerisiert, trotzdem hatte der Rechner mit 43903 freien Bytes den größten nutzbaren Speicher zu seiner Zeit.

In den obersten 16 KByte befand sich der Bildschirmspeicher. Das war für einen 8 Bitter ziemlich groß. Andere Rechner begnügten sich mit 6 KByte wie der C64 oder Sprectrum, ermöglichte aber auch mehr Bildpunkte und einen hochauflösenden Modus, der sogar die Grafikfähigkeiten des IBM PC übertraf. Nach Initialisierung des Betriebssystems wurden die oberen ROMS initialisiert. Das begann mit dem BASIC Interpreter und ging dann über die Erweiterungsroms, die man entweder intern verbaute oder extern anschloss. Wer ein Gerät mit Floppy hatte, hatte eines dieser ROMS immer verbaut, das war das das AMSDOS mit #7. Ich hatte noch eine Speichererweiterung mit #6. Um die Erweiterungen unter BASIC anzusprechen, konnte jedes ROM im oberen Bereich Befehle mit Sprungadressen ablegen, die dann mit dem | begannen wie |CPM oder |Bank. Sie konnte man in das BASIC-Programm einbauen.

Insgesamt also eine durchdachte Systemarchitektur, bei der der Speicher gut genützt wurde und die auf Erweiterung ausgelegt war. So gab es auch unzählige Erweiterungen, die meisten schafften es leider nicht auf den deutschen Markt, sondern gab es nur in England, von wo der Rechner kam. Dort hatte er auch einen großen Marktanteil, von mehr als 50 %.

Man sieht: Bank-Switching gab es schon, nur eben beschränkt auf ROMs. So war es auch einfach das Modell zu erweitern und das tat man beim CPC 6128. Was den Rechner aber einholte, war der Fluch der Komptabilität. Es sollten ja alle Programme, das waren vor allem Spiele, für die beiden Vorgänger laufen. Also musste der Rechner dazu kompatibel sein. Das bedeutete: man konnte wenig ändern. Nach wie vor gab es 16 K Bänke nur, konnte man nun mit einem Ausgabebefehl an das ULA eine von acht Konfigurationen wählen. Schon an der Zahl ist klar, dass dies nicht alle technisch möglichen sind, denn es gab ja acht Bänke mit 51 möglichen verschiedenen Konfigurationen, um die auf vier 16 K Bereiche zu verteilen. Im wesentlichen gab es vier Fälle:

Der unterste 16 K Bereich und oberste konnten nicht geswitcht werden, ohne das man sich den BASIC-Interpreter oder das Betriebssystem wegzog, in den dritten 16 K befanden sich wichtige Datenstrukturen und Sprungvektoren. Da sowieso nur ein 16-K-Block auf einmal angesprochen wurde entschied man sich daher für den einzigen Bereich, der beim CPC 464/664 vollkommen frei war.

Eine einfache Lösung, aber mit überschaubarem Nutzen. Die 128 KByte kamen meiner Ansicht daher nur CP/M Nutzern richtig zu Gute.

Meine Alternative

Komptabilität ist gut, aber sie sollte nicht heilig sein. Meiner Ansicht nach hätte es auch eine Möglichkeit gegeben, einen zweiten Modus einzuführen. Das sähe meiner Ansicht nach so aus:

Was klar ist, ist das der Rechner nie mehr als 64 K RAM ansprechen kann. Anstatt Krückenlösungen zu machen, wie die ihn als Grafikspeicher zu nutzen, halte ich es für sinnvoller, den Bildschirmspeicher auszubauen. Der verbaute MC 6845 kann bis zu 512 KB RAM ansprechen und ist in weiten Grenzen frei programmierbar. Er wurde beim IBM PC in so unterschiedlichen Grafikkarten wie der CGA, Hercules, EGA und VGA eingesetzt. Am sinnvollsten erscheint mir den Bildschirmspeicher auf 32 KByte zu vergrößern. Das erlaubt einen neuen hochauflösenden Modus (640 x 400 in zwei Farben), der auch beim Monitor möglich sein sollte (ein Monitor der horizontal 640 Pixels schafft, schafft auch vertikal 400). Die anderen Modi haben dann mehr Farben (640 x 200 in vier anstatt zwei Farben, 320 x 200 in 16 anstatt vier Farben, denkbar wäre auch ein neuer Modus 320 x 400 in vier Farben, die Darstellung wäre dann nicht so verzerrt wie bei 640 x 200.

Damit belegt der Bildschirmspeicher die oberen 32 KByte. Da der MC 6845 ein Videocontroller, aber kein Videoprozessor ist, muss der Speicher im Adressbereich der CPU liegen. Damit rutscht der freie Speicher unter BASIC auf 32 KByte – Buffer = ~ 26 KByte zusammen. Anstatt nun wieder einen BASIC-Interpreter in die oberen 16 K zu verbauen, habe ich mir gedacht ist ein BASIC Compiler wohl die bessere Wahl. Ein Compiler benötigt nicht das ganze RAM dauernd im Zugriff, da er nicht jede Zeile neu interpretiert, wie eine Textverarbeitung parst er eine Textdatei und erzeugt daraus Binärcode. Nur wenn er den Binärcode für eine Bank fertig hat oder die nächste Textzeile in einer anderen Bank liegt, muss er die Bank wechseln. Er kommt daher mit wenig RAM aus. Die restlichen 96 kb kann man so aufteilen in zwei Banks von je 48 K einmal für den Quelltext und eine für das erzeugte Programm. Das würde dann zum Start umkopiert werden, enthält auch alle notwendigen Switchingroutinen und ist als Binärprogramm mit einem CP/M Programm vergleichbar. Es würde beim Start die Situation wie unter CP/M vorfinden: fast 64 K freies RAM (unter CP/M waren 61 K frei) nur mit Sprungvektoren / Switchroutinen am oberen Ende. Ein Programm könnte so maximal 48 K lang sein (Rest für Variablen). Alternativ speichert man das erzeugte Programm auf Disk dann fällt auch diese Grenze weg und auch der Quelltext kann dann 96 K lang sein.

Ich denke in den 32 Kb, die sowieso der Bildschirmspeicher blockiert, passt ein solcher Compiler. Es gibt zwei Anhaltspunkte. Ich denke an ein BASIC ohne Zeilennummern mit Prozeduren und Funktionen, lokalen Variablen, Variablen und wertparametern, eine Art Pascal lite, nur ohne die bei Pascal noch vorhandenen Möglichkeiten für eigene Typen, Zeigern Records, Aufzählungstypen, Sets, es soll ja einfach bleiben. Es gab einen BasIc Compiler für den CPC 6128, den FabaCom, der war 23 kByte groß. Umgekehrt war Turbo Pascal, mit noch größerem Sprachvorrat und integriertem Editor, 32 KByte groß. So denke ich passt ein BASIC Compiler in 32 KByte.

Der Lohn: BASIC Programme sind so schneller, da kompiliert, es ist ein komfortables BASIC, wie es damals auch gerade woanders aufkam (Atari ST:GFA-BASIC, MS-DOS: Turbo BASIC, Sinclair QL: Super BASIC) und man kann die ganzen 64 KByte nutzen, nicht nur rund 42 KByte und hat noch die doppelte Auflösung. Der technische Aufwand besteht in einem weiteren 32 KByte großen ROM für den BASIC Interpreter.

Wenn schon, denn schon

Als ich für den Artikel mal alte Ct‘s mit Tests und Projekten zum CPC gewälzt habe, bin ich auch über die damals noch üblichen Preislisten für Bauteile gestolpert. Als der CPC erschien, waren 16 Bit CPUs schon weit verbreitet. Der IBM AT und Atari ST waren erschienen, in den USA auch der Amiga. Diese CPUs waren höher getaktet und so sanken die Preise für schnelle Bausteine rapide ab. Hier mal eine Tabelle mit Preisen aus der ct Ausgabe, in der der 6128 getestet wurde:

Typ 4 MHz Version 6 MHz Version 8 MHz Version
Z80 CPU 4,95 9,90 17,56
4164 RAM 2,80 2,80 – 4,10 4,90 – 4,95

Zur Erklärung: Die Z80A CPU, die im CPC 6128 steckte, ist bis 4 MHz Takt spezifiziert. Bis 6 MHz erlaubt die Z80B CPU, bis 8 MHz die Z80H (früher als Z80C bezeichnet). Bei der Z80 benötigt man RAMs mit einer Zugriffzeit, die dem Kehrwert der Taktfrequenz entspricht, also bei 4 MHz mit 250 ns Zugriffszeit, 6 MHz 166 ns Zugriffszeit und 8 MHz 125 ns. Entsprechend findet man bei den Typen die Zugriffszeit vermerkt. Ein Blick auf die Platine des CPC 464 zeigt, das er schon 4164 (64 KBit x 1 Bit) Bausteine mit 150 ns Zugriffzeit verbaut hatte, obwohl 250 ns gereicht hätten. Ein Blick auf die Preisliste zeigt auch – die waren damals nicht mehr teuerer als die 250 ns Typen. Ich kann mich auch an eine Leserzuschrift erinnern, bei der jemand die Z80A CPU durch eine Z80B ersetzt hatte und den Quarz ebenso und der Rechner stabil lief – bis auf die Floppyroutinen, der Floppykontroller hatte seinen Takt wahrscheinlich auch vom Haupttakt abgeleitet und beim Schrieben auf die Disk entspricht jedes Bit einer bestimmten Zeitdauer. Das Speichern auf Kassette ging aber. Das bedeutet, der Rechner hätte an und für sich schon mit 6 MHz laufen können.

Bei Ferigungbeginn des CPC 6128 war eine Z80H CPU noch 11,5 DM teurer, 120-ns-RAMs pro Stück um 80 Pfennig teuer als 160 ns Bausteine. Das addiert bei 16 RAM-Bausteinen und einer Z80H CPU 24,30 DM zum Gerätepreis, der bei 1398 DM lag – die doppelte Geschwindigkeit für wenig Zusatzkosten und die sanken noch mit der Zeit. Ich habe dann noch geschaut ob das nicht Probleme bei den anderen Bausteinen gibt. Ergebnis: Nein. Der I/O Baustein 8255 wird auch im IBM PC eingesetzt und kommt mit 8 MHz zurecht. Das Gate Array hat sogar einen eigenen 16 MHz Takt, der noch höher ist und generiert aus ihm den 4 MHz CPU Takt (den müsste es nur noch teilen anstatt vierteln). Der Soundchip AY-8910 läuft sowieso nur mit 1 bis 2 MHz erhielt also schon vorher einen geteilten Takt. Der 6845 ist für eine Zykluszeit von 1 µs spezifiziert. Es gibt aber auch die 6845A und B Version mit 0,67 und 0,5 µs Zykluszeit, die dann den doppelten Takt zulassen.

Der 6845 ist auch schuld an einer Besonderheit des CPC 6128. Die CPU läuft zwar mit 4 MHz, Assemblerprogramme sind aber nur so schnell, wie auch einer CPU mit 3,2 MHz. Der Grund: Damit sich CPU und CRTC nicht in die Quere kommen, wenn sie auf den Videospeicher zugreifen, werden alle Z80 Befehle auf ein Vielfaches von 4 Takten durch Wartezyklen gestreckt. (4 Takte = 1 µs, die Zykluszeit des 6845). Da ein Z80 im Mittel 6,8 Takte im Instruktionsmix brauchte, wurde der Durchschnitt auf 8 Takte gestreckt und die CPU um rund 20 % verlangsamt.

Da nun das BASIC-Programm, aber auch CP/M Programme immer in der Bank laufen, in der nicht das Videoram liegt, könnte man diese Einschränkung für diesen Bereich aufheben. In der Summe wäre dann der Rechner (8 MHz Takt, keine Wartezyklen) 2,5-mal schneller als der „originale“ CPC 6128 und das auch bei Spielen oder CP/M Programmen. Das wäre doch ein deutlicher Kaufanreiz.

Geschwindigkeit

Wie schnell wäre der CPC so? Die Frage ist natürlich hypothetisch, aber man kann sich der Antwort nähern. Es gab von einem sehr guten deutschen Programmier-Trio einen BASIC-Compiler für den CPC, der den vollen Sprachumfang abdeckte und es gab in der ct‘ 10/1987 ein Hochsprachenbenchmark in Pascal und C, bei dem auch der CPC mitmachte. Den Benchmark hatte ich noch unter meinen DOS Files und ich habe ihn in BASIC umgewandelt, was gut ging. Für einige Kommandos musste ich trotzdem ins Handbuch schauen, ist schließlich über 30 Jahre her, das ich unter BASIC programmiert habe.

CPC BASIC CPC BASIC compiliert CPC Turbo Pascal IBM PC Turbo Pascal
Integerberechnungen 42,72 / 66,67 6,85 7,93 1,23
Flieskommaberechnungen 66,66 / 79,02 34,6 67,59 39,11
Funktionen 62,89 59,93 117 56,39
Textausgabe 59,67 59,57 39,65 64,20
Grafikausgabe 21,85 / 43,05 6,89 7,89 6,59
Speichern 21,5 / 21,97 / 22,91 / 37 18,7 /19,56 / 20,07 16,5 4,78

Zur Erklärung: ich habe die Benchmarks in drei Emulatoren laufen lassen und die Werte mit denen aus der Zeitschrift vergleichen. Bei den Fliesskommaberechnungen, Grafikausgabe und Speichern habe ich Unterschiede gefunden (Ct-Werte in Fett hinter dem /). Beim Speichern gab es ja nach Emulator (der ja Mechanik nicht so simulieren kann wie Elektronik) leichte Unterschiede um 1-2 Sekunden.

Der kompilierte Code kann bei Fliesskommaberechnungen, transzendenten Funktionen, der Textausgabe und Grafikausgabe mit einem IBM PC mithalten. Nur bei den Ganzzahlberechnungen und dem Speichern auf Disk ist er deutlich langsamer. Turbo Pascal holt hier noch einiges mehr aus dem Code ist dafür bei den Berechnungen mit Fließkommazahlen wegen der Genauigkeit von 11 anstatt 7 Stellen langsamer. Wenn man nun den Code nochmals um den Faktor 2,5 durch einen schnelleren Prozessor beschleunigen könnte, so wäre der CPC mit Z80H 8 MHz CPU in den meisten Aspekten einem IBM PC überlegen.

Problem Floppies

Was jedem CPC Anwender als Idee für einen verbesserten CPC einfällt sind die Floppies. Einer urbanen Legende zufolge soll die Wahl auf das ungewöhnliche 3 Zoll Format gefallen sein, weil man vom Hersteller die Diskettenlaufwerke billig bekam, der wohl so das Format im Markt durchsetzen wollte. Außer Amstrad hat aber nur die Firma Tatung im Einstein es eingesetzt. Resultat: Noch nach Jahren kostete eine 3 Zoll Diskette 17,90 DM (ja man kaufte sie einzeln!) während ein Zehnerpack Verbatim 3,5 Zoll Disketten (DS/DD, das heißt auch noch mit der doppelten Kapazität) für 49,90 DM zu haben war. NoName noch billiger. Man hätte gleich ein 3,5 Zoll Laufwerk verbauen sollen, den Platz gab es wie jeder sehen kann, der das Gehäuse mal geöffnet hat.

Das Joyce Konzept

Amstrad brachte nicht nur die CPC-Serie auf den Markt, sondern auch den Joyce, eigentliche technische Bezeichnung PCW 8256. Er war noch mehr ein Komplettsystem als die CPC-Reihe. Man bekam einen monochromen Monitor mit 90 x 32 Zeichen (er war grafisch mit 720 x 348 Punkten, das entsprach der Herculeskarte beim IBM PC), an ihm war an der Seite ein 3 Zoll Laufwerk verbaut, ein Zweites konnte ergänzt werden. Das war anders als beim CPC ein DS/DD Laufwerk mit der vierfachen Kapazität, aber eben auch im 3 Zoll Format. Die Tastatur war abgesetzt also nicht wie beim CPC ein dicker Kasten mit Floppy. Dazu kam ein Drucker mit 9 Nadeln. Der Rechner hatte 256 KByte RAM, 102 KByte davon waren eine RAM Disk, der Rest wurde für CP/M 3.0 benötigt. Mitgeliefert wurde ein BASIC, das von Diskette geladen wurde und die Textverarbeitung Locoscript.

Für mich war der Rechner nicht auf dem Schirm. Denn er wurde in Deutschland auch als Textverarbeitungskomplettsystem vermarktet. Wie dröge. Auch in Zeitschriften fanden sich kaum Programme und Projekte für den Joyce. Als ich dann für mein Buch „Computergeschichte(n)“ die Verkaufszahlen von Computern recherchierte, kam ich ins Staunen. Der Rechner, der in Deutschland nicht so poulär war, wurde 8 Millionen mal verkauft, die CPC-Serie dagegen nur 3 Millionen mal!

Warum? Nun zum einen war bei uns schon die Marketing Kampagne schlecht. Er wurde als reines Textverarbeitungssystem verkauft. Was man bekam, war aber ein vollwertiger CP/M Rechner mit hoch auslösender Grafik, 256-Kbyte-RAM und Monitor. Das für 2490 DM. Zum Vergleich: Zum gleichen Zeitpunkt kostete ein No-Name IBM PC Nachbau mit 256 KB RAM und einem Laufwerk, der in etwa dasselbe leistete, 3500 DM, dazu benötigte man aber noch einen Monitor (400 DM) und einen Drucker (ab 800 DM), so wurde man locker fast das doppelte los. Mehr leisten konnte der aber auch nicht.

Was mir entging, den meisten Journalisten ebenso, war das der Joyce ein Rechner war, der diejenigen ansprach die einen Computer einfach nur benutzen wollten. Wer ein Textverarbeitungssystem auf einem anderen Rechner in Betrieb nehmen wollte, hatte Folgendes zu tun:

Das alles setzt für Leute die keinen Computer benutzt haben eine ziemlich Hürde auf. Dagegen war, weil die Hardware und Software aufeinander abgestimmt waren beim Joyce schon alles fertig eingestellt. Ich habe das damals nicht so gesehen. In meiner Ignoranz gehört einfach dazu das man sich in die Materie einarbeitet und ein Computer war schließlich zum Programmieren da. Mir hätte zu denken geben müssen, das Alan Sugar, Chef von Amstrad sagte, der PCW wäre sein erster Computer – ich fand die Aussage damals komisch für jemanden der Computer herstellt und verkauft und anscheinend vorher nie einen benutzt hat. Auf der anderen Seite kannte ich auch jemanden der sich schwerer mit Computer tat. Er arbeitete z.B. das DOS-Handbuch durch, als er beim Buchstaben „F“ ankam, musste er alles neu installieren. Das wäre mit einem Joyce nicht passiert.

Was man meiner Ansicht nach verpennt hat, war die Chance, die in dem Konzept lag: so viele verschiedene Programme brauchte man damals im Büro eigentlich nicht. Damals kamen die ersten integrierten Pakete auf wie Symphonie. Wenn man, anstatt den Rechner mit 256 KByte Speicher auszuliefern, nur 128 verbaut hätte, das reicht für CP/M 3.0, Bildschirmspeicher und eine große TPA und stattdessen die Anwendungen in ROMS gegossen hätte – neben der Textverarbeitung eine Tabellenkalkulation (Supercalc), Datenbank (Dbase II) und ein Modul für Diagrammen (GSX als Schnittstelle war ja schon an Bord), dann hätte man ein komplettes Paket gehabt. Da die Programme im ROM sitzen, sollten sie dann auch etwa 60 KByte für die Daten nutzen können, was viel ist. Bei einem IBM PC müsste man, weil die Anwendung auch Speicher belegt, dort wegen dem 16-Bit-Code auch Betriebssystem und Anwendung größer sind, mindestens 320 KByte verbauen, um auf eine analoge Anlage zu kommen. Dabei sind ROMS billig. Ein maskenprogrammiertes ROM ist noch einfacher aufgebaut als ein dynamisches RAM. Es ist einfach eine Matrix von Transistoren, die entweder im Durchlassbetrieb oder Sperrbetrieb arbeiten entsprechend 0 oder 1 Bits. Ein RAM hat dagegen noch pro Bit einen Kondensator sowie Schreib-/Leseverstärker und die ganze Refreshlogik. Trotzdem waren zu dem Zeitpunkt RAMs schon billig 41256 RAM-Bausteine (256 KBit x 1) kosteten 9,90 DM, bei vier Anwendungen, jede war unter CP/M etwa 70 bis 80 KByte groß, hätte man 320 KByte Speicher benötigt, die Bausteine dafür kosteten als RAM rund (10 Stück) 100 DM, ich denke als ROM waren sie noch billiger. Vor allem aber bekommt ein Hersteller andere Konditionen für die Software oder kann sich Software sogar programmieren lassen, wie das bei Locoscript ja auch der Fall war. Selbst die für den Preisbeutel eines Heimcomputer zugeschnittenen Versionen von Word-Star, Dbase und Multiplan kosteten damals 199 DM pro Stück, PC Anwendungen lagen deutlich im Preis oberhalb von 500 DM. So war der Nutzen für den Kunden offensichtlich. Auch hier gibt es Vorbilder: Beim Sinclair QL gab es eine Softwaresuite zum Computer und die war ein wesentlicher Verkaufsanreiz.

Was wurde aus Amstrad?

Amstrad entwickelte die 8 Bit Serie weiter, es gab dann CPC 6128+ und andere verbesserte Geräte, später auch die Spielkonsole GX 4000, ebenso gab es eine 512 kb Version des PCW, später sogar mit 3,5 Zoll Laufwerken. Daneben bauten sie eine IBM PC kompatible Linie auf, die auch zum Kampfpreis vertrieben wurde. Was sie aber nicht fertigbrachten, war sich einmal von der ursprünglichen Hardware zu lösen und einen Mehrwert, wie ich ihn in meiner Konzeption geschildert habe, zu bieten. Selbst die GX 4000 Konsole kam noch mit einem 4 MHz Z80A – das war 1990. Zu dem Zeitpunkt war nicht nur die Z80H billig, es gab auch Nachfolgechips, die über eine integrierte MMU mehr Speicher adressieren konnten und weitere Befehle hatten z.b. für die Multiplikation/Division wie den HD64180 oder Z180.

Alan Sugar, Chef von Amstrad (der Firmenname ist eine Abkürzung von Alan Michael Sugar Trading) hat es nicht geschadet. Er hat heute ein geschätztes Vermögen von 1,4 Mrd. Euro und er wurde 2009 auch geadelt.

Kleine Notiz am Rande: Den Z80 gibt es immer noch, anders als andere Prozessoren dieser Zeit wie den 6502, 68000 oder 8086. Bei Reichelt kostet die 6 MHz Version mit 5,99 Euro aber doppelt so viel wie vor 34 Jahren … Das billigste Z80 System das man heute (neu) kaufen kann ist der Taschenrechner Ti 83.

Die mobile Version verlassen