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 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 (teils 640x400 erlaubten in 256k), mit 80x30 Zeichen in 8x16 Font zugelassen. Ab 800x600 16bpp (braucht 1024k) wurde es dann ausgereift, weil 16bpp für RGB 32*32*32=32768 Farben tauglich ist, 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. Der Sol-20 ist dagegen ein vollständiger Rechner, mit einer VDM-1 fest eingebaut, wenn auch nur als intelligentes Terminal vermarktet. 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 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. 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 Zeichennummern 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. Daneben hatte es keinerlei Graphikzeichen, konnte nur reduzierte ASCII Art, und scheidet damit hier aus. Zudem hatte er nur 1kx6(!)bit MOS Schieberegister als Videospeicher, war somit nicht direkt adressierbar, konnte kein vorzu veränderbares Bild, nur reine Fernschreiber Emulation. (Dieses war wiederum 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 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. Es wurden aber wegen Hauptspeicher mit 6+2=8bit nutzen, die beiden extra Bits für reverse und blinkende Darstellung benutzt. 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, würde aber mit nur diesem hier ausscheiden (wie es der Apple 1 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 als Y*32+Y*8+X strikte nach 2 10bit Addierern verlangt, dazu 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, der in 8*128Bytes aufgeteilt ist, mit in 128 je eine 3er Gruppe 0+8+16, 1+9+17, .., 7+15+23 zu 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 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 16 Farben erlaubt (wie TV Dazzler). Diese werden aber hier als NTSC statt RGBI Farben spezifiziert, durch die 4bit als "Viertelwellenpixel" Muster nutzen, welche pro Bit einen 14.31818MHz Takt lang wirken, mit 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 keine Schwingung, und 0101=1010=Grau weil eine 14.31818/2=7.159MHz Schwingung, sowie alle 0011 0110 1100 1001 mittlere/50% Farben (Violett Blau Grün Orange), alle 0111 1011 1101 1110 helle/75% Farben (Cyan Gelb Rosa Hellblau), alle 0001 0010 0100 1000 dunkle/25% Farben (Magenta Dunkelblau Dunkelgrün und Dunkelrot/Braun). 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 Timing von PAL Monitoren ansteuern, aber nur in Schwarzweiss, 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.)

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 3 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, Zeilen zu 40* 7bit.

Mit Farbmonitor ist es weit komplizierter, das Bitmap wird dabei zu direkt binär codierten "Halbwellenpixel" Muster, 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.

Daher entsteht in erster Näherung eine Art pseudo-2bpp mit 3.5(!) "Pixel" pro Byte, wobei jeweils von einem "Zwischenpixel" seine beiden Bits als "Halbpixel" auf 2 Bytes verteilt werden. 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 (0)0.10.10.10 (0)10.10.10.1, 20mal wiederholt. Dies ist so kompliziert 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. Der Monitor sieht 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 interpretierend, und 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 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 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. Er ist zudem erst ab II Plus sauber implementiert.)

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 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 auf Text mit 96 ASCII Zeichen, aber keine Graphikelemente. Dazu noch falls mit 1k 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 welches sichtbar ist). Dazu auch ab Revision B auch "Double Low Resolution" Block 80x84, sowie falls mit 64k 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 die 7 Pixel a bis g jetzt sogar in 4 Bytes als Bits 0bbbaaaa 0ddccccb 0feeeedd 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 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. 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. 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" Videomonitor.

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 gar keinen Y*40+X 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 statt 1 Addierer in Apple II) wird teilweise kompensiert durch keinen vollen Zeilenzähler haben (was 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 8k oder 16k oder 32k DRAM statt 4k oder 8k SRAM, aber selbige 1k VRAM aus SRAMs. 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 1k. Die 8096 addiert nur eine Speichererweiterung 32k zu 96k. Die 8296 hat dann aber nur noch 2*64=128k DRAM, liest Video ohne separates VRAM aus dem ersten von diesen, nur 8bit breit, mit 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=20)bit in 3 Registern, welche 2mal 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) mit horizontal 160/80Pixel Raster, sowie 2 Missile und 1 Ball 1x1 (3 2bit Register) als horizontalen 160/80/40/0Pixel Block, alle auf 160er positionierbar. 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", und explizite 8 Helligkeitsstufen "Luma"), und damit eigentlich völlig überdimensioniert. Hat 2 Register für Spielfeld Vordergrund und Hintergrund, 2 für jeden Player+Missile, 1 für denn Ball, zusammen 5. Diese sind aber 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, sowie die Farben setzen. 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. Damit können auch mehrere Karten zusammen genutzt werden, welche dann 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 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.

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 gescrollt 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 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 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 Konsolen Subset 400 gemacht). Danach doch noch in 1982 als Konsole 5200, aber nicht zu den 400 und 800 kompatibel (und auch nicht zum VCS/2600). Dann 1983 verbilligt zu 800XL (und Subset 600XL). Zum Schluss noch 1985 umgestylet als 65XE (und eine speichererweiterte 130XE). Dann kam 1986 eine 5200+2600+neueres Kombination als 7800 Konsole. Aber diese wurde nach Firmenaufkauf bereits 1987 durch die XE basierte 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 Verzierung sind, aber nicht Spielmodule wegen ROM Chips kaufen sondern wegen den Spielen darin! Das restliche Management hat dies auch nicht bemerkt und korrigiert, trotz dass sie als Filmfirma wissen sollten dass Leute Filme nicht wegen dem Streifen anschauen sondern wegen der Geschichte drauf. Das hat viele Entwicker hinausgeekelt, was die restlichen massiv überlastete, und bei Atari zu eigenen schlechten oder gar unfertigen Spielen führte (Pacman und E.T.), sowie bei mehreren von den Ehemaligen gegründeten Drittfirmen zu ihren oft überhasteten aber dann überhypeten Spielen. Nicht verwunderlich führte dies zusammen mit den Limiten der VCS/2600 zu einer Flut von Schrottspielen, gefolgt von Vertrauenszusammenbruch der Käufer, und zusammen mit derer Marktdominanz zum Nordamerikanischen Videogame Crash von 1983 (die restliche Welt hatte zumeist nicht VCS/2600 und war davon wenig betroffen). Dabei verlor Atari massiv, was dann zu obigem Firmenaufkauf führte, gefolgt von planlosem hin und her, sowie davon Verlust der externen Spielehersteller.)

Zwei Customchips CTIA/GTIA (Color/Graphic Television Interface Adaptor, für eine einst geplante bessere Bitmap Konsole), sowie ANTIC (AlphaNumeric Television Interface Controller, mit Textmodi bzw eben Zellmodi weil addiert zu einem Homecomputer). Mit Bild aus dem normalen DRAM Hauptspeicher. Dazu noch für nicht-graphisches POKEY (Paddles plus Tastatur plus Audio plus UART), alle 3er 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):

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 mal ein 35.8µs schmales, Overscan 384 mal ein 53.6µs überbreites). Trotz 1bpp hat Modus "F" aber nur "1.5" statt 2 Farben, genauer einen "Chroma" Farbton in 2 "Luma" Helligkeitsstufen. (Den Modus "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 versagt aber 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, durch 3 weitere 2x8 4bpp Font bzw 80x192 4bpp Bitmap Varianten ersetzbar, aber mit sehr niederer Auflösung, und geben dabei erst noch nur relativ nutzlose Fähigkeiten: "$00" ist der normale 320er Modus, "$40" ist 16 Helligkeiten von 1 Farbton (Mono 4bpp), "$80" ist 9von16 Farben mit beliebiger Helligkeit, "$C0" ist 16 Farbtöne in 1 Helligkeit (Kaleidoskop-artig, und kein Schwarz mehr).

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

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

Farben wieder mit Register auswählbar aus 16*8=128 (16 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+Missile (alle Missiles als fünften Player zusammengelegt nehmen die vierte Bild/Spielfeld Vordergrund Farbe), kein separater Ball, zusammen 9. 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.

Wie man sieht ist dies ein massiv komplexer Chipsatz, mit vielen Modi zeilenweise schaltbar und Zellmodi mit ladbarem Font. 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. 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 Bandbreite frei ist, für neben 8bit Zeichennummer und 6*1bit Fontstreifen lesen sowie Zugriff für den Prozessor auch noch zeichenweise Farbdaten lesen. Bei 40*6=240 von 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 zeichnen 8bit Zeichennummer 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 Speichertakt verlangt, mit wegen diesem damals teure 200ns 4116-20 DRAMs benötigen. Obiges "Text" sind dagegen nur 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, der Apple II hat 2.045MHz, der Commodore 64 2.045MHz NTSC oder 1.97MHz PAL.)

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 Pixelgruppen 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 jegliche 2bpp Sachen, was dessen grosse Schwäche ist. Ebenso kein fein scrollen, und auch kein Overscan, trotz selbst bei Graphic immer noch recht schmalem Textfeld.

Dazu Sprites, in allen Modi ausser "0" weil dies ein anderes Timing hat, 8x8 oder 16x16 1bpp (genauer 1x1 oder 2x2 Spritezellen aus 256 zu je 8x8). Mit horizontal volles 256 oder halbes 128er Pixel Raster (mit gleichzeitig auch vertikal ihre Zeilen doppelt gezeichnet), auf volle 256er positionierbar. Jedes hat eine eigene Farbe. Wobei entweder alle 8x8 oder alle 16x16 sind ("Size" = 0 oder 1), sowie alle 256er 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 Attribute für pixelweise Wahl 0:YJK oder 1:TMS9918-artiges 4bpp). Die V9938 addiert vertikal scrollen für Text, erst die V9958 auch horizontal für Games. Beide erlauben bei G4 bis G7 auch vertikalen Overscan, mit 212 statt 192 Zeilen, sowie interlaced auf 2*192=384 bzw 2*212=424. Beide 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 Zeichennummerbyte 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. Es addiert beides horizontal und vertikal scrollen, zudem mit obere 2 Zeilen und rechte 8 Spalten davon ausnehmbar. Kein Overscan. Sprites sind nun 8x8 oder 8x16 4bpp (genauer 1x1 oder 1x2 Spritezellen aus 256 zu je 8x8), aber mit 8 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, auch 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 32*8=256 von 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 wie Atari 800 abgestuft. 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 in Schwarzweiss, plus dem 7.16MHz Pixeltakt, erzeugt auf einem NTSC Farbmonitor 4 Farben (wie Apple II, mit dessen Sw+Bl+Or+Ws Farbsatz). Das versagt aber wieder auf einem PAL Farbmonitor, weil dieser dazu 17.734472/2=8.867MHz Pixel bräuchte. Vielleicht 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 die Hälfte der Block/Pixel Bits unbenutzt, welche mit einem hypothetischen VDG 4x1 Modus zusammen, sogar ordentliche 128x192 ergeben würden, 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 und 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. Er verkaufte sich aber nicht, trotz weit besser zu sein, vermutlich wegen der zu niedrigen horizontalen Auflösung.

Daher verwendet für den VC-20 (bzw VIC-20 im englischen Sprachraum oder VIC-1001 in Japan). Das aber mit nur der halben Bandbreite des PET/CBM. 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 5kByte ergab, nicht mal die 8k SRAM des PET 2001.

Umschaltbar 2 Zellmodi. Wegen Bandbreite wurden, um Zeichencodes plus Font zu holen ohne den Prozessor 40% der Zeit anzuhalten, die PET/CBM 40 Zeichen auf 20 halbiert, aber dann für etwas weniger schlimm das Bild auf 22 verbreitert, aber dafür 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 (wie Atari 800 Zell "4") Font. Aus variablem ROM/ModulROM/RAM Satz (wie Atari 800) 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 Zeichen. ROM hat 2x2 Blockgraphik (gibt 44x46) sowie alle PET/CBM Graphikzeichen darin (beide Fonts). Aber mit ModulROM/RAM erlaubt wieder spielespezifisch ersetzen, und somit selbst bei 2bpp noch 88x184 Pixel. Tastatur hat auch alle Graphikzeichen drauf, aber weil weniger Tasten, 2 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. Jedes Zeichen hat damit ein eigenes von 16 NTSC Farben (und ganzer Hintergrund eines davon, sowie Rand nur eines von ersten 8), diese als Farbton+Helligkeit Kombinationen ohne separate Helligkeitsstufen (genauer nahe-RGB, in Reihe Schwarz Weiss Rot Cyan Magenta Grün Blau Gelb, Hellbraun und Pastellbraun, sowie Pastelle der Rot bis Gelb). Mit dazu die identischen unteren Adressbits A0..A9 nutzend, womit dies strike ein 8+4=12bit Videochip ist! Das erlaubt 256 Zeichen Font mit 16 Vordergrund Farben zu kombinieren, selbst bei 2bpp, statt dem Atari 800 Zell "6" seinen nur 64 Zeichen mit 4 Farben und nur in 1bpp, bzw Zell "4" mit 2bpp aber nur 2 schaltbare Farben pro Zeichen, oder der TMS9918 seine 256 Font mit 2*16 Farben aber massiver Bandbreite und gar kein 2bpp, sowie Farben entweder nur 32 Paare oder pro 8x1 mit massivem Speicherverbrauch. Wovon sowohl farbige plus reverse Textausgabe wie auch vor allem Spiele massiv profitierten.

Kein Prozessortakt auf 7/8 bremsen, weil bei diesen breiten Pixeln der NTSC Farbmonitor 4 Farben Effekt nicht entstehen kann, selbst mit beliebigen Farben, weil nur 176 Pixel haben es verhindert. Die aktuelle Zeilennummer ist auslesbar, aber kein Interrupt davon. 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 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 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 der massive Schwachpunkt. Alleine diese verdoppeln, mit einem separaten 1kx8bit ZeichencodeRAM (wie PET/CBM) verwenden, und nur den Font von ROM/ModulROM/RAM holen was in dessen Bandbreite passen würde, wäre der VIC ein sehr guter Chip gewesen. Dazu noch 16k DRAM statt 5k SRAM und der VC-20 wäre ein sehr guter Rechner gewesen.

Sinclair ZX80 (1980)

Absoluter Minimalstrechner, 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 SRAM und 1 7805 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 strikte auch 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 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), das ist aber mit einem Lötpunkt umstellbar.

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 als (32+1)Bytes gespeichert.

Am Ende der Zeile, egal wieviele Bytes bis zum HALT waren, wird das zuvor präparierte R Register des Refreshzählers zu Bit6 = 0, was erkannt wird und automatisch einen INT Interrupt generiert. Damit wird der Refreshzähler als 7bit Timerinterrupt missbraucht, wonach der Prozessor wieder aus ROM an 0000..0FFF liest, womit nichts mehr ausgegeben wird und der Prozessor alles bekommen, 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. Kein fein scrollen. Erst recht keine Sprites. 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, und ohne Interrupts eingeschaltet, weil ohne R als Timer, und so 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 4 oder 5 TTLs (je nach ob man genaues Timing duplizieren will) umfassende Erweiterung welche diese dort nachrüstet. (Womit die ULA etwa 18 + 4 oder 5 = 22 oder 23 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). Beliebig horizontal und vertikal in Hardware scrollbar. 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 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. (Dieser Ansatz wurde auch im Nascom verwendet, mit 48x16 Zeichen, aus einem Ausschnitt von einem 64x16 Speicher anzeigen.)

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! (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äre 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 Speicheradresse zusammenlegen. Es gibt aber auch keinen Y*40+X Addierer. Aber auch keinen separaten Adresszähler (wie PET/CBM). Aber dessen Funktionalität ist in der MC6845 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 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 selbigen 7.16MHz bzw 2*7.16=14.32MHz, und somit 44.7µs breites Textfeld wie Atari 800. 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.

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.)

Kein fein scrollen, ausser byteweise (8oder4 Pixel bei 1bzw2bpp) durch MC6845 Anfangsadressen schieben. 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 addressieren (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.

Kein fein scrollen, wieder ausser byteweise (8oder4oder2 Pixel bei 1bzw2bzw4bpp) durch MC6845 Anfangsadressen. Keine Textmodi, weil inzwischen genug Speicher um auch bei Bitmap genug Text darzustellen, und damit auch ohne dessen Verbrauch an Bandbreite, mit statt dessen bis zu 640 Pixel. 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 Speicheradresse zusammenlegen. Es gibt wieder keinen massiven Y*40+X Addierer. Ebenso nicht den kleinen Apple II 4bit Addierer. Aber auch keinen separaten Adresszähler (wie PET/CBM, oder wie MC6845 in MDA oder CGA).

Vielmehr werden die 80 Zeichen pro zeilen mit einem einfachen Schalter 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). Aber wegen separatem SRAM gehen Prozessor und Video Adressen durch den selbigen Schalter. Also erscheint dies dem Programmierer einfach als einen 4k Block, mit 128x32 Zeichen (wie Osborne 1), aber diese mit Zeichen von 64 bis 127 vierfach überlappend, und Zeichen von 0..63 der Zeilen von 24 bis 31 ebenfalls mit je 3 Zeilen von diesen (und einem unbenutztem 16er). (Dieser Ansatz wurde im wegen Firmenuntergang nie verkauften VDM-2 auch so gemacht. Was dann vom Entwickler Ende 1979 veröffentlicht wurde, und vermutlich durch Kaypro kopiert.)

(Der Nachfahre Kaypro 10 (1983) erweiterte auf separatem 2+2=4k VRAM aus SRAMs, asynchron vom Prozessor und mit eigenen Adressregistern. Text 80x24, aber mit der verwendeten MOS6545A wären eigentlich 80x25 machbar, weil lineare Adresse. Wohl wegen zu obigem kompatibel nicht ausgenutzt. 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 benutzen sogar 160x100). 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. (VDM-2 hat 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).

(Dazwischen gab es als Prototypen einen zum originalen VIC pinkompatiblen VIC-1.5 (NTSC MOS6562 und PAL MOS6563) der für einen VIC-40 Rechner gedacht war, aber auch als Aufrüstsatz mit Austauschchip für den VIC-20, ebenfalls mit doppelten 40x25, aber dem VIC statt VIC-II Farbsatz, und ohne Bitmap und Sprites. Dieser Chip soll einst für ein ColorPET Projekt designt worden sein. Die NTSC MOS6564 und PAL MOS6565 wurden scheints für ein Projekt namens TOI vorgesehen. Der MOS6568 ist mir unbekannt.)

Er hat Umschaltbar 3 Zellmodi und 2 Bitmapmodi:

Zell immer 40x25 Zeichen (wie PET/CBM, somit den massiven VIC Schwachpunkt an horizontaler Auflösung korrigiert). Speicher hat die selbige Bandbreite, aber mit pro Zeile nur den Font holen, weil die Zeichencodes nur in der ersten Videozeile eines Zeichens geholt werden, mit sie danach aus einem internen 40 Zeichencodes (und auch die Farbcodes) Buffer wiederholt werden. Dies haltet den Prozessor für jeweils 40µs an, was aber nur in 1/8 der Bildzeilen passiert, so nur noch 40/8=5% Leistung kostet. Diese sind als die 25 "Badlines" bekannt.

Mit 8x8 1bpp oder aber 4x8 2bpp ("Multicolor") Font (wie Atari 800 und VIC). Aus variablem ROM/ModulROM/RAM Satz, von 256 Zeichen (wie TMS9918 und VIC). ROM hat 2x2 Blockgraphik, sowie alle PET/CBM Graphikzeichen darin (beide Fonts, wie VC-20). Aber mit ModulROM/RAM erlaubt wieder spielespezifisch ersetzbar. 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), wieder mit identischen unteren Adressbits A0..A9 nutzend, womit der VIC-II ebenfalls ein 8+4=12bit Videochip ist (wie VIC). Dadurch wieder 256 Font mit 16 Vordergrund Farben kombinierbar (leicht andere als beim VIC, Pastell Cyan/Magenta/Gelb ersetzt durch Graustufen 25%/50%/75%, Pastellbraun durch Dunkelbraun), und das auch mit 2bpp. 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 mit nur 20 Zeichen breit, unter dem VC-20 seinen 22 liegend!

Bitmap 320x200 1bpp oder 160x200 2bpp (auch "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 "Badlines" hier erhalten.

Trotz beliebigen Farben und 40 Zeichen breit kein Prozessortakt auf 7/8 bremsen. Damit auch 320 Pixel wie Atari 800, aber ein schmales Textfenster, selbiges 40µs wie die 280er 7/8 Pixel vom Apple II. Trotzdem keine/wenige NTSC Farbmonitor 4 Farben Effekte. Dies wohl vor allem weil dem ca 8MHz Pixeltakt seine /2=4MHz Wellen nicht auf die 14.31818/2/2=3.579MHz von NTSC oder die 17.734472/2/2=4.434MHz von PAL fallen. Das erst recht nicht mit 6von8Pixel Font seinen breiten Zeichen mit 2Pixel breiten Vertikalen seinen 2MHz Wellen. Weshalb man sich fragt, warum andere so sehr 1/8 Prozessortakt zu opfern bereit waren. (Vermutlich wegen billigem 14.31818/16=0.895MHz Divisor bei NTSC, aber bei PAL dann einem aufwendigeren 17.734472/20=0.8867MHz. Womit C64 bei PAL den identisch teuren 17.734472/18=0.985MHz benutzt, und bei NTSC konsistent diesen als 14.31818/14=1.0227MHz nimmt, was der Apple II auch schon hatte.)

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 vertikal und horiontal, aber stets ganzes Bild (und dieses dabei auf 38 Zeichen bzw 24 Zeilen reduziert, im Gegensatz zum Atari 800 der die Scrollverluste mit Overscan benutzen kompensieren kann). Die aktuelle Zeilennummer ist auslesbar, sowie mit automatischem Vergleich auch als Rasterinterrupt nutzbar. Zwar keine Displayliste, aber obiges plus jederzeit Moduswechsel durch Software erlaubt vieles zu kompensieren (inklusive der Randfarbe vom Overscanbereich umschaltbar machen um Hintergrund Bänder bis in den Rand hinauszuziehen, oder fein scrollen selektiv einschalten um Bänder zu scrollen). 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 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.

(Der Nachfahre Commodore 128 hat einen leicht erweiterten VIC-II E (NTSC MOS8564 und PAL MOS8566), mit nur einen Port addiert, wie von 6502 zu 6510, sowie 1/2MHz Modusschalter. Sowie einem zusätzlichen VDC Chip (MOS8563), wie TMS9918 mit eigenem 16k oder 64k Speicher, asynchron vom Prozessor und mit eigenen Adressregistern. Aber ansonsten eher an der CGA angelehnt was Videoformat anbegeht. Für Timing aufbauend auf einem erweiterten MOS6545 Registersatz. Text 80x25 Zeichen. Mit 8x8 1bpp Font, stets aus RAM Satz, von 256 Zeichen. Mit 8bit Attributen, aber nur Bits 3..0 Vordergrund RGBI Farben, weil Bits 7..4 ARUF A=Alternativen Zeichensatz und R=Revers und U=Unterstrich und F=Flash(blinkend). Gar kein 2bpp. Daher Bitmap auch nur 640x200 1bpp, in vollen 16k, ohne Farbattribute, nur 2 RGBI Register.)

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, der flackert, was als "Snow" (= Schnee) bekannt ist.

(Selbiges "Snow" hat man wegen langsamen 1MHz Speicher auch stets im PET 2001 (im CBM 3000 mit 2MHz Speicher ist das behoben). Ebenfalls in der CGA im 80 Zeichen Modus, der den 2MHz Speicher trotz Doppelzugriffe in die selbige DRAM page voll auslastet (in der MDA ist dies nicht der Fall, wegen separaten Zeichen- und Attributspeichern). Dies wird aber trotz langsamen Speicher vermieden in den VDM-1 und Sol-20 sowie im TRS-80 Model 1, durch bei Zugriff die geholten Videodaten ausnullen. Was dem Jupiter Ace und dem PET und der CGA fehlt.)

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 22 oder 23 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. 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 als 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.

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. Mit für alle 8x8 Pixel Zellen 1+1+3+3bit RGBI Farbattribute. Wobei Vordergrund und Hintergrund nur eigene 3bit RGB haben (in Vorder Bits0..2 bzw Hinter Bit3..5, als GRB), mit gemeinsames I (in Bit 6). Dazu noch stets blinkend (wie CGA wenn Hintergrund Intensität zu Blinken umgeschaltet ist) (in Bit7). Aber mit nur alle 8x8 Pixel eine Zelle (wie C64), aber ohne dem C64 sein "Multicolor" 2bpp 4 Farben Modus, was oft in "Attribute Clash" resultierte, wenn in einem 8x8 Feld mehr als nur 2 Farben gebraucht werden (was beim TMS9918 wegen dessen kleinerem 8x1 Feld weit weniger zutraf, und dort als "Color Spill" bekannt ist, und bei C64 eben erst bei mehr als 4 Farben geschieht). Dieses fehlende 2bpp ist wohl die grösste Schwäche dieser ansonsten erstaunlich guten Graphik. Dazu noch separates RGB ohne I (auch als GRB) Register für den Rand im Overscan (wie C64 auch, TMS9918 nicht).

Hat kein FarbRAM wie C64, muss daher trotz dass er mit stets Bitmap keine Zeichennummern Zugriffe braucht 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 möglich, neben 2*2 Videozugriffe), falls dieser auf die ersten 16k vom DRAM Speicher zugreift. Das ist als "Waitstates" oder "Contention" bekannt. Es geschieht bei allen Zeilen, nicht nur jeder ersten Zeile von Zeichen wie die C64 "Badlines" (die ULA hat keinen internen Buffer). Beim C64 sind es aber auch CPU für 40µs zu 100% stoppen, hier nur ein bis zu 75% Verlust (je nach auf welches von 8 Takten der Prozessor loslegt mit 0..7 Waits). Ist wegen Z80 und Basic ROM ungebremst ausser für die wenigen Zugriffe auf Basic Status und Code und Variablen vernachlässigbar, aber bremst bei Maschinencode um etwa 21/64=33% (C64 40/8=5%). Weshalb viele Spiele nach 48k verlangen, nicht nur für mehr Platz sondern auch wegen voller Geschwindigkeit in den ungebremsten separaten 32k.

Selbst für in 6/8 Takte 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, hier aber 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), 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! 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 6von8 Bits 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 Bandbreite für bei jede 6 Pixel zeichnen 1 8bit Zeichennummer 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 (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 Zeichennummer 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 22 oder 23 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 5.35MHz Pixeltakt. Damit bei nur 32*8=256 Pixel schon 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 Zeichennummerbyte holen, dann 2/3 statt 1/2 Bandbreite 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 2k an Bildspeicher als (2*32)x30 horizontal oder 32x(2*30) vertikal verwaltet werden, bei erweiterten Modulen mit 2+2=4k sogar als (2*32)x(2*30).

Dazu Sprites, mit 8x8 oder 8x16 2bpp (genauer 1x1 oder 1x2 Zeichen aus dem Font, 1x2 nutzen 2*128 Paare, in 4k standard plus 4k erweitertem Font), mit horizontal volles 256Pixel Raster, auf 256er positionierbar, sowie horizontal und vertikal spiegelbar, was die 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 von der Zeichennummer 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 Chip schaltbar 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 oder gar 8bit separates FarbRAM sondern weitere 1k an normalem 8bit Speicher benutzt. Ist damit strikte sogar 8+8=16bit Video. Hat dazu für Zeichencodes und Farbcodes zwei interne 40 Zeichen Buffer. Hat daher auch "Badlines", sogar 2 davon pro Zeichenzeile, in der ersten Zeile pro Zeichen das zweite Byte holen und gleich nutzen und speichern, in jeder Zeile vor einem Zeichen bereits das erste Byte holen und erst nach dem alten vorhandenen letztmals nutzen speichern. Im Bitmap 1bpp sind es so auch 2 Farben pro Zeichen (wie C64), aber im 2bpp auch nur 2 statt 3 pro Zeichen mangels Platz für 3*(3+4=7)=21bit in 16bit.

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 vertikal und horiontal, 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 deren offizieller Schulrechner), zumal sie neben mehr Video und Speicher auch noch schnelleren Prozessor hatten (aber das auch vom Video mehr ausgebremst). Der Plus/4 hatte zudem als reinen "farbigen PET" Homebusiness Rechner mehr in Basic nutzbares RAM (und alle 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 weder Zeichennummern noch Attributbytes). Was 80 statt 40 Bytes Videodaten erlaubt, und trotzdem die halbe Bandbreite 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 x200 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 (dessen Netzteil auch den Rechner versorgt), sowie Fernseher oder Videomonitor (braucht separates Netzteil mit auch RGB zu Video Umwandler drin).

Kein fein scrollen, wieder ausser bytepaar(!)weise (16oder8oder4 Pixel bei 1bzw2bzw4bpp) durch MC6845 Anfangsadressen schieben. Keine Textmodi, weil inzwischen genug Speicher um auch bei Bitmap genug Text darzustellen, und damit auch ohne dessen Verbrauch an Bandbreite (bis zu "Badlines"), 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 von 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 32k Hauptspeicher abgetrennt. Wie diese 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 Zeichennummern), 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, 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 DRAM und VRAM, auch nur 1.77MHz statt 4MHz, vermutlich weil kompatibel bleiben. Letzteres als 2*(2*16)=32von64k Videospeicher, mit darin 10+10k statt 10+2.5k Bild (auch plus 2*1.25k Zeichennummern), sowie 32+2*16=64k Hauptspeicher. Trotz 40*8=320 Pixel 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 Spalten im Speicher liegen. Hat nun 2 Bitmapmodi. Obiges 320x256 1bpp, aber nun mit alle 8x1 Pixel 2 Farben aus 16 (wie TMS9918). Oder umschaltbar auf 320x256 2bpp, in festen 4 Farben schwarz/rot/cyan/weiss (also 2bit R und G=B). Letzteres aber wegen dem 10+10k Videospeicher mit zwei 8*1bpp Bitplanes statt 32k an 4*2bpp Chunks (R in Bitmap, G=B in Farbattribut). Es ist damit wie Amiga anfällig auf "Ghosting" beim scrollen, wenn das dargestellte Bild Pixel beinhaltet von denen eine Plane ihre Bits bereits verschoben sind und die andere noch unverschoben ist, was unpassende Bits kombiniert zu zufälligen Farben welche kurz aufflackern, ähnlich wie beim "Snow" Problem. (Beim 1bpp plus Farbspeicher kombinieren sich lediglich neues Muster mit alten Attributen, was weniger flackert.) Es kann anderseits egal ob 1oder2 Planes zu 8*1bpp mit dem gleichen Font beschrieben werden, statt bei 2bytes 4*2bpp mit "zerlegtem" Font.)

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. Dabei wird wegen langsamen alten 64k Speicherchips der eigentlich gute Prozessor während Bildzeilenausgabe gebremst. (Der Macintosh 512k hat zwar schnellere 256k Speicherchips, aber die gleiche Steuerlogik, kann sie somit nicht ausnutzen. Erst der Macintosh Plus in 1986 konnte dies.)

Dank 16bit recht hohe (aber für 16bit eher niedere) 512x342 1bpp auf dem eingebauten 9" Spezialmonitor, aber nur in Schwarzweiss (und damit selbst unter den 720x348 einer HGC Bitmap). Scheidet wegen Spezialmonitor strikte hier aus, aber weil eingebaut wird er noch durchgelassen. Daher keine Farben möglich. 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.) Es passen 85x28 Zeichen beim 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.)

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 wie bei vielen aufgerüsteten Schreibmaschinen (die hatten 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 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 $10000 und zweites $3500 bis $5500.) (Selbiges hatten sie 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, mit Monitor und Kassettenlaufwerk.)

(Ganz ausser Konkurrenz kam erst beim Nachfahren 32bit Mac II von 1987 eine Auswahl von Graphikkarten, darunter auch farbige, anfangs mit VGA-artigem 640x480 4bpp, oder vertikalem 600x800, 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, nur einer 16/8bit 68008. Nachfolger des ZX Spectrum. Wie diesen 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, 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 Bandbreite bzw halbe "Waitstates" oder "Contention" erlaubt hätte.

Nur 2 Bitmapmodi, 512x256 2bpp und 256x256 4bpp, beide in 32kByte. Also das Volumen von Spectrum Attribute von 8x8 Zellen in 3/4k auf 8x1 Zellen in 6k verfeinern (wie TMS9918), dann beide 6k Bitmap und 6k Attribute zusammenlegen zu 12k, dann von 192 auf 256 Zeilen verl&aunl;ngern zu 16k (wie Microtan 65 und BBC), sowie dann Bandbreite verdoppeln zu 512 Pixel in 32k. Mit 512 von 15MHz bzw 256 von 7.5MHz Pixeltakt, ein sehr schmales 34µs Textfeld. Aber hat gar keine Attribute mehr, und kein "Attribute Clash", weil die 2*16k nun stets als 2 Bitplanes zusammengelegt werden (wie KC 85/4).

Farben bei 512x256 mit 2bpp, ohne Farbattribute oder auch nur Farbregister, sind somit nur 4 feste Farben schwarz/rot/grün/weiss (auch hier errinnert die KC 85/4 an einen umschaltbaren Spectrum oder QL, nur mit cyan statt grün, und 320x256 statt 512x256 Pixel). Diese sind angeordnet als Pseudobitplanes statt Chunks mit Bit0..7 8*R und Bit8..15 8*G, und damit wenigstens nicht anfällig auf "Ghosting" beim scrollen. Ist damit fast so schwach wie die MC6847 basierten Rechner (aber hat wenigstens schwarz in der Auswahl, und 512x256 statt 128x192 Pixel).

Farben bei 256x256 mit 4bpp, aber es hat nur 8 RGB statt 16 RGBI, weil wegen 1bit für blinken nur 3bpp nutzbar. Damit vergleichbar wie die BBC ihr 4bpp Modus 8+blink (hat dabei aber 256x256 statt 160x256 Pixel). Angeordnet als gemischte(!) Pseudobitplanes+Chunks Bit0..7 4*BR und Bit8..15 4*FG (F=flash=blink).

Dabei fehlen aber einerseits genau dem textorientierten 512x256 Modus das für einen Cursor nutzbare blinken, mit statt dessen für Text fast nutzlose 2bpp, statt besser passende 1bpp für Font, plus Attribute welche bei Text eh kein Clash haben aber viele Zeichenfarben plus blinken erlauben. Anderseits hat der spieleorientierte 256x256 Modus der kaum blinken nutzen kann dieses, und verliert dafür an Farben, ausgerechnet dort wo Attribute Clash meiden die 4bpp nützlich macht. 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 Ersatz vom Spectrum, und dass 256x256 nicht für Spiele ist, sondern nur für Graphen.

IBM Enhanced Graphics Adapter EGA (1984)

Ganz ausser Konkurrenz, weil mit gigantischen (1bis4)*64=64bis256kBytes Speicher laufend (und zudem noch 32bit breitem!). Scheidet damit komplett aus. Hier nur als Beispiel, was man damals schon mit viel Masse machen konnte, und weil Urahne der heutigen PC Graphik und damit als Vergleich wertvoll. Kein Rechner, sondern eine Karte für den IBM PC Bus, und damit auch für 16/8bit 8088 PC/XT, nicht nur 16bit 286 PC/AT mit ISA Bus! Daher wie CGA mit separatem VRAM aus DRAMs, asynchron und nicht Prozessor bremsend. Ebenfalls mit Adressen vom Prozessor, dessen Adressmodi ausnutzend. Aber nur 1*64k Adressraum davon nehmend, weil die 64bis256kBytes als 16bis64kWorte von 32bit angeordnet sind (1bis4 Sätze von je 8 16kx4bit DRAM Chips)! Mit 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 deren Steuerregister kollidieren.

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 80x43 Zeichen, mit dem altem 8x8 CGA Font.

Bitmapmodi einerseits CGA kompatibel 640x200 1bpp und 320x200 2bpp. Mit anderseits eigene 640x350 1..4bpp (mit 1bpp fast wie HGC). Dies mit Bitplanes statt Chunks (wie KC 85/4), mit gleichem Font bei variablen bpp Vorteil, aber ohne "Ghosting" weil mit einem aufwendigen 8zu(1..4*8)=32bit Pixelprozessor die Planes synchron bewegbar sind (neben auch Bewegung beschleunigend und den Adressraum auf die 64kWorte erweiternd). Davon 4*28k nutzend (oder einen solchen Ausschnitt aus bis zu 4*64k an Bilddaten).

Mit 16 Farben aus 64 RGB (4*4*4), was auch bei CGA kompatigel gilt, dessen 16 feste 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 Bandbreite 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 dieser Masse zu erschlagen!)

(Noch mehr ausser Konkurrenz ist die davon erweiterte Video Graphics Array VGA von 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 gab es 80x50, mit (8+1=9)x8 Font. Bei Bitmap addierte sie offiziell 640x480 4bpp (mit Bitplanes), sowie 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 640x480 4bpp passt er aber nicht mehr in 64k Adressraum, kann daher nicht mehr mit MDA oder HGC kombiniert werden. Mit 256 bzw 16 Farben aus 262144 RGB (64*64*64). Wieder nur mit externem VGA oder Multisync Spezialmonitor, dem ersten mit 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 (256*256*256) statt 262144, sowie "Hi-Color" 800x600 3*5=15bpp mit direkten 32k RGB (32*32*32) 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! Eigentlich von Tramiel Technologies Limited, vom ex Commodore Besitzer Jack Tramiel, der dort wegging und eine neue Firma gründete. Welche dann Atari Inc aufkaufte und ausschlachtete, und sich dabei auch in Atari Corp umbenannte. 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 Designer daran beteiligt waren.

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 Bandbreite. Benutzt auch vierfache Menge Videospeicher (von 8k Bitmap auf 32kByte). Hat damals riesige 512k Speicher, daher den Featuresatz abgebaut/vereinfacht, nur noch Bitmapmodi, keine Zellmodi mehr. Mit Bild aus dem normalen DRAM Hauptspeicher. Ohne separaten Farbspeicher. Auch ohne Zeichencodes und damit ohne "Badlines". Selbiger 8MHz 68000 wie der Macintosh, aber dank schnellen 256k Generation Speicherchips ohne ihn zu bremsen (wie beim Macintosh Plus seinen 64k Chips), und somit der schnellste aller Homecomputer! Auf zwei Customchips basiert, Speicher/Adressen Controller/Generator ("MMU"), und Daten/Pixel Chip ("Shifter"). Umschaltbar 3 Bitmapmodi, aber welche davon benutzbar sind ist abhängig vom Monitortyp:

Mit dem Schwarzweiss Spezialmonitor ist stets 640x400 1bpp 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 normalen RGB Monitor. Wieder nicht mal 2bpp Graustufen, trotz dass der Shifter eigentlich 2bpp könnte, mit dann 320x400 erzeugen, aber der Monitor kann es nicht, weil unterhalb dem MDA seinen 3 Graustufen. Also wieder mit Schwarzweiss rastern (wie Macintosh). Auch mit eigenartigem 0=weiss und 1=schwarz (wie Macintosh). Erlaubt 80x25 Zeichen bei 8x16 1bpp 100dpi Font, oder 80x50 Zeichen mit 8x8. Minus GUI Platzverlust erlaubt dies aber nicht mehr 80 Zeichen breite Platz! Die Hardware könnte auch 6x12 Font und so gar 106x33 Zeichen, aber die Systemsoftware hat keinen Font mit solchen drin. Alles im allem ein besserer Macintosh, der sogar als Spitzname Jackintosh genannt wurde, aber nicht so ausgenutzt wird. Es gab sogar ein Modul, mit genau 3 ROM Sockel, eines mit ST spezifischer Treibersoftware vom Dritthersteller, zwei von einem Mac zu entnehmen (oder wohl eher zu kopieren), das den ST in einen besseren und billigeren Mac verwandelte.

Mit dem RGB Monitor (vergleichbar den BCC und CPC ihren) sind es dann 640x200 2bpp (und das kann auch 2bpp Graustufen sein) oder 320x200 4bpp (aber kein 4bpp Grau). Dies mit 4oder16 Farben aus 512 RGB (8*8*8) (ist damit ziemlich genau ein in allem verdoppelter CPC, aber auch verdoppelte CGA Bitmapmodi) (ist damit gleiche 2oder4bpp wie QL, aber wegen Farbregister ohne dessen Limite auf feste 4). Bei 640 von 16MHz Pixel ein 40µs Textfeld (wie C64). Verwendet Pseudobitplanes statt Chunks, also Pixel in Worten wie bei Planes behandelt (mit den Font Vorteilen), aber Worte im Speicher wie bei Chunks liegend (und somit auch ohne Pixelprozessor resistent gegen "Ghosting"), das beste von beiden Welten! Erlaubt 80x25 bzw 40x25 mit 8x8 Font. Wieder minus GUI Platzverlust nicht mehr 80 Zeichen breit. Wieder könnte es 6x12, aber fehlt ebenso. Keine Sprites, aber kann dies wieder mit den 4bpp kompensieren, wie BBC und CPC.

Das Bild kommt stets aus einem 32k Speicherblock (wieder verdoppelter CPC), der vom Speicher/Adressen Chip nur in 32k Schritten angeordnet werden kann, und vom System jeweils auf das je nach Speichergrösse variable Ende von diesem gesetzt wird. Damit kein byteweise scrollen durch MC6845 wie CGA oder BBC oder CPC. Auch kein pixelweise fein scrollen. Für einen derart einfachen Rechner 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 dies den Prozessor 40% der Zeit stoppen würde.

(Der Nachfahre STE (1989) erweiterte auf 4oder16 Farben aus 4096 RGB (16*16*16), konnte auch fein scrollen, und addierte einen Blitter um Pixel umzukopieren. Sowie DMA basierten PCM (Samples) Audio neben dem AY-3-8912 Soundchip.)

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

Commodore Amiga (1985)

Halb ausser Konkurrenz, weil 16bit. Trotz mit Namen Commodore eigentlich der direkte Nachfolger vom Atari 800, weil vom selbiger Designer wie 800 und VCS/2600, der nach Atari verlassen die Firma HiToro gründete, später in Amiga umbenamst, und dort den Chipsatz mit Namen Lorraine entwickelte, teils mit Finanzierung durch Atari. Nach dem Weggang von Jack Tramiel von Commodore hat er Atari aufgekauft, wonach die HiToro andere Geldquellen suchten, und dabei von Commodore aufgekaut wurden, welche Atari auszahlten. Weshalb Tramiel Technologies Limited trotz Atari aufkaufen und Atari Corp werden den Lorraine Chipsatz verloren. Wonach sie ihr eigenes bereits angefangenes "Commodore" Design als Atari ST herausbrachten, während Commodore dieses "Atari" Design als Amiga herausbrachten. Verdrehte Welt!

Ist strikte ein Atari 800 mit doppelter Speicherbreite (von 8bit auf 16bit), doppeltem Speichertakt (von 1.79MHz auf 3.57MHz), das ergibt auch vierfache Bandbreite. Kann aber mehr als vierfachen Videospeicher (von 1..8k auf 8..64k), weil keine Bandbreite mehr für Zeichencodes holen reserviert. Mit Bild aus dem normalen DRAM Hauptspeicher. Dank schnellen 256k Speicherchips kann er bis 32k ohne Prozessor bremsen, aber mehr als das geht auf Kosten vom Prozessor, alle Zeilen werden dabei zu "Badlines". Ausser es wird neben dem "ChipRAM" auch "FastRAM" addiert, also DRAM auf welches Video (und auch Audio und Floppycontroller) nicht zugreifen kann, womit das ChipRAM zu VRAM wird, wenn auch direkt vom Prozessor adressierbares. Wieder daher Featuresatz abgebaut/vereinfacht, nur noch Bitmapmodi, keine Zellmodi mehr. Dabei entfallen alle vertikalen fein scroll Effekte wegen ohne Zellmodi überflüssig geworden. Wieder ein dreier Customchipsatz, mit den Agnus (Address GeNerator UnitS) statt ANTIC, Denise (Display ENabler) statt GTIA, sowie Paula (Ports, Audio and UART) statt POKEY. Ebenfalls deswegen mit 14.31818/2=7.159MHz NTSC und 17.734472/2.5=7.039MHz PAL gebremst auf 7/8 Prozessortakt, damit auch bei 640 von 14.31818MHz bzw 14.187MHz Pixeltakt ein 44.7µs Textfeld.

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 Bitplanes statt Chunks (wie KC 85/4 2bpp und EGA und VGA 1..4bpp), mit wieder gleichem Font bei variablen bpp. Aber dadurch ebenfalls massiv anfällig auf "Ghosting", zumal ohne jegliche Synchronisierung durch einen Pixelprozessor (den die EGA hat). 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 benutzt dies nicht. All dieses gibt es auch mit Overscan bis 768x256 bzw 384x256, was obiges GUI Problem kompensieren könnte, aber auch nicht dazu genutzt wurde. Kann weiterhin doppelte Zeilenzahl mit interlaced. Alles auf einem Fernseher oder Videomonitor oder RGB Monitor. Keine mehr als 200bzw256 Zeilen, und keine Spezialmonitor Option, weil auch hier wie Atari 800 anfangs als Spielkonsole designt und dann zum Homecomputer recyclet. Hat davon fein scrollen vertikal und horiontal.

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

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

Dazu ist noch mit Dual Playfield das Bild/Spielfeld als 2*3bpp nutzbar, mit 8 Farben plus darüber noch 7 Farben (weil 0 = transparent) als ein einzelnes "Monstersprite" von ganzer Bildgrösse mit separatem horizontalen fein scrollen. Zumeist für Parallaxeffekte genutzt, tiefenabhängig scrollend, aber mit verbessertem Parallax mit zwischen Teilen der vorderen Ebene bei transparenten Pixeln durchscheinenden Teilen der hinteren Ebene. 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, und ohne Sprite Grössenlimiten der Objekte von nur im horizontalen Rücklauf laden.

32 Farben aus 4096 RGB (16*16*16), ausser Extra Half Bright (EHB) Modus mit 2*32 voll+halb, sowie Hold And Modify (HAM) Modus alle 4096 (letzteres mit 1/3 Auflösung ausser den 16 Startfarben mit voller Auflösung, aber diese auch per Copper zeilenweise anpassbar). Auflösung plus Overscan plus viele Farben plus grosse Sprites 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 der EGA ihre maximalen 4bpp), wenn auch nur wegen der Registerzahl (aber in der EGA schon wegen der Busverdrahtung).

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

Sega Mega Drive (1988) bzw Genesis (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 aber auch dem gerade voll laufenden Mega Drive abgeschossen werden. Was Sega bei den Spieleherstellern diskreditierte, und so auch 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 den 8bit Slot zu 16bit Slot "Power Base" Konverter), der bei Mega Drive Spielen zum Audio Koprozessor wird. 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 niedrige 256x(224oder240), sowie G5 bessere 320x(224oder240), aufgeteil als 32x(28oder30) sowie 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 Bandbreite. 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 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 schmales 33.5µs bzw G5 320 mittleres 41.9µs Textfeld sind. Nur vertikales Overscan.

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

Kann auch Dual Playfield, als "Monstersprites" von je 32x32 bis 128x128 Zellen zu je 8x8 (und somit 256x256 bis 1024x1024 Pixel), für Parallax mit hinterer Ebene durchscheinend oder grosse Objekte, siehe die langamer als die Plattformen scrollende Hintergrundgraphik bei Sonic.

Farben sind 4 schaltbare Sätze von 16, aber aus nur 512 RGB (8*8*8) (gleich wie ST und weniger als Amiga oder gar MCGA). Vermutlich kann der Hintergrund Zellenweise und Sprites einzeln einen Satz nehmen, aber Details sind mir unbekannt. Sicher ist, dass Sonic auf Mega Drive massiv farbiger aussieht als auf Master System, was bei beide 4bpp haben praktisch nur von mehr Farbauswahl her kommen kann, wobei Master System Hintergrund nur 2 Sätze und Sprites nur einen dieser haben konnte, und diese nur aus 64 RGB (4*4*4) kommen.

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. Viele Spiele nutzen daher 320-16=304 breit um Bandbreite 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, auch 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 320x224 4bpp Playfield braucht 35k davon).

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 reicht dann für 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. Sobald man kein Playfield mehr hat, alle Bandbreite in Sprites stecken tut, kann man auch alle einzelnen Objekte als Sprites einzeln scrollen, und damit nochmals 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 (32*32*32*2). 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, 64k, aber als je 32k davon an separaten 8bit Zellspeicher VRAM und Fontspeicher FRAM (wie Jupiter ACE) (neben auch 128k sonstiges SRAM), alles mit 8bit Speicher zur extern 8bit 65816 passend, aber wegen zwei Chips mit 2*8=16bit Bandbreite, sofern man beide mit Pipelining ausnutzen kann, was zumeist nicht der Fall ist (Zellspeicher zumeist nur Teils vom Fontspeicher).

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 seiner 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 vom Videospeicher Code sowie 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 zuwenig Leistung. Ebenso das stärkere und sauteure Parallelstück dazu Virtua Processor des Sega Mega Drive. Das weil 16bit und 3D 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 dann alleine weitermachte, war noch grenzwertiges 3D. Das auch weil sie weiterhin die niedere Famicom/NES und SuperFamicom/SNES Auflösung hatte. Erst die Playstation 2 taugte wirklich, und wurde damit prompt die erfolgreichste Konsole aller Zeiten.)

Farben sind 16 schaltbare Sätze von 4 oder 16, aus 32768 RGB (32*32*32) (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 "Badlines" 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 1+7+7=15bit 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 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 RGB 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-artigem Prozessor bremsen 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 Bandbreite 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 Bandbreitebedarf) 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, und ungebremsten Takt vom Prozessor (wenn auch 5% davon an die "Badlines" 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). 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 Zeichennummerbyte, was 2/3 statt 1/2 Bandbreite 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 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 er 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 Zeichennummerbyte, was sogar 4/5 statt 1/2 Bandbreite 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 damit wenigstens 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 ist 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 160er Pixelclocks (die 320er werden offiziell als "Halfclocks" 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 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. 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, und so nur 112 von den 128 Speicherzyklen/Zeile vom C64, mit davon wegen dem Overscan 2*48=96 statt 2*40=80 für den Hintergrund reserviert, nur 112-96=16 statt 128-80=48 im Rücklauf (wo Spritebits gelesen werden). Nach Abzug vom Speicherrefresh (beide etwa 4), sowie bis zu 6 weitere für die Displayliste reserviert (maximal Pseudomodus "1" plus Adresse plus Modus plus fakultative Adresse), verbleibt die Differenz von 8*3=24 zu 5*1=5 Spritebytes/Zeile. Da kann auch die Displayliste nichts mehr retten. Sie spart zwar selektiv RAM (und damit Bandbreite bzw Prozessorbremse) bei variabel aufwendigem Hintergrund, sowie Prozessor bei Modi im Bild umschalten bzw scrollen, aber bei Farben oder Sprites aufbessern ist sie wirkungslos, also doch wieder Software gefragt. Dabei sind Text oder Paint Programme 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 wurde hier der Hardware Aufwand und 6 Speicherzyklen/Zeile 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 ü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 mit vielen Spielen, die 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 übernamen, und Japan ohnehin noch an Spielhallenautomaten festhielt. Dann kam wegen viele Entwickler herausekeln, sowie seinen Limiten und davon eine Flut an Schrottspielen, der Nordamerikanische Videogame Crash von 1983. Europa und Japan waren davon wenig betroffen, weil bereits Homecomputer bzw noch Automaten. In Japan fing Nintendo gerade den Wechsel an, zu Konsolen, mit Erfolg, und nahm danach auch gleich die am Boden liegenden USA mit. Sega schaffte es wegen später startend anfangs nur halbwegs in Europa sowie gross in Südamerika. Erst mit der Mega Drive konnten sie ausnutzen, dass Nintendo 16bit total verschlief.)

(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 hat 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 Gütesiegel machbar gewesen wäre, ohne Gefahr von Missbrauch. Sega hat im Kontrast dazu alles erlaubt, und das Resultat auch als Coolness vermarktet, was der Mega Drive ebenfalls half (während Nintendos Ruf als Kinderspielzeug die N64 und Gamecube stark hinderte). Gefolgt von einer Kollision mit Moralwächtern welche genau missliebige Inhalte unterdrücken 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 mit vollen alles machenden 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 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. 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 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 (sowie dem kleinen 5.5k RAM im VC-20, aber mehr als die 2+2k im Famicom/NES!) massiv unterschätzt wurde, 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 und/oder 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! Mit bei 4bpp nur 4 160er Pixel in einem Bytepaar(!) ist selbst fehlendes fein scrollen durch die MC6845 Anfangsadresse modifizieren halbwegs ersetzbar. 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 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.)

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 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 (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. Die Blockgraphik liefert 16 gute Farben, aber auch 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 durfte. (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 um 64k an Speicher. Damit geht er fast bis an die Grenze von 320x200 8bpp ihren 64k. Dazu kommen jede Menge Features, von vielen Farben (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. Lediglich die Bitplanes und ihr "Ghosting" beim scrollen störten gross, hier am schlimmsten, ausser noch beim KC 85/4. Der Blitter ist eher überbewertet, zumal er nur Umkopieren beschleunigt, und das wegen Setup Aufwand sich erst bei grossen Flächen sich lohnt, wo genau "Ghosting" dann am schlimmsten wird. Der Copper ist da nützlicher, aber nicht wirklich dringlich, weil er wie die Atari 800 Displayliste letztlich nur alle Rasterinterrupt Techniken beschleunigt. Und den Prozessortakt auf 7/8 gebremst macht er 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 wegen langsamen Speicher zu bremsen. Mit dem farbigen Monitor sind seine 640x200 2bpp und 320x200 4bpp mit 32k genau ein verdoppelter Amstrad/Schneider CPC seine 16k, und damit das doppelte vom ersten Platz in der Kategorie. Sie sind sogar identisch mit einem Amiga solange man dort nicht Prozessor für mehr bpp opfert! All das aus einem sehr einfachen simplen auf billig gebauten Rechner (anfangs nur $800 mit Schwarzweiss Spezialmonitor bzw $1000 mit RGB Monitor), trotz mit 512k 4 mal soviel Speicher wie dem Mac seine 128k (anfangs $2500 trotz nur Schwarzweiss), bzw 2 mal soviel wie Amiga 256k. Das mit gleichem 8MHz Prozessor wie der Mac, aber ungebremst, und 1/8 mehr Takt als Amiga. Selbst fehlender Blitter und Copper und Sprites sind mit schnellem Prozessor und 4bpp nicht so kritisch, wie es damalige Spiele oft zeigten. Fehlende mehr als 1bpp in Schwarzweiss, nicht mal ein 320x400 2bpp, machen diesen Monitor für Spiele unattraktiv, verlangen nach Farbmonitor, nur noch 200 Zeilen (aber das hat Amiga auch). Lediglich hat er dort keine über 4bpp und 16 Farben, sowie kein Overscan, was ihn auf den zweiten Platz verweist, wenn auch erstaunlich knapp. Nur mit 8bpp addieren, trotz damit nur 160x200 haben, hätte er bereits den ersten Platz gleichauf genommen. Mit zudem fakultativ doppeltes Bild mit 40% Prozessor opfern wie Amiga, als 640x400 2bpp oder 320x400 4bpp, bzw 640x200 4bpp oder gar 320x200 8bpp Farbig, 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 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, und 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 unter dem C64!). Selbst Tastatur und Disk können ihn nicht mehr retten, zumal jahrelang keine auf dem Rechner laufende Entwicklungswerkzeuge existierten, man dazu einen separaten schweineteuren LISA benutzen musste, der Mac alleine wie bei Konsolen nur Konsum erlaubte. Erst der Mac Plus in 1986 erlaubte entwickeln, als Ersatz nachdem die LISA 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 die GUI Software für den gebremsten 16bit Prozessor zu viel, und damit schnachlangsam. Und ebenso die Fenster für bloss 9" Monitor mit 512x342 zu viel. Was alles zum Spitznamen "Mickey Mouse Rechner" führte. Die LISA war mit nur 5MHz trotz 720x360 sogar noch schlimmer. Was 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 breit sichtbar. Selbiges galt auch mit Microsoft Windows auf 16bit/286er oder gar noch 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 Ziel hatte als Forschungsrechner einem Durchschnittsrechner von +10 Jahre = 1982 zu entsprechen, und Dorado in 1980 +10= 1990. Ersterer brachte nur A4 Format Vollbild Bitmap, zweiterer erst A3 Format GUI mit Fenster und Desktop. Alle GUIs auf 1980er Rechnern waren damit 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 sein konnte. Während Apple nur knapp überlebte, und Atari sowie Commodore untergingen.)

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.04.08