Home | Artikel | VCFe Videoarchitekturen als visuelles Medium

VCFe Vortrag vom 2016.04.30 - Homecomputer und Spielkonsolen - Videoarchitekturen 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", bzw genauer als "was kann dieser damit anstellen", was sieht er dabei. Dazu werde ich vor allem Videomöglichkeiten von ein paar guten als Spielkonsolen designten Homecomputern als visuelle Medien vergleichen. Aber der Vollständigkeit halber hab ich auch noch nach und nach weitere graphischen Rechner als Übersicht 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 3D 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 mit ihrem MCGA Modus und dessen 320x200 8bpp (braucht 64k) wurde dieser Ansatz benutzbar, weil 8bpp für RGB 6*6*6=216 Farben oder RRGGBBII 4*4*4=64 Farben in 4 Helligkeitsstufen tauglich ist (wie in vielen damaligen PC Spielen gesehen). Ab SVGA 640x480 8bpp (braucht 300k) wurde es auch komfortabel (nur 640x400 passten noch in 256k), mit 80x30 Zeichen in 8x16 Font zugelassen. Ab 800x600 16bpp (braucht schon 1024k) wurde es dann ausgereift, weil diese 16bpp für RGB 32*32*32=32768 Farben Truecolor tauglich sind, und 800x600 etwa ein volles PAL 567i Fernsehbild ist, und 80 Zeichen zu 8 Pixel ihre 640 Breite nun auch in Fenster passen. Somit sind 320x200 in 64k die untere Grenze an für beliebiges brauchbarer Auflösung.

Alle Rechner mit nur 4/8/16/32k an Videospeicher (oder gar ganzem Speicher) liegen darunter, und sind selbst für minimales 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. Gefolgt von 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 Objektdaten der Spiele in den Rechner einzugeben!

Die Spielregeln

Zuerst einmal die Auswahlkriterien welche Rechner hier überhaupt angeschaut und verglichen werden. Weil es hier um Videoarchitekturen 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. Inszwischen sind es 36 Videokarten und Computer und Konsolen geworden, 28 8bit und 8 16bit.

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 (DMA Logik und Videogenerator) für beliebige S100 Bus Rechner (wie dem MITS Altair 8800 (1975)). Früh erschienen, daher alles reine TTL Logik, keine Customchips, dementsprechend primitiv.

Nur 4 Bitmapmodi, 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, wobei mit eigenem Speicher die DMA Logik um Speicher zu teilen weit vereinfacht wäre. Braucht wegen Timing aber SRAM, was damals mit kleinen 1kx1 SRAMs nur 1k mit 8-Chip, bzw 2k mit 16-Chip ergab, oder 4k mit sehr teurem 32-Chip.

Bitmap daher nur in 2 Grössen von 0.5k oder 2k Speicher umschaltbar, dies 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 jedes Pixel volles RGBI, bzw hier stets als IBGR angeordnet. Dabei erlaubt RGB 000=Schwarz, 111=Weiss, 100 010 001 die 3 Grundfarben Rot Grün Blau, sowie 110 101 011 ihre 2er Kombinationen Gelb Magenta/Violett Cyan/Blaugrün. Nur RGB sind aber binär unfreundliche 3bpp, also erweitert man oft auf 3+1=4bpp mit I, welches von normale/dunkle auf intensive/helle Versionen davon schaltet. Bei nur 1bpp ist dagegen 0=Schwarz und 1=Farbe mit IBGR aus einem einzelnen Register.

Aber selbst die "grossen" 2k mit 64x64 bei 4bbp sind eine sehr geringe Auflösung für Spiele, praktisch auf Blockgraphik Niveau. Und 1bpp ist praktisch nur für Diagramme brauchbar. Und selbst dessen "grosse" 128x128 erlauben 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 ist der TV Dazzler fast nur als Kuriosität nutzbar. Und hier um zu zeigen wie man von den untersten 64k in der Einführung 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-1 und Sol-20 (1976)

Die VDM-1 ist kein Rechner, sondern ebenfalls eine S100 Bus Karte. Diese ist aber nur eine Karte, mit alles separatem Videospeicher (VRAM) und DMA Logik und Videogenerator drauf. Aber nur in Schwarzweiss, was den Analogteil massiv vereinfachte, sowie nur dem eigenen separaten VRAM benutzend, was die DMA Logik weit einfacher machte. Dies erlaubt zudem trotz langsamen 1MHz SRAMs den Prozessor ungebremst im Hauptspeicher laufen zu lassen, mit bei Zugriffen auf Videospeicher dessen geholte Videodaten kurz ausnullen.

Der Sol-20 ist dagegen ein vollständiger Rechner, mit einer VDM-1 fest eingebaut, wenn auch nur als intelligentes Terminal vermarktet. Strikte war die Absicht ein Terminal zu machen, aber Aufpreis für eine 8080 statt einges an Logik war nur etwa $10, und dafür bekam man ein intelligentes Terminal, mitsammt Ausbaubarkeit zu einem vollen Rechner.

Das VRAM ist halbwegs zwischen obigen 0.5k oder 2k, mit 1k SRAM (sowie nur 1k sonstiges SRAM im einem nicht erweiterten Sol-20, weil eben nur als Terminal). Ebenfalls früh erschienen, daher alles reine TTL Logik, keine Customchips, dementsprechend primitiv. Trotzdem aber mit vollen Textmodus, weil eben Terminal.

Dieser 1 Textmodus hat 64x16 Zeichen. Mit 9x13 Font (7von9 breite Zeichen, 9von13 hoch), damit (64*9=576)x(16*13=208) Pixel. Aus festem ROM Satz, von 128+modifiziert (= reverser oder blinkender Cursor) Zeichen, mit neben 96 ASCII auch noch 32 Graphikzeichen drin. (Es verwendet dazu ein 6574 oder 6575 Font ROM, ersterer mit einem etwas inkonsistenten Satz von Graphikzeichen, mit Blockgraphik nur unvollständig drin, zweiterer mit den ASCII Steuerzeichen Kurzcodes, damit strikte hier ausscheidend.) Beliebig vertikal in Hardware scrollbar um umkopieren zu sparen, weil auf Videokarte umdesignt aber anfangas für ein prozessorloses Terminal geplant. Bei 64*9=576 von 14.31818MHz Pixeltakt ein mittleres 40.2µs Textfeld. Dies reicht anstelle eines Terminals um Programme oder Daten einzugeben, ist aber mit nur ASCII Art zu limitiert um Spiele zu machen.

Dies zeigt wie man zu viel Auflösung trotz wenig Speicher kommt: Durch wenige Zeichencodes an Speicher (1k) per Font ROM (0.5k) in viel mehr Pixel übersetzen, sowie Farben weglassen, aber zum Preis von wenigen festen Pixelmustern und nur Schwarzweiss.

Apple II (1977)

(Davor war der Apple 1 (1976). Dieser hatte nur Text, 40x24 Zeichen, mit Font festem 2513 ROM Satz, von 64 ASCII Zeichen. Darin hatte es keinerlei Graphikzeichen, er konnte nur reduzierte ASCII Art, und scheidet damit hier aus. Aber weit schlimmer hatte er nur 1kx6(!)bit MOS Schieberegister als Videospeicher, keine Cursorsteuerung, war somit nicht adressierbar, konnte kein vorzu veränderbares Bild, nur eine reine Fernschreiber Emulation. (Dieses war eine erweiterte Variation des Don Lancaster TV Typewriter (1973), der aber nur 32x16 Zeichen hatte, mit selbigem Font ROM.) (Wer mehr zum Apple 1 Rechner und sein Video wissen will, kann meine detailierte Analyse von dessen Hardware und Software lesen.))

Der Apple II entstand, nachdem der Apple 1 Designer Steve Wozniak diesen dem 6502 Prozessor Designer Chick Peddle vorführte, und statt Lob einen Zusammenschiss kassierte, wonach er keine Ahnung habe, wie man mit Mikroprozessoren designt, gefolgt von einer Lektion wie man es macht. Mit dem Apple II hat Wozniak diese Lektion umgesetzt, und dazu noch massiv erweitert. Es brachte vor allem den Ersatz der 1kx6bit MOS Schieberegister durch einen 1kByte Ausschnitt vom normalen DRAM Hauptspeicher, und damit beliebig adressierbar und veränderbar. Weil Rechner und Graphik integriert sind, mit sehr einfacher DMA Logik. Ebenfalls früh erschienen, daher alles reine TTL Logik, keine Customchips, dementsprechend ziemlich primitiv. (Der II Plus (1979) unterscheidet sich nur in der erweiterten Software, sowie Power-On Reset Logik, und ein paar andere Korrekturen.)

Trotzdem hat er aber umschaltbar 3 Modi, Text und Blockgraphik und Bitmap:

Text 40x24 Zeichen. Mit 7x8 Font (5von7 breite und 7 von 8 hohe Zeichen), damit (40*7=280)x(24*8=192) Pixel (vergleichbar gepackt wie VDM-1 und Sol-20). Aus festem ROM Satz, von 64+revers+blinkend Zeichen, keine Graphikzeichen, auch nur reduzierte ASCII Art. Verwendet das identische 2513 Font ROM wie Apple I. Bis hier ist er pixel-identisch mit dem Apple 1. Es wurden aber wegen Hauptspeicher mit 6+2=8bit nutzen, die beiden extra Bits für reverse und blinkende Darstellung benutzt. Wegen der 2MHz Bandbreite vom 4116 DRAM Speicher (1MHz für Prozessor und 1MHz für Video) kann er dies ohne den Prozessor zu bremsen (Apple 1 hatte nur 1MHz 4096 DRAM Speicher). Bei 40*7=280 von 14.31818/2=7.16MHz Pixeltakt ein eher schmales 39µs Textfeld. Dies kann gar keine Graphik, auch nicht Graphikzeichen, reicht aber als Terminal um Programme oder Daten einzugeben, er würde aber mit nur diesem hier ausscheiden (wie es der Apple 1 auch tut).

Dabei kann er aber wegen 40 Zeichen pro Zeile keine 2^n sein (wie bei 32 oder 64 Zeichen) nicht einfach die X und Y Koordinaten als Speicheradresse zusammenlegen. Sie müssen als Y*40+X umgerechnet werden, was mit Y*32+Y*8+X strikte nach 2 10bit Addierern verlangt, was 6 4bit Chips braucht. Erkennen dass dies (Y*4+Y)*8+X sind, erlaubt Bit0..2 direkt von X, ohne Addierer, nur noch 2 7bit Addierer in 4 4bit Chips. Dazu wird im Apple 2 aber nur 1 4bit Addierer benutzt! Dafür liegen die Zeilen aber nichtlinear im 1kByte Speicher. Dieser ist in 8*128Bytes aufgeteilt, mit in 128 je eine 3er Gruppe Zeilen 0+8+16, 1+9+17, .., 7+15+23, zu je 3*40=120Bytes plus 8 unbenutzte. Ausgelesen werden dann alle 8 ersten 40er, dann 8 mittlere, dann 8 letzte. Was aber nur 8*3=24 Zeilen und *40=960 Zeichen erlaubt, die eigentlich in 1k passenden 40x25 Zeichen verhindert. (Apple 1 hat auch nur 40x24 wegen einer vergleichbaren Vereinfachung im Timing der Steuerung des Schieberegister Videospeichers.)

Separate Blockgraphik "Low Resolution" ohne Font hartverdrahtet, mit selbigen 40x24 Zellen in selbiger Anordnung, aber diese statt als 64 Zeichen (6bit) in 3 Darstellungen (2bit) in nur 1x2 Blöcke (je 4bit) zerteilt (ergibt ganze 40x48). Dabei werden diese mit 2*4bit definiert (Bit0..3 oben und Bit4..7 unten). Was somit 16 Farben erlaubt (wie TV Dazzler).

Diese werden aber hier als NTSC statt RGBI Farben spezifiziert. Diese nutzen aus, wie Farbfernsehen als Erweiterung von bestehendem Schwarzweiss definiert wurde. Statt RGB zu senden, werden neben der Helligkeit Y = R+G+B für Schwarzweiss, nur noch 2 Farbdifferenzen U = B-Y und V = R-Y gesendet. Diese werden als Form von analoger Datenkompression mit niederer Frequenz (= Details) gesendet (Schwarzweiss liefert Details). Sie werden um weiter Bandbreite zu sparen mit dem Y gemischt, aber damit man sie wieder trennen kann beide auf einen 3.579646MHz Träger gesetzt, bzw zwei solcher mit 90grad Phasenverschiebung damit diese sich nicht stören. Dadurch wird der Farbton zum Phasenwinkel der Summe der beider Träger, die Farbsättigung zur Stärke des Trägers (ohne ist total entsättigt = Schwarzweiss), und Helligkeit ist ohnehin das normale Schwarzweiss Signal.

Der Apple II erzeugt nun NTSC Farben durch die obigen 4bit als "Viertelwellenpixel" Muster nutzen, welche pro Bit einen 14.31818MHz Takt lang wirken, mit somit 4 zusammen eine von 2^4=16 möglichen 14.31818/4=3.579MHz Schwingungsformen definieren, welche der NTSC Videomonitor zum einfärben auswertet. Wobei gilt 0000=Schwarz und 1111=Weiss weil gar keine Schwingung, und 0101=1010=Grau beide weil eine 14.31818/2=7.159MHz Schwingung, beides keine 3.579MHz und damit eben total entsättigt! Anderseits werden alle 0011 0110 1100 1001 zu mittlere/50% Farben (Violett Blau Grün Orange), alle 0111 1011 1101 1110 zu helle/75% Farben (Cyan Gelb Rosa Hellblau), alle 0001 0010 0100 1000 zu dunkle/25% Farben (Magenta Dunkelblau Dunkelgrün und Dunkelrot/Braun), weil mit 3.579MHz Schwingung, und davon Phase/Farbton aus der Bitanordnung, und Helligkeit aus der Bitzahl. Dies ist aber wegen 40x48 extrem klotzig, und daher unbrauchbar für Terminal, sowie limitiert für Spiele.

Aber dieser Farbtrick geht nur mit einem NTSC Farbmonitor. Der Apple II Europlus kann zwar das 50Hz statt 60Hz Schwarzweiss Timing von PAL Monitoren ansteuern, aber keine Farben. Das weil diese für Farben 17.734472/4=4.336MHz Schwingungen statt 14.31818/4=3.579MHz bräuchten. Genauer meint das Handbuch, dass es auch bei PAL Monitoren Farben gibt, welche aber "abweichen können" ("colors generated may differ").

(Dies alles wurde für Breakout-artige Spiele addiert, wo solche Klötzchen graphisch ausreichen. Der Apple 1 und II Designer hatte für Atari am Breakout Spielautomaten optimieren gearbeitet. Aus selbigem Grund hat der Apple II auch seine Paddle/Analogjoystick Anschlüsse und Beep bekommen.) (Dieser Modus wäre besser gewesen mit 2x1 Blöcken, und dann 2*24=48 Zeilen in 2kByte DRAM Speicher, für 80x96 statt 40x48.)

Dazu Bitmap "High Resolution" (40*7=280)x(8*24=192) 1bpp Bitmap. Für 192 Zeilen wurde der Speicherausschnitt auf 8* 1kByte erweitert. Um Adressleitungen umschalten zu sparen wurden die 3bit Videozeile in Zeichenzeile vorne an die bestehenden 10bit Adressen zusammengelegt. Damit ist es noch mehr nichtlinear, 8 Sätze zu 8 * 3 Gruppen, mit nur Zeilen 0,8,16,24,..,184 wie oben als 0+64+128, 8+72+136, .., 56+120+184, aber dann 1,9,17,25,..,185, .., 7,15,23,31,..191 als 7 weitere mal 8 * 3. Mit Schwarzweissmonitor sind es direkte 280x192 Pixel, 8*3*8 Zeilen zu 40* 7bit.

Mit Farbmonitor ist es weit komplizierter, das Bitmap wird dabei als direkt binär codierte "Halbwellenpixel" Muster benutzt, welche pro Bit zwei 14.31818MHz Takte lang wirken, 2 davon eine 14.31818/2/2=3.579MHz Schwingung definierend. Farben sind 2 Farbsätzen zu je 4 Farben, Sw+Vt+Gn+Ws (00+01+10+11 sind obige 0000+0011+1100+1111) bzw Sw+Bl+Or+Ws (00+01+10+11 sind obige 0000+0110+1001+1111), je nach ob Farbattribut Bit7 =0 oder =1 ist. Bit7 tut nur die 7 anderen Bit0..6 Pixel um einen 14.31818MHz Takt verzögern, 0011 zu 0110 und 1100 zu 1001, was sie anderst einfärbt Vt zu Bl und Gn zu Or. Es kann kein Grau oder 25% oder 75% entstehen, nur Schwarz und Weiss sowie 50%.

Dabei entsteht in erster Näherung eine Art pseudo-2bpp mit 3.5(!) "Pixel" pro Byte, 7 "Pixel" in 2 Bytes, wobei jeweils von einem "Zwischenpixel" seine beiden Bits als "Halbpixel" auf 2 Bytes verteilt werden. Es wird zuerst (= links im Bild) das niederwertigstes Bit (= rechts im Byte!) dargestellt. Dabei sind 2 Bytes mit 7 "Pixel" a bis g, dann verteilt als: (0)d.cc.bb.aa (0)gg.ff.ee.d, womit neben d verteilt auch a bis c bzw e bis f verschieden angeordnet sind für die gleiche Farbe! Eine ganze Zeile Grün=10 ist somit abwechselnd (0)0.10.10.10 und (0)10.10.10.1, diese 2 Bytes 40/2=20 mal wiederholt. Das ist so kompliziert mit 7 von 8 um nicht den Prozessor mit 14.31818/16=0.895MHz auf 7/8 gebremst laufen zu lassen, sondern mit 14.31818/14=1.0227MHz, was eben bereits einen Speicherzugriff alle 7 Pixel (bzw 3.5 "Pixel") ergibt, statt alle 8 (bzw 4), mit so nur Zeit um 7 Bits als Pixel zu versenden.

Strikter betrachtet ist das Signal bei Schwarzweiss und Farbe genau das selbige, stets 40*7=280 Pixel ohne jeglichen Schalter, nur der Monitortyp macht einen Unterschied, je nach ob er Farbsignale auswerten kann! Dabei gilt stets 000...=Schwarz und 111...=Weiss, egal wo anfangend oder endend, egal ob innerhalb eines Bytes oder über Bytegrenzen hinweg, egal welcher Monitortype. Der Monitor bekommt ohnehin nur 280 Pixel ihre Wellenformen, keine 40 Bytes zu 1+7 Bits! Schwarzweissmonitor zeigt sie einfach direkt als 280 Pixel 1bpp an. Farbmonitor "verschmiert" sie zu 140 "Doppelpixel", aber diese weiterhin im 280er Raster angeordnet, mit bei Bitwechseln 0zu1 bzw 1zu0 wegen entstehendem 14.31818/4=3.579MHz Signal dieses als Farbsignal (miss-)interpretierend, sie daher einfärbend.

Das aber mit Farben abhängig von ihrer Position in der Zeile, und davon die Phasenlage des Farbsignales! Weshalb eine einzelne 1 von 0-en umgeben bei geraden Pixeln 0,2,4,..,278 zu Violett (bzw wenn mit Bit7 verzögert Blau), aber bei ungeraden 1,3,5,..,279 zu Grün (bzw verzögert Orange) wird! Mehrere 10101... anfangend bei 0,2,4,..,278 sind langes Violett, selbiges anfangend bei 1,3,5,..,279 aber langes Grün. Jeder 01 zu 10 oder 10 zu 01 Wechsel ergibt dort wo sie zusammenkommen ein 11 bzw 00, und damit einen weissen bzw schwarzen "Übergang", je nach wie scharf oder schmierend der Monitor ist. Dieses Bitmap ist für Terminal weniger wert, aber für Spiele besser.

(Dies wurde auch nur addiert weil mit leichter Erweiterung der Blockgraphik Schaltung machbar! Der Farbattribut Bit7 Verzögerer ist sogar ein Flick der Erweiterung, der auf Revision 0 Boards noch nicht vorhanden war. Es ist trotzdem die einzige echt brauchbare Graphik, wenn auch wegen der doppelt nichtlinearen Adressen plus verstreuten Bitanordnung schwierig zum programmieren!) (Leider kann man den einfärben Effekt nicht ausschalten, um auf Schwarzweissmonitore ausgerichtete Programme auch auf Farbmonitor in 280x192 zu sehen, ohne bei 1 Pixel schmalen Details diese "verschmiert" und in Falschfarben zu bekommen. So ein Ausschalter ist eigentlich vorhanden, und im Textmodus auch aktiv. Wobei dieser auch ein Flick ist, der auf Revision 0 Boards noch nicht drauf war, und daher wegen Modusschalter kompatibel bleiben nicht voll durchgezogen werden konnte.)

Es ist zudem möglich, oben 40(/2*8=160) Zeilen Blockgraphik oder (20*8=)160 Bitmap mit unten 4(*8=32) Zeilen Text zu mischen. In diesem Fall scrollt die Systemsoftware auch nur in diesen 4 Zeilen, bzw sie kann ohnehin jederzeit auf beliebige horizontale und/oder vertikale Ausschnitte scrollen eingestellt werden. Mit volle 40x24 oder untere 40x4 nur als zwei Standardfälle. Dies wurde gerade auch in graphischen Adventures genutzt, für Illustration oben und Text unten.

Dies alles zeigt einen weiteren Ansatz: Mit flexibel sein durch Modi umschalten, für entweder Text mit Font aber Pixelmuster limitert (wie VDM-1 und Sol-20, oder Blockgraphik mit Farben aber geringe Auflösung (wie TV Dazzler), oder aber Bitmap mit Auflösung und etwas Farben aber grossem 8k statt 1k Speicherbedarf.

(Der Nachfahre Apple IIe (1983) erweiterte Text auf 96 ASCII Zeichen, aber keine Graphikelemente, und das auch nur bei Normaldarstellung, nicht bei revers oder blinkend. Dazu noch falls mit 1k SRAM Speichererweiterung "80-column" doppelter Text 80x24. Das ist noch nichtlinearerer, mit alle Zeichen 0,2,4,..,78 in den addierten 1k, sowie 1,3,5,..,79 im "alten" 1k Speicher (beide in den selbigen 1k an Adressen, aber mit einem Umschaltbit für welcher im Prozessorzugriff ist). Dazu auch ab Revision B auch "Double Low Resolution" Block 80x84, sowie falls mit 64k DRAM Speichererweiterung "extended 80-column" sogar "Double High Resolution" Bitmap 560x192 1bpp bzw 140x192 pseudo-4bpp. Letzteres ist dabei nochmals schlimmer, weil das 40x25 nichtlinear, plus das 280x192 verachtfachen, plus das 80x25 doppelte Speicher, plus jetzt 7 Pixel a bis g sogar in 4 Bytes als Bits neu:0bbbaaaa alt:0ddccccb neu:0feeeedd alt:0ggggfff (wenn auch ohne die Farbattribut Bit7 verzögerung), aber dafür hatte es alle 16 Farben weil mit 4bpp nun auch volle "Viertelwellenpixel" (daher auch kein verzögern mehr). Auch das strikte nur ein Signal, bei Schwarzweiss 560 Pixel, bei Farbe "verwischt" zu 140 "Pixel" in 560er Raster.)

Tandy TRS-80 Model 1 (1977)

Früh erschienen, alles reine TTL Logik, keine Customchips, und billig, dementsprechend recht primitiv. Direkt im Rechner eingebaut (wie Apple II), aber mit separatem 1k VRAM aus SRAMs (wie VDM-1 und Sol-20), aber nur Bits 0..5 und 7 (kein Chip für Bit6!), und ebenfalls einfache DMA Logik, ebenfalls mit bei Zugriff Videodaten kurz ausnullen.

Hat nur 2 Textmodi. Text 32x16 (für Fernseher statt Monitor) oder 64x16 Zeichen (letzteres wie VDM-1 und Sol-20). Bei 32x16 wird jedes zweite Zeichen im VRAM übersprungen. Mit 6x(8von12) Font. Aus festem ROM Satz, von 64 ASCII Zeichen (strikte hat das ROM 128 Zeichen Adressen, aber nur 32..95 werden genutzt). Dazu aber vom Modusattribut Bit7 gesteuert ohne Font hartverdrahtete aber mit dem Font mischbare 2x3 Blockgraphik in Bit0..5 (gibt 64x48 bzw 128x48). Bei 64*6=384 von 10.6445MHz Pixeltakt ein recht schmales 36.1µs Textfeld.

Nur Schwarzweiss, auf dem separaten aber mitgelieferten Videomonitor (bzw ab Model 2 ist dieser eingebaut). Wie Apple II reicht dies als Terminal um Programme oder Daten einzugeben. Es ist aber auch mit 64x48 bzw 128x48 halbwegs brauchbar für einfache Spiele, eher Vollbild Actionspiele mit Text irgendwo im Bild.

Dies zeigt einen weiteren Ansatz: Ebenfalls mit Font kompakt, aber weniger limitiert wegen mit Text beliebig mischbarer Blockgraphik, weshalb auch kein Modusschalter nötig ist, bzw dieser als ein Modusattribut zeichenweise ist.

Commodore PET 2001 (1977)

Früh erschienen, alles reine TTL Logik, keine Customchips, und billig, dementsprechend auch recht primitiv. Direkt im Rechner eingebaut (wie Apple II), aber mit separatem 1k VRAM aus SRAMs (wie VDM-1 und Sol-20 und Tandy TRS-80 Model 1), und ebenfalls einfache DMA Logik. Aber ohne bei Zugriff Videodaten kurz ausnullen, weshalb der zufällig gerade getroffene dargestellt werdende Zeichenausschnitt durch ein beliebiges anderes ersetzt wird, was zum kurzen aufflackern zufälliger Pixel fürht, und als "Snow" (= Schnee) bekannt ist.

Hat nur 1 Textmodus. Text 40x25 Zeichen (etwas mehr als Apple II seine 40x24). Mit 8x8 Font. Aus zwei festen ROM Sätzen von 128+revers Zeichen (wie VDM-1 und Sol-20). Diese haben neben 64bzw96 ASCII auch 64bzw32 Graphikzeichen drin. Weit bessere solche, inklusive 8 Zeichen (*2 mit revers) für im Font integrierte mischbare 2x2 Blockgraphik (gibt 80x50), und viele andere Graphikelemente. Die beste Pseudographik, weil auch noch einen Satz Zeichen ohne Kleinbuchstaben für 64 statt 32 Elemente, neben einem Satz mit Kleinbuchstaben aber nur 32 Elemente. Bei 40*8=320 von 8MHz Pixeltakt ein mittleres 40µs Textfeld. Nur Schwarzweiss, auf dem eingebauten 9" Monitor.

Dabei kann er (wie Apple II) wegen 40 Zeichen pro Zeile keine 2^n sein nicht einfach die X und Y Koordinaten als Speicheradresse zusammenlegen. Es gibt aber auch keinen Y*40+X Addierer, sogar gar keinen Addierer! Statt dessen wird eine separate Adresse gezählt, welche in den ersten 7 von 8 Videozeilen einer Zeichenteile wieder auf den Anfang dieser gesetzt wird, aber in der achten Videozeile weiterzählen darf. Weshalb die Zeilen hier auch linear im Speicher liegen, und somit volle 40x25=1000 plus nur 24 unbenutzte Bytes machbar sind. Der Mehrbedarf an Chips (3 Address statt 1 Addierer in Apple II) wird teilweise kompensiert durch keinen vollen Zeilenzähler haben (was wiederum 2 Chips spart).

Dazu noch die ganzen Graphikzeichen auf der Tastatur abgebildet, um sie mit Shift einzugeben, was zusammen mit vielen solchen sehr gut ist. Wie Apple II und TRS-80 Model 1 reicht dies als Terminal um Programme oder Daten einzugeben, mit 40x25 besser als 40x24 oder 64x15. Es ist aber auch mit 80x50 und Elemente auch halbwegs brauchbar für einfache Spiele, wieder eher Vollbild Actionspiele mit Text und Elemente irgendwo im Bild.

Dies zeigt einen weiteren Ansatz: Ebenfalls mit Font kompakt, aber weniger limitiert wegen vielen mit Text beliebig mischbaren Graphikzeichen, und das direkt im Font, weshalb auch kein Modusschalter oder Modusattribut nötig ist, und das wiederum mehr Zeichen erlaubt.

(Die Nachfahren CBM Serie 3000er bzw PET 2001N (1979) sind leicht überarbeitet für mehr Speicher, mit 1* oder 2* 16k DRAM statt PET 4* oder zumeist 2*4* 1k SRAM, aber selbige 1k VRAM aus SRAMs. Dieses aber 2MHz fähig, und damit kein "Snow" mehr. Sie haben besseres Basic 2.0, und echte Tastatur, sowie externes Kassettenlaufwerk. Serie 4000er (1980) haben selbigen Speicher und Video, aber verbessertes Basic 4.0. Serie 8000er und neuere 4000er (1981) haben einen MOS6545 Timing Chip (eine Variante des später beschriebenen MC6845), einen grösseren 12" statt 9" Monitor, und die 8000er Modelle darauf 80x25 Zeichen. Letztere zumeist aus 2* 1k VRAM welche parallel als 16bit gelesen werden, mit erst ab dem Font ROM doppelt getacktet, statt allen anderen ihren 40x25 aus 1* 1k. Die 8096 addiert nur eine 64k Speichererweiterung von 32k auf 96k. Die 8296 hat dann aber nur noch 2* 64k DRAM, liest Video ohne separates VRAM aus dem ersten dieser 64k, nur 8bit breit, weil inzwischen mit sogar 4MHz Zugriffen auf schnellere DRAMs.)

Atari VCS bzw 2600 (1977)

Reine Spielkonsole. Ein Schritt aufwärts, zu Prozessor und Spielmodul ROMs benutzen, statt nur hartverdrahteter Pong (und Derivate) Logik. Minimale Hardware, nur 6507 (28pin 6502 die max 8k Seicher nutzen kann) und 6532 (RAM 128Bytes + IO 2*8bit + Timer) und steckbares Modul ROM (max 4k nutzbar), was praktisch einen erweiterbaren 3+1-Chip Mikrocontroller mit ersetzbarer Firmware ergibt. Dazu einzelner Customchip TIA (Television Interface Adaptor), für Video und Audio und Paddles und Feuerknöpfe, dementsprechend extrem primitiv. Hat nur 1 Bitmapmodus, wegen dies einfacher sein als Textmodi und auch passender für Spiele.

Aber Bitmap trotz extrem wenig Speicher von nur 128Bytes. Das Bitmap ist nicht mal in diesen, sondern nur 40x1(!) 1bpp, aus nur 20 Pixel/Bits an TIA chipinternem VRAM als (4+8+8=)20bit in 3 Registern, welche zweimal pro Zeile ausgegeben werden, das zweite mal per Schaltbit gerade wiederholt oder reversiert gespiegelt! DMA Logik braucht es gar keine, weil diese Bits als internes Dualport RAM verdrahtet sind, nicht von extern geholt werden. Diese nur 40 Pixel ergeben die typischen "klotzigen" Spielfelder der Spiele der VCS/2600. Alle Zeilen werden identisch wiederholt, was nur vertikale Streifenmuster ergibt, ausser die Software überschreibt zeilenweise vorzu die TIA Register! Die Anzahl genutzter Zeilen ist damit ebenfalls rein per Software gegeben.

Dazu Sprites, 2 Player 8x1 1bpp (8bit Register) in horizontal 160/80Pixel schaltbarem Raster, sowie 2 Missile und 1 Ball 1x1 (3 2bit Register) als horizontalen 160/80/40/0Pixel Block, alle auf 160er positionierbar (die Läge einer Welle vom NTSC Farbträger Signal. Wieder alle Zeilen identisch ausser von Software überschrieben oder ausgeschaltet. Damit war er aber der erste Rechner mit Sprites, wenn auch diese von Atari noch Player Missile Graphics (PMG) genannt werden.

Farben mit Register auswählbar aus 16*8=128 (16 NTSC Farbtöne "Chroma", in expliziten 8 Helligkeitsstufen "Luma"), und damit eigentlich völlig überdimensioniert. Hat 2 Register für Spielfeld Vordergrund und Hintergrund, 2 für die beiden Player und deren Missiles, 1 für denn Ball, zusammen 5. Mit den 160/80/2*20Pixel werden pro Pixel genau 1/2/4 Zyklen 3.579646MHz NTSC Farbwellen ausgegeben. Diese Farben sind ebenfalls zeilenweise durch die Software überschreibbar, was die typischen "streifigen" Farben mancher VCS/2600 Spiele ergibt. Bei 160 Pixel von 3.579646MHz Takt ein 44.7µs breites Textfeld.

VCS/2600 Spiele ihre Software besteht wegen alle Zeilen gleich sein vor allem daraus, während dem Bild ausgeben vorzu synchron alle Register umzuschreiben, die Spielfeld Pixel ersetzen, sowie Player Muster und Missile/Ball Breite/Aus setzen, sowie die Farben anpassen. Dies kann sogar während in der Zeile drin mehrfach gemacht werden, was als "Racing the Beam" bekannt ist. Dafür ist zwecks synchronisierung die aktuelle Zeilennummer auslesbar, sowie der Prozessor bis zur nächsten Zeile per Waitstates pausierbar. Zudem zwischen den Bildern die Joysticks bzw Paddles abzufragen und mit der Spiellogik auszuwerten inklusive Sprite Positionen setzen, sowie auch den vertikalen Rücklauf auslössen.

Mit 3.579646/3=1.19318MHz 6507 Prozessor passen in eine Zeile von 63.5us NTSC bzw 64us PAL nur (160+88=228)/3=76 Speichertakte, was bei 2 oder 3 Takte in den meisten Befehlen der 6507 für nur etwa 30 davon ausreicht! Wegen dies, plus dem geringen 160er bzw 40er Raster, verwenden viele Spiele einen "Zweizeilen" Ansatz mit Doppelzeilen, in welchem zeilenweise abwechselnd das Spielfeld oder die Spielobjekte ersetzt werden, was um 1 Videozeile verschobene Doppelzeilensätze ergibt.

Dies zeigt einen weiteren Ansatz: Auflösung trotz fehlendem Speicher, durch horizontale Auflösung mit Sprites punktuell verbessern und vertikale Auflösung in Software implementieren, sowie viele Farben trotz nur 1bpp (plus Sprites) mit Farbregister übersetzen. Es ist damit brauchbar für Spiele, aber total unbrauchbar als Terminal, kann nur anderstwo entwickelte Spiele ablaufen lassen. Somit reiner Konsum aber keine Kreativität, was für Konsolen typisch ist, bzw Homecomputer welche kreativ erlauben zu besser als Konsolen macht.

MTU K-1008 Visible Memory (1979)

Kein Rechner, sondern eine Erweiterungskarte für dem KIM-1 Hexkit plus Serialterminal Einplatinenrechner! Bzw mit einem K-1007 Adapter für extern an den nur Textmodus PET/CBM (und die K-1008-6 Version ist zum direkt im PET/CBM einbauen). Relativ früh erschienen, alles reine TTL Logik, keine Customchips, und billig, dementsprechend auch sehr primitiv. Nach Herstellerbeschreibung im Handbuch ist die K-1008 "eine 8k DRAM Karte, aber statt die Refreshzyklen zu verschwenden, werden die gelesenen Daten zu einem Videosignal formattiert und ausgegeben".

Daher nur 1 Bitmapmodus, in dem (320/8=40)x200=8000 der 8192 Bytes linear ausgegeben werden. Das ergibt 320x200 1bpp in 8kByte, was mit einem 8x8 Font für 40x25 Zeichen reicht (wie PET/CBM Textmodus). Mit 320 von 8MHz Pixeltakt ein mittleres 40µs Textfeld (auch wie PET/CBM). Kann einen beliebigen 8k Block von 2000bis3FFF .. C000bisDFFF benutzen (der Block 0000bis1FFF ist interner Speicher der KIM-1). Damit können auch mehrere Karten zusammen genutzt werden, welche sogar synchron laufen, mit n Karten als n Bitplanes gibt es n bpp, für 2^n Graustufen oder Farben. Das wird aber mit 16 DRAM Chips pro Karte sehr teuer!

Tangerine Microtan 65 (1979)

Relativ früh erschienen, alles reine TTL Logik, keine Customchips, und billig, dementsprechend auch sehr primitiv. Nur wenige Schritte oberhalb eines Hextasten plus 7-Segmentanzeige Maschinencode Lernsystemes wie dem KIM-1, weil noch eine Videoausgabe und volle ASCII Tastatur addiert. Direkt im Rechner eingebaut, und aus einem 512Byte (wie TV Dazzler minimal) Ausschnitt vom normalen SRAM Hauptspeicher (von mindestens 1k) laufend (wie Apple II aber dort 1k von mindestens 4k), und damit beliebig beschreibbar. Weil Rechner und Graphik integriert sind, mit sehr einfacher DMA Logik. Der Hersteller wies explizit auf kein "Snow" hin.

Hat nur 1 Textmodus. Text 32x16 Zeichen (wie Fernseher Modus vom TRS-80 Model 1). Mit 8x16(!) Font, was aber die 256 Videozeilen von einen PAL Monitor oder Fernseher benötigt, kein NTSC. Aus festem ROM Satz, von 64 oder 128 ASCII Zeichen. Dazu aber vom Modusattribut Bit8(!) gesteuert ohne Font hartverdrahtete aber mit dem Font mischbare grosse 2x4 Blockgraphik (passend zu den 256 Videozeilen) in Bit7..0 (gibt 64x64).

Für Bit8 muss das erste 1k SRAM aber 9bit breit sein, 8bit Daten plus 1bit Attribut. Dieses erscheint aber nicht als separat adressierbares 1bit RAM, sondern wird parallel zu den Daten geschrieben, aus einem Flag welches per IO Zugriffe aktiviert/deaktiviert wird. Das Bit8 kann daher aber auch nicht ausgelesen oder mitgescrollt werden, weshalb Blockgraphik nur statisch ist. Zumindest besagt das Handbuch dies, real kann man scrollen falls entweder alle Zeichen Blockgraphik sind, oder zumindest eine vorhersehbare Anordnung haben deren Bit8 beim scrollen dupliziert werden kann, oder man ohnehin nur einen Ausschnitt mit Blockgraphik scrollt.

Nur Schwarzweiss, auf beliebigem Fernseher. Wie obiges reicht als Terminal um Programme oder Daten einzugeben, aber auch halbwegs brauchbar für einfache Spiele, wieder eher Vollbild Actionspiele.

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. Wurde aber 1978 nach Firmenaufkauf durch Warner Brothers vom neuen 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 gemacht). Danach doch noch in 1982 als Konsole 5200, aber nicht voll zu den 400 und 800 kompatibel (und schon gar nicht zum VCS/2600). Dann 1983 verbilligt zu 800XL (und Subset 600XL). Zum Schluss noch 1985 passend zum ST umgestylet als 65XE (plus eine speichererweiterte 130XE). Dann kam 1986 eine 5200+2600+neueres Kombination als 7800 Konsole. Aber diese wurde nach weiterem Firmenaufkauf bereits 1987 durch die XE kompatible und damit inzwischen schwächere XEGS ersetzt. Was alles Atari bei den Spieleherstellern diskreditierte, und so auch allen späteren Systemen jegliche Unterstätzung kostete. Tod durch wiederholtem Kopfschuss per Management.

(Obiges neues Management hatte einen ehemaligen Textilfirmen Manager als Chef. Er behandelte Spieledesigner als etwa gleich unwichtig wie davor Handtuch Musterdesigner. Er hat nicht begriffen, dass Leute Handtücher wegen Tuch benutzen kaufen und die Muster nur Dekoration sind, aber nicht Spielmodule wegen ROM Chips kaufen sondern wegen den Spielen darin! Das restliche Management hat seinen Fehler nicht bemerkt und korrigiert, trotz dass Warner Brothers als Filmfirma eigentlich wissen sollte, dass Leute auch Filme nicht wegen dem Filmstreifen besuchen, sondern wegen der Geschichte drauf. Und jeder weiss, dass Leute Bücher nicht wegen dem Papier kaufen, sondern wegen den Text drin. Gamedesigner sollten daher zumindest wie Autoren und Musiker, oder gar wie Schauspieler und Regisseure behandelt werden. Was hier ihnen versagt blieb. Diese Missachtung hat viele davon hinausgeekelt. Was einerseits die wenigen noch verbliebenen massiv überlastete, und bei Atari zu eigenen schlechten oder gar unfertigen Spielen führte (Pacman bzw E.T.). Dazu kamen bei mehreren von den Ehemaligen gegründeten Drittfirmen ihre oft wegen schnell Profit einnehmen müssen überhasteten, aber wegen viele Konkurrenten trotzdem überhypeten Spielen. Nicht verwunderlich führte dies zusammen mit den Limiten der VCS/2600 zu einer Flut von Schrottspielen, gefolgt von Vertrauenskrise der Käufer und Marktzusammenbruch. Dabei verlor Atari massiv, was zu obigem zweiten Firmenaufkauf führte.)

Drei Customchips, "CTIA"/"GTIA" (Color/Graphic Television Interface Adaptor) Bitmap für die einst geplante bessere Konsole, sowie "ANTIC" (AlphaNumeric Television Interface Controller) mit Textmodi bzw eben Zellmodi weil erweitert zu einem Homecomputer mit Bild aus dem normalen DRAM Hauptspeicher, sowie "POKEY" (POtentiometer KEYboard) Paddles und Tastatur mit auch Audio und UART. Alle als dreier Chipsatz zusammen die kleinere TIA im VCS/2600 ersetzend, und damit weit mehr leistend. Umschaltbar (wie Apple II), aber hier massive 8 Bitmapmodi und 6 Zellmodi:

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

Trotz 1bpp hat Modus "F" aber nur "1.5" statt 2 Farben, genauer einen "Chroma" Farbton in zwei "Luma" Helligkeitsstufen. Dies weil Atari in 160 Wellen vom NTSC Farbträger Signal rechnet (von Atari als "color clocks" bezeichnet), die 320 damit Halbwellen sind (als "half clocks" bezeichnet), und sie daher nur eine Wellenform an "Chroma" in zwei Signalstärken an "Luma" zulassen.

(Dieser "F" mit den Farben auf Schwarz und Weiss gestellt (also Chroma Grau mit Luma 0% bzw 100%), zusammen mit dem 7.16MHz Pixeltakt, erzeugt auf einem NTSC Farbmonitor 4 Farben (wie Apple II sein Sw+Bl+Or+Ws Farbsatz). Das alles versagt aber ohnehin wieder auf einem PAL Farbmonitor, weil dieser dazu 17.734472/2=8.867MHz Pixel bräuchte.)

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

Ab GTIA sind die Bitmap "F" sowie Zell "2" und "3" Modi, statt mit 8x8 1bpp Font bzw 320x192 1bpp Bitmap, auch 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 der ANTIC Displayliste sind zudem für die möglichen 240 NTSC Zeilen (die extra PAL Zeilen sind stets leer) ihre Modi und diverse Optionen beliebig zeilenblockweise mischbar. (Der ANTIC wird von Atari selber mit "resembles a small dumb microprocessor" beschrieben, was aber bei manchen Fans zu "is a true microprocessor" übertrieben wird. Real kann er nur genau aus der Displayliste ein internes Modusregister sowie zwei Adressregister vorzu nachladen. Womit die Displayliste eher eine Art von Formatierangeben sind, und der ANTIC deren Auswerter.)

Damit an Formatierungen einstellbar sind:

Offensichtlich kann er dabei (wie Apple II und PET/CBM) ebenfalls wegen 32/40/48 Zeichen pro Zeile keine 2^n sein nicht einfach X und Y Koordinaten als Speicheradresse zusammenlegen. Zudem kann er wegen zeilenweise Moduswechsel nicht mit festem Y*40+X Addierer wie bei Apple II arbeiten. Also wird wie bei PET/CBM eine separate Adresse gezählt und wiederholt. Welche aber mit bei jeder Moduszeile fakultativ die Datenadresse mehrmals direkt gesetzt werden kann, statt nur bei Bildanfang auf 0. Weshalb die Zeilen zwar normalerweise linear im Speicher liegen, ausser es wird hiermit gezielt gesprungen.

Dazu Sprites, 4 Player 8Pixel 1bpp (je 8bit Register) sowie 4 Missiles 2Pixel 1bpp (alle in 4*2=8bit Register, bzw zusammenlegbar als fünften Player von 8 Pixel 1bpp). Register fakultativ automatisch ladbar pro Zeile, kosten dann aber 256 Zeilen Bytes pro Sprite. Dabei angeordnet als letzte (1+4)*256 Bytes eines beliebigen 2k Blockes, Missiles zuerst. Können alle mit Zeilen doppelt zeichnen auf (1+4)*128 von 1k reduziert werden. Mit horizontal je in einzel oder doppel oder gar vierfach Pixel Breite. Sind horizontal auf 160Pixel "Pixelclocks" Raster positionierbar. Vertikal positioniert durch Sprite in diesem 256er oder 128er Speicher umkopieren.

Farben wieder mit Register auswählbar aus 16*8=128 (16 NTSC Farbtöne und 8 Helligkeitsstufen, vermutlich die identischen 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, keine separate Missiles (alle 4 nehmen die Farbe ihres passenden Players, bzw alle Missiles als fünften Player zusammengelegt nehmen die vierte Bild/Spielfeld Vordergrund Farbe), zusammen 9 Farben. Während Spielfeld und Sprites automatisch vom ANTIC geladen werden, kann man wechselnde Farben nur in Software machen (wie VCS/2600), weshalb dessen "streifigen" Farben blieben oder wegen Aufwand verschwanden. Bei 320*1 oder 160*2 oder 80*4 oder 40*8 von 14.31818/2=7.16MHz Pixeltakt ein 44.7µs breites Textfeld (Narrow 256*1 ein 35.8µs schmales, Overscan 384*1 ein 53.6µs überbreites).

Die PAL Version vom GTIA (es hat keine PAL CTIA) ersetzt die 14.31818MHz mit 17.734472MHz. Damit werden die 16 Farbtöne in schnellere und auch leicht anderst geformte "Viertelwellenpixel" Muster umgesetzt. Man beachte dass die Videodaten nur zwischen Farbregister schalten (wie Apple II "Low Resolution"), nicht selber die NTSC Muster beinhalten (wie Apple II "High Resolution"), daher ist die Mustererzeugung beliebig ersetzbar. Wegen Software kompatibel bleiben wird der Prozessor von NTSC 14.31818/8=1.79MHz auf PAL 17.734472/10=1.77MHz nur leicht verschoben. Auch die extra Bildzeilen werden fest auf Leerzeilen gesetzt, damit die Displayliste gleich bleiben kann. Damit sind aber die 160 Pixel an Wellen (bzw 320 an Halbwellen) gar keine solche mehr, weil schnellere Wellen! Es funktioniert aber trotzdem, weil die Analogelektronik vom Monitor auch mit Wellenbruchstücken zurecht kommt. Schliesslich richten sich Kanten im einem Bild vor einer Fernsehkamera auch nicht nach deren Wellen aus, zumal diese je nach Farbton ohnehin in anderer Phase sind und damit an anderem Ort in der Bildzeile liegen! Weshalb man sich ernsthaft fragt, warum Atari bzw Designer Jay Miner darauf bestand, die NTSC Pixelrate genau auf die Farbwellen und ihre Halben auszurichten, mit dazu den Prozessor von den 2MHz die er kann auf 7/8 Takt bremsen.

Wie man sieht ist dies ein massiv komplexer Chipsatz, mit vielen Modi zeilenweise schaltbar und Zellmodi mit ladbarem Font und noch Sprites dazu. Was nur noch vom Amiga Chipsatz überboten wird, welcher vom gleichen Designer stammt, sogar seine nachfolgende Arbeit ist!

Texas Instruments TMS9918 VDC Chip (1979)

Kein Rechner oder Spielkonsole, sondern ein generischer Videochip, 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 im Homecomputer TI-99/4 (1979, mit originalem TMS9918), sowie TI-99/4A (1981, erweiterte TMS9918A). Ebenso letztere im Coleco ColecoVision (1982, Konsole) und Adam (1983, Homecomputer). Ebenso im Sega SG-1000 (1983, Konsole) und SC-3000 (1983, Homecomputer). Am bekanntesten aber ebenfalls im Spectravideo SV328 und in all den davon abgeleiteten MSX Geräten (ab 1983).

Einzelner Chip TMS9918 VDC (Video Display Controller). Mit separatem max 16k VRAM aus DRAMs oder SRAMs. Mit eigenem Bus zu diesem, daher asynchron von beliebigem Prozessortyp (mit 9900 in TI-99/4(A) und Z80 in allen anderen obigen), sowie den Prozessor nur bei Videozugriffen bremsend, und nicht wie Atari 800 den ganzen Prozessortakt auf 7/8 bremsend. Aber mangels Pins hat es keine Adressierung der 16k vom Prozessor. Es braucht daher eigene Adressregister im VDC, mit diese laden umständlich und langsam. Dies verhindert zudem Prozessor Adressmodi ausnutzen, bzw reduziert von indirekte benutzen zu nur direkte oder IO, mit die Adressregister im VDC die Indirektion addierend. Es ist dafür aber auch nicht mehr auf den 64k Prozessor Adressraum limitiert, sondern addiert seine 16k zu diesem. (All dies gilt auch für die in der Einleitung erwähnten µPD7220 und EF93xx Videochipfamilien.)

Er hat umschaltbar 2 Zell und 1 Blockgraphik und 1 Bitmap Modi:

Zell "0" ("Text") 40x24 Zeichen. Mit 6x8 1bpp Font. Aus variablem VRAM Satz, von 256 Zeichen. Strikte 8x8 1bpp Daten aber mit jeweils den beiden LSB jedes Bytes als Pixel ignoriert. Kann nur-RAM Zeichen, weil vom VDG keinerlei Zugriff auf ROM im Prozessor seinem Adressbereich besteht. Der Font muss daher vom System aus ROM ins VRAM geladen werden, ist aber dafür beliebig modifizierbar. Wie Atari 800 Zell "2" nur 2 Farben fürs ganze Bild. Das weil bei 14.31818/(2*6)=1.193MHz Zeichenfolge nicht mehr genug Speicherbandbreite frei ist, für neben 8bit Zeichencode und 6*1bit Fontstreifen lesen sowie Zugriff für den Prozessor auch noch zeichenweise Farbdaten zu lesen. Bei nur 40*6=240 Pixel (Apple II 40*8=280, Atari 800 40*8=320) trotz langsamen 14.31818/2=7.16MHz Pixeltakt ein sehr schmales 33.5µs Textfeld. Liefert aber 40 Zeichen/Zeile als Terminal um Programme oder Daten einzugeben.

Zell "1" ("Graphic 1") 32x24 Zeichen. Mit 8x8 1bpp Font. Aus variablem VRAM Satz, von 256 Zeichen, wieder spielespezifisch ins VRAM zu laden. Bei 32*8=256 Pixel leicht breiteres 35.8µs Textfeld. Wie Atari 800 Zell "6" pro Zeichen Farben. Aber statt 64 Zeichen und nur 2bit Vordergrund Farbauswahl, hier volle 256 Zeichen mit in 32 8er Gruppen je einer Vordergrund und Hintergrund Farbe, mit dazu im Speicher 32 4+4bit Farbattributpaaren. Diese aus 15 NTSC Farben (16. "Farbe" ist transparent, für zusammen mit Genlock ein Fernsehbild mit Overlays versehen, wie bei Teletext wenn mit einem transparentem Hintergrund dargestellt, wie es für Untertitel benutzt wird). Diese 32 vom Speicher lesen statt in 32 Farbregister halten (Atari braucht nur 4+1=5) kostet von 40 auf 32 Zeichen/Zeile reduzieren, aber das ist für Spiele akzeptabel. Man bekommt dafür volle 256 Zeichen plus zellweise Farben gelesen (und erst noch 2*16 davon), statt nur 64 Zeichen mit 4v+1h.

Dabei werden aber für jede 8 Pixel ausgeben 8bit Zeichencode und 8*1bit Fontstreifen und 2*4bit Farbattribut gelesen, mit einem vierten Zugriff frei für den Prozessor. Was auch so wegen 4 Speicherzugriffe pro 8 Pixel trotz Bremse auf 32 Zeichen herunter nach 3.579646MHz Speicherbandbreite verlangt, mit wegen diesem damals teure 200ns 4116-20 DRAMs benötigen. Obiges "Text" sind dagegen 3 Speicherzugriffe pro 6 Pixel, die 40 Zeichen aus selbigen 3.579646MHz. Als Vergleich der Atari 800 hat nur 1.79MHz NTSC oder 1.77MHz PAL Speicher, der Apple II hat 2.045MHz Speicher, der Commodore 64 2.045MHz NTSC oder 1.97MHz PAL Speicher.

Separate Blockgraphik "3" ("Multicolor") ohne Font hartverdrahtet, 64x48 mit 4bpp alle 15 NTSC Farben (immerhin weniger klotzig als dem Apple II seine 40x48 Blockgraphik, aber noch unter dem TV Dazzler seinen 64x64).

Ab TMS9918A Bitmap "2" ("Graphic 2") 256x192 1bpp. Strikte sind dies einfach pro Drittel vom Bild (32x8=256 Zeichen) einen eigenen 256er Font benutzen. Was mit einfach alle 3*256 Zeichen linear durchlaufen einen Bitmapmodus ergibt, von (32*8=256)x(2*8*8=192) in 3*2=6kBytes (statt 2k Font). Dabei liegen die Pixel nichtlinear im 6k Speicherausschnitt, sondern wie zu einem Font passend in 8 Bytes/Zeichen Gruppen, von zuerst Zeilen 0..7 je Pixel 0..7 (= Zeichen 0), dann selbige Zeilen alle 8..15, 16..23, .., 248..255 (= Zeichen 0..31), gefolgt von selbiges der Zeilen 8..15 (= Zeichen 32..63), dann Zeilen 16..23, .., 184..191 (= Zeichen 736..767). Mit zudem für alle 8x1 Pixelstreifen eigene Vordergrund und Hintergrund Farben aus 15 NTSC (das braucht zweite 3*2=6kByte statt nur 256/8=32Bytes an Farbattributen). Sehr viel Auflösung und Farben, aber zum Preis von viel Speicher. Man kann dies aber reduzieren, mit nur einem 3 mal wiederholtem 2k Font wie im Zellmodus benutzen, nur mit pro 8x1 Pixel eines Zeichens Farben, statt 32 Gruppen von 8 ganze Zeichen.

Dafür fehlen aber jegliche 2bpp Sachen vom Atari 800, was dem TMS9918 seine grosse Schwäche ist. Ebenso hat es kein Overscan, trotz selbst bei Graphic immer noch recht schmalem Textfeld. Auch kein fein scrollen, und ebenso keine Displayliste.

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 Pixel 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 sichtbare in einer Zeile, von bis zu 32 angemeldeten. Dies ist nur möglich weil Sprites nicht alle Zeilen hoch sind, wie Atari 800. (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.)

Damit den selbigen Zellmodi mit ladbarem Font Ansatz wie Atari, mit Bitmap aber nur als modifizierten Zellmodus mit mehreren Fonts. All das ohne die aufwendigen zeilenweise schaltbaren Modi. Mit statt dessen viel mehr Sprites. Was diesen zu einem sehr guten Kompromiss machte. Dazu noch frei erwerbbar im Handel, kein Wunder wurde er so oft eingesetzt.

(Die erweiterten Yamaha V9938 und V9958 VDP (Video Display Processor) von 1985 bzw 1988, in den MSX 2 bzw MSX 2+ benutzt, vergrössern den Videospeicher von max 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 reine Bitmaps, welche ohne Font Zellnummern lesen zu müssen mehr Bandbreite in die Pixel stecken können, mit klein G4 256x192 4bpp und G5 512x192 2bpp, sowie gross G6 512x192 4bpp und G7 256x192 8bpp. Ab V9958 gibt es G7 auch mit YJK (YUV-artig) für 19268 kombinierte Farben (eine 4-er Gruppe Pixel hat 4*5bit Y und zusammen je 1*6bit J und K), sowie mit YJK+YAE für 12499 kombinierte plus 16 dedizierte Farben (reduziert zu 4*4bit Y, weil 1bit für pixelweise Wahl 0:YJK oder 1:TMS9918-artiges 4bpp). Beide erlauben bei G4 bis G7 auch vertikalen Overscan, mit 212 statt 192 Zeilen, sowie interlaced auf 2*192=384 bzw 2*212=424. Die V9938 addiert vertikal fein scrollen für Text, erst die V9958 auch horizontal für Games. Beide zeigen die erstpriorisierten 8 pro Zeile von 32 angemeldeten Sprites. Zudem erlauben sie bei G3 (ist nur G2 mit dies addiert) sowie G4 bis G7 (stets) neben 1bpp auch 2/3/4bpp Sprites, aber nur durch 2/3/4 der 8 Sprites pro Zeile zusammenlegen. Ebenso haben sie statt 15 NTSC Farben volle 16 aus 512 RGB Farben (ausser G7 mit 8bpp fest 3R3G2B, oder V9958 YJK bzw YJK+YAE).)

(Das erweiterte Sega Master System VDP (Video Display Processor), in SG-1000 Mark III von 1985 bzw Master System von 1986, bleibt bei max 16k (die originale SG-1000 hatte nicht mal die vollen 16k der 9918 ausgenutzt). Es bringt einen einzelnen weiteren G4 Zellmodus von 32x24 Zeichen. Mit 8x8 4bpp(!) Font. Braucht so vier Bytes an Font pro Pixelzeile eines Zeichens, was mit nur vor dem ersten von vier Fontbytes ein Zeichencodebyte holen, dann 4/5 statt 1/2 Bandbreite an Fontdaten erlaubt. Daher aber auch Vordergrund und Hintergrund Farbwahl direkt aus dem Font heraus, keine 1bpp mit danach separaten 2*4bit Farbattributen per G2 Zellgruppen oder G3 Pixelzeilen. Das spart weiter an Farbdaten lesen, und erlaubt damit erst 4bpp trotz Font Zellnummern lesen. Es verliert aber die Möglichkeit ein Zellenmuster mit mehreren Farben zu kombinieren, selbiges Muster anderst eingefärbt braucht daher ein weiteres Zeichen. Der Font hat aber einen Satz von 448 Zeichen (bzw strikte 16k/(8*4=32)=512, aber davon wird noch der Bildspeicher abgezogen), was obiges fehlende kombinieren etwas kompensiert. Jede Zelle ist horizontal und vertikal spiegelbar, was die Anzahl Muster reduziert, fehlendes kombinieren weiter kompensiert. Kein Overscan oder Interlace. Addiert beides horizontal und vertikal fein scrollen, zudem mit obere 2 Zeilen und rechte 8 Spalten davon ausnehmbar. Sprites sind nun 8x8 oder 8x16 4bpp (genauer 1x1 oder 1x2 Spritezellen aus 256 zu je 8x8), aber mit 8 sichtbare pro Zeile von 64 angemeldeten. Ebenso hat es statt 15 NTSC Farben sogar volle 32 (16 für Zellen und 16 für Sprites), aber aus nur 64 RGB Farben.)

Motorola MC6847 VDG Chip (1979), plus MC6883 SAM (1980)

Kein Rechner oder Spielkonsole, sondern generischer Videochip, in diversen Geräten verwendet. Darunter TRS-80 Color Computer (CoCo) 1 und 2 (1981 bzw 1983), sowie Dragon 32 und 64 (1982 bzw 1983), sowie Acorn Atom, sowie dem oben erwähnten NEC PC-6001, sowie auch Fujitsu FM-7, aber auch viele Hongkong Rechner wie dem Laser 200 als wohl bekanntesten. Nach dem MC6844 DMA Chip, und darauf aufbauend dem oft benutzten MC6845 Video Timer+DMA Chip, ist der MC6847 VDG (Video Display Generator) ein einzelner Chip für ganzes Video inklusive den Daten zu Pixel wandeln. Bzw zwei Chips wenn zusammen mit dem MC6883 bzw 74LS783 SAM (Synchronous Address Multiplexer) verwendet (TRS-80 Color Computer 1 und 2 sowie Dragon 32 und 64 haben diesen drin, Acorn Atom aber nicht). Mit Bild aus dem normalen SRAM oder DRAM Hauptspeicher (TRS-80 Color Computer 1 und 2 sowie Dragon 32 haben DRAM, Acorn Atom hat SRAM). Deswegen den Prozessortakt auf 7/8 bremsend (wie Atari 800).

Der MC6847 soll nach manchen Aussagen aus einer Zusammenarbeit von Motorola und Tandy entstanden sein, für den TRS-80 CoCo, daher auch mit am TRS-80 Model 1 "halbem" 32x16 angelehnten Videoformat für Fernseher. Weiter soll der MC6883/74LS783 als Reduktion/Verbilligung des Prototyprechners entstanden sein. Nach anderen Aussagen hat Motorola den Chipsatz entwickelt mitsammt Referenzdesign, und Tandy nur dieses benutzt. Definitiv besteht der CoCo zumindest in der ersten Version zu 100% aus von Motorola hergestellten Chips, selbst alle TTLs. Der Dragon ist dem CoCo sehr ähnlich, sogar mit identischer Tastaturanordung zum CoCo 2 (und identische 8x7 Matrix sowie Stecker, aber die 7er Kante ihre Leitungen sind darauf vertauscht, Dragon @ABCDEFG HIJKLMNO und PQRSTUVW sind bei CoCo 01234567 ()*+,-./ und @ABCDEFG), fast identischem Erweiterungsport (fehlende -12V sind zweites 12V), kein 3-Draht bitbanging RS232 (aber Dragon 64 hat einen 6551 Chip) weil die 2 Leitungen für den addierten Druckerport umgenutzt wurden, und fast identischem Basic (das CoCo Extended Basic, aber stets beide 8k ROMs anwesend oder gar als ein 16k, aber andere Tokens sowie Einsprungadressen).

Er hat Umschaltbar 1 Text und 2 Blockgraphik und 8 Bitmapmodi:

Text 32x16 Zeichen (wie "halbes" TRS-80 Model 1). Mit 8x12 Font (fast wie TRS-80 Model 1). Aus im Chip selber eingebautem festem ROM Satz, von ASCII64+revers Zeichen (wie TRS-80 Model 1). Mit Bit6 oder Bit7 als revers, je nach Verdrahtung (TRS-80 Model 1 und Dragon 32 nehmen dazu Bit6). Nur in Schwarzgrün oder Schwarzorange. Bei nur 32*8=256 Pixel mit langsamen 14.31818/2=7.16MHz Pixeltakt ein recht schmales 35.8µs Textfeld (wie TMS9918 Graphic Modi).

Dazu aber ohne Font hartverdrahtete 2x2 Blockgraphik "4" in Bit3..0 (gibt nur 64x32), in festen 8 Vordergrund und 1 Hintergrund NTSC Farben (Gn+Ge+Bl+Rt+Ws+Cy+Mg+Or) + Sw, in Bit6..4. Kann je nach Verdrahtung vom Modusattribut Bit7 gesteuert mit dem Font gemischt werden (TRS-80 Model 1 und Dragon 32 machen dies so).

Separate Blockgraphik "6" ohne Font hartverdrahtet 2x3 in Bit5..0 (gibt immerhin 64x48) in 4+1 Farben (Gn+Ge+Bl+Rt) + Sw oder (Ws+Cy+Mg+Or) + Sw, in Bit7..6. Aber nicht voll mit dem Font mischbar. (Beim CoCo und Dragon sind, wegen Verdrahtung von Bit7 auf den Text/Block Modusschalter, und der "4" zu "6" Schalter nur bei Block wirksam, nur die Farben Bl+Rt bzw Mg+Or nutzbar, diese dafür aber auch mit Text mischbar.)

Bitmap ist abgestuft (wie Atari 800). Als "R" (Resolution) mit 128x64 128x96 128x192 oder 256x192 1bpp in Schwarzgrün oder Schwarzweiss. Oder als "C" (Color) mit 64x64 128x64 128x96 oder 128x192 2bpp mit nur obigen 4er Farbsätzen, und damit ohne Schwarz!. Mit zudem den Bildrand ebenfalls 1=Grün bzw 1=Weiss (statt 0=Schwarz wie bei Text oder Blockgraphik), was nervt.

(Mit "R" 256x192 auf Schwarzweiss gestellt, zusammen mit dem 7.16MHz Pixeltakt, erzeugt auf einem NTSC Farbmonitor 4 Farben (wie Apple II sein Sw+Bl+Or+Ws Farbsatz). Das versagt aber wieder auf einem PAL Farbmonitor, weil dieser dazu 17.734472/2=8.867MHz Pixel bräuchte. Vermutlich ist dies der Grund, warum der CoCo in den USA einen weit besseren Ruf hat als der Dragon in Europa.)

Die VDG und SAM (falls vorhanden) unpassend zu einander konfigurieren addiert weitere Modi. Mit VDG auf 32x16 Text plus 2x2 Block, sowie SAM auf 256x192 1bpp, entstehen 32x192 Zeichen mit 2x1 Block (gibt 64x192). Dabei bleiben aber die Hälfte der Block/Pixel Bits unbenutzt, was die Auflösung halbiert. Mit einem hypothetischen VDG 4x1 Modus zusammen würde es sogar ordentliche 128x192 ergeben, was 32x24 Zeichen mit 4x8 Font erlauben würde, in allen 8+1 Farben, somit in jeder Hinsicht besser für Spiele als alles vorhandene! Selbst ohne SAM wären solche 4x1 "Vertikalstreifen" (und auch 1x4 "Horizontalstreifen") nützlich für Balkendiagramme. Dazu nutzbare Moduspins wären sogar vorhanden und unbenutzt (sie werden benutzt um die Bitmapmodi zu unterscheiden).

Auch mit VDG und SAM unpassend zu einander konfigurieren könnte man den 32x16 Textmodus auf 32x24 verbessern, mit SAM nur 8 mal statt 12 mal selbiges Zeichen aus dem RAM holen. Aber dies scheitert am eingebauten Font, von dem dann einfach die unteren 4 Zeilen abgeschnitten werden. Strikte kann dies mit einem externen Font ROM gelöst werden, aber solcher ist zumeist nicht vorhanden.

Damit der schwächste Chip in dieser Liste, sogar unterhalb von einigen TTL Rechnern. Das pure Gegenteil zur TMS9918, welche aufs Maximum hinaufgezogen wurde, mit hier nur das Minimum gemacht, auf TRS-80 Model 1 seinem unteren 32x16 Niveau, nur 64er ROM Font und damit mischbare 2x2 bzw 2x3 Blockgraphik, plus letztere mit mehr oder weniger 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 Technology als generischer Videochip (NTSC MOS6560 und PAL MOS6561) für beliebige Kleinterminals und Geräteanzeigen sowie Spielkonsolen besser als dem VCS/2600 gedacht. Stand damit in direkter Konkurrenz zur MC6847. Wie diesen mit Bild aus dem normalen SRAM oder DRAM Hauptspeicher.

Der VIC verkaufte sich aber nicht, trotz weit besser zu sein. Vermutlich wegen seiner zu niedrigen horizontalen Auflösung. Daher von Commodore verwendet für den VC-20 (bzw VIC-20 im englischen Sprachraum, oder VIC-1001 in Japan). Wegen einem Überschuss an 1kx4 SRAM Chips bei MOS wurde der VC-20 dann mit solchen gebaut, was um trotzdem billig zu sein seine geringen 5* 1kByte ergab, nicht mal die zumeist 2*4* 1kByte SRAM des PET 2001.

Umschaltbar 2 Zellmodi. Wegen 2MHz Bandbreite vom Speicher (1MHz für Prozessor und 1MHz für Video) wurden, um Zeichencodes plus Font zu holen, ohne den Prozessor 40% der Zeit anzuhalten um "Snow" zu vermeiden, die PET/CBM 40 Zeichen auf 20 halbiert, aber dann für etwas weniger schlimm das Bild auf 22 verbreitert, mit dafür aber die Zeilen von 25 auf 23 reduziert, damit es immer noch in halbe 512Bytes passt. Das ergibt nur 22x23 Zeichen. Mit 8x8 1bpp (wie Atari 800 Zell "2" und TMS9918 "1" ("Graphic 1") oder aber 4x8 2bpp "Multicolor" Font (wie Atari 800 Zell "4"). Aus variablem ROM/RAM Satz (wie Atari 800, aber ohne direkt ModulROM, muss ins RAM umkopiert werden) aber von vollen 256 Zeichen (wie TMS9918), mit eingebautem ROM als 128+revers genutzt (wie Atari 800). Braucht so trotz Zeichencodes plus Font holen nur die Hälfte vom etwa 2MHz Speichertakt, aber zum Preis von nur 22 noch Zeichen (nahe Atari 800 Zell "6" nur 20). ROM hat 2x2 Blockgraphik (gibt 44x46) sowie alle PET/CBM Graphikzeichen darin (beide Fonts davon). Aber mit RAM erlaubt wieder spielespezifisch ersetzen, und somit selbst bei 2bpp noch 88x184 Pixel. Tastatur hat auch alle Graphikzeichen drauf, aber weil weniger Tasten, 2 solche pro Taste, mit zweitem Shift mit Commodore Logo drauf.

Dazu aber ein separates 1kx4bit FarbRAM (und somit strikte 5+0.5=5.5kBytes Speicher im VC-20) mit Vordergrund Farbattribut. Mit dazu die identischen unteren Adressbits A0..A9 nutzend, womit dies strike ein 8+4=12bit Videochip ist! Jedes Zeichen hat mit 3 der 4 extra Bits ein eigenes von 8 NTSC Farben (sowie ganzer Hintergrund ein weiteres von 16, sowie Rand eines von den ersten 8), diese als Farbton+Helligkeit Kombinationen ohne separate Helligkeitsstufen (genauer sind sie beinahe-RGB, in Reihe Schwarz Weiss Rot Cyan Magenta Grün Blau Gelb, dann nur Hintergrund noch Hellbraun und Pastellbraun sowie Pastelle der Rot bis Gelb). Das erlaubt 256 Zeichen Font mit 8 Vordergrund Farben zu kombinieren. Dazu kommt mit dem vierten der 4 extra Bits zeichenweise 1bpp/2bpp umschalten, mit dann 3 statt 1 Hintergrundfarben von allen 16. Dies statt dem Atari 800 Zell "6" seinen nur 64 Zeichen mit 4 Farben und diese nur in 1bpp (und nur 20 pro Zeile), bzw Zell "4" mit 2bpp aber nur 2 Vordergrund Farben pro Zeichen, oder der TMS9918 seine 256 Font mit 2*16 Farben aber massiver Speicherbandbreite (und gar kein 2bpp), sowie Farben entweder nur 32 Paare oder pro 8x1 mit massivem Speicherverbrauch. Wovon hier sowohl farbige plus reverse Textausgabe wie auch vor allem Spiele massiv profitierten.

Die aktuelle Zeilennummer ist auslesbar, aber kein Interrupt davon. Was aber mit VIA Timerinterrupt kompensierbar ist. Kein Bitmap. Aber die 2bpp kompensieren dies teilweise, wenn auch auf Kosten von nur noch 22*4=88 statt 22*8=176 Pixel pro Zeile (von denen es wiederum 23*8=184 Zeilen hat, weil 22x23 Zeichen statt 20x25). Wie TIA im VCS/2600 auch Audio und Paddles im selbigen Chip.

Damit hat dieser genau den flexiblen Zellmodi mit ladbarem Font Ansatz, mit vollen 256 Zeichen plus 8 oder 16 Farben, plus Wahl von 1bpp oder 2bpp, aber ohne Exzess, wenn auch ohne Bitmap. Das ist total ausreichend, es ist sogar überraschend gut. Praktisch alle guten 1980er Chips bauen auf einer vergleichbaren Kombination auf. Nur die wegen Bandbreite sehr niedrige halbierte horizontale Auflösung ist massiver Schwachpunkt dieses Chips. Und der geringe Speicher der massive Schwachpunkt vom VC-20.

Alleine Auflösung verdoppeln, mit 1 der 5 kByte als separates 1kx8bit Zeichencode RAM (wie PET/CBM) verwenden, und dann nur den Font von ROM/RAM holen, was auch mit 40 Zeichen in dessen Bandbreite passen würde, und der VIC wäre ein sehr guter Chip gewesen. Dazu noch 16k DRAM statt den restlichen 4k SRAM und der VC-20 wäre ein sehr guter Rechner gewesen. (Es gab sogar einen geplanten zum originalen VIC pinkompatiblen Nachfolger VIC-1.5 (NTSC MOS6562 und PAL MOS6563) der für einen VIC-40 Rechner gedacht war, aber auch als Aufrüstsatz mit Austauschchips für den VIC-20. Diese wurden wegen besserem VIC-II und Commodore 64 abgesetzt. Diese hätten auch doppelte 40x25 gehabt, mit VIC statt VIC-II Farbsatz, aber ohne Bitmap und Sprites.)

Sinclair ZX80 (1980)

Absoluter Minimalstrechner, mit dem Ziel designt billigst möglicher Rechner zu sein. Daher nur ein Schritt oberhalb eines Hextasten plus 7-Segmentanzeige Maschinencode Lernsystemes, quasi ein Basic Lernsystem. Die ZX80 hat neben Z80A Prozessor und 1 4k ROM und 1 Paar 1kx4 SRAMs und 1 7805 Spannungsregler noch genau 18 TTLs, keine Customchips. Dementsprechend extremst primitiv.

Selbst die Zeichencodes vom Bild aus dem normalen SRAM Hauptspeicher werden vom Prozessor als Programm ausgelesen. Dies mit solange bei Befehl holen das SRAM an C000..FFFF statt 4000..7FFF angesprochen wird (und gilt strikte auch bei ROM an 8000..BFFF statt 0000..3FFF), speziell reagieren. Alle Bytes mit Bit6=0 werden vom Videogenerator "nebenher" als Zeichen ausgegeben (0..63 normal, 128..191 revers), mit dem Prozessor dabei einen 0=NOP Befehl vorgaukeln (alle Programme/Daten von RAM und ROM kommen durch 1k Widerstände, aber der NOP Generator besteht aus OC Inverter, welche aktiviert hart nach 0 ziehen aber bei 1 nur loslassen.)

Der eigentliche Fontzugriff (auf die letzten 64*8 Bytes im ROM) wird auch halbwegs mit dem Prozessor gemacht, dazu wird trotz SRAM dem Z80 sein DRAM Refreshzyklus ausgenutzt. Wobei A9..15 den nebenbei ausgegebenen Inhalt vom I Register haben (Hex 0E), aber A3..8 vom gelesenen Zeichencode Bit0..5 und A0..2 vom Videozeile in Zeichenzeile Zähler her eingefügt werden (womit das eigentliche R Register komplett ignoriert wird!). Daher ist auch kein RAM Font möglich, weil diese Einfügelogik nur auf ROM Adressen einwirkt, nicht auf RAM. Eigenartig ist dass normal (Bytes mit Bit7=0) schwarz auf weiss und revers (=1) weiss auf schwarz (sonst eher benutzt wird normal weiss auf schwarz und revers schwarz auf weiss), was aber mit einem Lötpunkt umstellbar ist.

Bytes mit Bit6=1 (64..127 und 192..255) werden vom Videogenerator als Leerzeichen ausgegeben und an den Prozessor durchgereicht. Um Platz im nur 1k grossen Speicher zu sparen werden Zeilen ohne rechts verbleibende Leerzeichen gespeichert, sondern mit einem HALT Befehl (118) beendet, der den Prozessor ohne weiteren Bytes zu holen in eine interne NOP Endlosschleife schickt. Voller Bildspeicher ist somit 1+24*(32+1)=793Bytes, minimaler aber nur 1+24*(0+1)=25Bytes. Je mehr Platz der Benutzer mit Programm und Variablen verwendet, umso weniger Zeilen verbleiben bevor der Rechner alte wegkürzt trotz dass es noch Bildschirmplatz frei hätte! Weshalb auch die Kommandozeile sich stets auf der unteren neuesten befinget. Ist der (erweiterte) Speicher mehr als 3.25k, werden alle Zeilen egal was ihr Inhalt ist stets als (32+1)Bytes gespeichert.

Am Ende der Zeile, egal wieviele Bytes bis zum HALT waren, zählt das zuvor präparierte R Register des Refreshzählers bis Bit6 = 0, was erkannt wird und automatisch einen INT Interrupt generiert. Damit wird der Refreshzähler als 7bit Timerinterrupt missbraucht, wonach der Prozessor die Interruptroutine wieder aus ROM an 0000..0FFF liest, womit nichts mehr ausgegeben wird und der Prozessor alles bekommt, egal was für Datenbytes. Dabei wird auch die Bildsynchronisation in Software erzeugt. Die Videozeile in Zeichenzeile wird aber in Hardware gezählt. Das kostet die ganze Rechenleistung, erlaubt entweder nur Bild anzeigen ohne Software ablaufen, oder nur Software ablaufen ohne Bildausgabe oder Sync, weshalb das Bild nach jedem Befehl zuckt wenn es neu synchronisiert.

Nur 1 Textmodus. Text 32x24. Mit 8x8 1bpp Font. Aus festem ROM Satz, von 64+revers Zeichen. Bei 32*8=256 von 6.5MHz Pixeltakt trotz nur 32 Zeichen ein 39.4µs breites Textfeld. Trotz nur 64er Font mit 2x2 Blockgraphik und 1x2 Matrixgraphik, womit sogar nur einen Teil von ASCII64 drin ist. Zeichensatz gibt: Leerzeichen 7*Block 3*Matrix " £ $ : ? ( ) > < = + - * / ; , . 0..9 A..Z), es fehlen somit von ASCII64: ! # % & ' [ \ ] ^ _. Nur in Schwarzweiss. Dazu passend nur eine Folientastatur. Wegen geringer Anzahl mit einzelnen Graphikzeichen drauf, wie PET/CBM, mit normalem Shift benutzt.

Dazu gibt es noch einen undokumentierten Bitmapmodus. Dieser besteht darin, den "Font" mit I und R aus dem RAM statt ROM auszulesen, wobei obige Einfügelogik eben versagt, Zeichencode und Videozeile in Zeichenzeile ignoriert werden! Da aber R nur die untersten 7bit incrementiert, und I erst recht nicht incrementiert wird, muss man mit einer eigenen Ausleseroutine arbeiten, welche I und R passend setzt, und dann direkt 32 NOPs liefert (welche Bit6=0 zeichnen und Bit7=0 nicht reversieren haben), mit danach Zeilenrücklauf abwarten, dann ab I und R setzen wiederholt. All das ohne Halt, weil ohne Interrupts eingeschaltet, weil ohne R als Timer, und so wird auch vermeiden in der normalen Routine zu landen. Bit0..5 werden ohne die Einfügelogik ignoriert, weil nur das ROM diese zu sehen bekommt, nicht aber das RAM, welches eben R bekommt, damit das Bitmap holt. Dies erzeugt sogar einen echten 256x192 Bitmapmodus. Nur reichen die internen 1k SRAM nirgendswohin, weil dazu (256/8=32)*192=6k an Bildspeicher gebraucht werden. Und die externen Speichererweiterungen machen dabei zumeist nicht mit, ausser man modifiziert sie (nur 2 Dioden und einen Widerstand addieren), dass sie auch bei Refreshzyklus einen Lesezyklus machen.

(Der Nachfahre ZX81 (1981) lieferte gleichen Prozessor und Takt sowie doppelt grosses 1 8k ROM (mit Basic um Fliesskomma erweitert) und 1 1kx8 SRAM und 1 7805. Aber er verfrachtete alle 18 TTLs in ein ULA (Uncommitted Logic Array) Gate Array Semicustomchip. All das sogar 100% kompatibel, weshalb auch das ZX81 ROM (plus passendes Folientastatur Overlay wegen umgeordneten Graphikzeichen) für die ZX80 als Nachrüstsatz verkauft wurde. Aber das ULA hat zudem eine Erweiterung, um mit NMI Interrupt getriebenem Multithreading sowohl das Bild ausgeben zu lassen, wie auch die eigentliche Software langsamer auszuführen, statt nur Bild ohne Software oder Software ohne Bild. Das kostet dann 2+(24*8)=194 von 310 Zeilen plus in den verbleibenden Zeilen 58 von 207 Takten, lässt somit 25% vom 3.25MHz Takt, also effektive 0.8MHz. Die dazu genutzten "FAST" und "SLOW" Modusschaltbefehle sind auf ZX80 mangels Umschalter einfach wirkungslos. Es gibt aber eine 5 oder 6 TTLs (je nach ob man genaues Timing duplizieren will) umfassende Erweiterung welche diese dort nachrüstet. (Womit die ULA etwa 18 + 5oder6 = 23oder24 TTLs entspricht.))

Osborne 1 (1981)

Früh erschienen, alles reine TTL Logik, keine Customchips, und passt in portabel, dementsprechend recht primitiv. Direkt im Rechner eingebaut, mit Bild aus einem 4k Ausschnitt vom normalen DRAM Hauptspeicher (wie Apple II), und damit beliebig adressierbar und veränderbar. Hat nur 1 Textmodus. Text 52x24. Mit 8x10 1bpp Font. Aus festem ROM Satz, von 128 ASCII Zeichen. Dieses hat neben 96 ASCII auch 32 Graphikzeichen drin, inklusive 16 für im Font integrierte mischbare 2x2 Blockgraphik (gibt 104x48). Bei 52*8=416 von 8MHz Pixeltakt ein voll breites 52µs Textfeld. Nur Schwarzweiss, auf dem eingebauten 6" Monitor.

Strikte könnte er wegen 52 Zeichen pro Zeile keine 2^n sein nicht einfach die X und Y Koordinaten als Speicheradresse zusammenlegen zu können. Das vermeidet er aber, indem er die 52x24 Zeichen aus einem beliebig horizontal und vertikal scrollbaren derartigen Ausschnitt von einem 128x32 Speicher anzeigt, was dann 2^n sind. Aber mit nur einem Teil davon darstellen, und deswegen 4k statt 1248=1.25k an Videospeicher brauchen. Warum dies nicht 64 pro Zeile sind, mit nur halb soviel Speicher verbrauchen, ist mir unbekannt. Vielleicht wurde er auf spätere 80x24 erweiterbar ausgelegt. (Ähnliches wurde auch im Nascom verwendet, mit 48x16 Zeichen, aus einem Ausschnitt von einem 64x16 Speicher anzeigen, aber ohne scrollbar.)

Dazu noch 2 Attributbits, unterstrichen und halbhell. Mit den 7bit Zeichen 9bit. Dazu muss das letzte 16k DRAM aber 9bit breit sein, 7bit Daten plus 2bit Attribut (wie Microtan 65). Hier aber als voll adressierbares DRAM, dank Bankswitching (Bank1 RAM, Bank2 ROM+IO, Bank3 nur 1bit Attribut). Wie Apple II und TRS-80 Model 1 und PET/CBM reicht dies als Terminal um Programme oder Daten einzugeben. Wurde aber ohnehin praktisch nur als portable Büromaschine genutzt.

IBM Monochrome Display Adapter MDA (1981)

Kein Rechner, sondern eine Karte für den IBM PC Bus. Wegen Karte mit separatem 4k VRAM aus SRAMs (wie TMS9918), daher auch asynchron und nicht Prozessor bremsend. Aber mit Adressen vom Prozessor, dessen Adressmodi ausnutzend (ungleich TMS9918, als entscheidender Vorteil). Für Timing und Adressen ein MC6845 Chip, Datenpfad TTL, keine Customchips, daher auch primitiv.

Nur 1 Textmodus. Text 80x25. Mit grossem 9x14 1bpp Font. Aus festem ROM Satz, von 256 Zeichen. Braucht dazu einen separaten MDA Spezialmonitor der die resultierenden 720x350 anzeigen kann. Scheidet damit strikte hier aus, wird aber wegen Einleitung zur CGA sein drin gelassen. Keinerlei Graphik ausser Graphikzeichen. Darunter zwar auch 1x2 und 2x1 Blockgraphik aber trotz 256 Zeichen keine 2x2 (es gibt also doch nur maximal 80x50, bzw 160x25). Aber mit 8bit Attributen, als (1+3)+(1+3)bit, Hintergrund (Bits 7..4) und Vordergrund (Bits 3..0) je 3 Helligkeitsstufen (0,7,15) (manche Monitore erlauben noch 8 als viertes) und weiteres Unterstreichen Attribut. Hintergrund Bit7 ist mit Mode Control (MC) Register Bit5=1 umschaltbar zu nur noch 2 Helligkeitsstufen (0,7) plus blinkend. Vordergrund auf 1 oder 9 setzen wirkt wie 7 oder 15, aber mit Unterstreichen addiert. Ist damit strikte 8+8=16bit Video, aus eigentlich 2k 16bit Worten an SRAM! (Leider wird trotz so vielen Attributbits keines als Modusattributbit benutzt, für ohne Font hartverdrahtete aber damit mischbare 2x4 Blockgraphik (wie Microtan 65 es mit 9bit SRAM macht für 64x64 in 32x16, wären hier in 80x25 dann ordentliche 160x100).)

Dabei kann er (wie Apple II) wegen 80 Zeichen pro Zeile keine 2^n sein nicht einfach die X und Y Koordinaten als Adresse zusammenlegen. Es gibt aber auch keinen Y*40+X Addierer. Verwendet einen separaten Adresszähler (wie PET/CBM), aber dieser ist in der MC6845 bereits eingebaut.

IBM Color Graphics Adapter CGA (1981)

Kein Rechner, sondern eine Karte für den IBM PC Bus. Erweiterte graphische und farbige Alternative zur MDA. Verwendet normalen Videomonitor oder RGB Monitor. Wegen Karte mit separatem 16k VRAM aus DRAMs (wie TMS9918), daher auch asynchron und nicht Prozessor bremsend. Aber mit Adressen vom Prozessor, auch dessen Adressmodi ausnutzend (ungleich TMS9918, als entscheidender Vorteil). Für Timing und Adressen auch MC6845 Chip, Datenpfad TTL, keine Customchips, aber einiges mehr TTL als MDA, daher noch ziemlich primitiv. Kann wegen verschiedenem Adressbereich und Steuerregister (B800 und 03Dx) zusammen mit einer MDA (B000 und 03Bx) im gleichen Rechner sein, für Dualhead mit Text+Graphik.

Trotzdem aber umschaltbar 3 Modi, 1 Text und 2 Bitmapmodi:

Text 40x25 oder 80x25. Mit 8x8 1bpp Font. Aus festem ROM Satz, von 256 Zeichen. Mit 7.159MHz bzw 2*7.16=14.318MHz, und somit 44.7µs breites Textfeld (wie Atari 800). Auch hier unnötige Prozessorbremse, weil die 8088 im PC deswegen von seinen 5MHz auf 4.77MHz reduziert wurde, nur um einen Quarz zu sparen, der erst noch bei MDA nicht gespart wird! Hat trotz 256 nur 1x2 oder 2x1 Blockgraphik aber kein 2x2(!) darin (gibt also doch nur maximal 80x50 bzw noch 160x25). Dazu aber 8bit Farbattributen/FarbRAM, als (1+3)+(1+3)bit, mit Hintergrund (Bits 7..4) und Vordergrund (Bits 3..0) an Farbattributen, und so 16 RGBI (bzw hier als IRGB angeordnet) Farben. Hintergrund Bit7 ist mit Mode Control (MC) Register Bit5=1 umschaltbar zu nur 8 RGB plus blinkend statt intensiv. Kein Unterstreichen. Ein einzelnes Color Select (CS) Register liefert in Bit3..0 die IRGB Randfarbe. Ist damit strikte 8+8=16bit Video. Wieder ohne mischbare 2x4 Blockgraphik. Ausser Attributen und Farben kompatibel mit der MDA. Aber im Gegensatz zur MDA kein 16bit SRAMs, nur 8bit DRAMs, was dann in der 80 Zeichen Breite den 2MHz Speicher trotz Doppelzugriffe in die selbige DRAM Page voll auslastet, und bei Zugriffen mangels Videodaten kurz ausnullen zu "Snow" führt.

Bitmap 320x200 2bpp in 1*IRGB-Register+festen-3er-satz. Braucht die ganzen 16k VRAM, daher keine Farbattribute, nur feste Farbsätze. Mit MC Reg Bit2=0 und CS Reg Bit5=0 Gn+Rt+Ge = RG(B=0) bzw Bit5=1 Cy+Vt+Ws = RG(B=1) oder MC Reg Bit2=1 Cy+Rt+Ws, sowie mit CS Reg Bit4=1 alle drei mit Intensiv addiert. Die CS Bit3..0 IRGB liefern hier neben Randfarbe auch für Pixel=00 Hintergrund. Das ist aber sehr limitierend, weil ohne 00=Schwarz gesetzt, hat man kein solches in allen drei Sätzen! Und den Rand will man ohnehin Schwarz haben. Also keine echte Farbauswahl.

Zudem liegen die Zeilen nichtlinear im 16k Videospeicher, weil die MC6845 nur bis 128 (Zeichen-)Zeilen zählen kann. Also werden die 200 Zeilen als 100 (Zeichen-)Zeilen 0,2,4,..198 zu je 2 Videozeilen pro Zeichenzeile dargestellt, mit dem Videozeile in Zeichenzeile Bit vorne an die resultierende 100*80=8000 = 8k ihren 13bit Adressen zusammengelegt, somit als Adresse+(0oder1)*8k genutzt.

Bitmap 640x200 1bpp in schwarz+1*IRGB-Register. Auch die ganzen 16k VRAM, keine Farbattribute, und keine Farbsätze. Die CS Bit3..0 IRGB liefern hier wenigstens Pixel=1 Vordergrund, mit Hintergrund und Randfarbe stets Schwarz, was weit besser ist. Wobei es nur Farben hat wenn mit RGB Monitor, nicht aber auf Videomonitor, während 320x200 auf beiden Farben hat. Auch hier gilt selbiger nichtlinearer Videospeicher. (Das ist in gewissem Masse genau ein Cromemco TV Dazzler im "X4" Modus, nur mit 16k statt max 2k und somit 8 mal mehr Pixeln, 640x200 statt max 128x128.)

Hat viel Speicher und hohe Auflösung. Aber die beiden Bitmapmodi liefern weder viele bpp noch ordentliche Farbwahl. Und der Textmodus kann weder mit RAM Font noch guter Blockgraphik aushelfen, weil nur selbige 1x2 und 2x1 der MDA. Egal was man hier versucht, es fehlt stets genau das was gute Spiele erlaubt.

Dies ausser man nimmt Text 80x25, stellt dann den MC6845 um auf 80x100(!) Zeichen, was in einem flachen 8x2 1bpp "Font" resultiert. Dann wird der Zeichenspeicher (jedes erste von zwei Bytes, 8von16k) fest mit von den ROM 2x1 Blockgraphik Zeichen 221 oder 222 gefüllt, was statt deren 160x25 nun 160x100 gibt. Danach wird im Attributspeicher (die zweiten Bytes, auch 8von16k) gearbeitet, mit Bits 7..4 (Hintergrund) links und Bits 3..0 (Vordergrund) rechts erscheinend, die beiden 4bit Farben für die resultierenden zwei 4x2 grossen "Pixel" (wie Apple II Blockgraphik ihre 2*4bit, aber hier neben einander statt über einander). Dies ergibt eine absolut brauchbare 160x100 in den vollen 16 Farben. Dieses wird als "Tweak Mode" bezeichnet. Nur war dieser den meisten Programmierern damals unbekannt, weshalb nur wenige Spiele es nutzten. (IBM selber bezeichnet dies im offiziellen Handbuch als Low Resolution, mit den 320x200 als Medium Resolution und 640x200 als High Resolution, und bemerkt noch dass es "not supported in ROM" ist. Es gibt dann aber keine Anleitung wie man es macht, nur Aussage "requires special programming", mit dabei noch fälschlich zu behaupten, dass es auf Text 40x25 basiert. Es behauptet ebenso falsch, dass 640x200 "Supports black-and-white only" ist.)

Acorn BBC Micro (1981)

Nachfolger des Acorn Atom von 1980 (mit MC6847). Anfangs als Acorn Proton bezeichnet (der Vorgänger hiess Atom, und der kleinere Nachfolger Electron), aber dann wegen Zusammenarbeit mit der BBC umbenannt. Mit Bild aus dem normalen DRAM Hauptspeicher. Für Timing und Adressen MC6845 Chip, Datenpfad ULA (Uncommitted Logic Array) Gate Array Semicustomchip, daher recht primitiv. Dazu noch einen SAA5050 Teletext Chip.

Trotzdem aber umschaltbar 7 Bitmap und 1 (Tele-)Text Modi:

Auch hier kann die MC6845 nur bis 128 (Zeichen-)Zeilen zählen. Im (Tele-)Text "7" kann sie damit direkt adressieren (wie PET/CBM oder eher wie MDA). In allen Bitmap Modi geht dies nicht mehr (wie CGA). Hier werden die 200 Zeilen aber als 25 (Zeichen-)Zeilen zu je 8 Videozeilen dargestellt (wie PET/CBM), aber das mit dem Videozeile in Zeichenzeile Bit als A0..2 zusammengelegt, womit die 8 Bytes einer Zeichenposition direkt hinter einander im Speicher liegen (wie TMS9918 "2" ("Graphic 2") seine 3 Fonts). Aber diese 8er dann in 16er Gruppen, in somit 128 Bytes. Von diesen passen 2*(16*8)=256 in die max 2*16=32k DRAM, welche wieder nichtlinear benutzt werden, in 2k Blöcken durch den Speicher springend.

Farben 2/4/16, aus 8(!) RGB. Mit bei RGB noch viertes Bit statt intensiv für blinkend, aber wegen Bitmap keine Zeichen Vordergrund und Hintergrund austauschen sondern durch pixelweise RGB Werte reversieren zu Komplementärfarben, Weiss auf Schwarz blinkt zu Schwarz auf Weiss, Gelb auf Blau blinkt zu Blau auf Gelb, aber Grün auf Schwarz blinkt zu Magenta auf Weiss, oder Weiss auf Blau blinkt zu Schwarz auf Gelb. Auf Fernseher oder Videomonitor oder RGB Monitor. Weil keine Rücksicht auf NTSC oder PAL, mit geraden 2MHz auf den Prozessor los.

Keine Textmodi, weil inzwischen genug Speicher um auch bei Bitmap genug Text darzustellen. Damit auch ohne dessen Verbrauch an Speicherbandbreite füt Zeichencodes, mit statt dessen bis zu 640 Pixel verdoppelt. Daher aber auch die "halbierten" Modi 4..6 mit nur 8 bis 10k, statt "volle" Modi 0..3 mit 16 bis 20k, für falls nur Model A mit nur 16k DRAM (erst Model B mit 32k erlaubt "volle" Modi). Die 256 sind wie beim Microtan 65 wegen Design nur für PAL Monitor machbar, eine britische Eigenart welche ebenso im Compukit UK101 der Fall ist (dort als 32x32 Zeichen mit 8x8 Font). Damit ist dies ein total moderner Rechner, mit 8 bis 20k Bild, von den 64k in der Einleitung nur noch Faktor 3 bis 8 entfernt.

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

Hercules Graphics Card HGC (1982)

Kein Rechner, sondern eine Karte für den IBM PC Bus. Erweiterte graphische Alternative zu den MDA (keine Farben oder Graphik) bzw CGA (Graphik und Farben aber niedere Auflösung) Karten. Benutzt den verbreiteten MDA Spezialmonitor. Scheidet damit auch hier strikte aus, wird aber als erweiterte MDA gerade noch der Vollständigkeit wegen durchgelassen. Kann aber neben dessen Textmodus mit vollem 9x14 1bpp ROM Font, auch einen Bitmapmodus mit hoher Auflösung (aber ohne Farben). Wegen Karte mit separatem 32k VRAM (strikte sind es sogar 64k VRAM, in 2 32k Pages) aus DRAMs (wie TMS9918), daher auch asynchron und nicht Prozessor bremsend. Aber mit Adressen vom Prozessor, auch dessen Adressmodi ausnutzend (wie MDA und CGA, ungleich TMS9918, als entscheidender Vorteil). Verwendet den MDA Adressbereich auf 64k erweitert, kann daher nicht mit einer CGA im gleichen Rechner sein, und logisch nicht mit einer MDA. Wurde manchmal auch als Monochrome Graphics Adapter MGA bezeichnet.

Der Bitmapmodus verwendet 720x348 1bpp. Damit auch keine Graustufen, trotz dass der MDA Monitor 3 Helligkeitsstufen kann. Verwendet nur 348 Zeilen trotz den 350 des Monitors und genug Speicher für solche. Das weil er wegen der MC6845 ihrer Limite auf max 128 (Zeichen-)Zeilen diesen mit vertikal 87 (Zeichen-)Zeilen zu je 4 Videozeilen pro Zeichenzeile betreibt, diesmal mit den zwei Videozeile in Zeichenzeile Bits vorne an die resultierende 87*80=<8000=8k ihren 13bit Adressen zusammengelegt, somit als Adresse+(0bis3)*8k genutzt.

Kaypro II (1982)

Früh erschienen, alles reine TTL Logik, keine Customchips, und passt in portabel, dementsprechend recht primitiv. Direkt im Rechner eingebaut, mit Bild aus separatem 2k VRAM aus SRAMs. Hat nur 1 Textmodus. Text 80x24. Mit 7x10 1bpp Font. Aus festem ROM Satz, von 128 ASCII Zeichen. Dieses hat neben 96 ASCII auch 32 Graphikzeichen drin. Dazu noch Blinkattribut (wie VDM-1 und Sol-20). Bei 80*7=560 von 14MHz Pixeltakt ein mittleres 40micro;s Textfeld. Nur Schwarzweiss, auf dem eingebauten 9" Monitor.

Dabei kann er (wie Apple II) wegen 80 Zeichen pro Zeile keine 2^n sein nicht einfach die X und Y Koordinaten als Adresse zusammenlegen. Es gibt wieder keinen massiven Y*80+X Addierer. Ebenso nicht den kleinen Apple II 4bit Addierer. Er hat aber auch keinen separaten Adresszähler (wie PET/CBM, und in MC6845 auch MDA oder CGA).

Vielmehr werden die 80 Zeichen pro Zeile mit einem einfachen Schalter auf Adressbit6 in 64+16=80 zerteilt, und diese eigenartig nichtlinear im 2k Speicher abgelegt. Zuerst (4*16=64)x(3*8=24) in den ersten 1.5k und dann (3*16+16)x8 in den verbleibenden 0.5k (mit so 16x6 unbenutzt). Wegen separatem SRAM gehen Prozessor und Video Adressen aber durch den selbigen Schalter. Also erscheint dies dem Programmierer einfach als einen 4k Block, mit 128x32 Zeichen (wie Osborne 1), aber diese mit Zeichen den von 64 bis 127 vierfach überlappend, und Zeichen von 0..63 der Zeilen von 24 bis 31 ebenfalls mit je 3 Zeilen von obigen (und einem der unbenutzten 16er). (Dieser Ansatz wurde in der wegen Firmenuntergang nie verkauften VDM-2 auch so gemacht. Was dann vom Entwickler Ende 1979 veröffentlicht wurde, und vermutlich durch dann Kaypro kopiert.)

(Der Nachfahre Kaypro 10 (1983) erweiterte auf separates 2+2=4k VRAM aus SRAMs, asynchron vom Prozessor und mit eigenen Adressregistern (wie TMS9918). Text 80x24, aber mit der verwendeten Rockwell 6545-A1 wären eigentlich 80x25 machbar, weil diese lineare Adressen erzeugt. Wohl wegen zu obigem kompatibel bleiben nicht ausgenutzt. Lineare Adressen erzeugt diese nicht nur bei Videodaten auslesen, sondern auch bei den Adressen für Prozessorzugriffe (die Daten selber gehen aber nicht durch den 6545-A1 (wie bei TMS9918), sondern durch separate Tristate Gatter (wie bei PET/CBM)). Mit 8x? 1bpp Font. Aus festem ROM Satz, von 256 Zeichen, 128 ASCII+Graphikelemente plus weitere 128 (*2 mit revers) für im Font integrierte mischbare 2x4 Blockgraphik (gibt mit dabei den vollen 80x25 Speicher doch ausnutzen sogar 160x100!) (das was der MDA genau fehlt). Neben 2k 8bit Zeichen SRAM auch 2k 8bit Attribut SRAM (wie MDA), wovon aber nur 4bit genutzt sind, für revers und halbhell und blinken und unterstrichen. (Die VDM-2 hatte 128+revers Zeichen, sowie 4 Attribute für halbhell und blinken und unterstrichen sowie Font ROM/SRAM auswählen.))

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

Anfangs als Spielkonsole Max-Machine (bzw Ultimax oder VIC-10) mit nur 2k SRAM Speicher designt, aber dann umpositioniert als Nachfolger vom VC-20 und mit 64k DRAM verkauft. Einzelner Chip VIC-II (Video Interface Chip II), als erweiterten VIC des VC-20. Daher ebenfalls ein generischer Videochip (NTSC MOS6567 und PAL MOS6569). Wenn auch wieder nur von Commodore genutzt. Mit Bild aus dem normalen DRAM Hauptspeicher (die Max-Machine ihre nur-NTSC MOS6566 benutzt hingegen aus dessen SRAM). Hat alle guten Eigenschaften vom VIC geerbt, aber alle seine Schwächen abgelegt, insbesondere die horizontal zu niedere Auflösung von 22x23 auf 40x25 verdoppelt. Zudem kamen weitere nette Sachen dazu, wie Bitmap und Sprites. Die Designer hatten gezielt die Features anderer Chips und Rechner verglichen, und daraus ihre Wunschliste erzeugt. Die Sprites wurden explizit wegen der TMS9918 addiert, und oft auch so benamst (offiziell heissen sie aber Movable Object Blocks).

Er hat Umschaltbar 3 Zellmodi und 2 Bitmapmodi:

Zell immer 40x25 Zeichen (wie PET/CBM), und somit den massiven VIC Schwachpunkt an horizontaler Auflösung korrigiert. Hat zwar nur die selbige 2MHz Speicherbandbreite (1MHz Prozessor und 1MHz Video). Aber das reicht zumeist ohne Prozessorbremse für 40 Zeichen mit pro Videozeile lediglich den Font holen, weil die Zeichencodes nur in der ersten Videozeile eines Zeichens geholt werden (wie Atari 800 Zellmodi "2" bis "5"), mit sie danach aus einem internen Buffer von 40 Zeichencodes (und auch noch von 40 Farbcodes) wiederholen. Dies haltet den Prozessor während der 2*40 Zugriffe um Zeichencodes und Font mit vollen 2MHz zu holen für jeweils 40µs an, was aber nur in 25 der angezeigten 200 Bildzeilen passiert, so nur noch 1/8 der ansonsten 40% = 5% an Leistung kostet. Diese Anhalter sind als die 25 "Bad Lines" bekannt.

Dies mit 8x8 1bpp oder aber 4x8 2bpp "Multicolor" Font (wie Atari 800 und VIC). Aus variablem ROM/ModulROM/RAM Satz (wie Atari 800), von 256 Zeichen (wie TMS9918 und VIC). ROM hat 2x2 Blockgraphik, sowie alle PET/CBM Graphikzeichen darin (beide Fonts davon, wie VC-20, aber neu gestaltet mit 2 Pixel breiten vertikalen Linien). Aber mit ModulROM/RAM erlaubt wieder spielespezifisch ersetzbar, jetzt sogar ohne von ModulROM ins RAM umkopieren. Bei somit 40*8=320 von etwa 8MHz Pixel ein mittleres 40µs Textfeld. Dazu wieder ein 1kx4bit FarbRAM (und somit strikte 64+0.5=64.5kBytes Speicher im C64) mit Vordergrund Farbattribut (wie VIC). Ebenso mit identischen unteren Adressbits A0..A9 nutzend, womit der VIC-II ebenfalls ein 8+4=12bit Videochip ist (wie VIC). Das erlaubt wieder 256 Font mit vollen 16 (bei fest 1bpp) bzw noch 8 (bei "2bpp", genauer 1bit zeichenweise 1bpp/2bpp, wie VIC) Vordergrund Farben zu kombinieren (mit hier leicht andere Farben als beim VIC, selbige Schwarz Weiss Rot Cyan Magenta Grün Blau Gelb, dann Hellbraun aber Dunkelbraun statt Pastellbraun, sowie die Pastelle von Rot * * Grün Blau *, aber dann die * als Graustufen 25%/50%/75% statt Pastell Cyan/Magenta/Gelb). Besser als alle anderen Rechner ihre Zellmodi bisher.

Zu obigen 2 hat es zudem "Extended", nur mit 8x8 1bpp Font (nicht mit 4x8), aus Satz von 64 Zeichen, mit Bit7+6 als 4 Hintergrund Farbattribut und Bit5..0 als 64 Zeichen. Auch hier, wie Atari 800 Zell "6", für 4 Farben und 64 Zeichen, nicht als 4*64 Zeichen mit je eigenen 64 für jede Farbe. Man kontrastiere dies aber im Atari 800 nur um zu 2bit Vordergrund Farbattribut zu kommen, statt hier zu 2bit Hintergrund zusätzlich zu dem FarbRAM 4bit Vordergrund, und Atari 800 das auch noch mit nur 20 Zeichen breit, unter dem VC-20 seinen 22 liegend!

Bitmap 320x200 1bpp oder aber 160x200 2bpp "Multicolor". Strikte sind dies nur 1000 von 1024 Zeichen von 4 linear durchlaufenen 256er Fonts (analog TMS9918 "2" ("Graphic 2"), falls alle Zeichen von den 3 Fonts linear benutzt werden). Aber hier ohne die eigentlichen Zeichencode Zugriffe, weil stets fest linear durch die 4 Fonts. Daher liegen die Pixel ebenso nichtlinear im 8k Speicherausschnitt, sondern wie zu einem Font passend in 8 Bytes/Zeichen Gruppen. Neben dem 1kx4bit FarbRAM werden aber auch die wegen die 4 "Fonts" stets linear durchgehen nun unbenutzten 1kByte an Zeichencode RAM als weitere Farbcodes benutzt, mit bei 8x8 1bpp 2von16 bzw bei 4x8 2bpp Pixel gar 3von16 Farben pro Zelle. Besser als alle anderen Rechner ihre Bitmapmodi bisher. Daher bleiben aber auch die "Bad Lines" hier erhalten.

Hat 320 Pixel (wie PET/CBM und Atari 800). Aber mit etwa 8MHz Pixel ein schmales Textfenster von 40µs (wie 320 vom PET/CBM und 280 vom Apple II). Damit keine/wenige NTSC Farbmonitor 4 Farben Effekte, weil dem etwa 8MHz Pixeltakt seine /2=4MHz Wellen nicht auf die 14.31818/2/2=3.579MHz von NTSC oder 17.734472/2/2=4.434MHz von PAL fallen. Das erst recht nicht mit dem revidierten 6von8Pixel Font seinen Zeichen mit 2 Pixel breiten Vertikalen und deren 2MHz Wellen. Weshalb man sich ernsthaft fragt, warum andere so sehr bereit waren 1/8 Prozessortakt zu opfern. (Vielleicht wegen billigem 14.31818/16=0.895MHz Divisor bei NTSC, aber bei PAL einem aufwendigeren 17.734472/20=0.8867MHz. Während C64 bei PAL den identisch teuren 17.734472/18=0.985MHz benutzt, und bei NTSC konsistent diesen als 14.31818/14=1.0227MHz nutzt, was der Apple II auch schon hatte. Oder weil sie die Pixelgrenzen genau auf NTSC Farbwellen legen wollten, trotz dass deren Farben genau in der Phasenverschiebung codiert sind, und dies sowieso bei PAL versagt.)

Was hier aber komplett fehlt ist Overscan. Vermutlich weil das nur 1k an FarbRAM mit 40x25=1000 bereits voll ist, es keine zu erwartenden 48x30=1440 oder gar 52x32=1664 an Zeichen abdecken kann. Hat fein scrollen horiontal und vertikal, aber stets ganzes Bild. Dieses wird auf 38 Zeichen bzw 24 Zeilen reduziert, im Gegensatz zum Atari 800 der die Scrollverluste kompensieren kann, horizontal mit 2*4 Overscan addieren, vertikal mit mehr Zeilen in Displayliste). Scrolldistanz ist 3bit statt 4bit, horizontal mit Pixel um 0..7 verzögern (scrollt so auch nach rechts), vertikal mit Zeilen um 0..7 verzögern (scrollt so nach unten).

Hat zwar keine Displayliste, aber die aktuelle Zeilennummer ist auslesbar, sowie mit automatischem Vergleich auch als Rasterinterrupt nutzbar. Dieses plus jederzeit Moduswechsel durch Software erlaubt vieles zu kompensieren (inklusive der Randfarbe vom Overscanbereich umschaltbar machen um Hintergrund Bänder bis in den Rand hinauszuziehen, oder fein scrollen selektiv einschalten um Bänder zu scrollen). Kann keine Zeilen zusammensammeln, also muss grob scrollen per umkopieren geschehen, und auch keine Bytes an Zeilenende überspringen, also muss was an einer Kante herausscrollte für die gegenüber viederverwendet werden. Generell opfert Commodore bzw MOS nur wo gewollt etwas Prozessor um stets Videochip Komplexität und Bandbreite 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 TMS9918), aber mit Rasterinterrupt explizit mehrfach verwendbar. Mehr Sprite Bits als jeder andere 8bit Rechner, vermutlich weil keine Bandbreite für horizontales Overscan oder Displayliste verbraucht wird.

Farben mit Register auswählbar aus 16 festen NTSC Farbton+Helligkeit Kombinationen (vermutlich identische 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.

Damit hat es alles vom VIC, inklusive Zellmodi mit ladbarem Font Ansatz und das FarbRAM für jedes Zeichen. Aber auch die verdoppelte horizontale Auflösung und Bitmap und auch noch Sprites. Wie man sieht ist dies ein mengenmässig sehr leistungsfähiger Chip, trotz strukturell weit einfacher als beim Atari 800, eher auf dem TMS9918 Niveau, aber ohne dessen Bandbreite Limitation auf 32 Zellen wenn mit Farben, und ohne dessen 1bpp Limiten. Er wurde damit zum idealen Kompromiss und begründete den guten Ruf vom C64.

(Der Nachfahre Commodore 128 (1985) hat einen leicht erweiterten VIC-IIE (NTSC MOS8564 und PAL MOS8566), mit nur einen Port addiert, wie von 6502 zu 6510, sowie dem 1zu2MHz Modusschalter. Zusätzlich dazu einen VDC Chip (MOS8563), wie TMS9918 mit eigenem Speicher (hier 16k oder 64k), asynchron vom Prozessor und mit eigenen Adressregistern. Aber ansonsten eher an die C64 und Kaypro 10 angelehnt was das Videoformat anbegeht. Für Timing und Adressen aufbauend auf einem erweiterten MOS6545 Registersatz, dabei sogar kompatibel mit der erweiterten Rockwell 6545-A1. Text 80x25 Zeichen. Mit 8x8 1bpp Font, stets aus RAM Satz, von 256 Zeichen. Mit vollen 8bit Attributen, aber nur Bits 3..0 Vordergrund RGBI Farben und keine Hintergrund Farben (nahe C64), weil Bits 7..4 alternativen Zeichensatz und revers und unterstrichen und blinkend sind (nahe VDM-2 und Kaypro-10). Gar kein 2bpp. Daher Bitmap auch nur 640x200 1bpp, in vollen 16k, ohne Farbattribute, nur 2 RGBI Register (nur leicht besser als CGA). (Die MOS8563 wurde übrigens für ein Z8000 und Unix basiertes Workstation/Timesharing System Commodore 900 designt, als Ersatz von PET/CBM gedacht. Dieses war bereits fertig zum in den Verkauf gehen, wurde aber nach dem Einkauf des Amiga abgeschossen, trotz dass dieser eher Ersatz des C64 war.))

Jupiter Ace (1982)

Abgeleitet von ZX80 und ZX81, weil von ex Sinclair Leuten welche an ZX80 und ZX81 (sowie auch ZX Spectrum) gearbeitet hatten. Hat gleichen Z80A Prozessor und 6.5MHz Takt, aber 2 4k EPROMs statt 1 4k bzw 1 8k ROM (und mit Forth statt Basic drin), ebenso 1 7805, mit dazu noch 19 genau TTLs (keine ULA). Also eher ZX80 Technologie. Dementsprechend ziemlich primitiv.

Aber hat 3 Paare 1kx4 SRAMs statt nur 1 Paar, als je 1k für System und Benutzer, plus separates VRAM, plus separatem Fontspeicher (FRAM). Wegen FRAM ist beim Fontzugriff kein I Register als Basis ausnutzen notwendig. Wie bei TMS9918 muss der Font aber vom System aus ROM ins FRAM geladen (und dabei dekomprimiert) werden, ist dafür auch beliebig modifizierbar. Nichts in der damaligen Presse hat auf ein derartiges Feature hingewiesen, weil nur von Forth statt Basic gesprochen wurde, der Rest vom Rechner komplett ignoriert. Also war dieser völlig überraschend gut. Das VRAM hat stets Platz für volles Bild (brauch nur 3/4k, restliche 1/4k werden als Buffer benutzt). Braucht kein HALT mit Datenbit6 um dieses erkenntlich zu machen, was 128+reverse Zeichen erlaubt. Ebenso kein Adressbit6 = 0 vom R Register als Interrupttimer. Es wird ohnehin voll in Hardware ausgegeben, ohne den Prozessor zu benutzen oder NOPs vorzugaukeln, mit so stets Bildausgabe und Sync, und das alles ohne Prozessor zu bremsen.

Er benimmt sich somit wie eine stark reduzierte TMS9918, mit nur "Graphic 1" Mode, nur 128+reverse Zeichen an Font, feste weiss auf schwarz Farben, und ohne Sprites. Aber wegen separaten VRAM und FRAM, mit Adressen vom Prozessor auch dessen Adressmodi ausnutzend (wie CGA). Das sogar mit wählbarer Priorität. Adressbit10=1 bekommt Prozessor Waitstates bis eine Videozeile ausgeben fertig ist, trotz dass der Speicher eigentlich Zugriffe zwischen Videodaten holen aushalten würde. Adressbit10=0 wartet Prozessor nicht, aber die Videoausgabe wird gestört durch dessen unpassenden Speicherzugriff, was dann "Snow" ergibt.

Wie beim ZX80 in wenigen TTLs implementiert (braucht 19 statt dessen 18, trotz weit besser zu sein), statt wie bei ZX81 in einem ULA (umgerechnet etwa 23 oder 24 TTLs). Dies gerade auch wegen separatem Fontspeicher, was alleine 4 TTLs der ZX80 einspart (3 für ROM Adresse umschalten und 1 für Zeichencode zwischenspeichern). Mit den Jupiter Ace noch etwas vereinfachen, Font in 2k EPROM statt 1k FRAM, wäre er mit noch 3 TTLs weniger (2 für FRAM schreiben/lesen Logik und 1 für Hardware reverse), sogar mit 16 unter der ZX80 ihre 18 gekommen, trotz immer noch besser sein als die ZX81! Er beweist, dass die ZX80 ein Fall war von sparen egal was es kostet, und bei als ZX81 verbessern wurde die Rechnung fällig, wenn auch in der ULA versteckt. Anderseits kann er wegen separatem VRAM und FRAM auch keinen undokumentierten Bitmapmodus aus dem Hauptspeicher.

Nur 1 Textmodus. Text 32x24. Mit 8x8 1bpp Font. Aus variablem RAM Satz, von 128+reverse Zeichen. Dies reicht für volles ASCII und Graphikzeichen, aber insbesondere auch für bliebige spezifische Zeichen. Mit 256 von 6.5MHz Pixeltakt trotz nur 32 Zeichen ein 39.4µs breites Textfeld. Nur in Schwarzweiss. Kein Bitmap.

Sinclair ZX Spectrum (1982)

Nachfolger der ZX80 und ZX81. Minimalrechner, mit dem Ziel designt billigster farbiger Rechner zu sein. Wie ZX81 mit einem ULA (Uncommitted Logic Array) Gate Array Semicustomchip, aber mit nur fast alles drin, weil auch noch 6 TTLs (4 davon nur falls Spectrum 48k, mit 16k Grundspeicher und 32k Erweiterung, diese entsprechen also dem DRAM Modul). (Es gibt einige Spectrum Clones, welche nahelegen dass die ULA etwa 30 bis 40 TTLs entspricht.) Daher halb primitiv, aber weitaus besser. Im Gegensatz zu ZX80 und ZX81 voll in Hardware laufend, mit stets Bildausgabe und Sync, sowie ohne Prozessor bei Ausgabe zu bremsen. Mit Bild aus separatem 16k VRAM (bei Spectrum 16k alles, bei Spectrum 48k die ersten 16k) aus DRAMs (wie TMS9918), daher auch asynchron und nicht den Prozessor bremsend. Aber mit Adressen vom Prozessor, auch dessen Adressmodi ausnutzend wie CGA. Daher kann ein Spectrum 16k mit nur dem VRAM laufen.

Nur 1 Bitmapmodus, da mit DRAMs ausreichend Bitmap Speicher jetzt billiger ist als ZX80 und ZX81 Text oder TMS9918 Zell Logik. Bitmap 256x192 1bpp (wie TMS9918A "2" ("Graphic 2")). Mit 256 von 7MHz Pixeltakt, ein recht schmales 36.6µs Textfeld. Trotz Bitmap und nicht Zellgraphik hat er wie bei Zellgraphik für jeweils 8x8 Pixel Zellen Farbattribute (wie VC-20 und C64). Diese sind als 1+1+3+3bit RGBI, wobei Vordergrund und Hintergrund nur eigene 3bit RGB haben (in Vorder Bit0..2 bzw Hinter Bit3..5, als GRB), mit gemeinsamem I (in Bit 6). Dazu noch stets blinken (wie CGA wenn Hintergrund Intensität auf Blinken umgeschaltet ist) (in Bit7). Dazu noch separates RGB ohne I (auch als GRB) Register für den Rand (wie VC-20 nur 8 Randfarben). Wäre ohne blinken leicht billiger gewesen, und mit dem Bit7 genutzt für Vordergrund und Hintergrund beide volle 4bit IGRB sogar leicht besser ohne teurer.

Diese Farbattribute aber mit nur alle 8x8 Pixel eine Farbzelle, und ohne den VC-20 und C64 ihren "Multicolor" 2bpp 4 Farben Modi, was oft in "Attribute Clash" resultierte, wenn in einem 8x8 Feld mehr als nur 2 Farben gebraucht werden (was beim TMS9918 trotz 1bpp wegen dessen kleinerem 8x1 Feld weit weniger zutraf, und dort als "Color Spill" bekannt ist, und bei VC-20 sowie C64 erst bei mehr als 4 Farben geschieht). Dieses fehlende 2bpp ist wohl die grösste Schwäche dieser ansonsten erstaunlich guten Graphik.

Hat kein separates FarbRAM wie VC-20 und C64, muss daher trotz dass er stets Bitmap benutzt (und damit keine Zeichencode Zugriffe braucht) trotzdem vergleichbare Zugriffe machen (wie beim C64 Bitmap "Multicolor" das Zeichencode RAM als weitere Farbcodes benutzen). Dazu muss er bei jeder Zeile den Prozessor für 6/8 seiner Takte (bzw 12/16 Pixeltakte) stoppen (nur ein Speicherzugriff von 2 Takten alle 8 Takte (=16Pixel) ist noch möglich, neben den 2*2 Videozugriffen in 2*3 Takten), falls dieser auf die ersten 16k vom DRAM Speicher zugreift. Das ist als "Waitstates" oder "Contention" bekannt.

Dies geschieht bei allen Zeilen, nicht nur jeder ersten Zeile von Zeichen (wie die C64 "Bad Lines"), weil die ULA keinen internen Buffer hat. Beim C64 sind es aber auch CPU für 40µs zu 100% stoppen, hier nur von 0% bis 75% Verlust (je nach auf welches von 8 Takten der Prozessor loslegt mit 0..7 Waits). Es ist zudem wegen separatem VRAM und Z80 und Basic ROM ungebremst ausser für die wenigen Zugriffe auf Basic Status und Code und Variablen vernachlässigbar. Es bremst aber bei Maschinencode um etwa 21/64=33% (C64 40/8=5%). Weshalb viele Spiele nach 48k verlangen, nicht nur für mehr Platz für Programm sondern auch wegen voller Geschwindigkeit in den ebenso ungebremsten separaten 32k.

Selbst für in 2*3 von 8 Takten müssen aber die 1Byte Attribute einer Zelle und alle 8Bytes Bitmap welche zu diesen passen in der gleichen 128Byte DRAM Page liegen, um Doppelzugriffe auf die langsamen DRAMs auszunutzen. Was in einem massiv nichtlinearen Bitmapspeicher resultiert, vergleichbar zu aber schlimmer als die linear durchlaufenen 3 oder 4 256er Fonts der TMS9918 und C64! Dazu hat es hier die 8 Zeilen eines Zeichens trotz nur 32Bytes Zeilenlänge in 256er Schritten im Speicher abgelegt (und das DRAM mit A0..6 als /RAS sowie A7..13 als /CAS angesteuert), mit dazwischen die Zeilen der nächsten 7 Zeichen. Womit die 192 Bitmapzeilen (6kByte) in 3 64er Gruppen (zu je 2kByte) kommen, in Reihe 0,8,16,..,56, 1,9,17,..,57, .. 7,15,23,..63, dann 64..127 und dann 128..192 bis auf 3*2=6k hinauf, dann die Attribute ihre 768Bytes linear. Womit die oberste Zeichenzeile ihre Bitmapzeilen in Adressen Hex 4000..401F,4100..411F,4200..421F, .. 4700..471F liegen und ihre Attribute in 5800..581F, mit dazu xx00..xx1F einmal mit /RAS gesetzt und dann 4[0..7]xx und 58xx mit zweimal /CAS gelesen!

Mit Softwaretechniken ähnlich denen der VCS/2600, welche hier die Farbattribute von Zeile zu Zeile überschreiben, können diese bis auf 8x1 Pixel aufgeteilt werden. Auch die Randfarbe kann so geändert werden, um Hintergrund Bänder bis in den Rand hinauszuziehen. Aber mangels jeglicher auslesbarer aktuellen Zeilennummer kann solche Software nur mit der Bildausgabe synchronisieren, indem sie vom Bildrücklauf Interrupt getriggert wird, dann durch das ganze Bild ausgeben Zyklen abzählt! Da Interrupts aber eine Latenz haben, kann die Software nur genau auf Takt synchronisieren mit Einausgabe lesen von nicht vorhandenen Geräten und dabei den Video Lesevorgang betrachten, dies auf erste paar Zeilen mit spezifischen Pixelmustern aber mit beiden Farben anfangs schwarz! Ende Bild kann man in das Hauptprogramm zurück, welches dann normal Bild aufbaut, immerhin weil dann kein Bild ausgegeben wird mit voller Leistung vom Prozessor.

(Der Nachfahre Spectrum 128 hat identisches Video, unterscheidet sich nur durch Erweiterung des Rechners von 64k auf 128k DRAM, welche als 8*16k verwaltet werden, wovon 2*16k Videospeicher sein können, sowie den Bildausgang neben PAL Fernseher auch direktes RGB. Zudem addierte er für Audio einen AY-3-8912 Soundchip.)

Tangerine Oric-1 (1982)

Ein direkter Konkurrent vom ZX Spectrum, und auch etwa vergleichbar halb primitiv, aber nicht ganz so gut. Mit Bild aus dem normalen 16k oder 64k (nur 48k nutzbar) DRAM Hauptspeicher. Kann aber 2 Modi, Zell und Bitmap: Zell hat 40x28 Zeichen, von denen aber Basic nur 39x27 benutzt (weil fest 1 Zeile oben Status ausgibt, und 1 Spalte links Hintergrundfarbe setzt oder zweiten Zeichensatz anwählt für die jeweilige Zeile). Mit 6x8 1bpp Font (wie TMS9918 "Text"). Bitmap hat passende 240x200 1bpp, aus eigentlich für 320x200 reichende 8000 von 8kByte, aber mit davon nur 6 breit als Pixel genutzt, wie beim Font. Plus darunter in den verbleibenden 8192-8000=192 Bytes 3 Zeilen zu 40 an Zellmodus (wie Apple II seine 4 Text unten), aber diese stets aktiv. Diese 3 Zeilen decken sich in Ausgabezeilen und Speicherplatz mit den letzten 3 der 28 vom Textmodus, und Basic scrollt auch nur noch in diesen, kürzt einfach von 39 nutzen auf 3. Somit auch 200/8+3=28 Textzeilen hoch, bzw 200+3*8=224 Videozeilen, dank PAL Monitor (wie Microtan 65 und BBC). Hat für Audio einen AY-3-8912 Soundchip. Bis jetzt ist es noch relativ normal.

Was aber fehlt ist trotz zeichenweise Farben jeglicher Platz für Attribute! Dies weil unzureichend Speicherbandbreite für bei jede 6 Pixel zeichnen 1 8bit Zeichencode und 1 6*1bit Fontstreifen und 1 Farbattribut lesen, und einem vierten Zugriff freilassen für den Prozessor. (Wobei die verbauten 150ns DRAMs sogar schneller sind als die bei der TMS9918 minimal verlangten 200ns.) Womit dies wegen Attribute fehlen an Bandbreite dem "Text" Modus der TMS9918 entspricht, mit nur 3 Speicherzugriffe pro 6 Pixel, bei 6MHz Pixeltakt und 3MHz Speichertakt (davon 1MHz für den Prozessor, aber mit 1.5MHz Timing, weshalb ein 2MHz Prozessor verbaut wird), und somit bei 40 Zeichen ein 40µs breites Textfeld. Es hat aber trotz keiner Bandbreite für Attribute doch zellenweise Farben!

Im Zellmodus gilt statt dessen, dass die 8bit Zeichencodes auf x00xxxxx Muster getestet werden. Mit ungleich das gewertet als RZZZZZZZ für 96 (ASCII-)Zeichen, mit R=1 die beiden Farben reversierend. (Strikte wird wie im BBC seinem blinken der RGB Wert invertiert, trotz Zellmodus, blinken tut hier aber die 1-Bits im Zeichen ausfiltern wie bei den meisten!) Mit 6x8 Font. Aus variablem RAM Satz, von deswegen nur 96+revers. Aber mit gleich das gewertet als x00AAAAA für setze Attribut statt zeichne Zeichen (welches dann als Leerzeichen gezeichnet wird, mit R wirkend). Dabei wirken die AAAAA bei 00BGR als setze Vordergrund Farbe und bei 10BGR als setze Hintergrund Farbe. Ebenso wirken sie bei 01FDA als setze F=Flash(blinkend) und D=Doppelhoch und A=Alternativen Zeichensatz (weitere 96+revers Zeichen, mit 32..95 davon als 2x3 Blockgraphik vorbesetzt). Verbleibende 11GHx wirken als schalte Modi, mit G=GraphikBitmap(1)/Zell(0) und H=60Hz(1)/50Hz(0) und x ignoriert. Geladen werden normaler Zeichensatz ASCII 32..127 und alternativer Zeichensatz Blockgraphik 2x3 in 32..95.

Im Bitmapmodus wäre ohne Zeichencode genug Bandbreite vorhanden. Trotzdem gilt wie oben, dass die gelesenen 8bit an Pixelmuster ebenfalls auf x00xxxxx Muster getestet werden. Mit ungleich das gewertet als R1PPPPPP für 6 Pixel P, wieder mit R=1 Farben reversierend. (Daher wohl wie beim BBC blinken den RGB Wert invertierend, weil hier kein Zellmodus, aber blinken tut weiterhin die 1-Bits ausfiltern!) Aber mit gleich das wieder gewertet als setze Attribut statt zeichne Pixel (welche dann als Leerpixel gezeichnet werden). Wobei hier die D und A Attribute vom 01FDA unwirksam werden. Zellmodus oder Bitmapmodus kann von 6er Pixelsatz zu Pixelsatz umgeschaltet werden, solange Zell und Bitmap Speicheranordnung nicht kollidieren (was sicher ist falls die untersten 24 Zeilen Bitmap nicht genutzt werden).

Tangerine nennt dies "serielle Attribute". Es erlaubt 2*3+2=8 (in Bitmapmodus) bzw +3=11 (in Zellmodus) Bits an Attributen, ohne dafür separaten Speicher zu verbrauchen, und ohne 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 (Bitmap) bzw gar 6x8 Feld (Zell) gebraucht werden, sondern bereits wenn solche in direkten Nachbarfeldern ohne ein "leeres" (= alles Hintergrund) Feld dazwischen gebraucht werden. Ein sehr eigenartiges Design. Welches aber scheints auch im Teletext benutzt wurde.

Galaksija (1983)

Abgeleitet von TRS-80 Model 1 als Spezifikation aber mit ZX80 und ZX81 als Inspiration zu billig Video mit dem Prozessor aus dem normalen SRAM Hauptspeicher lesen. Hat den gleichen Prozessor, mit leicht weniger Takt als ZX80 und ZX81 (3.25MHz statt 3.5MHz), aber weit mehr als TRS-80 Model 1 (1.774MHz). Sowie 1 oder 2 4k EPROMs (mit stark modifizierten TRS-80 Level 1 Basic darin, in Basis und Erweiterung aufgeteilt), und 1 bis 3 2k SRAMs. Tastatur sehr ähnlich TRS-80 CoCo, fast identische 8x7 Matrix (insbesondere Pfeiltasten und Space in CoCo Matrixposition), aber 7Ein zu 8Aus statt 8Ein zu 7Aus (wie TRS-80 Model 1, nur dort auch 8Ein weil Shift eigene Zeile), und ohne @ und Clear, dafür mit Repeat und Del und List. Yugoslavischer Rechner, anfangs nur als Selbstbauanleitung in der Populärwissenschaft Zeitschrift Galaksija gedacht, erst später in Serie gebaut. Daher nur aus Standardchips (inklusive 2 4k EPROMs statt 1 8k ROM), sowie eine einseitige Platine mit Drahtbrücken wie in damaliger analog Audio und Video Elektronik üblich, dementsprechend ziemlich primitiv. Ebenso daher kein Herstellername.

Ohne den Gebrauch von I Register um Font zu adressieren, weil dieser in einem eigenen 2k Font EPROM ist (wie TRS-80 Model 1). Auch ohne HALT und Bit6 = 0 vom R Register für Interrupt ausnutzen, weil genug SRAM um volles Bild zu speichern. Alles zu Zyklen pro Zeile sowie Zeilen pro Bild sowie Syncpulse komplett in Hardware erzeugt, trotz weniger Chips! Daher auch kein Bild zucken möglich. Auch kein Zeichencodes als Programm auslesen mit NOPs vorgaukeln, sondern den Refreshzyklus mit Register I und R für die Zeichencodes auslesen benutzt (wie ZX81 im undokumentierten Bitmapmodus den "Font"). Daher keine Limite auf Bit6=0, volle 256 Zeichen sind machbar (werden aber vom 2k Font EPROM limitiert auf 2*64=128 davon, wie TRS-80 Model 1).

Mit IRQ Interrupt einmal pro Bild angestossen wird nur die Zeichenfolge ihre I und R sowie die Zeile in Font auswählen und Ende Zeilenausgabe blank per Programm gesteuert, mit während der Zeile ausgeben alles 4-Zyklen Befehle notwendig sein (31 von 32 NOPs, letztes Zeichen den Opcode vom Ende der Zeilenausgabe auf blank stellen, dessen Datentransfer hat kein Refresh, und der dann nach 7 Taken kommende Befehl ist wegen nun blank irrelevant). Das nicht ausgegebene 8te Bit von R wird in Hardware nachgeflickt, aber zusammen mit der Videozeile in Zeichenzeile in Software berechnet. Das kostet 1+(16*13)=209 von 320 Zeilen an Prozessor, lässt 35% vom 3.072MHz Takt, also effektive 1.06MHz (was mehr ist als ZX81 seinen 25% vom 3.25MHz, effektive 0.8MHz). Ein "FAST" und "SLOW" kann wegen IRQ statt NMI Interrupt einfach durch dies mit DI aus- bzw EI einschalten erreicht werden, Bildausgabe ist dann weg, aber Sync bleibt.

Trotz somit besser sein als selbst die ZX81, hat es nur 12 TTLs plus 2 damit vergleichbare 4000er CMOS, und somit noch unter der ZX80 ihre 18 TTLs, und weit unter der ZX81 ULA (umgerechnet etwa 23 oder 24 TTLs). Auch das wegen separatem Fontspeicher 4 TTLs eingespart. Er beweist, dass die ZX80 nicht nur ein Fall war von sparen egal was es kostet, sondern auch noch von dabei gar nicht mal alles mögliche gespart! Aber auch er hat gegenüber einem vereinfachten Jupiter ACE mit Font in 2k EPROM statt 1k FRAM und 16 statt 19 TTLs, dann genau identische 4+4+2k EPROMs und nur 2 TTLs weniger. Also auch sehr wenig gespart, trotz was es an Prozessor kostet.

Nur 1 Textmodus. Text 32x16 (wie TRS-80 Model 1). Mit 8x13 1bpp Font (nahe MC6847 8x12, sowie nahe VDM-1 und Sol-20 9x13). Aus festem ROM Satz von 64 beinahe-ASCII Zeichen (mit [ \ ] und ^ ersetzt für serbische Akzente, sowie ' und @ ersetzt mit Promptzeichen). Dazu vom Modusattribut Bit7 gesteuerte aber im Font EPROM integrierte mischbare 2x3 Blockgraphik (gibt 64x48) (wie TRS-80 Model 1). Mit 6.144MHz Pixeltakt, und somit trotz nur 32 Zeichen ein 41.67µs breites Textfeld. Nur in Schwarzweiss (wie TRS-80 Model 1 sowie ZX80 und ZX81).

Dazu gibt es noch einen mit leichter Modifikation machbaren Bitmapmodus. Dieser braucht nur ausreichend RAM (weil 6k Bild statt 0.5k), und Umgehung des Zeichensatz ROMs. Dazu wird dessen Ausgang abgeschaltet und die Bitmap statt Zeichencode Daten per Tristategatter direkt daran vorbeigeleitet. Wozu als Modusschalter das nur 6bit breite Videozeile in Zeichenzeile plus 8tes Bit Refresh plus Bandausgabe Hilfsregister von Bit2..7 um Bit1 erweitert wird. Nur einen der 16-13=3 ungenutzten Zeilen im Font EPROM mit Muster=Adresse laden ging nicht, weil eben nur 128 Zeichen dort Platz haben, Bit6 der Adresse ignoriert wird. Das resultierende Verfahren ist praktisch identisch mit dem ZX80 seinen undokumentierten Bitmapmodus, nur der volle Sync in Hardware spart wieder Prozessor. Dabei entstehen hier statt 32x16 Zeichen mit 8x13 Font nun (32*8)x(16*13) = 256x208 Pixel (ZX80 hat statt 32x24 Zeichen mit 8x8 Font dann (32*8)x(24*8) = 256x192). Diese Erweiterung, zusammen mit 32k DRAM Speicher dazu, sowie 8k mehr ROM für die Graphikroutinen und einen Vollbild Editor, und für Audio einem AY-3-8910A Soundchip, ist als Galaksija Plus bekannt.

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

Als Famicom hauptsächlich als Spielkonsole designt. Aber erweiterbar mit Tastatur (und anderem) an Erweiterungsport, sowie mit DiskSystem (1986) mit Floppylaufwerk als Untersatz plus BootROM und ErweiterungsRAM und Diskcontroller 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), ohne Tastatur oder DiskSystem, nur noch reine Spielkonsole, und dabei nicht mal das Modulformat kompatibel geblieben! Keine Paddles, aber dafür der erste Rechner mit Joypads neben Joysticks (wobei zu Atari Joysticks kompatible Joypads problemlos machbar sind).

Einzelner Customchip PPU (Picture Processing Unit) für Video. Sowie zweiter Customchip APU (Audio Processing Unit), mit Audio und Joypad Interface sowie Prozessor und "DMA" Blockkopierer Koprozessor, alle in einem Chip integriert. Benutzt wie TMS9918 separates VRAM, daher auch asynchron und nicht Prozessor bremsend. Wie bei diesem mangels Pins keine Adressierung vom Prozessor, braucht eigene Adressregister, verhindert Prozessor Adressmodi ausnutzen. Aber nur 2k VRAM aus SRAMs (sowie nur 2k sonstiges SRAM, und damit selbst zusammen sogar unter der VC-20 ihren 5.5k SRAM!). Beide sind neben den Programm und Font ROMs in Modulen auch mit RAM erweiterbar (dazu es hat separate Busse von Prozessor und Video zu den Modulen, daher die so breiten Modulstecker). Obiges "DMA" kann 256er Pages vom Prozessor ROM oder RAM ins VRAM kopieren, für zu Laufzeit erstellte Fonts, was aber am knappen VRAM scheitert ausser das Modul liefert auch noch SRAM mit. Stoppt den Prozessor bei Videozugriffen während der ganzen Bildausgabe komplett (kein schneller Speicher wie TMS9918, trotz SRAM). Man kann so nur während dem vertikalen Bildrücklauf zeichnen. Ebenso wird der Prozessor beim Blockkopierer benutzen gestoppt.

Nur 1 Zellmodus, kein Bitmap, mangels Speicherplatz. Zell 32x30. Mit 8x8 2bpp Font, und somit 256x240 Pixel. Das aber bereits inklusive dem Overscan in beiden Richtungen, wegen dem sehr niedrigen 14.31818/8*3=5.37MHz NTSC bzw 17.734472/10*3=5.32MHz PAL Pixeltakt. Damit selbst bei nur 32*8=256 Pixel ein mit 47.8µs relativ breites Textfeld erzeugt. Nur 3/4 relativ zu Atari 800 oder TMS9918 oder MC6847 ihren 7.16MHz, bzw gar 2/3 relativ zu C64 ihren etwa 8MHz, und nicht viel mehr als die VC-20 ihre etwa 4MHz. Womit diese 32 Zeichen bei anderen auf 44 bzw gar 48 verbreitert entsprechen würden, weshalb hier real etwa 24..28 Zellen breit für ein Textfeld nutzbar sind. Was auch die typisch klobigen Texte in Famicom/NES Spielen ergibt.

Dies dafür mit stets 8x8 trotz 2bpp Font, was mit 32 Zeichen sehr detailierte 256 Pixel gibt, trotz 4-farbig, weil ohne dafür auf 4x8 Font die Pixelzahl halbieren zu mössen (wie Atari 800 oder C64 von 320 zu 160 herunter). Braucht so zwei Bytes an Font pro Pixelzeile eines Zeichens, was mit nur vor dem ersten von zweiten Fontbytes ein Zeichencodebyte holen, dann 2/3 statt 1/2 der Speicherbandbreite an Fontdaten erlaubt, und damit erst diese Pixelmenge. Das genialste an diesem System, und das 2 Jahre vor der SG-1000 Mark III bzw Master System, welche dies dann auf 4bpp und 4/5 Bandbreite hinauf weiterzog. Dafür ist aber Text limitiert auf obige etwa 24..28 Zellen (im Gegensatz zu Atari und Commodore, mit entweder 40 Zeichen in grobem 4x8 Font oder 20 Zeichen in vollem 8x8 Font, oder zu Master System mit 32 Zeichen in vollem 8x8 Font). Aus ModulROM/ModulRAM Satz (VRAM ist zu klein), von 256 Zeichen, Format ist pro Zeichen 8+8=16 Bytes, zuerst 8 Bytes alle Bit0 dann 8 Bytes alle Bit1 (Atari 800 und C64 haben stets 8 Bytes, mit jedes 8*1bit oder 4*2bit drin).

Weiterhin fein scrollen horizontal, mit pro Zeile variabler Menge, was Parallaxscrollen erlaubt (tiefenabhängig vorne/unten schneller scrollend als hinten/oben), und vertikal zwischen Zeilen (erlaubt Splitscreen Effekte). Dabei können Bildauschnitte von einem 2k Bildspeicher verwaltet werden, als (2*32)x30 horizontalscroll oder 32x(2*30) vertikalscroll, bei mit SRAM erweiterten Modulen mit 2+2=4k sogar als (2*32)x(2*30) beidescroll.

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 notwendige Anzahl Muster im Font reduziert, gerade auch wenn Spritebewegungen von nach rechts zu nach links wenden (und damit ist dies sinnvoller bei Sprites als bei der Sega Master System dies für Bild/Spielfeld aber nicht Sprites haben). Alle entweder 8x8 oder 8x16 (wie TMS9918 nur ein global wirkendes Flag). Stets automatisch geladen, aber 8 sichtbare pro Zeile von 64 angemeldeten (somit gleiche maximale Pixelmenge wie 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!). Dazu 4 Sätze von 3 für Bild/Spielfeld Vordergrund, und 4 Sätze von 3 für Sprites, zusammen 25. Verwendet dazu vom Zeichencode unabhänigige Farbattribute, namens Object Attribute Memory (OAM). Aber nur eweils 2x2 Zellen (also 16x16 Pixel!) haben ein 2bit Attribut (dies wegen Speichermangel, ausser das Spielmodul hat einen MMC5 Erweiterungschip drin, der mit mehr RAM auf einzelne Zeichen (8x8 Pixel) genau spezifizieren erlaubt), um 1 der 4 Sätze von 3 Vordergrundfarben auszuwählen. Sprites haben jedes ein eigenes 2bit 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 geringer Chip, 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 Atari 800 auf 7/8 gebremst) und mit mehr Speicher und besserer Graphik. Aber trotzdem billiger als C64, aber auch weniger leistungsfähig als dieser. Ein Chip TED (TExt Display, trotz dass er auch Bitmap kann!). Mit allen 2+1 Zell und 2 Bitmapmodi vom C64 VIC-II, aber ohne dessen Sprites (welche über die Hälfte vom VIC-II seinem Aufwand ausmachen!). Wie dieser ein generischer Videochip (NTSC und PAL selbiger umschaltbarer Chip MOS7360), aber auch nur von Commodore genutzt. Wieder mit Bild aus dem normalen DRAM Hauptspeicher.

Damit sind die Zellmodi "normales" 40x25 Zeichen (den massiven VC-20 22x23 Schwachpunkt korrigiert, wie auch beim C64), und mit Bitmap noch als Dreingabe. Mit 8x8 1bpp bzw 4x8 2bpp Font (und auch dem "Extended" mit 4 Hintergrundfarben). Aus variablem ROM/ModulROM/RAM Satz, von schaltbar 128+invers (wie Atari 800) oder 256 (wie VC-20 und C64) Zeichen. Sowie Bitmapmodi 320x200 1bpp oder 160x200 2bpp (wie C64). Bei 320*1 oder 160*2 von 14.31818/2=7.16MHz Pixeltakt ein 44.7µs Textfeld (wie Atari 800). Damit bis auf die fehlenden Sprites das beste was man kombinieren konnte.

Farben mit Register auswählbar aus 16*8=128 NTSC (wie Atari VCS/2600 und 800, aber mit den 16 VIC/VIC-II Farben als Farbtöne, mit dann je 8 Helligkeitsstufen davon, und wegen Schwarz mit 8 Stufen alle Schwarz real noch 15*8+1=121 Farben). Hat 1 Register für Rand, 4 für Bild Vordergrund und Hintergrund, zusammen 5 (wie C64). Plus dazu Vordergrund direktes Farbattribut pro Zeichen, Bit6..0 auch obige 128 im 1bpp Modus sowie Bit7 blinkend.

Dazu aber kein 4bit bzw gar 8bit separates FarbRAM sondern weitere 1k an normalem 8bit Speicher benutzt. Hat dazu für Zeichencodes und Farbcodes zwei interne 40 Zeichen Buffer. Im Bitmap 1bpp sind es so auch 1 Farben pro Zeichen (wie C64), aber im 2bpp nur noch 2 statt 3 pro Zeichen mangels Platz für 3*(3+4=7)=21bit in 16bit. Hat daher auch "Bad Lines", sogar 2 davon pro Zeichenzeile, in der ersten Zeile pro Zeichen das zweite Byte holen und gleich nutzen und speichern, sowie in jeder Zeile vor einem Zeichen bereits das erste Byte holen und erst nach dem alten vorhandenen letztmals nutzen speichern. Hat 1.79MHz Speicherbandbreite und einen Prozessor der diese voll ausnutzen kann (wie Atari 800), weshalb hier wieder etwa 30% davon verloren gehen. Hat auch einen 2MHz Prozessor unnötig auf 7/8 gebremst, was ihn mit obigen 100-20=70% verbleibend im Vergleich zum C64 seinen 1MHz und 100.5%=95% Verlust, noch etwa 33% schneller sein erlaubt.

Overscan fehlt wie C64, 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 Graphik+Text gemischt Anordnung kann so nachgestellt werden. Hat fein scrollen horizontal und vertikal, mit wie C64 die Reduktion auf 38 Zeichen bzw 24 Zeilen. Wie beim TIA im VCS/2600 und VIC im VC-20 auch Audio im Chip. Zudem einen PIO Port für Tastatur+Joystick, sowie Timer, aber keine Paddles. Solange man keine Sprites oder Paddles braucht ein sehr guter abgerundeter Chip.

Damit waren C16 und C116 gute VC-20 Upgrades im Billigmarkt, vor allem C16 in Mexiko sowie C116 und Plus/4 in Ungarn (letzterer wurde sogar deren offizieller Schulrechner), zumal sie neben mehr Video und Speicher auch noch schnelleren Prozessor hatten (aber auch vom Video mehr ausgebremst). Der Plus/4 hatte zudem als reinen "farbigen PET" Homebusiness Rechner mehr in Basic nutzbares RAM (und alle hatten ein besseres Basic), sowie die namensgebenden 4 in ROM eingebauten Applikationen, eine bessere 4 statt 2 Tasten Cursorsteuerung, ein am Modulport passendes 1551 Floppylaufwerk (welches mit Parallelkabel schneller war als dem C64 seine sehr lahme 1541 Floppy mit gebremstem bitbanging Serialbus), sowie eine Hardware UART für Modems (der Atari 800 verwendet seine UART im POKEY nur für dessen schnelleren SIO Port Serialbus und 810 Floppy). Das wäre ein guter Small/Home Business Rechner gewesen. Nur hat Commodore nach Managementwechsel entgegen dem expliziten Designziel von Billigmarkt und darf nicht mit C64 konkurrenzieren versucht, den Plus/4 als Ersatz vom C64 zu vermarkten, trotz explizit als schwächer designt ohne Sprites, was ihm seinen Spitznamen Minus/60 einbrachte.

Amstrad/Schneider CPC464 (1984)

Ziel war besser als den "schwangeren Taschenrechner" (O-Ton Amstrad Chef!) des ZX Spectrum zu sein, mit echter Tastatur und 80 Zeichen, aber billiger als einen BBC, mit dafür einfachster Hardware. Wie BBC und Spectrum mit Bitmap Bild aus dem normalen DRAM Hauptspeicher. Er verwendet sogar fast selbigen RGB Monitor Stecker (DIN6, Pins wie dieser 1=R 2=G 3=B 4=Sync 5=GND, aber 6=Composite statt 6=5V) (daher auch separaten Stecker und Kabel für Strom vom Monitor zum Rechner), und das selbige Basic wie der Z80 Zweitprozessor zum BBC. Für Timing und Adressen wieder einen MC6845 Chip, aber für den Datenpfad ein Gate Array Semicustomchip, daher auch ziemlich primitiv. Hat für Audio einen AY-3-8912 Soundchip.

Dabei wird im 40 Zeichen Rasterschritt (wie C64) aus dem DRAM Speicher gelesen, mit 2 mal 8bit an Bitmapdaten holen per Doppelzugriff in der selbigen DRAM Page (es braucht hier weder Zeichencodes noch Attributbytes). Was 80 statt 40 Bytes Videodaten erlaubt, und trotzdem die halbe Speicherbandbreite für den Prozessor freilässt, der ohnehin nur etwa 1MHz davon benutzt, nicht gebremst wird (abgesehen von 3-Takt Zugriffe auf 4 und 5oder6-Takt auf 8 ausdehnen, was um 10% kostet, damit etwa vergleichbar zu Spectrum 4MHz auf 3.5MHz bremsen wirkt). Umschaltbar nur 3 Bitmapmodi, ähnlich dem BBC seine, aber keine x256 Zeilen, und die sind keine x200von256, ebenso keine halbgrosse Breite, und kein Teletext Modus:

Auch hier kann die MC6845 nur bis 128 (Zeichen-)Zeilen zählen. Hier werden die 200 Zeilen wieder als 25 (Zeichen-)Zeilen zu je 8 Videozeilen dargestellt (wie BBC und PET/CBM), aber anderst nichtlinear angeordnet 0,8,16,... zu je 8 Videozeilen pro Zeichenzeile dargestellt, mit dem Videozeile in Zeichenzeile Bit als Adresse+(0bis7)*1k genutzt (ähnlich CGA aber in 8*(80x25) statt 2*(80x100), sowie identisch wie Apple II erweitert auf Bitmap).

Farben 2/4/16, aus 27 RGB. Dabei haben alle RGB je 3 Stufen, was sowohl null/halb/voll Helligkeit erlaubt, aber auch mit eines voll intensiv plus halb bei anderen Komponenten Pastellfarben. Eigenartig nicht als 3*2=6bit codiertes R*16+G*4+B*1, sondern als 5bit Zahlen 0..26 mit R*9+G*3+B*1 welche mit einer ROM Tabelle umgerechnet werden. Blinken nur in Software mit der Farbzuordnungtabelle modifizeren. Auf mitgeliefertem RGB oder Grün Monitor (deren Netzteile auch den Rechner versorgen), sowie Fernseher oder Videomonitor (brauchen separates Netzteil mit auch RGB zu Video Umwandler drin). Weil keine Rücksicht auf NTSC oder PAL, mit geraden 4MHz als Prozessortakt.

Keine Textmodi, weil inzwischen genug Speicher um auch bei Bitmap genug Text darzustellen, und damit auch ohne dessen Verbrauch an Bandbreite (bis zu "Bad Lines"), mit statt dessen bis zu 640 Pixel. Braucht wegen stets mindestens 64k DRAM vorhanden auch keine "halbierten" Modi der BBC. Damit ist dies ebenfalls ein total moderner Rechner, mit 16kByte Bild, von den 64k in der Einleitung nur noch Faktor 4 entfernt.

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

(Der Nachfahre 664 (1985) hat identisches Video und auch restlicher Rechner, unterscheidet sich nur durch weglassen des eingebauten Kassettenlaufwerkes zugunsten eines eingebauten Diskettenlaufwerkes. Dessen Nachfahre 6128 (1985, nur 3 Monate spüter) hat ebenfalls identisches Video und Diskettenlaufwerk, unterscheidet sich nur durch Erweiterung des Rechners von 64k auf 128k DRAM, welche als 8*16k verwaltet werden wovon 2*16k Videospeicher sein kö:nnen.)

(Die Nachfahren 464plus und 6128plus (kein CPC mehr im Namen) (1990) addierten 32 von 4096 RGB Farben, und fein scrollen, sowie Sprites.)

Mühlhausen HC 900 (1984) bzw KC 85/2 (1985)

Mit 85 im Namen weil in 1984 noch als Homecomputer HC900 geplant, in 1985 zum Kleincomputer umspezifiziert und neu nummeriert. Die KC 85/2 hat nur ein 4k Monitor ROM. DDR Rechner, keine Customchips, alles reine TTL Logik, dementsprechend ziemlich primitiv.

Nur 1 Bitmapmodus (wie ZX Spectrum), weil auch in der DDR inzwischen ausreichend Bitmap Speicher mit DRAMs billiger ist als TTL Logik). Wie CGA und ZX Spectrum eigener 16k Videospeicher, vom hier nur 16k Hauptspeicher abgetrennt. Wie dieser vom Prozessor adressiert, dessen Adressmodi ausnutzend. Bitmap 320x256 1bpp, mit PAL Monitor Zeilen ausnutzen (wie Microtan 65 und BBC), trotz dass die DDR eigentlich SECAM Fernsehen benutzte! Erlaubt daher sogar 40x30(von32) Zeichen, bei 8x8 Font. Für je 8x4 Pixel Zellen 1+1+3+3bit RGBI Farbattribute, mit 2 Farben als Vordergrund 16 (Bit6..3 XGRB) und Hintergrund 8 (Bit2..0 GRB) sowie dazu blinkend (Bit7) (Anordnung wie ZX Spectrum, ausser X hier nur auf die Vordergrundfarbe wirkend). Die 8x4 sind mehr als ZX Spectrum 8x8 aber weniger als TMS9918 8x1, so immer noch auf "Attribute Clash" ziemlich anfällig. (All das errinnert stark an ZX Spectrum, aber der Hersteller hat später unter dem Namen KC Compakt einen CPC Clone gemacht, nicht einen ZX Spectrum Clone! So einen gab es aber auch in der DDR, namens Spectral.)

Mit 10k Bitmap plus 2.5k Farbattributen (plus 1.25k Zeichencodes), ist er trotz keine Modi Umschalten besser als alle Modi der CGA! Dazu wird die ohnehin langsame 2oder2.5MHz UB800 aber noch im Prozessortakt auf 1.75MHz gebremst. Warum keine 4MHz UA880 drin ist weiss ich auch nicht, vermutlich weil eben als Homecomputer konzipiert. Trotzdem ist dieser Rechner recht aufwendig, und wurde wohl auch deshalb von HC zu KC umbenamst, und dann als Ausbildungsrechner benutzt, weil mit DDR Technologie und DDR Wirtschaft weder hometauglicher Preis noch Fabrikationsmenge drin lagen.

(Der Nachfahre KC 85/3 (1986) hat identisches Video und auch restlicher Rechner, unterscheidet sich nur durch erweitertes 16k ROM mit Basic statt von Kassette ins RAM laden (85/2 hatte nur 4k mit Betriebssystem). (Die davor "fehlende" KC 85/1 war ein total anderer Rechner, von einem anderen Hersteller Robotron, anfangs als Z9001 bezeichnet bevor neu nummeriert, mit spätere Modelle als KC 87 und A5105.))

(Der Nachfahre KC 85/4 (1988) erweiterte von 16kbit auf 64kbit Chips, je 64k statt 16k von DRAM und VRAM, aber weiterhin nur UB880 mit 1.77MHz statt UA880 mit 4MHz, vermutlich weil kompatibel bleiben. Letzteres als 2*(2*16=)3k Videospeicher, mit darin 10+10k statt 10+2.5k an Bild (auch plus 2*1.25k Zeichencodes). Trotz 40*8=320 Pixel wird die Speicheradresse einfach zusammengelegt, aber revers mit Y Koordinate 0..255 an A0..7 und X 0..39(von64) an A8..13, weshalb die Pixel nichtlinear als 40 8bit breite Spalten/Streifen im Speicher liegen. Hat nun 2 Bitmapmodi. Obiges 320x256 1bpp (aus ersten 10k), aber nun mit alle 8x1 Pixel 2 Farben aus 16 (wie TMS9918) (aus zweiten 10k statt aus 2.5k der ersten). Oder umschaltbar auf 320x256 2bpp, in festen 4 Farben schwarz/rot/cyan/weiss (also 2bit für R und G=B). Letzteres aber wegen dem 10+10k zusammengesetzem Videospeicher mit zwei 8*1bpp Bitplanes statt 20k an 4*2bpp Chunks (mit R in den ersten 10k und G=B in den zweiten). Es ist damit wie der Amiga anfällig auf "Ghosting" beim scrollen, wenn das ausgegebene Bild Pixel beinhaltet von denen eine Plane ihre Bits bereits verschoben sind aber die andere noch nicht, was unpassende Bits kombiniert zu zufälligen Farben welche kurz aufflackern, ähnlich wie beim "Snow" Problem. (Beim 1bpp plus Farbspeicher kombinieren sich lediglich neues Muster mit alten Attributen, was weit weniger flackert.) Es kann anderseits egal ob 1 oder 2 Bitplanes wegen 8*1bpp mit dem gleichen Font beschrieben werden, statt bei Chunks mit in 2 Bytes von je 4*2bpp "zerlegtem" Font. Anderseits sind je nach der zu setzenden Farbe ihrer Nummer die Bits zu setzen oder zu löschen, was mühsam ist!)

Apple Macintosh (1984)

Halb ausser Konkurrenz, weil 16bit. Nur 1 Bitmapmodus. Alles reine TTL Logik, keine Customchips, teils noch PALs, dementsprechend sehr primitiv für seine Zeit. Mit Bild aus dem normalen 16bit DRAM Hauptspeicher. Der eigentlich 8MHz taugliche 68000 Prozessor wird etwas gebremst auf eigenartige 7.8336MHz (weil 1/2 von 15.6672MHz Pixel, welche wiederum auch /4.25(!) die 2*1.8432MHz für Drucker+Modem UART/RS232 abgeben). Aber weit schlimmer wird dies, wird wegen dem langsamen 2MHz Speichertakt der 64k Speicherchips während den Videozeilen ausgeben den Prozessor für jeden zweiten Speicherzyklus angehalten (alle Zeilen sind somit halbe "Bad Lines"), zumindest falls er einen RAM Zugriff machen will. Das gilt auch im Mac 512K, weil nur 64k Chips ersetzt durch 256k, sonst identisches Board. Selbiges gilt immer noch im Mac 512Ke, weil nur ROM und Floppy verdoppelt. Ebenso im Mac Plus (1986), weil nur 256k Chips ersetzt durch 256k oder gar 1024k SIMMs sowie SCSI addiert. Erst im Mac SE (1987) gab es ein Board redesign, welches diesen Bremser etwa halbierte!

Hatte im Vergleich zum Apple II 128k statt 4..48k Speicher, daher den Featuresatz abgebaut/vereinfacht, nur noch Bitmap wie bei "High Resolution", keine Zellmodi mehr. Daraus dank 16bit recht hohe (aber für 16bit doch eher niedere!) 512x342 1bpp auf dem eingebautem 9" Monitor, aber nur in Schwarzweiss (und damit selbst unter den 720x348 einer HGC Bitmap). Hat exakt quadratische Pixel. Eigenartigerweise aber keine 512x384, was echtes 4:3 Bild ergäbe. Genauer sind es 15.6672MHz Pixel, 512+192=704 pro Zeile, 22.25kHz Zeilen, 342+28=370 pro Bild, 60.15Hz Bilder. Bild ist somit (512/8)*342=21888kByte, nicht ganz 3 mal die Apple II "High Resolution" 8k. Der Bremser ist somit um 0.5*(512/704)*(342/370)=0.336=33.6%, von 7.8336MHz auf 5.2338MHz. Allerdings muss der Prozessor ab und zu intern extra Zeit arbeiten (z.B. Indexrechnungen), mit seine ansonsten 4-Takt Zugriffe auf 6 oder gar 8 verlängern, was nicht gebremst wird, womit am Schluss beobachtete etwa 6MHz herauskommen. Wegen eingebautem Monitor keine Farben möglich, als einziger der 16bit Rechner hier. Nicht einmal 2bpp Graustufen gibt es. Nur mit Schwarzweiss rastern liegt noch drin. (Daher wurde auch selektierter Text früher in revers Video statt mit Grau hinterlegt angezeigt.)

Hat für Audio einen erstaunlich guten 8bit PCM (Samples) Generator, basierend auf einem PWM DA Wandler. Dieser bekommt seine Daten aus einem 370Bytes Buffer (genauer die gerade adressierten Bytes von einem 370Worte Buffer), welcher mit der 22.25kHz Zeilenfrequenz per DMA ausgegeben wird. Da die 512 Pixel pro Zeile genau in 2^n passen (wie bei 32 oder 64 Zeichen) kann er dazu einfach die vertikale Videoadresse missbrauchen.

Es passen 85x28 Zeichen vom normalen 6x12 1bpp 72dpi Font. Minus GUI Elemente Platzverlust erlaubt das gerade noch etwa 80x25 (falls 80*6=480 von 512 und 25*12=300 von 342 Pixel verbleiben). Eigenartig ist 0=weiss und 1=schwarz, weil Apple glaubt Bildschirme (dunkel und Pixel aufleuchtend) wie Papier (hell und Druckfarbe abdeckend) behandeln zu müssen. (Vielleicht weil sie selbigen 6x12 Font, der typisch für Nadeldrucker ist, auch auf dem ImageWriter benutzten, einem etwa 512 Pixel breiten Nadeldrucker ohne eingebauter Logik, der mit auf dem Mac vorgerenderten Bitmaps beliefert wird, und dazu die selbige Renderengine nutzt, für direktes WYSIWYG.)

Anfangs mit Ziel als Billigrechner von $1000 designt, zu nutzen als eine "Information Appliance" (= Informations Haushaltsger¨t). Eigentlich eine bessere elektronische Schreibmaschine, mit separater Tastatur und dem Rechner plus Floppy im Monitor eingebaut statt im fakulativen Druckwerk. Dies engegen bei vielen aufgerüsteten elektrischen Schreibmaschinen, mit Rechner plus Floppy im Tastatur+Druckwerk, sowie fakultativen Monitor. Wobei Apple schätzte dass 70% aller Benutzer den Drucker kaufen, es wurden aber 90%. (Also das selbige Konzept was Amstrad mit den "Joyce" Rechnern PCW8256 und PCW9512 erfolgreich weit billiger umsetzte, mit stets mitgeliefertem Druckwerk.) Der Mac wurde aber dann nach dem Wechsel von 8bit 6809 zu 16bit 68000 (und dabei Preis auf $1500 angehoben) zu einer billigeren Alternative zur schweineteuren LISA aufgebauscht. (Der Mac Originalprojektleiter ist frustriert vom Kurswechsel bei Apple weggegangen und has seine ursprüngliche Vorstellung als Canon Cat herausgebracht.)

Der Mac wurde dann wegen der dabei entstandenen GUI Software als teuren Komfortrechner vermarktet, mit alleine wegen der Werbekampagne finanzieren den Preis von inzwischen bereits $2000 auf $2500 angehoben! (LISA kostete erstes Modell noch $10000 und zweites $3500 bis $5500.) (Selbiges hatte Apple schon davor mit dem Apple II gemacht, einst als minimalistischen Rechner designt, aber dann wegen Vollgraphik und Farbe als teuren Powerrechner vermarktet, je nach Speicher von $1300 bis $2600, nur der Rechner.) (Die gleichzeitigen Tandy TRS-80 Model 1 und PET 2001 kosteten ab $700, trotz mit Monitor und Kassettenlaufwerk.)

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

Sinclair QL (1984)

Halb ausser Konkurrenz, weil 16bit. Naja, strikte halbes 16bit, mit anstelle einer vollen 68000 wie in den meisten anderen 16bit hier, nur einer 16/8bit 68008. Nachfolger des ZX Spectrum, mit dem Ziel designt billigster Bürorechner zu sein. Wie Spectrum alles in einem ULA (Uncommitted Logic Array) Gate Array Semicustomchip, auch dessen Video (das Interface zu Tastatur/Joysticks RS232 und Laufwerke ist wegen Pinzahl in einer zweiten ULA ausgelagert). Daher halb primitiv. Mit Bild aus dem normalen DRAM Hauptspeicher.

Aber wegen 8bit zur ULA trotz 2*8 64k Speicherchips dieser vermutlich mit massiv "Waitstates" oder "Contention", vergleichbar bei einem Spectrum mit nur 16k (Dokumentation zu den Details ist nicht aufzufinden). Mit einer externen Speichererweiterung (oder nur die bestehenden 2*8 als 8 VRAM und 8 DRAM aufgeteilt), wäre dies dann eher wie beim Spectrum 48k seinen 16k VRAM plus 32k DRAM gewesen, nur hier dann 128k VRAM plus externes DRAM (bzw nur bestehende 64k VRAM plus 64k DRAM). Oder ansgesichts von 2*8 Speicherchips und 2 ROM Chips eine echte 68000 nehmen, was nur mehr Pins an dieser und an der ULA sowie eine zweite 74245 gekostet hätte, aber doppelte Speicherbandbreite bzw halbe "Waitstates" oder "Contention" erlaubt hätte.

Nur 2 Bitmapmodi, 512x256 2bpp und 256x256 4bpp, beide in 32kByte. Also das Volumen von wie wenn, zuerst Spectrum Attribute von 8x8 Zellen in 3/4k auf 8x1 Zellen in 6k verfeinert (wie TMS9918), dann beide 6k Bitmap und 6k Attribute zusammengelegt zu 12k, dann 2bpp daraus macht, dann von 192 auf 256 Zeilen verl&aunl;ngert zu 16k (wie Microtan 65 und BBC), sowie dann Bandbreite verdoppelt zu 512 Pixel in 32k. Mit 512 von 15MHz bzw 256 von 7.5MHz Pixeltakt, was ein sehr schmales 34µs Textfeld ergibt.

Farben bei 512x256 mit 2bpp, ohne Farbattribute oder auch nur Farbregister. Er hat gar keine Attribute mehr, und somit auch keinen "Attribute Clash". Es sind somit aber auch nur noch 4 feste Farben schwarz/rot/grün/weiss (auch hier errinnert die KC 85/4 an einen umschaltbaren Spectrum oder QL, nur mit B=G für cyan statt B=R&G für grün, und 320x256 statt 512x256 Pixel). Das ist damit fast so schwach wie die MC6847 basierten Rechner (aber hat wenigstens schwarz in der Auswahl, und 512x256 statt 128x192 Pixel). Allerdings sind diese 2bpp angeordnet als Pseudobitplanes statt Chunks, mit Bit0..7 als 8*R und Bit8..15 als 8*G, in 2 separaten Bytes wie bei 8bit Bitplanes. Aber diese beiden Bytes sind direkt hintereinander in einem Bildspeicher, statt verteilt in 2 separaten Speicherhälften, und damit wenigstens nicht mehr anfällig auf "Ghosting" beim scrollen. Sie sind aber weiterhin mühsam zu nutzen, oder gar wegen der anderen Sorte Bytes überspringen noch mühsamer.

Farben bei 256x256 mit 4bpp, aber es hat dabei nur 8 RGB statt 16 RGBI, weil 1bpp für blinken abgezweigt wird, nur 3bpp nutzbar bleiben. Damit vergleichbar wie die BBC ihr 4bpp Modus mit 8farbig+blinken (hat dabei aber 256x256 statt 160x256 Pixel). Hier wird nochmals eigenartiger angeordnet, als gemischte(!) Pseudobitplanes+Chunks, mit Bit0..7 4*BR und Bit8..15 4*FG (F=flash=blink). Was alle Nachteile beider Anordnungen verbindet, beide Bytes speziell bearbeiten mühsam, aber doch nicht den selbigen Font nutzen können!

Dabei fehlen einerseits genau dem textorientierten 512x256 Modus das für einen Cursor noch nutzbare blinken. Es hat statt dessen für Text fast nutzlose 2bpp. Besser wären passende 8 Pixel 1bpp für Fontmuster plus 8bit Attribute, welche bei Text eh keinen Clash haben aber dann 16 Zeichenfarben plus blinken erlauben würden. Anderseits hat der spieleorientierte 256x256 Modus der kaum blinken nutzen kann dieses. Es verliert dafür die 16 Farben, ausgerechnet dort wo Attribute Clash meiden die 4bpp nützlich machen würde. Damit kann er weniger darstellen als ein Spectrum, ist erstaunlich schwächer als der erstaunlich gute Vorfahre! Interviews legen nahe, dass der Rechner rein als Businessrechner designt wurde, nicht als Erweiterung/Ersatz vom Spectrum, und dass die 256x256 nicht für Spiele gedacht waren, sondern nur für Graphen. Aber auch dabei ist 16 Farben opfern für blinken sinnlos.

IBM Enhanced Graphics Adapter EGA (1984)

Ganz ausser Konkurrenz, weil mit gigantischen 64bis256kBytes Speicher laufend (und zudem erst noch noch 32bit breitem!). Scheidet damit komplett aus, disqualifiziert. Hier nur als Beispiel, was man damals schon mit viel Masse machen konnte, und weil Urahne der heutigen PC Graphik und damit als Vergleich mit allen anderen wertvoll. Kein Rechner, sondern eine Karte für den IBM PC Bus, und daher eine 8bit(!) Karte, weil auch im 16/8bit 8088 PC/XT nutzbar, nicht nur im 16bit 80286 PC/AT! Daher wie CGA mit separatem VRAM aus DRAMs, asynchron und nicht Prozessor bremsend.

Ebenfalls mit Adressen vom Prozessor, dessen Adressmodi ausnutzend. Aber trotz bis 256k nur 1*64k Adressraum davon nehmend, weil die 64bis256kBytes als 16bis64kWorte von 32bit angeordnet sind (in 4 8bit Bänken von je 1bis4 Paaren 16kx4bit DRAM Chips, erste Bank auf Karte, restliche auf Erweiterung, zweite dort fest, dritte und vierte als Sockel)! Aus fünf Gate Array Semicustomchips gebaut, wie IBM sie auch in Grossrechner Prozessoren verbaut, weshalb IBM solche Chips selber herstellen kann. Verwendet einen umschaltbaren Adressbereich, kann daher mit MDA oder HGC im gleichen Rechner sein, aber trotzdem nicht mit einer CGA, weil mit deren Steuerregister kollidierend.

Zellmodus statt Textmodus, zu 80x25 Zeichen CGA kompatibel. Aber mit neu 8x14 1bpp Font (fast wie MDA und HGC ihre 9x14). Braucht dazu einen separaten EGA Spezialmonitor, analog zu bei MDA und HGC. Würde auch damit hier auscheiden, wenn nicht bereits an der Speichermenge. Aus RAM Satz, von 256 Zeichen (strikte schaltbar so dass Attribut Bit3 für 2 mal 256 geht, mit dann aber nur noch je 8 Farben). Zudem gab es einen 80x43 Zeichen Modus, mit dann dem altem 8x8 CGA Font.

Bitmapmodi einerseits CGA kompatibel 640x200 1bpp und 320x200 2bpp. Aber anderseits eigene 640x200 4bpp und 640x350 1oder4bpp (mit 640x350 1bpp ist es fast HGC, aber inkompatibel). Davon 1oder4*28k nutzend (bzw einen solchen Ausschnitt aus bis zu 4*64k an Bilddaten). Dies mit Bitplanes statt Chunks (wie KC 85/4), was den gleichen Font bei variablen bpp Vorteil gibt.

Hier aber ohne jegliches "Ghosting", weil Pixel der Planes mit einem aufwendigen 8zu(4*8=)32bit Pixelprozessor synchron bewegbar sind, statt eine Plane nach dem anderen. Dazu werden bei von VRAM lesen alle 32bits in 4*8 Latches Register zwischengespeichert, und je nach 2bit Bankauswahl ein Byte von 4 auf den Bus zum Prozessor geliefert (Read Mode 0). Weiterhin kann er aber alle 4 Bytes kombinieren, und ein Bitmap erzeugen wo jede Bitposition 1 ist falls alle 4 Bytes ihre korrespondierenden Pixeln zusammen eine spezifische Farbe in einem Register ergeben (Read Mode 1). Bei zum VRAM schreiben wird es aufwendiger. Ein Byte vom Bus kommend geht je nach einer 4bit Bankmaske in eines oder auch mehrere der Bänke! Löschen besteht aus 0 in alle Bänke schreiben, egal was die Latches drin haben. Zeichnen addieren besteht aus 1er in die Bänke passend zur Farbe senden, also für Farbe 5 (0101) dieses in die Bankmaske schreiben, dann werden nur genau die passenden beiden Bänke verändert! Für einzelne Pixel in einem Byte einfügen müsste eigentlich der Prozessor viermal zuerst lesen dann mit OR einfügen und noch schreiben. Hier werden aber nur die Pixel einmal vom Prozessor geschieben, weil sie im Pixelprozessor für jede Bank mit dessen Latch Inhalt OR eingefügt werden (es hat auch AND zum löschen und XOR zum invertieren, sowie obiges voll ersetzen), und dann gleich in nur die passenden Bänke schreiben (Write Mode 0). Aber je nach Farbe teils setzen teils löschen bleibt extrem mühsam. Es ist aber auch möglich, analog zu obigem beim lesen Bytes nach Bitposition kombinieren, hier eine oder mehrere der Bitposition mit neuen 4bit aus einem Register zu ersetzen. Oder aber die Daten vom Prozessor so zu nutzen (Write Mode 2). Was dann so komfortabel ist wie bei Chunks, aber nur ein Pixel aufs mal, statt in Gruppen. All dies kann auch auch noch bitpositionweise ausmaskiert werden per Register, welche nur kopiert und welche modifiziert (ersetzt oder OR/AND/XOR) werden. Damit sind mehrere mit der selbigen Farbe setzbar. Auch umkopieren um zu scrollen wird so gemacht, mit alle 32bit auf einmal lesen in die Latches, und dann unverändert schreiben, wobei der Pixelprozessor die Daten vom Prozessor ignoriert, nur die Latches Inhalte schreibt (Write Mode 1). (VGA addiert noch obiges bitpositionweise ausmaskieren mit Daten vom Prozessor (Write Mode 3).)

Mit 16 Farben aus 64 RGB Palette, was auch bei CGA kompatibel gilt, dessen 16 festen Farben ersetzend. Ebenso wurde ein Vertical Blank Interrupt (VBI) addiert.

(Erweiterte SuperEGA Clones konnten mit gleichem Speicher auch 640x480 4bpp (4*38k) nachdem Multisync Spezialmonitore erschienen, oder gar mit ausreichend Speicherbandbreite sogar 800x600 4bpp (4*60k). Nur die 4 Bitplanes ihre 4bpp Limite verhinderte noch 320x200 8bpp machen, oder gar mit ausreichend Bandbreite auch 640x400 8bpp mit Masse zu erschlagen!)

(Noch mehr ausser Konkurrenz ist die davon erweiterte Video Graphics Array VGA (1988). Ein einzelnes Gaterarray, mit EGA-erweitertem MC6845 als Teil davon. Zellmodus 80x25 CGA und EGA kompatibel. Aber nun mit (8+1=9)x16 1bpp Font auf 720x400. Zudem gibt es 80x50, mit (8+1=9)x8 Font. Bei Bitmap addierte sie offiziell 640x480 4bpp (mit Bitplanes). Aber auch den Multi-Color Graphics Array MCGA Modus, genau obige 320x200 8bpp (mit Chunks statt Bitplanes), aber kein 640x400 8bpp trotz dass dies noch in die 256k passen würde. Wegen den 640x480 4bpp passt er aber nicht mehr in 64k Adressraum, kann daher nicht mehr mit MDA oder HGC kombiniert werden. Mit MCGA Modus 256 aus 262144 RGB dank dem RAMDAC Chip. In EGA und somit auch CGA Modus werden zuerst die 16 Farben aus 64 Palette bestimmt, dann dessen 6bit auf 8 erweitert, und dann diese auf die RAMDAC losgelassen. Wieder nur mit externem VGA oder Multisync Spezialmonitor, dem ersten Monitor mit dem HD15 VGA Stecker.)

(Wieder gingen erweiterte SuperVGA 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 Bitmapmodi oberhalb 320x200 sind inkompatibel zu einander über die 64k hinaus adresserweitert. Wegen Adressbereich geht bis zu 800x600 4bpp mit einer MDA oder HGC, aber 1024x768 4bpp nicht mehr. Ebenso geht 320x200 8bpp mit diesen, aber je nach Karte ihre Adresserweiterung ist darüber stets machbar oder stets nicht oder nach Auflösung. Erst spätere SVGA addierten 1 Sprite, oft 16x16 2bpp (transparenz+inversion), als Hardware Mauscursor. Später kamen mit 1M Speicher auch 1024x768 oder gar 1152x864 8bpp, sowie die 16/256 Farben aus 16M RGB statt 262144, sowie "Hi-Color" 800x600 3*5=15bpp mit direkten 32k RGB Farben. Noch später kamen "True-Color" 3*8=24bpp direkt. Von diesen 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 bis in den Verkauf sein ging! Stammt eigentlich von Tramiel Technologies Limited, vom ex Commodore Gründer und Manager Jack Tramiel als neue Firma gegründet, nachdem er wegen einem Krach bei Commodore wegging, und dabei auch ihm treue Mitarbeiter mitnahm/abwarb. Hat dann die Atari Konsolen/Homecomputer Abteilung aufgekauft, der zweite beim Atari 800 erwänhte Aufkauf, dabei behielt Warner Brothers die Spielhallenautomaten Abteilung, und ausgeschlachtet für Mitarbeiter und Ausrüstung und Technologie. Hat dabei auch sich in Atari Corp umbenannt, um den etablierten Namen auszunutzen, trotz nicht die bei Warner verbleibene Atari Inc zu sein. Seither gibt es zwei Ataris! Trotz mit Namen Atari damit eigentlich der ideelle Nachfolger vom C64. Bzw weit eher sogar von den TED basierten Rechnern Commodore 16 und 116 und Plus/4, zumal er wie diese keine Sprites hat, und auch keine der VIC/VIC-II/SID Designer daran beteiligt waren (die sind schon davor bei Commodore weggegangen, haben Ensoniq gegründet).

Ist strikte ein C64 (bzw eben C16,C116,Plus/4) mit doppelter Speicherbreite (von deren 8bit auf 16bit), und doppeltem Speichertakt (von deren 2MHz (bzw 1.79MHz) auf 4MHz), das ergibt vierfache Speicherbandbreite. Benutzt daher auch vierfache Menge Videospeicher (von 8k Bitmap auf 32kByte). Mit Bild aus dem normalen DRAM Hauptspeicher. Hatte damals riesigen 512k Speicher, daher den Featuresatz abgebaut/vereinfacht, nur noch Bitmapmodi, keine Zellmodi mehr. Auch ohne separaten Farbspeicher. Auch ohne Zeichencodes, und damit ohne jegliche "Bad Lines". Selbiger 68000 wie der Macintosh, aber wegen reinem RGB Video und kein Quarz mit RS232 teilen mit vollen 8MHz, und dank den neuen 4MHz 256k Speicherchips auch ganz ohne dem Mac seine halben "Bad Lines" (strikte hat er wie CPC 6-Takt Zugriffe auf 8 ausdehnen, was um 10% kostet). Damit war er der schnellste aller damaligen Homecomputer! Basiert auf vier Customchips, "MMU" DRAM Speicher Adressen/Steuersignale Generator, sowie "Shifter" Video Pixel/Farben Ausgabe, und "Glue" Timing/Adressdecoder/Synchronisation, sowie "DMA" Harddisk. Hat für Audio einen YM2149F Soundchip (eine Kopie des AY-3-8910). Umschaltbar 3 Bitmapmodi, aber welche davon benutzbar sind ist abhängig vom Monitortyp (der dies an einem Pin des Videosteckers bekannt gibt):

Mit dem 12" Schwarzweiss Spezialmonitor SM124 ist stets 640x400 1bpp 70Hz in 32k (über 1/3 mehr als beim Macintosh seinen 512x342 in 22k, und vergleichber mit HGC seinen 720x348, auch in 32k). Würde mit nur Spezialmonitor auscheiden, aber hat weiter unten auch einen RGB oder gar normalen Video Monitor. Wie Mac dabei nicht mal 2bpp Graustufen, trotz dass der Shifter eigentlich 2bpp könnte, mit dann 320x400 erzeugen, aber der Monitor kann es nicht, weil mit nur 1bpp Videosignal unterhalb dem MDA seinen 3 Graustufen. Also wieder mit Schwarzweiss rastern (wie Macintosh). Mit umschaltbar normalem 0=schwarz und 1=weiss, oder eigenartigem 0=weiss und 1=schwarz (wie Macintosh), wobei die Mac inspirierte GEM Software zweiteres benutzt. Erlaubt 80x25 Zeichen bei 8x16 1bpp 100dpi Font, oder 80x50 Zeichen mit 8x8. Minus dem GUI Platzverlust erlaubt dies aber nicht mehr 80 Zeichen breite Platz! Die Hardware könnte auch 6x12 Font (wie Macintosh) und so gar 106x33 Zeichen, aber die Systemsoftware hat keinen Font mit solchen drin. Alles in allem ein besserer Macintosh, der als Spitzname Jackintosh genannt wurde. (Es gab sogar ein Modul, mit genau 32k ROM + 64k Sockel, mit in den 32k ST spezifischer Treibersoftware vom Dritthersteller, und die 64k von einem toten Mac zu entnehmen (oder wohl eher von einem lebenden kopiert bevor man ihn verkauft), das den ST in einen besseren und billigeren Mac verwandelte, etwas mehr Prozessor und weit mehr RAM und ordentlich mehr Pixel und Monitorfläche zu unter halbem Preis.)

Mit dem 12" RGB Monitor SC1224 (vergleichbar BCC und CPC ihren) (STM Modelle können auch einen normalen Fernseher benutzen) sind es dann 640x200 2bpp (und das kann auch mit 2bpp Graustufen sein) oder 320x200 4bpp (aber das kann kein 4bpp Grau mehr sein weil nur 8 Stufen an RGB Farbtiefe im "Shifter"). Dies mit 4oder16 Farben aus 512 RGB (ist damit ziemlich genau ein in allem verdoppelter CPC, aber auch verdoppelte CGA Bitmapmodi) (es sind damit auch gleiche 2oder4bpp wie QL, aber wegen Farbregister ohne dessen Limite auf feste 4 Farben bei 2bpp, und ohne blink volle 16 Farben bei 4bpp) (auch hier wäre besser statt 2bpp eher 8 Pixel 1bpp plus 2*4bit Attribute gewesen für 16 Zeichenfarben). Bei 640 von 16MHz Pixel ein 40µs Textfeld (wie C64). Verwendet Pseudobitplanes statt Chunks, also stets selbiges 1bpp von 16 Pixel in einem Wort wie bei Bitplanes (mit den selbigen Font nutzen Vorteilen), aber die resultierenden 2oder4 Worte für die 2oder4bpp liegen direkt hintereinander in 1 Speicher (wie QL 2bpp, nur hier auch bei 4bpp ohne gemischt, und das Wort mit allen MSB der Pixel zuerst) wie bei Chunks (und somit auch resistent gegen "Ghosting", ohne den Aufwand von 4 Bänken VRAM vom EGA Pixelprozessor). Aber je nach der zu setzenden Farbe ihrer Nummer die Bits zu setzen oder zu löschen bleibt mühsam, oder wird gar wegen die anderen Sorten Bytes überspringen mühsamer, ausser man interleaved die 2oder4 Rechenlogiken welche bei Bitplanes in 2oder4 Schlefen kommen würden. Erlaubt 80x25 bzw 40x25 mit 8x8 Font. Wieder minus dem GUI Platzverlust nicht mehr 80 Zeichen breit. Wieder könnte es 6x12, aber die Systemsoftware macht es nicht.

Das Bild kommt stets aus einem 32k Speicherblock (wieder verdoppelter CPC), der vom Speicher/Adressen Chip nur in 256Byte Schritten angeordnet werden kann, und vom System jeweils auf das je nach Speichergrösse variable Ende von diesem gesetzt wird. Keine Sprites, aber kann dies wieder mit den 4bpp kompensieren, wie BBC und CPC. Für einen derart einfachen Rechner trotzdem erstaunlich gut und modern, weil er bereits Auflösung und 4bpp Masse ausnutzt, mit 32k von den 64k in der Einleitung nur noch Faktor 2 entfernt ist. Das einzige was man vermissen kann wäre ein 160x200 8bpp, oder gar 64k Modi mit 640x200 4bpp oder 320x200 8bpp, wenn auch diese den Prozessor 40% der Zeit stoppen würden.

(Der Nachfahre STE (1989) erweiterte auf 4oder16 Farben aus 4096 RGB. Er konnte auch Speicheradresse wortweise und chipintern pixelweise fein scrollen, sowie Videoadresse in Software umschalten für Zeilen in beliebiger nichtlinearer Reihenfolge anzeigen lassen. Er addierte zudem einen Blitter. Ebenso addierte er per DMA ausgegebenes PCM (Samples) Audio. Er kam aber zu spät, weil in 4 Jahren zuviele nicht-STE verbreitet worden waren, weshalb die meisten Spieleprogrammierer die extra Fähigkeiten nicht mehr ausnutzen wollten.)

(Noch mehr ausser Konkurrenz kamen dann im Nachfahren 32bit Atari TT (1990) weitere etwa "vierfache" Modi, Schwarzweiss 1280x960 1bpp sowie RGB 640x480 4bpp und 320x480 8bpp.)

Commodore Amiga (1985)

Halb ausser Konkurrenz, weil 16bit. Stammt eigentlich von der Firma Hi-Toro (später in Amiga umbenamst), von ex Atari Leuten als neue Firmen gegründet. Trotz mit Namen Commodore damit eigentlich der direkte Nachfolger vom Atari 800. Hat Chips vom selbigem Designer wie dieser und VCS/2600, der bei Hi-Toro mitmachte, und dort den Chipsatz mit Namen Lorraine entwickelte. Dies teils mit Finanzierung durch Atari. Nach dem Weggang von Jack Tramiel von Commodore hat dieser Atari aufgekauft, wonach Amiga andere Geldquellen suchte, und dabei von Commodore aufgekaut wurde, welche Atari auszahlten. Weshalb Tramiel Technologies Limited trotz Atari aufkaufen und Atari Corp werden den Lorraine Chipsatz verloren. Wonach sie ihr eigenes bereits skizziertes "Commodore" Design als Atari ST herausbrachten, während Commodore dieses "Atari" Design als Commodore Amiga herausbrachten. Verdrehte Welt!

Ist strikte ein Atari 800 mit doppelter Speicherbreite (von 8bit auf 16bit), und doppeltem Speichertakt (von 1.79MHz auf 3.57MHz), das ergibt auch vierfache Speicherbandbreite. Wieder daher Featuresatz abgebaut/vereinfacht, nur noch Bitmapmodi, keine Zellmodi mehr. Kann aber mehr als vierfachen Videospeicher (von 8k Bitmap auf variable 8..82k). Mit Bild aus dem normalen DRAM Hauptspeicher. Dank schnellen 256k Speicherchips kann er bis 32k ohne Prozessor anhalten, aber mehr als das (3oder4*16k bzw 5oder6*8k Modi) geht auf Kosten vom Prozessor, alle Zeilen werden dabei zu "Bad Lines", wenn auch variabele Menge ((3oder4)-2)*22% bzw ((5oder6)-4)*11% Leistung verloren. Ausser es wird neben "ChipRAM" auch "FastRAM" addiert, also DRAM auf welches Video (und auch Audio und Floppycontroller) nicht per DMA zugreifen kann, womit das ChipRAM zu VRAM wird, wenn auch direkt vom Prozessor adressierbares (wie ZX Spectrum, wenn neben 16k noch 32k auf 48k addiert werden). Wie Atari 800 wieder drei Customchips, "Agnus" (Address GeNerator UnitS) Speicher/Adressen Controller/Generator (statt ANTIC), sowie "Denise" (Display ENabler) Daten/Pixel (statt GTIA), sowie Paula Audio/Floppy/Ports/UART (statt POKEY).

Ebenfalls wegen Nachfolger vom Atari 800 mit 14.31818/2=7.159MHz NTSC und 17.734472/2.5=7.039MHz PAL gebremst auf 7/8 Prozessortakt. Plus dazu 6-Takt Zugriffe auf 8 ausdehnen (wie Atari ST). Damit auch bei 640 von 14.31818MHz bzw 14.187MHz Pixeltakt ein 44.7µs Textfeld. Wird weiterhin in 160er "color clocks" und 320er "half clocks" gerechnet, trotz dass es einen RGB Farbgenerator hat, weil anfangs noch auf NTSC hin designt. Aber selbst mit NTSC wäre er unnötig gebremst, weil PAL auch keine exakten "color clocks" bekommt.

Umschaltbar 2 Bitmapmodi aus 16bit Speicher 640x200 NTSC bzw 640x256 PAL 1..4bpp (16..64k bzw 20.5..82k) oder 320x200 NTSC bzw 320x256 PAL 1..6bpp (8..48k bzw 10.25..61.5k). Dies mit reinen Bitplanes (wie KC 85/4 2bpp und EGA 1..4bpp) statt den Chunks vom Atari 800. Mit wieder gleichem Font bei variablen bpp, aber dadurch eben massiv anfällig auf "Ghosting" (wie die KC 85/4), zumal ohne jegliche Synchronisierung durch einen Pixelprozessor (den die EGA hat, und Hi-Toro in Betracht gezogen hatten aber dann doch wegliessen). Und logischerweise auch mühsam zu benutzen. Erlaubt 80x(25oder30) bzw 40x(25oder30) Zeichen bei 8x8 Font. Minus GUI Platzverlust ebenfalls nicht mehr 80 Zeichen breit Platz. Die Hardware könnte auch 6x12, aber die Systemsoftware nutzt dies nicht aus.

All dieses gibt es auch mit Overscan bis 752x242 NTSC bzw 736x288 PAL und 376x242 NTSC bzw 368x288 PAL (NTSC hat mehr horizontal wegen leicht mehr Prozessortakt), was obiges GUI Problem kompensieren könnte, aber auch nicht dazu genutzt wurde. Kann weiterhin doppelte Zeilenzahl anzeigen mit interlaced. Alles auf einem Fernseher oder Videomonitor oder RGB Monitor. Keine mehr als 200bzw256 Zeilen, und keine Spezialmonitor Option, weil wie der Atari 800 anfangs als Spielkonsole designt und dann zum Homecomputer recyclet. Hat davon auch fein scrollen horiontal und vertikal. Kann dabei mit Anfangsadresse beliebig plus nach jedem Zeilenende ein "Modulo" Register zu den Videoadressen addieren die restlichen Daten am Anfang und Ende von überlangen scrollbaren Videozeilen überspringen, um Bildausschnitte anzuzeigen. Limite ist nur der Speicherplatz.

Statt bloss Displayliste mit einer Copperliste, welche vom Koprozessor ausgeführt wird, sind alle Chipsatz Register ihre Inhalte vorzu mit Konstanten umprogrammierbar, egal ob beliebige Modi oder Scrollen oder Farbsatz modifizieren oder Sprites schieben. Weiterhin kann der Copper bis erreichen einer Position (nicht nur bis Zeile sondern sogar bis genaue Position in Zeile) beim anzeigen warten (falls schon dort vorbei its ohne warten), womit er pro Zeile mehrere Operationen machen kann, aber auch Zeilen überspringen. Ebenso kann er je nach vor/nach einer Position die nächste Operation überspringen. Damit ist er im Gegensatz zum ANTIC deutlich näher zu einem Prozessor, wenn auch Operationen auf Register=Konstante limitiert sind. Auch Copperinterrupt kann er (analog zu Displaylisteninterrupt), einfach durch ein spezielles Register beschreiben (statt durch ein festes Bit pro Zeilen Datenwort). Ebenso nichtlineare Listen durch eine zweite Listenadresse beschreiben und aktivieren, dies sogar mit Unterlisten aufrufbar, weil wieder auf die andere Adresse retourschaltbar.

Damit wird auch grob scrollen ohne umkopieren machbar, durch Zeilen in beliebiger nichtlinearer Reihenfolge anzeigen. Ebenso kann man Bildteile aus dem ganzen Speicher zusammensammeln, gerade auch feste/Menu/Status vs gescrollte/Szene Auschnitte vom Bild. Aber all dies wird auch aufwendiger, weil die Adressen der Zeilen für jede Bitplane einzeln nachgetragen werden müssen! Und die Daten auch für jede Bitplane separat im Speicher liegen. Was auch diese bearbeiten erschwert.

Weit interessanter hat er einen Blitter (der Name kommt von BitBlT, BIT BLock Transfer), einem Bitmap Koprozessor um beliebige lineare oder blockweise Speicherausschnitte zu füllen oder umzukopieren oder modifizieren (inklusive vor allem beliebige rechteckige Ausschnitte im Bild scrollen, mit blockweise=zeilenweise, mit Breite in 16Pixel Segmenten, Höhe in Zeilen). Er kann sogar 3 beliebige Ausschnitte (eines ist üblicherweise der Zielausschnitt, muss aber nicht) verknüpfen.

Dies mit Zielausschnitt "D" jedes Pixel per beliebige 8bit Logiktabelle aus den korrespondierenden Pixeln der Ausschnitte "A" und "B" und "C" (oder statt Ausschnitte mit je 1x16bit festem Bit-/Pixelmuster) verknüpfen. Damit kann er Fontmuster (Ausschnitt "A") einfärben (fest "B") und ins Bild hineinrendern (Ausschnitt "C"), oder bereits farblich fertiges Objekt (Ausschnitt "A") mit einem Transparenzmuster als Schablone (Ausschnitt "B") ins Bild (Ausschnitt "C") hineinrendern. (Der STE Blitter kann nur 2 Auschnitte verknüpfen, und einer davon fest der Zielausschnitt, mit nur 4bit Logiktabelle, sowie statt Quellausschnitt ein im Chip liegendes 16x16 Füllmuster nutzen. Also nichts mit Schablonen. Allerdings kann er den Hintergrund mit AND "ausstanzen" und dann das Objekt mit OR "einsetzen", aber auf Kosten doppelter Laufzeit. EGA fehlt all dies, sie hat nur 4 feste Funktionen, was 2bit entspricht (mit AND und OR darin), und kein Füllmuster. Da sie aber vom Prozessor getrieben wird, kann man dies simulieren mit Planes "ausstanzen" oder "einsetzen" auf Kosten von Laufzeit und Pixelmasken setzen auf Kosten von Prozessorzeit.)

Obiges erst nachdem die "A" und "B" um 0..15 Pixel geschoben wurden ("C" kann nicht geschoben werden, wird daher zumeist für den Hintergrund benutzt, "A" und "B" daher als Objekt und Schablone), und dabei auch mit unverbrauchten Pixeln des vorherigen Wortes kombiniert wurden, mit selber unverbrauchte weitergeben. (STE Blitter kann auch schieben und kombinieren, nur den Quellausschnitt. EGA fehlt das kombinieren, was dessen schieben praktisch wertlos macht. Dies auf dem Prozessor machen ist weit langsamer, was genau den ST vor STE so sehr ausbremste, ausser man nutzt den grossen Speicher für 4 oder 8 Kopien an einmal vor-geshifteten Elementen. Bei rein umkopieren ohne schieben und kombinieren reicht die 8MHz 68000 um 32k Videospeicher in nur 30ms=0.03s(!) zu scrollen.) Dabei kann es bei Breiten welche nicht genau in 16Pixel passen im ersten und letzten Wort jeder Zeile (bzw beide Enden eines Einzelwortes) von "A" auch automatisch Teilworte bitpositionweise ausmaskieren). (STE kann das auch. EGA muss die Software die Maske anfangs/ende jeder Zeile setzen.)

Der Blitter entspricht damit funktionell dem Pixelprozessor der EGA. Nur arbeitet der Pixelprozessor synchron mit 4 Planes je 8bit verändern, während der Blitter asynchron nur 1 Plane aufs mal 16bit verändert, und für jede Plane separat angestossen werden muss. Was dann genau das "Ghosting" beim scrollen maximal verschlechtert. (STE tut wegen Pseudobitplanes je nach Operation allenfalls mit Worte überspringen und mehrfach anstossen arbeiten, muss aber nicht immer.) Weiter kann die EGA ihr separates VRAM nur durch den Pixelprozessor beschrieben und gelesen werden, während das Amiga Bild im DRAM Hauptspeicher direkt beschrieben und gelesen wird. Der Blitter muss daher explizit angeworfen werden, aber arbeitet dann mit eigenem DMA autonom (STE alles auch), während der Pixelprozessor stets auf nur Zugriffe reagiert, aber ohne autonom sein vom Prozessor mit Zugriffen und Adressen getaktet werden muss.

Mit Hilfe des Coppers das Bild aus einzelnen Zeilengruppen zusammensetzen reduziert "Ghosting", auf nur die aktuelle Zeilengruppe statt Ganzbild Auflösung und die geringere Kopierzeit davon. Es reduziert aber auch den Blitter Nutzen auf innerhalb eines Blockes, weshalb um Fonts zu rendern die Blöcke zumindest alle Bildzeilen einer Textzeile beinhalten müssen, was den Nutzen von diesem Ansatz wiederum etwas reduziert. Bzw ist es sinnvoller, einfach mit dem Copper alle Zeilengruppen umordnen, wie es bereits im Atari 800 mit der Displayliste machbar war!

Besser wird der Blitter für Doublebuffering benutzt, mit während ein Bild unverändert angezeigt wird ein separates Bild in einem anderem Speicherausschnitt mit Elemente einkopieren aufbauen. Gefolgt von Ausschnitt umschalteten und nächstes Bild im nun unbenutzten alten Ausschnitt aufbauen, und dann wieder zurück umschalten. Dabei wird sehr viel kopiert, was der Blitter optimal beschleunigt, ohne dass dabei "Ghosting" sichtbar wird (der Mehrfachaufwand für jede Plane bleibt aber bestehen). Damit ist er sogar sehr gut für spritelose grossflächige Spriteeffekte erzeugen nutzbar, um alle Objekte bitgenau geschoben und ausmaskiert ins neue Bild hineinzurendern, was als Compositing bekannt ist. (STE Blitter ist genau dafür da. EGA Pixelprozessor kann ebenso benutzt werden, mit den 4*64k als 2 4*28k Ausschnitte, und dem Resten für die Elemente. Beide müssen sogar mangels jeglicher Sprites so genutzt werden.)

Dazu hat er auch noch Sprites, 8 16xN 2bpp als Pseudobitplanes (2*16bit pro Zeile). Sie sind wie Atari 800 wieder horizontal nur im halbierten Raster (aber hier sind das immerhin 320 statt 160 Pixel), und auch nur auf 320er positionierbar, und auch vertikal bei interlaced nur auf Zeilenpaare. Es hat dazu 8*4 Bytes/Zeile an Spritedaten, weit mehr als die 5*1 Bytes/Zeile der Atari 800. Aber dies sind nicht viel mehr als die 8*3 Bytes/Zeile vom C64! Diese nutzen paarweise die Farben 0+1: 17..19, 2+3: 21..23, 4+5: 25..27, 6+7: 29..31. Sie sind zudem paarweise zusammenlegbar zu 4bpp (wie Yamaha V9938 und V9958 1bpp zu 2/3/4bpp zusammenlegbar), das ergibt dann 2bpp Pseudobitplanes kombiniert zu 2*2bpp gemischten Bitplanes. Diese nutzen alle Farben 17..31. Mit Sprites sind daher nur 4 Bitplanes sinnvoll, mit Farben 0..15, nur 5 Bitplanes falls man die Spritefarben doppelt nutzen will.

In der Höhe sind sie beliebig bis ganzes Bild einstellbar, wie es der Atari 800 stets hatte. Sie sind aber auch auf weniger Zeilen reduzierbar um Speicher zu sparen, oder um sie mehrfach auszunutzen mit ungenutzte Zeilen dazwischen ohne Daten ausgeben "abwarten". Wie Atari 800 und C64 hat es keine Prioritätslogik (wie es TMS9918 oder V9938 und V9958 oder Famicom/NES haben). Aber die Spriteposition + Höhe + Modus werden pro "Ausschnitt" der Spritedaten neu geladen, und Farben können per Copper mit Farbregister beschreiben geändert werden, und so explizit mehrfach verwendet werden. Aber mit 4bpp plus Blitter sind Sprites weniger wichtig geworden, wenn auch sie weniger müsam zu verschieben sind als in den Bitplanes mehrfach wiederholt einfügen und entfernen. Und sie vermeiden jegliches "Ghosting".

Dazu ist noch mit Dual Playfield das Bild/Spielfeld als 2*3bpp nutzbar, mit 8 Farben plus darüber noch 7 Farben (weil 0 = transparent) als ein einzelnes "Monstersprite" von ganzer Bildgrösse mit separatem horizontalen fein scrollen. Zumeist für Parallaxeffekte genutzt, tiefenabhängig scrollend, mit zwischen Teilen der vorderen Ebene bei transparenten Pixeln durchscheinenden Teilen der hinteren Ebene. Aber auch vordere Ebene für einblenden von Statusanzeigen und Steuerelementen. Mit Copper umschaltbar auch für verbessertes Parallax, mit mehreren Ebenen von denen pro Zeilenblock maximal 2 sichtbar sein können. Kann aber auch anstelle von oder zusätzlich zu Sprites benutzt werden, zwar ohne einzelne Bewegbarkeit mehrerer Objekte welche umkopiert werden müssen, aber mit automatischem einfügen ins Hintergrundbild ohne dieses wegspeichern/modifizieren/wiederherstellen, und mit eigenem Farbsatz (wenn auch nur 8+7 Farben trotz 2*3=6bpp, während 4/5/6bpp 16/32/(2*32) erlauben), und ohne Sprite Grössenlimiten der Objekte von nur im horizontalen Rücklauf laden her (was Compositing aber auch kann).

Mit je nach 1bis5bpp dann 2bis32 Farben aus 4096 RGB. Dazu noch mit 6bpp entweder Extra Half Bright (EHB) Modus 2*32 volle+halbe, oder Hold And Modify (HAM) Modus alle 4096 gleichzeitig (aber nur 1/3 Auflösung, ausser den 16 "Startfarben" 00xxxx mit voller Auflösung, weil 01BBBB und 10RRRR und 11GGGG ersetzen dann jeweils einen der RGB Komponenten, eine Serie von allen drei erzeugt erst beliebige Farben). Auflösung plus Overscan plus viele Farben plus grosse Sprites plus Dual Playfield gaben ihm zurecht seinen Ruf als das Graphikwunder schlechthin. Wieder zum Preis von einem massiv komplexen Chipsatz haben. Auch hier kann man nur noch ein 320x200 8bpp vermissen, weil die Bitplanes auf 6bpp limitiert sind (analog zu EGA ihre maximalen 4bpp), wenn auch nur wegen der Registerzahl (während in der EGA schon wegen der Busverdrahtung der 4 Bänke).

(Noch mehr ausser Konkurrenz kamen dann im erweiterten ECS Chipsatz der 16bit Rechner A3000 und A600 (1990) weitere Modi, darunter 2bpp 640480 (trotz ohne Interlace) sowie doppelbreite 1280200 und 1280256 (sowie mit Interlace doppelte Zeilenzahl). Danach kam der erweiterte AGA Chipsatz der 32bit Rechner A4000 und A1200 (1992) mit weiteren Modi, darunter auch grosse 800x600 und 1024x768 ohne Interlace, sowie weniger mit 8bpp bis zu 256 Farben aus 16M RGB, sowie den 8bpp HAM8 Modus mit 262144 davon gleichzeitig (64 "Startfarben" und jeweils 6bit RGB ersetzen).)

Sega Mega Drive (1988) bzw Genesis (1989)

Halb ausser Konkurrenz, weil 16bit. Im Gegensatz zum erst weit nach der Famicom/NES und somit zu spät gekommenen Master System, war dieser ein massiver Erfolg weil weit vor der verspäteten SuperFamicom/SNES gekommen. Hat fast überall mit der Famicom/NES gleichgezogen oder gar einen massiven Vorsprung herausgeholt, und zumeist auch gegen die SNES behalten (ausser in Japan wo die NEC PC Engine sie hinderte, und die SuperFamicom/SNES auch früher herauskam und somit weniger aufzuholen hatte). Dieser Vorteil wurde aber danach wieder komplett verscherzt, weil Sega Japan und Sega USA sich einen internen Machtkampf lieferten, bis zu dabei sich gegenseitig Information vorenthalten. Also kamen die inkompatible 32bit Mega Drive Erweiterung 32X (USA) sowie der 32bit Saturn (Japan) kurz nacheinander heraus, gefolgt von der 32X versagen. Weiter hat Sega Japan die Mega Drive abgeschossen weil "Misserfolg" dort und Konkurrenz zur Saturn, trotz dass Sega USA damit gerade voll am laufen waren und weit mehr Potential hatten als die Saturn. Was alles Sega bei den Spieleherstellern diskreditierte, und so auch der alleine verbleibenden Saturn und allen späteren Systemen jegliche Unterstätzung kostete. Wieder Tod durch Kopfschuss per Management.

Einzelner Customchip VDP (Video Display Processor) Chip, nicht mehr die TMS9918 Familie wie Master System. Dieser ist aber strukturell ähnlich, und zum Master System seinem erweitertem G4 Modus kompatibel, plus einen weiteren neuen Modus G5, nicht mehr aber die normalen TMS9918 Modi 0 bis 3. Hat wegen kompatibel sein neben der 68000 auch dem Master System seinen Z80 (Master System Spielmodule brauchen dazu aber noch den 8bit zu 16bit Slotformat "Power Base" Konverter), der bei Mega Drive Spielen zum Audio Koprozessor wird, zusammen mit einem TI76489 PSG und einem YM2612 FM Soundchip. Benutzt wie Master System separates 64k VRAM aus SRAMs (neben auch 64k sonstiges SRAM, und 8k Z80 SRAM).

Hat nur 2 Zellmodi G4 und G5. Hat keine Bitmapmodi, trotz mit 64k VRAM eigentlich genug Speicherplatz dafür. Im G4 stets niedrige 256x(224oder240), sowie G5 selbige oder bessere 320x(224oder240), aufgeteilt als 32x(28oder30) bzw 40x(28oder30) mal 8x8 Zellen. Die G5 hat wie schon G4 stets 4bpp. Hat keine 512 oder 640 Pixel Modi, trotz mit 64k VRAM genug Speicher, aber wegen Zellmodi vermutlich nicht genug Speicherbandbreite, zumal das VRAM mangels Pins nur 8bit breit ist. Kann weiterhin doppelte Zeilenzahl durch interlaced. Damit fast vergleichbar mit den ST 320x200 4bpp und sogar den Amiga 320x200 bzw 320x256 4bpp, aber noch unterhalb der MCGA 320x200 8bpp, und erst recht unterhalb der ST und Amiga 640x200 bzw 640x256. Etwas gebremst auf 7.67MHz NTSC bzw 7.61MHz PAL, statt den 8MHz vom ST, aber mehr als die 7.159MHz NTSC bzw 7.039MHz PAL vom Amiga, womit die G4 256 Pixel ein sehr schmales 33.5µs bzw G5 320 mittleres 41.9µs Textfeld sind. Hat somit nur vertikales Overscan (wie Atari 800).

Weiterhin fein scrollen horizontal, mit ganzes Bild oder jede Zellenzeile oder jede Videozeile variabel (aus Tabelle im VRAM), und vertikal ganzes Bild oder jedes paar an Zellenspalte (auch Tabelle im VRAM). Dabei können Bildauschnitte von einem 1k bis 4k Bildspeicher verwaltet werden, als 32x32, 32x64, 32x128, 64x32, 64x64 oder 128x32.

Grob scrollen durch umkopieren hat es einen DMA Blockkopierer Koprozessor, wie die Famicom/NES, aber im VDP integriert, nicht im Prozessor. Damit kann er nicht nur SRAM zu VRAM und umgekehrt kopieren, sondern auch VRAM intern. Ist alles andere als ein voller Blitter. Aber mit Byteadressierung vom VRAM und mit 4bpp als Chunks, ergibt das wegen 2 Pixel pro Byte immerhin recht feine Pixelpaar Auflösung, bei 256 oder 320 Pixel pro Zeile scrollen in ausreichendem 128er oder 160er Raster.

(Pixel mit einem Blitter bitweise schieben, wie bei Amiga und STE, wird nur wegen den Bitplanes bzw Pseudobitplanes überhaupt so kritisch. Erst 256 oder 320 Positionen nutzen verlangt hier nach nur 2 vor-geshifteten Kopien. Aber Bitplanes machen diese Situation 4 mal schlimmer, brauchen 4 oder gar 8 Kopien, oder Hardware shiften im Blitter! Womit dieser zu einem Fall wird von aufwendiger Hardware um einen Designfehler auszugleichen.)

Dazu viele und grosse Sprites, von 8x8 bis 32x32, auch 4bpp. Stets automatisch geladen, mit bei 320x(224oder240) 20 sichtbare pro Zeile von 80 angemeldeten, bzw bei 256x(224oder240) 16 sichtbare pro Zeile von 64 angemeldeten (mehr als der Amiga, und sowieso mehr als ST und MCGA ihre gar keinen).

Kann auch Dual Playfield namens Scroll A und Scroll B als "Monstersprites" für Parallax mit hinterer Ebene durchscheinend oder grosse Objekte, siehe die langsamer als die Plattformen scrollende Hintergrundgraphik bei Sonic. Weiterhin kann für Menues oder Statusanzeigen aus Scroll A ein Rand oben oder unten (nicht beide) sowie links oder rechts (auch nicht beide) ausgeschnitten werden, und dort statt dessen Daten eines dritten nicht gescrollbaren Playfields namens Window dargestellt werden.

Farben sind 4 schaltbare Sätze von 16, aber aus nur 512 RGB (gleich wie ST und weniger als Amiga oder gar MCGA). Die 4 Farbsätze können zellenweise und spriteweise einzeln beliebig gewählt werden. Sicher ist, dass Sonic auf Mega Drive massiv farbiger aussieht als auf Master System, was bei beide 4bpp haben praktisch nur von diesem Mehr an Farbauswahl her kommen kann, wobei Master System Hintergrund nur 2 Sätze und Sprites nur einen von diesen haben konnte, und diese nur aus 64 RGB bestanden.

SNK Neo Geo (1990)

Halb ausser Konkurrenz, weil 16bit. Sehr speziell darin, dass die Konsole Neo Geo AES (Advanced Entertainment System) voll kompatibel designt wurde zum Spielautomaten Neo Geo MVS (Multi Video System), und ursprünglich als Mietgerät gedacht war, um zuhause zu trainieren auf identischen Spielen, mitsammt dem Spielstand auf Karten abspeichern welche auch mit dem Automaten austauschbar waren. Mit dementsprechned mit viel Leistung, und daher weit teurer als Konsolen sonst waren. Auch viel Modul Speicherplatz, was die Spiele auch teuer machte. Aber auch mit geringen Stückzahlen, mit daher Entwicklungskosten niedrig gehalten, was sich in einfachen aber effektiven Features auswirkte.

Hat wie Mega Drive neben einer 68000 auch eine Z80 drin, stets nur als Audio Koprozessor benutzt. Benutzt ein separates 64k VRAM aus SRAMs, plus ein "Fast VRAM" von 4k (neben auch 64k sonstiges SRAM, und nur 2k Z80 SRAM). Wird daher von manchen einfach als eine erweiterte (mehr Sprites) und beschleunigte (12.5MHz statt 7.67MHz NTSC bzw 7.61MHz PAL) Mega Drive eingestuft. Hat aber eine total andere Graphik.

Hat keine Zellmodi, aber auch keine Bitmapmodi, und damit gar keinen Bildhintergrund, sondern kann nur Sprites darstellen! Diese auf 320x224 Raster, mit stets 4bpp. Damit ist fein scrollen automatisch durch die Spriteposition gegeben. Ebenso wieviele der 320x224 abgedeckt werden, mit schlicht Sprites in passender Grösse und Anordnung hinstellen. Ich verdächtige wegen 12.5MHz Prozessor, dass es 6.25MHz Pixeltakt sind, was mit 320 Pixel genau volles 51.2µs Feld an Breite erlaubt, also ist auch Overscan automatisch abgedeckt, je nach wo man Sprites hinstellt. Viele Spiele nutzen daher 320-16=304 breit um Speicher zu sparen. Damit sind die 320 20% gröbere Pixel als bei Master System und Mega Drive, aber 20% feinere als bei Famicom/NES und SuperFamicom/SNES.

Die Sprites bestehen aus 16x16 Pixel "Zellen", aus VRAM/ModulROM/ModulRAM genommen, mit horizontal und vertikal spiegelbar. Diese aber vertikal bis zu 32*16=512 hoch gehend, welche als "Stripes" bezeichnet werden. Sprites können zudem mit einem Flag an die Position des vorhergehenden Stripes "angehängt" werden, und so mit nur dem ersten Sprite einer Gruppe positionieren gemeinsam bewegt werden, was auch breitere Sprites sehr komfortabel erlaubt.

Damit kann man auch einen normalen Hintergrund mit Bitmapmodus simulieren, mit 320/16=20 auf 16x224 gesetzte Sprites zusammen gruppieren. Dann kann man einen Font darin rendern wie BBC und CPC sowie ST und Amiga. Womit dies zu Bitmapmodus simulieren wird, und keinen Zellmodus. Dazu muss das Modul aber neben Programm und Font ROMs auch VRAM mitbringen (es hat wie Famicom/NES separate Busse von Prozessor und Video zu den Modulen), ausser der Hintergrund passt in die eingebauten 64k (ein einzelnes Bitmap mit 320x224 4bpp Playfield braucht 35k davon, leicht kleineres 304x212 passt in 32k).

Strikte kann man auch einen Zellmodus simulieren, mit 320/16=20 sowie 224/16=14 Zellen, wovon wegen Overscan etwa 18x12 brauchbar sein werden, mit 20*14=280 bzw 18*12=216 Sprites. Dies ergibt aber mit den 16x16 Zellen nur einen sehr groben Font. Man könnte für nur 8x8 Font oben/links in 16x16 nutzen mit 4 Sätze von 320x224 um 8Pixel versetzt anordnen. Aber dies verbraucht mehr Sprites als anmeldbar sind. Also ist eher Bitmap mit Font rendern angesagt. Damit ist die Neo Geo weit moderner als die Mega Drive.

Insgesammt können 380(!) Sprites angemeldet sein, von denen auf einer Zeile bis zu 96(!) dargestellt werden können. Letzteres soviel, weil Spritebits nicht nur in den 1/5 Zeit des horizontalen Rücklaufes geladen werden können, sondern auch in den 4/5 des eigentlichen Zeichnens weiter geladen werden, gerade auch gemeinsam bewegte Serien von Sprites. Damit entfällt das Problem der Mega Drive, dass wenn kein Dual Playfield benutzt wird die Hälfte der 4/5 an Bandbreite schlicht verschwendet werden. Weiter entfällt, weil Sprites ohne Zellnummern direkt Bitmap sind, die Bandbreite verbrauchen für die Zellmatrix auslesen.

Das sind genug Sprites um bis zu 4(!) Playfields durch zusammensetzen zu simulieren, um mit Parallax tiefenabhängig zu scrollen, was automatisch durch die Spritesammlung vom Hintergrund passend verschieben entsteht! Es braucht daher auch kein Dual Playfield, weil die Sprites beliebig viele (Teil-)Playfields simulieren können. Aber noch besser erlaubt es, mit weniger hohen Sprites auch horizontale Bänder zu machen, von denen lediglich pro Zeile maximal 4 sichtbar sein können, aber im ganzen Bild beliebig viele, solange in die 380 Sprites passend (selbst nur 200 davon belegen reichen für 10 Bänder zu je 20 Sprites!). Was besseren Mehrfachparallax mit mehreren Ebenen in einer Zeile durchscheinend ergibt, als es mit Dual Playfield je simuliert werden könnte, mit pro Zeile nur eine Ebene durchscheinend.

Aber eigentlich ist Parallax nur eine Methode, um bei wenigen zu kleinen Sprites und einem mit nur einem Playfield schwach ausgenutztem Speicher den letzteren besser auszunutzen mit zweitem Playfield. Sobald man gar kein Playfield mehr hat, alle Bandbreite in Sprites stecken tut, kann man auch alle einzelnen Objekte als Sprites einzeln scrollen, und damit nochmals weit besseres tiefenabhängiges scrollen haben als überhaupt mit Parallax geht. Dann kann man auf nur einen einzelnen Hintergrund reduzieren, und verbleibende 380-20=360 Sprites mit 96-20=76 pro Zeile für bewegte Objekte nehmen! Mit sovielen und den Stripes plus anhängen, bekommt man die für Neo Geo Spiele typischen vielen grossen Sprite Objekte, was diese zur besten 2D Konsole aller Zeiten machte.

Erstaunlich gibt es trotz all diesem, und keinen dedizierten Hintergrund, einen dedizierten nicht scrollbaren Vordergrund namens FIX, um Userinterface oder Status oder Headupdisplays oder Heathbars darzustellen. Trotz dass dies mit auch wenigen Sprites problemlos machbar wäre.

Farben mit Register auswählbar aus 65536 RGB. Diese sind sogar volles 18(!)bit RGB, mit aber dem niedrigsten Bit fuer alle gemeinsam für 16bit, also 5R+5G+5B+1LSB. Dazu hat es 4096(!) 16bit Register um 256 Sätze von 15+1 festzulegen. Jede 16x16 "Zelle" der Sprites hat dann eine der 256 Sätze zugeordnet. Wie man sieht ist dies eigentlich ein featuremässig sehr einfacher, aber mengenmässig extrem leistungsfähiges System.

Nintendo SuperFamicom (1990) bzw SuperNES (1991)

Halb ausser Konkurrenz, weil 16bit. Naja, strikte halbes 16bit, eigentlich unterhalb halbes 16bit, mit anstelle einer 16/32bit 68000 (Datenpfad 16bit aber Register 32bit) wie in den meisten anderen 16bit, nur einer 8/16bit 65816 (Datenpfad extern 8bit intern 16bit und Register 16bit), als erweiterte 8bit 6502 der Famicom/NES, (selbige erweiterte wie im Apple IIgs), und ist so am ehesten vergleichbar mit einer EGA in einem 8088 PC/XT.

Ein Customchip Paar PPU (Picture Processing Unit). Benutzt wie Famicom/NES ebenfalls separates VRAM aus SRAMs, aber 64k (wie Mega Drive), aber als je 32k davon an separaten 8bit Zellspeicher VRAM und Fontspeicher FRAM (wie Jupiter ACE) (neben auch 128k sonstiges SRAM). Alles mit 8bit Speichern zur extern 8bit 65816 passend. Aber wegen zwei Chips mit 2*8=16bit Speicherbandbreite, sofern man beide mit Pipelining ausnutzen kann (dabei PPU-1 Zellspeicher auslesend und PPU-2 Fontspeicher auslesend), was zumeist nicht der Fall sein kann (Zellspeicher hat zumeist nur Teils vom Fontspeicher Bedarf).

Hat nur 8 Zellmodi, kein Bitmap, trotz eigentlich genug Speicherplatz. Wegen der relativ niedrigen 5.35MHz Pixeltakt (identisch wie Famicom/NES), wieder mit dessen sehr niedrigen 256x(224oder240), bzw 32x(28oder30) von 8x8 Zellen (ausser die selten genutzten Modi 5 und 6 mit 10.7MHz und 512x(224oder240), bzw 64x(28oder30) 8x8 Zellen). Beides bereits inklusive Overscan, bei 32*8=256 Pixel 47.8µs Textfeld (und damit wieder wenig, nur 5/6 vom Neo Geo seinen 320er mit 6.25MHz, bzw gar 3/4 vom Amiga seinen 320er mit etwas über 7MHz, bzw 7/10 vom Mega Drive seinen etwa 7.6MHz, oder sogar 2/3 vom ST seinem 320er 8MHz). Damit auch nur etwa 24..28 an Textfeld, und mit (24..28)*8=192..224) Pixel die typisch klobigen Famicom/NES Texte auch in den SuperFamicom/SNES Spielen. Kann weiterhin doppelte Zeilenzahl durch interlaced (aber 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, und wie bei diesem die Menge an Spritebits reduziert, was somit auch hier eine schlechte Idee ist.

Dazu noch mehr Anzahl und Grösse an Sprites, 8x8 bis 64x64 4bpp (diese aus 1x1 bis 4x4 mal 8x8 Zellen zusammengesetzt, aus RAM Zeichensatz von 512), sowie horizontal und vertikal spiegelbar. Stets automatisch geladen, mit 32 sichtbare pro Zeile von 128 angemeldeten (nochmals mehr als die Sega Mega Drive, aber weit unter der Neo Geo). Aber das auf nur 34 Zellen davon laden begrenzt (die Mega Drive schafft stets 20 bei vollem 32x32, was hier 80 Zellen entspricht). Neben dem HDMA Verlust schlägt hier noch zu, dass die Mega Drive einen 64k 16bit Speicher in 2/6 Zellmatrix und 4/6 Font aufteilen kann, aber die SuperFamicom/SNES von dem 32k 8bit Fontspeicher limitiert wird.

Dazu ist noch mit 1 bis 4 Layern der Hintergrund zusammengesetzt aus "Monstersprites" von je 32x32 bis 128x128 Zellen zu je 8x8 (und somit 256x256 bis 1024x1024 Pixel). Dieses Quad Playfield ist ebenfalls besser als Dual Playfield um Mehrfachparallax zu haben, mit maximal 3 Ebenen durchscheinend, oder für mehrere grosse Objekte doch unabhängig bewegen. Diese mit pro Layer aus einem 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. Es ist aber weit aufwendiger mit 4 mehrere zu simulieren, als mit den automatischen Sprite basierten horizontalen Bändern der Neo Geo, oder gar alles als Sprites statt Bänder. Wobei allenfalls das HDMA zumindest die Umschalterei machen kann, ebenfalls wie beim Amiga der Copper dessen Dual Playfield.

Hat einfache pseudo-3D Fonttransformationen vom Hintergrund, mit Mode 7. Dieser verwendet stets 1 Layer mit 8bpp, was zusammen mit den 2 separaten 8bit SRAMs als Videospeicher und Fontspeicher in 1FontZugriff=1Byte=1Pixel resultiert. Mode 7 tut dann nur noch die aus Videospeicher Zeichencode und Bild Pixelposition Koordinaten zusammengesetzen Fontspeicher Adressen transformieren, statt innerhalb von einem Zeichen linear durchzugehen. Das erlaubt skalieren, verzerren und rotieren von Zeichen, und mit dieser Transformation ihre Schrittweiten per Software zeilenweise vorzu angepasst auch pseudo-3D Texturen im ansonsten 2D vom Spielfeld. Die Sprites bleiben aber 2D, mit jeglichen 3D Ansichten nur durch separate Zeichen im Font durchgehen, wie bei allen anderen Rechnern hier.

(Selbst der echt-3D Polygongraphik Erweiterungschip Super FX reichte nicht für ordentliche 3D Graphik, weil weit zuwenig Leistung. Ebenso das stärkere aber sauteure Parallelstück dazu, der Virtua Processor Erweiterungschip des Sega Mega Drive. Das weil 3D und 16bit (oder gar 8bit) einfach nicht zusammenpassen. Sogar die 32bit Playstation, welche der Nachfolger der SuperFamicom/SNES hätte werden sollen, bevor Nintendo ausstieg und die N64 brachte und Sony alleine weitermachte, war noch grenzwertiges 3D. Das weil sie zwar bis 640x512 hinauf konnte, und diese Auflösung mit (Textur/Polygon-)Blitter auch trotz keine Sprites problemlos 2D behandeln konnte, aber bei 3D zumeist weiterhin die niedere Famicom/NES und SuperFamicom/SNES Auflösung benutzt wurde mangels GPU Leistung. Erst auf der Playstation 2 taugte 3D wirklich, und sie wurde damit prompt die erfolgreichste Konsole aller Zeiten.)

Farben sind 16 schaltbare Sätze von 4 oder 16, aus 32768 RGB (mehr als alle ausser MCGA und Neo Geo). 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 Sätze 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 Sprites können jedes eines von 8 weiteren Sätzen benutzen.

Vergleich der Systeme

Nachdem die Teilnehmer bekannt sind, geht es nun darum diese Systeme für diverse visuelle Effekte als Medium zu benutzen versuchen, und sie dabei 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 Bitmapmodi

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 VDM-1 und Sol-20, PET/CBM und VC-20, TRS-80, Microtan 65, ZX80 und ZX81, IBM MDA, Jupiter Ace, Galaksija, Famicom/NES. Aber auch manche 16bit Konsolen, Mega Drive und SuperFamicom/SNES.

Die 16bit schlagen hier zu, dank mehr Speicher und Bandbreite. Am besten mit 640x400 der ST als doppelte 640x200 aus 32k. Weniger mit 512x342 der Macintosh als nicht ganz doppelte 512x192 aus 22k. Beide brauchen dazu aber wegen doppelten Zeilen einen Spezialmonitor, beim ST separat wählbar oder beim Macintosh fest eingebaut, und das bei beiden nur in Schwarzweiss. Scheiden auch strikte aus. EGA liefert dazwischen 640x350 (Breite von ST, Höhe von Macintosh), auch mit einem EGA Spezialmonitor, aber dafür in Farbe, in massiv Speicher. Scheidet damit kompett aus. 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 Atari 800), dafür kann er doppelte Zeilen nur mit interlaced statt Spezialmonitor. Der QL scheidet mangels 1bpp haben aus.

Auscheiden tun sicher die Mega Drive und SuperFamicom/SNES, wegen trotz 16bit keine Bitmaps. Aber auch erst recht die Neo Geo, ohne überhaupt einen Bildhintergrund zu haben!

Die Farbauswahl dabei kann sehr verschieden sein. Schlimmstenfalls ist nur ein Schwarzweiss Monitor vorhanden, stets beim Macintosch, sowie beim ST falls 1bpp, sowie beim Apple II (wenn Schwarzweiss weil 280x192 oder 560x280 gewollt ist), sowie bei der Visible Memory. 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 bei TV Dazzler und CGA. Noch besser als das kann auch die Flächenfarbe beliebig sein, beide aus 8 beim BBC, aus 27 beim CPC, aus 64 bei der EGA, 128 beim 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 512 bzw 4096 beim ST(E), weil Farben nur in 2oder4bpp Farbmodi und nur mit Farbmonitor machbar).

1bpp/2Farben Farbzellenmodi

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 oder Rasterzeile abtesten die Farbwahl zeilenweise vorzu ändern. Dies ergibt aber "streifige" Farben. Weit besser ist daher, dies in Hardware zellenweise schalten zu können, jeweils 8 Pixel breite Zellen, passend zu Schriftzeichen und/oder Objekten 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 zumeist 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 C64 und ZX 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 sogar 1+7+7bit für 2 von 128 Farben (plus blinken) mit 8x8 Zellen im TED.

Dabei wird aber für die Zellenfarben festlegen mehr Speicher benutzt (plus 1/8 oder 1/4 oder gar 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, wie im C64. Was auch ein Grund ist nur 8x8 Zellen zu benutzen, weil das die Ausblockzeit auf nur jede achte Zeile reduzieren kann, als "Bad Lines" bezeichnet.

Oder man akzeptiert mehr Prozessor ausblocken. Zumindest der ZX Spectrum nutzt obiges einmalige Laden nicht aus, holt bei allen 8 Zeilen wiederholt. Weshalb er dann separates VRAM benutzt, also nur bei Videozugriffen den Prozessor bremst, und dann auch nicht zu 100% in der Zeile. Selbiges die KC 85 Serie, auch mit separatem VRAM. Die 8x4 von 85/2 und 85/3 sind durch dessen 16k limitiert, die 8x1 vom 85/4 werden dann erlaubt durch (2*)2*16=64k.

Oder man benutzt weit schnelleren und teuren Speicher, wie TMS9918 seinen 4*0.895=5.58MHz statt 2*0.895=1.79MHz. Was dann dessen 8x1 Zellen ohne den Prozessor ausblocken erlaubt, selbst bei Videozugriffen ihn nur etwas bremst bis zum nächsten freien Zugriff, bei jedem vierten Takt. Dies ist vermutlich auch beim TED der Fall.

Abseits liegt der Oric, mit 6x1 Farbzellen ohne den Prozessor ausblocken, aber zum Preis, dass Farben umschalten eine Zelle als Attributschaltbyte mit Leerplatz kostet.

(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 BBC!) bzw 512x192 1bpp liefern, wobei dieses dann nur noch mit im ganzem Bild 2 Farben wie oben gehen würde (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 verteilen (zu je 640x128).)

2bpp/4Farben Bitmapmodi

Auch so bleibt eine Zelle auf 1bpp und 2 Farben beschränkt, mit den Problemen von "Attribute Clash" bzw "Color Spill", 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 beliebig 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. Darunter TV Dazzler (kann nur 1bpp und 4bpp, aber kein 2bpp), VCS/2600, alle TMS9918, ZX Spectrum, Oric, KC 85/2 und 85/3 (aber nicht 85/4). (Davon können sich alle TMS9918 und ZX Spectrum sowie KC 85/2 und 85/3 aber halbwegs 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) 640x200 bzw 640x256 kann (plus noch Overscan) sowie die EGA die ebenfalls bei 2bpp (und 4pp) 640x350 kann. Nach diesen verbleibt nur noch mit 640x200 der ST mit Farbmonitor, mit halbierter Zeilenzahl, sowie mit 512x256 der QL. Der Macintosh fällt weg, ebenso der 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. 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 ebenso kein 512x192 1bpp).

Die Farbauswahl hier kann wieder sehr verschieden sein. Schlimmstenfalls gibt es nur einen festen 4er Satz, wie QL (Sw+Rt+Gn+Ws), oder 2 feste 4er Sätze, wie MC6847 (Gn+Gl+Bl+Rt oder Ws+Cy+Mg+Or). Etwas besser kann eine Farbe gewählt werden, wie 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 27 beim CPC, 64 bei der EGA, 128 beim Atari 800, 512 (bzw 4096) beim ST (bzw STE), und 4096 beim Amiga.

2bpp/4Farben Farbzellenmodi

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 NTSC Farbmonitor offeriert bei seinen 280x192 1bpp dann pseudo-2bpp 140x192 in nur 2 festen 4er Sätze (Sw+Gn+Vt+Ws oder Sw+Bl+Or+Ws), aber kann diese für jede 7x1 Zelle wählen (mit dem achten Farbattributbit). (Atari 800 "F" und MC6847 "R" mit NTSC Farbmonitor können bei ihren 320x192 bzw 256x192 1bpp selbige pseudo-2bpp 160x192 bzw 128x192, ohne Farbattributbit nur Sw+Bl+Or+Ws.)

Die C64 und TED dagegen machen auf volle Farbzellen, wegen 160x200 nun in 4x8 Grösse, aber mit 4+4+4=12bit 3 (C64) bzw 7+7=14bit 2 (TED) "Stifte", welche 3 Farben aus 16 (C64) bzw 2 aus 128 (TED) wählbar (sowie 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 Bitmapmodi

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. Darunter alle MC6847, die CGA (wäre 160x200 wie CPC), VC-20 und C64 und TED, KC 85/4 (wäre 160x256 wie BBC). (Letztere beide können sich aber wieder mit ihren Farbzellen halbwegs retten.) (Die CGA kann mit "Tweak Mode" auf zumindest recht ordentliche 160x100 kommen. Aber das wurde wegen unbekannt selten benutzt.)

Die 16bit ziehen teilweise genauso mit. Ein paar von ihnen haben bei 2bpp immer nicht ihre ganze Bandbreite vom Speicher ausgenutzt, und gehen daher für 4bpp mit gleicher Auflösung auf doppeltem Speicherplatz weiter. Wieder Amiga 640x200 bzw 640x256 (plus noch Overscan) sowie 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 ST macht trotz 16bit auf halbiert, mit noch 320x200. Der QL halbiert auch, mit noch 256x256. Der Amiga kann neben 640x200 bzw 640x256 durchziehen auch 320x200 bzw 320x256 (plus Overscan) ohne den Prozessor zu bremsen.

Strikte kann man den FIX Vordergrund der Neo Geo als einen 4bpp Bitmapmodus anschauen, wenn man ignoriert dass er wie Sprites transparent sein kann, um alle anderen Sprites anzuzeigen, inklusive dem Hintergrund aus solchen.

Die Farbauswahl geht jetzt immer auf 16 Farben, die Frage ist nur noch welche. Am schlechtesten ist es bei BBC und QL, die nur 8 Farben kennen und das vierte bpp nur für (reversfarbig) blinken benutzen k%ouml;nnen. Etwas besser bei Atari 800 mit GTIA Modi, der entweder 16 Helligkeitsstufen eines Farbtones oder 16 Farbtöne in einer Helligkeitsstufe oder nur 9 Farben aus 128 bietet. Apple IIe "Dual High Resolution" mit NTSC Farbmonitor offeriert mit seinen pseudo-4bpp 16 NTSC Farben. Vergleichbare 16 hat es beim TMS9918 "Multicolor". TV Dazzler hat 16 RGBI Farben. Sogar 16 aus 27 der CPC, 16 aus 64 die IBM EGA, 16 aus 512 bzw 4096 beim ST(E) und Amiga. Wenn man das Neo Geo FIX hier hinzunimmt, ist es sogar mit 16x16 Farbzellen, jede mit einer von 256 Sätze von 16 Farben aus 65556.

Mehr als 4bpp/16Farben Bitmapmodi

Mehr als 4bpp liefert der Amiga mit bis 6bpp. Dazu muss aber auch er nun 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), wobei 0..15 normal 16 aus 4096 Farben setzen, und dann 16..31,32..47,48..63 jeweils eine der drei BRG Komponenten direkt mit 4bit modifizieren während den beiden anderen beibehalten. All diese auf kosten von nur noch 320x200 bzw 320x256 falls 0..15 benutzt bzw 106x200 bzw 106x256 bei vollen 4096 Farben. All die enorm guten fast photorealistischen Bilder welche dem Amiga seinen Ruf aufbauten wurden in diesem Modus erzeugt. Auch hier wird der Prozessor trotz halbierter Auflösung etwas gebremst, zu 5bpp 11% bzw 6bpp 22%.

Sogar mehr als 6bpp liefern die V9938 und V9958 mit "G7" 256x192 8bpp, als einzige mit 8bit. Der Atari ST könnte von seinem Speicher/Timing her 160x200 8bpp liefern, es scheitert nur an den internen Leitungen im maximal 4bpp breiten "Shifter" Chip. Er könnte mit Amiga-artiger Prozessorbremse auf 40% es sogar bei 320x200. Der Amiga könnte mit seinem Timing auch auf 320x200 bzw 320x256 liefern, mit wie bei 640x200 bzw 640x256 4bpp den Prozessor 40% ausbremsend, es scheitert an den maximal 6 Bitplane Adressregistern. Die 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 VGA lieferte dies dann, wenn auch nur mit MCGA Modus bei 320x200, so nur 1/4 ihres 256k Speichers nutzend, trotz ausreichend Speicherbandbreite für 640x400 haben, wie es die SVGA 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, ausser dort wo er auf eine eingebautes ROM limitiert ist. Problematisch dabei sind die fest gegebene Zellengrösse/Zellengrenzen sowie die limitierte Anzahl Zellensorten im Font, oder gar limitierter Zellsatz.

1bpp/2Farben Pixelzellenmodi

Analog zu obigen 1bpp/2Farben Bitmapmodi 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. Darunter TV Dazzler, VCS/2600, BBC, ZX Spectrum, CPC, alle KCs, sowie alle 16bit ausser der EGA und teils Konsolen. Aber ebenfalls die Neo Geo, ohne überhaupt einen Bildhintergrund zu haben!

Ohne jegliche Zellmodi scheiden hier ebenfalls alle mit festen ROM Textmodi statt ladbarem RAM Zellen aus. Darunter VDM-1 und Sol-20, Apple II, PET und CBM, TRS-80, Microtan 65, alle MC6847, ZX80 und ZX81, IBM MDA und CGA, Galaksija.

Zudem scheiden die Famicom/NES aus, weil Zellmodi aber nur 2bpp. Das Master System mit G4 verwendet gar 4bpp. (Es hat aber noch die TMS9918 "Text" und "Graphic 1", aber diese wurden selten genutzt, und daher auch in der Mega Drive weggelassen.)

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

Anderseits haben die Mega Drive und SuperFamicom/SNES zwar sogar nur Zellmodi, aber keine 1bpp.

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

1bpp/2Farben Farb+Pixelzellenmodi

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:

Wieder abseits liegt der Oric, mit 6x8 Farbzellen ohne den Prozessor ausblocken, aber zum Preis von Farben umschalten kostet eine Zelle als Attributschalt Leerzeichen, und reduziert den Font auf 96.

2bpp/4Farben Pixelzellenmodi

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. Dies ist die Welt der dritten Generation Konsolen und mit ihnen mithaltenden Homecomputern. Das vorhandene streut wieder massiv:

2bpp/4Farben Farb+Pixelzellenmodi

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

Die 16bit steigen hier fast alle aus, weil genug Speicher, und damit besser die Text bzw Zellen Logik (und Zellnummern Bandbreitenbedarf) einsparen, und zudem weit flexiblere Graphik bekommen. Wenn auch auf Kosten von Prozessorlast beim scrollen, was 16bit aber locker wegstecken kann.

Die SuperFamicom/SNES dreht dagegen hier erst auf. Reine Zellgraphik, aber neben 2bpp sogar 4bpp und 8bpp, und das bei 4bpp mit 8 Sätzen von 15, wieder in 32x30 (PAL) oder in nur 32x28 (NTSC). Dazu sogar noch massive 4 Layer, mit bei 2bpp jedes Layer eigene 8 Sätze von 3 (aber 4bpp alle Layer die selbigen 8*15).

Auch das Mega Drive dreht noch mehr auf, mit dessen G5 Modus, selbige 4bpp, aber nun volle 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 daher die letzte Neuentwicklung vor Bitmap. Davor gab es den Textmodus, mit etwas weniger Logik, und zwei separaten Speichern um Bandbreite zu verteilen, mit dem Font nur in billigem ROM. Dies ist technisch uralt. Jedes Texterminal (ausser solchen mit Softfonts) basiert ausschliesslich auf diesem.

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 bzw der Menge Blockgraphik anschauen. Zumal Farben hier zumeist auch nicht relevant sind. Zudem ist alles 1bpp:

Sprites

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, sowie 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 wenn 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. Dies erst recht wenn sie mit eigenen Farben daherkommen. Das sind die Sprites. Diese sind stets kleine Bitmaps wie in den Zellen verwendet, 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. Bei 8bit waren dies nur wenige neuere, bei 16bit die meisten (alle ausser Macintosh und Atari ST). Diese streuen erst recht massiv:

Ranglisten nach Kategorien

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, diese zuerst mit und dann 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 gerade noch an den Commodore 64. Hat 320 Pixel statt bloss 256. Hat Zell und Bitmapmodi, beide in 1bpp und 2bpp (wenn auch bei letzterem nur 160 Pixel). Vollen 256er Font in den Textmodi. All das zusammen mit dem 8+4=12bit Datenbus von RAM+FarbRAM, somit 16 Farben pro Zeichen bzw pro 8x8 Pixel Zelle, plus noch mit "Extended" 4 Hintergrundfarben von 2bpp (aber auf Kosten von 64er Font). Bei Bitmap 1bpp 2von2 bzw 2bpp 3von4 zellenweise und bei Text immer noch 1bpp 1von2 bzw 2bpp 1von4 zellenweise. Dazu die grösste Menge Spritebits pro Zeile, 8*24*1bpp=8*12*2bpp=196bit. Und noch jede Menge flexiblen Komfort wie fein scrollen und lesbarer Zeilennummer und Rasterinterrupt. Dazu ungebremsten Takt vom Prozessor (wenn auch 5% davon an die "Bad Lines" verloren gehen). Das einzige was einem hier wirklich fehlt ist Overscan. Nett wäre noch die 16 Farben aus mehr auswählen können (wie Atari 800 oder TED). Verschmerzen kann man dass intensivere Effekte nach vorzu in Software umkonfigurieren verlangen. Die Designer vom VIC-II haben ihre Erfahrungen von PET/CBM und VC-20/VIC sowie ihre "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 aufzeigen drin!

Platz 2 geht knapp dahinter an die Nintendo Famicom. Abstriche gibt es für dessen 256 Pixel, trotz dass diese inklusive Overscan sind, was nur etwa 24..28 Zeichen breit an Text erlaubt, (was somit etwa (24..28)*8=192..224 Pixel entspricht). Ebenso geringeren Abstich für die die fehlenden Bitmaps. Und weiteren geringeren für nur ModulROM Font, ausser ModulRAM wird addiert. Das vernichtet jede Chance auf den Platz 1. Aber hat einen 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 gar 512 (bzw eher (384..448) Pixel an Text) mit 1bpp entspricht! Die 8x8 2bpp brauchen 2 Fontbytes pro Zeichencodebyte, was 2/3 statt 1/2 Speicherbandbreite an Fontdaten erlaubt. Damit gibt es trotz gebremsten Speichertiming, schlimmer als beim Atari 800 und TMS9918 und MC6847, zwar nur 3/4 1bpp Pixel (was bei Text kostet), aber 3/2 2bpp Pixel (was bei Graphik addiert). Was graphisch genial ist und der Famicom/NES ihren zweiten Platz sichert. Danach werden selbst die vom Speicherplatz her auf 16x16 limitierten Farbzellen noch akzeptabel, zumal diese gleich zellenweise 3 Farben von 4 Sätzen erlauben. Dazu kommen die zweitmeisten Spritebits pro Zeile, 8*8*2bpp=128bit. Man merkt wie die Erfahrungen aus Spielhallen Automaten herstellen (teils Nintendo Automaten beinhalten von NTSC/PAL auf RGB modifizierte Famicoms/NES!). Aber ebenso merkt man die Limiten von einer Spielkonsole zu einen Homecomputer ausbauen wollen, wie nur etwa 24..28 Zeichen breit nutzbar für Text. Er kann somit den C64 nicht überholen, weil zwar das 256er Spielfeld mehr als dessen 2bpp 160 Pixel hat, aber gegen 1bpp 320 nicht ankommt, sowie ebenso die 256er Sprites nicht gegen dessen 160oder320, zumal diese vom Spielfeld unabhängig und einzeln wählbar sind. Was Tastatur und DiskSystem wenig attraktiv machte, weshalb die 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 schnelles VRAM fehlt, trotz hier SRAMs. Ebenfalls nervt etwas, dass man keine Prozessor Adressenmodi benutzen kann. Zudem fehlen Paddles, es gibt nur Joystick, bzw eben neu hier eingeführt das Joypad.

(Obiges gilt aber nur voll für die volle Famicom. Die umgestaltete und dabei reduzierte NES ohne Tastatur und DiskSystem verliert massiv, weil gar kein Homecomputer mehr, nur noch reine Abspielkonsole. Damit ist sie auch nicht mehr selber programmierbar, braucht externe Programmerstellung und Modulproduktion. Darin ist sie kein Deut besser als der Atari VCS/2600 war! Dazu kommt erst noch dass zwecks Spielezensur mit einem Lockout Chip erweitert wurde, was eigene Module herstellen verhindert, nur das erlaubt wofür Nintendo einem Module herstellen willig ist, mit vielen Limiten. Damit ist nur noch Konsumieren möglich, was die Diktatur erlaubt. 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 gar 2000, für 62mio NES gab es trotz 20 Jahren aber nur um 1400. Was alles der reduzierten NES eine Disqualifikation wegen Foul einbringt!)

Platz 3 geht überraschend an den TMS9918. Auch nur 256 Pixel, aber das wenigstens im Bild drin, mit volle 32 Zeichen nutzbar. Kann 256er Font, sogar mit Farben auf 1x8 ("Graphic 2") oder aber 8x8 an 32 8er Gruppen Zeichen gebunden ("Graphic 1"). Dazu noch "Text", 256er Font, mit nur 6x8 aber dafür 40 Zeichen. Dazu noch die drittmeisten Spritebits pro Zeile, 4*8oder16*1bpp=32oder64bit. Und keine Prozessorbremse, ausser bei Zugriff aufs VRAM (und dabei weniger als die Famicom/NES). Abstriche gibt es für das komplette fehlen jeglicher 2bpp Farbigkeit, und damit kann er nur den dritten Platz erreichen. Auch die fehlenden Overscan und fein scrollen stören etwas. Nervend ist aber die Programmierung, wegen keine Prozessor Adressenmodi benutzen können, was aber nur Aufwand und Geschwindigkeitsverlust ist, nicht einem graphisch limitiert (und auch die Famicom/NES trifft). Ebenso fehlen praktisch allen TMS9918 Rechnern die Paddles. (Bonuspunkte gibt es für den genauen Gegensatz zur Famicom/NES, dass der Chip in vielen verschiedenen Rechnern erhältlich ist. Mit Tastaturen, sowie Modulen und Kassetten und Flopys, und somit frei programmierbar ist.)

(Die V9938 und V9958 erweitern einiges davon. Einerseits ihre massiven G4..G7 Bitmapmodi ohne Zellnummern, bis zu 512 Pixel mit 2oder4bpp, oder bis zu 4oder8bpp bei 256 Pixel. Anderseits ihren T2 Zellmodus mit 80x24 2bpp. Dazu 8 statt 4 von 32 Sprites. Vertikal etwas Overscan (212 statt 192 Zeilen). Fein scrollen (V9938 aber nur vertikal, erst V9958 kann auch horizontal). Das reicht um bei Text oder Spielfeld die Famicom/NES und gar den C64 zu überholen. Aber weiterhin eher geringere Menge an Spritebits, nur 8*8oder16*1bpp=64oder128bit, wie NES und 2/3 C64, verhindert bestes 8bit zu werden, plaziert sie zwischen C64 und NES. Sie waren zudem mit V9938 in 1985 bzw V9958 sogar erst in 1988 zu spät um noch etwas zu erreichen, haben nur noch MSX mit MSX 2 bzw MSX 2+ etwas verlängert.)

(Die Sega SG-1000 Mark III bzw Master System erweitern mit deren G4 Zellmodus auf 4bpp, und damit besser als die Nintendo Famicom/NES. Dies ist sogar eine konsequente 4bpp Logik, ohne pixel-halbierte Fonts, volle 8x8 4bpp. Das braucht 4 Bytes Font pro Zeichencodebyte, was sogar 4/5 statt 1/2 Speicherbandbreite an Fontdaten erlaubt. Dies zudem ohne die niedrige Pixelrate der Famicom/NES, 256 mit vollen 32 Zeichen Text. Und das erst noch ohne auf 16x16 limitierte Farbzellen, weil gar keine solche mehr, mit voll 4bpp Farben im Font! Aber damit auch Farben fest im Zeichen drin, keine Zellmuster mit Farben kombinierbar, was aber mit 448 Zeichen im Font weniger schlimm ist. Ebenso mehr Spritebits, 8*8*4bpp=256bit, doppelte V9938/V9958 und NES, sowie 4/3 C64. Dies aber nur wenn man die 4bpp ausnutzen kann, mit 2bpp/3Farben Sprites entsprechen sie nur noch 8*8*2bpp=128bpp der V9938/V9958 und NES sowie 2/3 C64. Also zieht sie insgesammt etwa mit der C64 gleich. Ohne Overscan. Aber in beide Richtungen fein scrollen. Auch hier merkt man ihre Erfahrungen aus Spielhallen Automaten herstellen. Sie waren aber mit 1985 bzw 1986 auch zu spät, konnten gegen die Dominanz der seit 1983 bzw 1985 loslegenden Famicom/NES nur noch wenig anrichten. Hatten wie letztere auch keine Tastatur oder Disk (das war der SC-3000 vorbehalten), und sind darin wieder auf Atari VCS/2600 Niveau abgeschlagen. Aber zumindest keinen Lockout Chip und Spielezensur, und somit keine Disqualifikation.)

Platz 4 geht enttäuschend an den Atari 800. Er hat zwar theoretisch 320 Pixel, aber dieses nur in Modi "2" und "3" und "F" mit deren "1.5" Farben Logik benutzbar. Sonst hat dieser nur 160 Pixel (mit Overscan bis 192) breit (und damit unter der Famicom/NES ihre 192..224 (bzw 256), sowie beim VC-20 seinem 176). Es ist auch so dokumentiert als 160 "color clocks", die 320 werden offiziell als "half clocks" bezeichnet. Hat ordentlichen 2bpp Support in 160er Text und Bitmapmodi. Aber es gibt kein zellenweises Farben setzen, mit nur 4 oder 5 Farben auf dem ganzen Bildschirm, ausser man geht per Display List Interrupt und Software umkonfigurieren, was aber wegen Timing nur zeilenweise "streifig" wirken kann. Was alles ihn 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 alles erst für seinen 4 Hintergundfarben "Extended" Textmodus opfert). Man merkt hier, dass Atari eine Spielhallenfirma ist und erstmals einen Homecomputer aus einer halbfertigen erweiterten Spielkonsole machte, und das mit der Auflösung nicht im Griff hat, während Commodore als Bürofirma beim C64 zum zweiten mal einen Spielerechner machte, und vom ersten gelernt hat. Dazu kommen noch die zweitgeringsten Spritebits pro Zeile, nur 5*8*1bpp=40bit. Was auch nicht bei korrigieren von obigen Limiten helfen kann. Die Sprites dazu noch ebenfalls mit nur 160er Raster, gerade diese nicht detailiert, weil nur 8 Pixel breit pro Sprite. Das ist besonders schwach bei einer Spielefirma, und dazu dem Erfinder der Sprites (Pong Geräte waren praktisch nur Sprites mit festem Hintergrund). Dies wurde besonders kritisch als aus dem Atari 800 die 5200 und XEGS Konsolen abgeleitet wurden. Es ist aber unvermeidbar wegen des gebremsten 7/8 Prozessortaktes (wenn auch von 2MHz aus), und so nur 114 von den 128 Speicherzyklen/Zeile vom C64, mit davon wegen dem Overscan bis 2*48=96 statt bis 2*40=80 für den Hintergrund reserviert, nur 114-96=18 statt 128-80=48 im Rücklauf (wo Spritebits gelesen werden). Nach Abzug vom Speicherrefresh (C64 immer 5, Atari 800 bis 9), sowie bis zu 3 weitere für die Displayliste reserviert (maximal 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 Speicherbandbreite bzw Prozessorbremse) mit 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 ohnehin nur 1 Modus, und Spiele mit mehreren Modi nutzen den Prozessor zumeist nur im vertikalen Rücklauf, haben ihn im Bild frei um Modi zu wechseln. Also wurden hier Hardwareaufwand und Speicherzyklen blockieren an den falschen Ort gesetzt. 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, weit abgeschlagen. Das weil mit viel komplexem Aufwand am Ziel effektiver Graphikleistung vorbeigeschossen, ein klassicher Fall von Second System Syndrom! Die in der Einführung erwähnte Atari 800 vs Commodore 64 Debatte wird somit eindeutig von letzterem gewonnen, weil trotz zweites System nicht derart überbordet.

Platz 5 und damit letzter geht noch wie zu erwarten an den Atari VCS/2600. Der erste Customchip mit Sprites, bereits in 1977, was absolut gut für damals war. Aber ausser zum spielen praktisch unbrauchbar, und selbst zum spielen extrem primitiv. Der als erweiterte Pong Konsole mit 2*20=40 Pixel/Zeile extrem klotzige 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 auch nur 2*8 plus 3*1 Pixel = 2*8*1bpp+3*1*1bpp=19bit. Ausser man programmiert sehr aufwendige "Racing the Beam" Techniken, womit Pong Spiele genau ihre 3x5 Font Spielstandsanzeigen hinbekommen. Dazu kommt noch der grosse Programmaufwand, um zeilenweise alle Spielfeld und Sprites oder gar Farben in Software umkonfigurieren zu müssen, was garantiert dass mit den maximal 4k ROM welche adressiert werden können nur wenig Spiellogik verarbeitet werden kann.

(Der VCS/2600 hielt wegen billig und früh erscheinen und somit etabliert sein, die weit bessere (aber dazu 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 direkt von den Telespielen übernamen, und Japan ohnehin noch an Spielhallenautomaten festhielt. Dann kam wegen Atari viele Entwickler herausekeln, plus viele überhastete Spiele von denen, sowie den Limiten der VCS/2600, die Flut an Schrottspielen. Das ergab zusammen mit dessen Marktdominanz dort, den nordamerikanischen Videogame Crash von 1983, der eigentlich als nordamerikanischer Videokonsolen Crash bezeichnet werden sollte, weil die wenigen Automaten und Computer Gamer dort wenig betroffen waren. Europa und Japan waren ebenso wenig betroffen, weil bereits bei Homecomputer bzw noch bei Automaten. In Japan fing Automatenhersteller Nintendo gerade den Wechsel an, zu Konsolen als kleiner Automat für zuhause, mit Erfolg weil dort keine Homecomputer, und nahm danach auch gleich die am Boden liegenden USA mit. Ebenfalls Automatenhersteller Sega schaffte es wegen später startend mit dem Master System anfangs nur halbwegs in Europa sowie mehr in Südamerika. Erst mit der Mega Drive ausnutzten sie aus, dass Nintendo bei der SNES 16bit total verschlief. Aber sie schossen sich selber ab mit dem Konflikt von Saga USA mit Mega Drive gegen Sega Japan mit Saturn. Nintendo verpeilte sich dann auch noch mit der N64, und Sony übernahm dann mit der Playstation die Führung.)

(Dieser Crash hat auch Nintendo USA zur Lockout Chip Erweiterung der NES gebracht, um damit Spiele zu zensieren, um Qualität zu erzwingen. (Nintendo Japan hatte in der Famicom keinen solchen.) Nur haben sie wie jegliche Zensur diese Machtposition auch für "missliebige" Inhalte unterdrücken missbraucht. Während nur Qualität fördern bereits mit einem reinen Gütesiegel als Empfehlung machbar gewesen wäre, ohne Gefahr von Missbrauch einer Monopolposition. Sega hat im Kontrast dazu diesen Fehler ausgenutzt, alles erlaubt, und das Resultat auch als Coolness vermarktet, was der Mega Drive ebenfalls half (während Nintendos Ruf als Kinderspielzeug die N64 und auch Gamecube stark hinderte). Gefolgt von einer Kollision mit Moralwächtern welche genau missliebige Inhalte unterdrückt haben wollten. Wonach Sega aber statt Zensur einführen die Spielewertung nach Altersklassen erfand, bzw vom Film übernahm und adaptierte.))

8bit mit Customchips ohne Sprites (inklusive volle alles machende Gatearrays)

Platz 1 geht eindeutig an die TED Rechner Commodore 16 und 116 und Plus/4. Bei einem überarbeiteten und ordentlich erweiterten VC-20 VIC, ohne dessen 22 Zeichen Limite, nicht verwunderlich. Bei einem spritelosem reduzierten C64er VIC-II erst recht nicht. Sofern man keine Sprites braucht ist der TED mit dem C64 auf obigem Platz 1 graphisch fast 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 mit den 8+4=12bit Farbzellen von Commodore, und erst noch auf 8+8=16bit erweitert, somit das beste von beiden! Selbiges gilt beim Font, umschaltbar Commodore 256er flexibel oder Atari 128er sparsam. Lediglich der Overscan fehlt, wenn auch nur horizontal, vertikal geht es mit Rasterinterrupt ausnutzen, es hat hier keine FarbRAM Limite. Ebenso offensichtlich fehlen vor allem die Sprites. Mit 7/8 Prozessorbremse, aber wie Atari 800 von 2MHz aus. 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 800, mit zumindest Farben pro Zeichen haben, plus 2bpp, was zusammen das fehlen dessen ohnehin schwachen Sprites zumeist aufwiegen kann! Trotzdem wurde der Plus/4, nachdem er als angeblichen C64 Homecomputer Nachfolger (fehl-)vermarktet wurde, wegen fehlenden Sprites und schwachem Audio unterschätzt und verspottet als Minus/60, trotz in allem anderem gleich gut oder gar leicht besser zu sein!

Platz 2 geht überraschend an den Commodore VC-20. Er leidet zwar massiv an seiner "halbierten" 176 Pixel Auflösung, und nur 22 Zeichen breitem Text. Bitmaps fehlen auch. Aber abgesehen davon hat er einen 256er Font mit 1bpp und 2bpp (was aber nur noch 88 Pixel ergibt), und dazu noch FarbRAM auf 8+4=12bit. In obiger Kategorie hätte er nicht nur den VCS/2600 klar geschlagen, sondern auch den Atari 800 bedrängt. Hätte er nur 40 Zeichen bekommen wäre er wie die TED Rechner am 800er vorbeigezogen. Erstaunlich für Commodore erstmals einen Kleinterminal und Geräteanzeigen Chip designen, und zur Spielkonsole erweitern, und dann zum Homecomputer ausbauen! Damit ist dessen VIC ein erstaunlich guter Chip, der nur wegen seiner geringen Auflösung massiv unterschätzt wurde (sowie wegen dem kleinen 5.5k RAM im VC-20), noch weit mehr als der TED später. Er legte zudem noch die Basis von C64 und TED. (Ebenso unterschätzt wird damit Al Charpentier als Designer vom VIC und auch VIC-II, sowie als einen Einfluss auf den TED, der absolut mit Jay Miner als Designer von TIA und ANTIC+CTIA und Agnus+Denise vergleichbar ist.)

Platz 3 geht erstaunlich an den Sinclair ZX Spectrum. Zwar nur 256 Pixel, wie TMS9918, und auch nur 1bpp als seine grösste Schwäche, aber zumindest mit Farbattributen, wenn auch nur auf 8x8. Damit konnte man bei einem Billigrechner leben, solange man nicht mehr als 2 Farben in einer Zelle haben muss, was sonst mit "Attribute Clash" kollidierte. Was gerade scrollende Spiele besonders schlecht traf, weshalb viele Spectrum Spiele ein statisches Spielfeld haben, nur bewegte Figuren in Bereichen mit deren Farbe nutzen. Für so billig ist das aber erstaunlich gut und völlig akzeptabel. Wurde dementsprechend oft geklont (vor allem im Ostblock, erweiterte Spectrums dominierten in Russland noch durch die ganzen 1990er!).

Platz 4 geht total überraschend an den Tangerine Oric. Sogar nur 240 Pixel, und nur 1bpp, aber zumindest mit Zeichen und Farben auf 6x8 im Zellmodus bzw sogar auf 6x1 im Bitmapmodus. Trotzdem hinter dem ZX Spectrum, weil die Attributschalt Leerpixel bzw Leerzeichen noch schlimmeren "Attribute Clash" erzeugen. Damit konnte man bei einem Billigrechner aber auch leben.

Platz 5 geht dann noch wie erwartet als letzter an die Motorola MC6847. Hat nur 256 Pixel, und das auch nur mit im Chip selber eingebautem festem 64er ROM Font, oder 1bpp Bitmap ohne Farbwahl. Kann 2bpp, mit nur 128 Pixel, aber das ohne Schwarz und mit schlechter Farbauswahl ohne Farbattributen oder auch nur Farbregister. Kann 8+1 Farben in mischbarer 2x2 Blockgraphik, oder 4+1 Farben in unmischbarer 2x3 Blockgraphik mit Schwarz (aber diese sind beide nur 2*32=64 breit, und ohne SAM Tricks auch nur 2*16=32 bzw 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 reiner TTL Rechner! (Nur mit "R" 256x192 in Schwarzweiss auf NTSC Farbmonitor, kann man die 4 Apple II pseudo-2bpp Farben Sw+Bl+Or+Ws bekommen. Was ihn weit besser macht, unter ZX Spectrum aber etwa vergleichbar Oric (weniger Pixel aber gar kein "Attribute Clash". Aber das versagt bei PAL, wird zu rein Schwarzweiss.)

8bit ohne Customchips (inkl mit MC6845 Timing oder allenfalls noch nur-Datenpfad Gatearrays)

Platz 1 und 2 gehen etwa gleichauf an den Acorn BBC Micro und den Amstrad/Schneider CPC. Deren 640 Pixel liefern bis zu 80 Zeichen trotz 8Pixel breit, für viel Text. Aber viel entscheidender sind bei 320 Pixel bereits 2bpp und vor allem bei 160 Pixel volle 4bpp. Somit können diese selbst die recht primitive Logik und das Fehlen von Sprites grossteils wettmachen! Wo exakt sie in obiger "mit Sprites" Kategorie landen würden ist offen. Wohl irgendwo unter dem C64 und über dem Atari 800, ziemlich sicher oberhalb vom TMS9918 (aber unter V9938 und V9958 und Master System), und wohl unter der Famicom/NES. Damit schlagen sie erst recht locker alle in der "ohne Sprites" Kategorie, ausser den TED der halbwegs mithalten kann. Und hier in dieser sowieso alle. Preis dafür ist der Verbrauch von sehr viel Videospeicher (beim BBC wählbar 20.5/16/10.25/8k, im CPC fest 16k), sowie viel CPU um diesen umzuschaufeln (was deren ungebremsten 2MHz 6502 bzw 4MHz Z80 aber auch recht gut können, gerade auch die Z80 mit ihrem eingebauten LDIR/LDDR Blockkopierer, 16k werden in etwa 0.1s umkopiert). Damit sind diese eigentlich erstaunlich moderne Rechner, welche die Methoden heutiger (S-)VGA Rechner vorwegnahmen, nur mit geringerer Leistung. Unter einander kann der BBC mit 256 statt 200 Zeilen und halbierbarem Speicherplatz punkten, aber der CPC mit 3^3=27 statt nur 2^3=8 RGB Farben gleichauf oder eher leicht voraus ziehen.

(Die 464plus und 6128plus addierten 32 von 4096 RGB Farben, und fein scrollen, sowie Sprites, und wären mit letzteren sogar ein Sprung in die erste Kategorie. Sie waren aber in 1990, und somit erst 5 Jahre nachdem die 16bit Atari ST und Commodore Amiga erschienen waren, als 8bit schlicht nicht mehr relevant. Auch dass die 464plus immer noch Kassette hatte war total veraltet. Ebenso einen Modulsteckplatz addieren, der seit Floppys irrelevant wurde. Dies traf erst recht die mit ihnen eingeführte GX-4000 nur-Modul Konsole, welche genauso scheiterte wie die Atari 800 basierte XEGS und die C64 basierte 64GS Konsolen.)

Platz 3 geht völlig überraschend in die DDR an den Mühlhausen KC 85/2 (und dem 85/3, und erst recht dem 85/4). Bereits bei 85/2 und 85/3 volle 320 Pixel mit FarbRAM auf 8x4. Beim 85/4 das FarbRAM sogar auf 8x1 verbessert, und dazu noch die 2bpp Alternative angeboten, wenn auch mit Bitplanes und ohne Farbwahl. Nur mit 640x256 1bpp und 160x256 4bpp addiert würde das Teil mit obigem BBC gleichziehen, bzw mit 16 Farben statt 8 sogar darüber hinaus! All das in nur reinem TTL, einfacher Struktur, aber sehr wirksam, weil genau das was man braucht, auf etwas über TED Niveau! Aber auch hier ist der Preis viel Speicher (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, plus beide weitere 1.25k simulierter Textmodus Speicher) sowie viel CPU um diesem umschaufeln. Wobei letzteres die auf nur 1.75MHz bzw 1.77MHz gebremste 2MHz UB880 ordentlich belastet, trotz LDIR/LDDR haben, mitsammt "ghosting" wegen den Bitplanes, was bei der ineffizienten eingebauten Software der 85/2 sehr langsames scrollen in 0.6s ergab (wurde im 85/3 seinen neueren ROMs weit verbessert)!

Platz 4 geht wenig überraschend an die Hercules HGC. Sie ist sehr hoch aufgelöst mit 720x348, mehr als jede andere 8bit Karte oder Rechner. Aber hat keinerlei Farben, als einzige Karte mit Bitmap. Als eine mit Bitmap erweiterte IBM PC MDA auch nicht verwunderlich. Scheidet wegen MDA Spezialmonitor aber strikte ohnehin aus.

Platz 5 geht eher überraschend an die MTU K-1008 Visible Memory. Nicht ganze so hoch aufgelöst mit 320x200, aber immerhin gutes Mittelmass, mehr als ZX Spectrum oder Oric. Aber auch keinerlei Farben, ausser mehrere werden synchron betrieben.

Platz 6 geht sehr überraschend an den Jupiter Ace. Zwar nur 256x192 Pixel, und nur 1bpp, und ohne Bitmap, und sogar als einziger Rechner mit Zellgraphik keine Farben. Aber er wird durch die 128 Zeichen RAM Font gerettet, womit auch ohne Bitmap volle 32x24 Zellen mit beliebigen 8x8 Muster machbar sind. Ist damit an Auflösung beim ZX Spectrum seinen 256x192, bleibt aber mangels Farben selbst hinter dem Oric zurück.

Platz 7 geht erst massiv abgeschlagen an die IBM PC CGA. Diese kann eigentlich 640 Pixel, oder 320 mit 2bpp, und damit zwei Modi der BBC und CPC, mit dem selbigen 16k Speicher wie letzterem, welchen die 4.77MHz 8088 erst recht problemlos umschaufeln kann. Aber genau der weitere Modus mit 160 Pixel und 4bpp fehlt hier massiv. Noch schlimmer, auch bei 2bpp ist nur eine Farbe frei wählbar, und diese erst noch an die Randfarbe gekoppelt, und muss damit Hintergrund sein. Dazu kommen noch wenige feste 3er Farbsätze ohne Schwarz darin, welche den Register/Rand praktisch auf Schwarz zwingen. Daher kommen die vielen für die CGA typischen Spiele mit Sw+Gn+Rt+Ge oder gar 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 aber wenigstens noch mit Schwarz plus einer 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 es hat keinen RAM Font, was ihn selbst hinter den ZX Spectrum und Oric und Jupiter Ace Billigrechnern stellt. Und zu dessen Blockgraphik benutzen zwingt, welche aber auch nur 1x2 Blöcke liefert, nur 80x50 erlaubt trotz 80x25 Zeichen. Egal was man es versucht, die CGA macht einen Strich durch die Rechnung, verhindert gute Graphik und frustriert! (Nur mit dem vielen unbekannten "Tweak Mode" kommt man mit 2x1 Blockgraphik und 8x2 Font noch auf halbwegs ordentliche 160x100 mit 16 Farben. Wobei die CGA selbst bei dieser Pseudo-Bitmap in der Auflösung unter allen drei Billigrechnern ZX Spectrum und Oric und Jupiter Ace liegt. Zudem war dies zumeist unbekannt, weshalb nur wenige Spiele es nutzten. Womit die CGA selbst hinter all diesen landet!) (Bonuspunkte gibt es aber für die ganze Schaltung am Ende vom Handbuch abgedruckt.)

Platz 8 geht weiter hinten an den Apple II. Zwar noch 280 Pixel aber nur mit 1bpp (mit Schwarzweissmonitor), sonst nur noch 140 "Pixel" mit pseudo-2bpp (mit Farbmonitor) in seinen ganzen 6 Farben und geringer Auswahl. Dazu kommt dass die 140 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 Atari 800) angebracht gewesen. Für volle Geschwindigkeit muss man mit mehr Schaltung dahinter gehen (welche die Atari 800 hat, und trotzdem nicht ausnutzt, der C64 hat sie und nutzt sie). Die Blockgraphik liefert 16 gute Farben, aber nur mit 1x2 Blöcken, was nur 40x48 erlaubt. (Mit 2x1 Blöcke und 2 oder 4 mal mehr Zeilen, würden bessere 80x48 oder 80x96 drin liegen, wobei letzteres etwa obigem CGA "Tweak Mode" entsprechen würe.) Zudem ist es erst noch nicht mit Text beliebig mischbar (ausser mit fest oben 20/24 Graphik und unten 4/24 Text). Text ist zudem nur ASCII64 Zeichen ROM Font, ohne Blockgraphik, oder auch nur Kleinbuchstaben, und ohne Farben. Es hat damit zwar 3 Modi aber keiner davon ist wirklich gut, vergleichbar frustrierend wie CGA, aber wegen älter noch schwächer. (Nur den Farbeffekt im Bitmap abschalten können, hätte beliebige 280x192 erlaubt, mit eigenem 7x8 Font, inklusive 96 ASCII und Blockgraphik, wenn auch weiterhin ohne Farben.) (Bonuspunkte gibt es auch hier für extrem gute Dokumentation, die ganze Schaltung und der System Sourcecode sind im Referenzhandbuch abgedruckt!)

(Der Apple IIe erweitert auf Text mit vollem ASCII96, aber weiterhin mit ROM Font und ohne Farben. Mit 1k Speichererweiterung "80-column" gibt es sogar 80x24 Zeichen davon, auf BBC und CGA und CPC Niveau. Ebenso "Double Low Resolution" Blockgraphik auf immerhin 80x48 (wenn auch diese in 1982 total veraltet ist). Weit besser gibt es mit der 64k Speichererweiterung "extended 80-column", die auch "Double High Resolution" Bitmap auf 560er mit 1bpp kann, und somit auch 140 "Pixel" mit pseudo-4bpp in vollen 16 Farben. Womit er nicht nur die CGA überholt, sondern bis zu zwischen KC 85/4 (max 4 von 16 Farben) und BBC+CPC (etwas mehr Auflösung) kommt, von Platz 8 auf 3 springt! Aber diese 140 sind dann aus 80*1.75 bestehend, weil in 7bit 1.75*4bpp passen, was noch schwieriger zu programmieren ist! Weshalb er den Platz 3 mit der KC 85/4 teilen muss.)

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

8bit ohne Bitmapgraphik oder RAM Font

Platz 1 geht gerade noch an die IBM PC MDA. Ohne Bitmap oder RAM Font oder Farben, zählen in dieser Kategorie nur noch die Anzahl Zeichen im Bild sowie dem ROM Zeichendatz seine Anzahl und Art an Graphikzeichen. Die MDA hat als einzige 80x25 Zeichen, und erst noch mit vollem 256er Font und separaten Attributen. Der Font hat aber vor allem viele akzentierte Zeichen, so wenig Graphikzeichen. Insbesondere hat die im Font eingebaute mischbare Blockgraphik nur 1x2 und 2x1, keine 2x4 mit Modusattribut, womit es trotz 80x25 Zeichen nur auf 80x50 Blöcke reicht, oder auf 160x25. Scheidet wegen MDA Spezialmonitor aber strikte ohnehin aus. (Der "Tweak Mode" der CGA geht auf der MDA nicht, mangels Speichermenge, mit nur 4k statt 16k.)

Platz 2 geht knapp dahinter an die Commodore PET und CBM. Hier sind es immerhin noch 40x25 (CBM8000er sogar 80x25), mit 128+revers Font. Das aber erst noch mit 2 Fonts zur Auswahl, für volles ASCII+Graphik32 oder ASCII64+Graphik64. Somit eine grosse Sammlung an Graphikzeichen, plus im Font eingebaute mischbare 2x2 Blockgraphik, und damit Auflösung von 80x50 (CBM8000er sogar 160x50), was die beste Pseudographik aller Zeiten ergibt, das Vorbild für alle anderen.

Platz 3 geht knapp dahinter an den Kaypro II. Hat grössere 80x24, aber nur 128 ohne revers Font. Und nur einen Font mit volles ASCII+Graphik32. Somit weniger Graphikzeichen als PET/CBM. (Beim Kaypro 10 sind es dann 80x24 von 80x25, mit in letzteren separater 2x4 Blockgraphik, für 160x100. Damit zieht er am PET und CBM vorbei, selbst an CBM8000er.)

Platz 4 geht mit Abstand an den Osborne 1. Kann zwar 52x24 von 32x128 Zeichen, mit 128er Font, aber ohne revers, wenn auch mit halbhell und unterstrichen, dank dem 9bit breiten letzten 16k DRAM. Hat zudem damit mischbare 2x2 Blockgraphik, und erlaubt so doch noch recht viel Auflösung von 104x48, wenn auch sehr schmale hohe Blöcke.

Platz 5 geht mit Abstand an den Tangerine Microtan 65. Kann nur noch 32x16 Zeichen, zwar mit 128er Font inklusive Symbole, aber ohne revers. Hat zudem damit mischbare 2x4 Blockgraphik, dank dem 9bit breiten ersten 1k SRAM, und erlaubt so doch noch recht viel Auflösung von 64x64.

Platz 6 geht mit kurz dahinter an den Tandy TRS-80 Model 1. Zwar wahlweise 32x16 oder 64x16, aber nur ASCII64. Und 64x16 sind weniger nützlich als 40x25, trotz 1024 statt nur 1000 Zeichen. Hat noch damit mischbare 2x3 Blockgraphik, und erlaubt so doch noch recht viel Auflösung von 64x48 bzw 128x48, aber hat keine weiteren Graphikzeichen).

Platz 7 geht dann an den Galaksija. Praktisch ein Tandy TRS-80 Model 1, mit selbigen ASCII64 plus mischbare 2x3 Blockgraphik. Kann aber nur die 32x16, bzw 64x48 Blockgraphik. Und braucht 65% von Prozessor zum zeichnen, ist also langsamer trotz mehr MHz. (Mit der Bitmapmodus Modifikation würde er nach Oric kommen (weil keine Farben) aber vor Jupiter Ace (weil mehr als Zellmodus). Weil das aber nur mit einer Speichererweiterung plus etwas Modifikation geht, verbleibt er in dieser Kategorie.)

Platz 8 geht noch an die Sinclair ZX80 und ZX81. Haben zwar 32x24 (schmaler TRS-80, aber mehr Zeilen), mit 2x2 Blockgraphik (und damit doch nur selbige Anzahl von 64x48 Blöcken), aber dafür nicht mal volles ASCII64, weil die Blockgraphik in die 64 Zeichen mit hinein muss. Und braucht ebenfalls den Prozessor zum zeichnen, im ZX81 75% davon und langsamer, im ZX80 sogar 100% und Bild sobald er rechnet abschaltend. Somit entsteht das Minimalste was hier überhaupt noch antreten darf. (Mit dem undokumentierten Bitmapmodus würde er auch nach Oric aber vor Jupiter Ace kommen, sowie leicht nach modifizierter Galaksija (weil 192 statt 208 Zeilen und mehr Prozessorverbrauch). Weil das aber nur mit einer modifizerten Speichererweiterung geht, verbleibt er in dieser Kategorie.)

Platz 9 geht dann an die Processor Technology VDM-1 und Sol-20. Zwar stets 64x16, und stets volles ASCII, und kein Prozessor verbrauchen. Aber nur einen inkonsistenten Satz von Graphikzeichen, ohne vollständige Blockgraphik. Damit strikte unten aus der Wertung herausfallend. (Bonuspunkte gibt es aber für die ganze Schaltung im Handbuch detailliert beschrieben und danach abgedruckt, weil der Rechner auch als Selbstlötprojekt machbar war.)

16bit Systeme

Platz 1 geht wie zu erwarten an den Commodore Amiga. Mit 640 Pixel und bis zu 4bpp oder 320 bis zu 6bpp sind das bis auf 64k an Speicher. Damit geht er fast bis an die Grenze von 320x200 8bpp ihren 64k. Dazu kommen jede Menge Features, von vielen Farben (32 normal oder (2*)32 EHB oder 4096 HAM) und Overscan und fein scrollen, bis zu mit Copperliste alles umstellbar (und diese bis beliebiger Zeile pausierbar). Dazu kommen recht grosse Spritesbits, 8*16*2bpp=256bit. Damit ist er eine sehr gute Erweiterung des Atari 800, praktisch alle dessen Schwächen beseitigt. Aber die Bitplanes und ihr "Ghosting" beim scrollen stören gross, hier am schlimmsten, ausser noch beim KC 85/4. Der Blitter wird damit oft eher überbewertet, zumal er nur Umkopieren beschleunigt, und das wegen Setup Aufwand sich erst bei grossen Flächen lohnt, wo genau "Ghosting" am schlimmsten wird. Ausser er wird zwecks Doublebuffering benutzt, wo er rendering optimal beschleunigt. Der Copper ist noch nützlich, aber auch nicht wirklich dringlich, weil er wie die Atari 800 Displayliste letztlich nur alle Rasterinterrupt Techniken beschleunigt. Und den Prozessortakt unnötig auf 7/8 gebremst macht er vielleicht gerade mal wett. Anderseits kostet er ebenfalls Spritebits. 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, ausser es hat externes FastRAM und das ChipRAM wird zu VRAM degradiert. Und ebenso 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 dem Macintosh seine 512x342 1bpp locker, mit 32k um ein Drittel mehr als dessen 22k. Dazu ohne wie Mac den Prozessor anhalten. 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 in deren Kategorie. Sie sind sogar identisch mit einem Amiga solange man dort nicht Prozessor für mehr bpp opfert! Kann man hier nicht, weil keine Bitplanes, aber daher auch kein "Ghosting", wenn auch weiterhin Probleme wegen Pseudobitplanes. All das aus einem sehr einfachen simplen auf billig gebauten Rechner (Projektname war RBP, Rock Bottom Price, anfangs nur $800 mit Schwarzweiss Spezialmonitor bzw $1000 mit RGB Videomonitor), trotz mit 512k 4 mal soviel Speicher wie dem Mac seine 128k (war anfangs $2500 trotz nur Schwarzweiss), bzw 2 mal soviel wie dem Amiga seine 256k (war anfangs $1300 mit Farben). Das mit gleichem Prozessor wie der Mac, aber volle 8MHz statt dessen 7.8336MHz, und gar 1/8 mehr Takt als dem Amiga seine 7.159MHz. Dazu noch ungebremst durch Video (wie auch der Amiga), bzw beide nur die 6-Takt Zugriffe auf 8 ausdehnen. Selbst fehlender Blitter und Copper und Sprites sind mit einem so schnellen Prozessor und 4bpp nicht mehr so kritisch, wie es damalige Spiele oft zeigten. (STE hat Blitter addiert, kam aber zu spät.) Fehlende mehr als 1bpp in Schwarzweiss, nicht mal ein 320x400 2bpp, machen diesen Monitor für Spiele unattraktiv, verlangen nach dem Farbmonitor, mit nur noch 200 Zeilen (aber das hat der Amiga auch). Lediglich hat er dort keine über 4bpp und 16 Farben, und die sind von 512 statt 4096, sowie kein Overscan. Aber insbesondere fehlt als schlimmstes fein scrollen. Was alles ihn auf den zweiten Platz verweist, wenn auch erstaunlich knapp. Nur mit Chunks statt Pseudobitplanes (und fein scrollen um Faktor 4 weniger wichtig), sowie 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 Amiga, als 640x400 2bpp oder 320x400 4bpp, bzw 640x200 4bpp oder gar 320x200 8bpp, hätte er den ersten Platz alleine genommen! Er wurde damals ebenfalls ziemlich unterschätzt, gerade auch im Vergleich mit dem Amiga, wenn auch nicht ganz so extrem wie TED oder gar VC-20.

Platz 3 geht an die SNK Neo Geo. Kann massive 256*16 Farben, und das aus 65536. Hat ein 320er Raster, mit 4bpp. Wenn auch das bereits mit Overscan, viele Spiele nutzten daher 320-16=304 breit. Aber kann kein 640er Raster, auch nicht auf 640-32=608 reduziert, nicht mal zum Preis von auf 2bpp herunter, was ihn hinter Amiga und Atari ST stellt. Hat kein Bitmapmodus (und auch kein Zellmodus), sondern nur Sprites, kann aber mit diesen ein Bitmap simulieren, solange der kleine separate VRAM Speicher noch ausreicht. Kein interlaced. Was alles ihn leicht weiter hinter den Amiga stellt. Keine Tastatur oder Disk, und damit die Limiten aller reinen Konsolen gegenüber Homecomputer. Was ihn klar hinter dem Amiga und auch dem ST stellt. Dazu aber massive 96 mal 16 Pixel Sprites pro Zeile, mit 4bpp, und somit die besten Spritebits überhaupt hier, 96*16*4bpp=6kbit(!) und die typischen grossen Sprite Objekte in dessen Spielen, was ihn doch bis an den spritelosen Atari ST aufrücken lässt. Dabei merkt man nicht nur die Erfahrungen aus Spielhallen Automaten herstellen, sondern dass die AES ein voller MVS Automat in Konsolenform ist!

Platz 4 geht an dann die Sega Mega Drive. Kann 4*16 Farben, aber aus nur 512, wie Atari ST, somit unter Amiga und gar Neo Geo. Ein 256 schmales bzw 320 normales Textfeld mit 4bpp, wenn auch in horizontal nur mehr Breite aber kein volles Overscan. Aber kein 512 oder 640 Feld. Kann aber interlaced. Was alles ihn deutlich hinter dem Amiga stellen würde, weniger hinter dem Atari ST und etwa gleichauf mit der Neo Geo. Aber hat nur Zellmodus, trotz vollem 16bit keinerlei Bitmap, was ihn klar hinter alle diese drei verweist. Dazu aber gute 20 mal 32Pixel an Sprites pro Zeile, mit 4bpp, und somit die zweitbesten Spritebits, 20*32*4bpp=2.5kbit, aber weit hinter der Neo Geo ihre 6kbit. Diese sind somit nicht ausreichend um fehlendes Bitmap zu simulieren, oder auch nur bandweises Parallax, bleibt so deutlich hinter dem Neo Geo. Keine Tastatur oder Disk, kann auch so nicht überholen. Auch hier merkt man die Erfahrungen aus Spielhallen Automaten herstellen, weil dieser explizit als 16bit Automatentechnologie in die Konsolen bringen designt wurde. Aber diese waren schwächere Automaten als die MVS.

Platz 5 geht erst an die Nintendo SuperFamicom/SNES. Kann immerhin 16*16 Farben aus 32768. Kann diese zu 256 zusammenlegen, aber dies wurde selten genutzt weil ausbremsend. Kann zwei 512 breite Modi (mit Overscan, was etwa (48..56)*8=384..448 breites Textfeld ergibt), aber das wurde auch selten genutzt. Ist sonst nur 256 breit (was weiterhin nur etwa (24..28)*8=192..224 Textfeld ergibt, und die typische klotzige Schrift wie schon bei der Famicom/NES), was ihn hinter Sega Mega Drive und Neo Geo stellt. Kann auch interlaced. Kann aber ebenfalls wie Mega Drive nur Zellmodi, was ihn klar hinter die Amiga und Atari ST und Neo Geo verweist. Kann viele oder grosse Sprites, aber nicht beides zusammen, weil Menge an Spritebits pro Zeile reduziert wegen HDMA, maximal 34 Zellen zu 8Pixel mit 4bpp an Sprites, 34*8*4bpp=1088bit, was ihn selbst klar hinter die Mega Drive ihre 2.5kbit stellt. Zudem schwach mit dem langsamsten nur 8/16bit 65816 Prozessor, klar hinter allen echt-16bit 68000 basierten, selbst hinter 16/8bit 68008. Keine Tastatur oder Disk, kann auch so nicht überholen. Das Mode 7 pseudo-3D Texturen reicht nicht um all dies noch zu retten. Kein Wunder dass die Mega Drive die SuperFamicom/SNES ernsthaft hindern konnte, und an manchen Orten sogar komplett abservierte.

Platz 6 geht dann an den Sinclair QL. Kann zwar noch maximal 512 Pixel, und das mit 2bpp. Aber die 2bpp sind für Text wo man viele Pixel nutzen will fast sinnlos. Und ohne Farbattribute oder Farbregister nur in 4 festen Farben, fast auf MC6847 Niveau unten (nur leicht bessere Auswahl mit schwarz, und 512x256 statt 128x192 Pixel). Nur 1bpp plus Attribute wäre gleichviel Daten (2*16k statt 32k) aber nützlicher (16 Farben wie Spectrum). Kann für Spiele 4bpp mit 256 Pixel, aber hat dann wegen gerade bei Graphiken sinnlosem blinken trotzdem nur 8 RGB Farben, unterhalb Spectrum seinen 16 auf Acorn BBC 8+blink Niveau (nur mit leicht besseren 256x256 statt 160x256 Pixel). Hat somit 2 Modi, aber keiner davon ist wirklich gut, frustrierend wie bei CGA und Apple II. Dazu noch keine Sprites, wie beim Atari ST, aber auch ohne dessen 320 Pixel und wählbaren 16 Farben. Somit schwächste Farben in der 16bit Generation. Er ist er sogar erstaunlich schwächer als sein erstaunlich guter 8bit Vorfahre ZX Spectrum seinen 16 Farben, und nur etwa gleichauf mit dessen Konkurrenten Oric seinen 8. Zudem schwach mit dem langsameren nur 16/8bit 68008 Prozessor, auch hinter allen echt-16bit 68000 basierten. Selbst Tastatur und Microdrive Endlosbandlaufwerke können ihn nicht mehr retten.

Platz 7 geht weit abgeschlagen an den Apple Macintosh. Mit für 16bit Generation eher niedrigen 512 Pixel Auflösung, was noch mit 6x12 Pixel Font halbwegs gerettet wird. Aber gar keine Farben, trotz dass alle anderen 16bit diese haben, und der Apple II einer der ersten Rechner mit solchen war. Selbst bei Schwarzweiss nur 1bpp, nicht mal 2bpp Graustufen. Damit klar unter Sinclair QL. Erst recht ohne Overscan oder Sprites. Dies gibt ihm keine Chance, total abgeschlagen. Somit schwächste Graphik dieser Generation, mit Abstand. Mit 22k nur die Hälfte mehr Speicher als beim CPC 16k, und nicht mal ein Viertel mehr als beim Acorn BBC und KC 85/4 20k, und nur 2/3 vom QL 32k, sowie ohne deren Farben und Modi, alles Rechner welche ich daher über den Mac setze (und diese wiederum alle unter dem C64!). Selbst Tastatur und Disk können ihn nicht mehr retten, zumal jahrelang (Jan 1984 bis Sep 1986) keine auf dem Rechner laufende Entwicklungswerkzeuge existierten, man dazu einen separaten schweineteuren LISA benutzen musste, ein Mac alleine wie bei Konsolen nur Konsum erlaubte. Erst MPW auf dem Mac Plus erlaubte entwickeln, als Ersatz nachdem die LISA bereits in 1985 eingestellt worden war. Eigentlich eine sehr primitive Kiste für seine Zeit, weil eigentlich bloss eine bessere elektronische Schreibmaschine. Der angeblich "graphische" Macintosh bezieht sich absolut nicht auf die Hardware, zu welcher sein Spitzname "Macintrash" bestens passte, sondern nur auf die GUI Software. Die leistete in 64k ROM mehr als dem Atari ST seine 192k ROM! Das Resultat von 4 bis 5 Jahre Entwicklung und Optimierung, statt in unter 1 Jahr zusammengeworfen.

(Trotzdem war diese Software für den Rechner zu viel, weil GUI und 16bit einfach nicht zusammenpassen. Ebenso waren die Fenster für den bloss 9" Monitor mit 512x342 zu viel. Zudem war der graphische Dateimanager ohne Harddisk erst recht langsam. Was alles zum Spitznamen "Mickey Mouse Rechner" führte. Die LISA war mit nur 5MHz trotz 720x360 sogar noch schlimmer. Was alles auch für den Atari ST galt, trotz ungebremstem 8MHz Prozessor und 640x400. Ebenso dem Amiga, zudem um 1/8 untertaktet und bei viele bpp noch mehr Last. Dazu noch visuell unpassender in beiden ihre 200 Zeilen Modi, und ohne 6x12 Font bei 640 Pixel minus Fenster auch noch keine 80 Zeichen pro Zeile sichtbar. Selbiges galt auch mit Microsoft Windows auf 16bit/286er oder gar noch schlimmer 8bit/8088 PCs, egal ob mit CGA 200 Zeilen visuell unpassend, oder EGA erst recht langsam.)

(Erst die 32bit Generation lieferte genug Prozessor (ab 30MHz) und Speicher (ab MBytes) für GUIs, sowie Harddisk Zugriffszeiten 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, mit noch genug von anderen Fenstern sehen, dass diese sich überhaupt lohnen. Aber mit trotzdem genug Farben für Graphik, ab 8bpp. Mit GUIs so minimal brauchbar ab 800x600@8bpp aus 512k Bildspeicher, und erst echt besser ab 1024x768 mit 8bpp aus 3/4 MByte oder gar 1152x865 mit 8bpp aus 1MByte. Also SVGA oder Macintosh II oder Atari TT oder Amiga AGA, alle ab etwa 1990.)

(Was alles komplett vorhersehbar gewesen wäre! Zumal der Xerox Alto in 1972 das Ziel hatte als Forschungsrechner einem Durchschnittsrechner von +10 Jahre = 1982 zu entsprechen, sowie Dorado und Star in 1980 +10 = 1990. Ersterer brachte nur A4 Format Monitor mit Vollbild Bitmap, zweiterer erst A3 Format Monitor mit GUI und Fenster und Desktop. Alle GUIs auf 1980er Rechner mit zumeist nur A5 Format Monitor waren damit weit verfrüht.) (Weshalb MS-DOS ohne diese Last, mit Auswahl von nur Kommandozeile oder mehreren zeichenbasierten Dateimanagern wie Norton Commander oder PC Tools oder Xtree, dominant werden konnte. Und letztere sich auch erst mit Harddisk durchsetzten. Während Apple nur knapp im hochpreis Graphiker Marktsegment die 1980er überlebte.)

Ganz ausserhalb der Konkurenz ist die IBM PC EGA. Ihre massiven 4*64=256k stellen sie weit oberhalb der 64k Grenze, und somit disqualifiziert. Auch den EGA Spezialmonitor brauchen kommt dazu. 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 vorbeizieht. Die Sega Mega Drive und SNK Neo Geo und Nintendo SuperFamicom/SNES verlieren an der Auflösung, sowie Mega Drive und SuperFamicom/SNES an fehlenden Bitmaps, werden somit von der EGA geschlagen. Aber gegen deren Sprites und sonstigen Effekten kann die EGA nichts anrichten, ohne die 8bpp des MCGA Modus der VGA. Den "graphischen" Mac schlägt sie aber locker, schlicht weil der keine Farben kann, oder auch nur Graustufen, und weniger Auflösung hat. Auch der QL hat keine Chance, mit nur 8 Farben.

(Die VGA kommt dann mit MCGA als allererste auf volle 8bpp, und damit vor allen anderen Rechnern hier! Und das sogar in genau 64k. Wenn auch nur mit bloss 1/4 von ihren 256k ausnutzenden 320x200 8bpp, und somit 2* Pixel und 2*bpp der CPC 16k ihren 160x200 4bpp. Zumindest bis die SVGA 640x480 oder gar 800x600 8bpp kamen. Das reichte aber dank schaltbaren Modi immer noch, solange man keine Sprites braucht, was auch mit genug Prozessor plus 8bpp weniger wichtig wird. Damit wurde die MCGA auch zum Anfang von allem brauchbaren PC Gaming. Und mit 64k zum Ende dieser Übersicht.)


Home | Artikel | VCFe Videoarchitekturen als visuelles Medium

Diese Seite ist von Neil Franklin, letzte Änderung 2020.07.02