Home | Artikel | VCFe Video als visuelles Medium

VCFe Vortrag vom 2016.04.30 - Homecomputer und Spielkonsolen - Video als visuelles Medium


Inhalt

Einführung

Nachdem die Themen Logik und Prozessoren sowie Ein-/Ausgabe für Kommunikation und Benutzer nun erledigt sind, wären jetzt alle grundlegenden Komponenten von Rechnern behandelt. Damit wäre jetzt der Schritt von Komponenten zu Systemen zusammensetzen angebracht. Aber wie in 2011 mit dem Thema Forth, welches aus einer 6502 vs Z80 Debatte mit Hilfe von Benchmarks in Forth vergleichen entstand, wo ich dann die Forth Interna als Einschub brachte, kommt hier wieder etwas vergleichbares dazwischen.

Diesmal war es eine Atari 800 vs Commodore 64 Debatte, welche dazu führte dass ich den Atari genauer anschaute und detailiert mit dem mir bestens bekannten C64 verglich. Gefolgt von nach einem letztjährigen Vortrag noch mit den TMS9918 basierten Rechnern vergleichen, und dann auch gleich mit dem Nintendo Famicom/NES. Weil dieses Jahr gerade das Thema Medien ist, werde ich als Übergangsphase nochmals Video anschauen, aber diesmal nicht aus der Perspektive von "wie funktioniert die Hardware" sondern von "wie benutzt es ein Graphiker bzw Programmierer in Software", genauer als "was kann dieser damit anstellen". Dazu werde ich vor allem Videomöglichkeiten von ein paar guten als Spielkonsolen designten Homecomputern als visuelle Medien vergleichen, mit der Vollständigkeit halber auch alle anderen verbreiteten farbigen Rechner als Randnotizen dazugenommen.

Heute sind wir uns im PC Zeitalter gewohnt, dass auf einem Bildschirm beliebiges angezeigt werden kann, auch Photos oder gar Videos, egal ob mit einer Kamera aufgenommen, oder im Rechner gerendert. Dies setzt aber hohe Ansprüche wegen Bilddatenmenge an einen Rechner, sowohl was den Speicherplatz wie auch insbesondere die Speicherbandbreite anbegeht. Dies wurde erst Ende 1980er bis Anfangs 1990er generell machbar. Etwa ab der 1988er IBM VGA Karte ihrem MCGA Modus mit dessen 320x200 8bpp (braucht 64k) wurde dieser Ansatz benutzbar (wie in vielen damaligen Spielen gesehen). Ab SVGA 640x480 8bpp (braucht 300k) wurde er auch komfortabel, weil 8bpp für RGB 6*6*6=216 Farben oder RRGGBBII 4*4*4=64 Farben in 4 Helligkeitsstufen tauglich ist. Ab 800x600 16bpp (braucht 960k) wurde er dann ausgereift, weil 16bpp für RGB 32*32*32=32768 Farben tauglich ist, und 800x600 etwa volles PAL 567i Fernsehbild ist. Somit sind 320x200 bis 640x480 die untere Grenze an für beliebiges brauchbarer Auflösung.

Alle Rechner mit nur 4/8/16/32k an Videospeicher liegen darunter, und sind daher für selbst ein 320x200 8bpp Bild nicht nutzbar! Dies betrifft insbesondere alle 8bit Rechner, deren Prozessoren ohne MMU nur insgesammt 64k Speicher adressieren können, für System plus Programm plus Daten plus Bild. Zum Glück muss ein Bild aber nicht ein volles Photo sein, wie es Jahrzehntausende an Erfahrungen mit Zeichnungen zeigen, welche weit weniger detailiert sind. Dies indem nur Entscheidendes abgebildet wird, das was es braucht um einen visuellen Eindruck zu hinterlassen. Alle vor 64k (und selbst viele vor 256k) Videoausgaben nutzten dies aus, um mit weniger Details trotzdem ausreichende Effekte zu erzielen.

Genau wie man beim Zeichnen aber wissen muss, wie man mit dessen gestalterischen Limiten und Möglichkeiten umgeht, wie man das Entscheidende trotzdem trifft, mussten auch Spielkonsolen und Homecomputer Videochip Designer dies wissen, Systeme entwickeln welche aus weniger Daten ein volles Bild generieren, ohne dass ihre Mechanismen unzureichend werden oder gar in den Weg geraten. Aber ebenso mussten alle auf diesen Rechnern gestaltenden Graphiker und codierenden Programmierer dies wissen, damit sie die gebotenen Mechanismen ausnutzen konnten. Dieser Vortrag beleuchtet genau die dazu relevanten Eigenschaften, und wie damit umgehen. Dabei liegt der Fokus vor allem auf Spielszenen und bewegten Objekten darin, weil das die grössten Ansprüche am Graphik stellt, und somit einen kritischen Test abgibt. Aber auch Text editieren muss effektiv gehen, und sei das nur um Programmcode und Obejktdaten der Spiele in den Rechner einzugeben!

Die Spielregeln

Zuerst einmal die Auswahlkriterien welche Rechner hier überhaupt angeschaut und verglichen werden. Weil es hier um Videoausgabe als graphisches Medium geht, scheiden alle ohne eine passende Graphik komplett aus:

Es verbleiben damit vor allem farbige Homecomputer (plus ein paar Videokarten), welche interessanterweise fast alle entweder auf TTL Logik basieren, oder Videochips haben welche eigentlich für Spielkonsolen designt wurden. Daher werden auch dedizierte Spielkonsolen als solches hier addiert.

Die Kontrahenden

Als nächstes kommen die Eigenschaften der beteiligten Rechner nach ihrem Erscheinungsdatum geordnet:

Cromemco TV Dazzler (1976)

Kein Rechner, sondern ein Paar vom Karten (Digital bzw Analogteil) für S100 Bus Rechner (wie dem MITS Altair 8800 von 1975). Früh erschienen, daher alles reine TTL Logik, keine VLSI Chips, dementsprechend primitiv.

Nur 4 Bitmap Modi, weil technisch einfacher als Textmodi oder gar Zellmodi. Kein eigenes RAM, um solches mit dem restlichen System zu teilen, um Kosten zu sparen. Es sind auch so schon 2 Karten Digital und Analog. Braucht wegen Timing aber SRAM, was damals mit 1kx1 SRAMs nur 1k mit 8-Chip, bzw 2k mit 16-Chip ergab.

Bitmap daher nur in 2 Grössen von 0.5k oder 2k Speicher umschaltbar, kombiniert mit 2 Darstellungen 4bpp "normal" sowie 1bpp "X4". Ergab Auflösungen von nur 32x32 oder 64x64 in 4bpp, sowie 64x64 oder 128x128 in 1bpp. Farben bei 4bpp sind bereits volles 2*8=16 RGBI, sowie bei 1bpp Schwarz+1*RGBI-Register, aber selbst 64x64 ist sehr geringe Auglösung für Spiele.

Selbst bei 128x128 1bpp erlaubt dies aber nur gerade 32x16 Zeichen mit einem 4x8 Font, bzw eher sogar 20x10 mit dem damals gewohnten 6x12 Nadeldrucker Font, also auch sehr geringe Textmenge um Programme oder Daten einzugeben, was nach einem separaten Terminal verlangte. Daher fast nur als Kuriosität nutzbar. Und um zu zeigen wie man von obiger unterste 64k auf 2k oder gar 0.5k herunterkommt: Durch massiv die Auflösung reduzieren und wenige Farben anbieten, oder etwas weniger Reduktion aber fast gar keine Farben mehr.

Processor Technology VDM und Sol-20 (1976)

Die VDM ist kein Rechner, sondern ebenfalls eine S100 Bus Karte. Der Sol-20 ist dagegen ein vollständiger Rechner, mit einer VDM eingebaut, wenn auch als intelligentes Terminal vermarktet. Ebenfalls früh erschienen, daher alles reine TTL Logik, keine VLSI Chips, dementsprechend primitiv. Trotzdem aber mit vollen Textmodus, weil eben ein Terminal.

Dieser 1 Textmodus hat 64x16 Zeichen. Mit 9x13 Font (7von9 breite Zeichen). Aus festem ROM Satz, von 128+revers Zeichen, mit neben 96 ASCII auch 32 Graphikzeichen drin. (Es verwendet einen 6574 oder 6575 (128*9)x(7von9) Font ROM. Ersterer mit einem etwas inkonsistenten Satz von Graphikzeichen, zweiterer mit ASCII Steuerzeichen Kurzcodes.) Damit anstelle eines Terminals nützlich für Programme oder Daten einzugeben, aber zu limitiert um Spiele zu machen. Dies zeigt wie man zu Auflösung mit wenig Speicher kommt, durch wenige Zeichennummern per Font in mehr Pixel übersetzen, aber zum Preis von wenigen festen Pixelmustern.

Apple II (1977), und II+ sowie IIe

Nachfolger des Apple I. Dieser hatte nur Text, 40x24 Zeichen, mit Font festem ROM Satz, von 64 Zeichen, keinerlei Graphik, aus 1kx6bit MOS Schieberegistern als Videospeicher und somit nicht adressierbar. Dieser war alles eine erweiterte Variation des Don Lancaster TV Typewriter von 1973, der nur 32x16 Zeichen hatte, mit selbigem Font.

Der Apple II war vor allem Ersatz der MOS Schieberegister durch einen 1kx8bit Ausschnitt vom DRAM Hauptspeicher. Ebenfalls früh erschienen, daher alles reine TTL Logik, keine VLSI Chips, dementsprechend primitiv. Trotzdem aber umschaltbar 3 Modi, Text und Blockgraphik und Bitmap:

Dies zeigt einen besseren Ansatz, mit flexibel sein durch Modi umschalten, entweder Font aber limitert (wie beim Processor Technology VDM), oder Bitmap mit Farben aber geringe Auflösung (wie beim Cromemco TV Dazzler), oder Bitmap und Auflösung mit etwas Farben aber grossem 8k Speicherbedarf.

Commodore PET 2001 (1977), und CBM Serie

Früh erschienen, alles reine TTL Logik, keine VLSI Chips, und billig, dementsprechend noch primitiver. Hat nur 1 Textmodus. Text 40x25 Zeichen. Mit 8x8 Font. Aus zwei festen ROM Sätzen von 128+revers Zeichen (wie beim VDM und Sol-20). Diese haben neben 64oder96 ASCII auch 64oder32 Graphikzeichen drin. Inklusive 16 für im Font integrierte mischbare 2x2 Blockgraphik (gibt 80x50), und viele andere Graphikelemente. Die beste Pseudographik, weil auch noch einen zweiten Satz Zeichen ohne Kleinbuchstaben für mehr Elemente. Nur Schwarzweiss, auf dem eingebauten Spezialmonitor. Reicht als Terminal um Programme oder Daten einzugeben, aber auch gerade noch brauchbar für einfache Spiele. Dies zeigt einen anderen Ansatz, mit Font aber weniger limitiert wegen Graphikzeichen.

(CBM Serie 3000er von 1979 sind leicht überarbeitet für mehr Speicher. 4000er und 8000er von 1980 haben noch mehr Speicher, sowie MOS6545 Timing Chip (eine Variante des MC6845) und grösseren Monitor. 8000er sind dabei Modelle mit 80x25.)

Tandy TRS-80 (1977)

Früh erschienen, alles reine TTL Logik, keine VLSI Chips, und billig, dementsprechend auch sehr primitiv. Hat 2 Textmodi. Text 32x16 oder 64x16 Zeichen (letzters wie bei VDM und Sol-20). Mit ?x? (unbekanntem) Font (sieht auf Photos nach 6x12 aus). Aus festem ROM Satz, von 64 (oder angeblich auch 96) ASCII Zeichen (je nach ob mit 7bit oder 8bit Videospeicher laufend). Dazu vom achten Bit gesteuert ohne Font hartverdrahtete aber mischbare 2x3 Blockgraphik (gibt 64x48 bzw 128x48). Nur Schwarzweiss, auf dem separaten Spezialmonitor. Wie obiges reicht als Terminal um Programme oder Daten einzugeben, aber auch etwas weniger brauchbar für einfache Spiele.

Atari VCS/2600 (1977)

Reine Spielkonsole. Ein Schritt aufwärts, zu Prozessor und Module benutzen, statt nur hartverdrahteter Pong (und Derivate) Logik. Chip TIA (Television Interface Adaptor), für Video und Sound und Paddles und Feuerknöpfe, dementsprechend primitiv. Hat nur 1 Bitmapmodus, wegen einfacher als Textmodi und auch passender für Spiele.

Aber dies trotz extrem wenig Speicher, von nur 128 Bytes. Das Bitmap ist sogar nur 40x1(!) 1bpp, genauer sogar nur 20 Pixel/Bits an chipinternem Videospeicher von (4+8+8=20)bit in 3 Register in der TIA, welche 2mal pro Zeile ausgegeben werden, das zweite mal wiederholt oder gespiegelt. Alle Zeilen werden identisch wiederholt, was nur vertikale Streifenmuster ergibt, ausser die Software überschreibt vorzu die TIA Register! Dafür ist zwecks synchronisierung die aktuelle Zeilennummer auslesbar, sowie der Prozessor bis zum nächsten Zeilenanfang per Waitstates pausierbar.

Dazu Sprites, 2 Player 8x1 1bpp (8bit Register) in horizontal 160/80Pixel Raster, sowie 2 Missile und 1 Ball 1x1 (3 2bit Register) als horizontalen 160/80/40/0Pixel Block, alle auf 160er positioniert. Wieder alle Zeilen identisch ausser von Software überschrieben oder gar ausgeschaltet. Damit war er der erste Rechner mit Sprites, wenn auch diese von Atari Player Missile Graphics (PMG) genannt werden.

Farben mit Register auswählbar aus 16*8=128 (16 NTSC Farbtöne "Chroma", und explizit 8 Helligkeitsstufen "Luma"), und damit eigentlich völlig überdimensioniert. Hat 2 Register für Bild/Spielfeld Vordergrund und Hintergrund, 2 für die 2 Player+Missile, 1 für denn Ball, zusammen 5.

VCS Spiele ihre Software besteht wegen alle Zeilen gleich sein vor allem daraus, die Zeilen Pixel sowie Player Muster und Missile/Ball Breite/Aus während dem Bild zeichnen vorzu umzuschreiben, sowie zwischen den Bildern die Joysticks bzw Paddles abzufragen und mit der Spiellogik auszuwerten inklusive Sprite Positionen setzen. Dies zeigt einen weiteren Ansatz, Auflösung trotz fehlendem Speicher, durch horizontale Auflösung mit Sprites verbessern und vertikale Auflösung in Software implementieren, sowie viele Farben trotz nur 1bpp (plus Spreites) mit Farbregister übersetzen. Es ist damit brauchbar für Spiele, aber total unbauchbar als Terminal, kann nur anderstwo entwickelte Spiele ablaufen lassen.

Atari 800 (1979)

Anfangs als Spielkonsole designt, als "etwa verdoppelten" Nachfolger der VCS/2600, weil dieser wegen primitiv sein zurecht auf nur 3 Jahre benutzbar angenommen wurde. Aber 1978 von Management geblockt, um das bestehende "ausreichende" Produkt nicht zu konkurrenzieren. Dann das Design als Homecomputer 800 recyclet und erweitert (plus ein weniger-RAM plus Folientastatur Subset 400). Dann doch noch 1982 als Konsole 5200, aber nicht zu den 400 und 800 kompatibel (und auch nicht zum VCS/2600). Dann 1983 verbilligt zu 800XL (und Subset 600XL). Zum Schluss noch 1985 umgestylet als 65XE (und speichererweiterte 130XE). Dann kam 1986 eine 5200+2600+neueres Kombination als 7800 Konsole. Aber die wurde nach Firmenaufkauf bereits 1987 durch die XE basierte und damit inzwischen schwächere XEGS ersetzt, was Atari bei den Spieleherstellern endgültig diskreditierte, und so allen späteren Systemen jegliche Unterstätzung kostete. Tod durch Kopfschuss per Management.

Zwei Chips CTIA/GTIA (Color Television Interface Adaptor, für eine einst geplante bessere Bitmap Konsole) und ANTIC (AlphaNumeric Television Interface Controller, mit Textmodi bzw eben Zellmodi weil addiert zu einem Homecomputer), sowie für nicht-graphisches POKEY (Paddles plus Tastatur plus Sound plus UART), alle 3 zusammen die kleinere TIA im VCS ersetzend, und damit weit mehr leistend. Umschaltbar (wie beim Apple II), aber hier massive 8 Bitmapmodi und 6 Zellmodi:

Die Bitmapmodi sind zwischen verschiedenen Auflösung und bpp und Speicherverbrauch abgestuft (wie beim Apple II Block vs Bitmap):

Bei 320*1 oder 160*2 oder 80*4 oder 40*8 von 14.318/2=7.16MHz Pixel ein 44.7µs breites Textfeld (Narrow 256 mal ein 35.8µs schmales, Overscan 384 mal ein 53.6µs überbreites). Bitmap "F" mit Farben auf Schwarz und Weiss mit 0% und 100%, und dem 7.16MHz Pixeltakt, erzeugt auf NTSC Farbmonitor 4 Farben wie beim Apple II. Dies versagt aber auf PAL Farbmonitor, weil dieser dazu 17.734/2=8.867MHz bräuchte. Europa Apple II haben einen NTSC zu PAL Umwandler drin, der dieses Verhalten aufrecht erhählt, Atari 800 aber nicht, weil obige offiziellen Farben aus spezifischen NTSC und PAL CTIA Chip Versionen kommen. (Aber trotz 1bpp hat letzteres nur "1.5" statt 2 Farben, genauer einen "Chroma" Farbton in 2 "Luma" Helligkeitsstufen. Was die verfärben Probleme weiter reduziert.)

Die Zellmodi sind zwischen verschiedenen Auflösung und bpp und Farben abgestuft:

Ab GTIA sind die Bitmap "F" sowie Zell "2" und "3" Modi, statt mit 8x8 1bpp Font bzw 320x192 1bpp Bitmap, durch 3 weitere 2x8 4bpp Font bzw 80x192 4bpp Bitmap Varianten ersetzbar, aber mit sehr niederer Auflösung, und geben dabei erst noch nur relativ nutzlose Fähigkeiten: "$00" ist der normale 320er Modus, "$40" ist 16 Helligkeiten von 1 Farbton (Mono 4bpp), "$80" ist 9von16 Farben mit beliebiger Helligkeit, "$C0" ist 16 Farbtöne in 1 Helligkeit (Kaleidoskop-artig, und kein Schwarz mehr).

Mit einer ANTIC Displayliste sind für alle möglichen 240 Zeilen (inklusive dem vertikalem Overscan) diverse Eigenschaften beliebig zeilenweise mischbar:

Dazu Sprites, 4 Player 8x240 1bpp (8bit Register) sowie 4 Missile 2x240 (bzw zusammenlegbar als fünften Player 8x240) 1bpp (mit 4*2=8bit Register), mit horizontal nur halbes oder gar viertel 160/80Pixel Raster, nur auf 160er positionierbar. 2 Player paarweise zusammensetzbar zu 2bpp. Register fakultativ automatisch ladbar pro Zeile, kosten dann aber alle 240 Zeilen Bytes pro Sprite. Vertikal positioniert durch Sprite in diesem 240er Speicher umkopieren.

Farben wieder mit Register auswählbar aus 16*8=128 (16 Farbtöne und 8 Helligkeitsstufen, vermutlich die identische wie im VCS/2600) (ausser GTIA bei "$40" mit 16 Helligkeiten). Hat 1 Register für Bildrand (und in 2bpp sowie 4-Farben 1bpp Modi auch Bild/Spielfeld Hintergrund), 4 für Bild/Spielfeld Vordergrund (und in "1.5" Farben 1bpp Modi auch Hintergrund), 4 für die 4 Player+Missile (alle Missiles als fünften Player zusammengelegt nehmen die vierte Bild/Spielfeld Farbe), kein separater Ball, zusammen 9.

Wie man sieht ist dies ein massiv komplexer Chipsatz, der nur noch vom Amiga überboten wird, der vom gleichen Designer stammt, weil das seine nachfolgende Arbeit ist!

Texas Instruments TMS9918 VDC Chip (1979)

Kein Rechner oder Spielkonsole, sondern generischer Chip, in diversen Geräten verwendet. Später kamen erweiterte TMS9918A, sowie flexiblere TMS9928A und TMS9929A mit 60Hz bzw 50Hz YUV Signalen statt nur 60Hz NTSC Composite. Zuerst erschienen in TI-99/4 (originale TMS9918) von 1979, sowie TI-99/4A (erweiterte TMS9918A) von 1981. Ebenso Coleco ColecoVision von 1982 (Konsole) und Adam von 1983 (Homecomputer). Ebenso Sega SG-1000 (Konsole) und SC-3000 (Homecomputer) von 1983. (Und auch eine erweiterte im SG-1000 Mark III von 1985, bzw als Master System von 1986.) Am bekanntesten aber ebenfalls im Spectravideo SV328 und in all den davon abgeleiteten MSX ab 1983. (Dort auch eine erweiterte Yamaha V9938 in MSX 2 ab 1985, bzw sogar Yamaha V9958 in MSX 2+ ab 1988).

Einzelner Chip TMS9918 VDC (Video Display Controller), mit separatem 16k Speicher (VRAM), mit eigenem Bus zu diesem, daher asynchron von beliebigem Prozessortyp (9900 in TI-99/4(A) und Z80 in allen anderen obigen), sowie diesen nur bei Videozugriffen bremsend, und nicht wie im Atari 800 den ganzen Prozessortakt auf 7/8 bremsend. Aber mangels Pins hat es keine 16k Abressierung vom Prozessor und seinen Adressmodi her, braucht so eigene Adressregister, umständlich und langsam. Es ist dafür aber auch nicht auf 64k Prozessor Adressraum limitiert. (All dies gilt auch für die in der Einleitung erwähnten µPD7220 und EF93xx Chips.)

Umschaltbar 1 Text und 1 Zell und 1 Blockgraphik und 1 Bitmap Modi:

Dafür fehlen jegliche 2bpp Sachen. Ebenso kein fein scrollen. Auch kein Overscan, trotz selbst bei Graphic immer noch recht schmalem Textfeld.

Dazu Sprites, in allen Modi ausser "0" weil dies ein anderes Timing hat, 8x8 oder 16x16 1bpp (genauer 1x1 oder 2x2 Spritezellen aus 256 zu je 8x8). Mit horizontal volles 256 oder halbes 128er Pixel Raster (mit gleichzeitig auch vertikal ihre Zeilen doppelt gezeichnet), auf volle 256er positionierbar. Jedes hat eine eigene Farbe. Wobei entweder alle 8x8 oder alle 16x16 sind ("Size" = 0 oder 1), sowie alle 256er oder alle 128er+doppelzeilen ("Magnification" = 0 oder 1), es hat dazu nur 2 global wirkende Flags. Stets automatisch geladen pro Zeile, nur für 8 oder 16 Zeilen (bzw mit "Magnification" 16 oder 32 Zeilen), statt alle Zeilen von Bild, daher neben horizontal auch vertikal positioniert per Register. Zeigt dann nur die erstpriorisierten 4 als sichtbare in einer Zeile, von bis zu 32 angemeldeten. Dies ist nur möglich weil Sprites nicht alle Zeilen hoch sind, wie beim Atari. (Die Sprites werden erstmals hier so benamst, nach einer Sorte Spuk den man sieht, der aber nicht dort ist, weil man hier die Sprites im Bild sieht, sie aber nicht im Bildspeicher vorhanden sind.)

(Die V9938 und V9958 VDP (Video Display Processor) erweitern den Videospeicher von 16k auf 128k. Obiges "Text" heisst hier T1. Dazu kommt T2 mit 80x24 und 2bpp Font. Obige "Graphic 1" und "Graphic 2" heissen hier G1 und G2. Dazu kommen fontlose Bitmaps von G4 256x192 4bpp, G5 512x192 2bpp, G6 512x192 4bpp, sowie G7 256x192 8bpp. Ab V9958 gibt es G7 auch mit YJK (YUV-artig) für 19268 kombinierte Farben (4-er Gruppe Pixel hat 4*5bit Y und zusammen je 1*6bit J und K), sowie mit YJK+YAE mit 12499 kombinierte plus 16 dedizierte Farben (Y reduziert zu 4*4bit, weil 1bit Attribute für pixelweise Wahl 0:YJK oder 1:TMS9918-artiges 4bpp). Die V9938 addiert vertikal scrollen, erst die V9958 auch horizontal. Beide erlauben bei G4 bis G7 auch vertikalen Overscan, mit 212 statt 192 Zeilen, sowie interlaced auf 2*192=384 bzw 2*212=424. Beide erlauben bei G3 (G2 mit dies addiert) sowie G4 bis G7 (stets) neben 1bpp auch 2/3/4bpp Sprites, mit 8 sichtbaren von 32 angemeldeten. Ebenso haben sie statt 15 NTSC Farben volle 16 aus 512 RGB Farben (ausser G7 mit 8bpp fest 3R3G2B oder YJK oder YJK+YAE).)

(Das Sega Master System VDP (Video Display Processor) bleibt bei 16k (die SG-1000 hatte nicht mal die vollen 16k). Es bringt einen einzelnen weiteren G4 Zellmodus von 32x24 Zeichen. Mit 8x8 4bpp(!) Font. Daher Vordergrund und Hintergrund Farbwahl direkt aus dem Font heraus, keine 1bpp mit danach separaten 2*4bit Farbattributen per G2 Zellgruppen oder G3 Pixelzeilen. Das verliert aber die Möglichkeit die Zellenmuster mit mehreren Farben zu kombinieren, selbiges Muster anderst eingefärbt braucht daher ein weiteres Zeichen. Hat einen variablem RAM Satz, aber von 448 Zeichen, was obiges fehlende kombinieren etwas kompensiert. Jede Zelle ist horizontal und vertikal spiegelbar, was die Anzahl Muster reduziert, fehlendes kombinieren weiter kompensiert. Es addiert beides horizontal und vertikal scrollen, zudem mit obere 2 Zeilen und rechte 8 Spalten davon ausnehmbar. Kein Overscan. Sprites sind nun 8x8 oder 8x16 4bpp (genauer 1x1 oder 1x2 Spritezellen aus 256 zu je 8x8), aber mit 8 sichtbaren von 64 angemeldeten. Ebenso hat es statt 15 NTSC Farben sogar volle 32 (16 Zellen und 16 Sprites), aber aus nur 64 RGB Farben.)

Motorola MC6847 VDG Chip (197x), und MC6883 SAM dazu (198x)

Kein Rechner oder Spielkonsole, sondern generischer Chip, in diversen Geräten verwendet. Darunter TRS-80 CoCo und Acorn Atom und Dragon 32/64, sowie dem oben erwähnte NEC PC-6001, aber auch viele Hongkong Rechner wie dem Laser 200. Ein Chip MC6847 VDG (Video Display Generator), bzw zwei mit dem MC6883 SAM (Synchronous Address Multiplexer). Wie beim Atari 800 den Prozessortakt auf 7/8 bremsend. Umschaltbar 1 Text und 2 Blockgraphik und 8 Bitmapmodi:

Kein fein scrollen. Keine Sprites. Der schwächste Chip in dieser Liste, unterhalb von einigen TTL Rechnern. Das Gegenstück zur TMS9918, welche aufs Maximum hinaufgezogen wurde, hier nur das einfachste gemacht, auf minimalem TRS-80 32x16 Niveau, nur ROM Font und mischbare Blockgraphik, plus letztere etwas Farben, plus etwas Bitmap mit keinen oder wenigen Farben.

Commodore VC-20 (1980), bzw VIC Chip (1977)

Einzelner Chip VIC (Video Interface Chip). Eigentlich von MOS als Videochip für Kleinterminals und Spielkonsolen besser als dem VCS gedacht, und damit direkte Konkurrenz zur MC6847. Er verkaufte sich aber nicht. Zwei andere Projekte eines Homecomputers (TOI) sowie eines farbigen PET scheiterten an der DRAM Busbandbreite (für 80 Zeichen breit bzw wegen den Farben) bzw den hohen SRAM Kosten (um diese Menge trotzdem zu liefern, wie beim TMS9918). Daraus entstand als Zwischenstufe ein verbesserter VIC für den VC-20 (bzw VIC-20 im englischen Sprachraum oder VIC-1001 in Japan). Das aber mit nur einem viertel der Breite von TOI, bzw der halben des PET. Wegen einem Überschuss an 1kx4 Chips bei MOS wurde der VC-20 dann doch mit SRAM gebaut, was um trotzdem billig zu sein seine geringen 5kByte ergab.

Umschaltbar 2 Zellmodi. Diese wegen viertel bzw halbe Breite nur 22x23 Zeichen (wenigstes etwas besser als strikte viertel bzw halbe mit 20x25 zu benutzen) (mit Overscan kann er angeblich bis zu 28x32). Mit 8x8 1bpp (wie Atari 800 und TMS9918) bzw 4x8 2bpp (wie Atari 800) Font. Aus variablem ROM/ModulROM/RAM Satz von, vollen 256 Zeichen (wie TMS9918), mit eingebautem ROM als 128+revers genutzt (wie Atari 800). Braucht so nur die Hälfte von etwa 2MHz Speichertakt. ROM hat 2x2 Blockgraphik (gibt 44x50) sowie alle PET/CBM Graphikzeichen darin, aber ModulROM/RAM erlaubt wieder spielespezifisch ersetzen.

Dazu 1kx4bit FarbRAM (und somit strikte 5+0.5=5.5kBytes Speicher) mit Vordergrund Farbattribut (jedes Zeichen hat eigenes von 16 NTSC Farben, ohne Helligkeitsstufen), mit den identischen unteren Adressbits A0..A9 nutzend, womit dies strike ein 8+4=12bit Videochip ist! Das erlaubt 256 Font mit 1*16+1 Farben zu kombinieren, ohne dem Atari 800 seine nur 64 Font bei 1*4+1 Farben, oder der TMS9918 seine 256 Font mit 2*16 Farben aber massiver Bandbreite.

Auch kein Prozessortakt auf 7/8 bremsen, weil bei diesen breiten Pixeln auch so wenig Verfärbung entsteht, selbst mit beliebigen Farben, nur 6von8breite Zeichen mit 2breiten Vertikalen reicht. Die aktuelle Zeilennummer ist auslesbar, aber kein Interrupt davon. Kein Bitmap. Kein fein scrollen. Keine Sprites. Wie die TIA im VCS auch Sound und Paddles im selbigen Chip. Nur die sehr niedere horizontale Auflösung ist ein massiver Schwachpunkt.

Sinclair ZX80 (1980), und ZX81 (1981)

Absoluter Minimalstrechner, nur ein Schritt oberhalb eines Hextasten plus 7-Segmentanzeige Maschinencode Lernsystemes, quasi ein Basic Lernsystem. ZX80 noch reines TTL, neben Prozessor und 1*4k ROM und 1*((1kx4)x2) SRAM und 1 7805, noch genau 18 Chips. Dementsprechend extremst primitiv. Selbst die Videospeicher Bytes werden vom Prozessor ausgelesen, und Werte 0..127 vom Videogenerator "nebenher" ausgegeben, dem Prozessor dabei NOP Befehle vorgaukelnd. Der eigentliche Fontzugriff (auf 64*8 Bytes) wird auch mit dem Prozessor gemacht, im Z80 seinem Refreshzyklus ausnutzend, wobei A8..15 den Inhalt vom I Register haben. Werte 128..255 brechen die Ausgabe ab und werden an den Prozessor durchgereicht. Zeilen enden soweit mir bekannt mit RETurn Befehl (C9,201).

Um Platz im nur 1k grossen Speicher zu sparen werden Zeilen ohne rechts verbleibende Leerzeichen und das Bild ohne unten verbleibende Leerzeilen gespeichert. Je mehr Platz der Benutzer mit Programm und Variablen verwendet, umso weniger Zeilen verbleiben bevor der Rechner alte wegscrollt trotz noch Bildschirmplatz zu haben!

Nur 1 Textmodus. Text 32x24. Mit 8x8 1bpp Font. Aus festem ROM Satz, von 64+revers Zeichen (0..127). Trotzdem mit 2x2 Blockgraphik und 1x2 halbhell Raster, weil nur einen Teil von ASCII64 drin. Zeichensatz ist: Leerzeichen 7*Blockgraphik 3*Raster " £ $ : ? ( ) > < = + - * / ; , . 0..9 A..Z), es fehlen von ASCII64: ! # % & ' [ \ ] ^ _. Nur Schwarzweiss. Kein fein scrollen. Erst recht keine Sprites.

(Nachfahre ZX81 lieferte doppelt grosses 1*8k ROM (mit Basic um Fliesskomma erweitert) sowie gleichen Prozessor und 1k SRAM und 7805, aber verfrachtete alle 18 TTLs in ein ULA (Uncommitted Logic Array) Gate Array. All das auch 100% kompatibel, womit sogar das ZX81 ROM im ZX80 als Nachrüstsatz läft. Aber mit leichter Erweiterung der Schaltung (entsprechend etwa 3..5 TTLs) um den Prozessor mit multithreading das Bild auszugeben und die eigentliche Software langsam (etwa 25%) auszuführen lassen, statt entweder nur Bild ohne Software oder nur Software schnell ohne Bild.)

IBM PC + CGA (1981)

Kein Rechner, sondern eine Karte für IBM PC Bus. Vom Prozessor separate Karte, mit eigenem Speicher (wie TMS9918), daher auch asynchron. Aber mit Adressen vom Prozessor (Segment C800..CFFF, davon aber nur 16k genutzt) mit dessen Adressmodi nutzend (ungleich TMS9918, entscheidender Vorteil). Für Timing und Adressen MC6845 Chip, Datenpfad TTL, daher auch halb-primitiv. Trotzdem aber umschaltbar 3 Modi, 1 Text und 2 Bitmapmodi:

Kein fein scrollen, ausser byteweise durch MC6845 Anfangsadressen schieben. Keine Sprites. Viel Speicher und hohe Auflösung, aber die Bitmapmodi liefern weder viele bpp noch ordentliche Farbwahl, und der Textmodus kann weder mit RAM Font noch guter Blockgraphik aushelfen. Egal was man hier versucht, es fehlt stets genau das was gute Spiele erlaubt.

(Ausser man nimmt Text 80x25, stellt dann den MC6845 um auf 80x100(!) Zeichen, was mit flachem 8x2 1bpp Font kompensiert wird. Dann wird es fest mit 8k von den 2x1 Blockgraphik Zeichen 221 bzw 222 gefüllt, und in weitere 8k dann die beiden 4bit Farben für die resultierenden zwei 4x1 grossen Pixel geschrieben. Dies ergibt eine brauchbare aber undokumentierte 160x100 in 16 Farben, was als "Tweak Mode" bezeichnet wird. Nur war dies damals den meissten unbekannt, weshalb wenige Spiele es nutzten.)

Acorn BBC Micro (1981)

Nachfolger des Acorn Atom von 1980 (mit MC6847). Anfangs als Acorn Proton bezeichnet, aber dann wegen Zusammenarbeit mit der BBC umbenannt. Für Timing und Adressen MC6845 Chip, Datenpfad TTL, plus einen SAA5050 Teletext Chip, daher auch halb-primitiv. Trotzdem aber umschaltbar 7 Bitmap und 1 (Tele-)Text Modi:

Farben 2/4/16, von 8 RGB plus blinkend durch reversieren, auf Fernseher oder Videomonitor oder RGB Monitor. Kein fein scrollen, wieder ausser durch MC6845 Anfangsadressen. Keine Textmodi, weil inzwischen genug Speicher um auch bei Bitmap genug Text darzustellen, und damit auch soviel Graphik ohne Zellmodus seine Limiten in der Anordnung. Damit ein total moderner Rechner, mit 8 bis 20k Speicher, von obigen 64k nur noch Faktor 3 bis 8 entfernt.

Keine Sprites, aber kann dies mit dem 4bpp Bitmap kompensieren im Gegensatz zur CGA, nur leicht mehr Shifter Logik und Umschalter (unter +10%). Genau dieses kleine Mehr macht den Unterschied aus von der CGA schrottig zum BBC anständig und modern!

Commodore 64 (1982), bzw VIC-II Chip (1982)

Anfangs auch als Spielkonsole Max-Machine (bzw Ultimax oder VIC-10) mit nur 4k Speicher designt, aber dann als Nachfolger vom VC-20 mit 64k verkauft. Später erweitert auf 128k als Commodore 128 (mit einem VIC-II E, sowie zusätzlichem VDC Chip, dieser wie bei TMS9918 mit eigenem 16k oder 64k Speicher asynchron vom Prozessor mit eigenen Adressregistern). Einzelner Chip VIC-II (Video Interface Chip II), als erweiterten VIC vom VC-20, hat fast all dessen guten Eigenschaften geerbt, aber alle Schwächen fehlen. Zudem kamen weitere nette Sachen dazu. Die Designer hatten explizit Features anderer Chips und Rechner verglichen, und daraus ihre Wunschliste erzeugt. Die Sprites wurden explizit wegen der TMS9918 addiert, und daher auch so benamst.

Umschaltbar 3 Zellmodi und 2 Bitmapmodi:

Trotz beliebigen Farben und 40 Zeichen breit kein Prozessortakt auf 7/8 bremsen. Damit auch 320 Pixel, aber ein schmales Textfenster, fast wie ein 256er 7/8 Pixel Rechner, und genau wie ein 280er 7/8 Pixel Rechner. Nur bessere Schaltung mit 6von8breite Zeichen mit 2breiten Vertikalen reicht. Wohl vor allem weil der ca 8MHz Pixeltakt seine /2=4MHz Wellen nicht auf die 14.318/2/2=3.579MHz oder 17.734/2/2=4.434MHz fallen, erst recht nicht mit einem 2breiten Vertikalen Font seinen 2MHz Wellen. Weshalb man sich fragt, warum andere so sehr 1/8 Prozessortakt zu opfern bereit waren. (Vermutlich wegen billigem 14.318/16=0.895MHz Divisor bei NTSC, aber bei PAL dann aufwendigeren 17.734/20=0.8867MHz, ausser man nimmt den Apple II analog Umwandler. Womit C64 bei PAL den identisch teuren 17.734/18=0.985MHz benutzt, und bei NTSC konsistent den als 14.318/14=1.023MHz nimmt.)

Was hier erstaunlicherweise fehlt ist Overscan, zumal der VC-20 dies noch hatte. Vermutlich so weil das nur 1k FarbRAM mit 40x25=1000 bereits voll ist, keine zu erwartenden 48x30=1440 oder gar 52x32=1664 an Zeichen abdecken kann. (Der VC-20 hatte auch 1kx4bit FarbRAM, aber mit nur 22x23=506 Zeichen in Normalmodus, und bis zu 28x32=896 mit Overscan.)

Hat fein scrollen vertikal und horiontal, aber stets ganzes Bild (und dieses dabei auf 24 Zeilen bzw 38 Zeichen reduziert, im Gegensatz zum Atari 800 der die Scrollverluste mit Overscan benutzen kompensieren kann). Die aktuelle Zeilennummer ist auslesbar, sowie mit automatischem Vergleich auch als Rasterinterrupt nutzbar. Zwar keine Displayliste, aber obiges plus jederzeit Moduswechsel durch Software erlaubt vieles zu kompensieren (inklusive der Randfarbe vom Overscanbereich umschaltbar machen, oder fein scrollen selektiv einschalten). Generell opfert Commodore bzw MOS nur wo gewollt etwas an Prozessor um stets Videochip Komplexität zu sparen.

Dazu Sprites, 8 24x21 1bpp oder 12x21 2bpp (direkt aus einem 256*(63+1)=16k Speicherbereich, nicht dem Font), mit horizontal volles 320 oder halbes 160 Pixel Raster, auf 320er positionierbar, separat vertikal ihre Zeilen auch 2 mal streckbar, mehr als jeder andere 8bit Rechner. Jedes Sprite hat eigene Farbe, sowie eigene Schalter für 1oder2bpp (wieder "Multicolor") und 320oder160er ("Expand X") und vertikal normal/doppelt ("Expand Y"). Zwar ohne Auswahl aus viel mehr angemeldeten (wie beim TMS9918), aber mit Rasterinterrupt explizit mehrfach verwendbar. Ausserdem können sie in den Overscan Bereich hinauslaufen.

Farben mit Register auswählbar aus 16 festen NTSC Farbton+Helligkeit Kombinationen (vermutlich identisch mit VC-20). Hat 1 Register für Rand, 4 für Bild/Spielfeld Vordergrund und Hintergrund, 8 für 1bpp Sprites, 2 geteilte für 2bpp Sprites, zusammen 15, plus FarbRAM für jedes Zeichen. Wie man sieht ist dies ein mengenmässig sehr leistungsfähiger Chip, trotz strukturell weit einfacher zu sein als beim Atari 800. Er wurde damit zum idealen Kompromiss.

Sinclair ZX Spectrum (1982)

Nachfolger der ZX80 und ZX81. Wie bei der ZX81 alles in einem ULA (Uncommitted Logic Array) Gate Array, auch dessen Video. Daher halb-primitiv. Nur 1 Bitmapmodus, da ausreichend Bitmap Speicher jetzt billiger ist als Text oder Zell Logik. Bitmap 256x192 1bpp in 6kByte (wie beim TMS9918A "2" ("Graphic 2")). Aber mit Farbattribute nur alle 8x8 Pixel (wie beim C64) 2 Farben aus 16bzw8 plus blinkend (wie bei der CGA). Aber dies ohne dem C64 seinem 2bpp "Multicolor", was oft in "Attribute Clash" resultierte, wenn in einem 8x8 Feld mehr als 2 Farben gebraucht werden (was beim TMS9918 wegen dessen kleinerem 8x1 Feld weit weniger zutraf, und dort als "Color Spill" bekannt ist). Erlaubt daher auch 32x24 Zeichen mit 8x8 Font. Kein fein scrollen. Keine Sprites.

Tangerine Oric-1 (1982), und Oric Atmos (1984)

Ein direkter Konkurrent vom Sinclair ZX Spectrum, und etwa vergleichbar primitiv. Kann aber 2 Modi, Zell und Bitmap: Bitmap hat 240x200 1bpp, aus eigentlich für 320x200 reichende 8kByte, aber mit davon nur 6von8 Bits als Pixel genutzt. Plus noch 3 Zeilen an Zellmodus darunter (wie beim Apple II). Zell hat 40x27 Zeichen. Mit 6x8 1bpp Font. Bis jetzt ist es noch relativ normal. Was aber fehlt ist trotz Farben jeglicher Platz für Attribute!

Im Bitmap Modus gilt statt dessen, dass die gelesenen 8bit an Pixelmuster auf x00xxxxx Muster getestet werden. Mit ungleich das gewertet als RxPPPPPP für 6 Pixel P, mit R=1 die Farben reversierend. Aber mit gleich das gewertet als x00AAAAA für setze Attribut statt zeichne Pixel" (welche dann als 000000 gezeichnet werden). Dabei gelten die AAAAA=00BGR als setze Vordergrund Farbe und =10BGR setze Hintergrund Farbe. Ebenso gilt =11GHx als schalte Modi, mit G=Graphik(1)/Zell(0) und H=60Hz(1)/50Hz(0) und x wird ignoriert.

Im Zellmodus gilt, dass die 8bit Zeichencodes auf x00xxxxx Muster getestet werden. Mit ungleich das gewertet als RZZZZZZZ für 96 (ASCII-)Zeichen, wieder mit R=1 reversierend. Mit 6x8 Font. Aus RAM Satz, von 96. Aber mit gleich das wieder gewertet als setze Attribut (und Space zeichnen). Wobei hier weitere Attribute wirksam werden, mit =01FDA setze F=Flash(blinkend) und D=Doppelhoch und A=Alternativen Zeichensatz benutzen.

Dies erlaubt zwar 2*3+2=8 (in Bitmapmodus) bzw +3=11 (in Zellmodus) Bits an Attributen, ohne dafür separaten Speicher zu verbrauchen, oder um diesen auszulesen Bandbreite zu brauchen. Aber es ist nochmals weit schlimmer auf "Attribute Clash" anfällig, nicht nur wenn mehr als 2 Farben in einem 6x1 bzw 6x8 Feld gebraucht werden, sondern bereits wenn solche in direkten Nachbarfeldern ohne ein "leeres" (= alles Hintergrund) Feld dazwischen kommen. Ein sehr seltsames Design.

Nintendo FamilyComputer/Famicom (1983), bzw NES (1985)

Als Famicom hauptsächlich als Spielkonsole designt. Aber erweiterbar mit Tastatur (und anderem) an Erweiterungsport, sowie mit Floppylaufwerk als Untersatz namens DiskSystem (1986) mit BootROM plus ErweiterungsRAM plus Controller im Modulport zu einem vollen Homecomputer (im Gegensatz zu Sega ihren separaten SG-1000 und SC-3000 Modellen). Aber beim Export mechanisch umgebaut und funktionell reduziert zum Nintendo Entertainment System (NES) in 1985, ohne Tastatur oder DiskSystem, nur noch reine Spielkonsole, und das nicht mal Modulformat kompatibel. Keine Paddles, aber dafür der erste Rechner mit Joypads neben Joysticks (wobei zu Atari Joysticks kompatible Joypads problemlos machbar sind).

Einzelner Chip PPU (Picture Processing Unit), sowie Sound APU (Audio Processing Unit) und Joypad Interface und "DMA" Blockkopierer im Prozessorchip integriert. Benutzt wie TMS9918 separates VRAM, ebenso mangels Pins keine Adressierung vom Prozessor, eigene Adressregister. Aber nur 2k davon (sowie nur 2k sonstiges RAM, und damit selbst zusammen sogar unter der VC-20 ihre 5.5k!) (beide sind mit RAM in Modulen erweiterbar). Dieses mit eigenem Bus, beide Busse zu den Modulen gehend, und den Prozessor bei Videozugriffen während der ganzen Bildausgabe komplett stoppend (kein schneller Speicher wie bei der TMS9918). Man kann so nur während dem vertikalen Bildrücklauf zeichnen. Ebenso wird der Prozessor beim Blockkopierer benutzen gestoppt.

Hat nur 1 Zellmodus, kein Bitmap, mangels Speicherplatz. Zellmodus hat nur 32x30 Zeichen, und das bereits inklusive dem Overscan. Was wegen der sehr niedrigen 5.35MHz Pixelrate ist, und damit bei 32*8=256 Pixel schon ein 47.8µs breites Textfeld. Nur 3/4 relativ zu Atari 800 oder TMS9918 oder MC6847 ihren 7.16MHz, bzw gar 2/3 relativ zu Commodore 64 ihren etwa 8MHz, und nicht viel mehr als die VC-20 ihre etwa 4MHz. Womit diese 32 Zeichen bei anderen eher 44 bzw gar 48 entsprechen würden, weshalb hier real etwa 24..28 Zellen breit für Textfeld nutzbar sind. Was auch die typisch klobigen Texte in NES Games ergibt.

Dies dafür mit 8x8 2bpp Font, was mit 32x30 Zeichen sehr detailierte 256x240 Pixel gibt, trotz 4-farbig, ohne dafür auf 4x8 Font die Pixel halbieren zu mössen (wie beim Commodore 64 von 320x200 zu 160x200, mit entweder grobem 4x8 Font oder auf nur 20 Zeichen mit 8x8 Font herunter). Aus VRAM/ModulROM/ModulRAM Satz, von 256 Zeichen, Format ist pro Zeichen 8+8=16 Bytes, zuerst 8 Bytes alle Bit0 dann 8 Bytes alle Bit1 (Atari und Commodore haben stets 8 Bytes, mit jedes 8*1bit oder 4*2bit drin).

Weiterhin fein scrollen horizontal, mit pro Zeile variabler Menge, was Parallaxeffekte erlaubt (vorne/unten schneller scrollend als hinten/oben), und vertikal zwischen Zeilen (erlaubt Splitscreen Effekte). Dabei können 2k an Bildspeicher als (2*32)x30 horizontal oder 32x(2*30) vertikal verwaltet werden, erweiterte 4k sogar als (2*32)x(2*30).

Dazu Sprites, mit 8x8 oder 8x16 2bpp (genauer 1x1 oder 1x2 Zeichen aus dem Font, 1x2 nutzen 2*128 Paare, in 4k standard plus 4k erweitertem Font), mit horizontal volles 256Pixel Raster, auf 256er positionierbar, sowie horizontal und vertikal spiegelbar, was die Anzahl Muster im Font reduziert, gerade auch wenn Spritebewegungen von nach rechts zu nach links wenden (und damit sinnvoller bei Sprites als bei der Sega Master System dies für Bild/Spielfeld aber nicht Sprites). Alle entweder 8x8 oder 8x16 (wie bei der TMS9918 nur ein global wirkendes Flag). Stets automatisch geladen, aber 8 sichtbaren von 64 angemeldeten (somit gleiche maximale Pixelmenge wie die TMS9918, aber wegen 2bpp doppelte Datenmenge).

Farben mit Register auswählbar aus 64 (12 NTSC Farbtöne in 4 Helligkeiten, plus Graustufen). Hat 1 Register für Hintergrund (es hat keinen Rand!), 4 Sätze von 3 für Bild/Spielfeld Vordergrund, 4 Sätze von 3 für Sprites, zusammen 25. Jeweils 2x2 Zellen (also 16x16 Pixel!) haben ein 2bit FarbRAM Attribut (ausser das Spielmodul hat einen MMC5 Erweiterungschip drin, der mit mehr RAM auf einzelne Zeichen (8x8 Pixel) genau spezifizieren kann), um 1 der 4 Sätze von 3 Vordergrundfarben auszuwählen. Sprites haben jedes ein eigenes 2bit FarbRAM Attribut, um 1 der 4 anderen Sätze von 3 zu benutzen. Wie man sieht ist dies ein mengenmässig graphisch sehr leistungsfähiger Chip, gerade auch mit den 2bpp und 3 zellweise variablen Farben, aber textuell sehr gering, trotz immer im Zellmodus laufend!

Commodore 16 und 116 und Plus/4 (1984), bzw TED Chip

Gemacht als verbesserten VC-20 Nachfolger, doppelt getaktet (aber dann wie beim Atari 800 auf 7/8 gebremst) und mit mehr Speicher und besserer Graphik. Aber trotzdem billiger als dem Commodore 64, aber dabei ebenso weniger leistungsfähig als dieser. Ein Chip TED (TExt Display, trotz dass er auch Graphik kann). Alle 2+1 Zell und 2 Bitmapmodi vom Commodore 64, mit leichten Änderungen, aber keine Sprites. Damit sind die Zellmodi "normales" 40x25 Zeichen (den massiven VC-20 Schwachpunkt korrigiert). Mit 8x8 1bpp bzw 4x8 2bpp Font (sowie "Extended" mit 4 Hintergrundfarben). Aus variablem ROM/ModulROM/RAM Satz, von 128+invers (wie Atari 800) oder 256 (wie VC-20 oder C64) Zeichen. Sowie Bitmapmodi 320x200 1bpp oder 160x200 2bpp (wie C64). Bei 320*1 oder 160*2 von 14.318/2=7.16MHz Pixel ein 44.7µs Textfeld (wie Atari 800).

Farben mit Register auswählbar aus 16*8=128 NTSC (wie Atari VCS/2600 und 800, aber mit den 16 C64 Farben als Farbtöne, mit dann 8 Helligkeitsstufen davon, wegen Schwarz mit 8 Stufen alle Schwarz real 121 Farben). Hat 1 Register für Rand, 4 für Bild Vordergrund und Hintergrund, zusammen 5. Plus dazu Vordergrund direktes Farbattribut pro Zeichen, Bit6..0 auch obige 128 im 1bpp Modus, und Bit7 blinkend. Dazu aber kein 4bit oder gar 8bit separated FarbRAM sondern weitere 1k an normalem 8bit Speicher benutzt, mit daher sogar 2 "Badlines" in der ersten Zeile eines Zeichens und der Zeile davor. Im Bitmap 1bpp sind es so auch 2 Farben (wie im C64), aber im 2bpp auch nur 2 statt 3 mangels Platz für 3*(3+4=7)bit.

Overscan fehlt wie im C64 VIC-II, trotz kein separates FarbRAM welches dies auf 1k limitiert. Anderseits ist auch ohne bereits 44.7µs Textfeld. Das kann zudem mit sehr extensiven Rasterinterrupt Techniken teilweise kompensiert werden, solange nur vertikales Overscan gewollt ist. Selbst die Apple II Bitmap+Text Anordnung kann so nachgestellt werden. Hat fein scrollen vertikal und horiontal, mit wie beim C64 die Reduktion auf 24 Zeilen bzw 38 Zeichen. Wie TIA im VCS und VIC im VC-20 auch Sound im Chip, zwar keine Paddles aber einen PIO Port für Tastatur+Joystick sowie Timer.

Damit waren C16 und C116 gute VC-20 Upgrades im Billigmarkt, vor allem C16 in Mexiko bzw C116 in Ungarn, zumal sie neben mehr Video und Speicher auch noch schnelleren Prozessor hatten. Der Plus/4 hatte zudem als reinen "farbigen PET" Homebusiness Rechner mehr in Basic nutzbares RAM, eine bessere 4 statt 2 Tasten Cursorsteuerung, ein am Modulport passendes 1551 Floppylaufwerk (welches mit Parallelkabel etwas schneller war als dem C64 seine sehr lahme 1541 Floppy mit bitbanging Serialbus), sowie eine Hardware UART für Modems (der Atari 800 verwendet seine UART im POKEY für dessen schnelleren SIO Port Serialbus und 810 Floppy). Nur hat Commodore dann entgegen dem Designziel versucht, den Plus/4 als Ersatz vom C64 zu vermarkten, trotz explizit schwächer, ohne Sprites, was ihm seinen Spitznamen Minus/60 einbrachte.

Amstrad/Schneider CPC464 (1984), und 664 sowie 6128 (1985)

Ziel besser als den "schwangeren Taschenrechner" (O-Ton Hersteller) des Sinclair ZX Spectrum zu sein, mit echter Tastatur und 80 Zeichen, aber billiger als einen Acorn BBC, mit dafür einfachste Hardware. Er verwendet sogar den selbigen RGB Monitor Stecker wie der BBC, und das selbige Basic wie der Z80 Zweitprozessor zum BBC. Für Timing und Adressen einen MC6845 Chip (wie BBC und CGA), Datenpfad ein Gate Array, daher auch halb-primitiv. Umschaltbar nur 3 Bitmap Modi, ähnlich dem BBC, aber kein Teletext:

Farben 2/4/16, aus 27 RGB (3*3*3), auf mitgeliefertem RGB Monitor (zugleich Netzteil vom Rechner). Kein fein scrollen, wieder ausser byteweise durch MC6845 Anfangsadressen schieben. Keine Textmodi, weil inzwischen genug Speicher um auch bei Bitmap genug Text darzustellen, und damit auch soviel Graphik ohne Zellmodus seine Limiten in der Anordnung. Damit ein total moderner Rechner, mit stets 16k Speicher, von obigen 64k nur noch Faktor 4 entfernt.

Keine Sprites, aber kann dies wieder mit den 4bpp kompensieren im Gegensatz zur CGA, nur die unter 10% mehr Shifter und Umschalter. Genau dieses kleine Mehr macht wieder den Unterschied aus, von der CGA schrottig zu CPC (und BBC) anständig, und hier noch mit 27 statt 8 RGB Farben erweitert!

(Die 464plus und 6128plus von 1990 addierten 32 von 4096 RGB Farben, und fein scrollen, sowie Sprites. Sie waren aber, 5 Jahre nach dem die 16bit Atari ST und Commodore Amiga erschienen waren, als 8bit schlicht nicht mehr relevant.)

Mühlhausen HC 900 bzw KC 85-2 (1984), und 85-3 sowie 85-4

Mit 85 im Namen weil in 1984 noch als HC900 Homecomputer geplant, in 1985 zum Kleincomputer umspezifiziert und neu nummeriert. DDR Rechner, keine VLSI Chips, alles reine TTL Logik, dementsprechend sehr primitiv.

Nur 1 Bitmapmodus (wie beim Spectrum, weil auch in der DDR inzwischen DRAM billiger ist als TTL Logik). Bitmap 320x256 1bpp (256 weil nur 50Hz Moni wie beim Acorn BBC, mehr als Commodore 64 320x200), für alle 8x4 Pixel 2 Farben aus 16 (mehr als Spectrum alle 8x8, aber weniger als TMS9918 alle 8x1, so immer noch auf "Attribute Clash" halb anfällig). Erlaubt daher sogar 40x30(von32) Zeichen, bei 8x8 Font. Dazu wird die ohnehin langsame 2oder2.5MHz UB800 auch noch im Prozessortakt auf 1.75MHz gebremst. Warum keine 4MHz UA880 drin ist weiss ich auch nicht, vermutlich weil eben als Homecomputer konzipiert, und auch beim KC 85-4 erweitern mit 1.77MHz nicht korrigiert. Wie CGA eigene 16k Videospeicher, vom Hauptspeicher abgetrennt, aber vom Prozessor adressiert, aber mit 10k Bitmap plus 2.5k Farbattributen (plus 1.25k Zeichennummern), und somit trotz kein Umschalten besser als die CGA.

Kein fein scrollen. Keine Sprites. Trotzdem sind diese Rechner recht aufwendig, und wurde wohl auch deshalb von HC zu KC umbenamst, und dann als Ausbildungsrechner benutzt, weil in DDR Technologie und mit DDR Wirtschaft weder hometauglicher Preis noch hometaugliche Fabrikationsmenge drin lagen. (Die KC 85-2 hatte nur ein geringes Monitor ROM, die KC 85-3 hatte erweitertes ROM mit Basic, statt von Kassette laden.)

(Nachfahre KC 85-4 erweitert auf (2von4)*16k Videospeicher, und so 10+10k statt 10+2.5k (beide plus 1.25k). Damit 2 Bitmapmodi. Obiges 320x256 1bpp, aber nun mit alle 8x1 Pixel 2 Farben aus 16 (wie TMS9918). Oder umschaltbar auf 320x256 2bpp. Letzteres aber wegen dem 10+10k Videospeicher mit zwei 8*1bpp Bitplanes statt 32k an 4*2bpp Chunks. Es ist damit anfällig auf "Ghosting" beim scrollen, wenn das dargestellte Bild Pixel beinhaltet von denen eine Plane ihre Bits bereits verschoben sind und die andere noch unverschoben ist, was unpassende Bits kombiniert zu zufälligen Farben welche kurz aufflackern. (Beim 1bpp plus Farbspeicher kombinieren sich lediglich neues Muster mit alten Farben, was weit weniger flackert.) Es kann anderseits egal ob 1oder2 Planes zu 8*1bpp mit dem gleichen Font beschrieben werden, statt bei 2bytes 4*2bpp mit "verschobenem" Font.)

Apple Macintosh (1984)

Halb ausser Konkurrenz, weil 16bit. Hat nur 1 Bitmapmodus. Alles reine TTL Logik, keine VLSI Chips, teils noch PALs, dementsprechend sehr primitiv für seine Zeit. Bitmap aus 16bit Speicher grosse 512x384 1bpp, aber nur Schwarzweiss auf dem eingebauten Spezialmonitor, daher auch keine Farben möglich. Nicht einmal 2bpp Graustufen gibt es, nur mit Schwarzweiss rastern liegt drin. (Daher wurde auch selektierter Text früher in revers statt mit Grau hinterlegt angezeigt.) Eigenartig ist 0=weiss und 1=schwarz, weil Apple glaubt Bildschirme (selbtleuchtend) wie Papier (reflektiv) behandeln zu müssen. Erlaubt 85x32 Zeichen bei 6x12 1bpp 72dpi Font. Minus GUI Elemente Platzverlust erlaubt das gerade noch etwa 80x24. Kein fein scrollen. Keine Sprites.

(Ganz ausser Konkurrenz kam erst beim 32bit Mac II von 1987 eine Auswahl von Graphikkarten, darunter auch farbige, anfangs mit VGA-artigem 640x480 4bpp, später auch 8bpp.)

IBM EGA (1984)

Ganz ausser Konkurrenz, weil aus gigantischem 4*64=256k (und damit 32bit breitem!) Speicher laufend. Hier nur als Beispiel, was man damals schon mit viel Masse machen konnte. Kein Rechner, sondern eine Karte für IBM PC Bus (damit auch für 16/8bit 8088 PC/XT, nicht nur 16bit 286 PC/AT ISA Bus!). Wie CGA mit eigenem Speicher und asynchron, aber ebenfalls mit Adressen vom Prozessor mit dessen Adressmodi nutzend (aber nur 1*64k Adressraum davon nehmend, weil als 64kWorte von 32bit verwertet!). Als zwei Gate Array Chips gebaut, die eine einen erweiterten MC6845, die andere den Datenpfad. Dies weil IBM grosse leistungsfähige Gatearrays verwendet hat, wie sie auch in Grossrechner Prozessoren verbaut werden, weshalb IBM solche Chips selber herstellen konnte.

Zellmodus statt Textmodus zu 80x25 Zeichen CGA kompatibel. Aber mit neu 8x14 1bpp Font. Aus RAM Satz, von 256 Zeichen (strikte schaltbar zu mit Attributbit3 2von4 mal 256 wählbar). Zudem 80x43 Zeichen, mit altem 8x8 Font. Bitmapmodi einerseits CGA kompartibel 640x200 1bpp und 320x200 2bpp. Mit anderseits dazu auch 640x350 1..4bpp. Dies mit Bitplanes statt Chunks (wie beim KC 85-4), mit gleichem Font bei variablen bpp Vorteil, aber ohne "Ghosting" weil mit einem aufwendigen 8zu(1..4*8)=32bit Pixelprozessor die Planes synchron bewegbar sind (neben auch bewegen beschleunigend und den Adressraum auf die 64kWorte erweiternd). Davon 4*28k nutzend (oder einen solchen Ausschnitt aus bis zu 4*64k Bild), mit 16 Farben aus 64 RRGGBB. Wie beim Mac geht dies nur auf einem EGA Spezialmonitor. Ebenso wurde ein Vertical Blank Interrupt (VBI) addiert.

(S-EGA Clones konnten mit gleichem Speicher auch 640x480 4bpp (4*38k) oder nachdem Multisync Monitore erschienen auch mit ausreichend Bandbreite sogar 800x600 4bpp (4*60k). Nur die 4 Bitplanes 4bpp Limite verhinderte auch 320x200 8bpp machen, oder gar mit ausreichend Bandbreite auch 640x400 8bpp mit dieser Masse zu erschlagen!)

(Noch mehr ausser Konkurrenz ist die davon erweiterte VGA von 1988. Als 1 Gaterarray, mit EGA-erweitertem MC6845 als Teil davon. Zell 80x25 CGA kompatibel. Aber nun mit (8+1=9)x16 1bpp Font. Sowie 80x50, mit (8+1=9)x8 Font. Beide mit 2oder4von8 mal 256 Zeichen. Bitmap addierte als MCGA Modus genau obige 320x200 8bpp (mit Chunks statt Bitplanes), sowie offiziell 640x480 4bpp (mit Bitplanes), aber kein 640x400 8bpp trotz dass es in 256k passten würde. Mit 256 bzw 16 Farben aus 262144. Erlaubt 80x30 mit 8x16 1bpp 100dpi Font, sowie 80x40 mit 8x12, sowie 80x60 mit 8x8. Wieder nur mit VGA Spezialmonitor, dem ersten mit HD15 VGA Stecker.)

(Wieder gingen S-VGA Clones weiter, mit 256k Speicher bis zu 640x400 8bpp, oder gar mit 512k Speicher 640x480 8bpp oder gar mit genug Bandbreite bis zu 800x600 8bpp (und 1024x768 4bpp). Aber alle 8bpp Chunks Modi sind inkompatibel zu einander über die 64k hinaus adresserweitert. Erst spätere S-VGA addierten 1 Sprite, oft 16x16 2bpp (sw+ws+invert), als Hardware Mauscursor. Ebenso kamen mit 1M Speicher auch 1024x768 oder gar 1152x864 8bpp, sowie die 16/256 Farben aus 16M statt 262144, sowie 800x600 3*5=15bpp mit 32k Farben direktem RGB. Von hier stammen alle modernen PC Karten ab, dabei die Inkompatibilitäten immer schlimmer werdend.)

Atari ST (1985)

Halb ausser Konkurrenz, weil 16bit. Einfacher geradliniger Rechner, der in unter 1 Jahr von Entwurf in den Verkauf sein ging. Eigentlich Tramiel Corp, welche den Namen Atari Inc aufgekauft haben, und sich dann in Atari Corp umbenannten. Trotz mit Namen Atari eigentlich der Nachfolger vom Commodore 64, weil selbiger Firmenbesitzer Jack Tramiel eben Atari aufgekauft hat. Strikte ein C64 mit doppelter Speicherbreite (von 8bit auf 16bit), doppeltem Speichertakt (von 2MHz auf 4MHz), gibt vierfache Bandbreite, benutzt vierfachen Videospeicher (von 8+1=9k auf 32k). Mit daher den Featuresatz abgebaut/vereinfacht, nur Bitmapmodi, keine Zellmodi oder Sprites (damit unter dem TED, auf Acorn BCC und Amstrad/Schneider CPC Niveau). Auf 2 Chips basiert, Speicher/Adressen Controller/Generator, und Daten/Pixel Chip ("Shifter"). Umschaltbar 3 Bitmap Modi aus 16bit Speicher, aber welche benutzbar sind abhägig vom Monitortyp:

Mit dem Schwarzweiss Spezialmonitor ist stets 640x400 1bpp (1/3 mehr als beim Mac 512x384). Wieder nicht mal 2bpp Graustufen, trotz dass die Hardware eigentlich 2bpp kann, also ist wieder rastern angesagt. Auch mit 0=weiss und 1=schwarz. Erlaubt 80x25 Zeichen bei 8x16 1bpp 100dpi Font, oder 80x50 Zeichen mit 8x8. Minus GUI Platzverlust erlaubt dies aber nicht mehr 80 Zeichen breite Platz!

Mit dem RGB Monitor (vergleichbar den BBC und CPC ihren) sind es dann 640x200 2bpp (und das kann auch 2bpp Graustufen sein) oder 320x200 4bpp (oder auch 4bpp Grau), mit 4oder16 Farben aus 4096 RGB (und damit genau ein in bpp verdoppelter CPC). Bei 640 von 16MHz Pixel ein 40µs Textfeld (wie Commodore 64). Verwendet Pseudobitplanes statt Chunks, also Pixel in Worten wie bei Planes behandelt (mit den Font Vorteilen), aber Worte im Speicher wie bei Chunks liegend (und so auch ohne Pixelprozessor resistent gegen "Ghosting"), das beste von beiden Welten! Erlaubt 80x25 bzw 40x25 mit 8x8 Font. Wieder minus GUI Platzverlust nicht mehr 80 Zeichen breit. Keine Sprites (aber dies kompensiert mit den 4bpp, wie beim BBC und CPC).

Ob er fein scrollen kann ist mir unbekannt. Aber das Bild kommt stets aus einem 32k Speicherblock, der soweit mir bekannt nur in 32k Schritten angeordnet werden kann, vom System jeweils auf das Ende vom Speicher gesetzt, also kaum scrollbar. Für einen derart einfachen Rechner erstaunlich gut und modern, weil er bereits Auflösung und 4bpp Masse ausnutzt, mit 32k von obigen 64k nur noch Faktor 2 entfernt ist. Zudem mit 8MHz 68000 viel Prozessorleistung hat. Das einzige was man vermissen kann wäre ein 160x200 8bpp, oder gar 64k Modi wie 640x200 4bpp und 320x200 8bpp.

(Noch mehr ausser Konkurrenz kamen dann im 32bit Atari TT von 1990 weitere Modi, darunter auch mit 8bpp.)

Commodore Amiga (1985)

Halb ausser Konkurrenz, weil 16bit. Trotz mit Namen Commodore eigentlich der Nachfolger vom Atari 800, weil selbiger Designer Jay Miner, nach Atari verlassen Firma HiToro gegründet, diese von Commodore aufgekauft. Ist strikte ein Atari 800 mit doppelter Speicherbreite (von 8bit auf 16bit), doppeltem Speichertakt (von 0.89 MHz auf 3.57MHz), gibt auch vierfache Bandbreite, kann aber mehr als vierfachen Videospeicher (von 1..8k auf 8..48k), und daher den Featuresatz abgebaut/vereinfacht (nur Bitmapmodi, keine Zellmodi, aber hat Sprites). Daher auch ein 3er Chipsatz, mit Agnus (Address GeNerator UnitS) statt ANTIC, Denise (Display ENabler) statt GTIA, sowie Paula (Ports, Audio and UART) statt POKEY. Ebenfalls deswegen gebremst auf 7/8 Prozessortakt, 7.16MHz bzw 7.09MHz 68000 statt den 8MHz vom Atari ST. Damit auch 640 von 14.318MHz Pixel ein 44.7µs Textfeld.

Umschaltbar 2 Bitmap Modi aus 16bit Speicher 640x(200oder256) 1..4bpp (16..64k oder 20.5..82k) oder 320x(200oder256) 1..6bpp (8..48k oder 10.25..61.5k). Dies mit Bitplanes statt Chunks (wie KC 85-4 2bpp und EGA und VGA 1..4bpp), mit wieder gleichem Font bei variablen bpp, aber dadurch ebenfalls massiv anfällig auf "Ghosting", zumal ohne jegliche Synchronisierung durch einen Pixelprozessor (wie in der EGA). Erlaubt 80x(25oder30) bzw 40x(25oder30) Zeichen bei 8x8 Font. Minus GUI Platzverlust ebenfalls nicht mehr 80 Zeichen breit Platz. All dieses gibt es auch mit Overscan bis 768x256 bzw 384x256, was obiges GUI Problem kompensieren könnte, aber nicht genutzt wurde. Kann weiterhin doppelte Zeilenzahl mit interlaced. Alles auf einem Fernseher oder Videomonitor oder RGB Monitor. Keine mehr als 200bzw256 Zeilen, und keine Spezialmonitor Option, weil auch hier wie beim Atari 800 anfangs als Spielkonsole designt und dann zum Homecomputer recyclet. Hat fein scrollen vertikal und horiontal.

Mit Copperliste statt Displayliste sind alle Register ihre Inhalte umprogrammierbar, egal ob beliebige Modi oder vertikalen Overscan oder Scrollen oder Farbsatz oder Sprites. Gerade Scrollen wird aber aufwendiger weil die Adressen der Zeilen für jede Bitplane einzeln nachgetragen werden müssen. Auch Copperinterrupt (analog zu Displaylisteninterrupt) kann er, einfach durch ein spezielles Register bearbeiten (statt durch ein Bit pro Datenwort). Ebenso Copper oder Prozessor anhalten, nicht nur bis Zeile sondern sogar bis Position in Zeile. Ebenso nichtlineare Listen durch eine zweite Listenadresse beschreiben und aktivieren, dies sogar als Unterlisten, weil wieder auf die andere Adresse retourschaltbar.

Zudem hat er einen Blitter um beliebige rechteckige Speicherblöcke zu füllen oder umkopieren (inklusive beliebige Ausschnitte im Bild scrollen, Breite in 16Pixel Blöcken, Höhe in Zeilen), oder gar zu verknüpfen (inklusive für Font rendern), oder einfach zu füllen (inklusive mit Muster). Dies mit Zielblock "D" jedes Pixel = beliebige Logikfunktion der korrespondierenden Pixeln in Blöcken "A" "B" und "C", nachdem diese 0..15 Pixel geschoben wurden, sowie bei ersten und letzten Wort von Zielblock auch Teilworte maskiert (= nicht verändert) werden können. Was aber wegen dieser Blöcke ebenfalls bitplaneweise bearbeiten genau das "Ghosting" beim scrollen maximal verschlechtert. Mit Hilfe des Coppers das Bild aus einzelnen Zeilengruppen zusammensetzen reduziert "Ghosting", als halbe Form der Atari ST Pseudobitplanes, nur auf Zeilen(-block) statt Wort Auflösung. Es reduziert aber den Blitter Nutzen auf innerhalb eines Blockes, weshalb um Fonts zu rendern die Blöcke alle Bildzeilen einer Textzeile beinhalten müssen, was den Nutzen von diesen Ansatz wiederum etwas reduziert. Dazu Sprites, 8 16xN 2bpp, aber wieder horizontal nur im halbierten 320Pixel Raster, und soweit mir bekannt auch nur auf 320er positionierbar (das ganze Timing wird sogar in 160ern gemessen). Diese sind Paarweise zusammensetzbar zu 4bpp. Wie im Atari 800 und Commodore 64 keine Prioritätslogik (wie es in der TMS9918 oder der Famicom/NES hat), aber die Spriteposition + Höhe + Modus + Farbe können alle mit Copperinterrupt und Prozessor oder direkt per Copper die Sprite Register beschreiben umstellt und so mehrfach verwendet werden.

Dazu ist noch mit Dual Playfield das Bild/Spielfeld als 2*3bpp nutzbar, mit 8 Farben plus darüber noch 7 Farben (weil 0 = durchsichtig) als ein "Monstersprite" von ganzer Bildgrösse mit separatem fein scrollen. Zumeist für fein gemusterte Parallaxeffekte benutzt.

32 Farben aus 4096 RGB, ausser Extra Half Bright (EHB) mit 2*32 voll+halb, und Hold And Modify (HAM) Modus alle 4096 (letzteres mit 1/3 Auflösung ausser den 16 Startfarben mit voller Auflösung, aber diese auch per Copper zeilenweise anpassbar). Auflösung plus Overscan plus viele Farben plus grosse Sprites und Parallax gaben ihm zurecht seinen Ruf als das Graphikwunder schlechthin. Wieder zum Preis von einem massiv komplexen Chipsatz sein. Auch hier kann man nur noch ein 320x200 8bpp vermissen, weil die Bitplanes auf 6bpp limitiert sind (analog zu der EGA ihre maximalen 4bpp), wenn auch nur wegen der Registerzahl (und in der EGA schon wegen der Busverdrahtung).

(Noch mehr ausser Konkurrenz kamen dann im AGA Chipsatz der 32bit Rechner A4000 und A1200 von 1992 weitere Modi, darunter auch 8bit 256 Farben aus 16M, inkusive dem HAM8 Modus mit 262144 davon.)

Sega Mega Drive (1988), bzw Genesis in den USA (1989)

Halb ausser Konkurrenz, weil 16bit. Im Gegensatz zum erst nach der NES weit zu spät gekommenen Master System, war dieser ein massiver Erfolg weil vor weit der verspäteten SNES gekommen. Hat fast überall mit der NES gleichgezogen oder gar einen massiven Vorsprung herausgeholt, und zumeist auch gegen die SNES behalten. Dieser Vorteil wurde aber danach wieder komplett verscherzt, weil Sega Japan und Sega USA sich einen internen Machtkampf lieferten, und dabei sich gegenseitig Information vorenthielten. Also kamen inkompatible 32bit Mega Drive Erweiterung 32X (USA) und 32bit Saturn (Japan) kurz nacheinander heraus, was Sega bei den Spieleherstellern endgültig diskreditierte, und so allen späteren Systemen jegliche Unterstätzung kostete. Wieder Tod durch Kopfschuss per Management.

Einzelner Chip VDP (Video Display Processor) Chip, nicht mehr die TMS9918 Familie wie im Master System. Dieser ist zum Master System seinem erweitertem G4 Modus kompatibel, und hat einen weiteren neuen Modus G5, nicht aber die normalen TMS9918 Modi 0 bis 3. Benutzt wie diesen separates VRAM, 64k davon (neben auch 64k sonstiges RAM).

Hat nur 2 Zellmodi G4 und G5, kein Bitmap, trotz eigentlich genug Speicherplatz. Im G5 niedrige 256x(224oder240) sowie bessere 320x(224oder240), wie G4 mit 4bpp, bzw 32x(28oder30) sowie 40x(28oder30) von 8x8 Zellen. Kann weiterhin doppelte Zeilenzahl durch interlaced. Damit fast vergleichbar mit den Atari ST 320x200 4bpp und sogar den Commodore Amiga 320x(200oder256) 4bpp, aber unterhalb der MCGA 320x3200 8bpp, wenn man Zellmodi statt Bitmapmodi ignoriert. Etwas gebremste 68000 auf 7.67MHz bzw 7.61MHz, statt den 8MHz vom ST, aber mehr als sie 7.16MHz bzw 7.09MHz vom Amiga, womit die 256 Pixel ein schmales 33.5µs bzw 320 ein mittleres 41.9µs Textfeld sind. Nur vertikales Overscan.

Dazu viele und grosse Sprites, 32x32, auch 4bpp. Stets automatisch geladen, mit 20 sichtbaren von 80 angemeldeten (mehr als der Amiga, und sowieso mehr als ST und MCGA ihre gar keinen).

Kann auch Dual Playfield, als "Monstersprites" von je 32x32 bis 128x128 Zellen zu je 8x8.

Farben sind 4 schaltbare Sätze von 16, aber aus nur 512 (weniger als ST oder Amiga oder gar MCGA). Vermutlich Hintergrund ein Satz und Sprites die restlichen teilend.

Nintendo SuperFamicom (1990), bzw Super NES (1991)

Halb ausser Konkurrenz, weil 16bit. Naja, mit anstelle einer 68000 wie in Macintosh und Amiga und ST und Mega Drive, strikte nur einer 16/8bit 65816, als erweiterte 8bit 6502 der Famicom/NES (selbige erweiterte wie im Apple IIgs), und so am ehesten vergleichbar mit EGA in einem 8088 PC/XT.

Ein Chip Paar PPU (Picture Processing Unit). Benutzt wie die Famicom/NES ebenfalls separates VRAM, 2*32k=64k (als je 32k an Videospeicher und Fontspeicher) davon (neben auch 128k sonstiges RAM), alles 8bit Speicher.

Hat nur 8 Zellmodi, kein Bitmap, trotz eigentlich genug Speicherplatz. Wegen wieder relativ niedriger 5.35MHz Pixelrate (identisch wie bei der Famicom/NES), mit dessen sehr niedrigen 256x(224oder239), bzw 32x(28oder30) von 8x8 Zellen (ausser selten genutzte Modi 5 und 6 mit 10.7MHz und 512x(224oder239), bzw 64x(28oder30) 8x8 Zellen). Beides bereits inklusive Overscan, bei 32*8=256 Pixel 47.8µs Textfeld (und damit wieder nur 3/4 vom Commodore Amiga seinen 320er etwas über 7MHz, bzw gar 2/3 vom Atari ST seinem 320er 8MHz, sowie 7/10 vom Sega Mega Drive). Damit auch nur 24..28 an Textfeld, und die typisch klobigen NES Texte auch in SNES Games. Kann weiterhin doppelte Zeilenzahl durch interlaced (aber auch nur in Modi 5 und 6).

Mit HDMA (Horizontal DMA) kann er während dem horizontalen Strahlrücklauf synchron Speicherzugriffe auslösen. Was am ehesten dem Copper vom Amiga entspricht.

Dazu noch mehr Anzahl an Sprites, 8x8 oder 16x16 oder 32x32 oder 64x64 4bpp (diese aus 1x1 bis 4x4 von 8x8 Zellen zusammengesetzt, aus RAM Zeichensatz von 512), sowie horizontal und vertikal spiegelbar. Stets automatisch geladen, mit 32 sichtbaren von 128 angemeldeten (nochmals mehr als die Sega Mega Drive). Aber auf nur 34 Zellen davon laden begrenzt (die Mega Drive schafft volle 20 bei 32x32, was hier 80 Zellen an horizontalen Pixeln entspricht).

Dazu ist noch mit 1 bis 4 Layern der Hintergrund zusammengesetzt aus "Monstersprites" von je 32x32 bis 128x128 Zellen zu je 8x8, nochmals besser als bei Dual Playfield. Mit pro Layer aus RAM Zeichensatz von 1024 Zeichen, diese ebenfalls horizontal und vertikal spiegelbar, und alle 4 mit separatem fein scrollen. In Modi 2 und 4 können Zellen sogar individuell gescrollt sein, für scrollende Fenster.

Hat primitive pseudo-3D Transformationen auf dem Hintergrund, mit Mode 7. Dieser ist stets 8bpp, was zusammen mit den 2 separaten 32kx8bit SRAMs als Videospeicher und Fontspeicher in 1FontZugriff=1Byte=1Pixel resultiert. Mode 7 tut dann nur noch die vom Videospeicher her zusammengesetzen Fontspeicher Adressen transformieren, statt inerhalb von einem Zeichen nur linear durchzugehen. Das erlaubt skalieren, verzerren und rotieren von Zeichen, und mit dieser Transformation ihre Schrittweiten per Software zeilenweise vorzu angepasst auch pseudo-3D. Die Sprites bleiben aber 2D, mit jeglichen 3D Effekten nur durch separate Zeichen im Font durchgehen, wie bei allen anderen Rechnern.

Farben sind 16 schaltbare Sätze von 4 oder 16, aus 32768 (mehr als alle ausser MCGA). Jeder Layer kann 8 Sätze benutzen, mit 2bpp bis zu 8*4=32 wobei jedes Layer andere 32, und 4bpp bis zu 8*16=128 alle Layer geteilte, sowie 8bpp alle 256, vermutlich pro Zelle ausgewählt (zumal Tetris mit 7*3 Farben plus Schwarz einzelne Blöcke schattiert). Modus 0 ist 4*2bpp, 1 ist 2*4bpp+1*2bpp, 2 ist 2*4bpp, 3 ist 1*8bpp+1*4bpp, 4 ist 1*8bpp+1*2bpp, 5 ist 1*4bpp+1*2bpp 512 Pixel, 6 ist 1*4bpp 512 Pixel, 7 ist 1*8bpp. Jedes Sprite kann 8 weitere Sätze benutzen.

Vergleich als Medien

Nachdem die Teilnehmer bekannt sind, geht es nun darum sie für diverse visuelle Effekte als Medium zu benutzen versuchen, und zu vergleichen wie sie dabei abschneiden mit welchen Features

Bitmapmodi

Die einfachste Form von Graphik ist genau das was man von Papier und Stift bzw Mosaiken her seit langem kennt, eine Fläche von Pixeln, welche man jede einzeln beliebig auf eine Farben setzen kann, komplett flexibel. Also Bitmapmodi. Genau daher verwenden wir heute ausschliesslich solche. Nur deren Platzbedarf ist problematisch, sonst sind sie universell.

1bpp/2Farben Bitmap Modi

Der einfachste Weg obige 320x200 8bpp ihre 64k zu reduzieren besteht darin, schlicht die 8bpp zu reduzieren, mit bei 320x200 mit nur 1bpp nur noch 8k brauchen. Was genau einer Zeichnung mit einfarbiger Zeichenfläche mit nur einem anderfarbigem Stift entspricht. Wenn dies ausreicht zählt als Vergleich von Rechnern nur noch wieviele Pixel an Bitmap in 1bpp sie jeweils liefern können:

Ohne jegliche Bitmapmodi scheiden alle anderen 8bit Rechner hier ganz aus. Darunter Processor Technology VDM und Sol-20, Commodore PET und VC-20, Tandy TRS-80, Sinclair ZX80 und ZX81, sowie die Nintendo Famicom/NES.

Die 16bit schlagen hier zu, dank mehr Speicher und Bandbreite. Am besten mit 640x400 der Atari ST als doppelte 640x200 aus 32k. Weniger mit 512x384 der Apple Macintosh als doppelte 512x192 aus 24k. Beide brauchen dazu aber wegen doppelten Zeilen einen Spezialmonitor, bei Atari separat wählbar oder beim Mac fest eingebaut, und das bei beiden nur in Schwarzweiss. EGA liefert dazwischen 640x350 (Breite von Atari, Höhe von Macintosh), auch mit einem Spezialmonitor, aber dafür in Farbe. Die bereits beim BBC und CPC gesehenen 640x256 bzw 640x200 auf einem Fernseher oder Videomonitor oder RGB Monitor kann der Amiga (und ebenso deren Speicher sparenden 320x256 bzw 320x200) (sowie plus Overscan wie beim Atari 800), dafür kann er doppelte Zeilen nur mit interlaced statt Spezialmonitor. Auscheiden tun sicher die Sega Mega Drive und Nintendo SuperFamicom/SNES wegen trotz 16bit keine Bitmaps.

Die Farbauswahl dabei kann sehr verschieden sein. Schlimmstenfalls ist nur ein Schwarzweiss Monitor vorhanden, beim Macintosch, sowie dem Atari ST für 1bpp, sowie beim Apple II (wenn Schwarzweiss weil 280x192 gewollt ist). Wenig besser kann man die Stiftfarbe umschalten, weiss oder grün bei den MC6847. Etwas besser lässt sich die Stiftfarbe beliebig einstellen, aus 16 beim Cromemco TV Dazzler und IBM CGA. Noch besser als das kann auch die Flächenfarbe beliebig sein, beide aus 8 beim Acorn BBC, aus 27 beim Amstrad/Schneider CPC, aus 64 bei der EGA, 128 beim Atari VCS/2600 und Atari 800 (aber bei letzterem nur "1.5" Farben, also 2 von 8 Helligkeiten von 1 von 16 Farbtönen), und 4096 beim Amiga (aber nicht 4096 beim Atari ST, weil nur in Farbmodi nur mit Farbmonitor machbar).

1bpp/2Farben Farbzellen Modi

Obiges erlaubt trotzdem nur 2 Farben auf dem ganzen Bild, weil 1bpp nun mal Monochrom ist, auch wenn wie oben eingefärbt. Etwas verbessern kann man mit Display Listen Interrupt oder Rasterinterrupt die Farbwahl zeilenweise vorzu ändern, was von obigen aber nur der Atari 800 kann. Weit besser ist aber, dies in Hardware zellenweise schalten zu können, jeweils 8 Pixel breite Zellen, passend zu Schriftzeichen und/oder Objekte in Szenen eher rechteckig denn zeilenbreit sein. Dies entspricht mit mehrerer Stiften colorieren können, solange einzelne Objekte nur je eine Farbe haben, und in die Zellen passen.

Dies kann man mit Stiftfarbe und Flächenfarbe machen. Oft mit 4+4bit für 2 von 16 Farben in einer Zelle benutzen. Dies mit 8x8er Zellen im Commodore 64 und Sinclair Spectrum, mit 8x4er Zellen im KC 85-2 und 85-3, oder gar mit 8x1er Zellen im KC 85-4 und TMS9918 "Graphic 2" Modus. Oder 1+7+7bit für 2 von 128 Farben (plus blink) mit 8x8 Zellen im TED.

Dabei wird aber für die Zellenfarben festlegen mehr Speicher (plus 1/8 oder 1/4 oder 1/1 (=doppelt)), und um diesen zu lesen erst recht mehr Bandbreite (stets doppelt in der ersten/einzigen Zeile der Farbzellen) benötigt.

Dabei wird entweder der Prozessor vom Speicher ausgeblockt und angehalten, beim Commodore 64, sowie vermutlich im Sinclair Spectrum. Was auch ein Grund ist nur 8x8 Zellen zu benutzen, weil das die Ausblockzeit auf nur jede achte Zeile reduzieren kann, beim 64er als "Badlines" bezeichnet, oder beim TED sogar 2 von 8 wegen 2*7bit Farben.

Oder man akzeptiert mehr Prozessor ausblocken, wie beim KC 85. Die 8x4 von 85-2 und 85-3 sind durch den 16k Videospeicher limitiert, die 8x1 vom 85-4 werden erlaubt durch (2*)2*16=64k Videospeicher. Wobei hier Videospeicher vom Hauptspeicher getrennt ist, also nur bei Videozugriff bremst.

Oder man benutzt weit schnelleren und teuren Speicher, beim TMS9918 seinen 4*0.895=5.58MHz statt 2*0.895=1.79MHz, was dann dessen 8x1 Zellen ohne den Prozessor ausblocken erlaubt, oder zumindest den nur etwas bremsend.

Abseits liegt der Tangerine Oric, mit jeder 6x1 Zelle ohne den Prozessor ausblocken, aber zum Preis von Farben umschalten kostet eine Zelle als Attributschalt Leerplatz.

(Man beachte hier noch, dass KC 85-4 und TMS9918 mit ihren 8Pixel*1bpp=8bit plus 8x1 Zelle 2*4=8bit Farben sogar gleich viel Speicher und Bandbreite verbrauchen wie wenn sie eine doppelt so breite Auflösung ohne Farbzellen hötten! Damit könnten diese auch 640x256 (einen vollen Acorn BBC!) bzw 512x192 1bpp liefern, wobei dieses dann nur noch mit im ganzem Bild 2 Farben wie oben gehen würde (und wie im BBC gemacht). Dabei würden dem TMS9918 die 12k sogar in seine 16k passen, aber der KC 85-4 müsste die 20.5k in 2*10.25k auf 2 seiner 16k Seiten (zu je 640x128) verteilen.)

2bpp/4Farben Bitmap Modi

Auch so bleibt eine Zelle auf 1bpp und 2 Farben beschränkt, mit den Problemen von "Attribute Clash", sobald man mehr als 2 Farben in der Zelle nutzen will. Oder zellenweise Farben sind in einem Rechner gar nicht vorhanden. Der andere Ansatz zu mehr Farben besteht darin, 2bpp statt 1bpp zu verwenden, für 4 statt 2 Farben, bei jedem einzelnen Pixel im Bild. Dies entspricht mehrere Stifte bleibig einsetzen, aber auf Kosten von mehr bpp, und damit mehr Speicher, oder wegen Bandbreite zumeist halbierter horizontaler Pixel:

Ohne jegliche 2bpp Bitmapmodi kommen neben all den Rechnern ganz ohne Bitmap, auch einige weitere ausscheidend. Einerseits der Cromemco TV Dazzler (kann nur 1bpp und 4bpp, aber kein 2bpp), dann der Atari VCS/2600, sowie alle TMS9918, Sinclair ZX Spectrum, die Tangerine Oric, die KC 85-2 und 85-3 (aber nicht 85-4). (Davon können sich die TMS9918 und Spectrum sowie KC 85-2 und 85-3 aber mit ihren Farbzellen retten.)

Die 16bit ziehen teilweise genauso mit. Ein paar von ihnen haben bei 1bpp nicht mal ihre ganze Bandbreite ausgenutzt, und gehen daher für 2bpp mit gleicher Auflösung auf doppeltem Speicherplatz. Logisch sind dies nur Rechner mit massiver Bandbreite, genauer den Amiga der auch bei 2bpp (und auch bei 4bpp) 640x200oder256 kann (plus Overscan) sowie die IBM EGA die ebenfalls bei 2bpp (und 4pp) 640x350 kann. Nach diesen verbleibt nur noch mit 640x200 der Atari ST mit Farbmonitor, mit halbierter Zeilenzahl. Der Apple Macintosh fällt weg, ebenso der Atari ST falls mit Schwarzweiss Monitor.

Irgendwas 8bit sucht man bei dieser Verdoppelung fast vergebens, nur die KC 85-4 schafft es, weil sie von 320x256 1bpp plus 8x1 Farbzellen auf 2bpp umschaltet, was aber auch nur die Häflte vom nicht vorhandenen 640x256 1bpp wäre. Ebenfalls kann dies die Acorn BBC, als halbierte vorhandene 640x256. Die TMS9918 mit ebenfalls 8x1 Farbzellen hätte Platz und Bandbreite, aber ein 256x192 2bpp Modus ist nicht implementiert, und auch sonst gar nichts mit 2bpp, und auch kein 512x192 1bpp.

Die Farbauswahl hier kann wieder sehr verschieden sein. Schlimmstenfalls gibt es nur 2 feste 4er Sätze, wie beim MC6847 (gn+gl+bl+rt oder ws+cy+mg+or). Etwas besser kann eine Farbe gewählt werden, wie bei der IBM CGA eine Farbe aus 16 und 3 feste 3er Sätze für den Resten (gn+rt+ge oder cy+vt+ws oder cy+rt+ws). Noch besser als das können alle 4 Farben gewählt werden, aus 8 beim Acorn BBC, aus 27 beim Amstrad/Schneider CPC, aus 64 bei der EGA, aus 128 beim Atari 800, und 4096 beim Atari ST und Amiga.

2bpp/4Farben Farbzellen Modi

Mit 2bpp gibt es zwar 4 unabhängige Farben. Aber das sind immer noch weniger als die oft 16 Farben welche man mit Farbzellen bekommt. Also gibt es auch die Kombination der beiden Ansätze, welche aber recht selten ist. Der Apple II mit Farbmonitor offeriert dazu nur 2 feste 4er Sätze (sw+gn+vt+ws oder sw+or+bl+ws), aber kann diese für jede 7x1 Zelle wählen (mit dem achten Bit). Die Commodore 64 und TED dagegen machen auf volle Farbzellen, wegen 160x200 nun in 4x8 Grösse, aber mit 4+4+4=12bit 3 (C64) bzw 1+7+7=15bit 2 (TED) "Stifte" der 3 Farben aus 16 (C64) bzw 2 aus 128 (TED) wählbar (und eine vierte (C64) bzw zwei weitere (TED) als zellenlose "Zeichenfläche" fürs ganze Bild), mit dem dritten "Stift" beim C64 aus der 8+4=12bit Erweiterung kommend, während der TED mit zwei "Stiften" bereits seine 8+8=16bit vom Hauptspeicher ausschöpft.

4bpp/16Farben Bitmap Modi

Auch so bleibt eine Zelle auf 2bpp und 4 Farben beschränkt, falls überhaupt vorhanden. Der 2bpp Ansatz kann auch erweitert werden auf 4bpp oder gar mehr. Das erlaubt jedem Pixel unabhängige 16 oder mehr Farben. Diese mehr bpp gehen wieder zumeist auf Kosten nochmals halbierter horizontaler Pixel, falls sie überhaupt hierhin kommen:

(Die TMS9918 könnte eigentlich mit gleicher Schaltung und nur anderem vertikalen Timing auf 64x96 oder gar 64x192 gehen, aber dies wird nicht angeboten. Wenn man seine 256x192 1bpp mit 8x1 Farbzellen mit leichter Erweiterung der Schaltung auch als 512x192 1bpp nutzen könnte, würden neben 256x192 2bpp sogar noch 128x192 4bpp nur mit anderem Timing drin liegen, aber dieses wird auch nicht angeboten.))

Ohne jegliches 4bpp Bitmapmodi kommen neben all den Rechnern ganz ohne Bitmap, und den bereits bei 2bpp schon ausgeschiedenen, weitere welche welche wegfallen. Dazu gehören auch alle MC6847, die IBM CGA (wäre 160x200 wie CPC), alle Commodore, und die KC 85-4 (wäre 160x256 wie BBC). (Letztere beide können sich aber wieder mit ihren Farbzellen retten.)

Die 16bit ziehen teilweise genauso mit. Ein paar von ihnen haben bei 2bpp immer nicht ihre ganze Bandbreite ausgenutzt, und gehen daher für 4bpp mit gleicher Auflösung auf doppeltem Speicherplatz weiter. Wieder der Amiga 640x200oder256 (plus Overscan) sowie IBM EGA 640x350. Wobei der Amiga bei 3bpp und 4bpp den Prozessor immer mehr ausbremst, zu 3bpp 22% bzw 4bpp 44%. Oder es wird jetzt doch reduziert. Der Atari ST macht trotz 16bit auf halbiert, mit noch 320x200. Der Amiga kann neben 640x200oder256 durchziehen auch 320x200oder256 (plus Overscan) ohne Prozessor bremsen.

Die Farbauswahl geht jetzt immer auf 16 Farben, die Frage ist nur noch welche. Am schlechtesten ist es beim Acorn BBC der nur 8 Farben kennt und das vierte bpp nur für (reversfarbig) blinken benutzen kann. Etwas besser beim Atari 800 mit GTIA, der entweder 16 Helligkeitsstufen eines Farbtones oder 16 Farbtöne in einer Helligkeitsstufe oder nur 9 Farben aus 128 bietet. Volle 16 RGBI Farben gibt es beim Cromemco TV Dazzler. Andere feste 16 beim TMS9918 "Multicolor". Sogar 16 aus 27 der CPC, 16 aus 64 die IBM EGA, 16 aus 4096 beim Atari ST und Amiga.

Mehr als 4bpp/16Farben Bitmap Modi

Mehr als 4bpp liefert der Amiga mit bis 6bpp. Dazu muss aber auch er die Auflösung stets halbieren auf 320x200 (plus Overscan). Bei 5bpp kann er noch volle 32 aus 4096. Bei 6bpp liefert er nur selbige 32, aber in voller und halber Helligkeit im EHB (Extra Half Bright = zusätzlich halb hell) Modus. Ebenfalls bei 6bpp gibt es dann schliesslich alle 4096 Farben aufs mal, im HAM Modus (Hold And Modify = beibehalten und modifizieren), mit dazu setzen 0..15 normal 16 aus 4096 Farben, und dann 16..31,32..47,48..63 modifizieren jeweils eine der drei RGB Komponenten direkt mit 4bit mit den beiden anderen beibehalten. All diese auf kosten von nur noch 320x200oder256 falls 0..15 benutzt bzw 106x200oder256 bei vollen Farben. All die enorm guten fast photorealistischen Bilder welche dem Amiga seinen Ruf aufbauten wurden in diesem Modus erzeugt. Auch hier wird der Prozessor etwas gebremst, zu 5bpp 11% bzw 6bpp 22%.

Mehr als 6bpp liefert die V9938 mit "G7" 256x192 8bpp, als einziger 8bit. Der Atari ST könnte von seinem Speicher/Timing her diese mit 160x200 8bpp liefern, es scheitert nur an den internen Leitungen im maximal 4bpp breiten "Shifter" Chip. Er könnte mit Amiga-artigem Prozessor bremsen auf 40% es sogar bei 320x200. Der Amiga könnte mit seinem Timing auch auf 320x200oder256 liefern, mit wie beim 640x200oder256 4bpp den Prozessor 40% ausbremsend, es scheitert an den maximal 6 Bitplane Adressregistern. Die IBM EGA könnte dies sogar mit grossen 640x200 liefern mit ihrem 4*8=32bit Bus, es scheitert hier an der hart in 4 Bitplanes aufgeteilten Schaltung. Die IBM VGA lieferte dies dann, wenn auch nur mit MCGA 320x200, und so nur 1/4 ihres 256k Speichers nutzend, trotz ausreichend Bandbreite für 640x400, wie es S-VGA zeigen.

Zellmodi

Bitmaps sind flexibel aber aufwendig an Speicher und Prozessor. Der ganz andere Weg zumindest Speicher (aber nicht Bandbreite, der Bedarf daran steigt sogar noch!) zu sparen ohne die Pixelzahl abzubauen besteht darin, nicht jedem Pixel im ganzen Bild seinen eigenen Speicherplatz zu geben, sondern das Bild aus Zellen zusammenzusetzen, mit statt einem einzelnen bildgrossen Bitmap aller Pixel nur einem kleinen Satz von zellengrossen Pixelmustern (dem Font) sowie einer Liste von Zellnummern (dem nun weit kleineren Bildspeicher). Der Font ist dabei in RAM (oder allenfalls noch ModulROM), und somit durch passende Softfonts ersetzbar. Problematisch dabei sind die fest gegebene Zellengrösse/Zellengrenzen sowie die limitierte Anzahl Zellensorten im Font.

1bpp/2Farben Pixelzellen Modi

Analog zu obigen 1bpp/2Farben Bitmap Modi kann man auch hier mit nur 1bpp arbeiten, was wieder einer Zeichnung mit einfarbiger Zeichenfläche mit nur einem anderfarbigem Stift entspricht, bzw wegen fixer Zellen eher einem Stempeldruck mit nur einer Farbe. Auch dabei gilt nur noch, wieviel Menge man an Pixel bekommt, hier aber statt Menge Bitmap nun zusammengesetzt aus Anzahl Zellen mal Pixel in einer Zelle, sowie noch wieviele Zellen man im Font definieren kann:

Alle mit nur Bitmapmodi scheiden hier aus. Das sind Cromemco TV Dazzler, Atari VCS/2600, Acorn BBC, Sinclair ZX Spectrum, Amstrad/Schneider CPC, alle KCs, sowie alle 16bit ausser der IBM EGA.

Ohne jegliche Zellmodi scheiden hier ebenfalls alle mit festen ROM Textmodi statt ladbarem RAM Zellen aus. Das sind Processor Technology VDM und Sol-20, Apple II, Commodore PET, Tandy TRS-80, Motorola MC6847, Sinclair ZX80 und ZX81, sowie IBM CGA.

Zudem scheiden die Nintendo Famicom/NES aus, weil Zellmodi aber nur 2bpp. Ebenso die Nintendo SuperFamicom/SNES, weil 2bpp oder 4bpp. Sowie das Sega Mega Drive, weil 4bpp. (Das Sega Master System hat noch die TMS9918 "Text" und "Graphic 1".)

Die 16bit steigen hier eigentlich alle aus, weil genug Speicher, und damit besser die Text bzw Zellen Logik (und Bandbreitebedarf) einsparen. Nur die EGA (und VGA) erweitern den für CGA kompatibel notwendigen Textmodus auf Zellmodus. Mit dann 80x25 mit 8x14 Font (und VGA 80x25 mit 9x16 Font) bzw sogar 80x43 mit 8x8 Font (und VGA sogar 80x50 mit 9x8 Font).

Die Farbauswahl ist hier weit einheitlicher als bei Bitmaps. Alle haben Farben, alle können Stiftfarbe und Flächefarbe wählen. Nur der Farbsatz und dessen Anwendung variert. Der Atari 800 "2" kommt hier wieder mit seinen "1.5" Farben halb-monochrom daher.

1bpp/2Farben Farb+Pixelzellen Modi

Obiges erlaubt wieder nur 2 Farben auf dem ganzen Bild, weil 1bpp wieder nun mal Monochrom ist, auch wenn wie oben eingefärbt. Wieder kann Display Listen Interrupt oder Rasterinterrupt nur zeilenweise andere Farben geben. Wieder ist die bessere Antwort dies in Hardware zellenweise schalten zu lassen mit Farbzellen. Dabei passen die Farbzellen stets genau auf die Pixelzellen, weil Farbzellen gleichzeitig addiert wurden wie dem Ausbau von ROM Textmodi zu RAM Zellenmodi. Der Rest streut massiv:

2bpp/4Farben Pixelzellen Modi

Auch so bleibt eine Zelle auf 1bpp und 2 Farben beschränkt, mit den Problemen von "Attribute Clash", sobald man mehr als 2 Farben in der Zelle nutzen will. Mit dazu hier noch dass die Zellenmuster auch auf die Zellen ausgelegt sind, was wenigstens "Attribute Clash" bei einem Spielhintergrund oder in einem Spielobjekt seltener macht. Um darin aber mehr Details zu packen will man wie bei Bitmap auch 2bpp für 4 statt 2 Farben nutzen können. Das vorhandene streut wieder massiv:

2bpp/4Farben Farb+Pixelzellen Modi

Auch hier sind 4 Farben im ganzen Bild zuwenig. Wieder passen Farbzellen zu Pixelzellen. Das vorhandene streut ebenso massiv:

Die 16bit steigen hier eigentlich alle aus, weil genug Speicher, und damit besser die Text bzw Zellen Logik (und Bandbreitebedarf) einsparen.

Nur die Nintendo SuperFamicom/SNES dreht erst auf. Reine Zellgraphik, aber neben 2bpp sogar 4bpp, wieder in 32x30 (PAL) oder gar nur 32x28 (NTSC). Dazu noch 4 Layer.

Auch das Sega Mega Drive dreht noch mehr auf, mit dessen G5 Modus, selbige 4bpp, aber nun 32x(28oder30) sowie 40x(28oder30) 8x8 Pixelzellen. Dazu noch Dual Playfield.

Textmodi

Bitmaps sind flexibel aber aufwendig an Speicher und Prozessor. Zellen sind genügsam an Prozessor, und mittel an Speicher, aber intensiv an Bandbreite und Logik, und waren die letzte Neuentwicklung vor Bitmap. Davor gab es Textmodus, mit etwas weniger Logik, und zwei separaten Speichern um Bandbreite zu verteilen, mit dem Font nur in billigem ROM, und zudem technisch uralt. Jedes Texterminal (ausser solche mit Softfonts) basiert ausschliesslich auf diesen.

Font in ROM macht es unmöglich, hier beliebige Formen zu zeichnen. Daher kann der Vergleich nur die Anzahl Zeichen im Bild sowie dem Umfang vom eingebauten Zeichensatz anschauen. Zumal Farben hier zumeist auch nicht relevant sind, also ist auch alles 1bpp:

Sprite Additionen

Bitmaps sind flexibel aber aufwendig an Speicher und Prozessor. Dies erst recht wenn man Auflösung für Details und viel Farben für Spielfeld und sich bewegende Objekte haben will. Dies ist machbar, wie es Acorn BBC und Amstrad/Schneider CPC zeigen, zum Preis von 160x256 bzw 160x200 4bpp und somit 20.5k bzw 16k an Speicher und viel Prozessor. Auch Atari ST und IBM EGA verwenden den selbigen Ansatz, nur mit 16bit bzw 32bit und 32k bzw 4*28k Speicher. Zellen sparen Prozessor und etwas Speicher, aber sind noch inflexibler wenn Objekte nicht in die Zellen passen, und erst recht auf max 2bpp limitiert, kein 4bpp.

Schnell merkt man, wie sehr mehrere vom Spielfeld unabh&aunl;nigige an beliebigen Orten einblendbare Objekte nützlich wären. Das sind die Sprites. Diese sind stets kleine Bitmaps wie in den Zellen, wenn auch oft grösser als diese. Die Grösse und Anzahl und Anordnung streut extrem massiv. Der Aufwand diese zu verwalten und einblenden ist gross, daher sind sie nur in wenigen grossen Chips enthalten. Diese streuen erst recht massiv:

Rangliste nach Fähigkeiten

Wegen der zum Teil sehr grossen Differenzen bei diesen Rechnern wird hier nach Kategorien verglichen. Mit zuoberst die besten, welche alle auf Customchips basiert sind, mit und ohne Sprites, dann einfachere mit nur Bitmap, dann solche mit nur noch Zeichenmodi Graphikes, dann noch als letztes die 16bit Systeme als Kontrast:

8bit mit Customchips mit Sprites

Platz 1 geht eindeutig an den Commodore 64. Ein 320er Pixelraster statt bloss 256er. Mit Zell und Bitmapmodi, beide in 1bpp und 2bpp. Vollen 256er Font in den Textmodi. All das zusammen mit dem 8+4=12bit Datenbus von RAM+FarbRAM, 16 Farben pro Zeichen bzw pro 8x8 Pixel Zelle, plus noch mit "Extended" 4 Hintergrundfarben von 2bpp auf Kosten von 64er Font. Mit Bitmap 1bpp 2von2 bzw 2bpp 3von4 zellenweise und Text immer noch 1bpp 1von2 bzw 2bpp 1von4 zellenweise. Dazu die grösste Menge Spritebits pro Zeile. Und noch jede Menge flexiblen Komfort wie fein scrollen und lesbarer Zeilennummer und Rasterinterrupt, und ungebremsten Takt vom Prozessor. Das einzige was einem hier wirklich fehlt ist Overscan (ausser bei den Sprites). Nett wäre noch die 16 Farben aus mehr auswählen können (wie beim Atari 800 und dem TED). Verschmerzen kann man dass intensivere Effekte nach Software vorzu umkonfigurierend verlangen. Die Designer vom VIC-II haben ihre Erfahrungen von PET/CBM und VC-20 sowie die "beste Features anderer Chips und Rechner vergleichen" Logik voll durchgezogen. Das Resultat ist saugut, der beste Videochip der 8bit Generation, er ist so gut wie sein Ruf. Kein Wunder fängt die Demoszene mit dem C64 vorzeigen an, hier ist viel zum ausnutzen drin!

Platz 2 geht überraschend an die Nintendo Famicom/NES. Abstriche gibt dessen 256er Pixelraster trotz dass dies inklusive Overscan ist, was an Text nur etwa 24..28 Zeichen breit erlaubt (was somit einem (24..28)*8=(192..224)er Raster entspricht), sowie die fehlenden Bitmaps, und gebremst. Das vernichtet jede Chance auf den ersten Platz. Aber ein 256er Font, zusammen mit der konsequenten 2bpp Logik welche viele Farben erlaubt, ohne pixel-halbierte 4x8 2bpp Fonts, volle 8x8 2bpp, was von der Font Bitmenge her einem 512er (bzw eher (384..448)er) Pixelraster mit 1bpp entspricht. Die 8x8 2bpp brauchen dafür 2 Bytes Font pro Pixelzeile eines Zeichen, mit daher nur bei jedem zweiten Fontbyte ein Zeichenbyte holen, was 2/3 statt 1/2 Bandbreite an Fontdaten erlaubt, und damit erst obiges Pixelraster. Damit gibt es trotz gebremsten Speichertiming, schlimer als beim Atari 800 und TMS9918 und MC6847, zwar nur 3/4 1bpp Pixel (was Text kostet), aber 3/2 2bpp Pixel (was Graphik addiert), was genial ist und der Famicom/NES ihren zweiten Platz sichert. Danach werden selbst die auf 16x16 limitierte Farbzellen zu akzeptabel, zumal diese dann gleich zellenweise 3 Farben von 4 Sätzen erlauben. Dazu kommen die zweitmeisten Spritebits pro Zeile. Man merkt wie die Erfahrungen aus Spielhallen Automaten herstellen (teils ihrer Automaten beinhalten von NTSC auf RGB modifizierte Famicoms/NES). Aber ebenso die Limiten von einer Spielkonsole zu einen Homecomputer ausbauen wollen, wie nur etwa 24..28 Zeichen breit nutzbar für Text. Was Tastatur und DiskSystem wenig attraktiv machte, weshalb Famicom/NES als Zwischending von Konsole zu Homecomputer eben als Familiencomputer bezeichnet wurde. Massiv nervig ist zeichnen nur während dem Bildrücklauf, weil dem TMS9918 sein schneller Speicher fehlt. Zudem fehlen Paddles, es gibt nur Joystick bzw eben Joypad.

(Obiges gilt teilweise nur für die volle Famicom. Die reduzierte NES ohne Tastatur und DiskSystem verliert massiv weil gar kein Homecomputer mehr, nur noch reine Spielkonsole. Damit auch nicht selber programmierbar, braucht externe Programmerstellung und Modulproduktion. Dazu kommt erst noch dass zwecks Spielezensur mit einem Lockout Chip und Regioncodes eigene Module herstellen verhindert wird, nur das erlaubt ist wofür Nintendo einem Module herstellen willig ist. Damit ist nur noch Konsumieren erlaubt, was die Diktatur vorgibt, es versagt somit als Medium! In Zahlen, für die etwa 2mio Atari 800 gab es in 13 Jahren um 1000 Spiele, für 17mio C64 gab es in 12 Jahren um 2000, für 62mio NES gab es trotz 20 Jahren aber nur um 1400. Was alles der NES eine Disqualifikation wegen Foul einbringt!)

Platz 3 geht noch überraschender an den TMS9918. Auch nur 256er Raster, aber das wenigstens im Bild drin, für volle 32 Zeichen. Kann 256er Font, sogar mit Farben auf 1x8 ("Graphic 2") oder aber 8x8 an 32 8er Gruppen Zeichen gebunden ("Graphic 1"). Dazu noch die drittmeisten Spritebits pro Zeile. Und keine Prozessorbremse. Abstriche gibt es nur für das komplette fehlen jeglicher 2bpp Farbigkeit, und damit nur den dritten Platz. Auch die fehlenden Overscan und Feinscrolllogik stören etwas. Nervend ist erst recht die Programmierung, wegen keine Prozessor Adressenmodi benutzen können, was aber nur Aufwand und Geschwindigkeitsverlust ist, einem nicht graphisch limitiert. Ebenso fehlen praktisch allen TMS9918 Rechnern die Paddles. (Bonuspunkte gibt es für den genauen Gegensatz zur NES, dass der Chip in vielen verschiedenen Rechnern erhältlich ist. Mit Tastaturen, und frei programmierbar. Mit Modulen und Kassetten und Flopys.)

(Die V9938 und V9958 erweitern einiges davon, mit ihren massiven G4..G7 Bitmapmodi, bis zu 512 Raster, bis zu 8bpp, 8 statt 4 von 32 Sprites, vertikal etwas Overscan (212 statt 192 Zeilen), und fein scrollen (V9938 aber nur vertikal, V9958 auch horizontal). Diese kamen aber nur sehr spät, haben nur noch MSX etwas verlängert.)) (Das Master System erweitert mit seinem G4 Zellmodus auf 4bpp und 448 Font, sowie 8 von 64 Sprites, ohne Overscan, aber in beide Richtungen fein scrollen. Auch hier merkt man ihre Erfahrungen aus Spielhallen Automaten herstellen. Dieser kam aber auch spät, konnte gegen Nintendo ihre Dominanz wenig anrichten.)

Platz 4 geht enttäuschend an den Atari 800. Er hat zwar theoretisch ein 320er Raster, aber dieses nur in Modi "2" und "3" und "F" mit deren "1.5" Farben Logik benutzbar. Sonst ist dies nur ein 160er Raster (mit Overscan bis 192) Rechner (und damit unter dem Famicom/NES 224 bzw 256, sowie beim VC-20 160+). Es ist auch so dokumentiert als 160er Pixelclocks (die 320er werden offiziell als "Halfclocks" bezeichnet). Zwar guten 2bpp Support in 160er Text und Bitmapmodi, aber dahinter gibt es kein zellenweises Farben setzen, mit nur 4 Farben auf dem ganzen Bildschirm, ausser man geht per Display List Interrupt und Software umkonfigurieren, was aber wegen Timing nur zeilenweise wirken kann, und ihn so klar auf den vierten Platz verweist. Dazu kommt nur 128er Font, bzw wenn man die Modi "6" und "7" für 2bit an Farbauswahl nutzen will sogar nur 64er Font, nicht mal 2*64 Zeichen geschweige denn 4*64 (was der C64 erst für seinen 4 Hintergundfarben "Extended" Textmodus opfert). Man merkt hier dass Atari eine Spielhallenfirma ist und erstmals einen Homecomputer aus einer Spielkonsole macht, und das mit der Auflösung nicht im Griff hat, während Commodore als Bürofirma beim C64 zum zweiten mal einen Spielerechner macht. Dazu kommen noch die zweitgeringsten Spritebits pro Zeile, was auch nicht bei korrigieren von obigen Limiten helfen kann. Dies dazu noch mit 160er Raster, gerade die Sprites nicht detailiert. Das ist besonders schwach bei einer Spielefirma, und dazu dem Erfinder der Sprites (Pong Geräte waren praktisch nur Sprites ohne Hintergrund). Dies wurde dann besonders kritisch als aus dem Atari 800 die 5200 und XEGS Konsolen abgeleitet wurden. Es ist aber unvermeidbar wegen des gebremsten 7/8 Prozessortaktes, und so nur 112 von den 128 Speicherzyklen/Zeile vom C64, mit davon wegen dem Overscan 2*48=96 statt 2*40=80 für den Hintergrund reserviert, nur 112-96=16 statt 128-80=48 im Rücklauf (wo die Spritedaten gelesen werden). Nach Abzug vom Speicherrefresh (etwa 4), sowie bis zu 6 weitere für die Displayliste reserviert (maximal Pseudomodus "1" plus Adresse plus Modus plus fakultative Adresse), verbleibt die Differenz von 8*3=24 zu 5*1=5 Spritebytes/Zeile. Da kann auch die Displayliste nichts mehr retten. Sie spart zwar selektiv RAM (und damit Bandbreite/Prozessorbremse) bei variabel aufwendigem Hintergrund, sowie Prozessor bei Modi im Bild umschalten bzw scrollen, aber bei Farben oder Sprites aufbessern ist sie wirkungslos, also doch wieder Software gefragt. Dabei sind Text oder Paint Programme alles nur 1 Modus, Games mit mehreren Modi nutzen den Prozessor nur im vertikalen Rücklauf, haben ihn im Bild frei um Modi zu wechseln, also ist hier Hardware Aufwand und 6 Speicherzyklen/Zeile blockieren am falschen Ort. Zudem ist noch die Displayliste ihre Scrollmethode nicht mit einem 8+4=12bit FarbRAM welches die unteren Adressbits nutzt kompatibel (mit dazu 2 separate Adressen und Pins benötigen). Damit fällt der Atari 800 wegen Bremse plus Overscan statt Spritemenge, sowie Displayliste statt FarbRAM, auf den vierten Platz, weil mit viel komplexem Aufwand am Ziel effektiver Leistung vorbeigeschossen!

Platz 5 und damit letzter geht dann wie zu erwarten an den Atari VCS/2600. Der erste VLSI Chip mit Sprites, bereits in 1977, was absolut gut für damals war. Aber ansonsten praktisch unbrauchbar. Der als erweiterte Pong Konsole mit 40er Raster grobpixelige Hintergrund kann fast gar keinen Text darstellen (selbst mit 4x8 Font nur 10 Zeichen pro Zeile, und das erst noch als 2*5 wiederholt!). Die Sprites liefern nur 2*8 und 3*1 Pixel. Ausser man programmiert sehr aufwendige "Racing the Beam" Techniken, womit Pong Spiele genau ihre 3x5 Font Spielstandanzeige bekommen. Und dann kommt noch der Programmaufwand, um alle Zeilen in Software umkonfigurieren zu müssen, was garantiert dass mit maximal 4k ROM adressieren nur wenig Spiellogik verarbeitet werden kann.

(Der VCS/2600 hielt wegen billig und früh etabliert sein mit vielen Spielen die bessere (aber inkompatible) Konkurrenz aus dem amerikanischen Markt heraus. Was ihn ab 1977 von 3 auf 6 Jahre zu 1983 "streckte", in denen in Europa die Homecomputer den Markt wegnamen, und Japan ohnehin noch an Spielhallenautomaten festhielt. Seine Limiten und Programieraufwand führten nachdem Atari viele Entwickler herausekelte, bei Atari zu eigenen unfertigen/schlechten Spielen (Pacman und E.T.), sowie bei den Drittfirmen zu ihren oft überhasteten aber überhypeten Spielen. Nicht verwunderlich führte diese Flut von Schrott zu einem Vertrauenszusammenbruch der Käufer, und dem Nordamerikanischen Videogame Crash von 1983. Dabei verlor Atari massiv. Europa und Japan waren davon wenig betroffen, weil bereits auf Homecomputer umgestiegen, oder noch bei Spielhallenautomaten. In Japan fing Nintendo gerade den Wechsel an, zu Konsolen, mit Erfolg, und nahm danach auch gleich die USA mit. Sega schaffte es wegen später startend anfangs nur halbwegs in Europa sowie gross in Südamerika. Erst mir der Mega Drive konnten sie ausnutzen, dass Nintendo 16bit total verschlief.)

8bit mit Customchips ohne Sprites

Platz 1 geht eindeutig an die TED Rechner (Commodore 16 und 116 und Plus/4). Mit einem überarbeiteten und ordentlich erweiterten VC-20 VIC nicht verwunderlich, mit spritelos reduzierten C64er VIC-II erst recht nicht. Sofern man keine Sprites braucht ist der TED mit dem Commodore 64 auf obigem Platz 1 graphisch identisch! Addiert man noch die grosse Auswahl an 16*8=128 Farben (strikte 121 davon weil 8*schwarz) und es wird noch besser, und macht ihn in dieser Eigenschaften etwa gleichauf mit dem Atari 800. Dies aber auch mit den Farbzellen von Commodore, und somit das beste von beidem! Selbiges gilt beim Font, umschaltbar Commodore 256er flexibel oder Atari 128er sparsam. Lediglich der Overscan fehlt, wenn auch nur teilweise (nicht horizontal, aber kann mit Rasterinterrupt ausnutzen vertikal, es hat hier keine FarbRAM Limite), plus vor allem die Sprites. Was bei einem Homebusiness Chip auch nicht verwundert, der Name TED (TExt Display) ist hier eindeutig Programm! Spielerechner sind die TED Rechner ohne Sprites und auch ohne Paddles ohnehin nicht. Aber selbst so sind sie besser als den Atari, mit Farben pro Zeichen haben, welche das fehlen dessen schwachen Sprites zumeist aufwiegen kö,nnen! Trotzdem wurde der Plus/4, nachdem er als angeblichen C64 Homecomputer Nachfolger vermarktet wurde, wegen fehlenden Sprites und schwachem Sound unterschätzt und verspottet als Minus/60, trotz in allen anderem gleich gut oder gar leicht besser zu sein!

Platz 2 geht erstaunlich an den VC-20. Er leidet zwar massiv an seiner "halbierten" 160er Raster Auflösung, und nur 23 Zeichen breitem Text. Bitmaps fehlen auch. Aber abgesehen davon hat er einen 256er Font mit 1bpp und 2bpp, und dazu noch FarbRAM auf 8+4=12bit, und sogar Overscan. Als einzigen in dieser Kategorie hat er auch noch Paddles. In obiger Kategorie hätte er nicht nur den VCS/2600 klar geschlagen sondern auch den 800er bedrängt. Hätte er nur 40 Zeichen bekommen wäre er wie beim TED am 800er vorbeigezogen, erstaunlich für Commodore erstmals eine Spielkonsole machen! Damit ist dessen VIC ein erstaunlich guter Chip, der nur wegen seiner geringen Auflösung (sowie dem kleinen 5.5k RAM im VC-20, aber mehr als die 2+2k im NES!) massiv unterschätzt wurde, noch weit mehr als der TED später. (Ebenso unterschätzt wird damit Al Charpentier als Designer von VIC und VIC-II, sowie als einen Einfluss auf den TED, der mit Jay Miner als Designer von TIA und ANTIC/CTIA und Agnus/Denise vergleichbar ist.)

Platz 3 geht dann noch wie erwartet an die MC6847. Hat nur 256er Raster, und das auch nur mit im Chip selber eingebautem festem 64er ROM Font oder 1bpp Bitmap ohne Farbwahl. Sonst nur 128er Raster 2bpp (und das ohne Schwarz), oder 8+1 Farben mischbarer 2x2 Blockgraphik oder 4+1 Farben unmischbarer 2x3 Blockgrpahik mit Schwarz (aber nur 2*32=64 breit, und ohne SAM Tricks nur 2*16=32 oder 3*16=48 hoch). Dazu noch Prozessortakt 7/8 gebremst. Da hilft auch nicht mehr, dass er oft mit einer 6809 daherkommt (wie in TRS-80 CoCo und Dragon 32/64, aber im Acorn Atom mit einer 6502, oder gar im NEC PC-6001 mit einer 8049(!)). Damit ist er der mit Abstand schwächste Chip hier, noch unterhalb einiger TTL Rechner.

8bit ohne Customchips (inkl solchen mit MC6845 Timing und/oder Datenpfad Gatearrays)

Platz 1 und 2 gehen mit Abstand gleichauf an den Acorn BBC Micro und den Amstrad/Schneider CPC. Deren 640er Raster liefern bis zu 80 Zeichen trotz 8Pixel breit, für viel Text. Aber viel entscheidender sind beim 320er Raster bereits 2bpp und vor allem beim 160er Raster volle 4bpp. Damit können diese selbst ihre primitive Logik und das Fehlen von Sprites komplett wettmachen! Mit in 4bpp nur 2 160er Pixel in einem Byte ist selbst fehlendes fein scrollen mit den MC6845 Anfangsadressen problemlos. Wo exakt sie in obiger "mit Sprites" Kategorie landen würden ist offen. Wohl irgendwo unter dem Commodore 64 aber über dem Atari 800, ziemlich sicher oberhalb vom TMS9918, vermutlich zwischen diesem und der Famicom/NES. Damit schlagen sie erst recht locker alle der "ohne Sprites" Kategorie, und hier in dieser sowieso. Einziger Preis ist der Verbrauch sehr von viel Videospeicher (beim BBC 20.5/16/10.25/8k, im CPC fest 16k), und viel CPU um diesen umzuschaufeln. Was deren 2MHz 6502 bzw 4MHz Z80 aber auch recht gut können (gerade auch die Z80 mit ihrem eingebauten LDIR/LDDR Blockkopierer, die 16k werden in etwa 0.1s gescrollt). Damit sind diese eigentlich erstaunlich moderne Rechner, welche die Methoden heutiger (S-)VGA Rechner vorwegnahmen. Unter einander kann der BBC mit 256 statt 200 Zeilen und variabel grossem Speicherplatz punkten, aber der CPC mit 3^3=27 statt 2^3=8 RGB Farben gleichziehen.

Platz 3 geht überraschend in die DDR an den KC 85-2 (und 85-3, und erst recht dem 85-4). Bereits beim 85-2 und 85-3 volles 320er Raster mit FarbRAM auf 8x4. Beim 85-4 das FarbRAM sogar auf 8x1 verbessert, und dazu noch die 2bpp Alternative angeboten. Mit 640x256 1bpp und 160x256 4bpp addiert würde das Teil mit obigem BBC gleichziehen, bzw mit 16 Farben statt 8 darüber! All das in nur reines TTL, einfache Struktur, aber sehr wirksam, weil genau das was man braucht, auf etwas über TED Niveau! Auch hier sind in der 85-2 und 85-3 dann 10.25+2.5=12.75k bzw in der 85-4 gar 10.25+10.25=20.5k an Speicher (plus weitere 1.25k simulierter Textmodus Speicher) und viel CPU um diesem umschaufeln der Preis. Was die nur 1.75MHz bzw 1.77MHz gebremste UB880 aber ordentlich belastet (trotz LDIR/LDDR haben), mitsammt "ghosting", was bei der ineffizienten eingebauten Software der 85-2 sehr langsames scrollen in 0.6s ergab!

Platz 4 geht auch erstaunlich an den Sinclair Spectrum. Zwar nur 256er Raster, und nur 1bpp, aber zumindest mit FarbRAM auf 8x8. Damit konnte man bei einem Billigrechner leben, solange man nicht mehr als 2 Farben in einer Zelle haben muss, und dann mit dem "Attribute Clash" kollidierte. Was gerade scrollende Spiele schlecht traf, weshalb viele Spectrum Spiele ein statisches Spielfeld haben, nur bewegte Figuren in Bereichen mit deren Farbe, für so billig ist das akzeptabel.

Platz 5 geht an die Tangerine Oric. Zwar nur 240er Raster, und nur 1bpp, aber zumindest mit Farben auf 6x8 Zellmodus bzw sogar im 6x1 Bitmapmodus. Trotzdem hinter dem Sinclair Spectrum, weil die Attributschalt Spaces bzw Leerplätze noch schlimmeren "Attribute Clash" erzeugen. Damit konnte man bei einem Billigrechner aber auch leben.

Platz 6 geht erst an die IBM PC CGA. Die kann eigentlich ein 640er Raster, oder 320er mit 2bpp, und damit zwei Modi der BBC und CPC, mit dem selbigen 16k Speicher dafür, welchen die 4.77MHz 8088 erst recht problemlos umschaufeln kann. Aber genau der weitere Modus mit 160er Raster und 4bpp fehlt hier massiv. Auch bei 2bpp ist nur eine Farbe frei wählbar, und diese erst noch an die Randfarbe gekoppelt. Dazu kommen noch die festen 3er Sätze ohne Schwarz Farbauswahl, welche die Register/Rand praktisch auf Schwarz zwingen. Daher kommen die vielen für die CGA typischen Spiele mit sw+gn+rt+ge oder sw+cy+vt+ws. Zudem kann die CGA dies nicht bei 1bpp mit FarbRAM und Attributen retten, weil sie nur in Textmodus Attribute hat. Der 1bpp ist wenigstens mit Schwarz plus freier Farbe. Damit fehlen bei Bitmap alle Methoden um die Effekte von Sprites zu ersetzen. Aber auch im Textmodus wird es nicht besser. Zwar hat es hier Attribute, aber kein RAM Font. Was zu dessen Blockgraphik benutzen zwingt, welche aber auch nur 1x2 Blöcke liefert, zu 80x50. Egal was man es versucht, die CGA macht einem einen Strich durch die Rechnung, verhindert gute Graphik und frustriert! (Nur mit dem "Tweak Mode" kommt man mit 2x1 Blockgraphik und 8x2 Font noch auf halbwegs ordentliche 160x100 mit 16 Farben. Weshalb sie trotz dieser Pseudo-Bitmap in der Auflösung selbst hinter den Spectrum und Oric Billigrechnern landet!)

Platz 7 geht dann an den Apple II. Zwar noch ein 280er Raster, aber nur mit 1bpp (mit Schwarzweissmonitor), sonst nur noch 140x192 wenn mit 2bpp (mit Farbmonitor) mit seinen ganzen 2*4 Farben und geringer Auswahl. Dazu kommt dass die 140 Pixel aus 40*3.5 bestehen, weil in 7bit 3.5*2bpp passen, also ein "Zwischenpixel" seine beiden Bits auf 2 Bytes beziehen muss, was diesen sehr schwierig zu programmieren macht! Wenn man schon eine solche Sparschaltung macht, wäre Prozessor auf 7/8 bremsen und Bild 8/7 breiter (wie im Atari 800) angebracht gewesen, für volle C64 Geschwindigkeit muss man mit mehr Schaltung dahinter gehen. Blockgraphik liefert 16 Farben, aber auch nur in 1x2 Blöcke, zu 40x48, und erst noch nicht mit Text mischbar. Text sind nur 64 Zeichen ROM Font, ohne Blockgraphik. Es hat damit zwar 3 Modi aber keiner davon ist wirklich gut, vergleichbar frustrierend wie die CGA, aber noch schwächer. (Bonuspunkte gibt es für die extrem gute Dokumentation, die ganze Schaltung ist im Referenzhandbuch abgedruckt!)

Platz 8 geht dann noch an den Cromemco TV Dazzler. Hier ist nur noch Bitmap, und trotzdem mit dem kleinsten RAM von 0.5k oder 2k, nur 32x32 4bpp bis 128x128 1bpp, im Vergleich zu selbst dem Apple II Bitmap seinen 8k. Damit ist dies die mit Abstand schwächste Bitmapgraphik überhaupt, trotz weit mehr Aufwand als Mehrfachplatine, aber das ist schlicht wegen dem Alter.

8bit ohne Bitmapgraphik

Platz 1 geht eindeutig an den PET bzw die CBM. Ohne Bitmap oder RAM Font oder Farben, zählen in dieser Kategorie nur noch die Anzahl Zeichen und dem ROM Zeichendatz seine Anzahl und Art an Graphikzeichen. Hier sind immerhin 40x25, mit 128+revers Font, und das erst noch mit 2 Fonts zur Auswahl, volles ASCII96+Graphik32 oder ASCII64+Graphik64. Plus im Font eingebaute mischbare 2x2 Blockgraphik, und damit eine Auflösung von 80x50, was die beste Pseudographik aller Zeiten ergibt, das Vorbild für alle anderen.

Platz 2 geht dann an den TRS-80. Wahlweise 32x16 oder 64x16, mit wahlweise ASCII64 oder volles ASCII96. Plus damit mischbare 2x3 Blockgraphik (aber keine weiteren Graphikzeichen), und erlaubt so noch recht viel Auflösung von 64x48 bzw 128x48.

Platz 3 geht noch an die ZX80 und ZX81. Stets 32x24 (stets schmaler TRS-80, aber mehr Zeilen), mit 2x2 Blockgraphik (und damit nur selbige Anzahl von 64x48 Blöcken), aber dafür nicht mal volles ASCII64. Somit entsteht das Minimalste was hier überhaupt noch antreten durfte.

Platz 4 geht dann an die Processor Technology VDM und Sol-20. Zwar stets 64x16, und stets volles ASCII96. Aber nur ein etwas inkonsistenter Satz von Graphikzeichen, ohne jegliche Blockgraphik.

16/32bit Systeme

Platz 1 geht wie zu erwarten an den Commodore Amiga. Mit 640er Raster und bis zu 4bpp oder 320er bis zu 6bpp sind das bis um 64k an Speicher. Damit geht er fast bis an die Grenze von 320x200 8bpp ihren 64k. Dazu kommen jede Menge Features, von vielen Farben ((2*)32 normal/EHB oder 4096 HAM) und Overscan und fein scrollen, bis zu mit Copperliste alles umstellbar (und diese bis beliebiger Zeile pausierbar), sowie viele grosse Sprites. Damit ist er eine sehr gute Erweiterung des Atari 800, praktisch alle dessen Schwächen beseitigt. Lediglich die Bitplanes und ihr "Ghosting" beim scrollen störten gross, hier am schlimmsten, ausser den KC-85/4. Der Blitter ist eher überbewertet, zumal er nur Umkopieren beschleunigt, und das wegen Setup Aufwand erst bei grossen Flächen sich lohnend, wo genau "Ghosting" dann am schlimmsten wird. Der Copper ist da einiges wertvoller, aber nicht wirklich dringlich, weil er letztlich nur alle Rasterinterrupt Techniken beschleunigt. Und den Prozessortakt auf 7/8 gebremst macht er gerade mal wett. Damit gewinnt der Amiga aber trotzdem als den besten Chipsatz der 16bit Generation, aber das vor allem wegen den vielen bpp, und erst noch trotz grosser Auflösung, wenn auch damit weiter bis zu 40% der 7/8 gebremst. Aber auch wegen vieler ausnutzbarer Möglichkeiten, kein Wunder ging die Demoszene vom C64 zum Amiga weiter!

Platz 2 geht auch nicht überraschend an den Atari ST. Selbst mit dem Schwarzweiss Monitor schlagen seine 640x400 1bpp den Mac seine 512x384 1bpp locker, mit 32k um ein Drittel mehr als dessen 24k. Dazu ohne wie im Mac den Prozessor wegen langsamen Speicher zu bremsen. Mit dem farbigen Monitor sind seine 640x200 2bpp und 320x200 4bpp mit 32k genau ein verdoppelter Amstrad/Schneider CPC seine 16k, und damit das doppelte vom ersten Platz derer Kategorie. Sie sind sogar identisch mit einem Amiga solange man nicht dessen Prozessor für mehr bpp opfert! All das aus einem sehr einfachen simplen auf billig gebauten Rechner (anfangs nur $1000, ohne Monitor und Floppy), trotz 4 mal soviel Speicher wie beim Mac (komplett $2500), bzw 2 mal soviel wie dem Amiga, sowie gleichem Prozessor wie dem Mac aber ungebremst, und 1/8 mehr als Amiga falls ungebremst. Er wurde damals ebenfalls ziemlich unterschätzt, gerade auch im Vergleich mit dem Amiga, wenn nicht ganz so extrem wie den TED oder gar dem VC-20. Selbst fehlender Blitter und Copper und Sprites sind mit 4bpp und schnellstem Prozessor nicht so kritisch, wie es damalige Spiele oft zeigten. Fehlende mehr als 1bpp in Schwarzweiss, nicht mal 320x400 2bpp geschweige denn 160x400 2bpp, machen das für Spiele unattraktiv, verlangen nach dem Farbmonitor. Lediglich hat er dort keine über 4bpp und 16 Farben, sowie kein Overscan, was ihn auf den zweiten Platz verweist. (Nur mit 8bpp addieren, trotz damit nur 160x200 haben, hätte er bereits den ersten Platz gleichauf genommen. Mit zudem fakultativ doppeltes Bild mit 40% Prozessor opfern wie im Amiga, als 640x400 2bpp bzw 640x200 4bpp oder 320x200 8bpp, hätte er den ersten Platz alleine genommen!)

Platz 3 geht dann an die Sega Mega Drive. Kann 4*16 Farben, wenn auch nur aus 512. Ein 256 schmales bzw 320 besseres Textfeld mit 4bpp, wenn auch mit horizontal nur Breite aber kein volles Overscan, aber kann inderlaced, was ihn hinter leicht den Amiga stellt. Dazu aber massive 20 mal 32Pixel an Sprites pro Zeile, wenn auch mit unbekannter bpp, vermutlich 4bpp, und somit die besten Sprites überhaupt hier. Auch hier merkt man die Erfahrungen aus Spielhallen Automaten herstellen, weil dieser explizit als 16bit Automatentechnologie in die Konsolen bringen designt wurde.

Platz 4 geht dann an die Nintendo SuperFamicom/SNES. Kann sogar 16*16 Farben aus 32768, mit diese zu 256 zusammenlegbar, aber dies selten genutzt weil ausbremsend. Kann zwei 512 breite Modi (mit Overscan, was ein 384..448 breites Textfeld ergibt), aber auch selten genutzt. Aber sonst nur 256 breit (was aber nur weiterhin 192..224 Textfeld ergibt, und die typische klotzige Schrift wie schon bei der Famicom/NES), was ihn hinter Sega Mega Drive stellt. Kann interlaced, aber auch selten genutzt. Kann viele oder grosse Sprites, aber nicht beides zusammen, weil pro Zeile maximal 34 Zellen zu 8Pixel mit 4bpp an Sprites. Zudem schwach beim langsamsten nur 16/8bit Prozessor. Das Mode 7 pseudo-3D reicht nicht um dies zu retten.

Platz 5 geht dann erst an den Apple Macintosh. Mit für die 16bit Generation eher niedrige Auflösung, sowie gar keine Farben, selbst bei Schwarzweiss nur 1bpp nicht mal Graustufen, geben ihm keine Chance, total abgeschlagen. Dazu wegen langsamen alten Speicherchips den eigentlich guten Prozessor um etwa 25% bremsend. Erst recht ohne Overscan oder Sprites. Schwächstes Bitmap dieser Generation, mit Abstand. Nur die Hälfte mehr Speicher als beim CPC, und nicht mal ein Viertel mehr als beim Acorn BBC und KC 85-4, sowie ohne deren Farben und Modi, alles Rechner welche ich daher über den Mac setze (und diese wiederum unter dem Commodore 64!). Eigentlich eine dumme primitive Kiste, anfangs as Billigrechner mit Ziel von $1000 designt, aber dann wegen der Software als teuren Komfortrechner vermarktet, mit alleine wegen der Werbekampagne finanzieren den Preis von $2000 auf $2500 angehoben! (Selbiges hatten sie schon mit dem Apple II gemacht, einst als minimalistschen Rechner designt, aber dann wegen Graphik und Farbe haben als teuren Powerrechner vermarktet.) Der angeblich "graphische" Macintosh bezieht sich absolut nicht auf die Hardware, zu welcher sein Spitzname "Macintrash" bestens passte, sondern nur auf die Software, welche in 64k ROM mehr leistete als dem Atari ST seine 192k ROM. Das Resultat von 4 Jahre Entwicklung und Optimierung, statt in unter 1 Jahr durchgezogen.

(Trotzdem war die GUI Software für den gebremsten 16bit Prozessor zu viel, und damit schnachlangsam. Was auch für den Atari ST galt, trotz mehr Prozessor. Ebenso dem Amiga, mit dort untertaktet und bei viele bpp noch mehr gebremst. Plus noch visuell unpassender in deren 200 Zeilen Modi, und zudem ohne 6x12 Font keine 80 Zeichen breit sichtbar. Selbiges galt auch mit Microsoft Windows auf 16bit/286er oder gar 8bit/8088 PCs, egal ob mit CGA 200 Zeilen total unpassend, oder EGA erst recht langsam. Erst die 32bit Generation lieferte genug Prozessor (ab 30MHz) und Speicher (ab mehrere MBytes) für GUIs, sowie Harddisk damit ein graphischer Dateimanager nicht schnarchlangsam ist. Ebenso hatten diese erst ausreichend Auflösung für Fenster, mehr als 640x480, für mehr als 80x25 Zeichen mit 8x16 100dpi Font, plus GUI Elemente, plus Fensterrahmen, plus noch genug von anderen Fenstern sehen dass diese sich lohnen. Mit trotzdem genug Farben für Graphik, ab 4bpp, aber weit besser 8bpp. Mit so minimal brauchbar ab 800x600 mit 4oder8bpp aus 256oder512k Bildspeicher, und dann echt besser ab 1024x768 mit 8bpp aus 3/4 MByte oder gar 1152x865 mit 8bpp aus 1MByte voll ausnutzend. Also S-VGA oder Macintosh II oder Atari TT oder Amiga AGA, ab etwa 1990.)

Ganz ausserhalb der Konkurenz ist die IBM PC EGA. Ihre massiven 4*64=256k stellen sie weit ausserhalb der 64k Grenze, disqualifiziert. Aber selbst mit 256k liefert sie nur maximal 4bpp, typisch IBM welche Auflösung mehr schätzt als bpp. So verliert sie bereits gegen dem Amiga seinen 6bpp aus nur 48k! Ebenso fehlen Overscan und Sprites. Damit könnte sie noch auf dem zweiten Platz, wenn nicht mit ihrem 8 mal mehr Speicher massiv teurer als dem Atari ST, der somit hier gewinnt. Die Sega Mega Drive und Nintendo SuperFamicom/SNES verlieren an Auflösung, werden selbst von der EGA geschlagen. Aber gegen ihre Sprites und sonstigen Effekte kann die EGA nichts anrichten. Den "graphischen" Mac schlägt sie aber locker, schlicht weil der keine Farben kann, oder auch nur Graustufen. (Die VGA kommt dann mit MCGA als allererste auf volle 8bpp, und damit vor allen anderen Rechnern hier. Wenn auch nur mit dem bloss 1/4 von ihren 256k ausnutzenden 320x200 8bpp, bis die S-VGA kamen. Das reicht immer noch, solange man keine Sprites braucht, was mit genug Prozessor plus 8bpp weniger wichtig wird. Damit wurde die MCGA der Anfang von allem brauchbaren PC Gaming.)


Home | Artikel | VCFe Video als visuelles Medium

Diese Seite ist von Neil Franklin, letzte Änderung 2018.08.20