Home | Artikel | VCFe Video als visuelles Medium

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


Inhalt

Einführung

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

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

Heute sind wir uns im PC Zeitalter gewohnt, dass auf einem Bildschirm beliebiges angezeigt werden kann, auch Photos oder gar Videos, egal ob mit einer Kamera aufgenommen, oder im Rechner gerendert. Dies setzt aber hohe Ansprüche wegen Bilddatenmenge an einen Rechner, sowohl was den Speicherplatz wie auch insbesondere die Speicherbandbreite anbegeht. Dies wurde erst Ende 1980er bis Anfangs 1990er generell machbar. Etwa ab der 1988er IBM VGA Karte 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, mit 80x30 Zeichen in 8x16 Font zugelassen. Ab 800x600 16bpp (braucht 960k) 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 breit ihre 640 nun auch in Fenster passen. Somit sind 320x200 bis 640x480 die untere Grenze an für beliebiges brauchbarer Auflösung.

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

Genau wie man beim Zeichnen aber wissen muss, wie man mit dessen gestalterischen Limiten und Möglichkeiten umgeht, wie man das Entscheidende trotzdem trifft, mussten auch Spielkonsolen und Homecomputer Videochip Designer dies wissen. 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 Videoausgabe als graphisches Medium geht, scheiden alle ohne eine passende Graphik komplett aus:

Es verbleiben damit vor allem farbige Homecomputer (plus ein paar Videokarten), welche interessanterweise fast alle entweder auf TTL Logik basieren, oder Videochips haben welche eigentlich für Spielkonsolen designt wurden. Daher werden auch dedizierte Spielkonsolen als solches hier addiert. Insgesammt sind es 29 Videokarten und Computer und Konsolen geworden, 22 8bit und 7 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 von 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" 64x64 bei 4bbp sind sehr geringe Auglö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 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 Videospeicher (VRAM) und DMA Logik und Videogenerator drauf. Aber nur in Schwarzweiss, was den Analogteil massiv vereinfacht, sowie wegen nur dem eigenen separaten VRAM benutzen auch die DMA Logik weit einfacher. 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 (sowie nur 1k sonstiges SRAM im einem nicht erweiterten Sol-20, weil Terminal). Ebenfalls früh erschienen, daher alles reine TTL Logik, keine Customchips, dementsprechend primitiv. Trotzdem aber mit vollen Textmodus, weil eben ein Terminal.

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

Apple II (1977), und II Plus

(Davor war der Apple 1 (1976). Dieser hatte nur Text, 40x24 Zeichen, mit Font festem ROM Satz, von 64 ASCII Zeichen. Daneben hatte es keinerlei Graphikzeichen, konnte nur ASCII Art, und scheidet damit hier aus. Zudem hatte er nur 1kx6(!)bit MOS Schieberegister als Videospeicher, war somit nicht direkt adressierbar, konnte keine bewegte Graphik, nur reine Teletype Emulation. (Dieser war wiederum eine erweiterte Variation des Don Lancaster TV Typewriter (1973), der aber nur 32x16 Zeichen hatte, mit selbigem Font ROM.) (Wer weit mehr zu Apple 1 wissen will, kann dazu meine detailierte Analyse von dessen Hardware und Software lesen.))

Der Apple II hat vor allem den Ersatz der 1kx6bit MOS Schieberegister des Apple 1 durch einen 1kx8bit Ausschnitt vom normalen DRAM Hauptspeicher. Weil Rechner und Graphik integriert sind, mit sehr einfacher DMA Logik. Ebenfalls früh erschienen, daher alles reine TTL Logik, keine Customchips, dementsprechend primitiv. Der II Plus unterscheidet sich nur in der erweiterten Software, sowie Power-On Reset Logik. Trotzdem aber umschaltbar 3 Modi, Text und Blockgraphik und Bitmap:

Dies zeigt einen besseren Ansatz, mit flexibel sein durch Modi umschalten, für entweder Font aber limitert (wie beim VDM-1 und Sol-20, oder Bitmap mit Farben aber geringe Auflösung (wie beim TV Dazzler), oder Bitmap und Auflösung mit etwas Farben aber grossem 8k statt 1k Speicherbedarf. 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ächten. Genauer meint das Handbuch dass es auch bei PAL Monitoren Farben gibt, welche aber "abweichen können" ("colors generated may differ").

(Nachfahre Apple IIe erweiterte auf Text mit 96 ASCII Zeichen. Sowie falls mit 1k Speichererweiterung "80-column" Text 80x24 und Block 80x84 "Double Low Resolution". Oder falls mit 64k Speichererweiterung "extended 80-column" sogar Bitmap 560x192 1bpp bzw 140x192 4bpp "Double High Resolution". Letzteres ist dabei noch schlimmer, 7 Pixel a bis g in 4 Bytes, als Bits 0bbbaaaa 0ddccccb 0feeeedd 0ggggfff, aber mit allen 16 Farben weil mit 4bpp nun auch "Viertelwellenpixel". Auch das strikte nur ein Signal, bei Schwarzweiss 560 Pixel, bei Farbe "verwischt" zu 140 Pixel in 560er Raster.)

Commodore PET 2001 (1977), und CBM Serie

Früh erschienen, alles reine TTL Logik, keine Customchips, und billig, dementsprechend noch primitiver. Direkt im Rechner eingebaut wie im Apple II, aber mit separatem 1k VRAM aus SRAMs wie in den VDM-1 und Sol-20, und ebenfalls einfache DMA Logik. Hat nur 1 Textmodus. Text 40x25 Zeichen (etwas mehr als beim Apple II). Mit 8x8 Font. Aus zwei festen ROM Sätzen von 128+revers Zeichen (auch wie beim VDM-1 und Sol-20). Diese haben neben 64oder96 ASCII auch 64oder32 Graphikzeichen drin. Inklusive 16 für im Font integrierte mischbare 2x2 Blockgraphik (gibt 80x50), und viele andere Graphikelemente. Die beste Pseudographik, weil auch noch einen zweiten Satz Zeichen ohne Kleinbuchstaben für mehr Elemente. Nur Schwarzweiss, auf dem eingebauten Videomonitor. Dies reicht als Terminal um Programme oder Daten einzugeben, aber auch gerade noch brauchbar für einfache Spiele, das eher von Vollbild Actionspielen mit Text irgendwo genutzt. Dies zeigt einen anderen Ansatz, ebenfalls mit Font kompakt, aber weniger limitiert wegen damit beliebig mischbaren Graphikzeichen

(CBM Serie 3000er von 1979 sind leicht überarbeitet für mehr Speicher, 16k oder 32k DRAM statt 4k oder 8k SRAM. 4000er und 8000er von 1980 haben selbigen Speicher, aber einen MOS6545 Timing Chip (eine Variante des MC6845) und grösseren Monitor. 8000er sind Modelle mit 80x25 statt allen anderen ihren 40x25.)

Tandy TRS-80 Model I (1977)

Früh erschienen, alles reine TTL Logik, keine Customchips, und billig, dementsprechend auch sehr primitiv. Hat 2 Textmodi. Text 32x16 oder 64x16 Zeichen (letzters wie bei VDM-1 und Sol-20), auch aus separatem 1k SRAM, mit einfacher DMA Logik. Mit ?x? (unbekanntem) Font (sieht auf Photos nach 6x12 aus). Aus festem ROM Satz, von 64 ASCII Zeichen. Dazu vom Bit7 gesteuert ohne Font hartverdrahtete aber mischbare 2x3 Blockgraphik (gibt 64x48 bzw 128x48). Nach manchen Aussagen auch erweiterbar auf 96 ASCII, oder gar auf 96+64+96 mit ASCII+Blockgraphik+Speziell, wobei dies allenfalls erst im Model III ist. Nur Schwarzweiss, auf dem separaten Videomonitor, bzw ab Model II eingebaut. Wie obiges reicht als Terminal um Programme oder Daten einzugeben, aber auch halbwegs brauchbar für einfache Spiele, wieder eher Vollbild Actionspiele.

Atari VCS bzw 2600 (1977)

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

Aber dies trotz extrem wenig Speicher, von nur 128 Bytes. Das Bitmap ist sogar nur 40x1(!) 1bpp, genauer sogar nur 20 Pixel/Bits an chipinternem Videospeicher von (4+8+8=20)bit in 3 Register in der TIA, welche 2mal pro Zeile ausgegeben werden, das zweite mal gerade wiederholt oder reversiert gespiegelt. 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! Dafür ist zwecks synchronisierung die aktuelle Zeilennummer auslesbar, sowie der Prozessor bis zum nächsten Zeilenanfang per Waitstates pausierbar.

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

Farben mit Register auswählbar aus 16*8=128 (16 NTSC Farbtöne "Chroma", und explizite 8 Helligkeitsstufen "Luma"), und damit eigentlich völlig überdimensioniert. Hat 2 Register für Spielfeld Vordergrund und Hintergrund, 2 für 2 Player+Missile, 1 für denn Ball, zusammen 5. Diese sind aber ebenfalls zeilenweise durch die Software überschreibbar, was die typischen "streifigen" Farben der VCS/2600 Spiele ergibt.

VCS/2600 Spiele ihre Software besteht wegen alle Zeilen gleich sein vor allem daraus, die Spielfeld Pixel sowie Player Muster und Missile/Ball Breite/Aus während dem Bild zeichnen vorzu umzuschreiben, sowie zwischen den Bildern die Joysticks bzw Paddles abzufragen und mit der Spiellogik auszuwerten inklusive Sprite Positionen setzen. Wegen dies, plus das geringe 160er Raster, verwenden viele Spiele einen "Zweizeilen" Ansatz von 100 Doppelzeilen, in welchem abechselnd das Spielfeld oder Spielobjekte ersetzt wird.

Dies zeigt einen weiteren Ansatz, Auflösung trotz fehlendem Speicher, durch horizontale Auflösung mit Sprites verbessern und vertikale Auflösung in Software implementieren, sowie viele Farben trotz nur 1bpp (plus Sprites) mit Farbregister übersetzen. Es ist damit brauchbar für Spiele, aber total unbauchbar als Terminal, kann nur anderstwo entwickelte Spiele ablaufen lassen.

Atari 800 (1979)

Anfangs als Spielkonsole designt, als "etwa verdoppelten" Nachfolger der VCS/2600, weil dieser wegen primitiv sein zurecht auf nur 3 Jahre benutzbar angenommen wurde. 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). Dann doch noch 1982 als Konsole 5200, aber nicht zu den 400 und 800 kompatibel (und auch nicht zum VCS/2600). Dann 1983 verbilligt zu 800XL (und Subset 600XL). Zum Schluss noch 1985 umgestylet als 65XE (und 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 Atari bei den Spieleherstellern endgültig 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 erachtete Spieledesigner als etwa gleich unwichtig wie davor Handtuchmusterdesigner. 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 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 überhypeten Spielen. Nicht verwunderlich führte dies zusammen mit den Limiten der VCS/2600 zu einer Flut von Schrottspielen, und zusammen mit dessen Marktdominanz zum Vertrauenszusammenbruch der Käufer, gefolgt vom Nordamerikanischen Videogame Crash von 1983. Dabei verlor Atari massiv, was dann zu obigem Firmenaufkauf führte, gefolgt vom Verlust der 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 Sound plus UART), alle 3er Chipsatz zusammen die kleinere TIA im VCS/2600 ersetzend, und damit weit mehr leistend. Umschaltbar (wie beim Apple II), aber hier massive 8 Bitmapmodi und 6 Zellmodi:

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

Bei 320*1 oder 160*2 oder 80*4 oder 40*8 von 14.31818/2=7.16MHz Pixel ein 44.7µs breites Textfeld (Narrow 256 mal ein 35.8µs schmales, Overscan 384 mal ein 53.6µs überbreites). Trotz 1bpp hat Modus "F" aber nur "1.5" statt 2 Farben, genauer einen "Chroma" Farbton in 2 "Luma" Helligkeitsstufen. Diesen mit Farben auf Schwarz und Weiss (also Chroma Grau mit Luma 0% bzw 100%) gestellt, plus dem 7.16MHz Pixeltakt, erzeugt auf NTSC Farbmonitor 4 Farben wie beim Apple II, in dessen Sw+Bl+Or+Ws Farbsatz. Das versagt 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 Farben abgestuft:

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

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

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

Farben wieder mit Register auswählbar aus 16*8=128 (16 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 bei der VCS/2600, weshalb dessen "streifigen" Farben blieben oder wegen Aufwand verschwanden.

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

Texas Instruments TMS9918 VDC Chip (1979)

Kein Rechner oder Spielkonsole, sondern 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 in TI-99/4 (originale TMS9918) von 1979, sowie TI-99/4A (erweiterte TMS9918A) von 1981. Ebenso Coleco ColecoVision von 1982 (Konsole) und Adam von 1983 (Homecomputer). Ebenso Sega SG-1000 (Konsole) und SC-3000 (Homecomputer) von 1983. Am bekanntesten aber ebenfalls im Spectravideo SV328 und in all den davon abgeleiteten MSX 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 im Atari 800 den ganzen Prozessortakt auf 7/8 bremsend. Aber mangels Pins hat es keine Adressierung der 16k vom Prozessor, braucht so eigene Adressregister im VDC, mit diese laden umständlich und langsam. Dies verhindert 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, addiert sich zu diesem. (All dies gilt auch für die in der Einleitung erwähnten µPD7220 und EF93xx Chips.)

Umschaltbar 2 Zell und 1 Blockgraphik und 1 Bitmap Modi:

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

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

(Die Yamaha V9938 und V9958 VDP (Video Display Processor) von 1985 bzw 1988, in den MSX 2 bzw MSX 2+, erweitern 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, 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 mit 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, erst die V9958 auch horizontal. Beide erlauben bei G4 bis G7 auch vertikalen Overscan, mit 212 statt 192 Zeilen, sowie interlaced auf 2*192=384 bzw 2*212=424. Beide erlauben bei G3 (G2 mit dies addiert) sowie G4 bis G7 (stets) neben 1bpp auch 2/3/4bpp Sprites, mit 8 sichtbaren von 32 angemeldeten. Ebenso haben sie statt 15 NTSC Farben volle 16 aus 512 RGB Farben (ausser G7 mit 8bpp fest 3R3G2B oder V9958 YJK bzw YJK+YAE).)

(Das 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). Es bringt einen einzelnen weiteren G4 Zellmodus von 32x24 Zeichen. Mit 8x8 4bpp(!) Font. Daher Vordergrund und Hintergrund Farbwahl direkt aus dem Font heraus, keine 1bpp mit danach separaten 2*4bit Farbattributen per G2 Zellgruppen oder G3 Pixelzeilen. Das verliert aber die Möglichkeit die Zellenmuster mit mehreren Farben zu kombinieren, selbiges Muster anderst eingefärbt braucht daher ein weiteres Zeichen. Hat einen variablem RAM Satz, aber von 448 Zeichen (bzw strikte 512, aber davon 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 sichtbaren von 64 angemeldeten. Ebenso hat es statt 15 NTSC Farben sogar volle 32 (16 Zellen und 16 Sprites), aber aus nur 64 RGB Farben.)

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

Kein Rechner oder Spielkonsole, sondern generischer Videochip, in diversen Geräten verwendet. Darunter TRS-80 CoCo und Acorn Atom und Dragon 32/64, sowie dem oben erwähnten NEC PC-6001, aber auch viele Hongkong Rechner wie dem Laser 200. Nach dem MC6840 DMA Chip, und darauf aufbauend dem MC6845 Video Timer+DMA, ist der MC6847 VDG (Video Display Generator) ein einzelner Chip für ganzes Video, bzw zwei wenn mit dem MC6883 SAM (Synchronous Address Multiplexer) zusammen verwendet. Mit Bild aus dem normalen DRAM Hauptspeicher. Wie beim Atari 800 den Prozessortakt auf 7/8 bremsend. Umschaltbar 1 Text und 2 Blockgraphik und 8 Bitmapmodi:

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

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

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

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

Dazu 1kx4bit FarbRAM (und somit strikte 5+0.5=5.5kBytes Speicher im VC-20) mit Vordergrund Farbattribut. Jedes Zeichen hat eigenes von 16 NTSC Farben, diese Farbton+Helligkeit Kombinationen, ohne separate Helligkeitsstufen, mit dazu die identischen unteren Adressbits A0..A9 nutzend, womit dies strike ein 8+4=12bit Videochip ist! Das erlaubt 256 Font mit 16 Farben zu kombinieren, ohne dem Atari 800 seine nur 64 Font bei 4+1 Farben, oder der TMS9918 seine 256 Font mit 2*16 Farben aber massiver Bandbreite. Wovon sowohl farige Textausgabe wie auch Spiel massiv profitierten.

Auch kein Prozessortakt auf 7/8 bremsen, weil bei diesen breiten Pixeln der NTSC Farbmonitor 4 Farben Effekt nicht entsteht, selbst mit beliebigen Farben, weil nur 160 Pixel und 6von8Pixel breite Zeichen mit 2Pixel breiten Vertikalen es verhindert. Die aktuelle Zeilennummer ist auslesbar, aber kein Interrupt davon. Kein Bitmap. Kein fein scrollen. Keine Sprites, aber die 2bpp kompensieren dies teilweise. Wie bei der TIA im VCS/2600 auch Sound und Paddles im selbigen Chip. Nur die sehr niedere horizontale Auflösung ist ein massiver Schwachpunkt. Alleine diese verdoppeln und dies wäre ein sehr guter Chip.

Sinclair ZX80 (1980), und ZX81 (1981)

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

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

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

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

IBM Monochrome Display Adapter MDA (1981)

Kein Rechner, sondern eine Karte für den IBM PC Bus. Nur 1 Textmodus. Text 80x25. Mit 9x14 1bpp Font. Aus festem ROM Satz, von 256 Zeichen. Braucht dazu einen separaten MDA Spezialmonitor der die resultierenden 720x350 anzeigen kann. Keinerlei Graphik ausser Graphikzeichen, darunter 1x2 und 2x1 Blockgraphik aber kein 2x2 (gibt also doch nur maximal 80x50, bzw 160x25). Aber mit 8bit Attributen (Hintergrund und Vordergrund je 3 Helligkeitsstufen und weiteres Unterstreichen Attribut). Wegen Karte mit separatem 4k VRAM aus SRAMs (wie bei TMS9918), daher auch asynchron und nicht Prozessor bremsend. Aber mit Adressen vom Prozessor, mit dessen Adressmodi ausnutzend (ungleich TMS9918, als entscheidender Vorteil). Für Timing und Adressen MC6845 Chip, Datenpfad TTL, keine Customchips, daher auch halb-primitiv.

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 im TMS9918), daher auch asynchron und nicht Prozessor bremsend. Aber mit Adressen vom Prozessor, mit dessen Adressmodi ausnutzend (ungleich TMS9918, als entscheidender Vorteil). Kann wegen verschiedenem Adressbereich zusammen mit einer MDA im gleichen Rechner sein, für Dualhead mit Text+Graphik. Für Timing und Adressen MC6845 Chip, Datenpfad TTL, keine Customchips, daher auch halb-primitiv.

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

Kein fein scrollen, ausser byteweise durch MC6845 Anfangsadressen schieben. Keine Sprites. 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. Nicht einmal ein Attributbit benutzen für ohne Font hartverdrahtete aber mischbare 2x4 Blockgraphik geht. Egal was man hier versucht, es fehlt stets genau das was gute Spiele erlaubt.

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

Acorn BBC Micro (1981)

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

Farben 2/4/16, von 8 RGB. Mit 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 durch MC6845 Anfangsadressen. Keine Textmodi, weil inzwischen genug Speicher um auch bei Bitmap genug Text darzustellen, und damit auch soviel Graphik ohne Zellmodus seine Limiten in der Anordnung. Damit ist dies ein total moderner Rechner, mit 8 bis 20k Speicher, 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 Shifter 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) und CGA (Graphik und Farben aber niedere Auflösung) Karten. Wiederverwendet den MDA Spezialmonitor. 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 DRAM Speicher (wie im TMS9918), daher auch asynchron und nicht Prozessor bremsend. Aber mit Adressen vom Prozessor, mit dessen Adressmodi ausnutzend (ungleich TMS9918, als entscheidender Vorteil). Verwendet den MDA Adressbereich, kann daher mit einer CGA im gleichen Rechner sein, aber 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, weil er intern wegen der MC6845 ihre Limiten auf max 128 Zeichen vertikal als 87 Zeichen zu je 4 Zeilen Höhe definiert ist (die CGA Bitmapmodi sind auch als 100 Zeichen zu je 2 Zeilen Höhe definiert).

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

Anfangs auch als Spielkonsole Max-Machine (bzw Ultimax oder VIC-10) mit nur 2k SRAM Speicher designt, aber dann als Nachfolger vom VC-20 mit 64k DRAM verkauft. Einzelner Chip VIC-II (Video Interface Chip II), als erweiterten VIC vom VC-20. Daher ebenfalls ein generischer Videochip, wenn auch wieder nur von Commodore genutzt. Mit Bild aus dem normalen DRAM Hauptspeicher. Hat fast alle guten vom VIC Eigenschaften geerbt, aber alle Schwächen abgelegt. Zudem kamen weitere nette Sachen dazu. Die Designer hatten explizit Features anderer Chips und Rechner verglichen, und daraus ihre Wunschliste erzeugt. Die Sprites wurden explizit wegen der TMS9918 addiert, und daher auch so benamst. Später erweitert auf 128k als Commodore 128 (mit einem VIC-II E, sowie zusätzlichem VDC Chip, dieser wie bei TMS9918 mit eigenem 16k oder 64k Speicher asynchron vom Prozessor mit eigenen Adressregistern).

Umschaltbar 3 Zellmodi und 2 Bitmapmodi:

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 beim 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 einem 6von8Pixel breite Zeichen mit 2Pixel breiten Vertikalen Font 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 den als 14.31818/14=1.0227MHz nimmt.)

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

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

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

Farben mit Register auswählbar aus 16 festen NTSC Farbton+Helligkeit Kombinationen (vermutlich 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. Wie man sieht ist dies ein mengenmässig sehr leistungsfähiger Chip, trotz strukturell weit einfacher zu sein als beim Atari 800. Er wurde damit zum idealen Kompromiss.

Sinclair ZX Spectrum (1982)

Nachfolger der ZX80 und ZX81. Wie bei der ZX81 alles in einem ULA (Uncommitted Logic Array) Gate Array Semicustomchip, auch dessen Video. Daher halb-primitiv. Mit Bild aus dem normalen DRAM Hauptspeicher. Nur 1 Bitmapmodus, da ausreichend Bitmap Speicher jetzt billiger ist als Text oder Zell Logik.

Bitmap 256x192 1bpp in 6kByte (wie beim TMS9918A "2" ("Graphic 2")). Farben 16 RGBI (bzw hier als IGRB angeordnet), wobei Vordergrund und Hintergrund eigene RGB haben (in Attributbits 0..2 bzw 3..5) aber gemeinsames I (in Bit 6). Dazu noch blinkend (wie bei der CGA wenn Hintergrund Intensität zu Blinken umgeschaltet wird) (in Bit 7). Aber mit Farbattribute nur alle 8x8 Pixel (wie beim C64), aber ohne dem C64 sein "Multicolor" 2bpp 4 Farben Modus, was oft in "Attribute Clash" resultierte, wenn in einem 8x8 Feld mehr als 2 Farben gebraucht werden (was beim TMS9918 wegen dessen kleinerem 8x1 Feld weit weniger zutraf, und dort als "Color Spill" bekannt ist). Dazu noch separates RGB ohne I Register für den Rand. Erlaubt daher auch 32x24 Zeichen mit 8x8 Font. Kein fein scrollen. Keine Sprites.

(Mit Softwaretechniken ähnlich denen der VCS/2600, welche hier die Farbattribute von Zeile zu Zeile überschreiben, können diese auf 8x2 Pixel für ganzens Bild oder sogar 8x1 für halbens Bild verfeinert werden.)

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

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

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

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

Dies erlaubt zwar 2*3+2=8 (in Bitmapmodus) bzw +3=11 (in Zellmodus) Bits an Attributen, ohne dafür separaten Speicher zu verbrauchen, 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 bzw 6x8 Feld gebraucht werden, sondern bereits wenn solche in direkten Nachbarfeldern ohne ein "leeres" (= alles Hintergrund) Feld dazwischen kommen. Ein sehr seltsames Design.

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

Als Famicom hauptsächlich als Spielkonsole designt. Aber erweiterbar mit Tastatur (und anderem) an Erweiterungsport, sowie mit DiskSystem (1986) mit Floppylaufwerk als Untersatz sowie BootROM plus ErweiterungsRAM plus Controller im Modulport zu einem vollen Homecomputer (im Gegensatz zu Sega ihren separaten SG-1000 und SC-3000 Modellen). Aber beim Export mechanisch umgebaut und funktionell reduziert zum Nintendo Entertainment System (NES), ohne Tastatur oder DiskSystem, nur noch reine Spielkonsole, und dabei nicht mal das Modulformat kompatibel. 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). Sowie zweiter mit APU (Audio Processing Unit), plus Joypad Interface, plus "DMA" Blockkopierer, alle im Custom Prozessorchip 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 mit RAM neben dem Programm und Font ROMs in Modulen 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. Stoppt den Prozessor bei Videozugriffen während der ganzen Bildausgabe komplett (kein schneller Speicher wie bei der TMS9918, trotz SRAM). Man kann so nur während dem vertikalen Bildrücklauf zeichnen. Ebenso wird der Prozessor beim Blockkopierer benutzen gestoppt.

Hat nur 1 Zellmodus, kein Bitmap, mangels Speicherplatz. Zellmodus hat nur 32x30 Zeichen, und das bereits inklusive dem Overscan. Was wegen der sehr niedrigen 5.35MHz Pixelrate ist, und damit bei 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 eher 44 bzw gar 48 entsprechen würden, weshalb hier real nur 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 8x8 2bpp Font, was mit 32x30 Zeichen sehr detailierte 256x240 Pixel gibt, trotz 4-farbig, ohne dafür auf 4x8 Font die Pixel halbieren zu mössen (wie bei Atari 800 oder C64 von 320x192oder200 zu 160x192oder200). Limitiert aber Text auf obige 24..28 Zellen (im Gegensatz zu Atari und Commodore, mit entweder 40 Zeichen in grobem 4x8 Font oder 20 Zeichen in normalem 8x8 Font). Aus VRAM/ModulROM/ModulRAM Satz, von 256 Zeichen, Format ist pro Zeichen 8+8=16 Bytes, zuerst 8 Bytes alle Bit0 dann 8 Bytes alle Bit1 (Atari 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 erweiterte Module 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 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). Alle entweder 8x8 oder 8x16 (wie bei der TMS9918 nur ein global wirkendes Flag). Stets automatisch geladen, aber 8 sichtbaren von 64 angemeldeten (somit gleiche maximale Pixelmenge wie die TMS9918, aber wegen 2bpp doppelte Datenmenge).

Farben mit Register auswählbar aus 64 (12 NTSC Farbtöne in 4 Helligkeiten, plus Graustufen). Hat 1 Register für Hintergrund (es hat keinen Rand!), 4 Sätze von 3 für Bild/Spielfeld Vordergrund, und 4 Sätze von 3 für Sprites, zusammen 25. Jeweils 2x2 Zellen (also 16x16 Pixel!) haben ein 2bit FarbRAM 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 FarbRAM Attribut, um 1 der 4 anderen Sätze von 3 zu benutzen. Wie man sieht ist dies ein mengenmässig graphisch sehr leistungsfähiger Chip, gerade auch mit den 2bpp und 3 zellweise variablen Farben, aber textuell sehr gering, trotz immer im Zellmodus laufend!

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

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

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

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

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

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

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

Farben 2/4/16, aus 27 RGB. Dabei haben alle RGB je 3 Stufen, was sowohl halb/voll intensiv aber auch mit stets voll intensiv plus halb bei anderen Komponenten besseres Pastell erlaubt. Auf mitgeliefertem RGB Monitor (zugleich Netzteil vom Rechner). Kein fein scrollen, wieder ausser byteweise durch MC6845 Anfangsadressen schieben. Keine Textmodi, weil inzwischen genug Speicher um auch bei Bitmap genug Text darzustellen, und damit auch soviel Graphik ohne Zellmodus seine Limiten in der Anordnung. Damit ein ist dies ebenfalls ein total moderner Rechner, mit stets 16k Speicher, 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 Shifter 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 noch mit 27 statt 8 RGB Farben erweitert!

(Die 464plus und 6128plus von 1990 addierten 32 von 4096 RGB Farben, und fein scrollen, sowie Sprites.)

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

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

Nur 1 Bitmapmodus (wie beim ZX Spectrum, weil auch in der DDR inzwischen DRAM billiger ist als TTL Logik). Wie bei der CGA eigener 16k Videospeicher, vom Hauptspeicher abgetrennt, aber vom Prozessor adressiert. Bitmap 320x256 1bpp (256 weil nur 50Hz Moni wie beim BBC, mehr als dem C64 seine 320x200), für alle 8x4 Pixel 2 Farben aus 16 (mehr als ZX Spectrum alle 8x8, aber weniger als TMS9918 alle 8x1, so immer noch auf "Attribute Clash" halb anfällig). Erlaubt daher sogar 40x30(von32) Zeichen, bei 8x8 Font. Mit so 10k Bitmap plus 2.5k Farbattributen (plus 1.25k Zeichennummern), ist er trotz keine Modi Umschalten besser als die 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, und wurde auch bei auf die KC 85-4 erweitern mit 1.77MHz nicht korrigiert.

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

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

Apple Macintosh (1984)

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

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

IBM Enhanced Graphics Adapter EGA (1984)

Ganz ausser Konkurrenz, weil aus gigantischem 4*64=256k (und damit 32bit breitem!) Speicher laufend. Hier nur als Beispiel, was man damals schon mit viel Masse machen konnte. Kein Rechner, sondern eine Karte für IBM PC Bus, und damit auch für 16/8bit 8088 PC/XT, nicht nur 16bit 286 PC/AT sein ISA Bus. Daher wie die CGA mit eigenem Speicher und asynchron und nicht Prozessor bremsend. Aber ebenfalls mit Adressen vom Prozessor mit dessen Adressmodi ausnutzend. Aber nur 1*64k Adressraum davon nehmend, weil die 256kBytes als 64kWorte von 32bit verwertet werden! Verwendet seinen eigenen Adressbereich, kann daher mit einer MDA oder HGC im gleichen Rechner sein, aber trotz eigenem nicht mit einer CGA, weil der Registerbereich kollidiert, und auch der Adressbereich falls im CGA kompatiblen Modus laufend. Als zwei Gate Array Semicustomchips gebaut, die eine einen erweiterten MC6845, die andere den Datenpfad. Dies weil IBM grosse Gate Arrays verwendet hat, wie sie auch in Grossrechner Prozessoren verbaut werden, weshalb IBM solche Chips selber herstellen kann.

Zellmodus statt Textmodus, zu 80x25 Zeichen CGA kompatibel. Aber mit neu 8x14 1bpp Font (fast wie die MDA und HGC ihre 9x14). Braucht dazu einen separaten EGA Spezialmonitor, analog zu bei MDA und HGC und Macintosh. Aus RAM Satz, von 256 Zeichen (strikte schaltbar mit Attributbit3 zu 2 mal 256 wählbar, mit dann aber nur noch je 8 Farben). Zudem 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 beim KC 85-4), mit gleichem Font bei variablen bpp Vorteil, aber ohne "Ghosting" weil mit einem aufwendigen 8zu(1..4*8)=32bit Pixelprozessor die Planes synchron bewegbar sind (neben auch Bewegung beschleunigend und den Adressraum auf die 64kWorte erweiternd). Davon 4*28k nutzend (oder einen solchen Ausschnitt aus bis zu 4*64k Bild).

Mit 16 Farben aus 64 RGB (4*4*4), was auch bei CGA kompatigel gilt, dessen 16 feste Farben ersetzend. Ebenso wurde ein Vertical Blank Interrupt (VBI) addiert.

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

(Noch mehr ausser Konkurrenz ist die davon erweiterte 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. Zudem 80x50, mit (8+1=9)x8 Font. Bitmap addierte als Multi-Color Graphics Array MCGA Modus genau obige 320x200 8bpp (mit Chunks statt Bitplanes), sowie offiziell 640x480 4bpp (mit Bitplanes), aber kein 640x400 8bpp trotz dass dies in die 256k passen würde. Mit 256 bzw 16 Farben aus 262144 RGB (64*64*64). Erlaubt 80x30 mit 8x16 1bpp 100dpi Font, sowie 80x40 mit 8x12, sowie 80x60 mit 8x8. Wieder nur mit externem VGA oder Multisync Spezialmonitor, dem ersten mit HD15 VGA Stecker.)

(Wieder gingen 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 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 je 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 800x600 3*5=15bpp mit direkten 32k RGB (32*32*32) Farben. Von hier stammen alle modernen PC Karten ab, dabei die Inkompatibilitäten immer schlimmer werdend.)

Atari ST (1985)

Halb ausser Konkurrenz, weil 16bit. Einfacher geradliniger Rechner, der in unter 1 Jahr von Entwurf bis in den Verkauf sein ging! Eigentlich von Tramiel Corp, 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 von den TED basierten Rechnern, zumal er wie diese keine Sprites hat, und auch keine der VIC/VIC-II Designer beteiligt waren.

Ist strikte ein C64, bzw eher C16,C116,Plus/4, mit doppelter Speicherbreite (von 8bit auf 16bit), doppeltem Speichertakt (von 2MHz bzw 1.79MHz auf 4MHz), gibt vierfache Bandbreite. Benutzt vierfachen Videospeicher (von 8+1=9k auf 32k). Mit Bild aus dem normalen DRAM Hauptspeicher. Mit daher den Featuresatz abgebaut/vereinfacht, nur noch Bitmapmodi, keine Zellmodi mehr, und auch keine Sprites (damit sogar unter dem TED). Auf zwei Customchips basiert, Speicher/Adressen Controller/Generator, und Daten/Pixel Chip ("Shifter"). Nicht gebremst, volle 16MHz Pixel. Umschaltbar 3 Bitmapbodi, aber welche benutzbar sind ist abhängig vom Monitortyp:

Mit dem Schwarzweiss Spezialmonitor ist stets 640x400 1bpp (1/3 mehr als beim Macintosh 512x384 seinen 24k, und vergleichber mit HGC 720x348, beide 32k). Wieder nicht mal 2bpp Graustufen, trotz dass die Hardware eigentlich 2bpp kann, also ist wieder rastern angesagt. Auch mit 0=weiss und 1=schwarz. Erlaubt 80x25 Zeichen bei 8x16 1bpp 100dpi Font, oder 80x50 Zeichen mit 8x8. Minus GUI Platzverlust erlaubt dies aber nicht mehr 80 Zeichen breite Platz! Die Hardware könnte auch 6x12 Font und so 106x33 Zeichen, aber die Systemsoftware hat keinen solchen drin.

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 (oder auch 4bpp Grau), mit 4oder16 Farben aus 4096 RGB (16*16*16) (und ist damit genau ein in bpp verdoppelter CPC). 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 dies fehlt. Keine Sprites (aber dies kompensiert mit den 4bpp, wie beim BBC und CPC).

Kein fein scrollen. Das Bild kommt stets aus einem 32k Speicherblock (wieder verdoppelter CPC), der soweit mir bekannt 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. 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 diese den Prozessor 40% der Zeit stoppen würden.

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

Commodore Amiga (1985)

Halb ausser Konkurrenz, weil 16bit. Trotz mit Namen Commodore eigentlich der direkte Nachfolger vom Atari 800, weil vom selbiger Designer wie die 800 und VCS/2600, der nach Atari verlassen die Firma HiToro gründete, mit Finanzierung durch Atari. Diese wurde aber nach Weggang von Jack Tramiel von Commodore aufgekauft, und Atari ausgezahlt. Weshalb Tramiel Corp trotz Atari aufkaufen ihr eigenes Design dann als Atari ST herausbrachten.

Ist strikte ein Atari 800 mit doppelter Speicherbreite (von 8bit auf 16bit), doppeltem Speichertakt (von 1.79MHz auf 3.57MHz), gibt auch vierfache Bandbreite. Kann aber mehr als vierfachen Videospeicher (von 1..8k auf 8..64k). Mit Bild aus dem normalen DRAM Hauptspeicher. Aber mehr als 32k geht auf Kosten vom Prozessor bremsen, ausser es wird neben dem "ChipRAM" auch "FastRAM" addiert, also DRAM auf dem der Videochip (und auch der Soundchip und der Floppycontroller) nicht zugreifen kann, womit das ChipRAM zu VRAM wird, wenn auch direkt vom Prozessor adressierbares. Wieder daher den Featuresatz abgebaut/vereinfacht, nur noch Bitmapmodi, keine Zellmodi mehr, aber hat Sprites. Dabei entfallen alle vertikalen fein scroll Effekte wegen ohne Zellmodi überflüssig geworden. Daher auch 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 Pixel 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 (wie in der EGA). Erlaubt 80x(25oder30) bzw 40x(25oder30) Zeichen bei 8x8 Font. Minus GUI Platzverlust ebenfalls nicht mehr 80 Zeichen breit Platz. Hardware könnte auch 6x12, aber System benutzt dies nicht. All dieses gibt es auch mit Overscan bis 768x256 bzw 384x256, was obiges GUI Problem kompensieren könnte, aber auch nicht genutzt wurde. Kann weiterhin doppelte Zeilenzahl mit interlaced. Alles auf einem Fernseher oder Videomonitor oder RGB Monitor. Keine mehr als 200bzw256 Zeilen, und keine Spezialmonitor Option, weil auch hier wie beim Atari 800 anfangs als Spielkonsole designt und dann zum Homecomputer recyclet. Hat 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 in 160ern gemessen). Diese sind Paarweise zusammensetzbar zu 4bpp, das ergibt 2bpp Chunks kombiniert zu 2*2bpp als Bitplanes. In der Höhe sind die beliebig bis ganzes Bild einstellbar, wie es der Atari 800 stets hatte, aber auch auf weniger reduzierbar um Speicher zu sparen. Wie im Atari 800 und C64 hat es keine Prioritätslogik (wie es in der TMS9918 oder der Famicom/NES eine hat), 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 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 "Monstersprite" von ganzer Bildgrösse mit separatem horizontalen fein scrollen. Zumeist für Parallaxeffekte genutzt, tiefenabhängig scrollend, aber mit zwischen Teilen der vorderen Ebene bei transparent durchscheinenden Teile der hinteren Ebene.

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 und Parallax gaben ihm zurecht seinen Ruf als das Graphikwunder schlechthin. Wieder zum Preis von einem massiv komplexen Chipsatz sein. Auch hier kann man nur noch ein 320x200 8bpp vermissen, weil die Bitplanes auf 6bpp limitiert sind (analog zu der EGA ihre maximalen 4bpp), wenn auch nur wegen der Registerzahl (aber in der EGA schon wegen der Busverdrahtung).

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

Sega Mega Drive (1988), bzw Genesis (1989)

Halb ausser Konkurrenz, weil 16bit. Im Gegensatz zum erst nach der Famicom/NES weit 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. Dieser Vorteil wurde aber danach wieder komplett verscherzt, weil Sega Japan und Sega USA sich einen internen Machtkampf lieferten, mit dabei sich gegenseitig Information vorenthalten. Also kamen inkompatible 32bit Mega Drive Erweiterung 32X (USA) und 32bit Saturn (Japan) kurz nacheinander heraus, gefolgt von 32X und Mega Drive abgeschossen werden, was Sega bei den Spieleherstellern endgültig diskreditierte, und so auch 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 im Master System. Dieser ist zum Master System seinem erweitertem G4 Modus kompatibel, und hat einen weiteren neuen Modus G5, aber nicht mehr die normalen TMS9918 Modi 0 bis 3. Hat wegen kompatibel sein neben der 68000 auch dem Master System seine Z80, der bei Mega Drive Spielen zum Soundkoprozessor wird. Benutzt wie das Master System separates VRAM, 64k SRAM davon (neben auch 64k sonstiges SRAM, und 8k Z80 SRAM).

Hat nur 2 Zellmodi G4 und G5. Hat keine Bitmap Modi, trotz mit 64k VRAM eigentlich genug Speicherplatz dafür. Im G4 niedrige 256x(224oder240), sowie G5 bessere 320x(224oder240), bzw 32x(28oder30) sowie 40x(28oder30) von 8x8 Zellen, wie G4 auch 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 sie 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 sichtbaren von 80 angemeldeten (mehr als der Amiga, und sowieso mehr als ST und MCGA ihre gar keinen).

Kann auch Dual Playfield, als "Monstersprites" von je 32x32 bis 128x128 Zellen zu je 8x8 (und somit 256x256 bis 1024x1024 Pixel), für Parallax mit hinterer Ebene durchscheinend.

Farben sind 4 schaltbare Sätze von 16, aber aus nur 512 RGB (8*8*8) (weniger als ST oder 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, wo Hintergrund nur 2 Sätze und Sprites nur einen dieser haben kann, und sie 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 die Mega Drive neben einer 68000 auch eine Z80 drin, stets als Soundkoprozessor benutzt. Benutzt ein separates VRAM von 64k SRAM, plus ein "Fast VRAM" von 4k (neben auch 64k sonstiges SRAM, und 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 weder Zellmodi noch 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 Pixel 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. Damit sind es gröbere Pixel als bei Master System und Mega Drive, aber 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 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 "angehängt" werden, und so mit nur dem ersten Sprite einer Gruppe positionieren zusammen bewegt werden, was auch breitere Sprites komfortabel erlaubt.

Damit kann man auch einen normalen Hintergrund mit Bitmapmodus simulieren, mit 320/16=20 auf 16x224 gesetzte Sprites gruppieren. Dann kann man einen Font darin rendern wie bei BBC und CPC sowie ST und Amiga, Dazu muss das Modul aber neben Programm und Font ROMs auch VRAM mitbringen (es hat wie die 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 sind 35k).

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 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 moderner als die Mega Drive.

Insgesammt können 380(!) Sprites angemeldet sein, von denen bis zu 96 auf einer Zeile dargestellt werden können, da kein Playfield etwa 3/4 der Zeit/Bandbreite wegnimmt. Das reicht um bis zu 4 Playfields mit Sprites 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 reichen für 10 Bänder zu 20). Was automatisch 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 Sprites und einem mit nur ein 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 diese mit wenigen Sprites problemlos machbar wären.

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 Super NES (1991)

Halb ausser Konkurrenz, weil 16bit. Naja, mit anstelle einer 68000 wie in allen anderen 16bit, strikte nur einer 16/8bit 65816, 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 die Famicom/NES ebenfalls separates VRAM, 2*32k=64k (als je 32k an Videospeicher und Fontspeicher SRAM) davon (neben auch 128k sonstiges SRAM), alles 8bit Speicher zur extern 8bit 65816 passend.

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

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

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

Dazu ist noch mit 1 bis 4 Layern der Hintergrund zusammengesetzt aus "Monstersprites" von je 32x32 bis 128x128 Zellen zu je 8x8 (und somit 256x256 bis 1024x1024 Pixel). Dies ist ebenfalls besser als Dual Playfield um Mehrfachparallax zu haben, mit maximal 3 Ebenen durchscheinend. 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 beim Amiga der Copper.

Hat primitive pseudo-3D Transformationen auf dem Hintergrund, mit Mode 7. Dieser ist stets 8bpp, was zusammen mit den 2 separaten 32kx8bit SRAMs als Videospeicher und Fontspeicher in 1FontZugriff=1Byte=1Pixel resultiert. Mode 7 tut dann nur noch die vom Videospeicher her zusammengesetzen Fontspeicher Adressen transformieren, statt 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. Die Sprites bleiben aber 2D, mit jeglichen 3D Effekten nur durch separate Zeichen im Font durchgehen, wie bei allen anderen Rechnern.

Farben sind 16 schaltbare Sätze von 4 oder 16, aus 32768 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 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, ZX80 und ZX81, sowie die Famicom/NES.

Die 16bit schlagen hier zu, dank mehr Speicher und Bandbreite. Am besten mit 640x400 der ST als doppelte 640x200 aus 32k. Weniger mit 512x384 der Macintosh als doppelte 512x192 aus 24k. 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. EGA liefert dazwischen 640x350 (Breite von ST, Höhe von Macintosh), auch mit einem EGA Spezialmonitor, aber dafür in Farbe. Die bereits beim BBC und CPC gesehenen 640x256 bzw 640x200 auf einem Fernseher oder Videomonitor oder RGB Monitor kann der Amiga (und ebenso deren Speicher sparenden 320x256 bzw 320x200) (sowie plus Overscan wie beim Atari 800), dafür kann er doppelte Zeilen nur mit interlaced statt Spezialmonitor. Auscheiden tun sicher die Mega Drive und SuperFamicom/SNES, wegen trotz 16bit keine Bitmaps. Erst recht die Neo Geo, ohne einen Bildhintergrund!

Die Farbauswahl dabei kann sehr verschieden sein. Schlimmstenfalls ist nur ein Schwarzweiss Monitor vorhanden, beim Macintosch, sowie dem ST für 1bpp, sowie beim Apple II (wenn Schwarzweiss weil 280x192 oder 560x280 gewollt ist). Wenig besser kann man die Stiftfarbe umschalten, weiss oder grün bei den MC6847. Etwas besser lässt sich die Stiftfarbe beliebig einstellen, aus 16 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 4096 beim ST, 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 beim C64, sowie vermutlich im ZX Spectrum. Was auch ein Grund ist nur 8x8 Zellen zu benutzen, weil das die Ausblockzeit auf nur jede achte Zeile reduzieren kann, beim 64er als "Badlines" bezeichnet, oder beim TED sogar 2 von 8 wegen 2*7bit Farben.

Oder man akzeptiert mehr Prozessor ausblocken. Zumindest der ZX Spectrum nutzt obiges einmalige Laden nicht aus, holt bei allen 8 Zeilen wiederholt. Selbiges auch die KC 85 Serie. Die 8x4 von 85-2 und 85-3 sind nur durch den 16k Videospeicher limitiert, die 8x1 vom 85-4 werden dann erlaubt durch (2*)2*16=64k Videospeicher. Wobei hier Videospeicher vom Hauptspeicher getrennt ist, also nur bei Videozugriffen den Prozessor bremst.

Oder man benutzt weit schnelleren und teuren Speicher, wie beim 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.

Abseits liegt der Oric, mit 6x1 Farbzellen ohne den Prozessor ausblocken, aber zum Preis, dass Farben umschalten eine Zelle als Attributschaltbyte 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 (und wie im BBC gemacht). Dabei würden dem TMS9918 die 12k sogar in seine 16k passen, aber der KC 85-4 müsste die 20.5k in 2*10.25k auf 2 seiner 16k Seiten 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 oft halbierter horizontaler Pixel:

Ohne jegliche 2bpp Bitmapmodi kommen neben all den Rechnern ganz ohne Bitmap, auch einige weitere ausscheidend. Einerseits der TV Dazzler (kann nur 1bpp und 4bpp, aber kein 2bpp), dann der VCS/2600, sowie alle TMS9918, ZX Spectrum, die Oric, die KC 85-2 und 85-3 (aber nicht 85-4). (Davon können sich die 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. 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 2 feste 4er Sätze, wie beim MC6847 (Gn+Gl+Bl+Rt oder Ws+Cy+Mg+Or). Etwas besser kann eine Farbe gewählt werden, wie bei der IBM CGA eine Farbe aus 16 und 3 feste 3er Sätze für den Resten (Gn+Rt+Ge oder Cy+Vt+Ws oder Cy+Rt+Ws). Noch besser als das können alle 4 Farben gewählt werden, aus 8 beim BBC, aus 27 beim CPC, aus 64 bei der EGA, aus 128 beim Atari 800, und 4096 beim ST und 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 Farbmonitor offeriert dazu nur 2 feste 4er Sätze (Sw+Gn+Vt+Ws oder Sw+Or+Bl+Ws), aber kann diese für jede 7x1 Zelle wählen (mit dem achten Bit).

Die 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. Dazu gehören auch alle MC6847, die CGA (wäre 160x200 wie CPC), alle C64 und TED, und die 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 undokumentiert 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 der 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 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 beim BBC der nur 8 Farben kennt und das vierte bpp nur für (reversfarbig) blinken benutzen kann. Etwas besser beim 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. Volle 16 RGBI Farben gibt es beim TV Dazzler. Andere feste 16 beim TMS9918 "Multicolor". Sogar 16 aus 27 der CPC, 16 aus 64 die IBM EGA, 16 aus 4096 beim ST 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%.

Mehr als 6bpp liefern die V9938 und V9958 mit "G7" 256x192 8bpp, als einzige 8bit. Der Atari ST könnte von seinem Speicher/Timing her diese mit 160x200 8bpp liefern, es scheitert nur an den internen Leitungen im maximal 4bpp breiten "Shifter" Chip. Er könnte mit Amiga-artigem Prozessor bremsen auf 40% es sogar bei 320x200. Der Amiga könnte mit seinem Timing auch auf 320x200 bzw 320x256 liefern, mit wie beim 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. Problematisch dabei sind die fest gegebene Zellengrösse/Zellengrenzen sowie die limitierte Anzahl Zellensorten im Font.

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. Das sind TV Dazzler, VCS/2600, BBC, ZX Spectrum, CPC, alle KCs, sowie alle 16bit ausser der EGA.

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

Zudem scheiden die Famicom/NES aus, weil Zellmodi aber nur 2bpp. Das Master System mit G4 verwendet gar 4bpp. (Es hat 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 das Mega Drive und die SuperFamicom/SNES sogar nur Zellmodi, aber keine 1bpp. Aber auch wieder die Neo Geo, ohne einen Bildhintergrund!

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

1bpp/2Farben Farb+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 Bandbreitebedarf) einsparen, und zudem weit flexiblere Graphik, wenn auch auf Kosten von Prozessorlast beim scrollen.

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 saher 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 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. Mit 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, 16 Farben pro Zeichen bzw pro 8x8 Pixel Zelle, plus noch mit "Extended" 4 Hintergrundfarben von 2bpp (aber auf Kosten von 64er Font). Mit Bitmap 1bpp 2von2 bzw 2bpp 3von4 zellenweise und Text immer noch 1bpp 1von2 bzw 2bpp 1von4 zellenweise. Dazu die grösste Menge Spritebits pro Zeile. Und noch jede Menge flexiblen Komfort wie fein scrollen und lesbarer Zeilennummer und Rasterinterrupt, und ungebremsten Takt vom Prozessor. Das einzige was einem hier wirklich fehlt ist Overscan (ausser bei den Sprites). Nett wäre noch die 16 Farben aus mehr auswählen können (wie beim Atari 800 und dem TED). Verschmerzen kann man dass intensivere Effekte nach Software vorzu umkonfigurierend verlangen. Die Designer vom VIC-II haben ihre Erfahrungen von PET/CBM und VC-20/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 ausnutzen drin!

Platz 2 geht knapp dahinter an die Nintendo Famicom/NES. Abstriche gibt es für dessen 256 Pixel trotz dass dies inklusive Overscan ist, was an Text nur etwa 24..28 Zeichen breit erlaubt, (was somit einem (24..28)*8=(192..224) Pixel entspricht. Ebenso geringeren Abstich für die die fehlenden Bitmaps. Das vernichtet jede Chance auf den Platz 1 (mit 320 Pixel hätte er diesen genommen). 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 mit 1bpp entspricht. Die 8x8 2bpp brauchen dafür 2 Bytes Font pro Pixelzeile eines Zeichen, mit nur bei jedem zweiten Fontbyte ein Zeichennummerbyte holen, was 2/3 statt 1/2 Bandbreite an Fontdaten erlaubt, und damit erst obige Pixelmenge. Damit gibt es trotz gebremsten Speichertiming, schlimer 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 auf 16x16 limitierten Farbzellen akzeptabel, zumal diese dann gleich zellenweise 3 Farben von 4 Sätzen erlauben. Dazu kommen die zweitmeisten Spritebits pro Zeile. Man merkt wie die Erfahrungen aus Spielhallen Automaten herstellen (teils ihrer Automaten beinhalten von NTSC auf RGB modifizierte Famicoms/NES). Aber ebenso merkt man die Limiten von einer Spielkonsole zu einen Homecomputer ausbauen wollen, wie nur etwa 24..28 Zeichen breit nutzbar für Text. Dies kann den C64 aber nicht überholen, weil zwar das Spielfeld so mehr als dessen 2bpp 160 Pixel hat, aber gegen 1bpp 320 nicht ankommt, sowie ebenso dessen Sprites nicht gegen 160oder320, vom Spielfeld unabhängig und einzeln wählbar. 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 schneller Speicher fehlt, trotz SRAMs. 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 und Regioncodes erweitert wurde, was eigene Module herstellen verhindert, nur das erlaubt wofür Nintendo einem Module herstellen willig ist. Damit ist nur noch Konsumieren erlaubt was die Diktatur vorgibt, es versagt somit als Medium! In Zahlen, für die etwa 2mio Atari 800 gab es in 13 Jahren um 1000 Spiele, für 17mio C64 gab es in 12 Jahren 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"). Dies ausser "Text", 256er Font, mit nur 6x8 Font aber dafür 40 Zeichen. Dazu noch die drittmeisten Spritebits pro Zeile. Und keine Prozessorbremse. Abstriche gibt es hier für das komplette fehlen jeglicher 2bpp Farbigkeit, und damit nur den dritten Platz. 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. 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.)

(Die V9938 und V9958 erweitern einiges davon. Einerseits ihren massiven G4..G7 Bitmapmodi ohne Zellnummern, bis zu 512 Pixel mit 2oder4bpp, oder 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 die Famicom/NES und den C64 zu überholen, bestes 8bit zu werden. Sie waren aber mit 1985 bzw gar 1988 zu spät um noch gross 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 Pixelzeile eines Zeichen, mit daher nur bei jedem vierten Fontbyte ein Zeichennummerbyte holen, was sogar 4/5 statt 1/2 Bandbreite an Fontdaten erlaubt. Dies zudem ohne die niedrige Pixelrate der Famicom/NES, mit vollen 32 Zeichen Text. Und das erst noch ohne auf 16x16 limitierte Farbzellen, weil gar keine solche mehr, mit voll 4bpp im Font. Aber damit auch Farben fest im Zeichen drin, keine Zellmuster mit Farben kombinieren, was aber mit 448 Font weniger schlimm ist. Ebenso 8 von 64 Sprites. 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, und sind darin wieder auf Atari VCS/2600 Niveau. 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 160+). Es ist auch so dokumentiert als 160er Pixelclocks (die 320er werden offiziell als "Halfclocks" bezeichnet). Zwar guten 2bpp Support in 160er Text und Bitmapmodi, aber dahinter gibt es kein zellenweises Farben setzen, mit nur 4 Farben auf dem ganzen Bildschirm, ausser man geht per Display List Interrupt und Software umkonfigurieren, was aber wegen Timing nur zeilenweise "streifig" wirken kann, und ihn so klar auf den vierten Platz verweist. Dazu kommt nur 128er Font, bzw wenn man die Modi "6" und "7" für 2bit an Farbauswahl nutzen will sogar nur 64er Font, nicht mal 2*64 Zeichen geschweige denn 4*64 (was der C64 erst für seinen 4 Hintergundfarben "Extended" Textmodus opfert). Man merkt hier dass Atari eine Spielhallenfirma ist und erstmals einen Homecomputer aus einer halbfertigen Spielkonsole macht, und das mit der Auflösung nicht im Griff hat, während Commodore als Bürofirma beim C64 zum zweiten mal einen Spielerechner macht. Dazu kommen noch die zweitgeringsten Spritebits pro Zeile, was auch nicht bei korrigieren von obigen Limiten helfen kann. Diese dazu noch ebenfalls mit nur 160er Raster, gerade die Sprites nicht detailiert, weil nur 8 Pixel 1bpp pro Sprite. Das ist besonders schwach bei einer Spielefirma, und dazu dem Erfinder der Sprites (Pong Geräte waren praktisch nur Sprites ohne Hintergrund). Dies wurde dann besonders kritisch als aus dem Atari 800 die 5200 und XEGS Konsolen abgeleitet wurden. Es ist aber unvermeidbar wegen des gebremsten 7/8 Prozessortaktes, und so nur 112 von den 128 Speicherzyklen/Zeile vom C64, mit davon wegen dem Overscan 2*48=96 statt 2*40=80 für den Hintergrund reserviert, nur 112-96=16 statt 128-80=48 im Rücklauf (wo die Spritedaten gelesen werden). Nach Abzug vom Speicherrefresh (etwa 4), sowie bis zu 6 weitere für die Displayliste reserviert (maximal Pseudomodus "1" plus Adresse plus Modus plus fakultative Adresse), verbleibt die Differenz von 8*3=24 zu 5*1=5 Spritebytes/Zeile. Da kann auch die Displayliste nichts mehr retten. Sie spart zwar selektiv RAM (und damit Bandbreite/Prozessorbremse) bei variabel aufwendigem Hintergrund, sowie Prozessor bei Modi im Bild umschalten bzw scrollen, aber bei Farben oder Sprites aufbessern ist sie wirkungslos, also doch wieder Software gefragt. Dabei sind Text oder Paint Programme ohnehin nur 1 Modus, Spiele mit mehreren Modi nutzen den Prozessor eigentlich 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 am 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, weil mit viel komplexem Aufwand am Ziel effektiver Leistung vorbeigeschossen! Die in der Einführung erwähnte Atari 800 vs Commodore 64 Debatte wird somit eindeutig von letzterem gewonnen.

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. Der als erweiterte Pong Konsole mit 40 Pixel 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 nur 2*8 und 3*1 Pixel. 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 inkompatible) Konkurrenz aus dem amerikanischen Markt heraus. Was ihn ab 1977 von 3 auf 6 Jahre zu 1983 "streckte", in denen in Europa die Homecomputer den Markt wegnamen, und Japan ohnehin noch an Spielhallenautomaten festhielt. 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 liegende 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 zur Lockout Chip Erweiterung gebracht, um damit Spiele zu zensieren, um Qualität zu erzwingen. Nur haben sie es wie jegliche Zensur 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. 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

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 Farbzellen von Commodore, und somit das beste von beidem! Selbiges gilt beim Font, umschaltbar Commodore 256er flexibel oder Atari 128er sparsam. Lediglich der Overscan fehlt, wenn auch nur teilweise (nicht horizontal, aber kann mit Rasterinterrupt ausnutzen vertikal, es hat hier keine FarbRAM Limite). 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, welche das fehlen dessen 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 Sound unterschätzt und verspottet als Minus/60, trotz in allen anderem gleich gut oder gar leicht besser zu sein!

Platz 2 geht erstaunlich an den VC-20. Er leidet zwar massiv an seiner "halbierten" 160 Pixel Auflösung, und nur 23 Zeichen breitem Text. Bitmaps fehlen auch. Aber abgesehen davon hat er einen 256er Font mit 1bpp und 2bpp (was dann nur noch 80 Pixel ergibt), und dazu noch FarbRAM auf 8+4=12bit, und sogar Overscan. In obiger Kategorie hätte er nicht nur den VCS/2600 klar geschlagen sondern auch den Atari 800er bedrängt. Hätte er nur 40 Zeichen bekommen wäre er wie beim TED am 800 vorbeigezogen, erstaunlich für Commodore erstmals eine Spielkonsole machen, 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, aber die Basis von C64 und TED legte. (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 dann noch wie erwartet als letzter an die MC6847. Hat nur 256 Pixel, und das auch nur mit im Chip selber eingebautem festem 64er ROM Font oder 1bpp Bitmap ohne Farbwahl. Sonst nur 128 Pixel 2bpp (und das ohne Schwarz), oder 8+1 Farben mischbarer 2x2 Blockgraphik oder 4+1 Farben unmischbarer 2x3 Blockgrpahik mit Schwarz (aber diese nur 2*32=64 breit, und ohne SAM Tricks 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!

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

Platz 1 und 2 gehen mit Abstand 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 ihre primitive Logik und das Fehlen von Sprites grossteils wettmachen! Mit bei 4bpp nur 2 160er Pixel in einem Byte 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), ebenso unter der Famicom/NES. Damit schlagen sie erst recht locker alle in der "ohne Sprites" Kategorie, und hier in dieser sowieso. 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, die 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 2^3=8 RGB Farben gleichauf 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 mit 1990, und somit 5 Jahre nachdem die 16bit Atari ST und Commodore Amiga erschienen waren, als 8bit schlicht nicht mehr relevant.)

Platz 3 geht überraschend in die DDR an den KC 85-2 (und 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. Mit 640x256 1bpp und 160x256 4bpp addiert würde das Teil mit obigem BBC gleichziehen, bzw mit 16 Farben statt 8 sogar darüber! All das in nur reinem TTL, einfacher Struktur, aber sehr wirksam, weil genau das was man braucht, auf etwas über TED Niveau! Auch hier sind in der 85-2 und 85-3 dann 10.25+2.5=12.75k bzw in der 85-4 gar 10.25+10.25=20.5k an Speicher (plus weitere 1.25k simulierter Textmodus Speicher) sowie viel CPU um diesem umschaufeln der Preis. Was die nur 1.75MHz bzw 1.77MHz gebremste UB880 aber ordentlich belastet (trotz LDIR/LDDR haben), mitsammt "ghosting" wegen Bitplanes, was bei der ineffizienten eingebauten Software der 85-2 sehr langsames scrollen in 0.6s ergab!

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

Platz 5 geht an die 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 6 geht erst abgeschlagen an die IBM PC CGA. Die kann eigentlich 640 Pixel, oder 320 mit 2bpp, und damit zwei Modi der BBC und CPC, mit dem selbigen 16k Speicher wie letzteren, welchen die 4.77MHz 8088 erst recht problemlos umschaufeln kann. Aber genau der weitere Modus mit 160 Pixel und 4bpp fehlt hier massiv. Auch bei 2bpp ist nur eine Farbe frei wählbar, und diese erst noch an die Randfarbe gekoppelt. Dazu kommen noch die festen 3er Farbsätze ohne Schwarz darin, welche die 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 keinen RAM Font. Was zu dessen Blockgraphik benutzen zwingt, welche aber auch nur 1x2 Blöcke liefert, zu 80x50. Egal was man es versucht, die CGA macht einem einen Strich durch die Rechnung, verhindert gute Graphik und frustriert! (Nur mit dem "Tweak Mode" kommt man mit 2x1 Blockgraphik und 8x2 Font noch auf halbwegs ordentliche 160x100 mit 16 Farben. Weshalb die CGA trotz dieser Pseudo-Bitmap in der Auflösung selbst hinter den ZX Spectrum und Oric Billigrechnern landet!)

Platz 7 geht weiter hinten an den Apple II. Zwar noch 280 Pixel aber nur mit 1bpp (mit Schwarzweissmonitor), sonst nur noch 140 wenn auch mit 2bpp (mit Farbmonitor) mit seinen ganzen 2*4 Farben und geringer Auswahl. Dazu kommt dass die 140 Pixel aus 40*3.5 bestehen, weil in 7bit 3.5*2bpp passen, also ein "Zwischenpixel" seine beiden Bits auf 2 Bytes beziehen muss, was diesen sehr schwierig zu programmieren macht! Wenn man schon eine solche Sparschaltung macht, wäre Prozessor auf 7/8 bremsen und Bild 8/7 breiter (wie im Atari 800) angebracht gewesen, für volle C64 Geschwindigkeit muss man mit mehr Schaltung dahinter gehen. Blockgraphik liefert 16 Farben, aber auch nur mit 1x2 Blöcke, zu 40x48. (Mit 2x1 und 4 mal mehr Zeilen, würden bessere 80x96 drin liegen, was obigem "Tweak Mode" entsprechen wöre.) Zudem ist es erst noch nicht mit Text beliebig mischbar (nur mit oben 20/24 Graphik und unten 4/24 Text). Text ist zudem nur 64 Zeichen ROM Font, ohne Blockgraphik. Es hat damit zwar 3 Modi aber keiner davon ist wirklich gut, vergleichbar frustrierend wie die CGA, aber noch schwächer. (Nur den Farbeffekt im Bitmap abschalten können, hätte beliebige 280x192 erlaubt, mit eigenem 7x8 Font, inklusive 96 ASCII und Blockgraphik, wenn auch ohne Farben.) (Bonuspunkte gibt es für extrem gute Dokumentation, die ganze Schaltung und der System Sourcecode ist im Referenzhandbuch abgedruckt!)

(Der Apple IIe erweitert auf Text mit 96 ASCII Zeichen, aber weiterhin ROM Font. Mit 1k Speichererweiterung "80-column" gibt es 80x24 Zeichen davon, sowie Blockgraphik auf 80x48. Wertvoller ist das Bitmap auf 560er mit 1bpp, sonst auch 140 aber mit 4bpp und volle 16 Farben. Aber die 140 Pixel aus 80*1.75 bestehend, weil in 7bit 1.75*4bpp passen, was dies noch schwieriger zu programmieren macht!)

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

Ausser Konkurrenz landet die Hercules HGC. Sie ist zwar 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.

8bit ohne Bitmapgraphik oder RAM Font

Platz 1 geht eindeutig an die IBM PC MDA. Ohne Bitmap oder RAM Font oder Farben, zählen in dieser Kategorie nur noch die Anzahl Zeichen und dem ROM Zeichendatz seine Anzahl und Art an Graphikzeichen. Diese hat als einzige 80x25 Zeichen, und erst noch mit vollem 256er Font. Dieser hat aber vor allem viele akzentierte Zeichen, so wenig Graphikzeichen. Insbesondere hat die im Font eingebaute mischbare Blockgraphik nur 1x2 und 2x1 drin, keine 2x2, womit es trotz 80x25 Zeichen nur auf 80x50 Blöcke reicht, oder auf 160x25.

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

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

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

Platz 5 geht dann an die Processor Technology VDM-1 und Sol-20. Zwar stets 64x16, und stets volles ASCII96. Aber nur einen inkonsistenten Satz von Graphikzeichen, und ohne jegliche Blockgraphik. Damit strikte unten aus der Wertung rausfallend.

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), sowie viele grosse Sprites. Damit ist er eine sehr gute Erweiterung des Atari 800, praktisch alle dessen Schwächen beseitigt. Lediglich die Bitplanes und ihr "Ghosting" beim scrollen störten gross, hier am schlimmsten, ausser noch dem 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 lohnend, wo genau "Ghosting" dann am schlimmsten wird. Der Copper ist da einiges wertvoller, aber nicht wirklich dringlich, weil er letztlich nur alle Rasterinterrupt Techniken beschleunigt. Und den Prozessortakt auf 7/8 gebremst macht er gerade mal wett. Damit gewinnt der Amiga aber trotzdem als den besten Chipsatz der 16bit Generation. Aber das vor allem wegen den vielen bpp, und erst noch trotz grosser Auflösung, wenn auch damit weiter bis zu 40% der 7/8 gebremst, 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 den Mac seine 512x384 1bpp locker, mit 32k um ein Drittel mehr als dessen 24k. Dazu ohne wie im Mac den Prozessor wegen langsamen Speicher zu bremsen. Mit dem farbigen Monitor sind seine 640x200 2bpp und 320x200 4bpp mit 32k genau ein verdoppelter Amstrad/Schneider CPC seine 16k, und damit das doppelte vom ersten Platz in dessen Kategorie. Sie sind sogar identisch mit einem Amiga solange man nicht dessen Prozessor für mehr bpp opfert! All das aus einem sehr einfachen simplen auf billig gebauten Rechner (anfangs nur $1000, ohne Monitor und Floppy), trotz 4 mal soviel Speicher wie beim Mac (anfangs $2500, aber komplett), bzw 2 mal soviel wie dem Amiga, sowie gleichem Prozessor wie dem Mac aber ungebremst, und 1/8 mehr als Amiga falls ungebremst. Er wurde damals ebenfalls ziemlich unterschätzt, gerade auch im Vergleich mit dem Amiga, wenn auch nicht ganz so extrem wie bei den TED oder gar dem VC-20. Selbst fehlender Blitter und Copper und Sprites sind mit 4bpp und schnellem Prozessor nicht so kritisch, wie es damalige Spiele oft zeigten. Fehlende mehr als 1bpp in Schwarzweiss, nicht mal 320x400 2bpp geschweige denn 160x400 2bpp, machen das für Spiele unattraktiv, verlangen nach dem Farbmonitor. Lediglich hat er dort keine über 4bpp und 16 Farben, sowie kein Overscan, was ihn auf den zweiten Platz verweist. (Nur mit 8bpp addieren, trotz damit nur 160x200 haben, hätte er bereits den ersten Platz gleichauf genommen. Mit zudem fakultativ doppeltes Bild mit 40% Prozessor opfern wie im Amiga, als 640x400 2bpp bzw 640x200 4bpp oder 320x200 8bpp, hätte er den ersten Platz alleine genommen!)

Platz 3 geht 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. Was ihn klar hinter Amiga und ST stellt. Dazu aber massive 96 mal 16 Pixel Sprites pro Zeile, mit 4bpp, und somit die besten Sprites überhaupt hier, und die typischen grossen Sprite Objekte, was ihn doch bis an den spritelosen Atari ST aufrücken lässt. Dabei merkt man nicht nur Erfahrung aus Spielhallen Automaten herstellen, sondern dass die AES ein voller MVS Automat in Konsolenform ist! (Nur mit 640er Raster addiert, und mehr VRAM dafür, hätte er wegen so guten Sprites plus so vielen Farben den ersten Platz mit Vorsprung genommen.)

Platz 4 geht an dann die Sega Mega Drive. Kann 4*16 Farben, aber aus nur 512. Ein 256 schmales bzw normal 320 besseres Textfeld mit 4bpp, wenn auch mit horizontal nur Breite aber kein volles Overscan. Aber kann 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 Sprites. Aber diese sind nicht ausreichend um fehlendes Bitmap zu simulieren, oder auch nur bandweises Parallax. 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 ein 384..448 breites Textfeld ergibt), aber wurde auch selten genutzt. Ist sonst nur 256 breit (wa weiterhin nur 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 interlaced, aber auch selten genutzt. Kann wie die Mega Drive nur Zellmodi, was ihn hinter Amiga und Atari ST und Neo Geo verweist. Kann viele oder grosse Sprites, aber nicht beides zusammen, weil pro Zeile maximal 34 Zellen zu 8Pixel mit 4bpp an Sprites, was ihn hinter die Mega Drive stellt. Zudem schwach mit dem langsamsten nur 16/8bit Prozessor, auch da hinter allen 68000. Keine Tastatur oder Disk, kann auch so nicht überholen. Das Mode 7 pseudo-3D reicht nicht um dies zu retten. Kein Wunder dass die Mega Drive die SuperFamicom/SNES ernsthaft bedrohte oder an manchen Orten gar abservierte.

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

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

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


Home | Artikel | VCFe Video als visuelles Medium

Diese Seite ist von Neil Franklin, letzte Änderung 2018.11.30