Home Computer PC Hardware Site Map counter

Bits sparen, Videoprozessor und -controller

In diesem Grundlagenartikel geht es um Grafik, ihren Speicherplatz, ihre Erzeugung und Modi, sowie die Probleme die sie verursacht bei den Heimcomputern der Achtziger Jahre.

Speicherplatzbedarf

Ein 8 Bitter hatte mit 64 KByte nicht viel Speicher und selbst mit nur damals typisch 4 Bits pro Farbe konnte eine ansprechende Grafik dann schon einen größeren Teil des Arbeitsspeichers beanspruchen. Bei meinem Computer, CPC 464/664/6128 war der Grafikspeicher 16 KByte groß, also ein Viertel des Gesamtspeichers, was folgende Modi ermöglichte:

Im Allgemeinen ist der Speicherbedarf berechenbar nach PixelX × PixelY × ld(Farben)/8, wobei ld() der Logarithmus zur Basis 2 ist (1 bei zwei, 2 bei vier, 4 bei 16 Farben).

Viele Grafikprozessoren dieser Zeit trennten aber Bitmap und Farben um Arbeitsspeicher einzusparen. Es gab einen "Bitmap"-Speicher, der das monochrome Pixelmuster aufnahm und dessen Größe man mittels PixelY × PixelY/8 berechnen konnte und einen Farbspeicher, wobei aber mehrere Pixel jeweils die gleiche Farbinformation hatten. Üblich als Modi waren:

Konkret hieß dies: in 8 bzw. 64 Bit sind nur zwei Farben (Vordergrund / Hintergrund) erlaubt, aber in den nächsten 8 / 64 Bit wieder eine andere Kombination. Als ich das zum ersten Mal las, dachte ich mir "da hat aber jemand viel Aufwand betrieben, um auch noch das letzte Bit herauszuquetschen". Aber beim Nachdenken ist die Idee genial. Es geht ja bei der Grafik meist um zwei Anwendungen. Das eine sind Spiele und das Zweite sind irgendwelche Diagramme entweder geschäftliche oder Funktionsplotter. In Spielen hat man oft monochrome Muster oder feste Texturen wie Wände. Innerhalb eines kleinen Bereiches wechseln die Farben kaum. Ähnlich sieht es bei Nutzgrafik aus, egal ob Tortendiagramme. Balkendiagramme oder Funktionsplotter - wenn sie nicht schon, um die höchste Auflösung für eine Hardcopy zu haben, monochrom sind, dann kommen auch dort in einem kleinen Bereich maximal zwei Farben vor. Probleme sind nur Spielfiguren, die sich bewegen. Der C64 und TMS 9918 hatten Sprites, die vom Videoprozessor bewegt wurden, also konnte er auch die korrekte Farbinformation ausgeben. Beim Spectrum ohne diese Fähigkeit, aber mit einer noch gröberen Farbauflösung scheint Pixelsalat, wo Hintergrundpixel dann abrupt ihre Farbe ändern, üblich gewesen sein und auch das Vermeiden dessen ziemlich aufwendig. Der Lohn. Man kann viel Speicher einsparen. Hier mal eine Berechnung für 320 × 200 Pixel und die gängigen Farben (8 oder 32 Farben gehen nicht geradzahlig in ein Byte und erhöhen so den Aufwand beim Schreiben und Auslesen)

Auflösung

Farben

Jeder Punkt farbig

8 Punkte eine Farbe

64 Punkte eine Farbe

320 × 200

2

8 KByte

8 KByte

8 KByte

320 × 200

4

16 KByte

12 KByte

8,5 KByte

320 × 200

16

32 KByte

16 KByte

9 KByte

Der Spareffekt wird um so größer je mehr Farben man einsetzt, mehr als 16 Farben hatten die Heimcomputer nicht, doch wenn man damals schon 256 Farben gehabt hätte, man wäre mit 24 bzw. 10 anstatt 64 KByte ausgekommen. Für einen Computer also durchaus eine Option, vor allem wenn er Hardware animierte Spielfiguren hat, dann fällt das Einsparen von Bits meist nicht mal auf. Die Begrenzung der Farbzahl (256 Farben gab es erst mit dem Amiga und dem Vega Grafikstandard 1986/7) lag nicht nur am Speicherplatzverbrauch, sondern auch daran das die Signale damals digital über eigene Leitungen pro RGB übertragen wurden. Mit drei Leitungen für RGB und eine für die Helligkeit konnte man acht Farben in zwei Helligkeiten übertragen, zusammen also 16 Farben wobei Schwarz und Weiß dabei sind. Auf der PC-Plattform waren dies Schwarz, Weiß, Grau, Dunkelblau (Navy), Blau, Dunkelrot (Maroon), Rot, Dunkelgrün, Grün (Lime), Gelb, Orange, Türkis und dunkeltürkis (Seal), dunkellila (purple) und lila (magenta).

Das Einsparen von Bits gab es auch noch später. Beim Amiga nutzte man das RLL-Verfahren, das damals auch Festplattenkontroller nutzten. Anstatt jedes Pixel abzuspeichern, zählte das Grafik-IC, wie viele Pixel in einer Zeile dieselbe Farbe hatten, und speicherte Farbwert und Anzahl ab. Bei den typischen Bildern mit weitestgehend monochromen Flächen spart das enorm viel Speicher ein. Das Verfahren ist Basis des PCX-Bildstandards, das heißt, man kann es heute noch leicht ausprobieren. Nur wenn jemand ein Pixel An-Pixel-Aus Muster hatte, belegte das mehr Speicher als normal. Allerdings klappte das beim Amiga trotz schnellerem 68000 Prozessor nur, weil der Graphic-Prozessor ein spezielles ASIC war, das diese Funktion in Hardware verankert hatte.

Video Display Controller vs. Video Display Processor

Für die Ausgabe des Bildschirminhalts gab es damals drei Methoden:

Doch was sind die Unterschiede zwischen einem Video Display Controller und einem Prozessor?

Ein Video Display Controller ist nur dafür da die Anzeige zum Monitor zu schicken (für eine Ausgabe auf einen Fernseher musste man noch einen PAL-Modulator hinterherschalten). Er verarbeitet sie aber in keiner Weise. Die meisten VDC interpretieren die Information des Arbeitsspeichers nicht einmal. Sie generieren nur synchron zum Verlauf des Elektronenstrahls auf seinem Weg über den Monitor die Adresse, wo die Information gerade im Speicher steht. Das Auslesen dieser, die Generierung von Farben und Anlegen der Information an den Ausgang muss in jedem Falle noch eine Schaltung übernehmen. Bei meinem Rechner war das eine ULA die damit sie dies auch schnell genug tun konnte mit 16 MHz getaktet war, der Videocontroller war dagegen nur mit 1 MHz getaktet. Bei der CGA-Karte (Abbilddung) entfällt ein Großteil der Bausteine nur auf diese Schaltung.

Ein Video Display Processor verwaltet einen Speicherbereich selbst und er kann die Daten auch beeinflussen. Er generiert dann auch die gesamte Ausgabe, die bei einem VDC noch eine externe Schaltung übernehmen musste. In den Achtzigern hatten VDP noch keine Möglichkeit die Grafik selbst zu zeichnen, das musste nach wie vor der Hauptprozessor machen. Aber die populärsten VDP hatten die Fähigkeit Sprites zu definieren. Das waren "Spielfiguren" meistens maximal etwa 30 × 30 Pixel groß, die vom VDP selbst bewegt wurden. Er übernahm dabei eine wichtige Arbeit, nämlich das Restaurieren des Bildschirminhalts, nachdem ein Sprite einen Bereich überquert hatte, das entlastete den Hauptprozessor und der konnte sogar ein anderes Programm abwickeln und wurde vom VDP über einen Interrupt unterbrochen, wenn zwei Sprites kollidierten oder eines den Bildschirmrand erreichte. Für Spiele Entwickler, die ja oft kleine Figuren hatten, (man denke an Pac-Man oder einen Ball) war das eine tolle Eigenschaft. Die zweite wichtige Eigenschaft wurde weniger genutzt: da der Video Display Prozessor das RAM selbst verwaltete, konnte es unabhängig vom Hauptspeicher sein und belegte so keinen Platz. Bei dem knappen Speicher eines 8 Bitters ein Vorteil. Das hatte aber auch den Nachteil, das nun die Haupt-CPU nicht nur den Zugriff auf den Speicher abstimmen musste (das war auch bei VDC nötig, spezielles schnelles VRAM wurde damals in der Regel nicht verbaut) sondern nur über den VDP auf den Speicher zugreifen konnte, das heißt ihm beim Lesen erst die Adresse mitteilen musste und dann warten, bis der Video Prozessor die Daten ausgelesen hatte. Bei der MSX-Serie war das so, was für deren langsamen Bildaufbau mitverantwortlich war. Beim C128 hatte der VDP ein gemeinsam genutztes RAM, das aber separat vom Hauptspeicher war. Das absolut kurioseste Konzept war, das des Ti 99, der nur Video-RAM hatte und der Hauptprozessor dort seine BASIC-Programme ablegte.

Video Display Controller hatten andere Vorteile. Sie waren oft flexibler, was Grafikmodi betrag. Der Motorola 6845 konnte bis zu 512 KB RAM adressieren. Er wurde z.B. in der CPC-Serie verwendet (verschiedene Grafikmodi von 160 × 200 × 16 bis 640 × 200 × 2), der CGA (Textmodi bis 80 × 25, Grafik bis 320 × 200 × 4), Hercules Grafikkarte (nur monochrom bis 720 × 348). Sein Verwandter 6847, der nur 256 × 192 Pixel als Modus bot, ein Modus, den aber viele Heimcomputer hatten und eine Auflösung, die man auch auf einem Fernseher darstellen kann, wurde im Dragon, TRS-80, Atom Acorn eingesetzt.

Eine 8-Bit-CPU alleine hätte die Grafikausgabe nicht geschafft: Selbst bei einer Grafik mit 320 × 200 Pixeln und 4 Farben (belegt 16 KBytes) hätte sie bei 25 Bildern/s (PAL-Standard) 400 KByte pro Sekunde übertragen müssen - das schafft sie nicht, wenn man bedenkt, dass man jedes Byte zuerst in die CPU laden, dann an einen Ausgabeport schreiben muss, dann den Adresszähler erhöhen und vergleichen muss (Zeilensprung / neues Bild). Gemacht hat dies soweit ich weiß nur die 6502 im VCS2600 System, das daher nur eine geringe Auflösung von 40 Pixeln pro Zeile bot (aber aufgrund des Schreibens "on the fly" konnte jede Zeile anders aussehen). Bei einer so reduzierten Auflösung ging das noch.

Textmodus

Die meisten geschäftlich genutzten Computer, so die meisten CP/M Rechner, aber auch die ersten Computer überhaupt hatten nur einen Textmodus. IBM bot für den PC sogar zwei Grafikkarten an: eine grafikfähige, die Color Graphic Adapter (CGA) und eine nicht grafikfähige, den Monochrome Display Adapter)MDA).

Der Textmodus hat zwei wesentliche Vorteile: er spart Arbeitsspeicher und die Auflösung kann viel höher sein.

Beim Textmodus ist die Speicherung der Bildinformation und die Darstellung getrennt. Es gibt einen Bildschirmspeicher, der meistens für jedes Zeichen das sichtbar war, ein Byte vorsah. Für die damals gebräuchliche Auflösung von 80 Zeichen pro Zeile und 25 Zeilen auf dem Bildschirm also 2.000 Bytes. Fortgeschrittene Systeme hatten noch einen zweiten Speicher mit einem Attributbyte. Ein Attribut konnte sein:

Jedes Bit in dem Byte steht für ein Attribut, es ist 0 wenn keines angewandt wird. Wie man sieht, benötigt man für diese 5 Attribute, die kombiniert werden können, nur 5 Bits, wodurch noch drei übrig sind. Bestimmte Systeme nutzten dies, um mit den restlichen drei Bits verschiedene Fonts auszuwählen. Damit konnte man zum einen Schriften des Druckers simulieren, man konnte aber auch den nicht in den Attributen vorhandene Schriftschnitt Kursive durch einen Font einführen. Alternativ konnte ein Font auch nur Grafikzeichen enthalten, das lies dann eine höhere Grafikauflösung im Blockgrafikmodus zu.

Beim Victor 9000, in Europa als "Sirius 1" verkauft, sah das z.B. so aus:

Zeichen und Fontcode wurden zu einem 11-Bit-Pointer kombiniert, der so auf eines von 2^11 Zeichen = 2.048 verschiedene Zeichen (128 pro Font × 16 Fonts) zeigte.

Der grundlegende Vorteil war, das selbst mit einem Attribut pro Zeichen die Darstellung mit 4.000 Bytes für den Bildschirm auskam, 2.000 für die Zeichen, 2.000 für die Attribute. Besonders bei den 8 Bit Rechnern, die nur 64 KByte adressieren konnten, sparte dies wertvollen Arbeitsspeicher ein. Wenn ein Computer für die Textverarbeitung und Tabellenkalkulationen benötigt wurde, warum sollte man dann Arbeitsspeicher für Grafik verschwenden - es gab damals auch noch eine echte Trennung zwischen Heim- und Personalcomputer. Neben der Ausstattung (Heimcomputer wurden meist ohne Floppys verkauft, und bei manchen gab es sie auch nicht als Zubehör) war die Beschränkung auf 32 bis 40 Zeichen pro Zeile, dafür Grafikfähigkeit ein Merkmal der Heimcomputer. Bei 80 Zeichen pro Zeile hätte man selbst bei 8 × 8 Matrix ein Viertel des Arbeitsspeichers als Bildschirmspeichers benötigt (siehe oben).

Die Zeichen selbst saßen in einem ROM. Sie waren also nicht veränderlich, wenngleich manche Systeme die Möglichkeit boten, den Zeichensatz umzudefinieren, dafür musste aber ein Teil oder der ganze Satz dann ins RAM geladen werden, was die Einsparung von Speicher wieder zunichtemachte. Ein ROM ist aber erheblich preiswerter in der Fertigung als DRAM oder gar SRAM Speicher, das spart also Kosten.

Die obigen Videocontroller beherrschten auch einen Textmodus, indem sie für jede Adresse die sie synchron zur Bewegung des Elektronenstrahls generierten, noch eine Zeilenadresse generierten:

Ein Zeichen bestand aus einer Matrix, z. B. 8 × 8 Punkte. In dem ROM belegte jedes Zeichen 8 Byte. Das erste Byte nahm das Bitmuster der obersten Zeile auf, dann kam die nächste etc. Die an den Videocontroller angeschlossene Logik musste nun nur noch aus dem Speicher den Zeichencode holen, mit 8 multiplizieren (oder den Inhalt dreimal nach links im Register schieben) um die Adresse des ersten Bytes im ROM zu erhalten und dann die Zeilenadresse addieren. Dann hatte es das Pixelmuster, das es an den Ausgang anlegen konnte.

8 × 8 war ein gängiges Muster, oftmals war es aber feiner. Bedenkt man, dass Monitore wie Röhrenfernseher ein 4/3 Verhältnis in der Seite haben, so ist bei 80 × 25 Zeichen das Zeichen in der Vertikalen gestreckt, natürlich wären bei gleichem Pixelabstand also 80 × 60 Zeichen. Zwar sind, wenn man sich einen Buchstaben auf dem Papier anschaut, auch diese länger als breit, aber würde man das Verhältnis auf den Bildschirm übertragen, so müssten es dort 36 Zeilen und nicht 25 sein. Viele Hersteller verwandten daher eine höher aufgelöste Matrix für die Zeichen. Der einfachste Weg wäre es die Auflösung in der horizontalen zu verdoppeln, also eine 8 × 16 Matrix zu nehmen. Dann besteht jedes Zeichen aus 16 Bytes im ROM. Nur ist das schon wieder zu viel (bei gedruckten Buchstaben beträgt das Seitenverhältnis zwischen Höhe und Breite 5 /3), es sieht aber immer noch gefälliger aus als die 8 × 8 Matrix. IBM setzte bei der MDA-Grafikkarte eine korrekte Umsetzung des Seitenverhältnisses um: 9 × 14. Allerdings nur mit einem Trick: Im ROM selbst waren die Zeichen nur 8 Bits breit gespeichert, das letzte Bit war immer 0 (Zwischenraum) und wurde von der Elektronik erzeugt. Ein Zeichen belegte so 14 Bytes, ansonsten wäre das Auslesen aus dem Rom sehr kompliziert gewesen. Die MDA Karte hatte so eine theoretische Auflösung von 720 × 350 Punkten (9 × 80) × (14 × 25), kam aber mit 4 KByte Speicher aus. Die Hercules Grafikkarte, die dieselbe Auflösung hatte, aber neben dem Textmodus einen Grafikmodus bot, hatte dagegen einen Speicher von 32 KByte für das Bitmap der Zeichen. Selbst wenn man das ROM hinzunimmt, (weitere 3,5 KBytes) ist klar, dass die Textdarstellung viel Speicher spart.

Blockgrafik

Ganz ohne Grafik kam man aber nie aus. Selbst in Textanwendungen benötigt man einige Grafikelemente. Für Menüs oder Eingabemasken zum Abgrenzen von anderen Elementen z.B. Linien zum Umranden. Wer Diagramme zeichnen will, benötigt Flächen: leer, voll gefüllt oder mit einem markanten Bitmuster gefüllt und wenn man einen 3D-Effekt braucht, Diagonal nach hinten verlaufende Kanten. Wenn man aber genauer nachdenkt, so wird klar, das von den vielen Bitmustern, die möglich sind, man in der Regel nur wenige braucht. Selbst Spiele kommen oft mit einem aus wenigen Elementen bestehenden Hintergrund aus (sonst würde das Aufbauen und Erzeugen auch zu viel Zeit benötigen) und einer Spielfigur aus, die aber dann wiederum aus wenigen Pixeln, typisch kleiner als 32 × 32 Pixel besteht.

Im Bildschirmspeicher gab es pro Zeichen, das sichtbar war, ein Byte. Ein Byte hat aber 256 verschiedene Werte. Demgegenüber waren vom damaligen US-Standard ASCII nur 95 Zeichencodes definiert, das waren die Codes von 32 (Leerzeichen) bis 127 (Tilde ~). Die ersten 32 Codes waren für Steuerzeichen reserviert, mit denen konnte man den Bildschirm löschen, den Cursor positionieren oder andere Aktionen auslösen. Sie wurden für Terminals benötigt, wurden, obwohl man so Zeichencodes verlor, aber auch von Computersystemen übernommen. Der Grund: So konnte man eine Anwendung leicht an verschiedene Computer anpassen, indem man einfach in eine Tabelle eintrug, welches Codezeichen z.B. für die Cursorpositionierung stand. Viele Computer übernahmen auch einen Terminalstandard wie den des VT-52 Terminals. Aber ein Heimcomputer, der keine Anwendungen laufen lies, konnte auch diese 32 Codes von 0 bis 31 nutzen. In jedem Falle waren aber 128 Codes zwischen 128 und 255 frei. Dies nutzten die meisten Systeme um hier weitere Zeichen zu definieren, auch wenn das ROM so doppelt so groß war. Neben internationalen Zeichen, die man für andere Sprachen benötigten (es fehlten im ASCII-Zeichensatz alle Zeichen, die nicht Bestandteil des lateinischen Alphabets sind, wie die deutschen Umlaute, französische Accente etc. ), waren dies mathematische Operatoren wie das Integralzeichen ∫, griechische Zeichen die man oft in der Mathematik benötigt oder Währungssymbole wie das englische Pfundzeichen (der Dollar war selbstverständlich im ASCII-Code enthalten). Doch es blieben noch Codes übrig und die konnte man für das Zeichnen mit Zeichen, der Blockgrafik verwenden. Schaut man sich den IBM Zeichensatz an, so sieht man die Ausrichtung auf Verbesserung der Testdarstellung. Es gibt dort vor allem Symbole um einfache oder doppelte Rahmen zu ziehen, Flächen zu füllen, als Schatten unter Schaltflächen oder für Diagramme. Heimcomputer nutzten andere Symbole die man in Spielen benötigte, wie Männchen in verschiedenen Positionen oder verschiedene Smileys.

Heimcomputer wie der C64 zeichneten dann den Hintergrund aus Zeichen aus dem Zeichensatz (oder definierten diesen zum Teil neu, bei vielen Systemen war es möglich, das man z.B. nur die letzten 16 Zeichen neu definierte und die restlichen aus dem ROM holte und dann benötigte man nur für diese 16 Zeichen Speicherplatz. Wenn der Videodisplay Prozessor dann noch Sprites bot, wie dies beim VIC des VC-20 / C64 oder TMS-9900 der Fall war, dann konnte man den Hintergrund als "Textdarstellung" festlegen und das Sprite aus wenigen Pixeln wurde vom VDP bewegt. So kam der C64 mit nur 1.024 Bytes für den Bildschirmspeicher (Charaktercodes) und weiteren 512 Bytes für die Farbinformation aus - zusammen 1.536 Bytes (genutzt wurden nur 1.500, doch um die Decodierung zu vereinfachen, war der Rest unbenutzt). Bei einer 320 × 200 Pixel Auflösung mit 4 Bits pro Farbe (16 Farben) hätte er sonst 32 KByte Speicher benötigt.

Opfert man 16 Zeichencodes, so kann man in den Bitmaps von 16 Zeichen alle Bitmuster unterbringen, die man für eine Grafikdarstellung mit doppelter Zeichenzahl (160 × 50) benötigt. Bei 64 Codes wäre unter Verwendung der Asymmetrie von Seitenverhältnis des Monitors und Zeilenzahl auch 160 × 100 möglich. Bei 256 Codes (wenn man einen reinen Zeichenfont für Blockgrafik hat, möglich, wenn das System mehrere Fonts zur Auswahl bietet, wäre eine Grafik mit 320 × 100 Pixeln möglich. Allerdings sind dem Autor keine Systeme bekannt, welche die beiden letzten Optionen nutzen. 16 Codes für Blockgrafikzeichen wurden dagegen sehr häufig eingesetzt. (Die Zahl der Zeichen kann man berechnen nach 2^Pixel pro Zeichen horizontal × 2^Pixel pro Zeichen vertikal).

Einschränkungen

Wird Grafik an einen Monitor oder auch Fernseher übertragen, so sind das durchaus hohe Datenraten. 320 × 200 Pixel, 25 Mal pro Sekunde an einen PAL-Fernseher übertragen sind 1,6 MPixel pro Sekunde, die, selbst wenn man bedenkt, das man üblicherweise nur ein Byte ausliest und dann den Inhalt über ein Schiebregister an den Ausgang schiebt, bei 16 Farben, wie sie der C64 bot, 800.000 Auslesevorgängen pro Sekunde entspricht.

Das Problem: RAM Chips benötigen eine gewisse Zeit für einen Lesezyklus. Für die damals gängigen Typen 4116 (16 KBit × 1 Bit, typisch eingesetzt in Computern mit < 32 KByte Speicher) und 4164 (64 KBit × 1 Bit, typisch eingesetzt in Computern mit > 32 KByte Speicher) gab es folgende Eckdaten:

Zugriffszeit

Zykluszeit 4116

Zykluszeit 4164

 Zykluszeit 41256
100 ns     200 ns

120


220 ns

 220 ns

150

320 ns

280 ns

 260 ns

200

375 ns

330 ns

  

250

410 ns


 

Das grundsätzliche Problem ist nun, das sowohl die Schaltung zum Auslesen der Daten aus dem RAM wie auch die CPU auf das RAM zugreifen müssen und sie sich dabei nicht in die Quere kommen dürfen. Ein RAM Chip kann innerhalb der oben genannten Zykluszeit einen Zugriff beantworten, aber nicht zwei. Wenn sie einen alten Rechner aufschrauben und sich die RAMs ansehen, finden sie die Zugriffszeit (nicht Zykluszeit) auf den Bausteinen aufgedruckt als Endung "-15", "-20" oder "-25". Mein CPC 464 hatte z.B. Bausteine mit 150 ns Zykluszeit, der C64 und IBM PC welche mit 250 ns.

Bei einem Heimcomputer mit VDC war der Bildschirmspeicher Teil des Hauptspeichers und der war typischerweise aus obigen Bausteinen aufgebaut. Die Organisation mit 1 Bit pro Zelle bedeutete, das wenn ein Byte in den Hauptspeicher geschrieben wurde, je ein Bit in einem von acht Bausteinen landete. Bestand der Hauptspeicher aus 8 Chips (entspricht 16 KByte beim Typ 4116 und 64 KByte beim Typ 4164) so sind Zugriffsprobleme vorprogrammiert, und zwar bei jedem Zugriff, nicht nur wenn man in den Bildschirmspeicher schreibt.

Eine Lösung wäre es gewesen, andere RAM-Chips wie die Typen 4416 und 4464 (organisiert mit 4 Bit pro Zelle) zu verwenden: dann gäbe es nur einen Konflikt, wenn die CPU in den Bereich schreibt, in dem auch der Bildschirmspeicher liegt - bei 4 Bits pro Zelle sind das 4 KByte von 16 KByte oder 16 KByte von 64 KByte RAM. Alternativ setzt man statische RAM ein, die sind zwar erheblich teurer als dynamische RAM, bei ihnen ist die Zykluszeit aber genauso lange wie die Zugriffszeit. Ein 150 ns RAM wie das 6264 (8 KBit x 8 = 8 Kbyte) kann also über 6 Millionen Zugriffe pro Sekunde verarbeiten. Dafür kostete es im Januar 1986 im Einzelhandel 10,3 DM pro Baustein, während das 4164-150 mit der gleichen Kapazität und Zugriffszeit nur 2,80 DM kostete also um fast den Faktor 4 billiger war.

Es wurde jedoch meist eine andere Lösung gewählt. Bedingt durch das getaktete Auslesen parallel zum Übertragen der Information an den Ausgang war der Zugriff der Videohardware berechenbar. Die CPU und der Videokontroller mussten sich nun einfach abwechseln. Das ging, weil bei den damaligen Mikroprozessoren die Befehlsverarbeitung nach dem Schema Fetch - Decode - Execute verlief. In der ersten Phase (Fetch) wurde auf den Arbeitsspeicher zugegriffen, die anderen beiden erfolgten in der CPU. Das galt, auch wenn ein Befehl nochmals auf den Arbeitsspeicher zugreifen musste wie beim Schreiben oder Holen von Daten. Lediglich am Ende des Befehls konnten Decode und Execute entfallen, wenn man z. B. Daten in den Arbeitsspeicher schrieb, musste man nichts mehr decodieren und ausführen, sobald der Speicher die Daten akzeptierte. Wenn der Videokontroller nun immer in der zweiten Phase (Decode/Execute) auf den Speicher zugriff, dann gab es keine Probleme. Einleuchtend ist, das je länger ein Prozessor für Decodieren und Ausführen braucht desto mehr Zeit hat man für die Bildübertragung und desto mehr Pixel kann ein Bild umfassen. Relativ schlechte Karten hatte der 6502. Bei ihm machte Fetch die Hälfte des Befehlszyklus aus. Bei Rechnern wie dem C64 oder Apple war der 6502 daher niedrig getaktet mit nur 1 MHz, weil der Speicher mit einem 2 MHz Systemtakt abwechselnd vom 6502 und dem VDC/VDP angesprochen wurde. Rechner mit dem 6502 und höherem Takt hatten eine intelligentere Lösung, wie beim Atari 400/800 wo es einen eigenen Baustein für die Grafik gab, der die CPU anhielt, wenn es ein Problem gab, aber eben nur dann und nicht immer 50 % der Zeit beanspruchte oder der Bildschirmspeicher war separat (Commodore 128, Acorn Electron) und ein CPU-Zugriff wurde nur beim Schreiben/Lesen in den Speicher synchronisiert.

Besser war die Situation bei Prozessoren mit längeren Decode/Execute Anteilen am Befehlszyklus. Beim Z80 fand der Zugriff in den ersten 1,5 Takten eines 4-Takt Maschinenzyklus statt und beim 8086 waren es die ersten 2 von 8 Takten. Dann war es auch ohne die CPU herunterzutakten möglich, den Videozugriff in die verbliebenden 2/3 oder ¾ der Zeit zu legen. Bei diesen CPUs war es aber typisch, das Befehle unterschiedlich lang dauerten, also nicht Vielfache von 4 Takten. Bei einer Z80 benötigte im Instruktionsmix ein Befehl 6,8 Takte. Damit stimmte aber die Synchronisierung mit dem Videozugriff nicht mehr. Als Folge wurden Wartetakte eingefügt. Bei der CPC-Serie und den MSX-Rechnern waren alle Befehle ein Vielfaches von 4 Takten lang, das bedeutete das eine 4-MHz-CPU in einem CPC genauso schnell arbeitete wie ein 3,2 MHz Z80 ohne Bremse, man also 20 % der Geschwindigkeit verlor - und zwar in jedem Programm, nicht nur beim Bildschirmzugriff. Ähnlich ging man auch beim IBM PC vor. Doch dort nicht ohne Probleme. Bei der CGA Karte war es so das im höchsten Videomodus die Ausleserate der Elektronik durch die Bildwiederholfrequenz von 60 Hz praktisch die Bandbreite der RAMs beanspruchte. Schrieb nun die 8088 CPU in den Bildschirmspeicher, so verursachte das Störungen bis zum nächsten Bildaufbau "Schneegestöber" genannt. DOS legte die Schreiboperationen daher in die Zeit, in der der Elektronenstrahl am Zeilenende wieder zurückfuhr. Viele Programme schrieben aber direkt in den Speicher. Ebenso gab es ein kurzes Blinken, wenn die Hardware scrollte. Bei der zeitgleich vorgestellten MDA-Karte gab es das Problem nicht, da diese das Bitmuster aus einem ROM holte. Auf das ROM hatte die CPU aber keinen Zugriff und zudem hat dieses anders als RAM keinen Zugriffszyklus, sondern nur eine Zugriffszeit (nach dem Lesen und Schreiben muss ein RAM die Daten in den Zellen wieder auffrischen, da sie durch die Operation zerstört werden). Die Zugriffszeit ist aber um den Faktor 2-3 kleiner als die Zykluszeit.

Rechner mit Videodisplayprozessor und separatem RAM haben dieses Problem nicht, doch da das Schreiben in das RAM über den VDP viel länger dauert als der direkte Zugriff, hatten zahlreiche Rechner das RAM in den Hauptspeicher eingeblendet und damit auch den Zugriffskonflikt.

Eine Lösung war Multiport-RAM, das ab 1982 verfügbar war wie das TMS 4161. Dies war ein 64 KBit × 1 RAM mit zwei Ports über, die man mittels eines Signals umschalten konnte. Der eine Port war, der normale wie ihn der Prozessor benötigte mit wahlfreiem Zugriff. Der Zweite erlaubte nur sequenziellen Zugriff. In ihm wurde jeweils eine Spalte im Chip ausgelesen und in 256 Bit abgespeichert. Bei jedem Zugriff über den seriellen Port konnte ein Bit ausgelesen werden. Der Vorteil: Das konnte mit bis zu 25 MHz geschehen. Demgegenüber betrog die normale Zykluszeit 260 ns, was beim normalen Zugriff maximal 3,8 MHz Takt entsprach. Vor allem konnte nun aber die Video Display Hardware diesen sequenziellen Port nutzen und die CPU den normalen. Multiport RAM war aber signifikant teurer und zog erst ein, als man ohne es nicht auskam. Der Commodore C128 hatte solches, aber nur im Videospeicher.

Selbst bei Optimierung des Zugriffs war die Datenrate lange Zeit ein begrenzender Faktor. Bei meinem Heimcomputer dem CPC sah die Berechnung für die Zugriffe so aus: 63 Zeichen pro Zeile, je zwei Bytes pro Zeichen x 310 Linien x 50 Hz = 1,953,000 Bytes pro Sekunde. Aufmerksame Leser werden feststellen, das dies nicht mit der Auflösung des Computers korrespondiert. Die Betrug 40 Zeichen x 200 Linien: der sichtbare Teil war deutlich kleiner als der Bildschirm. Dieser Trauerrand um das Bild war typisch für Heimcomputer. Man setzte ihn ein, weil dei meisten Computer nur Änderungen am Bildschirminhalt durchführten, wenn der nicht sichtbare Teil gezeichnet wurde um Störeffekte ("Schneegestöber") zu verhindern. Als Signal diente die zum Monitor übermittelten Signal für horizontale und vertikale Synchronisation. Allerdings gibt es auch beim Fernsehen nicht sichtbare Ränder die dennoch Bandbreite beanspruchen - nur sind sie dort mit 14 % in der Horizontalen und 11 % in der Vertikalen kleiner.

Die Übertragung wurde so gelöst, das VDC die Adresse an ein Gate-Array vorgab, das pro Mikosekunde (4 CPU-Takte) zwei Bytes übertrug, insgesamt also 2 MBytes/s, was ziemlich genau der geforderten Datenrate entspricht. Dazu kam noch maximal ein CPU Zugriff in dieser Zeit. Entsprechend braucht man RAM mit einer Zykluszeit von 333 ns. Die verbauten 4164-150 hatten diese (280 ns Zykluszeit). Verdoppelt man die Auflösung die im höchsten Modus bei 640 x 200 Pixel lag auf 640 x 400, so benötigt man schon 4 Bytes pro Mikrosekunde, mit dem CPU-Zugriff sind es fünf pro Mikosekunde und man bräuchte RAM mit 200 ns Zykluszeit. So was gab es aber nicht, 100 ns RAM die es ab der 256 KBit Generation gab boten dies. Leider wurde normales RAM nur langsam schneller, Mitte der Neunziger lag die Zugriffszeit bei 60 bis 70 ns- Entsprechend langsamer wurde die Grafik auf der PC-Plattform besser, obwohl es dort das Problem das sie viel Speicherplatz beanspruchte nicht gab, denn die Karten hatten einen eigenen Grafikspeicher. Hier eine Übersicht über einige Grafikstandards und der Vergleich mit der Geschwindigkeitssteigerung der Prozessoren;

Jahr Grafikstandard Auflösung Prozessor Geschwindigkeit (8086=1)  
1982 Hercules monochrom 720 x 350 x 1 8086 8 MHz 0,5 (IBM PC 4,77 MHz)  
1984 EGA 640 x 350 x 16 80286 8 MHz 1,9  
1987 VGA 640 x 480 x 16 80386 16 MHz 8,8  

Während Prozessoren um den Faktor 9 schneller wurden, stieg die Grafikauflösung kaum an und die Datenmenge nur um den Faktor 4,9. Anders als bei Prozessoren nützte auch ein Cache nichts. Denn es wurde ein Wert ja niemals mehrmals benötigt sondern sequentiell der gesamte Bildschirmspeicher periodisch übertragen. Daher setzten die Grafikkarten ab Mitte der Neunziger Jahre spezielles Grafik-RAM ein, das für schnelles Auslesen optimiert war und die Features von Multiport-RAM integrierte. Das ist bis heute so. Die relativ hohen Monochrom Auflösungen bei den ersten Grafikkarten wie der obigen Hercules Karte, aber auch die hohe Auflösung des Victor Sirius waren übrigens nur möglich weil diese monochrom waren. Man nutzte aus, das Monochrommonitore, egal ob mit grüner oder bernsteinfarbener Beschichtung nachleuchteten und übertrug das Bild nur 24 oder 25 mal pro Sekunde anstatt den augenfreundlichen 60 bis 72 Hz.

Artikel erstellt am 4.1.2020, zuletzt geändert am 30.12.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.

© des Textes: Bernd Leitenberger. Jede Veröffentlichung dieses Textes im Ganzen oder in Auszügen darf nur mit Zustimmung des Urhebers erfolgen.
Sitemap Kontakt Impressum / Datenschutz Neues Hier werben / advertisment here Buchshop Bücher vom Autor Top 99