Home Site Map Sonstige Aufsätze Weblog und Gequassel counter

Web Log Teil 576: 14.12.2019 -

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

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.

Ein zweite Investition wäre ein DMA-Baustein. Die Z80 DMA ist ein Spezial-IC die über mehrere Modi verfügt und darauf spezialsiert ist Bytes zu kopieren, soweohl vom Speicher zum Speicher wie auch vom Speicher zu einem Ein/Ausgabebaustein bzw. vom Baustein in den Speicher. Man muss dazu wissen das beim Kopieren von Daten es üblicherweise so zugeht:

Byte von Adresse1 in ein Register lesen

Byte vom Register an Adresse2 speichern

Adresse1 inkrementieren

Adresse2 inkrementieren

Zähler dekrementieren

Wiederholen wenn Zähler<>0

Die Z80 hat schon einen Spezialbefehl, der einen Transfer in 21 Takten schafft, der 8080 ohne diesen Befehl braucht dafür 71 Takte, trotzdem ist eine Z80 DMA nochmals um den Faktor 10 schneller und schafft das in 2 Takten. Der Nutzen ist schon bei einem Diskettenlaufwerk gegeben – die CPC hatten einen Skew von 2, das hießt die Zeit reichte nicht aus um in der Zeit die zwischen zwei Sektoren lag den Sektor von einem Puffer ins RAM zu kopieren. Schnellere Laufwerke die mehr als 250 kbit/s übertrugen waren auch nicht möglich, da reichte die Zeit in der Schleife nicht mal aus, ein Byte vom FDC einzulesen und sein Statusregister dann erneut abzufragen. Eine Festplatte wäre daher reine Geldverschwendung gewesen. Andere Einsatzgebiete gibt es bei der Verwaltung des Bildschirmspeichers, wie das schnelle Scrollen, bei dem fast der gesamte Inhalt kopiert werden muss. Eine Z80A DMA kostete zu dem Zeitpunkt 11,97 DM, zwar doppelt so teuer wie die CPU aber gemessen am Nutzen recht preiswert. Bei einer Verzehnfachung der Geschwindigkeit der Transfers würde auch eine Z80A DMA für eine Z80H CPU reichen (sie wird dann nur mit dem halben CPU-Takt betrieben).

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

6,85

7,93

1,23

Flieskommaberechnungen

66,66 / 79,02

34,6

67,59

39,11

Funktionen

67,82

59,93

117

56,39

Textausgabe

59,47

59,47

39,65

64,20

Grafikausgabe

21,85 / 43,05

6,89

7,89

6,59

Speichern

21,97 / 37

19,56

16,5

4,78

Zur Erklärung: ich habe die Benchmarks in einem Emulator laufen lassen und die Werte mit denen aus der Zeitschrift vergleichen. Bei den Fliesskommaberechnungen, Grafikausgabe und Speichern habe ich Unterschiede gefunden (Ct-Werte hinter dem /).

Der kompilierte Code kann bei Fliesskommaberechnungen, transzendenten Funktionen, der Textausgabe und Grafikausgabe mit einem IBM PC mithalten. Nur bei den Ganzzahlberechnungen 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

Selbst wenn man nur beim Textprogramm geblieben wäre, so wäre sogar primitives WYSIWYG möglich gewesen, wenn dieses aus dem ROM verschiedene Fonts genutzt hätte, die den Schriftschnitten (Fett, Italic, Unterstrichen – in der Kombination gibt es maximal 12 Möglichkeiten. Beschränkt man sich auf 128 Zeichen pro Font (96 nach ASCII genormte Zeichen und 32 Accente und Umlaute / Sonderzeichen) so hätte man dafür bei 8 x 8 Bit pro Buchstaben lediglich 12 KByte ROM benötigt, bei einem deutlichen Nutzen für den Anwender.

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.

16.12.2019: Der Commodore C128 – zu viel Computer

Als ich meinen letzten Beitrag über Verbesserungsmöglichkeiten des Amstrad CPC geschrieben habe, dachte ich auch an den Commodore C128, aber da der Artikel sowieso recht lange wurde habe ich mir ihn für diesen Beitrag aufgespart. Commodore Fans sind ja eine Klasse für sich. Alle naselang wird ein Beitrag von mir über den C64 in einem Forum herausgegraben und dann regnet es Kommentare. Es kann ja nicht sein, das am C64, dem zu seiner Zeit weltweit am meisten verkauftesten Computer irgendwas schlecht ist. Nun am C128 ist zumindest technisch wenig zu mäkeln.

Der C128 erschien fast zeitgleich mit dem Amstrad CPC 6128 und er war wie dieser einer der letzten 8 Bit Rechner die neu erschienen. Viele kamen mit 128 KByte Speicher, die aber meist nicht sinnvoll genutzt wurden, so beim erwähnten Amstrad CPC &128, aber auch beim Sinclair Spectrum 128 oder Atari 130 XE. Bei letzteren Rechnern war der Nutzen noch geringer, denn man konnte nicht mal CP/M laufen lassen. Beim Amstrad konnte man wenigstens unter CP/M den zusätzlichen Speicher sinnvoll nutzen.

Der C128 unterschied sich von den obigen Computern, denn er war ein Rechner, der eigentlich aus drei Rechnern bestand:

C128 Modus

Betrachtet man die Technik des C128, so hatte dieser eigentlich die meisten Kritikpunkte die ich bei meinem letzten Artikel monierte umgesetzt. Er sprach den Speicher über eine MMU an die auch fortschrittliche Z80 Derivate, wie der HD64180 boten. Eine MMU ist viel flexibler als das Bank-Switching, bei dem immer ein ganzer Block an geraden Blockgrenzen ausgewechselt wird. Unter BASIC waren von den 128 KByte die ersten 64 KByte für das Programm vorgesehen und die anderen 64 KByte für Variablen. Bei beiden gab es noch einen Abzug für den Stack und Sprungvektoren bzw. Memory Mapped I/O Adressen, sodass je 61 KByte übrig blieben – das ist bis auf 6 KByte der ganze Speicher. Das ist beeindruckend und ich keine keinen anderen Rechner, der so viel RAM frei hatte.

Der C128 hatte auch einen neuen Videoprozessor. Schon der VIC des C64 war gut. Er beherrschte Sprites und verwaltete als Videoprozessor den Speicher selbst, während Videocontroller wie er im CPC 6128 den Speicher nur ausgaben und die CPU sich um die Inhalte kümmern musste. Die Auflösung des 16 KByte großen Bereichs war schon beim Start mit 640 x 200 Pixel gut, wurde dann bei späteren Exemplaren immer besser, da der Videospeicher vergrößert wurde. Das war auch schon beim ersten Modell möglich, wenn man die Speicherchips ausgewechselt hat. Er hatte zudem einen 80 Zeichen Modus, den brauchte man, wenn man mit dem Rechner wirklich arbeiten wollte. Dann benötigte man aber auch einen Monitor, weil ein Fernseher diese Auflösung nicht packte. Der Videospeicher war aus eigenen VRAM-Chips aufgebaut und so vom Hauptspeicher getrennt.

Neben der MMU gab es noch einen weiteren Coprozessor für DMA-Zugriff. Den benötigte man vor allem beim Anschluss eines Diskettenlaufwerks. Die Floppys 1570 / 1571 (ein/zweiseitiges Beschreiben) waren deutlich schneller als die C64 Floppy. Bei der lag das daran, das Commodore zwar den Bus und die Elektronik von den größeren Laufwerken der CBM Serie übernommen hatte, aber von den acht Leitungen des IEC Busses beim C64 nur eine zum Rechner führte, sodass diese Floppy quälend langsam war. Die 1570 beschrieb Disketten einseitig und erreichte 3.000 Bytes/s, die 1571 doppelseitig mit 5.200 Bytes pro Sekunde im Burst-Modus. Wie bei vorherigen Rechnern hatten beide Floppys einen eigenen Rechner, obwohl Commodore auch einen FDC, den WD 1771 einsetzte. (ich möchte nicht meckern, aber mein CPC schaffte beim Kopieren bei einem Kopf eine bei zwei Köpfen üblicherweise zwei Spuren/s, was 4600 bzw. 9.000 Bytes pro Sekunde entspricht … und das ohne DMA-Chip). Das ROM war 64 KByte groß, wobei 16 KB auf das ROM im C64 Modus entfielen, 32 KByte auf den BASIC-Interpreter und 16 KByte auf den Kernel, BIOS und Monitor. Später gab es von Comomdore noch eine Maus zum Rechner und eine Windows ähnliche Umgebung namens GEOS.

CP/M Rechner?

Die Hinzunahme der Z80 CPU machte aus dem Commodore C128 einen CP/M Rechner, der mit 128 KByte Speicher auch CP/M Plus laufen lassen konnte, die neueste CP/M Version die aus dem 64 KByte nutzbaren Speicher eine sehr große TPA freischaufelte. Dafür gab es ein prominentes Vorbild. 1980 veröffentlichte Microsoft die Z80 Softcard. Sie war dafür gedacht das Microsoft den Apple II Markt für sich erschloss. Es gab von Microsoft nämlich keine Software für den Apple, alles war für CP/M entwickelt worden. Die Softcard enthielt einen Z80 Prozessor und einige Zusatzbausteine, mit denen er Zugriff auf den Apple Bus hatte. Er nutzte den Arbeitsspeicher des Apple.

Die Z80 auf dem C128 funktionierte nach demselben Prinzip. Beide Lösungen hatten eine Einschränkung: Da die Z80 den zweiten 6502/8502 Prozessor für die Ein-/Ausgabeoperationen nutzte und dieser nicht abgeschaltet wurde konnte die Z80 nur die Hälfte der Taktzyklen selbst nutzen und lief so mit 2 anstatt 4 MHz. Für den Apple erschienen daher bald Konkurrenzprodukte zur Softcard die eigenen Speicher auf der Karte hatten und eine schnellere CPU mit bis zu 6 MHz. Selbst wenn diese etwas teurer waren als die Softcard, die 1980 150 Dollar kostete – ein Achtel des Preises eines Apple II+, so war dies gemessen am hohen Preis des Apple II eine sinnvolle Aufrüstung. Aber 1985 war die Situation eine andere. 8 Bit Rechner näherten sich ihrem Ende. Neue Software für CP/M erschien kaum noch. Zudem war ein C128 billiger als ein Apple. Eine aufwendige Lösung mit eigenem RAM für die Z80 hätte den Preis des Rechners deutlich erhöht. Zum anderen gab es mit dem CPC 6128 ja einen Komplettrechner mit CP/M und nativ verbautem Z80A. Ein CPC 6128 kostete mit Monitor und einem Diskettenlaufwerk 1.598 DM. Der C128 kostete bei der Einführung 1198.-, dazu kam ein Laufwerk vom Typ VC 1570/1571 für 750 bzw. 950 DM. Mit eingebautem Laufwerk VC 1570, damit noch am ehesten mit dem CPC 6128 kostete der Rechner 1.785 DM, dazu kam für den Vergleich aber noch ein Grünmonitor, den es ab 300 DM gab. Zusammen wurde man also 2.085 DM los und damit ein Drittel mehr als beim CPC 6128, hatte dafür aber eine nur 2 MHz schnelle Z80 CPU. Kurz: wer von vorneherein plante CP/M einzusetzen, der kaufte sich keinen C128.

C64 Klon?

Kompatibilität ist ein zweischneidiges Schwert. Zum einen erschließt sich so ein Computer einen großen Softwarepool des vorherigen Modells – und der C64 war ein Verkaufsschlager, so gab es viele Software für ihn, wegen der schweren Programmierung, die von BASIC kaum unterstützt wurde, waren dies vor allem Spiele. Der Nachteil ist, dass man wegen der Kompatibilität von den neuen Möglichkeiten nichts nutzen konnte. Ein Nachteil, denn auch die oben erwähnten Konkurrenten aufwiesen. Der C64 wurde vor allem gekauft, um zu spielen. Mancher Teenager zog den Eltern zwar das Geld für den Computer aus der Nase, mit dem Argument er brächte ihn für die Schule oder um programmieren zu lernen, doch das BASIC, das von der rein textbasierten CBM Reihe unverändert übernommen wurde, unterstützte das Gerät kaum und programmieren war so für Leute, die es unter BASIC und nicht Assembler tun, wollten kein Spaß. Kurz: wer einen C64 haben wollte, kaufte auch einen C64, zumal der zu dieser Zeit mit unter 600 DM weniger als die Hälfte eines C128 kostete.

C128 Rechner?

Bleibt als wesentlicher Kaufgrund für den C128 sein Hauptbetreibmodus als 128-KByte-Rechner. Immerhin hat Commodore viel gelernt, und so das Gehäuse ergonomisch designt mit Tastatur und separatem Zehnerblock. Nach vorne abgeschrägt. Mit 80 Zeichendarstellung war er auch optisch gut fürs Arbeiten gedacht. Zum Verhängnis wurde dem Rechner sein spätes Erscheinen. Zu dem Zeitpunkt war schon der Atari ST erschienen. Er war zwar (mit Monochrommonitor und Floppy) mit 2.995 DM teurer als ein C128D mit Monitor, aber für den Mehrpreis von etwa 900 DM bekam man einen Rechner mit einer 8 MHz 16 Bit CPU, 512 KByte RAM und einem Monitor mit wirklich beeindruckendem Bild (und doppelt so hoher Auflösung). Ebenso sanken die Preise für PC-Kompatible immer weiter. Anfang 1986 erschien der Amstrad (Schneider) PC 1512, ein PC-Kompatibler mit 512 KByte RAM und einer 8 MHz 8086 CPU und einem Diskettenlaufwerk. Er kostete 1.998 DM und lag damit unter dem Preis eines äquivalent ausgestatteten C128. Die CPC-Serie als 8 Bit Konkurrenten habe ich schon erwähnt. So erschienen lange nicht so viele Programme zum Arbeiten für den C128 wie für diese Rechner was ihn für dieses Klientel unattraktiv machte. Angeblich sollen nur 20 Spiele für den C128 erschienen sein.

Übrig blieb ein Rechner mit einem komfortablen BASIC, das zwar schneller war als das des C64, aber nur um etwa ein Drittel schneller, trotz doppeltem Takt im C128 Modus, wahrscheinlich wegen des Bankswitchings bei jedem Zugriff auf Variablen- Damit lag der C128 in etwa gleichauf mit der CPC Serie, die ebenfalls ein schnelles BASIC mit Compretereigenschaften hatte und auch ähnlichen Komfort boten.

Für Commodore hatte der C128 aber einen bedeutenden Nachteil. An dem C64 konnte man zwar viel an der Hardware kritisieren, aber sie war einfach aufgebaut und der Rechner konnte billig produziert werden und lieferte im Verkauf gute Margen. Beim C128 hatte man zahlreiche teure Spezialbausteine verbaut, die MOS nur für diesen Rechner herstellte. Die Marge war immer niedriger als beim C64. So stellte Commodore die Produktion schon 1989 wieder ein – der C64 wurde produziert bis auch Commodore selbst, die Verluste mit dem Amiga einfuhr – 1994 ihren Betrieb einstellen musste. Der C128 war ein toller Computer, aber er kam zu spät, war zu teuer und war zwar „Drei Rechner in einem“, bediente aber die Bedürfnisse der drei Anwendergruppen nicht richtig. In der Historie muss man sagen, das nach dem C64 die 8-Bit Reihe bei Commodore chaotisch war und keines der erschienenen Geräte an den Erfolg des C64 anknüpfen konnte. Die Firma brachte 1984 den C16 und 116 heraus – Rechner mit 16 KB RAM und einer echten (C16) oder Gummitastatur (C116). Das war unsinnig – zu dem Zeitpunkt erschienen neue 8 Bit Rechner nur noch mit dem vollen Speicherausbau. Speicher war billig, der Preis des C64 sank so innerhalb eines Jahrs von 1.495 auf 700 DM, man konnte mit der Kastrierung des Speichers auf 16 KByte also wenig einsparen und der Markt für diese Geräte war extrem klein. Der Commodore Plus 4 war ebenfalls ein Flop. Bei ihm wurde das Entwurfsziel während der Entwicklung von einem billigen Einsteigergerät zu einem C64 mit eingebauter Software (Textverarbeitung, Tabellenkalkulation, Grafikprogramm) geändert. Das Problem: Als er 1984 erschien, war einer 1300 DM teuer, also doppelt so teuer wie ein C64. Die Software war aber schwierig zu bedienen und machte in Tests keinen guten Eindruck. Anders als der C128 war er zudem nicht kompatibel zum C64. Kurzum: der Plus 4 war ein Rechner, der teuer war, dessen Nutzen aber beschränkt war und der noch dazu mit der Software des C64 nichts anfangen konnte. 1986 wurden die letzten Exemplare verramscht.

Von den drei Rechnern verkaufte sich der C128 mit geschätzt 3 bis 4 Millionen Stück gut. Er konnte nicht an die Rekorde des C64 anknüpfen, liegt aber in einer Liga mit den Verkäufen des Amigas, Sinclair Spektrum und der CPC Serie, die auch alle bei 3 bis 4 Millionen liegen.

17.12.2019: Ein spätes Loblied auf die Diskette

Nach dem Kassettenrekorder war sie das Speichermedium der meisten Computer in den Achtzigern und auch Ursache für manchen Frust – die Diskette.

Die Diskette ist älter als die PC, sie wurde von IBM entwickelt, um leichter Softwareupdates auf Computer aufzuspielen. Sie war handlicher als Magnetbänder und es gab einen direkten Zugriff. Die Acht Zoll Disketten die IBM entwickelt hatte, waren aber, als ich mich mit Comutern zum ersten Mal beschäftigte, das war 1982 schon selten. 1975 hatte die Firma Shugart die Mikrofloppy entwickelt im handlicheren Format von 5,25 Zoll (heute müsste man, nachdem "Verbraucherschützer" das durchgesetzt haben, ja sie „133,35 mm Diskette“ nennen). Die setzte sich bei Mikrocomputern breit durch. Denn die Laufwerke waren viel kleiner. Zu einem anderen Vorteil komme ich noch. Ab 1984 kam dann noch die 3,5 Zoll Diskette hinzu, die mit einer festen Plastikhülle und einem Metallshutter, die zwar keine Floppy (also biegsam) war, aber robuster. Fortschritte in der Technologie erlaubten inzwischen auch die gleiche Kapazität wie bei den 5,25 Disks. Später kamen noch die HD-Formate hinzu, die mit dem IBM AT und der PS/2 Serie von IBM eingeführt wurden. Danach konnte kein weiterer Standard sich etablieren und die Diskette war auch für Softwareprogramme zu klein. Ich kann mich noch erinnern, dass ich als letztes Programm auf Disks mal Word Perfect für Windows installiert habe – das ganze Programm kam auf 24 Disketten. Etabliert haben sich nur wenige Standards:

Belegt waren Disketten beidseitig mit einer Magnetschicht. Die Unterteilung bezieht sich mehr auf die Laufwerke, die bei Single Sided eben nur einen Schreiblesekopf haben. Man konnte dann die Disketten umdrehen und die zweite Seite nutzen. Nur bei IBM kompatiblen Geräten gab es dann noch die HD Format mit 1,6 MByte und 2 MByte unformatierter Kapazität. Der letzte von IBM eingeführte Standard mit 4 MByte pro Diskette konnte sich nicht mehr durchsetzen.

Formatiert wurden die Disketten mit Sektoren von 128, 256, 512 oder 1024 Bytes, wobei die meisten Systeme 256 oder 512 Bytes verwendeten. Da es hinter jedem Sektor eine Zone ohne Daten gab, damit der Computer die eingelesenen Daten verarbeiten konnte und zu den Daten noch Verwaltungsinformationen kamen war die nutzbare Kapazität immer kleiner. Maximal konnte man auf einer Spur (6250 Bytes unformatiert) speichern:

Die ersten Disketten hatten nur 35 Spuren und waren hart sektoriert, das heißt, es gab in der Mitte eine Spur mit eine Reihe von Löchern, die den Sektoranfang markierten. Mit einer Fotozelle, die auch den Spuranfang detektierte, konnte so der Anfang jedes Sektors erkannt werden. Gängiger waren aber softsektorierte Disks, die der Hersteller nach eigenem Belieben unterteilen konnte. Hier erkannte man den Sektor an ID-Bytes. Dieses Format setzte 1982 aber nur noch Apple ein, die auch als eine der ersten Firmen eine Diskettenstation für ihren Computer auf den Markt brachten.

Wer einen Computer damals hatte, empfand Diskettenlaufwerke als langsam. Das Speichern dauerte, immer begleitet von den typischen schnarrenden Bewegungen des Schreib-/Lesekopfes. Wunschtraum war damals eine Festplatte, doch für die konnte man – zumindest wenn man einen Heimcomputer und keinen teuren Rechner hatte – genauso viel hinlegen wie für den Rechner mit Disketten selbst und auf eine 20 MB Festplatte, damals eine gängige Größe, passte auch nur der Inhalt von 30 Disketten.

Als ich mich in den letzten Tagen mit den beiden letzten Artikeln beschäftigt habe, wurde ich wieder dran erinnert. Ich habe mich zuerst gewundert, warum der C128, der 1985 erschien, noch eine 5,25 Zoll Diskettenstation hatte und diese Commodore-eigene Lösung mit einem eigenen Prozessor in der Floppy – wohlgemerkt zusätzlich zum Diskettenkontroller (FDC). Man konnte den auch durch den eigenen Prozessor ersetzen, wie Stephen Wozniak das beim Apple tat. Aber das war wohl der Kompatibilität zum C64 geschuldet, auch wegen dem Format, denn damals wurden in neuen Rechnern meist 3,5 Zoll Laufwerke verbaut. Die waren nicht nur kleiner, die Laufwerke waren auch etwas billiger.

Dann stolperte ich darüber, dass Commodore Werbung machte, das die neue Floppy so schnell sei, weil sie im „Burstmodus“ 3.000 bzw. 5.200 Zeichen pro Sekunde übertrage und das mittels eines DMA Bausteins und ich beschloss, mich dem Thema doch etwas mehr zu nähern.

Natürlich ist eine Floppy langsam. Die Spurwechselzeiten betrugen zwischen 3 und 40 ms. Die mittleren Zugriffszeiten lagen anfangs bei 463 ms und sanken bei den „normalen“ Formaten zum Ende hin auf 95 ms ab. Dass eine Floppy im täglichen Einsatz so langsam war, lag aber eher am Betriebssystem. Wenn man in eine Datei schrieb, dann aktualisierte jedes Mal wenn ein Block voll war (das waren meist 1 bis 4 KByte) das Betriebssystem die Verzeichnisinformationen, die auf den äußersten Spuren lagen und diese dauernde Reise hin und her kostete so viel Zeit. Wer eine Diskette nur kopierte, der merkte das ein Diskllaufwerk ganz schnell sein konnte, beim meinem System wurden dann 8 Spuren, so viel passten in den Speicher, in wenigen Sekunden eingelesen.

Schon damals beschäftigte ich mich mit den Floppies, wenn auch nur, um mehr als 40 bzw. später 80 Spuren zu nutzen – zwei, manchmal drei Spuren extra gingen nämlich drauf. Dazu musste man natürlich die Floppies selbst formatieren. Da stieß ich zum ersten Mal auf eine Eigenheit: den „Skew“. Die Sektoren waren nicht linear angeordnet, sondern bei meinem System in folgender Reihenfolge: 1,5,2,6,3,7,4,8,9.

Der Grund war relativ einleuchtend: Ein Sektor bestand nicht nur aus Nutzdaten. Es gab einige Verwaltungsinformationen, Prüfsummen etc., vor allem aber musste, nachdem ein Sektor lesen, oder geschrieben wurde, er verarbeitet werden. Der Normalfall war, dass das Betriebssystem einen festen Puffer für einen Sektor hatte und wenn ein Sektor in diesem Puffer war, so wurde er an die Stelle kopiert, wo er benötigt wurde. Eine Sequenz beim Z80-Prozessor dafür sah so aus:

    LD HL,Sektorpuffer
    LD DE,Zieladresse
    LD BC,Sektorlaenge
L1: LD A,(HL)
    LD (DE),A
    INC HL
    INC DE
    LD  A,B
    OR  C
    JP NZ,L1

Die Schleife L1 kopiert die Daten. Das Register A dient als Zwischenspeicher. Die meisten Befehle gehen dafür drauf, die Adressen zu inkrementieren und den Zähler zu dekrementieren und zu prüfen, ob der ganze Sektor kopiert ist. Diese Sequenz umfasst in der Schleife 71 Takte, mithin bei 512 Bytes und 4 MHz Takt 9 ms. Im 9 ms sind bei 300 U/Min und 6.250 Bytes pro Spur aber 284 Bytes am Schreib-/Lesekopf vorbeigeflogen. Die Lücke zwischen zwei Sektoren um dem Computer Zeit zu geben beträgt aber nur 103 Bytes. Beim 8080 dem Vorgänger des Z80 musste man damit leben. Der Z80 hat eine Spezialinstruktion, welche die obige Schleife ersetzt LDIR, die macht das in 21 Takten. Mithin schafft eine mit 3,8 MHz getaktete CPU, es gerade in der verfügbaren Zeit den Block zu kopieren. Dummerweise war es aber so das in meinem System alle Befehle auf ein vielfaches von 4 Takten gestreckt wurden, damit es keinen Zugriffskonflikt auf das Videoram gab. Das senkte den nominalen Takt von 4 auf 3,2 MHz ab. Das Programm war also mit dem Kopieren nicht fertig, als durch die Rotation mit 300 U/Min der nächste Sektor schon am Schreib-(Lesekopf vorbeikam, und verpasste diesen. Die versetzte Nummerierung glich dies zum Teil aus. Der nächste Sektor nach der 1 war die 5 und dann erst folgte die 2. So muste man nicht acht Sektoren warten, sondern nur zwei. Der Preis für diesen Skew von 2 war, das man für dass Einlesen einer Spur nicht eine sondern zwei Umdrehungen brauchte, die Datenrate also halbiert war.

Kleines Detail am Rande – die 16 Bitter hatten das gleiche Problem, nur bei Festplatten, die viel schneller rotierten. Die Platte in meinem Rechner war mit einem Skew von 3 formatiert worden. Ich experimentierte und merkte das man auch 2 nehmen konnte, wodurch die Lesegeschwindigkeit anstieg. Ein Skew von 1 war selbst mit meinem 10 MHz 80286 Rechner nicht möglich.

Nicht nur das – selbst das Einlesen eines Bytes vom FDC war für einen Mikroprozessor zeitkritisch: Hier die entsprechende Schleife für einen Z80:

    LD  HL,Sektoradr
    Ld  BC,Sektorlaenge
L1: In  A,(ADR1)  ; FDC Statusbyte lesen
    AND Mask      ; Bit maskieren
    JP  Z,L1      ; Wenn nicht gesetzt, Statusbye erneut holen
    In  A,(ADR2   ; Byte vom FDC lesen
    Ld (HL),A)    ; im Speicher ablegen
    Inc HL        ; auf nächste Adresse erhöhen
    Dec BC        ; Zahl der zu lesenden Bytes erniedrigen
    Ld  A,B       ; Vergleich ob BC=0
    or  C
    JP NZ,L1      ; wenn nein, dann nächstes Byte holen
    ret   

Sie dauert 63 Takte. Es stehen maximal 32 Mikrosekunden zur Verfügung (in den Fällen, in denen der FDC noch Prüfsummen bilden, mus sogar nur 23 Mikrosekunden. Das macht bei 63 Takten einen minimalen Takt von 2 bzw. 2,7 MHz. Das schaffte eine gängige CPU noch. Die höheren Datenraten die ein Minifloppy (8 Zoll Format) oder später das HD-Format lieferten (die Zahl der Spuren und die Rotationsrate blieben konstant, aber die Bytes pro Spur stiegen von 6250 unformatiert auf 10.000 bzw. 12.500) aber nicht mehr. Erst recht macht so der Einsatz einer Festplatte keinen Sinn, denn sie würde nicht schneller als ein Diskettenlaufwerk sein. Auch hier kann man die Schleife durch einen Spezialbefehl des Z80 noch optimieren.

    LD  HL,Sektoradr  ; Sektoradresse
    Ld  B,Sektorlaenge mod 256 ; Low Byte Sektorlaenge
    ld  e,Sektorlaenge / 256 ; High Byte Sektrolaenge
    ld  c,ADR2    ; Adresse FDC Datenbyte
L1: In  A,(ADR1)  ; FDC Statusbyte lesen
    AND Mask      ; Bit maskieren
    JP  Z,L1      ; Wenn nicht gesetzt, Statusbye erneut holen
    Ini           ; Byte vom FDC lesen, in (HL) schreiben, B decrementieren
    JP NZ,L1      ; wenn b=0 dann nächstes Byte holen
    dec e         ; High Byte Sektorlaenge dekrementieren
    JP NZ,L1      ; wenn b=0 dann nächstes Byte holen
    ret           ; zurück

Diese Version braucht 40 Takte, wenn nur die innere Schleife durchlaufen wird (bei 255 von 256 Bytes), sonst 54 Takte. Noch schneller ginge es, wenn der Abruf des Datenbytes ohne Abruf des FDC Statusregisters gehen würde. Dann kann man den Befehl INIR einsetzen, der die innere Schleife auf 31 Takte reduziert. Das setzt aber eine Hardwareverschaltung voraus, die den Prozessor anhält, solange kein Byte anliegt. Doch selbst mit INIR wird eine Z80 nie mehr als 190 KByte bei 4 MHz Takt lesen können. Eine Festplatte, wie der damals populäre Type Seagate ST-225 (20 MB formatiert) übertrug aber schon 625 kbyte/s.

Es gab eine Lösung für noch höhere Geschwindigkeiten das war der beim C128 von Commodore erwähnte DMA-Baustein. In all den oberen Schleifen entfiel auf das Einlesen vom Port oder das Kopieren von einer Adresse zur anderen nur der kleinste Anteil der Zeit auf die Kopieraktion.

Ein spezialisierter Baustein, die DMA ist dabei viel schneller. Beim Kopieren im Speicher erreichte Z80A mit 4 Mhz folgende Geschwindigkeiten:

Neben dem Kopieren von und zu schnellen Peripheriegeräten (Plattenlaufwerke, denkbar wären aber auch angeschlossene Silicondisks oder RAMDisks) kann man eine DMA auch zum Kopieren innerhalb des Speichers einsetzen, z.B. beim Bankswitching um Datenmengen zwischen den Banks schnell zu verschieben oder für das Verschieben im Grafikspeicher, z.B. beim Scrollen oder ziehen von waagerechten Linien / Füllmustern.

Leider wurde in fast allen Heimcomputern gespart, was die Ausstattung mit Peripheriebausteinen angeht. Jeder Mikroprozessorhersteller hatte eine Reihe von Zusatzbausteinen, die den Mikroprozessor unterstützten wie:

Von all den Bausteinen findet man, wenn man gängige Rechner aufschraubt, meist nur die PIO verbaut. Wird auch sie eingespart, dann ist meist ein ULA verbaut, denn würde der Prozessor auch noch die langsamen Geräte abfragen, er würde kein Programm mehr ausfuhren können. In Z80 Systemen übrigens (zumindest in denen die ich kenne) nicht die Z80 PIO, sondern das Intel Pendant 8255. Einfacher Grund: Die Z80 PIO hat zwei Paralellports, die 8255 drei wobei einer auch noch in zwei 4 Bit Ports (z.B. für zwei Joysticks) aufgeteilt werden kann. Manche Hersteller sparten dann auch noch den Videocontroller und Soundchip ein und integrierten die Funktion auch noch in ein ULA, so bei allen Sinclair 8 Bit Rechnern oder beim ORIC. Entsprechend zeigt sich, wenn man Preislisten dieser Zeit ansieht, eine Folge: Während die Mikroprozessoren laufend billiger wurden, blieb der Preis der Zusatzbausteine, obwohl die meistens technisch weniger komplex waren auf gleichem Niveau, weil die Nachfrage nur nach den CPUs viel größer war. In der Retroperspektive finde ich das etwas schade. Nicht alles ist sinnvoll. Zumindest in Deutschland mit den damaligen Regulationen der Post wird man nur wenige Einsatzmöglichkeiten für eine serielle Schnittstelle finden. Sie machte wohl eher einen Sinn, wenn man einen Drucker mit der seriellen Schnittstelle hat. Aber für einen programmierbaren Zähler, der in festgelegten Abständen ein Unterprogramm aufruft, fallen mir etliche Anwendungen ein. Vor allem der DMA-Chip hätte was genützt. Nicht nur weil man die Datentransferrate der Floppies (bei einem Skew von 2) so verdoppeln konnte, man hätte so erst die Möglichkeit für weitere leistungsfähige Peripherie geschaffen. Daneben kann man ihn für schnelle Kopieraktionen nutzen z.B. von einer Bank in die andere beim Bankswitching, beim Verschieben des Inhalts des Grafikspeichers (Scrollen), Linien Zeichnen, Füllen oder Bewegen von Spielfiguren. Das müssen nicht immer Blöcke sein. Die DMA hat auch einen Einzelbyte Modus. Selbst der ist aber mit 2 anstatt 14 Takten pro Byte noch deutlich schneller als die Z80 selbst.

Selbst RAM Disks sind so noch schneller. Denn eine RAM Disk hat die gleichen Einschränkungen, nur fällt die Wartezeit bei Skews oder bei Kopfbewegungen weg. Allerdings ist der Effekt kleiner. Den Unterschied von 190 kbyte/s zu 2 MByte/s merkt man bei einem Z80 System wo ein Programm maximal 64 KByte groß sein kann – mehr geht ja nicht in den adressierbaren Hauptspeicher nicht. Die RAM-Floppy sehe ich bei einem Z80 System als die die ideale Ergänzung an, auch weil man dann mit einem Floppylaufwerk auskam. Das Betriebssystem und Programme waren ja noch nicht so groß, als das man eine Festplatte brauchte. Ich hatte eine Speichererweiterung von Vortex in meinem System und das lief dann so ab: Nach dem Start von CP/M kopierte eine Batchdatei alles was ich zum Arbeiten benötigte – einige Dienstprogramme, Wordstar und Turbo Pascal in die RAM Disk. Danach kopierte ich von Hand die Sachen, die ich aktuell brauchte. Und bevor ich den Rechner ausschaltete dann wieder die geänderten Dateien zurück. Das habe ich nie vergessen. Schon ohne DMA war ohne Mechanik die Geschwindigkeit beeindruckend. Sie war ein Hauptgrund, warum ich mit dem Rechner bis 1993 gearbeitet habe.

Ich habe im CPC 6128 Artikel ja einen Benchmark aus der ct 1987 angeführt. In der Zeitschrift gab es auch Daten anderer Systeme. Das Speichern von 20 KByte in 1000 Zeilen dauerte ohne RAM Disk 16,5 sec, mit RAM Disk 2,38 s. Damit war der CPC schneller als jedes andere getestete System mit Diskettenlaufwerken, selbst teurere Rechner wie ein IBM AT, Amiga, Macintosh II und Atari ST wurden abgehängt. Selbst mit Festplatte waren nur wenige Systeme etwas schneller.

Dabei war Speicher billig. Als der CPC 6128 rauskam, kostete ein Floppy Disklaufwerk DS/SS etwa 360 DM, ein RAM Baustein von 256 KBit Größe dagegen 9,50 DM (Preis aus Anzeigen der ct 85/12). Das RAM für die 360 KByte die maximal auf eine Diskette formatiert draufgingen kostete also mit 104,5 DM weniger als ein Drittel des Laufwerks. Dafür kam man beim Arbeiten aber mit einem Laufwerk aus. So wäre, wenn der CPC 6128 als CP/M Rechner verkauft worden wäre, eine RAM-Aufrüstung auf 320 KByte (8 x 64 Kbit + 8 x 256 Kbit) oder gar 512 KByte ((16 x 256 KBit) sinnvoll gewesen – man hätte dann eine RAM-Floppy von 176 bzw. 448 KByte Größe gehabt. Die kleinere Floppy entspricht übrigens ziemlich genau der formatierten Kapazität des verbauten Diskettenlaufwerks von 180 KByte. Festplatten für den CPC erschienen dagegen erst relativ spät und waren ziemlich teuer. Bei CP/M für 8 Bit Rechner, das keine Verzeichnisse kennt, waren sie auch nicht sehr sinnvoll.


 

 

Sitemap Kontakt Neues Impressum / Datenschutz Hier werben / Your advertisment here Buchshop Bücher vom Autor Top 99