Die 8 Bit Spielkonsole

Eine der erstaunlichsten Dinge in den Achtzigern war, das massenweise Heimcomputer verkauft wurden, die aber primär zum Spielen verwendet wurden. Das führte sogar zu der Spiele Krise 1982/83, als viele Firmen, darunter Atari in finanzielle Bedrängnis gerieten, weil Heimcomputer ihre erste Konsolengeneration wie das VCS 2600 aus den Siebzigern um Längen schlugen.

Die Hersteller der Heimcomputer haben komischerweise nicht drauf reagiert,also selbst Konsolen produziert. Clive Sinclair regte sich auf, weil Leute seinen Spectrum zum Spielen nutzten und Commodore brachte erst 1990 eine Spielkonsole auf Basis des C64 heraus, als die 8 Bit Zeiten schon vorbei waren.

Es gab in den Achtzigern zwei Spielekonsolen, doch beide kamen aus Japan und waren erst viel später bei uns verfügbar. Zum einen die Nintendo NES mit eigener Hardware und das Sega Master System mit Standard Hardware wie dem Z80.

Ich will mal skizzieren, wie eine hypothetische Spielkonsole ausgesehen hätte, wenn sie von einem der Heimcomputerhersteller gekommen wäre, mit Standard-Hardware.

Vorteile einer Spielkonsole gegenüber einem Heimcomputer

Der grundlegende Vorteil ist, dass das System viel einfacher ist. Es ist nicht vorgesehen es groß zu erweitern, man benötigt eigentlich nur zwei Anschlüsse für Joysticks, einen für ein Modul und eben einen TV-Ausgang. Damit entfallen viele Stecker, Leitungen und das Platinenlayout wird einfacher. Man spart auch bei den Chips. Eine PIO, wie sie typischerweise benötigt wurde um die Tastatur abzufragen oder Daten vom Kassettenrekorder zu laden kann entfallen, das Abfragen der Joysticks oder Gamepads kann die CPU nebenher erledigen. Beim ROM entfällt der BASIC-Interpreter, der etwa die Hälfte ausmacht, wenn dort die Routinen für die Diskettenstation integriert sind, wie z.B. bei Commodore ist die Einsparung sogar noch größer.

Zudem kann die Tastatur entfallen. Die damaligen Konsolen hatten denn auch keine Tastatur. Das alles macht das System deutlich preiswerter, aber auch für den Kunden einfacher. Man muss keine Befehle mehr lernen, um ein Programm von Diskette zu laden. Alleine eine Tastatur kostete rund 100 DM in der Fertigung, wie der Preisunterschied zwischen dem C16 und C116 (normale / Gummitastatur) zeigt.

Systemarchitektur

Dreh- und Angelpunkt und größter Kostenfaktor ist die Videodarstellung. Es gibt prinzipiell drei Möglichkeiten das umzusetzen:

  • Die CPU macht alles selbst, unterstützt von einem Gate Array. So z.B. umgesetzt beim Oric oder den Sinclair Rechnern
  • Man setzt einen Videocontroller wie den Motorola 6847 ein, so z.B. beim Dragon, Tandy Color Computer, Video Genie
  • Man setzt einen Videoprozessor wie den TMS 9918/9 ff oder den VIC ein, so Commodore VC20 / C64, MSX Serie, Ti 99/4A.

Ein Videocontroller und -prozessor bietet verschiedene Grafikmodi, die man wählen und in gewissen Grenzen frei bestimmen kann und er liefert die Adresse des Bildschirmspeichers, deren Inhalt, die gerade an den TV Ausgang ausgegeben werden muss, tut das aber nicht selbst. Dafür benötigt man in jedem Falle eine Logik.

Ein Videoprozessor übernimmt auch die Ausgabe des Speichers an den Monitor und verwaltet den Speicher selbst, bietet zudem noch Sprites.

Da bei Konsolen der Preis noch etwas wichtiger als bei Computern ist, habe ich mich für die erste Möglichkeit entschieden. Die benötigte Funktionalität und das muss ja nur ein Grafikmodus sein, kann man in einem ULA ablegen, das ist bei der zu erwartenden hohen Stückzahl dann auch die billigere Lösung. Die vielen Möglichkeiten mehrere Modi sind bei einer Konsole irrelevant, die ja nur einen Modus hat.

Beim Zentralprozessor wird man, wenn man auf das Preis/Leistungsverhältnis schaut, zwangsläufig bei der Z80A landen.

Die grundlegende Systemarchitektur (ohne Bankswitching) wäre diese:

  • Ab Adresse 0: ROM (Bios, Kernel)
  • Darüber Grafikspeicher + Speicher für Daten des ROM / Moduls
  • Darüber bis FFFFH frei für Module.

Das hat den Vorteil, das Module bei einer fixen Startadresse beginnen und je nach Komplexität bis zu FFFFH gehen können.

Speicherfragen

Ich dachte zuerst an die Standardauflösung, die damals üblich war, das waren 256 x 192 Pixel in 16 Farben. Wie man leicht nachrechnen kann, benötigt man 4 Bit pro Pixel (16 Farben) damit 24 KByte für den Bildschirminhalt. Dazu käme noch der Bereich für die Arbeitsdaten der ROM. Der muss nicht groß sein, es sind ja vor allem Jump & Run Spiele ohne komplexe Spielszenarien, 2 bis 4 KB sollten da reichen. Das Sega Mastersystem hatte 8 KB RAM. Doch selbst mit einem nur 8 KByte großen ROM mit dem Betriebssystem sind so schon 34 bis 36 KB weg, was nur noch 18 bis 20 KB für das eigentliche Programm auf Modul übrig lässt und noch bedeutsamer – das mit Speicherbausteinen aufzubauen wird schwierig.

Speicherbausteine hatten damals vor allem eine 1-Bit-Organisation, man benötigte also immer 8, um ein Byte zu speichern. Bei den damaligen Typen 4116 (16 KBit) und 4164 (64 KBit) war eine Bank so automatisch 16 bzw. 64 KByte groß. Es gab auch die Organisation mit 4 Bit pro IC (4416 : 16 K x 4), doch auch damit war eine Bank immer 16 KByte groß.

Die für ROMs übliche Byte-Organisation hatten nur statische RAM (2114: 4 KBit, 6116: 16 KBit und 6264: 64 KBit), die dann „krumme“ RAM-Organisationen erlaubten, doch wie waren deutlich teuer, wie eine Recherche von Preisen der Zeit (1/185) zeigt:

Typ Organisation Preis pro Chip Minimale Bankgröße Preis pro 16 KB
2102 (SRAM) 1024 x 1 3,50 1 KB 448.-
2114 (SRAM) 1024 x 4 5,25 1 KB 168.-
4116 (DRAM) 16384 x 1 3,75 16 KB 30.-
4164 (DRAM) 64384 x 1 15,95 64 KB 127,6.- (64 KB)
6116 (CMOS-DRAM) 2048 x 8 14,70 2 KB 117,6 .-
6264 (CMOS-DRAM) 8192 x 8 89,99 8 KB 179,98.-

De Fakto ist Anfang 1985 die Ausrüstung des Speichers mit 4116 Chips die günstigste, nur belegt das RAM 32 KByte, also 24 KB für Grafik und 8 KB RAM. Eine Lösung ist, das die 32 KByte auch den Adressbereich des ROM abdecken, also praktisch 8 KB unbenutzbar sind.

Trotzdem muss man für die Daten noch etwas Speicher freischaufeln, denn die 24 KB des Bildschirmspeichers und 8 KB des ROM ergeben schon 32 KB. Es gibt zwei Lösungen. Zum einen kann man die Auflösung in beiden Dimensionen reduzieren: 240 x 180 lassen 2.976 Bytes frei, 227 x 170 sogar 5.281 Bytes. Der Nachteil: bei 256 Bytes pro Zeile kann man die Startadresse jeder Zeile einfach durch dreimaliges Shift nach Links ermitteln. Bei nicht durch 8 teilbaren Startdressen ist das komplexer.

Als zweite Lösung lässt man Zeilen bei der Darstellung weg. Pro Zeile gewinnt man so 128 Bytes. Die Reduktion von 192 auf 180 Zeilen also 1.536 Bytes.

Wenn das ROM nicht vollständig gefüllt ist und man die Routinen und Texte, die man beim einschalten braucht, an das Ende des ROM legt kann man es auch bis zu diesem Bereich (also weniger als 8 KB) ins RAM kopieren und dann nur mit dem RAM arbeiten, dann kann man hier noch einige Hundert Bytes freischaufeln.

Alternativen

Der populäre VDP TMS 9918/9 verwaltet sein eigens RAM, bietet Sprites, und kommt mit nur 16 KB für dieselbe Auflösung aus – er hat einen monochromen Bitmapspeicher und einen Farbspeicher für je 8 Bildpunkte, was die Größe des Bildschirmspeichers von 24 auf 12 KB absenkt. Der Nachteil: Nur Sprites werden „sauber“ bewegt, woanders gibt es Farb-Clash, wenn eine Figur von einem Achterbereich zum nächsten sich bewegt, so bekannt vom Spectrum, der sogar noch mehr Speicher einspart und einen Farbspeicher pro 64 Bildpunkte hat – anstatt 24 KB benötigt er so nur 7,5 KB. Da Spielfiguren aber Sprites sind, sieht der Benutzer das aber nicht.

Der TMS 9918/9 hat durch seinen eigenen Videospeicher den Vorteil, dass der Bildspeicher aus dem Adressraum herausfällt. Mit zwei 6116 kann man dann 4 KB Datenspeicher hinzunehmen und hat 52 KB für Module frei – dafür ist die Lösung aber trotz nur 20 KB Speicher genauso teuer wie 32 KB mit normalen DRAM. Dazu kommt noch der VDP, der deutlich teurer als eine Z80 ist.

Wenn es billig sein soll, dann wählt man folgende Konfiguration:

  • Hauptprozessor: Z80A
  • Soundprozessor: AY-8910
  • Auflösung: 240 x 180, 16 Farben
  • Speicher: 32 KB, davon 21 KB Bildschirmspeicher, 3 KB Datenspeicher, 8 KB vom ROM verdeckt
  • ROM: 8 KB
  • Maximale Modulgröße: 32 KB

Bank Switching

Eine einfache Spielkonsole nutzt gerade eben den 64 KB des Z80 Adressraum aus. Doch das Sega Master System mus Bank-Switching einsetzen, denn Module können weitaus mehr als 64 KByte adressieren. Sinnvollerweise wird man unten das ROM und das RAM einblenden. Das bedeutet die unteren 16 KB sind konstant. Darüber liegt, wenn das eingebaute ROM aktiv ist, der Bildschirmspeicher, oder, wenn das Modul aktiv ist, der Speicher des Moduls, das über entsprechende Routinen auch mehr als 48 KBN ansprechen kann. Gängig war damals eine Bankgröße von 16 KB, sodass man eine solche Bankbelegung aufstellen könnte:

16 KB Bank Start Modul eingesteckt Modulerweiterung
48 – 64 K Bildschirmspeicher (ROM) (ROM)
32 – 48K Bildschirmspeicher (ROM) ROM
16 – 32K BASISModulROM BASISModulROM
0 – 16K Eingebautes ROM + 8 K RAM ROM + 8 K RAM ROM + 8 K RAM

(ROM) heißt kann ROM enthalten, muss aber nicht, abhängig von der Modulgröße. Ein Modul enthält einen festen Bereich, das Basismodul das immer in der zweiten Bank leigt. Die oberen 32 K können dagegen durch Bankswitching gewechselt werden.

In diesem Szenario wäre der Bildschirmspeicher 32 KB groß, das reicht für 320 x 200 Pixel in 16 Farben. Im Prinzip könnte der Bildschirmspeicher auch 48 K groß sein, da er nur von dem Betriebssystem angesprochen wird. Dann würde sich eine QVGA-Auflösung (320 x 240 Pixel) anbieten. Viel höher würde ich nicht gehen, da die Ausgabe ja auf einem Fernseher erfolgt. Diese könnte dann mit 32 Farben erfolgen, wenn man eine etwas komplexere Adressierung des Bildschirmspeichers toleriert. Dann würde der Bildschirmspeicher 48.000 Bytes belegen, was den RAM-Bereich um 1.152 Bytes für das RAM lässt.

Spätestens ab 1985 ist es finanziell aktaktiver, anstatt RAM und Bildschirmspeicher aus separaten Chips zu fertigen einen 64-KB großen Hauptspeicher aus 4164 Chips vorzusehen und davon eben 8 kb für das eingebaute ROM nicht zu nutzen, da vom ROM verdeckt.

Abschätzungen

Die hypothetische Konsole ist teilweise über- und teilweise unterlegen dem Sega Mastersystem ebenfalls mit einer Z80A CPU. Diese hat auch ein 8 KB ROM, 24 KB RAM (davon 16 KB Videospeicher), doch die Auflösung ist besser (256 x 192 x 32 Farben zu 240 x 180 x 16 Farben im Modus ohne Bankswitching). Da diese Auflösung nicht in 16 KB Videospeicher unterzubringen ist (belegt 30 KB), wird das Master System wohl auch benachbarte Bildpunkte zusammen eingefärbt haben (bei 8 Bildpunkten pro Farbwert benötigt man 13,5 KB Bildschirmspeicher). Die hypothetische Konsole wäre in jedem Falle billig zu produzieren. Es bieten sich zwei Vergleiche an: Zum Sinclair Spectrum und VC 16/116. Der Sinclair Spectrum teilt einiges, so den Verzicht auf einen Videocontroller, Anschlüsse, sogar den Soundchip. Allerdings hat er einen BASIC-Interpreter und eine Tastatur, wenn auch keine gute. Mit einer Minimaltastatur und Gameportanschlüssen und einem Soundchip wäre er gut vergleichbar zum Sega System in der 16 K Version.

Ein zweiter Vergleich sind die Brüder VC 116 / 16 – sie unterscheiden sich nur in der Tastatur. Auch sie sind 16 K Computer, erschienen aber erst nach dem C64 im Jahr 1985. Sie sind Nachfolger des VC20, und wie dieser, mit zahlreichen Anschlüssen versehen, zudem einem BASIC Interpreter, der besser als der des C64 war. Leider war er zum C64 inkompatibel, und obwohl er auch einen Videoprozessor hatte, beherrschte dieser keine Sprites. C16 / 116 waren Flops, auch weil zu spät erschienen: 1985 kaufte keiner mehr einen Computer mit nur 16 KB Speicher (beim Spectrum der 1982 erschien, gab es anfangs eine 16 und 48 K Version, die 16 K Version wurde aber innerhalb eines Jahres eingestellt) und er war zu teuer: 398 DM, soviel kostete schon 1982 der Spectrum mit 16 K, doch seitdem hatten die Kosten für Halbleiter sich mehr als halbiert.

Würde die Konsole ab 1985 erscheinen, so wäre sicher die Version mit Banksitching eine bessere Lösung und langfristig auch billiger in der Produktion durch den uniformen 64 K RAM Bereich.

Für Softwarevendoren, aber auch die Hersteller selbst, gäbe es einen anderen Vorteil: Anders als Software auf Kassetten oder Disketten kann man Module nicht direkt kopieren. Die damals hohe Raubkopierquote wäre also niedriger, es würde sich für die Hersteller der Computer, die die Hardware selbst am besten kennen, daher lohnen selbst Module zu produzieren, das haben in der Regel die Hardwarehersteller nicht gemacht, aber durchaus die Hersteller der Spielekonsolen.

Vor allem könnten sie an ihren Erfolg und ihre Bekanntheit bei den Heimcomputern anknüpfen. Heute weiß jeder, was für Firmen Nintendo und NES sind – doch als ihre Konsolen herauskamen waren sie unbekannt, vor allem in Europa und Amerika, wo die Geräte auch erst Jahre später auf dem Markt auftauchten. Dagegen konnten Firmen wie Sinclair und Commodore, aber auch Atari auf ihrem Bekanntheitsgrad aufbauen.

2 thoughts on “Die 8 Bit Spielkonsole

  1. Das ColecoVision System wäre hier sicher auch interessant gewesen im Vergleich.
    Was die Module angeht: Der Raubkopiemarkt des C64 war voll von kopierten Modulspielen. Es war lächerlich einfach, das ROM auszulesen und einen Bootloader drumherum zu bauen, der den Inhalt an die richtige Adresse kopiert und startet. Als Kopierschutz haben die Spiele möglichst versteckt in den ROM-Bereich geschrieben. Das hat das Originalmodul natürlich nicht gestört, aber die RAM Kopie ging dann kaputt, wenn der Cracker diese Schreiboperationen nicht gefunden und entfernt hat.

    1. Ich sage nicht das man kein ROM kopieren kann, nur ist es eben aufwendiger als eine Kassette oder Diskette zu kopieren, man braucht zumindest einen EPROMER, das EPROM war damals auch nicht billig und auf der spielkonsole selbst geht das mangels Anschlussmöglichkeiten nicht. Dazu braucht man dann einen externen Computer und dann reden wir nicht mehr vom Tauschen von Spielen unter Schülern, sondern gewerbsmäßigen Kopieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.