Home | Artikel | VCFe Videoarchitekturen als visuelles Medium

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


Inhalt

Einführung

Nachdem die Themen Logik und Prozessoren sowie Ein-/Ausgabe für Kommunikation und Benutzer nun erledigt sind, wären jetzt alle grundlegenden Komponenten von Rechnern behandelt. Damit wäre jetzt der Schritt von Komponenten zu Systemen zusammensetzen angebracht. Aber wie in 2011 mit dem Thema Forth, welches aus einer 6502 zu 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 zu Commodore 64 Debatte, welche dazu führte dass ich den Atari genauer anschaute und detailiert mit dem mir bestens bekannten C64 verglich. Gefolgt von nach einem letztjährigen Vortrag noch mit den TMS9918 basierten Rechnern vergleichen, und dann auch gleich mit dem Nintendo Famicom/NES. Weil dieses Jahr gerade das Thema Medien ist, werde ich als Übergangsphase nochmals Video anschauen, aber diesmal nicht aus der Perspektive von "wie funktioniert die Hardware" sondern von "wie benutzt es ein Graphiker bzw Programmierer in Software", bzw genauer als "was kann dieser damit anstellen", was sieht er dabei. Dazu werde ich vor allem Videomöglichkeiten von ein paar guten als Spielkonsolen designten Homecomputern als visuelle Medien vergleichen. Aber der Vollständigkeit halber hab ich auch noch nach und nach weitere graphischen Rechner als Übersicht dazugenommen.

Heute sind wir uns im PC Zeitalter gewohnt, dass auf einem Bildschirm beliebiges angezeigt werden kann, auch Photos oder gar Videos, egal ob mit einer Kamera aufgenommen, oder im Rechner 3D gerendert. Dies setzt aber hohe Ansprüche wegen Bilddatenmenge an einen Rechner, sowohl was den Speicherplatz wie auch insbesondere die Speicherbandbreite anbegeht. Dies wurde erst Ende 1980er bis Anfangs 1990er generell machbar.

Etwa ab der 1988er IBM VGA Karte mit ihrem MCGA Modus und dessen 320x200 8bpp (braucht 64k) wurde dieser Ansatz benutzbar, weil 8bpp für RGB in 6*6*6=216 Farben tauglich sind (wie in vielen damaligen PC Spielen gesehen). Ab SVGA 640x480 8bpp (braucht 300k) wurde es auch komfortabel (nur 640x400 passten noch in 256k), mit 80x30 Zeichen in 8x16 Font zugelassen. Ab 800x600 16bpp (braucht schon 1024k) wurde es dann ausgereift, weil diese 16bpp für RGB 32*32*32=32768 Farben Hi-Color tauglich sind, und 800x600 etwa ein volles PAL 567i Fernsehbild ist, und 80 Zeichen zu 8 Pixel ihre 640 Breite nun auch in mehrere sichtbare Fenster passen. Somit sind 320x200 8bpp in 64k die untere Grenze an für beliebiges brauchbarer Auflösung.

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

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

Die Spielregeln

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

Es verbleiben damit vor allem farbige Homecomputer (plus ein paar Videokarten), welche interessanterweise fast alle entweder auf TTL Logik basieren, oder Videochips haben welche eigentlich für Spielkonsolen designt wurden. Daher werden auch dedizierte Spielkonsolen als solches hier addiert. Inszwischen sind es 37 Videokarten und Computer und Konsolen geworden, 29 8bit und 8 16bit.

Die Kontrahenden

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

Cromemco TV Dazzler (1976)

Kein Rechner, sondern ein Paar vom Karten (DMA Logik und Videogenerator) für beliebige S100 Bus Rechner (wie dem MITS Altair 8800 (1975)). Früh erschienen, daher alles reine TTL Logik, keine Customchips, dementsprechend primitiv.

Nur 4 Bitmapmodi, weil technisch einfacher als Textmodi oder gar Zellmodi. Kein eigener Speicher, 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 SRAM Chips nur 1k mit 8 Chips, bzw 2k mit 16 Chips ergab, oder 4k mit sehr teurem 32 Chips. Weshalb man doch zumeist separate SRAM Karte nahm und restlicher Speicher 4kx1 DRAM Chips. Womit nur die DMA Kosten verblieben.

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 als IBGR aus einem einzelnen Register.

Aber selbst die "grossen" 2k mit 64x64 bei 4bbp sind eine sehr geringe Auflösung für Spiele, praktisch auf Blockgraphik Niveau. Und 1bpp ist praktisch nur für Diagramme brauchbar. Und selbst dessen "grosse" 128x128 erlauben nur gerade 32x16 Zeichen mit einem 4x8 Font, bzw eher sogar 20x10 mit dem damals gewohnten 6x12 Nadeldrucker Font. Also auch sehr geringe Textmenge um Programme oder Daten einzugeben, was nach einem separaten Terminal verlangte. Daher ist der TV Dazzler fast nur als Kuriosität nutzbar. Und hier nur aufgeführt, um zu zeigen wie man von den untersten 64k in der Einführung sogar 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 einem separatem Bildspeicher und DMA Logik und Videogenerator drauf. Aber nur in Schwarzweiss, was den Analogteil massiv vereinfachte, sowie nur dem eigenen separaten Speicher benutzend, was die DMA Logik weit einfacher machte. Dies erlaubt zudem trotz langsamem 1MHz SRAM Chips den Prozessor ungebremst im Hauptspeicher laufen zu lassen, mit bei Zugriffen auf den Bildspeicher die gerade geholten Videodaten kurz ausnullen.

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

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

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

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

Apple II (1977)

(Davor war der Apple 1 (1976). Dieser hatte nur Text, 40x24 Zeichen, mit Font festem 2513 ROM Satz, von 64 ASCII Zeichen. Darin hatte es keinerlei Graphikzeichen, er konnte nur ASCII Art und diese nur reduziert, scheidet schon damit hier aus. Aber weit schlimmer hatte er nur 1kx6(!)bit Schieberegister als Bildspeicher, was mangels Adressierbarkeit keine beliebige Cursorsteuerung erlaubt, somit kein veränderbares Bild, nur reine Fernschreiber Emulation, und diese langsam mit max 60 Zeichen/s ausgeben. Die simple Cursorsteuerung wurde in dedizierter Hardware gemacht. (Wer mehr zum Apple 1 Rechner und Video wissen will, kann meine detailierte Analyse von dessen Hardware und Software lesen.))

Der Apple II entstand als Verbesserung davon. Er brachte vor allem den Ersatz der 1kx6bit Schieberegister durch einen 1kByte Ausschnitt vom normalen DRAM Hauptspeicher, und damit beliebig adressierbar und veränderbar, und alle Cursorsteuerung in Software implementiert. Es kann sogar 2 Seiten zu je 1k benutzen, was zwar Doublebuffering für Animation erlaubt, aber bei 1k Videospeicher auch mit umkopieren geht. Weil Rechner und Graphik integriert sind, mit sehr einfacher DMA Logik (die Graphik auslesen liefert sogar nebenbei noch den Speicherrefresh der DRAMs!). Ebenfalls früh erschienen, daher alles reine TTL Logik, keine Customchips, dementsprechend ziemlich primitiv.

(Gemäss manchen Aussagen war dieses revidierte Design die Folge davon, dass der Apple 1 Designer Steve Wozniak diesen dem 6502 Prozessor Designer Chuck Peddle vorführte. Wonach jener statt Lob einen Zusammenschiss erteilte, dass er keine Ahnung habe wie man mit Mikroprozessoren designt, gefolgt von einer Lektion wie man es macht, dedizierte Hardware wie im Apple 1 ersetzen durch Prozessor und Software. Mit dem Apple II habe Wozniak diese Lektion voll umgesetzt, und dazu noch massiv erweitert, während Chuck Peddle seine Vorstellung mit dem PET umsetzte. Andere Aussagen besagen aber, dass Wozniak den Apple 1 bereits wegen Geschwindigkeit und Chips sparen verbesserte, und erst den Apple II Prototyp Chuck Peddle vorführte, als Teil eines gescheiterten Versuches diesen an Commodore zu verkaufen. Chuck Peddle selber sagte dazu in einem Interview, er habe bei einer Werbetour um den 6502 zu verkaufen von zwei in einer Garage gehört, welche Hilfe brauchen um die 6502 zu benutzen, habe diese besucht und geholfen, was eher zu Apple 1 als zu Apple II Situation passt. Weitere Aussagen besagen, dass Chuck Peddle den PET als Fortsetzung des KIM-1 Hexkit plus Serialterminal Einplatinenrechners ausdachte, der zwecks Vermarktung des 6502 Prozessors entwickelt wurde. Wonach er das PET Konzept sogar erfolglos an Tandy zu verkaufen versucht hat, noch bevor er wegen dem Aufkauf von MOS Technology durch Commodore dort landete und Tramiel überzeugte, mit dann nach obigem Apple II Ankauf scheitern den PET umsetzen. Das könnte auch erst nach Apple 1 sehen geschehen sein, aber sicher nicht nach Apple II sehen. Noch weitere Aussagen besagen, dass Tandy Designer nach sehen wie einfach der PET war den TRS-80 entwickelten und dann intern verkaufen konnten. Womit alle 3 Rechner des "Trio von 1977" eng mit einander verwandt sind!)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Der Nachfahre Apple II Plus (1979) unterscheidet sich nur in der erweiterten Software, sowie Power-On Reset Logik, und ein paar andere Korrekturen. Video ist identisch, bis auf dass der einfärben Effekt Ausschalter verbessert wurde. Weiter war die Anpassung auf PAL erst im Apple II Europlus drin. Anderseits gab es im Apple II J-Plus passende japanische Katakana Schriftzeichen.)

(Der Nachfahre Apple IIe (1983) erweiterte Text auf 96 ASCII Zeichen, aber keine Graphikelemente, und das auch nur bei Normaldarstellung, nicht bei revers oder blinkend. Dazu noch falls mit 1k SRAM Speichererweiterung "80-column" doppelter Text 80x24. Video ausgelesen wird DRAM Hauptspeicher und SRAM Speichererweiterung gleichzeitig, womit dies strike 8+8=16bit Video ist. Dabei erscheinen aber beide "addierten" und "alten" 1k in den selbigen 1k an Adressen, was als Banking bekannt ist, mit einem Umschaltbit für welche der 1k Bänke im Prozessorzugriff sind. Das ist noch nichtlinearerer, mit alle Zeichen 0,2,4,..,78 in den "addierten" 1k, sowie 1,3,5,..,79 im "alten" 1k Speicher. Dazu auch ab Revision B noch "Double Low Resolution" Block 80x84. Sowie falls mit 64k DRAM Speichererweiterung "extended 80-column" sogar "Double High Resolution" Bitmap 560x192 1bpp bzw 140x192 pseudo-4bpp in 15 Farben. Hier ebenso beide 8k in den selbigen 8k an Adressen, aber mit dem Umschaltbit der jetzt alle 63k ausser den untersten 1k mit dem Systemstatus umschaltet. Letzteres wird so nochmals schlimmer, weil das 40x25 nichtlinear, plus das 280x192 verachtfachen, plus das 80x25 doppelte "addierten" 8k plus "alte" 8k Speicher, mit jetzt 7 Pixel a bis g sogar in 4 Bytes als Bits addiert:0bbbaaaa alt:0ddccccb addiert:0feeeedd alt:0ggggfff (wenn auch ohne die Farbattribut Bit7 verzögerung). Aber dafür hatte es alle 15 Farben weil mit 4bpp nun auch volle "Viertelwellenpixel" (daher auch kein verzögern mehr nötig). Auch das strikte nur ein Signal, bei Schwarzweiss 560 Pixel, bei Farbe "verwischt" zu 140 "Pixel" in 560er Raster.)

(Der Apple IIc (1984) ist ein kompakter IIe mit stets 128k, keine Slots, eingebaute Disk, selbiges Video.))

(Der Apple IIgs (1986) ist ein massiv erweiterter und schnellerer IIe, mit 2*14.31818/10=2.863636MHz, in bis zu 8M "fast" RAM, plus IIe kompatible 2*14.31818/28=1.0227MHz für 128k "slow" RAM (mit Video davon). Kann neben IIe Modi auch noch 640200@2bpp oder 320200@4bpp mit 4 bzw 16 Farben aus 4096, mit linearen Videoadressen. Sehr nett ist, dass man bei 320x200 sogar 16 Sätze zu je 16 Farben definieren kann, und pro Zeile ein passender Satz aktiviert wird. Ebenso dass man bei 640x200 2 Sätze zu je 4 Farben definieren kann, mit pro Spalte diese abwechselnd.)

(Der zuerst vorgesehene Nachfahre Apple III (1980) konnte eigentlich mehr als der IIe. Er hatte 2*128k als Minimum (weil stets 16bit breit), und wäre sogar mit Speicherplatine ersetzen auf 2*512k hinaufgegangen. Video war soweit mit bekannt die selbige erweiterte wie im IIe. Er ist aber wegen mechanischem (zu kleines Gehäse) und vor allem thermischem (Luftstau aber kein Lüfter) Fehldesign komplett gescheitert. Weshalb der weniger fähige IIe 3 Jahre später nachgeschoben wurde.)

Tandy TRS-80 (1977)

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

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

Nur Schwarzweiss, auf dem separaten aber mitgelieferten Videomonitor (ein RCA Schwarzweiss Fernseher ohne Tuner). (Hat ebenfalls separates aber mitgeliefertes Kassettenlaufwerk.) Wie VDM-1/Sol-20 und Apple II reicht dies als Terminal um Programme oder Daten einzugeben. Es ist aber auch mit 64x48 bzw 128x48 halbwegs brauchbar für einfache Spiele, eher Vollbild Actionspiele mit Text irgendwo im Bild.

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

(Der Nachfahre Model III (1980) hatte eingebauten Monitor und rechts neben diesem Platz für 2 Floppylaufwerke. Selbige Textmodi, aber nun mit 8x12 statt 6x12 Font. Aus festem ROM Satz, von nun 96 ASCII Zeichen plus die 64 2x3 Blockgraphik plus weitere 96 Graphikelemente. Mit 2MHz statt 1.77MHz leicht schneller. (Optional gab es eine 640x240 Bitmap Erweiterung. Ansichts von 64x16 Zeichen * 8x12 Font = 512x192 Pixel sind diese 640x240 Bitmap sogar möglicherweise mit vollem Overscan, zumal NTSC Fernseher genau 240 Zeilen hat.))

(Dessen Nachfahre Model 4 (1983) hatte zusätzliche Textmodi 40x24 und 80x24. Da auch alte 32x16 und 64x16 liefen ist anzunehmen weiterhin NTSC Monitor, und somit die neuen mit 8x8 statt alte mit 8x12 Font. Selbige 96+64+96 Zeichen, und zusätzlich revers aber nur wenn in 40 oder 80 Modi (wohl weil als Teil der neuen Bildspeicher Anordnung aktiviert, 2k 9bit statt 1k 8bit). Es hatte zudem volles 64k RAM statt max 48k. Konnte dazu die ROMs abschalten, und somit auch CP/M fahren neben TRSDOS. Sowie 4MHz, aber reduzierte auf 2MHz im III Modus. (Optional gab es eine 640x240 Bitmap Erweiterung, sogar mit gescrolltem Auschnitt von einem 1024x256 Bild.))

(Die Seitenlinie Model II (1979) und Model 12 (1983) waren volle Bürogeräte und keine Heimcomputer. Textmodi 40x24 und 80x24 (kein 32x16 oder 64x16). Mit 6x12 Font, wegen somit 480x288 Pixel auf eingebautem Spezialmonitor, aber separate Tastatur. Aus festem ROM Satz, von 96 ASCII Zeichen und 32 "Business Graphic" Zeichen. Zudem hatten sie 1 8" Floppylaufwerk vertikal neben dem Monitor. Basic kam von Disk statt ROM, nur 2k abschaltbares BootROM, was 64k RAM erlaubt, und somit auch CP/M fahren neben TRSDOS-II. Mit 4MHz statt 1.77MHz weit schneller. (Model 4 hat praktisch die I/III und II Linien zusammengeführt, abgesehen von den Floppys. Model 12 hat die II auf über 64k DRAM erweitert.))

(Die Model 16 (1982) und 16b waren auf selbige Gehäuse wie II und 12 aufbauende Z80+68000(!) Doppelprozessorsysteme, für 16bit Leistung plus 8bit Kompatibilität. Es gab sogar einen Aufrüstsatz von II auf 16. Dokumentation von technischen Details fehlt, aber von Bildern her scheint das 16 nur ein II zu sein, mit zusätzlichen 16bit Prozessor plus Speicher Platinen im Slotbereich, welche damit strikte ein Koprozessor sind. Auf der 68000 lief neben TRSDOS-16 auch Xenix (eine Unix Portierung), welche beide die Z80 als I/O Prozessor nutzten, genauer die 8bit Basis als Terminal mit Disks und allenfalls Ports für 2 weitere Terminals. Model 6000 war ein überarbeitetes schnelleres 68000 Board. Es war wiederum in 16 und 16b nachrüstbar. Damit hat Tandy bereits 2 Jahre vor Apple Macintosh und 3 Jahre vor IBM PC/AT 16bit geliefert!)

Commodore PET 2001 (1977)

Früh erschienen, alles reine TTL Logik, keine Customchips, und billig, dementsprechend auch recht primitiv. Direkt im Rechner eingebaut (wie Apple II), aber mit separatem 1k Bildspeicher aus SRAM (wie VDM-1/Sol-20 und Tandy TRS-80), und ebenfalls einfache DMA Logik. Aber ohne bei Zugriff die Videodaten kurz ausnullen, weshalb der zufällig gerade getroffene dargestellt werdende Zeichenausschnitt durch einen beliebigen anderen ersetzt wird, was zum kurzen aufflackern zufälliger Pixel fürht, und als "Snow" (= Schnee) bekannt ist. Strikte kann man ganze Videodarstellung abschalten (was die Systemsoftware beim scrollen macht) oder bis zum Ende der Bildausgabe warten (was die Systemsoftware bei einzelne Zeichen ausgeben macht). Aber das verlangsamt zeichnen und wird daher von Fremdsoftware oft nicht gemacht.

Hat nur 1 Textmodus (wie VDM-1/Sol-20). Text 40x25 Zeichen (etwas mehr als Apple II seine 40x24). Mit 8x8 Font. Aus festen ROM Satz von 128+revers Zeichen (wie VDM-1/Sol-20). Aber zwei solcher, "Graphic" und "Business". Diese haben neben 64bzw96 ASCII auch 64bzw32 Graphikzeichen drin. Weit bessere solche, inklusive 8 Zeichen (*2 mit revers) für im Font integrierte mischbare 2x2 Blockgraphik (gibt 80x50), aber auch viele andere dedizierte Graphikelemente. Die beste Pseudographik der Welt, weil eben einen zweiten speziellen Satz Zeichen ohne Kleinbuchstaben für 64 statt 32 Graphikelemente, neben einem normalen Satz mit Kleinbuchstaben aber nur 32 Elemente. Dieser Zeichensatz ist als PETSCII bekannt. Bei 40*8=320 von 8MHz Pixeltakt ein mittleres 40µs Textfeld. Nur Schwarzweiss, auf dem eingebauten 9" Monitor. Ebenfalls eingebautes Kassettenlaufwerk, womit dies ein alles-in-einem Bürogerät ist und kein Heimcomputer. Er ist somit auch der ideologische Vorläufer vom Macintosh. (Commodore war von Anfang an ein Büroausrüstung Hersteller, der von Schreibmaschinen via Taschenrechner und Chips brauchen zu MOS Technology aufkaufen kam, und dabei Chuck Peddle aufnahm.)

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

Wie VDM-1/Sol-20 und Apple II und TRS-80 reicht dies als Terminal um Programme oder Daten einzugeben, mit 40x25 besser als 40x24 oder gar nur 64x16. Dazu kommt ein sehr komfortabler Bildschirmeditor, um Kommandozeilen bei Eingabe zu editieren, aber auch um beliebige ausgegebene Zeilen allenfalls editiert als Eingabe zu nutzen (inklusive ausge-LIST-ete Zeilen modifizieren und als neue Zeilen addieren/ersetzen). Es ist aber auch mit 80x50 Blockgraphik plus Elemente auch halbwegs brauchbar für einfache Spiele, wieder eher Vollbild Actionspiele mit Text und Elemente irgendwo im Bild.

Dies zeigt einen weiteren Ansatz: Ebenfalls mit Font kompakt, aber weniger limitiert wegen vielen mit Text beliebig mischbaren Graphikzeichen, und das direkt im Font, weshalb auch kein Modusschalter oder Modusattribut nötig ist, was wiederum mehr Zeichen erlaubt. Dazu noch die ganzen Graphikzeichen auf der Tastatur abgebildet, um sie mit Shift einzugeben, was zusammen mit vielen solchen sehr gut ist.

(Die Nachfahren PET 2001-N bzw CBM 3000er Serie (1979) sind leicht überarbeitet für mehr Speicher, mit 1* oder 2* 16k DRAM statt PET 1* oder zumeist 2* 4*1k SRAM. Sie haben für Video aber selbige 1k aus SRAM, nun aber 2MHz fähig und damit kein "Snow" mehr. Sie haben zudem eine echte Schreibmaschinen Tastatur, statt der "Chicklet" Tastatur, aber brauchen daher externes Kassettenlaufwerk. Ebenfalls besseres Basic 2.0. Die frühen CBM 4000er Serie (1980) haben selbigen Speicher und Video, sind nur mit verbessertem Basic 4.0.)

(Die CBM 8000er Serie (1980) und neuere 4000er (1981) haben einen MOS6545 Timing Chip (eine Variante des später beschriebenen MC6845), und einen grösseren 12" statt 9" Monitor (daran kann man frühe und neue 4000er auseinanderhalten). Mit die 8000er darauf 80x25 Zeichen. Dazu hat sie 2* 1k Bildspeicher B¨nke aus SRAM, welche parallel als 8+8=16bit gelesen werden (wie Apple IIe mit "80-column"), mit erst ab dem Font ROM doppelt getacktet, statt allen anderen ihren 40x25 aus 1* 1k, mit alles einfach getacktet. Aber selbst dabei liegen alle Zeichen komfortabel linear im Speicher, weil mit Adressbit A0 zwischen den beiden SRAM B¨nken gewählt wird, und dann A1..10 statt A0..A9 innerhalb der 1k addresieren. Die neuen 4000er sind selbige MOS6545 basierte Schaltung, aber ohne die zweiten 1k und doppeltem Takten, deren Universalplatine ist für 4000er oder 8000er konfigurierbar. Die 8096 addiert nur eine +4*16k Speichererweiterung von 32k auf 96k.)

(Deren Nachfahren PET-II (B128 und B256 sowie CBM128-80 und CBM256-80) bzw CBM-II (B610 und B620 sowie B710 und B720) Serie (1982) haben 2oder4* 64k DRAM. Sie verwenden 2k Bildspeicher aus einem einzelnen 2kx8 SRAM Chip, da dieses inzwischen 4MHz fähig ist, und damit keine 2* 1k B¨nke aus je 2 1kx4 SRAM Chips mehr nötig. Die Bxxx/B6x0 haben einen separaten Monitor (wie Tandy TRS-80). Die CBMxxx-80/B7x0 haben einen eingebauten drehbaren Spezialmonitor mit 350 Zeilen und Ersatz vom bisherigen 8x8 Font durch 8x14, sowie zudem eine separate Tastatur.)

(Nach Misserfolg obiger Serie, wegen inkompatibel zu PET/CBM und sehr fraglichem nur beschränkt nutzbaren Design der Speichererweiterung, wurden die bestehenden CBM 8032 und 8096 modernisiert, durch in das neue CBMxxx-80/B7x0 Gehäse mit Monitor und separater Tastatur stecken, als CBM 8032-SK und 8096-SK. Das SK steht für "Separate Keyboard". Die letzte CBM 8296 hat wiederum 2* 64k DRAM, aber mit einer 8096-kompatiblen Speichererweiterung. Nun erstmals ohne separateb Bildspeicher, mit Bild aus dem ersten der 64k DRAM. Wie bei CBM-II ist Video nur 8bit breit, weil inzwischen sogar 4MHz Zugriffe auf schnelle DRAM Chips machbar waren.)

Atari VCS bzw 2600 (1977)

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

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

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

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

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

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

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

Exidy Sorcerer (1978)

Früh erschienen, alles reine TTL Logik, keine Customchips, und recht billig, dementsprechend auch ziemlich primitiv. Direkt im Rechner eingebaut (wie Apple II), aber mit separatem 2k Bildspeicher aus SRAM (wie VDM-1/Sol-20 und TRS-80 und PET/CBM) sowie separatem 1k Fontspeicher aus SRAM, und ebenfalls einfache DMA Logik.

Hat nur 1 Textmodus (wie VDM-1/Sol-20 und PET/CBM). Text 64x30 Zeichen (fast doppelte VDM-1/Sol-20 und TRS-80). Mit 8x8 Font. Aus gemischtem festen ROM Satz von 128 Zeichen mit vollem ASCII96 plus variablem RAM Satz von 128 Zeichen. Von letzteren sind 64 vorbesetzt mit Graphikelementen auf etwa PET/CBM Niveau ohne aber 2 Fonts schalten zu müssen. Bei 64*8=512 von 12.638MHz Pixeltakt ein mittleres 40.5µs Textfeld.

Nur Schwarzweiss, auf einem separaten Videomonitor oder Fernseher. (Benutzt ebenfalls separates Kassettenlaufwerk.) Wie VDM-1/Sol-20 und Apple II und TRS-80 und PET/CBM reicht dies als Terminal um Programme oder Daten einzugeben. Es ist aber auch mit 128x60 halbwegs brauchbar für einfache Spiele, eher Vollbild Actionspiele mit Text irgendwo im Bild. Viel wichtiger aber kann man 128 eigene 8x8 Zeichen definieren, für volle 512x240 Pixel, wenn auch kein volles Bitmap. Dieses ist voll brauchbar für jegliche Spiele, solange sie mit 2D Elementen arbeiten und nicht mit 3D Vektoren. Man merkt hier, dass Exidy ein Spielautomaten Hersteller ist.

Dies zeigt einen weiteren Ansatz: Ebenfalls mit Font kompakt, aber weniger limitiert wegen beliebig definierbaren Font für Spiele beliebig ladbar/ersetzbar. Wobei die Zeichencodes so kompakt wie Text sind, aber die Zellen trotzdem fast so graphisch wie Bitmap, statt nur ein Standardsatz generischer Graphikelemente. Zudem 256 Zeichen, statt nur 128+revers. Weshalb auch kein Modusschalter oder Modusattribut nötig ist, was wiederum mehr Zeichen erlaubt. Dazu noch die ganzen vorbesetzten Graphikzeichen auf der Tastatur abgebildet, um sie mit Graphic (die 64 vorbesetzten) bzw Shift-Graphic (die korrespondierenden 64 undefinierten) einzugeben, was zusammen mit vielen solchen sehr gut ist.

MTU K-1008 Visible Memory (1979)

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

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

Tangerine Microtan 65 (1979)

Relativ früh erschienen, alles reine TTL Logik, keine Customchips, und billig, dementsprechend auch sehr primitiv. Nur wenige Schritte oberhalb eines Hextasten plus 7-Segment Anzeige Maschinencode Lernsystemes wie dem KIM-1, weil noch eine Videoausgabe und fakultative volle ASCII Tastatur addiert (halbwegs dazwischen war der AIM 65, mit 14-Segment Anzeige und stets volle ASCII Tastatur). Direkt im Rechner eingebaut, aus einem 512Byte Ausschnitt vom normalen 1k SRAM Hauptspeicher laufend (als 256Byte Zeropage + 256Byte 6502 Stack + 512Byte Video) und damit beliebig beschreibbar (wie Apple II, aber dort von mindestens 4k als 256Byte ZP + 256Byte Stack + 256Byte Zeilenbuffer + 256k System + 1k Video + 2k Benutzer). Weil Rechner und Graphik integriert sind, mit sehr einfacher DMA Logik. Der Hersteller wies explizit hin auf kein "Snow" haben (dank 2MHz SRAM Chips).

Hat nur 1 Textmodus. Text 32x16 Zeichen (wie Fernseher Modus vom TRS-80). Mit 8x16(!) Font, was aber wegen x16 * x16 = 256 Videozeilen auf einen PAL Monitor oder Fernseher ausnutzen muss, kein NTSC erlaubt. Aus festem ROM Satz, von 64 (standard, 32..95) oder 128 (erweitert, 0..31 + 96..127) ASCII Zeichen, ohne revers, Bit7 ignoriert. Dazu aber von einem Modusattribut Bit8(!) gesteuert ohne Font hartverdrahtete aber mit Font mischbare grosse 2x4 Blockgraphik in Bit7..0 (gibt 64x64) (wie TRS-80, aber mit 2x4 statt nur 2x3 in Bit5..0 (gibt 64x48), passend zum 8x16 statt 6x(8von12) Font). Bei 32*8=256 von 6MHz Pixeltakt ein breiteres 42.667micro;s Textfeld.

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

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

Atari 800 (1979)

Anfangs als Spielkonsole designt, als "etwa verdoppelten" Nachfolger der VCS/2600, weil dieser wegen primitiv sein zurecht auf nur 3 Jahre benutzbar angenommen wurde. Die weitere Entwicklung wurde aber nach Firmenaufkauf durch Warner Brothers (1978) vom neuen Management geblockt, um das bestehende "ausreichende" Produkt nicht zu konkurrenzieren. (Das Prinzip von technisch überholt werden existiert wohl nicht bei Filmfirmen.) Dann wurde das Design als Homecomputer 800 recyclet und erweitert. (Plus ein nicht erweiterbares wenig Speicher plus Folientastatur Subset 400, vor allem als Spielkonsole gedacht, das sich etwa doppelt so viel verkaufte wie der volle 800.) Dann verbilligt zu 800XL (1983). (Plus ein wenig Speicher Subset 600XL.) Zum Schluss nach zweitem Firmenaufkauf noch passend zum ST umgestylet als 65XE (1985). (Plus eine speichererweiterte 130XE.)

(Später kam trotzdem noch ohne Tastatur als Konsole 5200 (1982), aber diese nicht zu den 400 und 800 IO Chip adresskompatibel, und nur 2k Subset vom 10k ROM, sowie mechanisch fehldesignte Joysticks, mit inkompatiblen Signalen Analog statt Digital. Daneben kam weiter noch eine erweiterte 2600 Konsole 7800 (1984), inkompatibel zu 800 und 5200! Diese wurde wegen dem zweiten Firmenaufkauf (1984) zuerst fallengelassen aber verspätet doch rausgelassen (1986). Aber fast parallel dazu kam eine XE kompatible Konsole XEGS (1987), und damit zu 5200 und 7800 inkompatibel! Was alles Atari bei den Spieleherstellern komplett diskreditierte, allen späteren Systemen jegliche Unterstätzung kostete. Dies insbesondere auch dem Jaguar (1993), für den Atari den ST weiterentwickeln aufgab, und unterging nach dessen Versagen mangels Spielehersteller Software. All das wegen diese Lektion schon beim selbigem Versagen vom Lynx (1989) nicht gelernt zu haben. Tod durch wiederholtem Kopfschuss per Management.)

(Obiges erstes neues Management hatte einen ehemaligen Textilfirmen Manager als Chef. Er behandelte Spieledesigner als etwa gleich unwichtig wie davor Handtuch Musterdesigner. Er hat nicht begriffen, dass Leute Handtücher wegen Tuch benutzen kaufen und die Muster nur Dekoration sind, aber Spielmodule nicht wegen ROM Chips kaufen sondern wegen den Spielen darin! Das restliche Management hat seinen Fehler nicht bemerkt und korrigiert, trotz dass eine Filmfirma eigentlich wissen sollte, dass Leute auch Filme nicht wegen dem Filmstreifen anschauen, sondern wegen der Geschichte darin. Und jeder weiss, dass Leute Bücher nicht wegen dem Papier kaufen, sondern wegen dem Text darauf. Ebenso weiss jeder Manager dass er Berichte nicht wegen dem Papier liest, sondern wegen den Daten darin. Gamedesigner sollten daher zumindest wie Autoren und Graphiker, oder gar wie Regisseure und Schauspieler behandelt werden. Was ihnen bei Atari versagt blieb, weder namentliche Nennung noch prozentuale Beteiligung am massiven Gewinn. Statt dessen wurden sie sogar mit Buchhaltungstricks um versprochene Erfolgsboni betrogen, gemäss Aussage von VCS/2600 und 800 Designer Jay Miner. Diese Missachtung hat viele davon hinausgeekelt. Was einerseits die wenigen verbliebenen massiv überlastete, und bei Atari zu eigenen schlechten oder gar unfertigen Spielen führte (Pacman bzw E.T.). Dazu anderseits bei mehreren von den Ehemaligen gegründeten Drittfirmen oft zu wegen schnell Profit einnehmen müssen überhasteten, aber wegen viele Konkurrenten trotzdem überhypeten Spielen. Nicht verwunderlich führte dies, zusammen mit den Limiten der VCS/2600, zu einer Flut von Schrottspielen, gefolgt von Vertrauenskrise der Käufer und Marktzusammenbruch im nordamerikanischen Videogame Crash von 1983. Addiert man noch Hardware billig verkaufen und erst an den Spielen Profit machen, also eine Hardwareproduktion mit einem Softwareverlag Businessmodell finanzieren versuchen, und Atari verlor massiv, was zu obigem zweiten Firmenaufkauf führte. Der Atari Gründer Nolan Bushnell hat den Verkauf an Warner in einem Interview als den grössten Fehler seines Lebens bezeichnet.)

Drei Customchips, "CTIA"/"GTIA" (Color/Graphic Television Interface Adaptor) arbeitet wie VCS/2600 nur mit Bitmap, sowie "ANTIC" (AlphaNumeric Television Interface Controller) holt Bilddaten per DMA aus dem normalen DRAM Hauptspeicher und wandelt dabei Textmodi zu Bitmap, sowie "POKEY" (POtentiometer KEYboard) Paddles und Tastatur mit auch Audio und UART. Alle als dreier Chipsatz zusammen die kleinere TIA im VCS/2600 ersetzend, und damit weit mehr leistend. Umschaltbar (wie Apple II), aber hier massive 8 Bitmapmodi und 6 Zellmodi:

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

Trotz 1bpp hat der 320 Pixel Modus "F" aber nur "1.5" statt 2 Farben, genauer einen "Chroma" Farbton in zwei "Luma" Helligkeitsstufen. Dies weil Atari in Pixelpaare als Vollwellen vom NTSC Farbträger Signal rechnet, welche 14.31818/4=3.5796MHz sind, und daher keine Halbwellen zulassen will. Weshalb sie bei 320 Pixel nur eine Wellenform an "Chroma" mit zwei Signalstärken an "Luma" zulassen.

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

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

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

Mit der ANTIC Displayliste sind zudem für die möglichen 240 NTSC Zeilen (die extra PAL Zeilen sind stets leer) ihre Modi und diverse Optionen beliebig zeilenblockweise mischbar. (Der ANTIC wird von Atari selber mit "resembles a small dumb microprocessor" beschrieben, was aber bei manchen Fans zu "is a true microprocessor" übertrieben wird. Real kann er nur genau aus der Displayliste ein internes Modusregister sowie zwei Adressregister vorzu nachladen. Womit die Displayliste eher eine Art von Formatierangeben sind, und der ANTIC deren Auswerter.)

Damit an Formatierungen einstellbar sind:

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

Farben wieder mit Register auswählbar aus 16*8=128 (16 NTSC Farbtöne und 8 Helligkeitsstufen, vermutlich die identischen wie im VCS/2600) (ausser GTIA bei "$40" mit 16 Helligkeiten). Hat 1 Register für Bildrand (und in 2bpp sowie 4-Farben 1bpp Modi auch Bild/Spielfeld Hintergrund), 4 für Bild/Spielfeld Vordergrund (und in "1.5" Farben 1bpp Modi auch Hintergrund), 4 für die 4 Player, keine separate Missiles (alle 4 nehmen die Farbe ihres passenden Players, bzw alle Missiles als fünften Player zusammengelegt nehmen die vierte Bild/Spielfeld Vordergrund Farbe), zusammen 9 Farben. Während Spielfeld und Sprites automatisch vom ANTIC geladen werden, kann man wechselnde Farben nur in Software machen (wie VCS/2600), weshalb dessen "streifigen" Farben blieben, oder nur wegen Aufwand meiden verschwanden. Bei 320*1 oder 160*2 oder 80*4 oder 40*8 von 14.31818/2=7.1591MHz Pixeltakt ein 44.7µs breites Textfeld (Narrow 256*1 ein 35.8µs sehr schmales, Overscan 384*1 ein 53.6µs überbreites).

Die PAL Version vom GTIA (es gab keine PAL CTIA) ersetzt die 14.31818MHz mit 17.734472MHz. Damit werden die 16 Farbtöne in schnellere und auch leicht anderst geformte "Viertelwellenpixel" Muster umgesetzt. Man beachte dass die Videodaten beim 800 nur zwischen Farbregister schalten (wie Apple II "Low Resolution"), nicht selber die NTSC Muster beinhalten (wie Apple II "High Resolution"), daher ist die eigentliche Mustererzeugung beliebig ersetzbar. Wegen Software kompatibel bleiben wird der Prozessor von NTSC 14.31818/8=1.79MHz auf PAL 17.734472/10=1.77MHz nur leicht verschoben (Pixel damit von 7.1591MHz auf 7.0938MHz). Auch die extra Bildzeilen werden fest auf Leerzeilen gesetzt, damit die Displayliste gleich lang bleiben kann.

Damit sind aber bei PAL die 160 Pixel an Wellen (bzw 320 an Halbwellen) gar keine solche mehr, weil schnellere Wellen! Es funktioniert aber trotzdem, weil die Analogelektronik vom Monitor auch mit Wellenbruchstücken zurecht kommt. Schliesslich richten sich Kanten im einem Bild vor einer Fernsehkamera auch nicht nach deren Wellen aus, zumal diese je nach Farbton ohnehin in anderer Phase liegen und damit an anderem Ort in der Bildzeile stehen! Weshalb man sich ernsthaft fragt, warum Atari bzw Designer Jay Miner darauf bestand, die Pixelrate genau auf die NTSC Farbwellenhälften auszurichten, mit dazu Prozessor von seinen 2MHz auf 7/8 Takt von 1.79MHz gebremst, statt 14.31818/7=2.0454MHz zu nehmen.

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

Texas Instruments TMS9918 VDC Chip (1979)

Kein Rechner oder Spielkonsole, sondern ein generischer Videochip, in diversen Geräten verwendet. Später kamen erweiterte TMS9918A, sowie flexiblere TMS9928A und TMS9929A mit 60Hz bzw 50Hz YUV Signalen statt nur 60Hz NTSC Composite. Zuerst erschienen im Homecomputer TI-99/4 (1979, mit originalem TMS9918), sowie TI-99/4A (1981, erweiterte TMS9918A). Ebenso letztere im Coleco ColecoVision (1982, Konsole) und Adam (1983, Homecomputer). Ebenso im Sega SG-1000 (1983, Konsole) und SC-3000 (1983, Homecomputer). Am bekanntesten aber in all den MSX Geräten (ab 1983).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bitmap ist abgestuft (wie Atari 800). Als "R" (Resolution) mit 128x64 128x96 128x192 oder 256x192 1bpp, nur in Schwarzgrün oder Schwarzweiss zur Auswahl. Oder als "C" (Color) mit 64x64 128x64 128x96 oder 128x192 2bpp, mit nur obigen 4er Farbsätzen, und damit ohne Schwarz!. Mit zudem bei beiden den Bildrand ebenfalls 1=Grün bzw 1=Weiss (statt 0=Schwarz wie bei Text oder Blockgraphik). Was nervt, zumal der Gn+Ge+Bl+Rt Satz der "bessere" ist (der Ws+Cy+Mg+Or ist zu hell), und davon Blau am dunkelsten wäre für Hintergrund, was nicht zu Grün Rand passt, und somit zu vielen Spielen mit Grün Hintergrund fürhte.

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

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

Auch mit VDG und SAM unpassend zu einander konfigurieren könnte man den 32x16 Textmodus auf 32x24 verbessern, mit SAM nur 8 mal statt 12 mal selbiges Zeichen aus dem RAM holen. Aber dies scheitert am eingebauten Font, von dem dann einfach die unteren 4 Zeilen abgeschnitten werden. Strikte kann dies mit einem externen Font ROM gelöst werden, aber solcher ist zumeist nicht vorhanden, weil es dazu einen separaten ROM Chip brächte statt einfach aus dem vorhandenen System ROM nehmen (wie Atari 800 es machen tut).

Damit der schwächste Chip in dieser Liste, sogar unterhalb von einigen TTL Rechnern. Das pure Gegenteil zur TMS9918, welche aufs Maximum hinaufgezogen wurde, mit hier nur das Minimum gemacht, auf TRS-80 seinem unteren 32x16 Niveau, nur 64er ROM Font und damit mischbare 2x2 bzw 2x3 Blockgraphik, plus letztere mit mehr oder weniger Farben, plus etwas Bitmap mit keinen oder wenigen Farben.

Commodore VIC-1001 (1980) bzw VIC-20/VC-20 (1981)

Einzelner Chip VIC (Video Interface Chip). Eigentlich von MOS Technology als generischer Videochip (NTSC MOS6560 und PAL MOS6561) für beliebige Kleinterminals und Geräteanzeigen sowie Spielkonsolen besser als dem VCS/2600 gedacht. Wie diesem auch Audio mit eingebaut. Stand damit als Standardchip in direkter Konkurrenz zur MC6847. Wie diesen mit Bild aus dem normalen SRAM oder DRAM Hauptspeicher.

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

Wegen 2MHz Bandbreite vom Speicher (1MHz für Prozessor und 1MHz für Video) wurden, um Zeichencodes plus Font zu holen ohne den Prozessor 40% der Zeit anzuhalten um "Snow" zu vermeiden, die PET/CBM 40x25 Zeichen beim VIC auf 20x25 halbiert. Aber dann wird für etwas weniger schlimm im VC-20 das Bild auf 22 verbreitert, mit dafür aber die Zeilen von 25 auf 23 reduziert, damit es immer noch in halbe 512Bytes passt. Das ergibt nur 22x23 Zeichen. Die schlechteste Eigenschaft vom VIC Chip, und der häufigst genannte Grund um keinen VC-20 zu kaufen, der Commodore vermutlich die Verkaufsmenge halbiert hat!

Hat nur 1 Zellmodus. Aber sowohl 8x8 1bpp (wie Atari 800 Zell "2" und TMS9918trotz Zeichencodes plus Font holen nur die Hälfte vom etwa 2MHz Speichertakt, aber zum Preis von nur 22 noch Zeichen (nahe Atari 800 Zell "6" nur 20). ROM hat 2x2 Blockgraphik (gibt 44x46) sowie alle PET/CBM Graphikzeichen darin (beide Fonts davon). Aber mit Font aus RAM erlaubt wieder spielespezifisch ersetzen, und somit selbst bei 2bpp noch 88x184 Pixel. Tastatur hat auch alle Graphikzeichen drauf, aber weil weniger Tasten, 2 solche pro Taste, mit zweitem Shift mit Commodore Logo drauf. Hat auch den PET/CBM Bildschirmeditor.

Dazu aber einen separaten 1kx4bit Farbspeicher (und somit strikte 5+0.5=5.5kBytes Speicher im VC-20) mit Vordergrund Farbattribut, was Farbzellen erlaubt. Mit dazu die identischen unteren Adressbits A0..A9 nutzend, womit dies strike ein 8+4=12bit Videochip ist! Jedes Zeichen hat mit 3 der 4 extra Bits ein eigenes von 8 NTSC Vordergrundfarben (sowie ganzer Hintergrund ein weiteres von 16, sowie Rand eines von den ersten 8, das dort fehlende Bit reversiert das ganze Bild), diese als Farbton+Helligkeit Kombinationen ohne separate Helligkeitsstufen (genauer sind sie beinahe-RGB, in Reihe Schwarz Weiss Rot Cyan Magenta Grün Blau Gelb, dann nur Hintergrund noch Hellbraun und Pastellbraun sowie Pastelle der Rot bis Gelb). Das erlaubt 256 Zeichen Font mit 8 Vordergrund Farben zu kombinieren.

Dazu kommt mit dem verbleibenden 1 der 4 extra Bits zeichenweise(!) die 1bpp/2bpp umschalten, mit dann 3 statt 1 Hintergrundfarben (obiges Hintergrund und ein "Auxillary" von allen 16, und die Randfarbe von 8). Dies statt dem Atari 800 Zell "6" seinen nur 64 Zeichen mit 4 Vordergrund Farben und diese nur in 1bpp (und nur 20 pro Zeile), bzw Zell "4" mit 2bpp aber nur 4 Farben pro Zeichen, oder der TMS9918 seine 256 Font mit 2*16 Farben aber massiver Speicherbandbreite (und gar kein 2bpp), sowie Farben entweder nur 32 Paare oder pro 8x1 mit massivem Speicherverbrauch. Wovon hier sowohl farbige plus reverse Textausgabe sowie vor allem Spiele massiv profitierten.

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

Damit hat dieser genau den flexiblen Zellmodi mit ladbarem Font Ansatz, mit vollen 256 Zeichen plus 8 oder 16 Farben, plus Wahl von 1bpp oder 2bpp, aber ohne Exzess, wenn auch ohne Bitmap. Das ist total ausreichend, es ist sogar überraschend gut. Praktisch alle guten 1980er Chips bauen auf einer vergleichbaren Kombination auf.

Nur die wegen Bandbreite sehr niedrige halbierte horizontale Auflösung ist massiver Schwachpunkt vom VIC. Und der geringe SRAM Speicher der massive Schwachpunkt vom VC-20. Alleine die Auflösung verdoppeln, durch 1 der 5 kByte als separaten 1kx8bit Bildspeicher (wie PET/CBM) verwenden (40x25=1000 Bytes in einem 1k wären ohnehin Zeichencodes), und dann nur den Font via Systembus von ROM/HauptRAM holen, was auch bei 40 Zeichen in dessen Bandbreite passen würde, und der VIC wäre ein sehr guter Chip gewesen. Dazu noch 16k DRAM statt den restlichen 4k SRAM (gleiche Anzahl 8 Chips), und der VC-20 wäre ein sehr guter Rechner gewesen. Noch besser wenn bei 16k (oder gar nach +16k Erweiterung) sogar mit font-artigem Bitmap Modus (wie TMS9918 "Graphic 2"), weil das wäre bereits ein spriteloser Commodore 64 gewesen!

(Es gab sogar real einen geplanten zum originalen VIC pinkompatiblen Nachfolger VIC-1.5 (NTSC MOS6562 und PAL MOS6563), der für einen VIC-40/VC-40 Rechner mit 40 Zeichen und 16k DRAM gedacht war. Dies sogar ohne separatem 1k Bildspeicher, wegen in unveränderter Schaltung laufend mit einem eine Zeile langem Schieberegister Buffer (wie Atari 800 im ANTIC). War auch als Aufrüstsatz aus Austausch VIC-1.5 + ROM für den VC-20 vorgesehen. Diese hätten auch die doppelten 40x25 gehabt, mit VIC Farbsatz, aber ohne Bitmap und auch ohne Sprites. Dies wurde aber abgesetzt, wegen schwächer als VIC-II, und statt dessen der Commodore 64 gemacht.)

Sinclair ZX80 (1980)

Absoluter Minimalstrechner, mit dem Ziel designt, billigst möglicher Rechner zu sein, anfangs 100 (Bausatz 80). Daher nur ein Schritt oberhalb eines Hextasten plus 7-Segmentanzeige Maschinencode Lernsystemes, quasi ein Basic Lernsystem. Hat neben Z80A Prozessor und 1* 4k ROM und 1* Paar 1kx4 SRAMs sowie 7805 Spannungsregler noch genau 17 TTLs, keine Customchips. Dementsprechend extremst primitiv.

Nur 1 Textmodus. Text 32x24. Mit 8x8 1bpp Font. Aus festem ROM Satz, von 64+revers Zeichen. Bei 32*8=256 von 6.5MHz Pixeltakt trotz nur 32 Zeichen ein mittleres 39.4µs Textfeld. Trotz nur 64er Font mit 2x2 Blockgraphik und 1x2 Matrixgraphik, womit sogar nur einen Teil von ASCII64 drin ist. Zeichensatz gibt: 1 Leerzeichen, 7 Block 3 Matrix 17 Sonderzeichen " £ $ : ? ( ) > < = + - * / ; , . 10 Ziffern 0..9 26 Buchstaben A..Z). Um die 7 Block 3 Matrix unter zu bringen fehlen somit von ASCII64: ! # % & ' [ \ ] ^ _. Nur in Schwarzweiss. Dazu passend nur Folientastatur mit lediglich 40 Tasten. Trotz geringer Anzahl Tasten mit einzelnen Graphikzeichen drauf, wie PET/CBM, mit Shift benutzt. Ebenso Gehäuse kein Kunststoff Spritzguss, sondern nur Plastik Tiefzug wie bei einem Joghurtbecher, daher auch keine Schrauben benutzbar, sondern mit Laschen zusammengeklipst.

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

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

Zeichen mit Bit6=1 (64..127 und 192..255) werden aber vom Videogenerator ausgelassen (und als Leerzeichen ausgegeben), ohne den NOP Generator zu aktivieren somit an den Prozessor durchgereicht. Um Platz im nur 1k grossen Speicher zu sparen werden Zeilen ohne rechts verbleibende Leerzeichen gespeichert, mit stattdessen einem HALT Befehl (118, Hex 76, Bit6=1) beendet, der den Prozessor ohne weiteren Bytes zu holen in eine interne NOP Endlosschleife schickt. Gezeichnet wird Video somit bei A15=1 und Zeichen Bit6=0 und Prozessor nicht HALT Zustand und Zyklus=M1. Voller Bildspeicher ist 1+24*(32+1)=793Bytes, minimaler aber nur 1+24*(0+1)=25Bytes. Je mehr Platz der Benutzer für Programm und Variablen verwendet, umso weniger alte Zeilen verbleiben bevor der Rechner sie aus dem Bildspeicher wegkürzt, trotz noch Bildschirmzeilen Platz frei haben! Weshalb auch die Kommandozeile sich stets auf der unteren neuesten Zeile befindet. Ist der (erweiterte) Speicher mehr als 3.25k, werden alle Zeilen stets als (32+1)Bytes gespeichert, egal was ihr Inhalt ist.

Für das Ende der Zeile erkennen, egal wieviele Bytes bis zum HALT waren, zählt das zuvor passend präparierte R Register des Refreshzählers bis es auf A6=0 überläuft, was automatisch einen INT Interrupt generiert. Das ohne jegliche Logik weil der INT=0 Test der Z80 nur stattfindet während R am ausgegeben werden ist. Damit wird der Refreshzähler als 7bit Timerinterrupt missbraucht, wonach der Prozessor zwar nicht meht HALT Zustand hat und einen M1 Zyklus macht, aber die Interruptroutine wieder aus dem ROM an 0000..0FFF liest, womit ohne A15=1 nichts mehr ausgegeben wird und der Prozessor alles bekommt, egal was für Datenbytes. Dabei wird auch die Bildsynchronisation in Software erzeugt, durch das Z80 Interrupt bestätigen Signal einen Horizontalpulsgenerator anstossen. Die Videozeile in Zeichenzeile wird aber in Hardware 0..7 gezählt, welche von obigem Horizontalpuls +1 geht, und vom Software generierten Vertikalpuls auf 0 synchronisiert wird. Das alles kostet die ganze Rechenleistung, erlaubt entweder nur Bild anzeigen ohne Software ablaufen, oder nur Software ablaufen ohne Bildausgabe oder auch nur Syncpulse, weshalb das Bild nach jeder Taske oder zuckt weil der Fernseher neu synchronisiert.

Strikte ist damit die Auflösung nur von der Software her gegeben. Es können nur mit mehr HALT Befehle ablegen und anderen Schleifen Konstanten in Register laden auch mehr als 24 Zeilen ausgegeben werden. Ebenfalls mit mehr Zeichen bis zu den HALT Befehlen und Rücklaufzeit Routinen kürzen mehr als 32 Zeichen. Mit Quarz auf 8MHz statt 6.5MHz steigern und Software anpassen könnten sogar 40x25 drin liegen. Zumal das Problem mit 40 Zeichen pro Zeile keine 2^n sein hier sogar irrelevant ist, weil die Zeichencodes als Programm lesen mit dem Programmzähler praktisch auf einen separaten Adresszähler wie in der 6845 hinausläuft! Und mit den variabel langen Zeilen wegen ohne rechts verbleibende Leerzeichen würden alle Zeilen unter 33 Zeichen nicht mal mehr Speicher brauchen. Weshalb man sich fragt, warum auf 32 limitiert wurde, und um ein deswegen zu schmales Bild zu meiden der Prozessor von 8/2=4MHz auf 6.5/2=3.25MHz um 3/16=18.75% ausgebremst wurde.

Dazu gibt es noch einen undokumentierten Bitmapmodus. Dieser besteht darin, den "Font" mit I und R aus dem RAM statt ROM auszulesen, wobei obige nur-ROM Einfügelogik eben versagt, Zeichencode und Videozeile in Zeichenzeile ignoriert werden! Da aber damit R Teil der Adresse ist statt Timer, muss man mit einer eigenen Ausleseroutine arbeiten, welche I und R passend setzt, und direkt 32 NOPs liefert (welche auch gleich Bit6=0 zeichnen und Bit7=0 nicht reversieren haben), und Zeilenrücklauf abwarter, dann ab I und R neu setzen wiederholt. All das ohne Halt, weil ohne Interrupts eingeschaltet, weil ohne R als Timer, und so wird auch vermeiden in der normalen Routine zu landen. Bit0..5 werden ohne die Einfügelogik ignoriert, weil nur das ROM diese zu sehen bekommt, nicht aber das RAM, welches eben R bekommt, damit das Bitmap holt. Dazu muss R anderst präpariert werden. Dies erzeugt sogar einen echten 256x192 Bitmapmodus. Nur reichen die internen 1k SRAM nirgendswo hin, weil dazu (256/8=32)*192=6k an Bildspeicher gebraucht werden. Und die externen Speichererweiterungen machen dabei zumeist nicht mit, ausser man modifiziert sie (nur 2 Dioden und einen Widerstand addieren), damit sie auch bei Refreshzyklus einen Lesezyklus machen. Aber dies ist mit Quarz auf 8MHz inkompatibel, ausser man legt die Zeilen als 3*40=120 + 8 unbenutzte in 128 ab, weil R nur Bits0..6 zählen kann.

(Der Nachfahre ZX81 (1981) lieferte gleichen Prozessor und Takt sowie doppelt grosses 1* 8k ROM (mit Basic um Fliesskomma erweitert) und 1* 1kx8 SRAM und 7805. Weiterhin mit Folientastatur, Gehäuse ist jetzt ein Kunststoff Spritzguss. Aber er verfrachtete alle 17 TTLs in ein ULA (Uncommitted Logic Array) Gate Array Semicustomchip um noch billiger zu sein, anfangs 70 (Bausatz 50). All das sogar 100% kompatibel, weshalb auch das ZX81 ROM (plus passendes Folientastatur Overlay wegen erweiterten Basic Befehlssatz und umgeordneten Graphikzeichen) für die ZX80 als Nachrüstsatz verkauft wurde. Aber das ULA hat zudem eine Erweiterung, um das Video HSync Signal in Hardware zu erzeugen, vom Timerinterrupt synchronisiert, sowie mit einem vom HSync angestossenem NMI Interrupt getriebenen Multithreading abwechselnd zwischen Program rechnen, Video Bild ausgeben, Program weiter rechnen, Video VSync Signal erzeugen, statt nur Bild ohne Software oder Software ohne Bild. Das ergibt dann 2+24*8=194 Zeilen Anzeige plus 6 Zeilen VSync sowie 54+56 Zeilen rechnen, von insgesammt 310 Zeilen, davon in den 54+56 Zeilen 58 Takte NMI sowie 149 Takte rechnen, von insgesammt 207 Takten, lässt somit 110/310 * 149/207 = 25.54% vom 3.25MHz Takt, also effektive 0.83MHz. Die dazu genutzten "FAST" und "SLOW" Modusschaltbefehle sind auf ZX80 mangels NMI Aktivierungsschaltung einfach wirkungslos. Es gibt aber eine 5 oder 6 TTLs (je nach ob man genaues Timing duplizieren will) umfassende Erweiterung welche diese dort nachrüstet. (Womit die ULA etwa 17 + 5 oder 6 = 22 oder 23 TTLs entspricht.))

Osborne 1 (1981)

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

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

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

IBM Monochrome Display Adapter MDA (1981)

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

Nur 1 Textmodus. Text 80x25. Mit grossem 9x14 1bpp Font. Aus festem ROM Satz, von 256 Zeichen. Braucht dazu einen separaten MDA Spezialmonitor der die resultierenden 720x350 anzeigen kann. Scheidet damit strikte hier aus, wird aber wegen Vorbereitung zur CGA sein drin gelassen. Keinerlei Graphik ausser Graphikzeichen. Darunter zwar auch 1x2 und 2x1 Blockgraphik aber trotz 256 Zeichen keine 2x2 (es gibt also doch nur maximal 80x50, bzw 160x25).

Aber mit 8bit Attributen, als (1+3)+(1+3)bit, mit Hintergrund (Bits 7..4) und Vordergrund (Bits 3..0) je 3 Graustufen (0,7,15) was "1.5bpp" ergibt (manche Monitore erlauben noch 8 als vierte Graustufe, was volle 2bpp ergibt) und weiteres Unterstreichen Attribut. Hintergrund Bit7 ist mit Mode Control (MC) Register Bit5=1 umschaltbar zu nur noch 2 Graustufen (0,7) plus blinkend. Vordergrund auf 1 oder 9 setzen wirkt wie 7 oder 15, aber mit Unterstreichen addiert. Ist damit strikte 8+8=16bit Video, aus eigentlich 2k 16bit Worten an SRAM!

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

(Leider wird trotz so vielen Attributbits keines als Modus Attributbit benutzt, für ohne Font hartverdrahtete aber damit mischbare 2x4 Blockgraphik (wie Microtan 65 es macht, mit 9bit SRAM für 64x64 Blöcke in 32x16 Zeichen ). Das wären hier mit 80x25 Zeichen dann ganz ordentliche 160x100 Blöcke. Ebenfalls gibt es kein Font aus SRAM (wie Sorcerer). Damit nur als reines Textterminal nutzbar.)

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 Bildspeicher aus DRAM (wie TMS9918), daher auch asynchron und nicht Prozessor bremsend. Aber mit Adressen vom Prozessor, auch dessen Adressmodi ausnutzend (ungleich TMS9918, als entscheidender Vorteil). Für Timing und Adressen auch MC6845 Chip, Datenpfad TTL, keine Customchips, aber einiges mehr TTL als MDA, daher noch ziemlich primitiv. Kann wegen von der MDA verschiedenem Adressbereich von Bildspeicher und Steuerregister (B800:xxxx und 03Dx) zusammen mit einer MDA (B000:xxxx und 03Bx) im gleichen Rechner sein, für Dualhead mit Text+Graphik!

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

Text 40x25 oder 80x25. Mit 8x8 1bpp Font. Aus festem ROM Satz, von 256 Zeichen. Bei 40*8 bzw 80*8 Pixel von 7.1591MHz bzw 14.31818MHz Pixeltakt ein breites 44.7µs Textfeld (wie Atari 800). Auch hier unnötige Prozessorbremse, weil die 8088 im PC deswegen von seinen 5MHz auf 4.77MHz reduziert wurde, nur um einen Quarz zu sparen, der erst noch bei MDA nicht mal eingespart wird! Hat trotz 256 nur 1x2 oder 2x1 Blockgraphik aber kein 2x2(!) darin (gibt also doch nur maximal 80x50 bzw noch 160x25).

Dazu aber 8bit Farbattribute, als (1+3)+(1+3)bit, mit Hintergrund (Bits 7..4) und Vordergrund (Bits 3..0) je 16 RGBI Farben (bzw hier als IRGB angeordnet), was Farbzellen erlaubt. Hintergrund Bit7 ist mit Mode Control (MC) Register Bit5=1 umschaltbar zu nur 8 RGB plus blinkend statt intensiv. Kein Unterstreichen. Ein einzelnes Color Select (CS) Register liefert in Bit3..0 die IRGB Randfarbe. Ist damit wieder strikte 8+8=16bit Video. Wieder ohne mischbare 2x4 Blockgraphik. Ausser Attributen und Farben kompatibel mit der MDA.

Aber hat im Gegensatz zur MDA kein 8+8=16bit SRAM, nur 8bit DRAM. Was dann bei den 80 Zeichen Breite und 2 Bytes pro Zeichen nach 3.579646MHz an Speicherbandbreite (wie TMS9918) verlangt, nur für die Videoausgabe alleine, ohne einen Prozessorzugriff! Was dann bei Prozessorzugriffen kollidiert, und mangels Videodaten kurz ausnullen zu "Snow" führt. Strikte kann man bis zum Ende der Bildausgabe warten (wie PET/CBM), aber das verlangsamt ebenfalls zeichnen und wird daher von Fremdsoftware oft nicht gemacht, oder war bei mancher sogar als Option einstellbar.

Bitmap 320x200 2bpp in 1*IRGB-Register+festen-3er-satz. Braucht die ganzen 16k Bildspeicher an Bitmap, und hat daher keine Farbattribute mehr (aber auch mangels diese lesen kein "Snow" mehr). Somit nur feste Farbsätze. Mit MC Bit2=0 und CS Bit5=0 Gn+Rt+Ge = RG(B=0) bzw Bit5=1 Cy+Vt+Ws = RG(B=1) oder mit MC Bit2=1 Cy+Rt+Ws (G=B). Mit CS Bit4=1 alle drei mit Intensiv addiert. Die CS Bit3..0 IRGB liefern hier neben Randfarbe auch für Pixel=00 Hintergrund. Das ist aber sehr limitierend, weil ohne 00=Schwarz gesetzt hat man kein solches in allen drei Sätzen! Und den Rand will man ohnehin Schwarz haben. Am ehesten war noch der Gn+Rt+Ge Satz mit Hintergrund=Blau nutzbar. (Das entspricht dann genau dem MC6847 "C" Bitmap mit Gn+Ge+Bl+Rt Satz, nur mit Blau Rand und Hintergrund, sowie 320x200 statt 128x192 Pixel.) Also keine echte Farbauswahl.

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

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

Hat viel Speicher und hohe Auflösung. Aber die beiden Bitmapmodi liefern weder viele bpp noch ordentliche Farbwahl, mangels Farbattribute. Und der Textmodus kann weder mit guter Blockgraphik (wie Microtan 65) noch mit Font aus SRAM (wie Sorcerer) aushelfen, weil nur selbiges ROM mit 1x2 und 2x1 der MDA. Egal was man hier versucht, es fehlt stets genau das was gute Spiele erlaubt!

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

(Der IBM PCjr (1984) addierte den bei der CGA fehlenden naheliegenden 160x200@4bpp Modus, mit doppelter Menge der "Tweak Mode" Pixeln, und als gerades Bitmap formatiert, und offiziell. Mit Bild aus dem normalen DRAM Hauptspeicher, bzw strikte dem erweiterten CGA Speicher von 64k statt 16k, mit 48k von diesem als Hauptspeicher! Zudem nochmals verdoppelte 32k Modi 320x200@4bpp und 640x200@2bpp, sofern wegen Bandbreite 16bit Speicher von 2*64=128k vorhanden ist, mit dann 96k als Hauptspeicher. Separate +128k Hauptspeicher konnte per Modul addiert werden. Mit 4 oder 16 Farben aus 64. Eigentlich bestes Video bisher. Zudem addierten sie für Audio einen SN76496 Soundchip. Das alles in einem kleinen und billigen auf den Heimmarkt gezielten 8088 PC Subset. Das hätte ein grosser Erfolg werden können, oder gar sein sollen. Nur war die "Freeboard" Tastatur ein komplettes Fehldesign, mit tippfeindlichen verkleinerten "Chicklet" Tasten (damit Schablonen dazwischen passen), sowie der namensgebenden unzuverlässigen und batteriesaufenden Infrarot Kabellosverbindung (damit im Raum bewegbar). So wurde der PCjr zum massiven Flop, und konnte sich auch nach Tastatur ersetzen nicht mehr erholen.)

(Tandy hat als Nachfolger der TRS-80 Serie auf IBM kompatibel gesetzt. Sie haben PC+CGA mit PCjr verglichen und sich für den Tandy 1000 (1984) auf PCjr kompatibel entschieden. Nach dessen Flop hat Tandy wohlweislich verschwiegen, dass sie dazu kompatibel sind, und die Kritik an nicht ganz PC kompatibel sein weggesteckt. Wegen billig und ordentlich wurde dieser zum erwarteten Erfolg. Wonach die erweiterten PCjr Videomodi sogar als Tandy Graphics Adapter TGA (bzw teils auch Tandy Color Graphics Adapter TCGA) bekannt wurden!)

Acorn BBC Micro (1981)

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

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

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

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

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

Kein fein scrollen, aber mit 160@4bpp sind ganze Bytes nur 2 Pixel und somit 80 Positionen horizontal, was dies grossteils kompensieren kann. Für 160 Positionen kann mit 2 Kopien von vorgeshifteten Elementen gearbeitet werden. Keine Sprites, aber kann dies mit dem 4bpp Bitmap kompensieren (wie PCjr) im Gegensatz zur CGA, mit dazu nur leicht mehr Shiftregister Logik und Umschalter (unter +10%). Genau dieses kleine Mehr macht den Unterschied aus, von der CGA schrottig zum BBC anständig und modern!

(Weitere Limite ist aber, dass mehr als 160 Pixel nur mit Reduktion auf 2bpp oder gar 1bpp machbar sind. Nett wäre 320 Pixel als 8Pixel@1bpp plus 2*4bit Farbattribute (wie TMS9918 "Graphic 2") statt als 8Pixel@2bpp ohne Attribute, für alle 16 Farben mit 40 Zeichen (wie CGA Text 40x25), oder gar beide Varianten zur Auswahl. Diese Verbesserung wäre mit nur dem Datenpfad ULA Gate Array Semicustomchip leicht erweitern machbar gewesen. Auch fein scrollen wäre nur eine leichte Erweiterung dort.)

Hercules Graphics Card HGC (1982)

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

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

Kaypro II (1982)

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

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

Vielmehr werden die 80 Zeichen pro Zeile mit einem einfachen Schalter auf Adressbit6 in 64+16=80 zerteilt, und diese nichtlinear in den 2k Bildspeicher abgelegt. Zuerst 64x24 in den ersten 1.5k und dann 3von4* 16x8 in den verbleibenden 0.5k (mit so 1* 16x8 unbenutzt). Wegen separatem SRAM gehen Prozessor und Video Adressen aber durch den selbigen Schalter. Also erscheint dies dem Programmierer einfach als einen linearen 4k Block, mit 128x32 Zeichen (wie Osborne 1), aber diese mit den Zeichenpositionen von 64 bis 127 vierfach wiederholt aus den letzten 0.5k, und den Zeichenpositionen 0 bis 63 der Zeilen von 24 bis 31 ebenfalls mit je 3 Zeilen von obigen (und einem der unbenutzten 16er). (Dieser Ansatz wurde in der wegen Firmenuntergang von Processor Technology nie verkauften VDM-2 auch so gemacht. Was vom Designer Ende 1979 veröffentlicht wurde, und vermutlich dann durch Kaypro kopiert. Der VDM-2 Designer selber hat danach aber den Osborne 1 mit dessen vollen 128x32 ohne Schalter aus 4k vom DRAM gebaut.)

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

Commodore 64 (1982)

Anfangs als Spielkonsole Max-Machine (bzw Ultimax oder VIC-10) mit nur 2k SRAM Speicher designt. Aber dann erweitert und umpositioniert als Nachfolger vom VIC-20/VC-20 und mit 64k DRAM verkauft. Er verdrängte so den schwächeren geplanten Nachfolger VIC-40/VC-40 mit VIC-1.5 Chip und 16k DRAM.

Einzelner Chip VIC-II (Video Interface Chip II), als erweiterten VIC des VC-20. Daher ebenfalls ein generischer Videochip (NTSC MOS6567 und PAL MOS6569). Mit Bild aus dem normalen DRAM Hauptspeicher. Wenn auch wieder nur von Commodore genutzt, im C64, aber auch im P500 (ein Teil der CBM-II Serie) (der Educator 64 bzw PET 64 bzw PET 4064 war dagegen ein C64 im CBM 4000er Gehäsuse). (Die Max-Machine ihre nur-NTSC MOS6566 benutzt hingegen aus dessen SRAM, der P500 Prototyp hatte auch noch diesen drin.)

Hat alle guten Eigenschaften vom VIC geerbt, aber alle seine Schwächen abgelegt. Insbesondere die horizontal zu niedere halbierte Auflösung von 22x23 (oder 20x25) wieder auf 40x25 verdoppelt (das hätte der VIC-1.5 vom VC-40 auch gemacht, aber genau nur das). Zudem kamen weitere nette Sachen dazu, wie Bitmap und Sprites. Die Designer hatten gezielt die Features anderer Chips und Rechner verglichen, und daraus ihre Wunschliste erzeugt. Die Sprites wurden explizit wegen der TMS9918 addiert, und oft auch so benamst (offiziell heissen sie aber Movable Object Blocks). Audio wurde in den separaten SID (Sound Interface Device) ausgelagert, der spezifisch als Musikinstrument und nicht nur als Tonerzeuger designt wurde.

Er hat Umschaltbar 3 Zellmodi und 2 Bitmapmodi:

Zell immer 40x25 Zeichen (wie PET/CBM), und somit den massiven VIC Schwachpunkt an horizontaler Auflösung korrigiert. Hat zwar nur die selbige 2MHz Speicherbandbreite (1MHz Prozessor und 1MHz Video). Aber das reicht zumeist ohne Prozessorbremse für 40 Zeichen, mit pro Videozeile lediglich in 1MHz den Font holen, weil die Zeichencodes nur in der ersten Videozeile eines Zeichens mit 2MHz geholt werden müssen (wie Atari 800 Zellmodi "2" bis "5"), mit sie danach aus einem internen Buffer von 40*8bit Zeichencodes (und auch noch 40*4bit Farbcodes) wiederholen. Dies kostet dem Prozessor bei 40/65 Zeichenzugriffe * 200/312 = 40% Ausgabezeit nur 1/8 * 40% = 5% an Leistung. Diese Anhalter sind hier als die 1/8 * 200 = 25 "Bad Lines" bekannt.

Dies mit reinem 8x8 1bpp Modus, oder aber gemischtem 8x8 1bpp 4x8 2bpp "Multicolor" Font (wie VIC). Aus variablem ROM/ModulROM/HauptRAM Satz (wie Atari 800), von 256 Zeichen (wie TMS9918 und VIC). ROM hat 2x2 Blockgraphik, sowie alle PET/CBM Graphikzeichen darin (beide Fonts davon, wie VC-20, aber neu gestaltet mit 2 Pixel breiten vertikalen Linien). Aber mit ModulROM/HauptRAM erlaubt wieder spielespezifisch ersetzbar, jetzt sogar ohne von ModulROM ins HauptRAM umkopieren. Hat ebenfalls den PET/CBM Bildschirmeditor.

Dazu wieder einen separaten 1kx4bit Farbspeicher (und somit strikte 64+0.5=64.5kBytes Speicher im C64) mit Vordergrund Farbattribut (wie VIC), was Farbzellen erlaubt. Ebenso mit identischen unteren Adressbits A0..A9 nutzend, womit der VIC-II ebenfalls ein 8+4=12bit Videochip ist (auch wie VIC). Das erlaubt wieder 256 Font mit vollen 16 (bei reinem 1bpp Modus) bzw noch 8 (bei gemischtem 1bpp und 2bpp Modus, zeichenweise wie VIC) Vordergrund Farben zu kombinieren (mit hier leicht andere Farben als beim VIC, selbige Schwarz Weiss Rot Cyan Magenta Grün Blau Gelb, dann Hellbraun aber Dunkelbraun statt Pastellbraun, sowie die Pastelle von Rot * * Grün Blau *, aber dann die * als Graustufen 25%/50%/75% statt Pastell Cyan/Magenta/Gelb). Besser als alle anderen Rechner ihre Zellmodi bisher.

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

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

Bei 40*8=320 Pixel (wie PET/CBM und Atari 800) von etwa 8MHz (NTSC 14.31818/14*8=8.1816MHz bzw PAL 17.734472/18*8=7.880MHz) Pixeltakt ein mittleres 40µs Textfeld (wie 320 vom PET/CBM und 280 vom Apple II). Damit keine/wenige NTSC Farbmonitor 4 Farben Effekte, weil dem etwa 8MHz Pixeltakt seine /2=4MHz Wellen weder auf 14.31818/2/2=3.5796MHz von NTSC noch auf 17.734472/2/2=4.3362MHz von PAL fallen. Das erst recht nicht mit dem revidierten 6von8Pixel Font seinen Zeichen mit 2 Pixel breiten Vertikalen und deren 2MHz Wellen (wie Atari 800). Weshalb man sich erst recht ernsthaft fragt, warum andere so sehr bereit waren, mit auf 7/8 Prozessortakt bremsen 1/8 Leitung zu opfern!

(Vielleicht wegen billigem 14.31818/16=0.895MHz Divisor bei NTSC, aber bei PAL ohnehin einem aufwendigeren 17.734472/20=0.8867MHz. Während C64 bei PAL den identisch kostenden 17.734472/18=0.985MHz benutzt, und bei NTSC konsistent selbigen als 14.31818/14=1.0227MHz (was der Apple II auch schon hatte). (VC-20 reversierte dies sogar, mit NTSC 14.31818/14=1.0227MHz und PAL billigeres 17.734472/16=1.1084MHz.) Oder weil sie die Pixelgrenzen genau auf NTSC Farbwellen legen wollten, trotz dass die Farben genau in der Phasenverschiebung der Wellen codiert sind, und dies sowieso bei den kürzeren PAL Wellen versagt.)

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

Hat keine Displayliste, aber die aktuelle Zeilennummer ist auslesbar. Zudem ist sie mit automatischem Vergleich auch als Rasterinterrupt nutzbar. Dieses plus jederzeit Moduswechsel durch Software erlaubt vieles zu kompensieren (inklusive der Randfarbe vom Overscanbereich umschaltbar machen um Hintergrundfarbe Bänder bis in den Rand hinauszuziehen, oder fein scrollen selektiv einschalten um Bänder zu scrollen). Kann keine Zeilen zusammensammeln, also muss grob scrollen per umkopieren geschehen, und auch keine Bytes an Zeilenende überspringen, also muss was an Platz an einer Kante herausscrollte für die gegenüber gleich wiederverwendet werden. Generell opfert Commodore bzw MOS Technology nur wo gewollt etwas Prozessor um stets Videochip Komplexität und Bandbreite zu sparen.

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

Farben mit Register auswählbar aus 16 festen NTSC Farbton+Helligkeit Kombinationen (vermutlich identische mit VC-20). Hat 1 Register für Rand, 4 für Bild/Spielfeld Vordergrund und Hintergrund, 8 für 1bpp Sprites, 2 geteilte für 2bpp Sprites, zusammen 15, plus den Farbspeicher für jedes Zeichen.

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

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

Sinclair ZX Spectrum (1982)

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

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

Diese Farbattribute aber mit nur alle 8x8 Pixel eine Farbzelle, für 6+0.75k statt 6+6k Bildspeicher, was oft in "Attribute Clash" resultierte, wenn in einem 8x8 Feld mehr als nur 2 Farben gebraucht werden. Was beim TMS9918 trotz auch nur 1bpp wegen dessen 6+6k und davon kleinerem 8x1 Feld weit weniger oft geschieht und dort als "Color Spill" bekannt ist. Sowie bei VC-20 und C64 trotz selbigem 8x8 Feld wegen ihren "Multicolor" 2bpp 4 Farben Modi erst bei mehr als 4 Farben geschieht. Dieses fehlende 2bpp ist wohl die grösste Schwäche dieser ansonsten erstaunlich guten Graphik.

Hat keinen separaten Farbspeicher wie VC-20 und C64, holt die Attribute aus dem Hauptspeicher (wie C64 bei Bitmap, mit den Zeichencodes als Farbcodes benutzen). Muss daher trotz dass er stets Bitmap benutzt (und damit keine Zeichencode Zugriffe braucht) trotzdem vergleichbare Zugriffe machen. Dazu muss er bei jeder Zeile den Prozessor für 6/8 seiner Takte (bzw 12/16 Pixeltakte) stoppen (nur ein Speicherzugriff von 2 Takten (4 Pixel) alle 8 Takte (16 Pixel) ist noch möglich, neben den 2*2 Videozugriffen in 4*3 Pixel). Dies nur falls der Prozessor auf die ersten 16k vom DRAM Speicher zugreift, was als "Waitstates" oder "Contention" bekannt ist.

Dies geschieht bei allen Zeilen, nicht nur jeder ersten Zeile von Zeichen (wie die C64 "Bad Lines"), weil die ULA keinen internen Buffer hat. Beim C64 ist dabei aber der Prozessor für 40µs zu 100% zu stoppen, hier nur von 25% bis 62.5% (zumeist 50%) Verlust, je nach ob der Prozessor nach 3..6 Takten pro Zugriff (zumeist 4) um +2..5 (zumeist 4) auf nach 8 warten muss. Es ist zudem vernachlässigbar wegen entkoppeltem ersten 16k DRAM, mit Basic ROM ungebremst, ausser für die wenigen Zugriffe auf Basic Status und Code und Variablen. Es bremst aber bei Maschinencode um etwa 45%. Was 45% * 32/56 Zeichenzugriffe * 192/312 Zeilen = 16% kostet (C64 40%/8=5%). Das neben ohnehin wegen 7MHz Pixel dem Prozessor um (8-7)/8=12.5% untertakten. Weshalb viele Spiele nach 48k verlangen, nicht nur für mehr Platz für Programm sondern auch wegen voller Geschwindigkeit in den wie ROM ungebremsten erweiterten 32k.

Selbst für 2*(Pixel+Attribute)=4Bytes in 4*3 von 16 Pixeln (Prozessor bekommt 1*4 Pixel) müssen aber für diese 4*3 statt 4*4 die 1Byte Attribute einer Zelle und alle zu diesen passende 8Bytes Bitmap in der gleichen 128Byte DRAM Speicherpage liegen, um Pagemode Doppelzugriffe (nur einmal /RAS Signal und zweimal /CAS) auf die langsamen billigen DRAMs (nur 2MHz) auszunutzen, für trotzdem 5 Zugriffe in etwas über 2us. Was aber in einem massiv nichtlinearen Bitmapspeicher resultiert, vergleichbar zu aber schlimmer als die linear durchlaufenen 3 oder 4 256er Fonts der TMS9918 und C64! Dazu hat es hier die 8 Zeilen eines Zeichens trotz nur 32Bytes Zeilenlänge in 256er Schritten im Speicher abgelegt! Weiterhin wird das DRAM revers mit A0..6 bei /RAS sowie A7..13 bei /CAS angesteuert, womit alle 32 Zeichen einer Zeile in verschiedenen /RAS liegen, trotz in direkt einander folgenden Adressen sein. Was erst den 8 Zeilen eines Zeichens zusammen sein erlaubt, und diese erst noch statt in minimalen 128er Schritten im Speicher gleich in 256er Schritten, um die Adressrechung fuer alle 8 Bytes eines Zeichens zu vereinfachen. Womit die 192 Bitmapzeilen ihre 6kByte in 3 64er Zeilengruppen zu je 2kByte kommen, in Reihe 0,8,16,..,56, 1,9,17,..,57, .. 7,15,23,..63, dann 64..127 und dann 128..192 bis auf 3*2=6k hinauf, dann die Attribute ihre 768Bytes, linear. Womit die oberste Zeichenzeile ihre 8 Bitmapzeilen in Adressen Hex 4000..401F,4100..411F,4200..421F, .. 4700..471F liegen und ihre Attribute in 5800..581F, mit dazu pro Zeichen xx00..xx1F einmal mit /RAS gesetzt und dann 40xx+58xx,41xx+58xx,42xx+58xx, .. 47xx+58xx mit zweimal /CAS gelesen! Die nächsten 7 Zeichenzeilen addieren dann je xx20 zum /RAS.

Mit Softwaretechniken ähnlich denen der VCS/2600, welche hier die Farbattribute von Zeile zu Zeile überschreiben, können diese bis auf 8x1 Pixel aufgeteilt werden. Auch die Randfarbe kann so geändert werden, um Hintergrund Farbbänder bis in den Rand hinauszuziehen. Aber es hat keine auslesbare aktuellen Zeilennummer (wie VC-20), geschweige denn Rasterinterrupt (wie C64), nicht mal Ende der Bildausgabe ist erkennbar (wie PET/CBM und CGA). Einerseits kann solche Software synchronisieren, indem sie vom Bildrücklauf Interrupt getriggert wird. Dieses ist aber nur einmal pro Bild der Fall, muss ab dann durch das ganze Bild ausgeben Zyklen abzählen! Anderseits kann solche Software vorzu synchronisieren, indem sie mit Eingabe liest von nicht vorhandenen Geräten, und dabei mangelns aktiver Datenquelle den Video Lesevorgang mit betrachtet. Dieses kann ausgewertet werden mit spezifischen Pixelmustern sehen statt dem Defaultwert $FF wenn kein Video gelesen wird! Mit Attributen Vordergrund = Hintergrund können diese Muster sogar visuell unsichtbar versteckt sein.

(Der Nachfahre Spectrum 128 hat identisches Video, unterscheidet sich nur durch Erweiterung des Rechners von 64k auf 128k DRAM, welche als 8*16k verwaltet werden, wobei 2*16k davon Bildspeicher sein können, sowie den Bildausgang neben PAL Fernseher auch direktes RGB hat. Von den 8*16k sind 4*16k (inklusive beide 2*16k Video) mit "Waitstates" oder "Contention" und die anderen 4*16k ohne. Zudem addierte er für Audio einen AY-3-8912 Soundchip.)

(Die Nachfahren +2 und +3 von Amstrad nach dem Firmenaufkauf sind auch 128k Modelle, aber die Zuordnung welche 4*16k mit "Waitstates" oder "Contention" sind ist teilweise inkompatibel.)

Jupiter Ace (1982)

Abgeleitet von ZX80/ZX81 sowie ZX Spectrum, weil von ex-Sinclair Leuten designt. Hat gleichen Z80A Prozessor und 6.5MHz Pixeltakt wie ZX80 und ZX81, ebenso gleiche Videoeckdaten und gleiche Tastaturanordnung, ebenso 7805. Aber mit 2* 4k EPROMs statt 1* 4k bzw 1* 8k ROM (und mit Forth statt Basic drin). Mit dazu noch 19 genau TTLs (keine ULA). Also eher ZX80 Technologie denn ZX81. Dementsprechend ziemlich primitiv.

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

Aber hat 3 Paare 1kx4 SRAM Chips statt nur 1 Paar, als je 1k für System und Benutzer, plus 2* 1k separate Bildspeicher als Zeichenspeicher und Fontspeicher (wie Sorcerer). Wegen Fontspeicher ist beim Fontzugriff kein I Register als Basis ausnutzen notwendig (wie ZX80/ZX81). Es muss aber der Font vom System aus ROM in den Fontspeicher geladen (und dabei dekomprimiert) werden, ist dafür aber auch beliebig modifizierbar (wie TMS9918). Nichts in der damaligen Presse hat auf ein derartiges Feature hingewiesen, weil nur von Forth statt Basic gesprochen wurde, aber der Rest vom Rechner komplett ignoriert. Also war dieser völlig überraschend gut.

Der Bildspeicher hat stets Platz für ein volles Bild (brauch nur 32x24=0.75k, restliche 0.25k werden als Buffer benutzt). Daher hat es kein HALT mit Datenbit6=1 um ein Zeilenende erkenntlich zu machen um Speicher zu sparen. Was volle 128+revers Zeichen erlaubt, statt nur 64+revers. Ebenso kein Adressbit6 = 0 vom R Register als Interrupttimer um wieder den Prozessor aufzuwachen. Es wird ohnehin voll in Hardware ausgegeben, ohne den Prozessor zu benutzen oder NOPs vorzugaukeln, mit so stets Bildausgabe und Sync, und das alles ohne Prozessor zu bremsen.

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

Wie beim ZX80 in wenigen TTLs implementiert (braucht 19 statt dessen 17, trotz weit besser zu sein), statt wie bei ZX81 in einem ULA (umgerechnet etwa 22 oder 23 TTLs). Dies vor allem wegen dem separaten Fontspeicher, was alleine 4 TTLs der ZX80 einspart (3 für ROM Adresse umschalten und 1 für Zeichencode zwischenspeichern). Mit den Jupiter Ace noch etwas vereinfachen, Font in 2k EPROM statt 1k SRAM, wäre er dann mit 3 TTLs weniger (2 für Fontspeicher schreiben/lesen Adressen und 1 für Hardware reverse), sogar mit 16 unter der ZX80 ihre 17 gekommen, trotz immer noch weit besser sein als die ZX81! Aber auf Kosten von separatem Font EPROM statt Ausschnitt vom System EPROM. Das Font EPROM eliminieren hätte obige 4 TTLs addiert auf 20, aber auch nur 3 mehr als ZX80, 2 oder 3 unter ZX81, trotz besser. Er beweist, dass die ZX80 ein Fall war von sparen egal was es kostet, und bei zu ZX81 verbessern wurde die Rechnung fällig, wenn auch in der ULA versteckt. Ausser man erachtet das eine eingesparte Paar 1kx4 SRAM Chips als wichtiger als verbrauchte 3/4 Prozessorleistung.

Allerdings kann er auch wegen separatem Zeichenspeicher und Fontspeicher keinen undokumentierten Bitmapmodus aus dem Hauptspeicher. Ebenso kein Quarz auf 8MHz für 40 Zeichen modifizierbar, weil ohne Zeichencodes als (Pseudo-)Programm lesen das Problem mit 40 Zeichen pro Zeile keine 2^n sein wieder auftritt, und hier keine Kompensation vorhanden ist.

Tangerine Oric-1 (1983)

Ein direkter Konkurrent vom ZX Spectrum, und auch etwa vergleichbar halb primitiv, aber nicht ganz so gut. Mit Bild aus dem normalen 16k oder 64k DRAM Hauptspeicher (mit nur 48k von letzterem nutzbar, ausser externes Signal schaltet die 16k ROM ab). Kann aber 2 Modi, Zell und Bitmap:

Zell hat 40x28 Zeichen, von denen aber Basic nur 39x27 benutzt (weil fest 1 Zeile oben Status ausgibt, und 1 Spalte links Hintergrundfarbe setzt oder zweiten Zeichensatz anwählt für die jeweilige Zeile). Mit 6x8 1bpp Font (wie TMS9918 "Text").

Bitmap hat passende 240x200 1bpp, aus eigentlich für 320x200 reichende 8000 von 8kByte, aber mit davon nur 6 breit als Pixel genutzt, wie beim Font. Plus darunter in den verbleibenden 8192-8000=192 Bytes 3 Zeilen zu 40 an Zellmodus (wie Apple II seine 4 Text unten), aber diese stets aktiv. Diese 3 Zeilen decken sich in Ausgabezeilen und Speicherplatz mit den letzten 3 der 28 vom Textmodus, und Basic scrollt dann auch nur noch in diesen, kürzt einfach von 28 nutzen auf 3. Somit auch 200/8+3=28 Textzeilen hoch, bzw 200+3*8=224 Videozeilen, dank PAL Monitor ausnutzen (wie Microtan 65 und BBC).

Dabei kann er (wie Apple II und PET/CBM und Atari 800) wegen 40 Zeichen pro Zeile keine 2^n sein nicht einfach die X und Y Koordinaten als Adresse zusammenlegen. Hier wird aber ein voller Y*40+X Addierer benutzt, in der ULA drin. Hat für Audio einen AY-3-8912 Soundchip. Bis jetzt ist es noch relativ normal.

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

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

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

Tangerine nennt dies "serielle Attribute". Es erlaubt 2*3+2+1=9 (in Bitmapmodus) bzw +2=11 (in Zellmodus) Bits an Attributen, ohne dafür separaten Speicher zu verbrauchen, und ohne um diesen auszulesen Bandbreite zu brauchen. Aber es ist nochmals weit schlimmer auf "Attribute Clash" anfällig, nicht nur wenn mehr als 2 Farben in einem 6x1 (Bitmap) bzw gar 6x8 Feld (Zell) gebraucht werden, sondern bereits wenn solche in direkten Nachbarfeldern ohne ein "leeres" (= alles Hintergrund) Feld dazwischen gebraucht werden. Ein sehr eigenartiges Design. Welches aber scheints auch im Teletext benutzt wurde.

Galaksija (1983)

Abgeleitet von TRS-80 als Spezifikation aber mit ZX80/ZX81 als Inspiration zu billig Video mit dem Prozessor aus dem normalen SRAM Hauptspeicher lesen. Hat den gleichen Prozessor, mit leicht weniger Prozessortakt als ZX80/ZX81 (3.072MHz statt 3.25MHz), aber weit mehr als TRS-80 (1.77MHz). Sowie 1oder2* 4k EPROMs (mit stark modifizierten TRS-80 Level 1 Basic darin, in Basis und Erweiterung aufgeteilt), und 1bis3* 2k SRAMs. Tastatur leicht modifizierte TRS-80, ebenfalls 7Aus zu 8Ein Matrix (wenn auch ohne dessen 8tes Aus wegen Shift eine eigene Zeile haben), aber mit Pfeiltasten und Space in TRS-80 CoCo Matrixpositionen, sowie ohne @ und Clear, dafür mit Repeat und Del und List.

Yugoslavischer Rechner, anfangs nur als Selbstbauanleitung in der Populärwissenschaft Zeitschrift Galaksija gedacht, erst später in Serie gebaut. Daher nur aus Standardchips (inklusive 2 4k EPROMs statt 1 8k ROM, wie Jupiter ACE), sowie eine einseitige Platine mit Drahtbrücken wie in damaliger analog Audio und Video Elektronik üblich, dementsprechend ziemlich primitiv. Ebenfalls daher kein Herstellername oder Modellname, einfach nach der Zeitschrift benamst.

Nur 1 Textmodus. Text 32x16 (wie TRS-80). Mit 8x13 1bpp Font (nahe MC6847 8x12, sowie nahe VDM-1/Sol-20 9x13). Aus festem ROM Satz von 64 beinahe-ASCII Zeichen (mit [ \ ] und ^ ersetzt durch serbische akzentierte Zeichen, sowie in der kommerziellen Ausgabe ' und @ ersetzt mit Firmenlogo als Promptzeichen). Dazu vom Modusattribut Bit7 gesteuerte aber im Font EPROM integrierte mischbare 2x3 Blockgraphik (gibt 64x48) (wie TRS-80). Bei 32*8=256 von 6.144MHz Pixeltakt trotz nur 32 Zeichen ein über mittleres 41.67µs Textfeld. Nur in Schwarzweiss (wie TRS-80).

Ohne den Gebrauch von I Register um Font zu adressieren, weil dieser in einem eigenen 2k Font EPROM ist (wie TRS-80). Auch ohne HALT mit Datenbit6=1, sowie ohne Addressbit6 = 0 vom R Register für Interrupttimer ausnutzen, weil mit minimal 2k genug SRAM um ein volles 32x16=0.5k Bild zu speichern. Alles zu Zyklen pro Zeile sowie Zeilen pro Bild sowie Syncpulse wird komplett in Hardware erzeugt, trotz weniger Chips! (Gespart werden gegenüber ZX80 dank separatem Font EPROM dessen 4 TTLs (3 Adresse umschalten und 1 Zeichencode), und die Sync Hardware kostet auch nur 2 TTLs plus 2 CD4000 statt 3 TTLs.) Daher ist kein Bild zucken mehr möglich. Wobei ein Bild aber 32*10=320 Zeilen statt 312 (+2.564%) lang ist, mit allerdings die Zeilen wegen 6.144MHz durch 12*32=384 teilen nur 62.5us statt 64us (-2.344%), was ersteres grossteils kompensiert.

Auch ist keine Zeichencodes als Programm auslesen mit NOPs vorgaukeln nötig (was 2 weitere TTLs der ZX80 spart), sondern der Refreshzyklus mit Register I und R wird hier für die Zeichencodes auslesen benutzt (wie ZX81 im undokumentierten Bitmapmodus den "Font"). Daher auch keine Limite auf Bit6=0, womit volle 256 Zeichen machbar sind. Sie werden aber vom 2k Font EPROM und den 13 Videozeilen/Zeichen limitiert auf 2048/16=128 davon, als 2*64=128 ASCII64 plus 2x3 Blockgraphik (wie TRS-80).

Mit IRQ Interrupt einmal pro Bild angestossen wird nur die Zeichenfolge ihre I und R sowie die Zeile in Font auswählen und Ende Zeilenausgabe blank per Programm gesteuert. Mit während der Zeile ausgeben zuerst 31 4-Zyklen Befehle notwendig sein (teils NOPs, aber teils ASCII welches sich mit Z80 01xxxxxx LD ohne (HL) Befehlscodes decken, um den READY Prompt auszugeben), sowie letztes Zeichen den Opcode für Ende der Zeilenausgabe auf blank stellen (dessen Datentransfer hat kein Refresh, gibt also nichts aus, und der erst nach 7 Takten kommende Befehl ist wegen nun Zeile in Font auf blank gestellt timing-irrelevant). Das nicht ausgegebene 8te Bit von R wird in Hardware nachgeflickt, aber zusammen mit der Videozeile in Zeichenzeile in Software berechnet (das 1 TTL an Register dazu ersetzt 2 TTLs der ZX80).

Das kostet 1+(16*13)=209 von 320 Zeilen an Prozessor, lässt 35% vom 3.072MHz Takt, also effektive 1.06MHz (was mehr ist als ZX81 seinen 25% vom 3.25MHz, effektive 0.8MHz, und ohne der ZX81 ihren +5 oder +6 TTLs in der ULA). Ein "FAST" und "SLOW" kann ohne R als Interrupttimer, mit IRQ statt NMI zeichnen auslösen, einfach durch dieses mit DI aus- bzw EI einschalten erreicht werden (wieder ohne ZX81 extra Schaltung), Bildausgabe ist dann weg, aber Sync bleibt weiter erhalten.

Trotz somit besser sein als selbst die ZX81, hat es nur 12 TTLs plus 2 damit vergleichbare 4000er CMOS, und liegt somit noch unter der ZX80 ihrer 17 TTLs, und weit unter der ZX81 ULA (umgerechnet etwa 22 oder 23 TTLs). Das zur Hälfte wegen separatem Font EPROM 4 TTLs eingespart, aber auch die eingesparte NOP Logik. Er beweist, dass die ZX80 nicht nur ein Fall war von sparen egal was es kostet, sondern auch noch von dabei gar nicht mal alles mögliche gespart! Ausser man erachtet wegen nur ein Paar 1kx4 SRAMs statt einem 2k SRAM den Bildanteil vom SRAM reduzieren als wichtig. Aber auch gegenüber einem vereinfachten Jupiter ACE (mit Font in 2k EPROM statt 1k SRAM und 16 statt 19 TTLs), hat er genau identische 4+4+2k EPROMs mit nur 2 TTLs weniger. Also doch sehr wenig gespart, trotz dass es 65% an Prozessor kostet.

Strikte ist die Auflösung nur von der Software her gegeben. Es können nur mit anderen Schleifen Konstanten in Register laden und anderes Font EPROM 8x8 1bpp auch 32x24 oder gar 32x26 angezeigt werden. Mit leichter Modifikation um die 4bit Videozeile in Zeichenzeile als 3bit Adresse und 1bit EPROM disable zu nutzen, was von 16 auf 8 Bytes pro Zeichen reduziert, sowie das fehlende Zeichenbit6 auf den frei werdenden Pin, könnte mit 2048/8=256 Zeichen auch volles ASCII plus 2x2 Blockgraphik plus 12 weitere angezeigt werden. Aber I und R nutzen ist mit Quarz auf 8MHz statt 6.144MHz für 40 Zeichen inkompatibel, ausser man legt die Zeilen als 3*40=120 + 8 unbenutzte in 128 ab, wie bei ZX80 im undokumentierten Bitmapmodus.

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

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

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

Einzelner Customchip PPU (Picture Processing Unit) für Video. Sowie zweiter Customchip APU (Audio Processing Unit), mit Audio und Joypad Interface sowie Prozessor und "DMA" Blockkopierer Koprozessor, alle in einem Chip integriert. Benutzt wie TMS9918 separaten Bildspeicher, 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 SRAM (sowie nur 2k sonstiges SRAM Hauptspeicher, und damit selbst zusammen sogar unter der VC-20 ihren 5.5k SRAM!). Beide sind neben den Programm und Font ROMs in Modulen auch mit SRAM 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 HauptRAM in den Bildspeicher kopieren, für zu Laufzeit erstellte Fonts, was aber am knappen VideoSRAM scheitert ausser das Modul liefert auch noch RAM mit. Stoppt den Prozessor bei Videozugriffen während der ganzen Bildausgabe komplett (kein schneller Speicher wie TMS9918, trotz SRAM). Man kann so nur während dem vertikalen Bildrücklauf zeichnen. Ebenso wird der Prozessor beim Blockkopierer benutzen gestoppt.

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

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

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

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

Farben mit Register auswählbar aus 64 (12 NTSC Farbtöne in 4 Helligkeiten, plus Graustufen). Hat 1 Register für Hintergrund (es hat keinen Rand!). Dazu 4 Sätze von 3 für Bild/Spielfeld Vordergrund, plus 4 Sätze von 3 für Sprites, zusammen 25, damit der farbigste 8bit Rechner überhaupt. Verwendet dazu vom Zeichencode unabhänigige Farbattribute, namens Object Attribute Memory (OAM), um Farbzellen zu haben. Aber nur jeweils 2x2 Zellen (also 16x16 Pixel!) haben ein 2bit Attribut (dies wegen Speichermangel, ausser das Spielmodul hat einen MMC5 Erweiterungschip drin, der mit mehr SRAM auf einzelne Zeichen (8x8 Pixel) genau spezifizieren erlaubt), um 1 der 4 Sätze von 3 Vordergrundfarben auszuwählen. Sprites haben jedes ein eigenes 2bit Attribut, um 1 der 4 anderen Sätze von 3 zu benutzen. Wie man sieht ist dies ein mengenmässig graphisch sehr leistungsfähiger Chip, gerade auch mit den 2bpp und 3 zellweise variablen Farben, aber textuell sehr geringer Chip, trotz immer im Zellmodus laufend!

Commodore 16 und 116 und Plus/4 (1984)

Designt als verbesserten VIC-20/VC-20 Nachfolger, für Leute welche sich den doppelt teuren C64 ($600 statt $300) nicht leisten konnten, als verbilligten VC-20 Rechner mit ZX Spectrum Preis, aber Features zwischen VC-20 und C64, mit mehr Graphgik und Speicher als ersterer sowie weniger Graphik und Audio als letzterer. Ist damit eigentlich ein Wiederaufleben des zugunsten vom C64 abgesetzten VIC-40. Somit explizit auf Niedrigpreis Small/Home Business ausgerichtet, nicht auf Videogamer. Der C116 ist das eigentliche ursprüngliche Design, in C16 umgewandelt für C64-ähnlicher entgegen dem Niedrigpreis Ziel, dann wegen zu teuer doch noch als C116 herausgekommen, dann als Plus/4 komplett pervertiert.

Ein Chip TED (TExt Display, trotz dass er auch Bitmap kann!). Mit allen 2+1 Zell und 2 Bitmapmodi vom C64 VIC-II. Aber ohne dessen Sprites, welche im Bürobereich nichts bringen, aber über die Hälfte vom VIC-II seiner Chipfläche ausmachen! Diesen Platz statt dessen genutzt um den SID einzusparen mit Audio im gleichen Chip (wie VC-20). Wie VIC und VIC-II ein generischer Videochip (NTSC und PAL selbiger umschaltbarer Chip MOS7360), aber auch nur von Commodore genutzt. Wieder mit Bild aus dem normalen DRAM Hauptspeicher.

Damit sind die Zellmodi "normales" 40x25 Zeichen (wie auch beim C64, den massiven VC-20 22x23 Schwachpunkt korrigiert), und mit Bitmap noch als Dreingabe. Mit 8x8 1bpp bzw 4x8 2bpp Font (und auch dem "Extended" mit 4 Hintergrundfarben). Aus variablem ROM/ModulROM/HauptRAM Satz, von schaltbar 128+invers (wie Atari 800) oder 256 (wie VC-20 und C64) Zeichen. Wieder mit PET/CBM Zeichensatz. Hat ebenfalls den PET/CBM Bildschirmeditor. Sowie Bitmapmodi 320x200 1bpp oder 160x200 2bpp (wie C64). Bei 320*1 oder 160*2 von 14.31818/2=7.1591MHz Pixeltakt ein breites 44.7µs Textfeld (wie Atari 800, doppelt getacktet aber auch auf 7/8 gebremst). Damit bis auf die bewusst weggelassenen Sprites fast das beste was man kombinieren konnte. (O-Ton TED Serie Konstrukteur: "You want to play games? Get a 64! You want to do text? Get a TED! (remember, TED means TExt Display).")

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

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

Overscan fehlt wie C64, trotz keinen separaten Farbspeicher welches dies auf 1k limitiert. Anderseits ist auch ohne bereits 44.7µs Textfeld, und Overscan ist im Bürobereich irrelevant. Das kann zudem mit sehr extensiven Rasterinterrupt Techniken teilweise kompensiert werden, solange nur vertikales Overscan gewollt ist. Selbst die Apple II Graphik+Text gemischt Anordnung kann so nachgestellt werden. Hat fein scrollen horizontal und vertikal, mit wie C64 die Reduktion auf 38 Zeichen bzw 24 Zeilen. Wie beim TIA im VCS/2600 und VIC im VC-20 auch Audio im Chip. Zudem einen PIO Port für Tastatur+Joystick, sowie Timer, aber keine Paddles. Aber solange man keine Sprites oder Paddles braucht ist er auch ein guter abgerundeter Chip.

Damit waren C16 und C116 gute Upgrades im Billigmarkt, dort wo der teurere C64 den VC-20 nicht verdrängen konnte. Dies vor allem C16 in Mexiko, sowie C116 und Plus/4 in Osteuropa (letzterer wurde sogar in Ungarn der offizielle Schulrechner), zumal sie neben mehr Video und Speicher auch noch schnelleren Prozessor hatten (wenn auch vom Video mehr ausgebremst). Der Plus/4 hatte zudem als reinen "farbigen PET" mehr in Basic nutzbares RAM (und alle hatten ein besseres Basic), sowie die namensgebenden 4 in ROM eingebauten Applikationen (welche aber trotz um von Band laden zu sparen ihre Daten nicht auf Band speichern konnten(!), so nach Floppy verlangten, was platzlimitierte Applikationen in ROM statt von Floppy laden sinnlos machte). Weiter hatten sie endlich eine bessere 4 statt 2 Cursortasten. Ebenso ein am Modulport anzusteckendes 1551 Floppylaufwerk, welches mit Parallelkabel weit schneller war als dem C64 seine sehr lahme 1541 Floppy mit gebremstem bitbanging Serialbus (und zudem bei nur-Kassette Benutzern die Kosten vom Serialbus einsparte, erst bei Floppy Benutzern die Kosten vom Parallelmodul addierte, aber dann auch dessen Geschwindigkeit gab). Zudem eine Hardware UART für RS232 zu Modems (der Atari 800 verwendet seine UART im POKEY nur für dessen schnelleren SIO Port Serialbus zur 810 Floppy, RS232 zu Modems und Parallel zu Drucker braucht einen 850 Expander). Das wären eigentlich gute Small/Home Business Rechner gewesen. Nur hat Commodore nach Managementwechsel entgegen explizitem Designziel von Billigmarkt unterhalb des C64 versucht, den C16 C64-ähnlicher zu machen als C16, und dann noch den Plus/4 als Ersatz vom C64 zu vermarkten, trotz explizit als schwächer designt ohne Sprites, was ihm seinen Spitznamen Minus/60 einbrachte.

Amstrad/Schneider CPC464 (1984)

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

Umschaltbar nur 3 Bitmapmodi, ähnlich dem BBC seine, aber keine x256 Zeilen, und die x200 sind keine x200von256. Ebenso keine halbgrosse Breite, und kein Teletext Modus:

Die MC6845 kann ohnehin nur mit 1MHz Speicherzyklen die Adressen für 40Bytes/Zeichen erzeugen. Alle diesen benutzende Rechner mit 80 Zeichen müssen aus jedem dessen Zugriffe ein Zugriffspaar machen, mit dabei Adressbit A0 varieren. Hier wegen Bild aus DRAM Speicher mit 2 mal 8bit an Bitmapdaten per Pagemode Doppelzugriff mit 1*/RAS+2*/CAS in der selbigen DRAM Page (wie ZX Spectrum für seine Bitmap+Attribute). Es braucht aber mit Bitmap keine Zeichencodes plus nichtlineare Fontzugriffe (was solche Techniken gegen die Atari 800 und C64 "Bad Lines" einsetzen verhindert), und wegen viele bpp keine separaten Attributbytes (was ZX Spectrum Bildspeicher so nichtlinear macht). Die reinen Bitmap Bytes liegen immer in Serien vor, von stets 80 pro Zeile. Was 80 Bytes 2MHz statt 40 Bytes 1MHz Videodaten erlaubt, und 16k statt 8k Bildspeicher (wie Atari 800 und C64) oder gar 6+0.75 (wie ZX Spectrum), mit trotzdem genug Speicherbandbreite für den Prozessor weitere 1MHz davon freilassen, mit nur 2.5MHz DRAMs brauchen. Wobei er nicht gebremst wird (abgesehen von 3-Takt Zugriffe auf 4 Takte ausdehnen, sowie 5oder6 auf 8, was aber unter 10% kostet und damit weniger im Vergleich zu ZX Spectrum von 4MHz auf 3.5MHz um 12.5% bremsen, plus bei Videozugriff weitere 16% davon verlieren).

Auch hier kann die MC6845 nur bis 128 (Zeichen-)Zeilen zählen. Hier werden die 200 Zeilen wieder als 25 (Zeichen-)Zeilen zu je 8 Videozeilen dargestellt (wie BBC und C64), statt 100 zu je 2 (wie CGA). Aber sie sind anderst nichtlinear angeordnet 0,8,16,... (wie Apple II mit "Hi-Res" Bitmap), statt BBC oder C64 ihre Videozeile pro Zeichenzeile in A0..2 für Zeichenblöcke, hier in A10..12 für Zeilenbänder.

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

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

Kein fein scrollen, aber mit 160@4bpp sind ganze Bytes nur 2 Pixel und somit 80 Positionen horizontal, was dies grossteils kompensieren kann. Für 160 Positionen kann mit 2 Kopien von vorgeshifteten Elementen gearbeitet werden, wozu die Z80 RLD/RRD Befehle beim shiften helfen und LDIR/LDDR beim einfügen. Keine Sprites, aber kann wieder mit 4bpp kompensieren (wie PCjr und BBC) im Gegensatz zur CGA, mit dazu nur wenig mehr Shiftregister und Umschalter. Genau dieses kleine Mehr macht wieder den Unterschied aus, von der CGA schrottig zu CPC (und BBC) anständig und modern. Und das hier zudem noch mit ordentlichen 3*3*3=27 statt 2*2*2=8 RGB Farben erweitert (aber weniger als PCjr sogar 4*4*4=64)!

(Weitere Limite ist wieder (wie BBC), dass mehr als 160 Pixel nur mit Reduktion auf 2bpp oder gar 1bpp machbar sind. Nett wäre 320 Pixel als 8Pixel@1bpp plus 2*4bit Farbattribute (wie TMS9918 "Graphic 2") statt als 8Pixel@2bpp ohne Attribute, für alle 16 Farben mit 40 Zeichen (wie CGA Text 40x25), oder gar beide Varianten zur Auswahl. Diese Verbesserung wäre mit nur dem Datenpfad Gate Array Semicustomchip leicht erweitern machbar gewesen. Auch fein scrollen wäre nur eine leichte Erweiterung dort.)

(Der Nachfahre CPC664 (1985) hat identisches Video und auch restlicher Rechner, unterscheidet sich nur durch weglassen des eingebauten Kassettenlaufwerkes zugunsten eines eingebauten Diskettenlaufwerkes.)

(Dessen Nachfahre CPC6128 (1985, nur 3 Monate spüter!) hat ebenfalls identisches Video und Diskettenlaufwerk, unterscheidet sich nur durch Erweiterung des Rechners von 64k auf 128k DRAM, welche als 8*16k verwaltet werden, wovon 2*16k als Bildspeicher benutzt werden können. Damit kann er sogar CP/M 3.0 fahren.)

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

(Die Seitenlinie PCW 8256 (1985) (bzw Schneider Joyce in Deutschland) war ein volles Bürogerät und kein Heimcomputer. Praktisch der ZX81 der Bürogeräte, hat neben Z80A Prozessor und 16* 4164 DRAMs und uPD765 Floppycontroller und 8041 Drucker Mikrocontroller nur ein 80pin(!) Gate Array. Hat nicht mal ein ROM, da der Drucker Mikrocontroller bei angehaltenem Prozessor einen Teil von seinem Inhalt via Gate Array ins DRAM lädt, dieses bootet alles andere von Floppy. Bitmapmodus 720x256 1bpp. Mit 8x8 Font und 90(!)x32 Zeichen. Videozeilen können wegen schnell scrollen beliebig in den ersten 8von16 der 16k Seiten an DRAM verstreut sein, mit einer 256*16bit Tabelle (3bit Seite + 10bit A4..13 + 3bit A0..2) ihrer Adressen um sie zu finden (wie Atari 800, wenn die Displayliste ohne Modusbyte nur stets die Datenadresse setzen könnte, dies aber in jeder Zeile machen würde). Videozeilen benutzen aber um schnell zu rendern nur jedes achte Byte, damit 8 Bytes/Zeichen Gruppen nutzbar sind (wie TMS9918 und BBC und C64), weshalb scrollen nur in 8 Zeilen Gruppen sinnvoll ist. Wurde für einen verbesserten CPC Nachfolger geplant, aber der Amstrad Firmenchef bemerkte, dass die meisten Rechner nur zur Textverarbeitung benutzt wurden, richtete den Rechner rein auf das aus. Mit Rechner und 2*Floppy im Monitor drin, aber separate Tastatur (wie TRS-80 Model II), sowie stets mitgeliefertes Nadeldruckwerk. Das Netzteil im Monitor versorgt Rechner und Drucker, nur 1 Stromkabel. Mit CP/M 3.0 System oder stets mitgelieferter Locoscript Textverarbeitung. Dies alles passend zum Einsatz als bessere elektronische Schreibmaschine. Insbesondere war es besser als die Konkurrenz durch aufgerüstete elektrische Schreibmaschinen, mit Rechner plus Floppy in einem kombinierten Tastatur+Druckwerk, sowie separatem Monitor. (PCW 8512 hat 512k statt 256k Speicher und zweite 720k statt 180k Floppy.) (PCW 9512 anderes Gehäuse und Typenraddruckwerk.))

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

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

Nur 1 Bitmapmodus (wie ZX Spectrum), weil auch in der DDR inzwischen ausreichend Bitmap Speicher mit DRAM billiger ist als TTL Logik). Wie CGA und ZX Spectrum eigener 16k Bildspeicher, vom hier nur 16k Hauptspeicher abgetrennt. Wie dieser vom Prozessor adressiert, dessen Adressmodi ausnutzend. Bitmap 320x(240von256) 1bpp, mit PAL Monitor Zeilen ausnutzen (wie Microtan 65 und BBC), trotz dass die DDR eigentlich SECAM Fernsehen benutzte! Erlaubt daher sogar 40x30(von32) Zeichen, bei 8x8 Font.

Trotz 40*8=320 Pixel (wie Apple II und PET/CBM und Atari 800) wegen 40 Zeichen pro Zeile keine 2^n sein wird die Speicheradresse einfach zusammengelegt! Dies aber revers mit Y Koordinate 0..255 an A0..7 und X 0..39(von64) an A8..13, weshalb die Pixel nichtlinear als 40 8bit breite Spalten/Streifen im Speicher liegen. Die oberste Bitmapzeile in Adressen Hex 8000,8100,8200, .. A700, dann zweite alles +1 und so weiter. Strikte ist das Resultat wie bei 5 linear durchlaufenen 256er Fonts (wie TMS9918 "2" ("Graphic 2") 3 Fonts und C64 4 Fonts), aber mit deren Zeichen vertikal vor horizontal durchgegangen.

Für je 8x4 Pixel Zellen 1+1+3+3bit RGBI Farbattribute, mit 2 Farben als Vordergrund 16 (Bit6..3 XGRB) und Hintergrund 8 (Bit2..0 GRB) sowie dazu blinkend (Bit7) (Anordnung wie ZX Spectrum, ausser mit X hier nur auf die Vordergrundfarbe wirkend), was Farbzellen erlaubt. Die 8x4 sind mehr als ZX Spectrum 8x8 aber weniger als TMS9918 8x1, und so immer noch auf "Attribute Clash" ziemlich anfällig. (All dies errinnert stark an ZX Spectrum. Aber der KC-85/2 Hersteller hat später unter dem Namen KC Compakt einen CPC Clone gemacht, nicht einen ZX Spectrum Clone! So einen gab es aber auch in der DDR, namens Spectral.)

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

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

(Der Nachfahre KC 85/4 (1988) erweiterte von 16kbit auf 64kbit Chips, je 64k statt 16k an Hauptspeicher und Bildspeicher, aber weiterhin nur UB880 mit 1.77MHz statt UA880 mit 4MHz, vermutlich weil fast kompatibel bleiben. Letztere 64k als 2* (2*16=)32k aufgeteilt, mit darin 10+10k statt 10+2.5k an Bild (auch plus 1.25k Zeichencodes). Hat nun 2 Bitmapmodi. Obiges 320x256 1bpp (aus ersten 10k), aber nun mit alle 8x1 Pixel 2 Farben aus 16 (wie TMS9918) (aus den zweiten 10k statt aus weiteren 2.5k der ersten). Oder umschaltbar auf 320x256 2bpp, in festen 4 Farben schwarz/rot/cyan/weiss (also 2bit für R und G=B). Letzteres aber wegen dem 10+10k zusammengesetzen Bildspeicher mit zwei 8*1bpp Bitplanes statt 20k an 4*2bpp Chunks (mit R in den ersten 10k und G=B in den zweiten). Es ist damit wie der Amiga anfällig auf "Ghosting" beim scrollen, wenn das ausgegebene Bild Pixel beinhaltet von denen eine Plane ihre Bits bereits verschoben sind aber die andere noch nicht, was unpassende Bits kombiniert zu zufälligen Farben, welche kurz aufflackern ähnlich wie beim "Snow" Problem. (Beim 1bpp plus Farbattribute kombinieren sich lediglich neues Muster mit alten Farben, was weit weniger flackert.) Es kann anderseits egal ob 1 oder 2 Bitplanes wegen 8*1bpp mit dem gleichen Font beschrieben werden, statt bei Chunks mit in 2 Bytes von je 4*2bpp "zerlegtem" Font. Anderseits sind je nach der zu setzenden Farbe ihrer Nummer die Bits zu setzen oder zu löschen, was mühsam ist!)

Apple Macintosh (1984)

(Davor war der Apple LISA (1983). Dieser hatte selbigen 68000 Prozesser (aber mit nur 5MHz), erstaunlich grosse 1MByte RAM, nur 1 Bitmapmodus, 720x360 Pixel, mit 9x? Font für 80x?? Zeichen, auf eingebautem 12" Monitor. Diese kostete aber erstes Modell noch $10000(!), und selbst zweites noch $3500 bis $5500, und scheidet damit hier aus.)

Halb ausser Konkurrenz, weil 16bit. Nur 1 Bitmapmodus. Mit Bild aus dem normalen 16bit DRAM Hauptspeicher. Hat keine Customchips, alles reine TTL Logik, aber teils noch mit PAL Programmierbare Logik, dementsprechend sehr primitiv für seine Zeit. Genauer hat es neben 1* Prozessor und 2* 32k ROM und 16* 64kx1 DRAMs und wenigen speziellen Chips (Floppy, Seriell, VIA/Parallel, RTC/Uhr) noch genau 6 PALs und 15 TTLs.

Der eigentlich 8MHz taugliche 68000 Prozessor wird etwas gebremst auf eigenartige 7.8336MHz (weil 1/2 von 15.6672MHz Pixel, welche wiederum auch /4.25(!) die 2*1.8432MHz für Drucker+Modem UART/RS232 abgeben). Aber weit schlimmer wird dies, wird wegen dem langsamen 2MHz der 64k Speicherchips während den Videozeilen ausgeben den Prozessor für jeden zweiten Speicherzyklus angehalten (alle Zeilen sind somit halbe "Bad Lines"), zumindest falls er einen RAM Zugriff machen will (ROM und IO sind ungebremst). Das gilt auch im Mac 512K, weil nur 64k Chips ersetzt durch 256k, sonst identisches Board. Selbiges gilt immer noch im Mac 512Ke, weil nur ROM und Floppy verdoppelt. Ebenso noch im Mac Plus (1986), weil nur 256k Chips ersetzt durch wahlweise 256k oder 1024k SIMMs, sowie SCSI addiert. Erst im Mac SE (1987) gab es ein redesign, welches diesen Bremser etwa halbierte (aber immer noch nicht eliminierte!).

Hatte im Vergleich zum Apple II 128k statt 4..48k Speicher, daher den Featuresatz abgebaut/vereinfacht, nur noch Bitmap wie bei "High Resolution", keine Zellmodi oder Blockmodi mehr. Daraus dank 16bit recht hohe (aber für 16bit eher niedere!) 512x342 1bpp auf dem eingebautem nur Schwarzweiss 9" Monitor (und damit selbst unter den 720x348 einer HGC Bitmap). Hat dabei exakt quadratische Pixel. Eigenartigerweise aber keine 512x384, was ein echtes 4:3 Bild ergäbe. Genauer sind es 15.6672MHz Pixel, 512+192=704 pro Zeile, 22.25kHz Zeilen, 342+28=370 pro Bild, 60.15Hz Bilder. Bild ist somit (512/8)*342=21888kByte, nicht mal dreifache Apple II "High Resolution" 8k. Da die 512 Pixel = 32 Worte pro Zeile genau in 2^n passen (wie bei 32 oder 64 Zeichen pro Zeile), und keine MC6845 Limiten setzt, und keine Farbzellen Limiten setzen, kann er einen rein linearen Bildspeicher benutzen.

Der Bremser wegen Speicher ist somit um 0.5*(512/704)*(342/370) = 0.336 = 33.6%, von 7.8336MHz auf 5.2338MHz. Allerdings muss der Prozessor ab und zu intern extra Zeit arbeiten (z.B. Indexrechnungen), mit seine ansonsten 4-Takt Zugriffe auf 6 verlängern, was dann doch nicht gebremst wird. Ebenso ist ROM Zugriff ungebremst. Womit am Schluss beobachtete etwa 6MHz herauskommen.

Wegen eingebautem Monitor keine Farben möglich, als einziger der 16bit Rechner hier. Nicht einmal 2bpp Graustufen gibt es, nicht mal optional. Nur mit Schwarzweiss rastern liegt noch drin. (Daher wurde auch selektierter Text in revers Video statt mit Grau hinterlegt angezeigt, weil rastern den Font unlesbar machen würde.)

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

Hat für Audio einen erstaunlich guten 8bit PCM (Samples) Generator, basierend auf einem PWM DA Wandler. Dieser bekommt seine Daten aus einem 370Bytes Buffer (genauer die mit geraden Adressen adressierten oberen Bytes von einem 370Worte Buffer), welcher mit den 22.25kHz Zeilenfrequenz per DMA ausgegeben wird, und genau ein Bild seine Zeilen lang ist. Für die Audioadressen kann er daher einfach den Zeilenzähler missbrauchen.

Anfangs mit Ziel als Billigrechner von $1000 designt, zu nutzen als eine "Information Appliance" (= Informations Haushaltsger¨t). Eigentlich eine bessere elektronische Schreibmaschine, mit Rechner plus Floppy im Monitor und separater Tastatur, statt mit Rechner plus Floppy in einem kombinierten Tastatur+Druckwerk und separatem Monitor. Wobei Apple schätzte dass 70% aller Benutzer den fakultativen Drucker kaufen, es wurden aber 90%. (Womit dies das selbige Konzept war, das Amstrad mit dem PCW 8256 sehr erfolgreich und weit billiger umsetzte.)

Man beachte hier noch, dass der Mac dazu anfangs in 1979(!) einen 8bit 6809 Prozessor hätte haben sollen, mit 256x256 Bitmap. Dann wurde Ende 1980 auf eine 16bit 68000 mit Adapter zu 8bit Speicher umgestellt (die 16/8bit 68008 existierte damals noch nicht), mit 384x256. Erst nach wegen Software Platz geben ohnehin 2 Bänke DRAM und 2 ROMs brauchen, wurde Herbst 1982 auf vollen 16bit Speicher erweitert, mit den 512x342. Einfach und billig war stets wichtiger als Leistung. Weiterhin wurde der Mac erst nach dem Wechsel von 6809 zu 68000 (und dabei Preis von geplant $1000 auf $1500 angehoben!) von Steve Jobs zu einer billigeren Alternative zur schweineteuren LISA aufgebauscht. Die dazu notwendige komplexe GUI Software erstellen dauerte weit länger als geplant, verzögerte den Rechner um 1 Jahr von 1983 auf 1984.

(Der Mac Originalprojektleiter Jeff Raskin ist frustriert vom Kurswechsel 1982 bei Apple weggegangen, und hat dann 1984 Information Appliance Inc gegründet um seine ursprüngliche Vorstellung doch noch herauszubringen. Zuerst als Apple IIe Karte SwyftCard (1985) und dann als 68008 Laptop Swyft (nur Prototyp) und 68000 Desktop Canon Cat (1987). Letzterer hat auch die anfangs geplante "Schreibmaschine mit Bildschirm statt Druckwerk und Disk neben Bildschirm" Bauform, im Gegensatz zum Mac "Klötzchen mit Bildschirm und Disk darunter und separate Tastatur". Er wurde aber nach anfangs Erfolg trotz wenig Werbung nach 2 Monaten bei Canon abgeschossen, ohne offizielle Grundangabe. Zwei annonyme Telephonate gaben zwei verschiedene Gründe aus, einer behauptet er sei Opfer eines internen Machtstreites zweier Abteilungen geworden, zweiter behauptet er sei als Teil des Druckmechanismus Deals von Canon mit NeXT geopfert geworden.)

Der Mac wurde dann wegen der Software als teuren Komfortrechner vermarktet, mit alleine wegen der Werbekampagne finanzieren den Preis von inzwischen bereits $2000 auf $2500 angehoben! Im Vergleich war der Atari ST anfangs nur $800 mit Schwarzweiss Spezialmonitor bzw $1000 mit RGB Videomonitor. Das trotz mit 512k 4 mal soviel Speicher wie dem Macintosh seine nur 128k, und einiges mehr Bauteilekosten. Der Amiga Amiga 1000 war anfangs $1300 ohne Monitor (+$300=$1600 mit Farbmonitor), mit 256k halbwegs dazwischen Speicher, wegen den teureren aufwendigen Customchips.

(Selbiges hatte Apple schon davor mit dem Apple II gemacht, eigentlich als minimalistischen Rechner designt, aber wegen Bitmapgraphik und Farben als teuren Powerrechner vermarktet. Er war je nach 4..48k Speicher von $1300 bis $2600, nur der Rechner ohne Monitor und Kassettenlaufwerk. Die in 1977 gleichzeitigen Tandy TRS-80 und PET 2001 waren weit billiger. Ersterer mit 4k Speicher 400+200(+50) = $600 (16k +300), zweiterer mit 4k Speicher $600 (8k $800), trotz Monitor und Kassettenlaufwerk mitgeliefert bzw eingebaut!) (Selbiges hat Steve Jobs bei NeXT wiederholt, mit erstem 68030 Würfel geplant $3000 aber dann verkauft $6500, und ist daran gescheitert.)

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

Sinclair QL (1984)

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

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

Nur 2 Bitmapmodi, 512x256 2bpp und 256x256 4bpp, beide in 32kByte. Also das Volumen, wie wenn ausgehend von einem Spectrum zuerst die Attribute von 8x8 Zellen in 0.75k auf 8x1 Zellen in 6k verfeinert wären (wie TMS9918), dann beide 6k Bitmap und 6k Attribute zusammengelegt zu 12k, dann 2bpp daraus gemacht in 12k, dann von 192 auf 256 Zeilen verl&aunl;ngert zu 16k (wie Microtan 65 und BBC), sowie dann die Bandbreite verdoppelt von 256 zu 512 Pixel in 32k. Mit 512 von 15MHz bzw 256 von 7.5MHz Pixeltakt, was eigentlich ein extrem schmales 34µs Textfeld ergeben sollte. Trotzdem wird im Handbuch angegeben, dass dies nur auf dem speziellen Monitor voll sichtbar ist, auf normalem Fernseher muss man einen Rand davon unbenutzt lassen!

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

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

Dabei fehlt aber einerseits genau dem textorientierten 512x256 Modus das für einen Cursor noch halbwegs nutzbare blinken. Es hat statt dessen für Text fast nutzlose 2bpp (mit 1bpp olus Attribute wäre Text weit besser, zumal dabei Attribute Clash irrelevant ist). Anderseits hat der spieleorientierte 256x256 Modus blinken, trotz dass er dieses kaum nutzen kann. Es verliert dafür die 16 Farben, ausgerechnet dort wo mit Attribute Clash meiden die 4bpp nützlich wären. Damit kann der QL weniger Farben darstellen als ein Spectrum, ist erstaunlich schwächer als sein erstaunlich guter Vorfahre!

Interviews legen nahe, dass der Rechner rein als Businessrechner designt wurde, nicht als Erweiterung/Ersatz vom Spectrum, und dass die 256x256 nicht für Spiele gedacht waren, sondern nur für Graphen. Aber auch dabei ist 16 Farben opfern für blinken sinnlos. Selbst die ganze Umschaltung von 512x256 mit 2bpp zu 256x256 mit 3von4bpp ist für Graphen eher nutzlos. Für einen reinen Businessrechner wäre 512x512 1bpp (oder gar als 640x400) auf einem Schwarzweiss Spezialmonitor sinnvoller gewesen, oder nur 512x256 als 2bpp mit Graustufen. Womit er ein besserer PCW 8256 gewesen wäre.

Weitere Aussagen berichten von anfangs zwei separate Projekten, Nachfolger vom Spectrum sowie dem Businessrechner, welche dann wegen fast gleicher Spezifikation zusammengelegt wurden. Aber die waren vermutlich genau in allem gleich ausser bei Video, welches beim zusammenlegen verborkst wurde, zu zuviel für Businessrechner, aber zuwenig für Nachfolger vom Spectrum.

IBM Enhanced Graphics Adapter EGA (1984)

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

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

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

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

Hier aber ohne jegliches "Ghosting", trotz echten Bitplanes, weil Pixel der Planes mit einem aufwendigen 8zu(4*8=)32bit Pixelprozessor synchron bewegbar sind, statt eine Plane nach dem anderen. Dazu werden bei von Bildspeicher lesen alle 32bits in 4*8 Latches zwischengespeichert, und je nach 2bit Bankauswahl ein Byte von 4 auf den Bus zum Prozessor geliefert (Read Mode 0). Weiterhin kann er aber alle 4 Bytes kombinieren, und ein Bitmap erzeugen wo jede Bitposition 1 ist falls alle 4 Bytes ihre korrespondierenden Pixeln zusammen eine spezifische Farbe in einem Register ergeben (Read Mode 1). Bei zum Bildspeicher schreiben wird es aufwendiger. Ein Byte vom Bus kommend geht je nach einer 4bit Bankmaske in eines oder auch mehrere der Bänke! Löschen besteht aus 0 in alle Bänke schreiben, egal was die Latches drin haben. Zeichnen addieren besteht aus 1er in die Bänke passend zur Farbe senden, also für Farbe 5 (0101) dieses in die Bankmaske schreiben, dann werden nur genau die passenden beiden Bänke verändert!

Für einzelne Pixel in einem Byte einfügen müsste eigentlich der Prozessor viermal zuerst lesen dann mit OR einfügen und noch schreiben. Hier werden aber die Pixel nur einmal vom Prozessor geschrieben, weil sie im Pixelprozessor für jede Bank mit dessen Latch Inhalt OR eingefügt werden (es hat auch AND zum löschen und XOR zum invertieren, sowie obiges voll ersetzen), und dann gleich in nur die passenden Bänke schreiben (Write Mode 0). Aber je nach Farbe teils setzen teils löschen bleibt extrem mühsam, mit 2 Zyklen für AND und OR.

Es ist aber auch möglich, analog zu obigem beim lesen Bytes nach Bitposition zu kombinieren, hier eine oder mehrere der Bitposition mit neuen 4bit aus einem Register zu ersetzen. Oder aber die Daten vom Prozessor so zu nutzen (Write Mode 2). Was dann fast so komfortabel ist wie bei Chunks, aber nur ein Pixel aufs mal, statt in Gruppen. All dies kann auch auch noch bitpositionweise ausmaskiert werden per Register, welche nur kopiert und welche modifiziert (ersetzt oder OR/AND/XOR) werden. Damit sind mehrere mit der selbigen Farbe direkt setzbar. Auch umkopieren um zu scrollen wird so gemacht, mit alle 32bit auf einmal lesen in die Latches, und dann unverändert schreiben, wobei der Pixelprozessor die Daten vom Prozessor ignoriert, nur die Latches Inhalte schreibt (Write Mode 1). (VGA addiert noch obiges bitpositionweise ausmaskieren mit Daten vom Prozessor (Write Mode 3).)

Mit 16 Farben aus 64 RGB Palette, was auch bei CGA Modi kompatibel benutzt wird, mit dessen 16 festen Farben vorbesetzt. Ebenso wurde ein Vertical Blank Interrupt (VBI) addiert.

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

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

(Wieder gingen erweiterte SuperVGA Clones weiter, mit 256k Speicher bis zu 640x400 8bpp (und 800x600 4bpp). Oder gar mit 512k Speicher 640x480 8bpp oder gar mit genug Bandbreite bis zu 800x600 8bpp (und 1024x768 4bpp). Die 1024x768 4bpp brauchen mehr als 64k Adressraum, benutzen zumeist 4*128k. Deswegen geht bis zu 800x600 4bpp mit einer MDA oder HGC, aber 1024x768 4bpp nicht mehr. Alle oberhalb 320x200 8bpp Chunks sind ohne 4* Bitplane Logik inkompatibel zu einander über die 64k hinaus adresserweitert. Daher geht 320x200 8bpp mit MDA oder HGC, aber je nach Karte ihre Adresserweiterung ist darüber stets machbar oder stets nicht oder je nach Auflösung. Später kamen mit 1M Speicher auch 1024x768 oder gar 1152x864 8bpp. Noch spätere addierten 1 Sprite, oft 16x16 2bpp (transparenz+inversion), als Hardware Mauscursor. Ebenso addiertern sie 2D Beschleuniger. Nochmals spätere addierten die 16/256 Farben aus 16M RGB statt 262144, sowie "Hi-Color" 800x600 3*5=15bpp mit direkten 32k RGB Farben. Noch weiter später kamen "True-Color" 3*8=24bpp direkt. Von diesen stammen alle modernen PC Karten ab, dabei die Inkompatibilität immer schlimmer werdend.)

Atari ST (1985)

Halb ausser Konkurrenz, weil 16bit. Einfacher geradliniger Rechner, der in unter 1 Jahr von Entwurf bis in den Verkauf sein ging! Stammt eigentlich von Tramiel Technologies Ltd, die neue Firma vom ex-Commodore Gründer und Präsident Jack Tramiel, nachdem er bei Commodore wegging wegen einem Krach um Managementstil mit dem Hauptinvestor. Wobei er ihm treue Mitarbeiter mitnahm/abwarb, inklusive C64 Ingenieur Shiraz Shivji. Hat dann die beinahe konkursite Atari Konsolen/Homecomputer Abteilung gekauft (der zweite beim Atari 800 erwänhte Aufkauf, dabei behielt Warner Brothers die Spielautomaten Abteilung), und diese ausgeschlachtet für Mitarbeiter und Ausrüstung. Hat dabei auch sich in Atari Corp umbenannt, um den etablierten Namen auszunutzen, trotz nicht die bei Warner verbleibene Atari Inc zu sein. Seither gibt es zwei Firmen Atari! Trotz mit Namen Atari damit eigentlich der ideelle Nachfolger vom C64. Bzw mangels Sprites eher "Nachfolger" vom abgesetzten VIC-20/VC-20 Nachfolger VIC-40. Bzw ist er eigentlich ein Seitenast vom später zugunsten vom Amige abgeschossenen Commodore 900 16bit Rechner, da einige der mitgenommenen Mitarbeiter zuletzt an diesem gearbeitet hatten.

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

Mit dem 12" Schwarzweiss Spezialmonitor SM124 ist stets 640x400 1bpp in 32k (über 1/3 mehr als beim Macintosh seinen 512x342 1bpp in 21.8k, und vergleichber mit HGC seinen 720x348, auch in 32k). Würde mit nur Spezialmonitor auscheiden, aber hat weiter unten auch einen RGB oder gar normalen Video Monitor. Wie Macintosh dabei nicht mal 2bpp Graustufen, trotz dass der Shifter eigentlich dies könnte, mit dann 320x400 erzeugen, aber der Monitor kann es nicht, weil mit nur 1bpp Videosignal unterhalb des MDA seinen 3 Graustufen mit "1.5bpp". Also wieder mit Schwarzweiss rastern (wie Macintosh). Mit umschaltbar normalem 0=schwarz und 1=weiss, oder dem eigenartigem 0=weiss und 1=schwarz (wie Macintosh), wobei die vom Macintosh inspirierte GEM Software zweiteres benutzt. Erlaubt 80x25 Zeichen mit 8x16 100dpi Font. Minus dem GUI Platzverlust erlaubt dies aber nicht mehr 80 Zeichen Breite! Die Hardware könnte auch problemlos 6x12 Font (wie Macintosh) und so gar 106x33 Zeichen, was der 12" statt 9" Monitor ebenso problemlos darstellen könnte, und was mit mehreren 80x25 Fenster erst sinnvoll sein würde, aber die Systemsoftware hat keinen solchen Font drin.

Alles in allem somit ein besserer Macintosh, der prompt als Spitzname Jackintosh genannt wurde. All das aus einem sehr einfachen simplen auf billig gebauten Rechner (Projektname war RBP, Rock Bottom Price). Es gab sogar zwei Module, The Magic Sac von Data Pacific und Spectre 128 von Gadgets by Small, mit ROMs + 64k Sockel, mit in den ROMs ST spezifische Treibersoftware vom Dritthersteller und die 64k von einem toten Mac 128k zu entnehmen (oder eher von einem lebenden zu kopieren). Diese verwandelten den Schwarzweiss ST in einen besseren und weit billigeren Mac, etwa viertel mehr Prozessor, viermal mehr DRAM, etwa drittel mehr Pixel und Monitorfläche, zu etwa einem drittel vom Preis! Einziges Problem waren die inkompatiblen Floppy Formate, was dann beim Spectre GCR mit einem eigenen dazwischen eingeschlauftem Macintosh-artigen Floppy Controller gelöst wurde. (Dies hätte auch der Mac Originalprojektleiter Jeff Raskin nach dem Untergang vom Canon Cat ausnutzen können. Einfach eine SwyftCard ST machen, zumal der ST einen Modulsteckplatz hatte. Oder gar gleich anstelle vom Canon Cat dieses. Wäre damit schneller auf den Markt gekommen, und mit einem Hardwarehersteller dahinter, der den ST als sein zentrales Produkt massiv verbreitete.)

Mit dem 12" RGB Monitor SC1224 (vergleichbar BCC und CPC ihren) (STM Modelle können auch einen normalen Fernseher benutzen) sind es dann umschaltbar 640x200 2bpp (und das kann auch mit 2bpp Graustufen sein) oder 320x200 4bpp (aber das kann kein 4bpp Grau mehr sein, weil nur 8 Stufen an RGB Farbtiefe im "Shifter"). Dies mit 4oder16 Farben aus 512 RGB. Ist damit ziemlich genau ein in allem verdoppelter CPC, aber kein vierfacher CPC für parallel zu einem vierfachem C64. Ebenso verdoppelte CGA Bitmapmodi (und sogar genau die PCjr 32k Modi). Es sind auch gleiche 2oder4bpp wie QL, aber wegen Farbregister ohne dessen Limite auf feste 4 Farben bei 2bpp, und ohne blink volle 16 Farben bei 4bpp. Bei 640 von 16MHz Pixel ein 40µs Textfeld (wie C64). Erlaubt 80x25 bzw 40x25 mit 8x8 Font. Wieder minus dem GUI Platzverlust nicht mehr 80 Zeichen Breite. Hier ist aber kein 6x12 benutzbar, weil dies mit 200 statt 400 Zeilen zu einem 6x6 Font füren würde. Beide 8x8 und 8x16 sind 6von8Pixel Fonts (wie Atari 800 und C64), damit der 8x8 auch auf Fernseher gut benutzbar ist.

Er verwendet Pseudobitplanes statt Chunks (wie QL), also stets selbiges 1bpp von 16 Pixel in einem Wort wie bei Bitplanes (mit den selbigen Font nutzen Vorteilen), aber die resultierenden 2oder4 Worte für die 2oder4bpp liegen direkt hintereinander in einem Speicher (wie QL bei 2bpp, nur hier auch bei 4bpp ohne gemischt, und das Wort mit allen MSB der Pixel zuerst) wie bei Chunks (und somit auch resistent gegen "Ghosting", ohne den Aufwand von 4 Bänken an separatem Bildspeicher und dem EGA Pixelprozessor). Aber je nach der zu setzenden Farbe ihrer Nummer die Bits zu setzen oder zu löschen bleibt mühsam, also muss man alle löschen und nur gewollte setzen was doppelte Zugriffe braucht (genauer bei 2bpp für 8 Pixel Zeichen 2 Worte lesen+löschen+setzen+scheiben, statt einfach 8*2=16bit 1 Wort schreiben). Oder wird gar wegen die anderen Sorten Bytes überspringen mühsamer, ausser man verzahnt die 2oder4 Rechenlogiken welche bei Bitplanes in 2oder4 Schleifen kommen würden. Dies alles wird auch als "woven layout" (= gewobene Anordnung) bezeichnet, und damit umgehen als "woven hell" (= gewobene Hölle).

Das Bild kommt stets aus einem 32k Speicherblock (wieder verdoppelter CPC), der vom Speicher/Adressen Chip nur in 256Byte Schritten angeordnet werden kann, und vom System jeweils auf das je nach Speichergrösse variable Ende von diesem gesetzt wird. Trotz je nach Modus wegen 640 Pixel pro Zeile keine 2^n sein 80 oder 160 Bytes pro Zeile, hat er keine Zeichenmodus Zeilenwiederholungen, keine MC6845 Limiten, keine Farbzellen Limiten, und kann damit rein linearen Bildspeicher benutzen (wie Macintosh). Keine Sprites, aber kann dies wieder mit den 4bpp kompensieren (wie BBC und CPC). Aber es fehlt ihm dabei ein vierfacher CPC zu sein, was erst dessen Ansatz von Sprites mit doppelter Speichermenge und bpp kompensieren voll durchziehen erlauben würde. Weshalb er eher nur ein vierfacher Apple II ist (und damit auch das was Apple an Videomenge anstelle vom Macintosh hätte liefern sollen, und das erst noch ohne halbe "Bad Lines").

Die aktuelle Videoadresse (nicht nur Videozeile) ist auslesbar. Aber es hat keinen Rasterinterrupt davon, was aber mit Rücklaufinterrupt und MFP Timer setzen gefolgt von dessen Timerinterrupt nutzen kompensierbar ist, wenn auch mit Aufwand. Für einen derart einfachen Rechner trotzdem erstaunlich gut und modern, weil er bereits Auflösung und 4bpp Masse ausnutzt, mit 32k Bild von den MCGA 64k in der Einleitung nur noch Faktor 2 entfernt. Als vierfachen CPC mit 64k und 320x200 8bpp hätte er diese sogar genau erreicht!

Das einzige was wirklich schmerzhaft fehlt ist horizontales fein scrollen (vertikal ist bei reinem Bitmap eh überflüssig). Auf dem ersten Blick wären mit 320@4bpp ganze Worte nur 4 Pixel und somit mit nur Worte umkopieren (die 68000 kann bei Wort/Langwort Speicherzugriffen keine Byteadressen nutzen!) 80 Positionen horizontal machbar, was dies grossteils kompensieren könnte. Aber die Pseudobitplanes sorgen für 1 Wort stets 16 Pixel sein, womit nur noch 20 Positionen horizontal sind bei 4bpp. Weshalb für 80 oder 160 oder gar 320 Positionen mit zwei Bildspeicher und jeweils im inaktiven ein Bild aufwendig neu aufbauen und danach aktives umschalten gearbeitet werden muss, was als Doublebuffering bekannt ist, mit dazu 4 oder 8 oder gar 16 Kopien von vorgeshifteten Elementen benutzen. Dabei kann man auch gleich Objekte ohne Sprites ins Bild hineinrendern, was als Compositing bekannt ist.

(Weitere Limite ist, dass mehr als 320 Pixel nur mit Reduktion auf 2bpp mit nur 4 Farben machbar sind. Nett wäre 640x200 Pixel als 8Pixel@1bpp plus 2*4bit Farbattribute (wie TMS9918 "Graphic 2") statt als 8Pixel@2bpp ohne Attribute, für alle 16 Farben mit 80 Zeichen (wie CGA Text 80x25), oder gar beide Varianten zur Auswahl. Diese Verbesserung wäre mit nur dem "Shifter" leicht erweitern machbar gewesen! Auch fein scrollen wäre nur eine leichte Erweiterung dort. Ebenso Chunks statt Pseudobitplanes.)

(Vermissen kann man weiter ein 160x200 8bpp. Oder besser gleich 64k Modi mit Schwarzweiss Spezialmonitor 640x400 2bpp oder gar 800x600 1bpp, sowie mit RGB Monitor 640x200 4bpp und 320x200 8bpp, als vierfacher CPC, und damit erst auf parallelem Stand zu einem vierfachen C64. Diese zudem mit Chunks für RGB mit Worte dann 160 Positionen und damit weder fein scrollen noch Doublebuffering mehr nötig. Sowie Compositing bei letzterem mit 1 Byte = 1 Pixel, womit Spiele schnell sein können trotz keine Sprites (wie MCGA). Wenn auch die Bandbreite dazu den Prozessor 40% der Zeit stoppen würde. Oder besser um dies zu verhindern Daten holen per DRAM Pagemode Doppelzugriffe mit 1*/RAS+2*/CAS (wie CPC), was aber 6MHz statt 4MHz DRAM Chips (CPC waren 3MHz statt 2MHz) gebraucht hätte (aber immerhin weit weniger teuer als TMS9918 seine 3.59646MHz statt 2MHz). Oder allenfalls mit 64kx4 DRAMs in Doppelbaenken zu je 4, mit 2 separaten /CAS Signalen gestaffelt, was vermutlich bereits mit 5MHz DRAM Chips gegangen wäre. Oder sogar mit 64kx4 DRAM Chips als 2*16=32bit machen, was mit 4MHz DRAM Chips geht, aber Leitungen und Tristate Gatter kostet (wie Apple IIe es mit "extended 80-column" als 2*8=16bit machte).)

(Der Nachfahre MegaST (1987) addierte einen bereits anfangs geplanten aber nicht umgesetzten Blitter, um Objekte ohne Sprites ins Bild hineinzurendern durch wortweise umzukopieren inklusive shiften. Aber dieser war schwächer als dem Amiga seinem, weil die Spezifikation nicht in der Zwischenzeit verbessert wurde. Anderseits war der MegaST auf dem Büromarkt ausgerichtet, womit dieser Blitter für GEM in DTP und CAD Anwendungen beschleunigen ausreichte. Spiele blieben beim ST, und damit ohne Blitter nutzen.)

(Der Nachfahre STE (1989) erweiterte auf 4oder16 Farben aus 4096 RGB. Er konnte auch Speicheranfangsadresse wortweise setzen, sowie die aktuell ausgegebene Videoadresse nicht nur in Software lesen um Bildsynchron den Farbsatz anzupassen, sondern auch umschalten für Zeilen in beliebiger nichtlinearer Reihenfolge anzeigen, inklusive einen zirkulären Bildspeicher erzeugen. Ebenfalls war der Blitter vorhanden, aber weiterhin ohne verbesserte Spezifikation. Als wichtigstes konnte er nun endlich pixelweise horizontal fein scrollen, statt das ganze Bild sehr langsam bitweise zu shiften, oder eher mit Doublebuffering Bild immer wieder neu aufzubauen. Ebenso addierte er per DMA ausgegebenes PCM (Samples) Audio. Er kam aber zu spät, weil in 4 Jahren bereits viele nicht-STE verbreitet worden waren, weshalb die meisten Spieleprogrammierer die nur geringen extra Fähigkeiten nicht mehr benutzen wollten. Wonach der ST erst gross gegenüber dem Amiga und vor allem VGA PCs verlor. (Wenn der STE die inzwischen auch bei billig 6MHz schnellen DRAMs ausgenutzt hätte mit Doppelzugriff für erweiterte "doppelte" 64k Videomodi, und somit zu einem vierfachen Apple IIe in dessen erweiterten "Double High Resolution" 16k Modus vergleichbar geworden wäre, hätte es mit dies benutzen wohl anderst ausgesehen. Zumal der erweiterte Apple IIe nach etwa 3 Jahren praktisch Standardanforderung von neuer Software wurde, trotz davor bereits 6 Jahre an II und II Plus verbreitet worden sein.))

(Noch mehr ausser Konkurrenz kamen dann im Nachfahren 32bit Atari TT (1990), mit weiteren "vierfachen" 128k Videomodi (genauer wegen noch etwas mehr Zeilen 150k), Schwarzweiss 1280x960 1bpp sowie Farben 640x480 4bpp (und 320x200 8bpp 64k), mit beide letzteren sogar VGA kompatibel, mitsammt dessen HD15 Stecker benutzen. (Die Speichermenge und Bandbreite hätten sogar für 640x240 8bpp oder gar 320x240 16bpp Hi-Color gereicht.) Der Blitter wurde wieder weggelassen, weil er den weit schnelleren Prozessor eher ausgebremst hätte!)

Commodore Amiga 1000 (1985)

Halb ausser Konkurrenz, weil 16bit. Stammt eigentlich von der Firma Hi-Toro (später in Amiga umbenamst), von ex-Atari Leuten als neue Firma gegründet. Mit dabei war auch der Atari 800 Chipdesigner Jay Miner. Trotz mit Namen Commodore damit eigentlich der direkte Nachfolger vom Atari 800. Wie dieser eine Spielkonsole welche zu einem Homecomputer erweitert wurde. Hat Chips vo obigem Designer von diesem und VCS/2600. Dies teils mit Finanzierung durch Atari, welche den Chipsatz im geplanten 1850XLD nutzen wollten. Nach dem Weggang von Jack Tramiel von Commodore hat dieser Atari aufgekauft, und nach entdecken derer Verhandlungen mit Amiga ein weit unzureichendes Angebot gemacht. Wonach Amiga andere Geldquellen suchte, und dabei von Commodore aufgekaut wurde, welche dann Atari ihren "Kredit" auszahlten. Weshalb Tramiel Technologies Ltd trotz Atari aufkaufen und Atari Corp werden den "Atari" Chipsatz verloren. Wonach sie ihr eigenes bereits vor vom Amiga erfahren skizziertes "Commodore" Design als Atari ST herausbrachten, während Commodore das "Atari" Design aufkaufte und als Commodore Amiga 1000 herausbrachte. Verdrehte Welt!

(Der Amiga 1000 konnte, wegen teures aber limitiertes Gehäuse, zuviel für Homecomputer aber zuwenig für Bürorechner, sich wegen Kosten nicht gegen Atari ST verbreiten und mangels Slots nicht gegen 286er PC mit EGA bestehen. Bis er in Amiga 500 (1987) und 2000 (1987) passend aufgespalten wurde. Was alles schon am Anfang bei Hi-Toro der Plan gewesen war, als Konsole plus Bürorechner, aus ihrer Atari 400 plus 800 Erfahrung heraus! Aber Commodore bestand auf dieser Kompromissvariante, welche keine Anwendergruppe befriedigten konnte. Sie hatten mit dies plus fehlendem Marketing geringe Verkaufszahlen, trotz dass IBM nach versagen des PCjr im Homebereich auf dem teuren PC mit schwacher CGA festsass (mangels einer PCjr Graphik für PC und mit EGA sehr teuer), sowie die Cloner noch nicht den Markt übernommen hatten. Bis Commodore endlich einsah und aufspaltete, wonach der Amiga 500 prompt den Atari ST überholte, sowie das erfolgreichste Modell der Serie wurde, trotz weiterhin fast nicht vorhandenem Marketing. Damit waren 2 Jahre an optimalen Verbreitungschancen unwiederbringlich verloren. Den massiven über 10 Millionen Erfolg vom C64 konnten sie so nicht mehr duplizieren. (Selbst der C128 verkaufte sich fast gleich viele wie alle Amiga Modelle zusammen!) Ebenso konnten sie nicht mit Verbreitung die 16bit Konsolen abhalten, so wie es der C64 mit den 8bit machen konnte. Der auf Amiga basierte CDTV war ebenfalls zu teuer, weil als "Super Videoplayer" statt CD-Konsole designt (wie bei der CD32 richtig gemacht, aber das war zu spät). Anderseits fehlten ihnen wegen mangels Umsatz die Finanzen um mit verbesserten Chips entwickeln gegen 486er PC mit VGA sowie Macintosh II Stand zu halten. Das Prinzip von technisch überholt werden verhindern existierte auch beim nach-Tramiel Management nicht (Tramiel verstand es auch nicht, aber wenigstens das Prinzip von finanziell unterboten werden verhindern, an letzterem gewann der ST anfangs aber verlor danach).)

Ist strikte ein Atari 800 mit doppelter Speicherbreite (von 8bit auf 16bit), und doppeltem Speichertakt (von 1.79MHz auf 3.5796MHz), das ergibt auch vierfache Speicherbandbreite. Wieder daher Featuresatz abgebaut/vereinfacht, nur noch Bitmapmodi, keine Zellmodi mehr. Kann aber sogar mehr als vierfachen Bildspeicher (von max 8k Bitmap auf variable 8..64 NTSC bzw 10.25..82k PAL). Mit Bild aus dem normalen DRAM Hauptspeicher. Dank schnellen 256k Speicherchips kann er bis 32k NTSC bzw 41k PAL ohne den Prozessor anhalten, aber mehr als das (3oder4* 16bzw20.5k oder 5oder6* 8bzw8.25k Modi) geht auf Kosten vom Prozessor, alle Zeilen werden dabei zu "Bad Lines", wenn auch variabele Menge davon, mit ((3oder4)-2)*22% oder ((5oder6)-4)*11% an Leistung verloren. Ausser es wird neben dem "ChipRAM" auch ein "FastRAM" addiert, also DRAM auf welches Video (und auch mehrkanaliges PCM (Samples) Audio und Floppycontroller) nicht per DMA zugreifen kann, womit das ChipRAM zu einem separaten Bildspeicher wird, wenn auch direkt vom Prozessor adressierbares (wie ZX Spectrum). Wie Atari 800 wieder drei Customchips, "Agnus" (Address GeNerator UnitS) Speicher+Adressen Controller+Generator (entspricht ANTIC), sowie "Denise" (Display ENabler) Videodaten+Pixel und Maus (entspricht GTIA), sowie Paula (Ports Audio Uart Logic) Tastatur/Audio/Floppy/Drucker/RS232 (entspricht POKEY).

(Diese Customchips haben massive Mengen an Logik darin. Der in TTL Chips gebaute Prototyp "Lorraine" (zwecks Logik verifizieren bevor Customchips hergestellt wurden) besteht aus 8+5+3=16 Platinen zu je 5 Felder zu je 5x5=25 an 20pin Chipsockeln, also 16*125 = 2000 Sockel an Platz. Diese wurden zu etwa 90% gefüllt, also entsprechen die 3 Customchips etwa 900+550+350 = 1800 an TTLs! Das ist das 30..100-fache der meisten 1970er Rechner, sowie des Macintosh. Mit TTLs im Bereich 10..100 Transistoren, 30 im Schnitt, haben sie also etwa 27000+16500+10500 = 54000 Transistoren in sich, fast 50% mehr als die 38000 Transistoren des 68000 Prozessors! Der Amiga brauchte dazu mehrere Jahre an Designzeit, und 2-stellig $-Millionen an Budget! Er kostete aber trotzdem ohne Monitor halb soviel und mit Farbmonitor zweidrittel wie der Macintosh mit eingebautem Schwarzweissmonitor.)

Ebenfalls wegen Nachfolger vom Atari 800 mit 14.31818/16*8=7.1591MHz NTSC und 17.734472/20*8=7.0938MHz PAL gebremst auf 7/8 Prozessortakt (und damit auch 7/8 vom Atari ST). Plus dazu 6-Takt Zugriffe auf 8 ausdehnen (wie Atari ST). Damit auch bei 640 von 14.31818MHz bzw 14.187MHz Pixeltakt ein 44.7µs breites Textfeld. Wird weiterhin in NTSC Wellen Raster gerechnet, trotz dass es einen RGB Farbgenerator hat, weil anfangs noch auf NTSC hin designt. Aber selbst mit NTSC wäre er unnötig gebremst, weil PAL so auch keine exakten Wellen bekommt.

Umschaltbar 2 Bitmapmodi aus 16bit Speicher 640x200 NTSC bzw 640x256 PAL 1..4bpp (16..64k bzw 20.5..82k), oder 320x200 NTSC bzw 320x256 PAL 1..6bpp (8..48k bzw 10.25..61.5k). Erlaubt 80x(25oder30) bzw 40x(25oder30) Zeichen bei 8x8 Font. Minus GUI Platzverlust ebenfalls nicht mehr 80 Zeichen breit Platz. Hier ist ebenfalls kein 6x12 benutzbar, weil 200 statt 400 Zeilen zu 6x6 Font füren würden (wie Atari ST mit RGB Monitor). Wieder ist es ein 6von8Pixel Font (wie Atari 800 und C64 und Atari ST), damit er auch auf Fernseher gut benutzbar ist. Selbiges nutzen führte auch zu der Schwarz/Weiss/Blau/Orange Farbkombination vom Desktop (genau die 4 7.1591MHz Pixeltakt auf NTSC Monitor Farben).

Dazu gibt es noch mit Overscan bis zu 752x242 NTSC bzw 736x288 PAL oder 376x242 NTSC bzw 368x288 PAL. Was auch obiges GUI Platzproblem kompensieren könnte. Es wurde aber nicht dazu genutzt, wohl weil mit über 44.7µs breit in den Bildrand hinausgehend. Kann bei NTSC mehr horizontal wegen leicht mehr Prozessortakt. Kann als einzige Rechner hier auf einen PAL Monitor/Fernseher volles vertikales Overscan. Kann weiterhin bei beiden doppelte Zeilenzahl anzeigen mit interlaced.

Ausschliesslich auf einem Fernseher oder Videomonitor oder RGB Monitor. Daher keine mehr als 200bzw256 Zeilen Spezialmonitor Option, weil wie Atari 800 anfangs als Spielkonsole designt und dann zum Homecomputer recyclet. Hat davon fein scrollen horiontal und auch vertikal (trotz dass letzteres bei reinem Bitmap eigentlich überflüssig ist!). Kann dabei mit Anfangsadresse beliebig, plus nach jedem Zeilenende ein "Modulo" Register zu den Videoadressen addieren, um die restlichen Daten am Ende und Anfang von überlangen scrollbaren Videozeilen zu überspringen, um Bildausschnitte anzuzeigen. Limite ist nur der Speicherplatz.

Mit reinen Bitplanes (wie KC 85/4 2bpp und EGA 1..4bpp), statt den Chunks vom Atari 800, oder den Pseudobitplanes vom ST. Mit wieder gleichem Font bei variablen bpp, aber dadurch eben massiv anfällig auf "Ghosting" (wie die KC 85/4). Dies zumal ohne jegliche Synchronisierung durch einen Pixelprozessor (wie ihn die EGA hat, und Hi-Toro in Betracht gezogen hatten, aber dann doch wegliessen). Ist logischerweise auch mühsam zu benutzen. Man kann aber obige "Modulo" Register einsetzen um die Planes zeilenweise verzahnt anzuordnen (alle von einer Zeile, dann erst von nächste Zeile), womit zumindest Ghosting reduziert wird, aber es bleibt mühsam. Zudem wurde dies nicht im Handbuch erwähnt, und war vielleicht deshalb so unbekannt und selten benutzt, dass so viele Programme es nicht nutzen, dass der Amiga seinen Ruf wegen "Ghosting" bekam.

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

Damit wird auch grob scrollen ohne umkopieren machbar, durch Zeilen blockweise in beliebiger nichtlinearer Reihenfolge anzeigen. Ebenso kann man Bildteile aus dem ganzen Speicher zusammensammeln, gerade auch feste/Menu/Status und gescrollte/Szene Auschnitte vom Bild. Aber all dies wird hier aufwendiger, weil die Adressen der Zeilen für jede Bitplane einzeln nachgetragen werden müssen, weil die Bitplanes separat im Speicher liegen können.

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

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

Obiges erst nachdem die "A" und "B" mit 2 32bit Barrelshifter um 0..15 Pixel geschoben wurden ("C" kann nicht geschoben werden, es wird daher zumeist für den Hintergrund benutzt, mit "A" und "B" daher als Objekt und Schablone), um dabei auch mit unverbrauchten Pixeln des vorherigen Wortes kombiniert zu werden, mit selber seine unverbrauchten Pixel weitergeben. Dies beseitigt die Probleme mit wegen Bitplanes 1 Wort stets 16 Pixel sein, weshalb Wortweise kopieren nur 20 oder 40 Positionen erlaubt. (MegaST/STE Blitter kann auch shiften und kombinieren, aber nur den Quellausschnitt. EGA fehlt das kombinieren, was dessen eigentlich vorhandenes shiften praktisch wertlos macht. Dies auf dem Prozessor machen ist weit langsamer, was genau den ST vor MegaST so sehr ausbremste, ausser man nutzt den doppelt grossen Speicher für 4 oder 8 oder gar 16 Kopien an einmal vorgeshifteten Elementen. Bei rein umkopieren ohne shiften oder kombinieren reicht die 8MHz 68000 um 32k Bildspeicher in nur 30ms=0.03s(!) zu scrollen, mit nur kombinieren ohne shiften ist immer noch unter 0.1s.)

Dabei kann es bei Breiten welche nicht genau in 16Pixel passen im ersten und letzten Wort jeder Zeile (bzw beide Enden eines Einzelwortes) von "A" auch automatisch Teilworte bitpositionweise ausmaskieren). Daher wird dieses vor allem beim ausschneiden von Objekten aus dem Bild benutzt, und "B" ist Schablone. (MegaST/STE kann das auch. EGA muss die Software die Maske anfangs/ende jeder Zeile setzen.)

Der Blitter entspricht damit funktionell dem Pixelprozessor der EGA. Nur arbeitet der Pixelprozessor synchron mit 4 Planes je 8bit verändern, während der Blitter asynchron nur 1 Plane aufs mal 16bit verändert und für jede Plane separat angestossen werden muss. Was dann genau das "Ghosting" beim scrollen maximal verschlechtert. Ausser man tut die Planes zeilenweise verzahnt anzuordnen, wonach der Blitter nur noch einfach für Anzahl Bitplanes * Anzahl Zeilen ablaufen muss, bei jedem "Zeilenende" zuerst durch die Bitplanes und dann erst durch die Zeilen springend. (ST tut wegen Pseudobitplanes je nach Operation allenfalls mit Worte überspringen und mehrfach anstossen arbeiten, kann aber auch einfach durchlaufen falls Rechenlogik mehrfach.)

Weiter kann die EGA ihr separater Bildspeicher nur durch den Pixelprozessor beschrieben und gelesen werden, während das Amiga Bild im DRAM Hauptspeicher direkt beschrieben und gelesen wird. Der Blitter muss daher explizit angeworfen werden, aber arbeitet dann mit eigenem DMA autonom (MegaST/STE alles auch), während der EGA Pixelprozessor stets nur auf Zugriffe reagiert, aber ohne autonom sein vom Prozessor mit Zugriffen und Adressen getaktet werden muss.

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

Alternativ wird der Blitter für Doublebuffering benutzt, mit während ein Bild unverändert angezeigt wird ein separates Bild in anderem Speicherausschnitt mit Elemente einkopieren aufbauen, gefolgt von Bildspeicher umschalteten. Dabei wird sehr viel kopiert, was der Blitter optimal beschleunigen kann, ohne dass dabei "Ghosting" sichtbar wird (der Mehrfachaufwand für jede Plane bleibt aber bestehen). Es gibt sogar mehrere Bildausgaben an Zeit um das neue Bild aufzubauen, aber kostet auch stets von Null aufbauen (oder zumidest vom Bild vor dem aktuellen aus). Damit ist er sogar sehr gut für spritelose grossflächige Spriteeffekte erzeugen nutzbar, um alle Objekte bitgenau geschoben und ausmaskiert ins neue Bild hineinzurendern, als Compositing. (MegaST/STE Blitter ist nur genau dafür da. EGA Pixelprozessor kann ebenso benutzt werden, mit den 4*64k als 2 4*28k Ausschnitte, und dem Resten für die Elemente. Beide müssen sogar mangels jeglicher Sprites so genutzt werden. Aber auch bei der Playstation wird auf Compositing statt Hardware Sprites gesetzt, nur mit dem Texturen Renderer nutzen statt einem Blitter.)

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

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

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

Mit je nach 1bis5bpp dann 2bis32 Farben aus 4096 RGB. Dazu noch mit 6bpp entweder Extra Half Bright (EHB) Modus 2*32 (30vollhelle+32halbhelle). Oder Hold And Modify (HAM) Modus alle 4096 gleichzeitig, aber nur mit 1/3 Auflösung, ausser bei den 16 "Startfarben" 00xxxx mit voller Auflösung, weil 01BBBB und 10RRRR und 11GGGG ersetzen jeweils einen der RGB Komponenten, erst eine Serie von allen drei erzeugt beliebige Farben, aber vorzu wird die Helligkeit (teil-)modifiziert.

Auflösung plus Overscan plus viele Farben plus grosse Sprites plus Dual Playfield gaben ihm zurecht seinen Ruf als das Graphikwunder schlechthin. Wieder zum Preis von einem massiv komplexen Chipsatz haben (wie Atari 800, vom gleichen Designer, seine vorherige Arbeit). Auch hier kann man nur noch ein 320x200 8bpp vermissen, weil die Bitplanes auf 6bpp limitiert sind (analog zu EGA ihre maximalen 4bpp), wenn auch nur wegen der Registerzahl (während in der EGA schon wegen der 32bit Busverdrahtung der 4 8bit Bänke).

(Der erweiterte ECS Chipsatz der 16bit Rechner A2000-C/A2000+ und A3000 (1990) sowie A500+ (1991) und A600 (1992) konnte weitere Videomodi. Darunter doppelbreite 1280200 und 1280256 (und mit Interlace doppelte Zeilenzahl) sowie mit verdoppelter Horizontalfrequenz doppelhohe 640480 (bereits ohne Interlace) alle mit max 2bpp (und max 4 von 64 statt 4096 Farben). (Damit sind sie ebenfalls wie beim STE keine "doppelte" Videomodi aus inzwischen schnelleren DRAMs.) (Leider fehlten trotz 64k/82k weiterhin doppelbittige 320x200 und 320x256 mit 8bpp, was aber mit max 6 Bitplanes an Adresslogik nicht machbar war.))

(Noch mehr ausser Konkurrenz kamen dann im Nachfahren AGA Chipsatz der 32bit A4000 (1992) und A1200 (1992) mit weiteren "vierfachen" Modi, bis zu 800x600 VGA und 1448241 NTSC bzw 1448278 PAL ohne Interlace (sowie 1448482 NTSC bzw 1448556 PAL mit Interlace), alle mit 8bpp und 256 Farben aus 16M RGB, oder HAM8 Modus mit 262144 RGB durch 64 3*2=6bit "Startfarben" oder jeweils 6bit einer der RGB ersetzen).)

Sega Mega Drive (1988) bzw Genesis (1989)

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

Einzelner Customchip VDP (Video Display Processor) Chip, nicht mehr die TMS9918 Familie wie Master System. Dieser ist aber strukturell ähnlich, und zum Master System seinem erweitertem G4 Modus kompatibel, plus einen weiteren neuen Modus G5, nicht mehr aber die normalen TMS9918 Modi 0 bis 3. Hat wegen kompatibel sein neben der 68000 auch dem Master System seinen Z80 (Master System Spielmodule brauchen dazu aber noch den 8bit zu 16bit Slotformat "Power Base" Konverter), der bei Mega Drive Spielen zum Audio Koprozessor wird, zusammen mit einem TI76489 PSG und einem YM2612 FM Soundchip. Benutzt wie Master System einen separaten 64k Bildspeicher aus SRAM (neben auch 64k Hauptspeicher SRAM, und 8k Z80 SRAM). Wie bei TMS9918 mangels Pins keine Adressierung vom Prozessor, braucht eigene Adressregister, verhindert Prozessor Adressmodi ausnutzen. Ebenfalls mangels Pins ist zwar der Datenbus zum Prozessor 16bit, aber Datenbus zum Bildspeicher hin nur 8bit, mit den SRAM Chips schneller getacktet.

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

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

Für grob scrollen durch umkopieren hat es einen DMA Blockkopierer Koprozessor, wie die Famicom/NES, aber im VDP integriert, nicht im Prozessor. Damit kann er nicht nur Hauptspeicher zu Bildspeicher und umgekehrt kopieren, sondern auch Bildspeicher intern. Ist ist alles andere als ein voller Blitter, aber mit Bytezugriffe aufs SRAM und mit 4bpp als Chunks, ergibt das wegen nur 2 Pixel pro Byte bzw Zugriff immerhin recht feine Pixelpaar Auflösung, mit bei 256 oder 320 Pixel pro Zeile scrollen in ausreichendem 128er oder 160er Raster. Aber die Zellmodi Logik verhindert hier ohnehin ganzes Bild als Bitmap scrollen.

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

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

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

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

SNK Neo Geo (1990)

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

Hat wie Mega Drive neben einer 68000 auch eine Z80 drin, stets nur als Audio Koprozessor benutzt. Mit einem YM2610 FM Soundchip. Benutzt einen separaten 64k Bildspeicher aus SRAM, plus ein "Fast Video" von 4k (neben auch 64k Hauptspeicher SRAM, und nur 2k Z80 SRAM). Wie bei TMS9918 und Mega Drive mangels Pins keine Adressierung vom Prozessor, braucht eigene Adressregister, verhindert Prozessor Adressmodi ausnutzen. Wird mit diesem Featuresatz 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 anderen und weit besseren Graphikansatz.

Hat keine Zellmodi, aber auch keine Bitmapmodi, weil es gar keinen Bildhintergrund hat, sondern nur Sprites darstellen kann! Diese auf 320x224 Raster, mit stets 4bpp. Damit ist fein scrollen automatisch durch die Spritepositionen gegeben. Ebenso wieviele der 320x224 abgedeckt werden, mit schlicht Sprites in passender Grösse und Anordnung hinstellen. Ich verdächtige wegen 12.5MHz Prozessor, dass es 6.25MHz Pixeltakt sind, was mit 40*8=320 Pixel genau volle breites 51.2µs Textfeld erlaubt. Also ist auch Overscan fakultativ abgedeckt, je nach wo/wieviel man Sprites hinstellt. Vertikal wohl auf 224 limitiert, weil einst für Automaten gedacht, mit nur NTSC, kein PAL. Viele Spiele nutzen nur 320-16=304 breit um Speicher zu sparen. Damit sind die 320 zwar 20% gröbere Pixel als bei Master System und Mega Drive, aber 20% feinere als bei Famicom/NES und SuperFamicom/SNES.

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

Damit kann man auch einen normalen Hintergrund mit Bitmapmodus simulieren, mit 320/16=20 auf 16x224 gesetzte Sprites zusammen gruppieren. Damit haben genug universelle Sprites den speziellen Hintergrund komplett ersetzt, was diese Graphik extrem universell macht. Dann kann man einen Font darin rendern wie BBC und CPC sowie ST und Amiga. Dazu muss das Modul aber neben Programm und Font ROMs auch SRAM mitbringen (es hat wie Famicom/NES separate Busse von Prozessor und Video zu den Modulen), ausser der Hintergrund passt in die eingebauten 64k (ein einzelnes Bitmap mit 320x224 4bpp Playfield braucht 35k davon, ein leicht kleineres 304x208 passt in 32k).

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

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

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

Aber eigentlich ist Parallax nur eine Methode, um bei wenigen zu kleinen Sprites und einer mit nur einem Playfield schwach ausgenutzten Bandbreite den letzteren besser auszunutzen mit zweitem Playfield. Sobald man gar kein Playfield mehr hat, alle Bandbreite in Sprites stecken tut, kann man auch alle einzelnen Objekte als Sprites einzeln scrollen, und damit nochmals weit besseres tiefenabhängiges scrollen haben als überhaupt mit Parallax geht. Dann kann man auf nur einen einzelnen Hintergrund reduzieren, und verbleibende 380-20=360 Sprites mit 96-20=76 pro Zeile für bewegte Objekte nehmen! Mit so vielen Sprites 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, weil praktisch vollendete 2D Techniken.

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

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

Nintendo SuperFamicom (1990) bzw SuperNES (1991)

Halb ausser Konkurrenz, weil 16bit. Naja, strikte halbes 16bit, oder gar unterhalb halbes 16bit. Hat anstelle einer 16bit 68000 wie in den meisten anderen hier (bzw 16bit 80286 in PC/AT mit EGA), oder zumindest einer 16/8bit 68008 im QL (bzw 16/8bit 8088 in PC/XT mit EGA), beide nur extern auf 8bit reduziert, lediglich eine 8/16bit 65816, 8bit 6502 intern auf 16bit erweitert (selbige wie im Apple IIgs benutzt).

Ein Customchip Paar S-PPU (Super - Picture Processing Unit). Benutzt wie Famicom/NES ebenfalls separaten Bildspeicher aus SRAM, aber 64k davon (wie Mega Drive und Neo Geo). Genauer diesen aufgespaltet als je 32k davon an separaten 8bit Zeichenspeicher und Fontspeicher (wie Sorcerer und Jupiter ACE) (neben auch 128k Hauptspeicher SRAM, mehr als die 64k der Mega Drive und Neo Geo). Alles mit 8bit Speichern zur extern 8bit 65816 passend, aber wegen zwei Chips trotzdem 8+8=16bit Speicherbandbreite für Videodaten, sofern man beide mit Pipelining ausnutzen kann (dabei die Chips PPU-1 Zeichenspeicher auslesend und PPU-2 Fontspeicher auslesend). Was aber zumeist nicht der Fall sein kann (Zeichenspeicher hat Zeichencode+Attribut 2 Bytes während Fontspeicher bei 2bpp oder 4bpp aber 2 oder 4 Bytes braucht). Damit genaues Gegenteil der Mega Drive ihrer 16bit Rechner mit 8bit Video, hier 8bit Rechner mit 16bit Video! Wie bei TMS9918 und Mega Drive mangels Pins keine Adressierung vom Prozessor, braucht eigene Adressregister, verhindert Prozessor Adressmodi ausnutzen.

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

Mit "HDMA" (Horizontal DMA) kann er während dem horizontalen Strahlrücklauf synchron Speicherzugriffe auslösen. Was am ehesten dem Copper vom Amiga entspricht, und wie bei diesem die Menge an Spritebits reduziert, was somit auch hier eine schlechte Idee ist.

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

Dazu ist noch mit 1 bis 4 Layern der Hintergrund zusammengesetzt aus "Monstersprites" von je 32x32 bis 128x128 Zellen zu je 8x8 (und somit 256x256 bis 1024x1024 Pixel). Dieses Quad Playfield ist ebenfalls besser als Dual Playfield um Mehrfachparallax zu haben, mit maximal 3 Ebenen durchscheinend, oder für mehrere grosse Objekte doch unabhängig bewegen. Diese mit pro Layer aus einem RAM Zeichensatz von 1024 Zeichen, diese ebenfalls horizontal und vertikal spiegelbar, und alle 4 mit separatem fein scrollen. In Modi 2 und 4 können Zellen sogar individuell gescrollt werden, für scrollende Fenster. Es ist aber weit aufwendiger mit 4 mehrere zu simulieren, als mit den automatischen Sprite basierten horizontalen Bändern der Neo Geo, oder gar alles als Sprites statt Bänder. Wobei allenfalls das HDMA zumindest die Umschalterei machen kann, ebenfalls wie beim Amiga der Copper dessen Dual Playfield.

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

(Selbst der echt-3D Polygongraphik Erweiterungschip Super FX reichte nicht für ordentliche 3D Graphik, weil weit zuwenig Leistung. Ebenso das stärkere aber sauteure Parallelstück dazu, der Virtua Processor Erweiterungschip des Sega Mega Drive. Das weil 3D und 16bit (oder gar 8bit) einfach nicht zusammenpassen. Sogar die 32bit Playstation war noch eher grenzwertiges 3D. Das weil sie zwar bis 640x512 hinauf anzeigen konnte, als Ausschnitt aus 1024x512 16bpp Bildspeicher, und diese Auflösung mit Texturen Renderer trotz keine Sprites problemlos in 2D behandeln konnte, aber bei 3D wurde zumeist weiterhin eine niedere Auflösung wie bei Famicom/NES und SuperFamicom/SNES benutzt, mangels GPU Leistung. Erst auf der 64bit Playstation 2 taugte 3D wirklich.)

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

Vergleich der Systeme

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

Speicheranordnung

Eine der fundamentalen Differenzen ist, wie und wo die Videodaten im Speicher abgelegt werden, da dies die Möglichkeiten vorgibt bzw limitiert. Einerseits kann dies die Menge an nutzbarem Bildspeicher hart limitieren oder mit Program und Datenspeicher abtauschen. Anderseits kann es Effekte mit Zugriffsgeschwindigkeit oder Aufwand entweder verunmöglichen oder zumindest erschweren.

Terminal Logik

Die älteste aber auch unflexibelste Variante. Der Bildspeicher ist am weitesten vom Prozessor entfernt, und mit der langsamsten Verbindung, sowie der unflexibelsten Programmierung (nur Daten, als ASCII oder allenfalls noch mit Escapesequenzen). Am schlimmsten eine RS232 Leitung (wie bei den meisten Minicomputern mit Terminals daran), am besten eine Parallelschnittstelle genutzt (wie in manchen frühen Mikrocomputern, inklusive Apple 1). Von den hier vorgestellten Systemen verwendet keines dies, weil kein System mit dieser Variante die Anforderungen zur Teilnahme erfüllt!

Separaten Bildspeicher

Der einfachste Ansatz. Die DMA Logik muss nur aus dem lokalen Bildspeicher auslesen können. Nur dieser muss mit dem Prozessor geteilt werden, und mit sonst nichts. Dies zudem nur wenn der Prozessor auf die Videodaten zugreift, also zur meisten Zeit nicht. Also kann zur Vereinfachung mit Video kurz ausblenden oder Prozessor bis Ende Zeile warten gearbeitet werden, oder gar Kollision zugelassen werden mit "Snow" Effekt. Aber ist hart limitiert auf die Menge an Bildspeicher. Verwendet vor allem in alten Systemen (1970er) sowie allen älteren PCs (vor Chipsatz Video, erst ab Ende 1990er nachdem Caches standard waren):

Im Hauptspeicher

Aufwendiger aber auch flexibler zu benutzen ist direkt einen Ausschnitt aus dem Hauptspeicher zu nehmen. Dies erlaubt variabel grosse Ausschnitte vom Speicher zwecks diverse Modi, und variabel liegende Ausschnitte zwecks Doublebuffering für Animation. Dieser Speicher muss aber dauernd mit dem Prozessor oder gar anderem geteilt werden, was zu speziellen Taktfrequenzen oder gar Prozessorpausen führt, bis hin zu ganze Zeilen lang anhalten. Hier verwendet vor allem in praktisch allen 1980er Heimcomputern:

Unadressierbaren Bildspeicher

Praktisch der separate Bildspeicher Ansatz, aber mit diesem hinter einem Graphikchip "versteckt". Damit auf dessem Grösse limitiert, aber inzwischen genug gross für Bitmap und/oder Doublebuffering. Keine Prozessor Adressen in diesem nutzbar, es wird nur ein kleiner Satz Register angeboten, von denen neben manche für Konfiguration einer den Datenzugriff durch den Chip auf den Bildspeicher macht, und weitere die Adresse dazu setzen. Damit eigentlich sogar ein Rückschritt von separaten Bildspeicher in Richtung von Terminal Logik, wenn auch direkt ohne Leitung am Prozessor angehängt, und mit Adresse setzen nicht auf Escapesequenzen limitiert. Trotzdem damit reduzierte Möglichkeiten der Adressierung, daher mühsam und langsam zu benutzen, wenn auch weit weniger schlimm als Terminals. Verwendet im TMS9918 (und auch den µPD7220 und EF936x) und von dort in praktisch alle Spielkonsolen kopiert:

Chiptechnologien

Hat man Prozessor und Speicher muss man noch den Speicherinhalt ausgeben. Dazu wird Chiplogik benötigt. Je nach der Chiptechnologie entstehen dabei wiederum Limiten, wie die Videodaten in Pixelmuster und Farben umgesetzt werden können.

Reine TTL Logik

Die älteste aber auch schwächste Variante. Bereits seit den 1960ern existent, vor den Mikroprozessoren (und in Minicomputern für die Prozessoren verwendet!). Nach dem Aufkommen von Mikroprozessoren weiterhin für das restliche Systemdesign inklusive Speicher ansteuern verwendet. Erlaubt nur dementsprechend primitive Systeme:

Customchips

Aufwendig und teuer zu entwickeln. Daher erst zur Massenproduktion in Millionenzahlen von auf Konsumenten ausgerichteten Systemen nutzbar. Daher zuerst in Spielkonsolen genutzt, und erst darauf aufbauend auch in Homecomputer:

Standardchips

Auch aufwendig und teuer zu entwickeln, weil sie auch Customchips sind. Aber die Kosten dafür werden wie bei allen Mikroprozessoren getragen durch Verkauf an beliebige Designer von beliebigen Systemen. Daher quer durchs Beet in allen Sorten genutzt:

Semicustomchips

Weniger aufwendig und teuer zu entwickeln als Customchips. Weil die Kosten für den universellen Basischip auf beliebige auf diesem aufbauende Designs aufgeteilt werden. Das einzelne Design muss nur die spezifische Chipverdrahtung erzeugen, aber die ganzen Transistorstrukturen sind fest als eine regelmässige Zellenstruktur vorgegeben. Diese werden als Serien mit verschiedenen Featuresätzen sowie als mehreren Grössen hergestellt. Daher vor allem bei kleineren Herstellern bzw bei kleinen Stückzahlen zu finden:

Bildgrösse

Egal was für Bilddaten erzeugt werden können, hat es stets eine Limite, auf in wie grossem Ausschnitt vom Bildschirm überhaupt Bild ausgegeben wird. In der Breite zählt die Menge an genutzter Zeit (NTSC max 51µs, PAL max 52µs). In der Höhe zählt die Anzahl an genutzter Zeilen (NTSC max 480i/2=240p, PAL max 576i/2=288p, mit "i" = interlaced und "p" = progressiv/nicht-interlaced). Weiterhin ist die in diesem Ausschnitt aufgelöste Pixelzahl relevant. Vor allem in Breite und Pixelzahl streuen Rechner stark, weil dieses auch noch via den Speicherzugriffen mit der Taktfrequenz zusammenpassen muss:

Bitmapmodi

Nach dem Bildausschnitt kommt dann der Bildinhalt. 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 wurde dieser Ansatz kopiert als Bitmapmodi. Genau daher verwenden wir heute ausschliesslich solche. Nur deren Platzbedarf ist problematisch, sonst sind sie universell.

1bpp/2Farben Bitmapmodi

Der einfachste Weg, die in der Einführung erwähnte 1988er IBM VGA Karte mit ihrem MCGA Modus und dessen 320x200 8bpp ihre 64k weiter zu reduzieren besteht darin, schlicht die 8bpp auf 1bpp zu minimieren, mit bei 320x200 nur noch 8k brauchen, oder bei 256x192 sogar nur noch 6k. Was genau einer Zeichnung mit einfarbiger Zeichenfläche und nur einem einzelnen anderfarbigen 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 VIC-20/VC-20, TRS-80, Sorcerer, Microtan 65, ZX80 und ZX81, IBM MDA, Jupiter Ace, Galaksija, Famicom/NES. Aber auch manche 16bit Konsolen, darunter Mega Drive und SuperFamicom/SNES.

Die 16bit schlagen hier ansonsten massiv zu, dank mehr Speicher und Bandbreite. Am besten mit 640x400 in 32k der ST als doppelte 640x200. Weniger mit 512x342 in 21.8k der Macintosh als nicht ganz doppelte 512x192. Beide brauchen dazu aber wegen doppelten Zeilen einen Spezialmonitor, beim ST separat wählbar oder beim Macintosh fest eingebaut, und das bei beiden nur in Schwarzweiss. Scheiden auch strikte aus. EGA liefert dazwischen 640x350 (Breite von ST, Höhe von Macintosh) in 28k, auch mit EGA Spezialmonitor, aber dafür auch in Farbe, aus massivem n*28k Speicher. Scheidet damit komplett aus. Die bereits beim BBC und CPC gesehenen 640x256 in 20.5k bzw 640x200 in 16k auf einem Fernseher oder Videomonitor oder RGB Monitor kann der Amiga (und ebenso der BBC Speicher sparenden 320x256 in 10.25k bzw 320x200 in 8k) (sowie plus Overscan wie Atari 800), dafür kann er doppelte Zeilen nur mit interlaced statt Spezialmonitor. Der QL scheidet mangels 1bpp haben aus.

Auscheiden tun sicher die Mega Drive und SuperFamicom/SNES, wegen trotz 16bit keine Bitmaps. Aber auch erst recht die Neo Geo, ohne überhaupt einen Bildhintergrund zu haben, nur Sprites (mit denen es aber ein Bitmap simulieren kann, aber nur mit 4bpp, was hier auscheidet).

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

1bpp/2Farben Farbzellenmodi

Obiges erlaubt selbst mit Auswahl 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 (wie in vielen VCS/2600 Spielen gesehen). Weit besser ist daher, dies in Hardware zellenweise schalten zu können, jeweils zumeist 8 Pixel breite Zellen, passend zu Schriftzeichen und/oder Objekten in Szenen eher rechteckig statt sonst zeilenbreit zu 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 Farbattribute für 2 von 16 Farben in einer Zelle benutzen (C64). Aber teils mit 1+1+3+3bit für speziellere Effekte wie blinken (ZX Spectrum und KC-85/2). Oder sogar 1+7+7bit für 2 von 128 Farben plus blinken im TED.

Dies mit 8x8er Zellen im C64 (1k) und ZX Spectrum (0.75k), mit 8x4er Zellen im KC 85/2 und 85/3 (2.5k), oder gar mit 8x1er Zellen im KC 85/4 (10.25k) und TMS9918 "Graphic 2" Modus (6k). Speziell ist mit 6x1 im Oric (und ist erst noch im Bitmap integriert). Minimal ist mit 2x3 im MC6847 in seiner 2+6=8bit 2x3 Blockgraphik "6" mit 2bit als 4 Stiftfarben "Farbzelle".

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 benötigt (stets doppelt, in der ersten/einzigen Zeile der Farbzellen, oder gar in allen).

Dabei wird entweder der Prozessor vom Speicher ausgeblockt und angehalten, wie im C64. Was auch ein Grund ist nur 8x8 Zellen zu benutzen, weil das die Ausblockzeit auf nur jede achte Zeile reduzieren kann, von 40% auf nur 5% Verlust, als "Bad Lines" bezeichnet.

Oder man akzeptiert mehr Prozessor ausblocken. Zumindest der ZX Spectrum nutzt obiges einmalige Laden nicht aus mangels Buffer, holt bei allen 8 Zeilen wiederholt. Weshalb er dann bei Videozugriffen den Prozessor bremst, aber dann auch nicht zu 100% in der Zeile. Ausser man erweitert auf 48k, mit die ersten 16k nur noch als separatem Bildspeicher. Selbiges die KC-85/2, stets mit separatem Bildspeicher. Deren 8x4 sind durch ihre 16k limitiert Bitmap 10.25 + 2.5k Farbattribute + 2.5k Zeichencodebuffer (die 8x1 vom KC-85/4 werden erst erlaubt durch dessen (2*)2*16=64k).

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

Abseits liegt der Oric, mit 6x1 Farbzellen ohne den Prozessor ausblocken, aber zum Preis dass jede Farbe umschalten eine Zelle als Attributschaltbyte "umfunktionieren" und als Leerplatz ausgeben kostet.

(Man beachte hier noch, dass KC 85/4 und TMS9918 mit ihren 8Pixel*1bpp=8bit plus 8x1 Zelle 2*4=8bit Farben sogar gleich viel Speicher und Bandbreite verbrauchen wie wenn sie eine doppelt so breite Auflösung ohne Farbzellen hötten! Damit könnten diese auch 640x256 (einen vollen BBC!) bzw 512x192 1bpp liefern, wobei dieses dann nur noch mit im ganzem Bild 2 Farben wie oben gehen würde (wie auch im BBC der Fall). 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 2* 640x128 oder eher 2* 320x256).)

2bpp/4Farben Bitmapmodi

Auch so bleibt eine Zelle auf 1bpp und 2 Farben beschränkt, mit den Problemen von "Attribute Clash" (ZX Spectrum) bzw "Color Spill" (TMS9918), sobald man mehr als 2 Farben in einer Zelle bzw Zeilensegment 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 drei Stifte beliebig einsetzen, aber auf Kosten von mehr bpp, und damit mehr Speicher, oder wegen Bandbreite zumeist eher halbierter horizontaler Pixel:

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

Die 16bit ziehen teilweise genauso mit. Ein paar von ihnen haben bei 1bpp nicht mal ihre ganze Bandbreite ausgenutzt, und gehen daher für 2bpp mit gleicher Auflösung auf doppeltem Speicherplatz. Logisch sind dies nur Rechner mit massiver Bandbreite, genauer den Amiga der auch bei 2bpp 640x200 in 32k bzw 640x256 in 41k kann (plus noch Overscan) sowie die EGA die ebenfalls bei 2bpp 640x350 in 2*28k kann. Nach diesen verbleibt nur noch mit 640x200 in 32k der ST mit Farbmonitor, mit halbierter Zeilenzahl, sowie mit 512x256 in 32k der QL. Der Macintosh fällt mit nur 1bpp 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 in 2*10.25k auf 2bpp in 2*10.25k umschaltet, was aber auch nur die Häflte vom nicht vorhandenen 640x256 1bpp wäre. Die TMS9918 mit ebenfalls 8x1 Farbzellen hätte Platz und Bandbreite, aber ein 256x192 2bpp Modus ist nicht implementiert, und auch sonst gar nichts mit 2bpp (und ebenso kein 512x192 1bpp).

Die Farbauswahl hier kann wieder sehr verschieden sein. Schlimmstenfalls gibt es nur einen festen 4er Satz, wie QL (Sw+Rt+Gn+Ws), oder 2 feste 4er Sätze, wie MC6847 (Gn+Gl+Bl+Rt oder Ws+Cy+Mg+Or). Etwas besser kann eine Farbe gewählt werden, wie IBM CGA eine Farbe aus 16 und 3 feste 3er Sätze für den Resten (Gn+Rt+Ge oder Cy+Vt+Ws oder Cy+Rt+Ws). Noch besser als das können alle 4 Farben gewählt werden, aus 27 beim CPC, 64 bei der EGA, 128 beim Atari 800, 512 (bzw 4096) beim ST (bzw STE), und 4096 beim Amiga.

2bpp/4Farben Farbzellenmodi

Mit 2bpp gibt es zwar 4 unabhängige Farben. Aber das sind weit weniger als die oft 8 oder gar 16 Farben welche man mit Farbzellen bekommt. Gerade für Text, wo man ohnehin keine 4 Farben in einer Zelle braucht, und die 2bpp nur nutzen kann um einen 1bpp Font in wenigen Farbkombinationen einfärben, ist 1bpp mit Farbzellen Attribute oft die bessere Wahl. Also gibt es auch die Kombination der beiden Ansätze, welche aber recht selten ist. Was erstaunlicherweise komplett fehlt ist einfach entweder eines oder anderes umschaltbar.

Der Apple II mit NTSC Farbmonitor offeriert bei seinen 280x192 1bpp dann pseudo-2bpp 140x192 in nur 2 festen 4er Sätze (Sw+Gn+Vt+Ws oder Sw+Bl+Or+Ws), aber kann diese für jedes 7x1 Zeilensegment wählen (mit dem achten Farbattributbit). (Atari 800 "F" und MC6847 "R" und CGA mit NTSC Farbmonitor können bei ihren 320x192 bzw 256x192 bzw 640x200 1bpp selbige pseudo-2bpp 160x192 bzw 128x192 bzw pseudo-4bpp 160x200, ohne Farbattributbit nur Sw+Bl+Or+Ws bzw volle 15 Farben.)

Die C64 und TED dagegen machen auf volle Farbzellen, wegen 160x200 nun in 4x8 Grösse, aber mit 4+4+4=12bit 3 (C64) bzw 7+7=14bit 2 (TED) "Stifte", welche 3 Farben aus 16 (C64) bzw 2 aus 128 (TED) wählbar machen (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. Dies ist eine der grossen Stärken dieser beiden Rechner.

4bpp/16Farben Bitmapmodi

Auch so bleibt eine Zelle auf 2bpp und 4 Farben beschränkt, falls zellenweise überhaupt vorhanden ist. Der 2bpp Ansatz kann aber auch erweitert werden auf 4bpp (oder noch mehr). Das erlaubt jedem Pixel unabhängige 16 oder mehr Farben. Dieses Mehr an bpp geht nun fast immer auf Kosten nochmals halbierter horizontaler Pixel, falls dies überhaupt vorhanden ist:

Ohne jegliches 4bpp Bitmapmodi kommen neben all den Rechnern ganz ohne Bitmap, und den bereits bei 2bpp schon ausgeschiedenen, weitere welche hier wegfallen. Darunter alle MC6847, die CGA (wäre 160x200 wie CPC), VIC-20/VC-20 und C64 und TED, KC 85/4 (wäre 160x256 wie BBC). Aber die TV Dazzler kommt wieder dazu (kann nur 1bpp und 4bpp, aber kein 2bpp). (Die CGA kann mit "Tweak Mode" auf zumindest recht ordentliche 160x100 in 16k kommen. Aber das wurde wegen unbekannt selten benutzt.) (PCjr lieferte die 160x200 und sogar 320x200 in 32k. Aber erst TGA machte diese bekannt.)

(Die TMS9918 könnte eigentlich mit gleicher Schaltung und nur anderem vertikalen Timing in "Multicolor" 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.)

Die 16bit ziehen teilweise genauso mit. Ein paar von ihnen haben selbst bei 2bpp immer nicht ihre ganze Bandbreite vom Speicher ausgenutzt, und gehen daher für 4bpp mit gleicher Auflösung auf doppeltem Speicherplatz weiter. Wieder Amiga 640x200 in 64k bzw 640x256 in 82k (plus noch Overscan) sowie EGA 640x350 in 4*28k. 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 in 32k. Der QL halbiert auch, mit noch 256x256 in 32k. Der Amiga kann neben 640x200 bzw 640x256 durchziehen auch 320x200 in 32k bzw 320x256 in 41k (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. Auch mit Sprites ein Hintergrund als Bitmap simulieren passt hierhin, mit 320x224 in 35k, oder mit weniger Overscan 304x208 32k.

Die Farbauswahl geht jetzt immer auf 16 Farben, die Frage ist nur noch welche. Am schlechtesten ist es bei BBC und QL, die nur 8 Farben kennen und das vierte bpp nur für (reversfarbig) blinken benutzen können. DEren grosse Schwäche. Etwas besser bei Atari 800 mit GTIA Modi, der entweder 16 Helligkeitsstufen eines Farbtones oder 16 Farbtöne in einer Helligkeitsstufe oder nur 9 Farben aus 128 bietet. Apple IIe "Dual High Resolution" mit NTSC Farbmonitor offeriert mit seinem pseudo-4bpp 15 NTSC Farben. Vergleichbare 16 hat es beim TMS9918 "Multicolor". TV Dazzler hat 16 RGBI Farben. Sogar 16 aus 27 der CPC, 16 aus 64 die EGA, 16 aus 512 (bzw 4096) beim ST (bzw STE) und Amiga.

Farbzellen machen hier praktisch keinen Sinn mehr. Daher gibt es sie nicht als Kombination der beiden Ansätze (ausser beim Neo Geo, wenn man das FIX oder in Sprites Bitmap simulieren hier hinzunimmt, ist es sogar mit 16x16 Farbzellen, jede mit einer von 256 Sätzen zu je 15von16 Farben aus 65556). Was aber ansgesichts von umschaltbaren bpp Modi aber bei allen fehlt ist das was eigentlich ideal wäre: Umschalten zwischen für Text optimale hohe Auflösung mit 1bpp und Farbattribute fuer trotzdem 16 Farben (was auf die 2bpp Datenmenge kommt) und für Graphik optimale halbierte Auflösung mit vollen 4bpp ohne "Attribute Clash" bzw "Color Spill". Entweder man bekommt 4bpp aber bei 1oder2bpp keine Farbattribute, oder hat dort Farbattribute aber kein 4bpp oder sogar kein 2bpp (ausser bei V9938).

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 in 51.25k kann er noch volle 32 aus 4096. Bei 6bpp in 61.5k liefert er nur selbige 32, aber in voller und halber Helligkeit im EHB (Extra Half Bright = zusätzlich halb hell) Modus. Ebenfalls bei 6bpp gibt es dann schliesslich alle 4096 Farben aufs mal, im HAM Modus (Hold And Modify = beibehalten und modifizieren), wobei 0..15 normal 16 aus 4096 Farben setzen, und dann 16..31,32..47,48..63 jeweils eine der drei BRG Komponenten direkt mit 4bit modifizieren während den beiden anderen beibehalten. All diese auf kosten von nur noch 320x200 bzw 320x256 falls nur die 0..15 benutzt oder gar nur /3= 106x200 bzw 106x256 bei vollen 4096 Farben. All die enorm guten fast photorealistischen Bilder welche dem Amiga seinen Ruf aufbauten wurden in diesem Modus erzeugt. Auch hier wird der Prozessor trotz halbierter Auflösung etwas gebremst, zu 5bpp 11% bzw 6bpp 22%.

Sogar mehr als 6bpp liefern die V9938 und V9958 mit "G7" 256x192 8bpp in 48k, als einzige mit 8bit. Der Atari ST könnte von seinem Speicher/Timing her 160x200 8bpp in 32k liefern, es scheitert nur an den internen Leitungen im maximal 4bpp breiten "Shifter" Chip. Er könnte mit Amiga-artiger Prozessorbremse auf 40% oder mit 6MHz DRAMs es sogar bei 320x200 in 64k. Der Amiga könnte mit seinem Timing auch auf 320x200 in 64k bzw 320x256 in 82k liefern, mit wie bei 640x200 bzw 640x256 4bpp den Prozessor 4*11=44% ausbremsend, es scheitert an den maximal 6 Bitplane Adressregistern. Die EGA könnte dies sogar mit grossen 640x200 in 8*28k 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 in 64k, so nur 1/4 ihres 256k Speichers nutzend, trotz ausreichend Speicherbandbreite für 640x400 zu haben, wie es die SVGA dann zeigten.

Zellmodi

Bitmaps sind flexibel, aber aufwendig an Speicher und Prozessor. Der ganz andere Weg zumindest Speicher zu sparen (aber nicht Bandbreite, der Bedarf daran steigt sogar noch!) 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). Auch gespart wird Prozessor um diesen kleineren Speicher umzukopieren beim scrollen, weshalb viele Spiele dies ausnutzen. Der Font ist dabei in Hauptspeicher oder Fontspeicher (oder allenfalls noch ModulROM), und somit durch passende Softfonts ersetzbar, ausser dort wo er auf ein eingebautes ROM limitiert ist. Problematisch dabei sind die fest gegebene Zellengrösse bzw Zellengrenzen, ebenso die Zellanordnung (wobei fein scrollen dieses Problem reduziert), sowie die limitierte Anzahl an 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 den fixen Zellen eher einem Stempeldruck mit nur einer Farbe. Auch dabei gilt nur noch, wieviel Menge man an Pixel bekommt, hier aber statt der Menge Bitmap nun zusammengesetzt aus Anzahl Zellen mal Pixel in einer Zelle, sowie noch wieviele Zellen man im Font definieren kann:

Alle mit nur Bitmapmodi scheiden hier aus. Darunter TV Dazzler, VCS/2600, BBC, ZX Spectrum, CPC, alle KCs, sowie alle 16bit ausser der EGA und teils Konsolen. Aber ebenfalls die Neo Geo, ohne überhaupt einen Bildhintergrund zu haben, nur Sprites!

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

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

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

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

Die Farbauswahl ist hier weit einheitlicher als bei Bitmaps. Fast alle hier vertretenen haben Farben, können Stiftfarbe und Flächenfarbe wählen. Nur die Sorcerer und Jupiter Ace haben hier keine Farben. Und der Atari 800 Zell "2" kommt hier wieder mit seinen "1.5" Farben wie bei Bitmap "F" nur halb-monochrom daher. Der TMS9918 "Text" schafft es auf 2 beliebige Farben.

1bpp/2Farben Farb+Pixelzellenmodi

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

2bpp/4Farben 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:

Ohne jegliche 2bpp Bitmapmodi kommen neben all den Rechnern ganz ohne Zellmodi, auch einige weitere ausscheidend. Darunter Sorcerer und Jupiter Ace weil weder 2bpp noch Farben, Oric weil wie bei Bitmap keine 2bpp, TMS9918 weil wie bei Bitmap keine 2bpp. Die grosse Schwäche dieser Rechner. (Bei MSX 2 und MSX 2+ dann mit den V9938 bzw V9958 umgangen mit besseren Bitmaps, aber auch dem "T2" 80x24 und 256* 6x8 2bpp.)

2bpp/4Farben Farb+Pixelzellenmodi

Auch hier sind 4 Farben im ganzen Bild weit weniger als die oft 16 Farben welche man mit Farbzellen bekommt. Also wieder Kombination der beiden Ansätze, wobei bestens Farbzellen zu Pixelzellen passen. Das vorhandene streut ebenso massiv:

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

Die SuperFamicom/SNES dreht dagegen hier erst auf. Reine Zellgraphik, aber neben 2bpp sogar 4bpp und 8bpp, und das bei 4bpp mit 8 15er Sätzen, wieder in 32x30 (PAL) oder in nur 32x28 (NTSC). Dazu sogar noch massive 4 Layer, mit bei 2bpp jedes Layer eigene 8 3er Sätze (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 gering an Speicher, aber intensiv an Bandbreite und Logik, und waren daher die letzte Neuentwicklung vor Bitmap. Davor gab es den Textmodus, mit etwas weniger Logik, und zwei separaten Speichern um Bandbreite zu verteilen, mit dem Font nur in billigem ROM. Dies ist technisch uralt. Jedes Texterminal (ausser solchen mit Softfonts) basiert ausschliesslich auf diesem!

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

Sprites

Bitmaps sind flexibel aber aufwendig an Speicher und Prozessor. Dies erst recht wenn man Auflösung für Details und viele Farben für Spielfeld und sich bewegende Objekte haben will. Dies ist machbar, wie es Acorn BBC und Apple IIe und Amstrad/Schneider CPC zeigen, zum Preis von 160x256 4bpp in 20.5k bzw 140x192 pseudo-4bpp in 16k bzw 160x200 4bpp in 16k an Speicher, sowie viel Prozessor. Auch Atari ST und IBM EGA verwenden den selbigen Ansatz, nur mit 32k 16bit bzw 4*28k 4*8=32bit Speicher. Zellen sparen Prozessor und etwas Speicher, aber sind 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. Aber der Hardwareaufwand diese zu verwalten und einblenden ist sehr gross, daher sind sie nur in wenigen grossen Customchips enthalten. Bei 8bit waren dies nur wenige neuere, bei 16bit die meisten (alle ausser Macintosh und QL und ST). Diese streuen dementsprechend erst recht massiv:

Scrollen

Sprites erlauben schnelle Animation, sind aber auf Spielobjekte limitiert. Gerade bei scrollenden Spielen will man aber das ganze Bild wie ein Sprite verschieben, und die Sprites davon unabhängig. Dies ist sogar von der Hardware her weit einfacher zu machen als Sprites. Auch dafür haben manche Rechner Logik vorgesehen:

Ranglisten nach Kategorien

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

8bit mit Customchips mit Sprites

Platz 1 geht gerade noch an den Commodore 64. Hat 320 Pixel statt bloss 256. Hat Zell und Bitmapmodi, beide in 1bpp und 2bpp (wenn auch bei letzterem nur 160 Pixel). Vollen 256er Font in den Zellmodi. All das zusammen mit dem 8+4=12bit Datenbus von Hauptspeicher+Farbspeicher, somit 16 Farben pro Zeichen bzw pro 8x8 Pixel Zelle, plus noch mit "Extended" 4 Hintergrundfarben von 2bpp (aber auf Kosten von 64er Font). Bei Bitmap 1bpp 2von2 bzw 2bpp 3von4 zellenweise und bei Text immer noch 1bpp 1von2 bzw 2bpp 1von4 zellenweise. Dazu die grösste Menge Spritebits pro Zeile, 8*24*1bpp=8*12*2bpp=196bit. Und noch jede Menge flexiblen Komfort wie fein scrollen und lesbarer Zeilennummer und Rasterinterrupt. Dazu ungebremsten Takt vom Prozessor (wenn auch 5% davon an die "Bad Lines" verloren gehen). Das einzige was einem hier wirklich fehlt ist Overscan. Nett wäre noch die 16 Farben aus mehr auswählen können (wie Atari 800 oder TED). Verschmerzen kann man, dass intensivere Effekte nach vorzu in Software umkonfigurieren verlangen. Die Designer vom VIC-II haben ihre Erfahrungen von PET/CBM und VIC-20/VC-20 sowie ihre "beste Features anderer Chips und Rechner vergleichen" Logik voll durchgezogen. Das Resultat ist saugut, ein abgerundetes Paket an Leistung ohne jegliche störende Löcher, der beste Videochip der 8bit Generation. Er ist so gut wie sein Ruf. Gegenüber 16bit fehlt ihm nur deren Mehrleistung, aber selbst von denen ist keiner derart gut abgerundet. Kein Wunder fängt die Demoszene mit dem C64 vorzeigen an, hier ist viel zum aufzeigen drin. Ebenso kein Wunder ist sein Name auch üer 25 Jahre nach dem Untergang von Commodore immer noch weitherum bekannt, das selbst bei Leuten welche damals noch nicht mal am Leben waren vom Hörensagen her, was ihn im wahrsten Sinne des Wortes zu einem von wenigen legendären Rechnern macht!

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

(Obiges gilt aber nur voll für die originale 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 nicht mehr selber programmierbar, braucht externe Programmerstellung und Modulproduktion. Darin ist sie kein Deut besser als der Atari VCS/2600 war! Dazu kommt erst noch, dass sie zwecks Spielezensur mit einem Lockout Chip erweitert wurde, was eigene Module herstellen verhindert, nur das erlaubte wofür Nintendo Module herstellen willig ist, mit vielen fraglichen Limiten. Damit ist nur noch Konsumieren möglich, was die Diktatur erlaubt. Es versagt somit als Medium! In Zahlen, für die etwa 2mio Atari 800 gab es in 13 Jahren um 1000 Spiele, für 17mio C64 gab es in 12 Jahren gar 2000, aber für weit mehr 62mio NES gab es trotz 20 Jahren nur um 1400. Was alles der reduzierten NES eine Disqualifikation wegen Foul einbringt!)

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

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

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

Platz 4 geht enttäuschend an den Atari 800. Er hat zwar theoretisch 320 Pixel, aber dieses nur in Modi "2" und "3" und "F" mit deren "1.5" Farben Logik benutzbar. Sonst hat dieser nur 160 Pixel (mit Overscan bis 192) breit (und damit unter der Famicom/NES ihre 192..224 (bzw 256), sowie beim VIC-20/VC-20 seinem 176). Hat ordentlichen 2bpp Support in 160er Zell und Bitmapmodi. Aber es gibt kein zellenweises Farben setzen, mit nur 4 oder 5 Farben auf dem ganzen Bildschirm, ausser man geht per Display List Interrupt und Software umkonfigurieren, was aber wegen Timing nur zeilenweise "streifig" wirken kann. Was alles ihn klar auf den vierten Platz verweist. Dazu kommt nur 128er Font, bzw wenn man die Modi "6" und "7" für 2bit an Farbauswahl nutzen will sogar nur 64er Font, nicht mal 2*64 Zeichen geschweige denn 4*64 (was der C64 alles erst für seinen 4 Hintergundfarben "Extended" Zellmodus opfert). Man merkt, dass Atari eine Spielautomatenfirma ist und erstmals einen Homecomputer aus einer halbfertigen erweiterten Spielkonsole machte, und das mit der Auflösung nicht im Griff hat, während Commodore als Bürofirma beim C64 zum zweiten mal einen Spielerechner machte, und vom ersten gelernt hat. Dazu kommen noch die zweitgeringsten Spritebits pro Zeile, nur 5*8*1bpp=40bit, was auch nicht bei korrigieren von obigen Limiten helfen kann. Die Sprites dazu noch ebenfalls mit nur 160er Raster, und gerade diese nicht detailiert, weil nur 8 Pixel breit pro Sprite. Das ist besonders schwach bei einer Spielefirma, und dazu dem Erfinder der Sprites (Pong Geräte waren praktisch nur Sprites mit etwas festem Hintergrund). Dies wurde besonders kritisch als aus dem Atari 800 die 5200 und XEGS Konsolen abgeleitet wurden. Es ist aber unvermeidbar wegen des gebremsten 7/8 Prozessortaktes und somit auch Speichertaktes, so nur 114 von den 128 Speicherzyklen/Zeile vom C64, mit davon wegen dem Overscan bis 2*48=96 statt bis 2*40=80 für den Hintergrund reserviert, so nur 114-96=18 statt 128-80=48 im Rücklauf (wo Spritebits gelesen werden). Nach Abzug vom Speicherrefresh (C64 immer 5, Atari 800 bis 9), sowie bis zu 3 weitere für die Displayliste reserviert (maximal Modus plus fakultative Adresse), verbleibt die Differenz von 8*3=24 zu 5*1=5 Spritebytes/Zeile. Da kann auch die Displayliste nichts mehr retten. Sie spart zwar selektiv Speicherplatz (und auch Bandbreite und damit Prozessorbremse) mit variabel aufwendigem Hintergrund, sowie Prozessor bei Modi im Bild umschalten bzw scrollen, aber bei Farben oder Sprites aufbessern ist sie wirkungslos, also doch wieder Software gefragt. Dabei sind Text oder Paint Programme ohnehin nur 1 Modus, und Spiele mit mehreren Modi nutzen den Prozessor zumeist nur im vertikalen Rücklauf, haben ihn im Bild frei um Modi zu wechseln. Also wurden hier Hardwareaufwand und Speicherzyklen blockieren an den falschen Ort gesetzt. Zudem ist noch die Displayliste ihre Scrollmethode nicht mit einem 8+4=12bit Farbspeicher welches die unteren Adressbits nutzt kompatibel. Damit fällt der Atari 800 wegen Bremse plus Overscan statt Spritemenge, sowie Displayliste statt Farbspeicher, auf den vierten Platz, weit abgeschlagen. Das weil mit viel komplexem Aufwand am Ziel effektiver Graphikleistung vorbeigeschossen wurde, ein klassicher Fall von Second System Syndrom! Die in der Einführung erwähnte Atari 800 vs Commodore 64 Debatte wird somit eindeutig von letzterem gewonnen, weil trotz ebenfalls zweites System nicht derart überbordet, sondern optimal gezielt.

Platz 5 und damit letzter geht noch wie zu erwarten an den Atari VCS/2600. Der erste Customchip mit Sprites, bereits in 1977, was für damals gut war. Aber ausser zum spielen praktisch unbrauchbar, und selbst zum spielen extrem primitiv. Der als erweiterte Pong Konsole mit 2*20=40 Pixel/Zeile extrem klotzige Hintergrund kann fast gar keinen Text darstellen (selbst mit 4x8 Font nur 10 Zeichen pro Zeile, und das erst noch als 2*5 wiederholt!). Die Sprites liefern auch nur 2*8 plus 3*1 Pixel = 2*8*1bpp+3*1*1bpp=19bit. Ausser man programmiert sehr aufwendige "Racing the Beam" Techniken, womit Pong Spiele genau ihre 3x5 Font Spielstandsanzeigen hinbekommen. Dazu kommt noch der grosse Programmaufwand, um zeilenweise alle Spielfeld und Sprites oder gar Farben in Software umkonfigurieren zu müssen, was garantiert dass mit den maximal 4k ROM welche adressiert werden können nur wenig Spiellogik untergebracht werden kann. Logisch weder Tastatur noch Speichermedien, keine Programmerstellung, reine Abspielkonsole. Aber zu dem Zeitpunkt verzeihbar, und mit dem Atari 800 dann auch korrigiert.

(Der VCS/2600 hielt wegen billig und früh erscheinen und somit etabliert sein, die weit bessere (aber dazu inkompatible) Konkurrenz aus dem amerikanischen Markt heraus. Was ihn ab 1977 von 3 auf 6 Jahre zu 1983 "streckte", in denen in Europa die Homecomputer den Markt direkt von den Telespielen übernamen, und Japan ohnehin noch an Spielautomaten festhielt. Dann kam wegen Atari viele Entwickler herausekeln, plus viele überhastete Spiele von denen, sowie den Limiten der VCS/2600, die Flut an Schrottspielen. Das ergab zusammen mit dessen Marktdominanz dort, den nordamerikanischen Videogame Crash von 1983. Dieser sollte richtigerweise als nordamerikanischer Videokonsolen Crash bezeichnet werden, weil die wenigen Automaten und Homecomputer Gamer dort wenig betroffen waren. Europa und Japan waren ebenso wenig betroffen, weil bereits bei Homecomputer bzw noch bei Automaten.)

(In Japan fing Automatenhersteller Nintendo gerade den Wechsel an, zu Konsolen als kleiner Automat für zuhause, mit Erfolg weil dort wenig Homecomputer verbreitet waren, und nahm danach auch gleich die am Boden liegenden USA mit. Ebenfalls Automatenhersteller Sega schaffte es wegen später startend mit dem Master System anfangs nur halbwegs in Europa sowie mehr in Südamerika. Erst mit der Mega Drive ausnutzten sie aus, dass Nintendo bei der SNES 16bit total verschlief. Aber sie schossen sich selber ab, mit dem Konflikt von Saga USA mit Mega Drive gegen Sega Japan mit Saturn. Nintendo verpeilte sich dann auch noch mit der N64, und die dabei fallengelassene Sony übernahm die Führung mit der Playstation, welche der Nachfolger der SuperFamicom/SNES hätte werden sollen bevor Nintendo ausstieg und die N64 brachte, wonach Sony alleine weitermachte. Bonuspunkte, dass davor Nintendo selber erst die Famicom/NES erzeugte, nachdem Commodore Nintendos Automatenspiele für die VC-20 lizenzieren wollte aber dann alles fallenliess, wonach Nintendo die Idee aufgriff und als Famicom/NES umsetzte.)

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

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

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

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

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

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

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

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

Platz 1 und 2 gehen etwa gleichauf an den Acorn BBC Micro und den Amstrad/Schneider CPC. Deren 640 Pixel liefern bis zu 80 Zeichen trotz 8Pixel breit, für viel Text. Aber viel entscheidender sind bei 320 Pixel bereits 2bpp und vor allem bei 160 Pixel volle 4bpp. Somit können diese selbst die recht primitive Logik und das Fehlen von Sprites grossteils wettmachen! Wo exakt sie in obiger "mit Sprites" Kategorie landen würden ist offen. Wohl irgendwo unter dem C64 und über dem Atari 800, ziemlich sicher oberhalb vom TMS9918 (aber unter V9938 und V9958 und Master System), und eher unter der Famicom/NES. Damit schlagen sie erst recht locker alle in der "ohne Sprites" Kategorie, ausser den TED der noch halbwegs mithalten kann. Und hier in dieser sowieso alle. Preis dafür ist der Verbrauch von sehr viel Bildspeicher (beim BBC wählbar 20.5/16/10.25/8k, im CPC fest 16k), sowie viel CPU um diesen umzuschaufeln (was deren ungebremsten 2MHz 6502 bzw 4MHz Z80 aber auch recht gut können, gerade auch die Z80 mit ihrem eingebauten LDIR/LDDR Blockkopierer, 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 dem halbierbarem Speicherplatzverbrauch punkten, aber der CPC mit 3*3*3=27 statt nur 2*2*2=8 RGB Farben gleichauf oder eher leicht voraus ziehen. (Beide wären mit 4*4*4=64 RGB Farben optimal.) (An weiterer geringer Schwäche haben sie nur fehlendes horizontales fein scrollen.)

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

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

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

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

Platz 6 geht überraschend an den Exidy Sorcerer. Zwar ohne Bitmap, und nur 1bpp, und keine Farben, wenn auch immerhin 512x240 Pixel. Aber er wird durch die 128 Zeichen RAM Font zusätzlich zu 128 Zeichen ROM Font gerettet, womit auch ohne Bitmap volle 64x30 Zellen mit beliebigen 8x8 Muster machbar sind. Ist damit an Auflösung oberhalb KC 85/2, bleibt aber mangels Farben hinter diesen, und mangels Bitmap hinter Visible Memory. Man merkt hier die Erfahrungen aus Spielautomaten herstellen, wenn auch noch auf primitivem Stand der 1970er.

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

Platz 8 geht erst massiv abgeschlagen an die IBM PC CGA. Diese kann eigentlich 640 Pixel, oder 320 mit 2bpp, und damit zwei Modi der BBC und CPC, mit dem selbigen 16k Speicher wie letzterem, was die 4.77MHz 8088 erst recht problemlos umschaufeln kann. Aber genau der weitere Modus mit 160 Pixel und 4bpp fehlt hier massiv. Noch schlimmer, auch bei 2bpp ist nur eine Farbe frei wählbar, und diese erst noch an die Randfarbe gekoppelt, und muss damit Hintergrund sein. Dazu kommen noch wenige feste 3er Farbsätze ohne Schwarz darin, welche den Register/Rand praktisch auf Schwarz zwingen. Daher kommen die vielen für die CGA typischen Spiele mit Sw+Gn+Rt+Ge oder gar Sw+Cy+Vt+Ws. Zudem kann die CGA dies nicht bei 1bpp mit Farbattributen retten, weil sie nur in Textmodus Attribute hat. Der 1bpp ist aber wenigstens noch mit Schwarz plus einer freier Farbe. Damit fehlen bei Bitmap alle Methoden um die Effekte von Sprites zu ersetzen. Aber auch im Textmodus wird es nicht besser. Zwar hat es hier Attribute, aber es hat keinen RAM Font, was ihn selbst hinter die ZX Spectrum und Oric und Jupiter Ace Billigrechner stellt. Und zu dessen Blockgraphik benutzen zwingt, welche aber auch nur 1x2 Blöcke liefert, nur 80x50 erlaubt trotz 80x25 Zeichen. Egal was man hier versucht, die CGA macht einen Strich durch die Rechnung, verhindert gute Graphik und frustriert! Bonuspunkte gibt es aber für die ganze Schaltung am Ende vom Handbuch abgedruckt.

(Nur mit dem vielen unbekannten "Tweak Mode" kommt man mit 2x1 Blockgraphik und 8x2 Font noch auf halbwegs ordentliche 160x100@4bpp mit 16 Farben. Wobei die CGA selbst bei dieser Pseudo-Bitmap in der Auflösung unter allen drei Billigrechnern ZX Spectrum und Oric und Jupiter Ace liegt. Zudem war dies zumeist unbekannt, weshalb nur wenige Spiele es nutzten. Womit die CGA selbst hinter all diesen landet!) (Strikte kommt man mit NTSC Monitor und 640x200 Modus sogar auf 160x200 pseudo-4bpp in 15 Farben. Aber dies ist mit dem üblichem IRGB Monitor gar nicht machbar.)

(Bei PCjr gab es dann die fehlenden 160x200 mit 16 Farben, was für zwischen BBC+CPC und KC-85/4 auf Platz 3 landen gereicht hätte. Es hatte sogar 640x200 mit 4 Farben und 320x200 mit 16 Farben in 32k. Was Platz 1 gegeben hätte. Nur ist dieser an der gnadenlos verhauenen Tastatur gescheitet.)

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

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

(Der Apple IIgs erweitert auf 640x200 mit 4 Farben und 320x200 mit 16 Farben in 32k. Er ist damit fast zu PCjr identisch, nur mit 4096 statt 64 Farbauswahl, und mit 320x200 zeilenweise 16er Farbsätze, und 640x200 spaltenweise 2 4er Farbsätze. Was erst recht Platz 1 gegeben hätte. Nur war er 1986 zu spät um noch etwas zu erreichen.)

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

8bit ohne Bitmapgraphik oder RAM Font

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

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

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

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

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

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

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

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

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

16bit Systeme

Platz 1 geht wie zu erwarten an den Commodore Amiga. Ein vierfacher Atari 800, mit 640 Pixel bis zu 4bpp oder 320 bis zu 6bpp. Das sind bis auf 64k NTSC oder 82k PAL an Speicher. Damit geht er bis an oder gar über die Grenze von 320x200 8bpp ihren 64k. Dazu kommen viele Farben (32 normal oder (2*)32 EHB oder 4096 HAM) und volles Overscan und fein scrollen. Dies alles mit Copperliste beliebig vorzu umstellbar (und dieser bis beliebige Zeile pausierbar). Dazu kommen recht viele Spritesbits, 8*16*2bpp=256bit, ideal für bewegtes 2D. Aber die Bitplanes und ihr "Ghosting" beim scrollen vom Spielfeld stören massiv, hier am schlimmsten ausser noch beim KC 85/4. Ausser das Bild wird zeilenweise verzahnt angeordnet. Der Blitter beschleunigt Umkopieren und rekombinieren, was aber wegen Setup Aufwand sich erst bei grossen Flächen lohnt, genau wo die Sprites versagen, aber auch wo "Ghosting" am schlimmsten wird, und somit den Einsatz limitiert. Oder er wird nur zwecks Compositing mit Doublebuffering benutzt, ohne jegliches "Ghosting", wo er 2D rendern sogar optimal beschleunigen kann. Der Copper ist halbwegs nützlich, aber nicht wirklich dringlich, weil er letztlich nur alle Rasterinterrupt Techniken beschleunigt (wie die Atari 800 Displayliste), wenn auch weit mehr davon. Anderseits kostet er mit Speicherzyklen blockieren ebenfalls Spritebits (wie Atari 800). Damit ist der Amiga eine gute Erweiterung seines Vorfahren Atari 800, praktisch alle dessen Schwächen grossteils beseitigt. Aber dessen Prozessortakt auf 7/8 gebremst bleibt weiterhin bestehen. Weiterhin gibt es Abstriche wegen viel überflüssig komplexem Hardwareaufwand, aber dann unnötig Takt gebremst. Alleine die Bitplanes verlangen nach pro Plane Adresslogik während Chunks (und auch Pseudopitplanes) nur eine gemeinsame Adresslogik bräuchten, womit selbst Pseudopitplanes statt echten eine Vereinfachung wären und erst noch einfacher zu benutzen als verzahnt anordnen (und womit das was beim ST kritisiert wird hier schon eine Verbesserung wäre!). Weiterhin war die fehlende Aufspaltung in Amiga 500 und 2000 ein massiver Fehler. Der Amiga gewinnt aber trotzdem, als besten der 16bit Generation. Wenn auch nicht ein so abgerundetes Paket wie der C64 es war, was aber auch für alle anderen 16bit Rechner gilt. Er gewinnt vor allem wegen den vielen bpp, und erst noch trotz grosser Auflösung, wenn auch damit weiter um bis zu 44% der 7/8 gebremst, ausser es hat externes "FastRAM" und das "ChipRAM" wird zu separatem Bildspeicher. Aber ebenso gut wegen vieler ausnutzbarer Möglichkeiten, vor allem die Sprites. Kein Wunder ging die Demoszene vom C64 zum Amiga weiter. Ebenso kein Wunder ist sein Name fast genauso bekannt wie dieser, was ihn ebenso legendär macht!

Platz 2 geht auch nicht überraschend an den Atari ST. Selbst mit dem Schwarzweiss Monitor schlagen seine 640x400 1bpp dem Macintosh seine 512x342 1bpp locker, mit 32k um ein Drittel mehr als dessen 21.8k. Dazu noch ohne Prozessor anzuhalten. Eben der bessere Jackintosh. Fehlende mehr als 1bpp plus Schwarzweiss machen dies aber für Spiele unattraktiv, verlangen nach dem farbigen Monitor. Damit ist er ein vierfacher Commodore 64, mit 640x200 2bpp und 320x200 4bpp aus 32k. Sie sind sogar identisch mit einem Amiga, solange man dort nicht Prozessor für mehr bpp und/oder Farben opfert! Kann man hier nicht, weil keine Bitplanes. Daher auch kein "Ghosting", wenn auch weiterhin Probleme wegen Pseudobitplanes. Auch mit gleichem Prozessor, aber volle 8MHz statt die Macintosh 7.8336MHz, und gar 1/8 mehr Takt als die Amiga 7.1591MHz. Dazu noch ungebremst durch Video (wie auch Amiga). Selbst fehlender Blitter und Copper und Sprites sind mit einem so schnellem Prozessor und mehr Speicher und 4bpp nicht ganz mehr so kritisch, wie es einige damalige Spiele zeigten. Aber auch er verfehlt ein so abgerundetes Paket zu sein wie der C64, diesmal wegen zuwenig sein statt zuviel. Insbesondere fehlt horizontal fein scrollen, was alle scrollenden Spiele zu wiederholt rendern mit Doublebuffering und Compositing zwingt. Wozu er genug Speicher hat, aber die Pseudobitplanes bremsen beim rendern von kleinen Objekten aus. Anderseits konnten scroll-lose RPGs unbeeinflusst davon das Mehr an Prozessor und Speicher zwecks Illustrationen decomprimieren oder gar Szenen rendern ausnutzen. Selbiges gilt für die fehlenden Sprites, es fehlen die einfachen aber grossen vom C64, was wieder wegen Compositing brauchen komplexe bewegende Graphiken ausbremst, aber statische RPGs nicht trifft. Generell gewinnt dieser "Big CPU" Ansatz vom ST vor allem bei Illustration/3D, während Animation/2D eher vom Amiga "Koprozessor" Ansatz profitiert. Das alles weil der ST eigentlich mehr ein verdoppelter CPC ist, aber dabei verfehlt vierfach zu sein. Womit er strikte eher ein vierfacher Apple II Plus ist. Was alles den ST auf den zweiten Platz verweist, wenn auch recht knapp. Mit fein scrollen hätte er bereits den ersten Platz geteilt. Mit Chunks statt Pseudobitplanes (wie BBC und CPC), und damit rendern schneller sowie fein scrollen um Faktor 4 weniger wichtig, hätte er ebenfalls den ersten Platz geteilt, selbst ohne fein scrollen. Mit zudem vervierfachte grosse Sprites vom C64 hätte er den ersten Platz alleine genommen! Oder mit "doppeltem" 64k Bild, und somit vierfachem CPC (bzw eher Apple IIe), ebenfalls alleine! Er wurde damals auch ziemlich unterschätzt, gerade im Vergleich mit dem Amiga, wenn auch nicht ganz so extrem wie TED oder gar VIC-20/VC-20.

Platz 3 geht an die SNK Neo Geo. Kann massive 256*16 Farben, und das aus 65536. Hat ein 320er Raster, mit 4bpp. Wenn auch das bereits mit dem Overscan Bereich, 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 volles Bitmap simulieren, solange der kleine separate Bildspeicher noch ausreicht. Kein interlaced. Was alles ihn leicht weiter hinter den Amiga stellt. Nur mit 320 Textfenster aus 400 mit Overscan, sowie 640er 2bpp pro Sprite schaltbar, hätte er die beiden geschlagen. Keine Tastatur oder Disk plus Speicher, und damit die Limiten aller reinen Abspielkonsolen gegenüber Homecomputer. Was ihn klar hinter dem Amiga und auch dem ST stellt. Dazu aber massive 96 mal 16 Pixel Sprites pro Zeile, mit 4bpp, und somit die besten Spritebits überhaupt hier, 96*16*4bpp=6kbit(!) und die typischen grossen Sprite Objekte in dessen Spielen, was ihn doch bis an den spritelosen Atari ST aufrücken lässt. Dabei merkt man nicht nur die Erfahrungen aus Spielautomaten herstellen, sondern dass die AES ein voller MVS Automat in Konsolenform ist!

Platz 4 geht an dann die Sega Mega Drive. Kann 4*16 Farben, aber aus nur 512, wie Atari ST, somit unter Amiga und gar Neo Geo. Ein 256 schmales bzw 320 normales Textfeld mit 4bpp, wenn auch in horizontal nur mehr Breite, aber kein volles Overscan. Aber kein 512 oder 640 Feld. Kann aber interlaced. Was alles ihn deutlich hinter dem Amiga stellen würde, weniger hinter dem Atari ST und etwa gleichauf mit der Neo Geo. Aber hat nur Zellmodus, trotz vollem 16bit keinerlei Bitmap, was ihn klar hinter die Neo Geo verweist. Dazu aber gute 20 mal 32Pixel an Sprites pro Zeile, mit 4bpp, und somit die zweitbesten Spritebits, 20*32*4bpp=2.5kbit, aber weit hinter der Neo Geo ihre 6kbit. Diese sind somit nicht ausreichend um fehlendes Bitmap zu simulieren, oder auch nur bandweises Parallax, bleibt so deutlich hinter dem Neo Geo. Keine Tastatur oder Disk plus Speicher, reine Abspielkonsole, kann auch so nicht überholen. Im Vergleich zu seinem Vorfahren Master System neben 320 Pixel breiteres Textfeld vor allem Dual Playfield und besserem scrollen sowie mehr Farbregister und in diesen mehr Farben. Eher sachte erweitert, aber gerade dort wo es entscheidend fehlte. Auch hier merkt man die Erfahrungen aus Spielautomaten herstellen, weil dieser explizit als 16bit Automatentechnologie in die Konsolen bringen designt wurde. Aber diese waren ältere und 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. Hat ermanentes Overscan /was etwa (48..56)*8=384..448 breites Textfeld ergibt). Aber auch all das wurde auch selten genutzt. Ist sonst nur 256 breit (was weiterhin nur etwa (24..28)*8=192..224 Textfeld ergibt, und die typische klotzige Schrift wie schon bei der Famicom/NES), was ihn hinter Sega Mega Drive und Neo Geo stellt. Kann auch interlaced. Kann aber ebenfalls wie Mega Drive nur Zellmodi, was ihn klar hinter die Amiga und Atari ST und Neo Geo verweist. Kann viele oder grosse Sprites, aber nicht beides zusammen, weil Menge an Spritebits pro Zeile reduziert wegen HDMA, maximal 34 Zellen zu 8Pixel mit 4bpp an Sprites, 34*8*4bpp=1088bit, was ihn selbst klar hinter die Mega Drive ihre 2.5kbit stellt. Zudem schwach mit dem langsamsten nur 8/16bit 65816 Prozessor, klar hinter allen echt-16bit 68000 basierten, selbst hinter 16/8bit 68008. Keine Tastatur oder Disk plus Speicher, reine Abspielkonsole, kann auch so nicht überholen. Der Mode 7 pseudo-3D Texturen reicht nicht um all dies noch zu retten. Hat im Vergleich zu seinem Vorfahren Famicom/NES vor allem weit mehr Speicher und Bildspeicher (bzw sogar separate Zeichenspeicher und Fontspeicher) statt ModulROM basierte Fonts, sowie mehr Bandbreite und Layer und/oder bpp, ebenso massiv mehr Farben. Aber kein Wunder dass die Mega Drive die SuperFamicom/SNES ernsthaft hindern konnte, und an manchen Orten sogar komplett abservierte.

Platz 6 geht abgeschlagen an den Sinclair QL. Kann zwar noch maximal 512 Pixel, und das mit 2bpp. Aber die 2bpp sind für Text wo man die vielen Pixel nutzen will fast sinnlos. Ohne Farbattribute oder Farbregister nur in 4 festen Farben, fast auf MC6847 Niveau unten (nur leicht bessere Auswahl mit schwarz, und 512x256 statt 128x192 Pixel). Nur 1bpp plus Attribute wäre gleichviel Daten (2*16k statt 32k) aber nützlicher (16 Farben wie Spectrum). Selbst reine 2bpp Graustufen wären wohl sinnvoller. Kann für Spiele 4bpp mit 256 Pixel, aber hat dann wegen gerade bei Graphiken sinnlosem blinken trotzdem nur 8 RGB Farben, unterhalb vom Spectrum seinen 16 auf Acorn BBC 8+blink Niveau (nur mit leicht besseren 256x256 statt 160x256 Pixel). Hat somit 2 Modi, aber keiner davon ist wirklich gut, frustrierend wie bei CGA und Apple II. Wohl die Folge von sowohl Spectrum Nachfolger wie auch Businessrechner Projekte zu einem Kompromiss zusammenlegen, und bei beidem versagen. (Man kontrastiere dies mit dem Atari ST, mit Schwarzweiss für Business und Farben für Spiele, beides richtig gemacht.) Dazu noch keine Sprites wie beim Atari ST, aber auch ohne dessen 320 Pixel und wählbaren 16 Farben. Somit schwächste Farben in der 16bit Generation. Zudem schwach mit dem langsameren nur 16/8bit 68008 Prozessor, auch hinter allen echt-16bit 68000 basierten. Er ist er sogar graphisch erstaunlich schwächer als sein erstaunlich guter 8bit Vorfahre ZX Spectrum mit dessen 16 Farben. Lediglich Prozessor und Speicher schlägt er diesen, und alle anderen 8bit, und sogar die SuperFamicom/SNES. Aber selbst Tastatur und Microdrive Endlosbandlaufwerke plus Speicher können ihn somit nicht mehr retten, er f&auuml;t selbst hinter den 16bit Konsolen zurück!

Platz 7 geht weiter abgeschlagen an den Apple Macintosh. Mit für 16bit Generation eher niedrigen 512 Pixel Auflösung, was mit dem 6x12 Pixel Font halbwegs gerettet wird. Aber gar keine Farben, trotz dass alle anderen 16bit diese haben. Selbst bei Schwarzweiss nur 1bpp, nicht mal 2bpp Graustufen. Damit klar selbst unter dem Sinclair QL! Dies gibt ihm keine Chance. Somit schwächste Graphik dieser Generation, mit Abstand. Mit 21.8k nur 2/3 vom QL und ST 32k, nicht mal dreifacher Apple II, nicht mal die Hälfte mehr Speicher als beim CPC 16k, und nicht mal ein Viertel mehr als beim Acorn BBC und KC 85/4 20k, sowie ohne deren Farben und Modi, alles Rechner welche ich daher über den Mac setze (und diese wiederum alle unter dem C64). Selbst Tastatur und Disk plus Speicher können ihn nicht mehr retten, zumal jahrelang (Jan 1984 bis Sep 1986) keine auf dem Rechner laufende Entwicklungswerkzeuge existierten! Man musste dazu einen separaten schweineteuren LISA benutzen (und dort ein separates "Lisa Workshop" Softwaresystem statt dem normalen "Lisa Office System" benutzen), ein Mac alleine wie bei Konsolen nur Konsum erlaubte. Erst "Macintosh Programmers Workshop" auf dem Mac Plus (1986) erlaubte dort zu entwickeln, als Ersatz nachdem die LISA bereits in 1985 eingestellt worden war! (Strikte war ein MacBasic geplant und ist sogar geschrieben worden, aber Microsoft hat dieses mit Drohung die Apple II Basic Lizenz nicht zu verlängern begraben.) Eigentlich eine sehr primitive Kiste für seine Zeit, weil eben bloss bessere elektronische Schreibmaschine (wie Amstrad PCW8256). Man kontrastiere dies mit seinem Vorfahren Apple II, dem ersten Rechner mit Farben und Bild aus DRAM und wählbare Modi, mit je 1MHz an Prozessor und Video Zugriffe auf 2MHz Speicher ungebremst, gegenüber nun dem Mac, der einzige 16bit Rechner ohne Farben und ohne Modi, mit 2MHz Prozessor und 1MHz Video Zugriffe auf 2MHz Speicher kollidierend. Strikte wäre anstelle vom Macintosh ein vierfacher Apple II Plus angebracht gewesen, mit etwa Atari ST Video, bzw etwa Apple IIgs Video! Der Mac ist dagegen bloss etwa der Apple 1 der 16bit Welt! Der angeblich "graphische" Macintosh bezieht sich somit absolut nicht auf die schwache Hardware, zu welcher sein Spitzname "Macintrash" bestens passte, sondern nur auf die GUI Software. Die leistete in 64k ROM weit mehr als dem Atari ST seine 192k ROM! Das Resultat von 4 Jahre Entwicklung und Optimierung, statt in unter 1 Jahr zusammengeworfen worden.

(Trotzdem war diese Software für den Rechner zu viel, weil GUI und 16bit einfach nicht zusammenpassen. Ebenso waren die Fenster für den kleinen 9" Monitor mit nur 512x342 Pixel zu viel. Zudem war der graphische Dateimanager ohne Harddisk erst recht langsam. Was alles zum Spitznamen "Mickey Mouse Rechner" führte, sowie zusammen mit seiner Flut von Dialogboxen zum Spitznamen "Meckertopf". Die LISA war mit nur 5MHz trotz 720x360 sogar noch schlimmer. Was alles auch für den Atari ST galt, trotz ungebremstem 8MHz Prozessor und 640x400 Pixel. Dazu kam noch visuell unpassender falls mit 640x200 Zeilen im Farbmodus. Selbiges galt mit Microsoft Windows auf 286er (oder gar noch schlimmer 8bit 8088er), mit EGA 640x350 wegen 4bpp langsam, oder mit CGA 640x200 visuell unpassend. Noch mehr galt dies beim Amiga, um 1/8 untertaktet und mit 640x200 stets visuell unpassend und dazu noch bei viele bpp langsam. (Ebenso unpassend war beim Amiga volles präemptives Multitasking auf einer Spielkonsole welche zu einem Homecomputer erweitert wurde, dessen Customchips aber Singletasking Koprozessoren waren, und der keinen Speicherschutz hatte.))

(Erst die 32bit Generation lieferte genug Prozessor (ab 30MHz) und Speicher (ab MBytes) und Bandbreite (ab 10MByte/s) für GUIs, ebenso einen Speicherschutz für Multitasking, sowie Harddisk Zugriffszeiten damit ein graphischer Dateimanager nicht schnarchlangsam ist. Insbesondere hatten diese erst ausreichend Auflösung für Fenster, mehr als 640x400 für mehr als 80x25 Zeichen mit 8x16 100dpi Font (oder zumindest mehr als 512x300 für mehr als 80x25 Zeichen mit 6x12 72dpi Font), plus GUI Elemente, plus Fensterrahmen, mit noch genug von anderen Fenstern sehen, dass diese sich überhaupt lohnen. Aber mit trotzdem genug Farben für Graphik, ab 8bpp. GUIs wurden somit real brauchbar ab 800x600@8bpp aus 512k Bildspeicher, und erst echt gut ab 1024x768@8bpp aus 3/4MByte oder gar 1152x865@8bpp aus 1MByte. Also SVGA oder Macintosh II oder Atari TT oder Amiga AGA, alle ab etwa 1990, und somit erst 2 Chipgenerationen nach der GUI Einführung!)

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

Ganz ausserhalb der Konkurenz ist die IBM PC EGA. Ihre massiven 4*64=256k stellen sie weit oberhalb der 64k Grenze, und somit disqualifiziert. Auch den EGA Spezialmonitor brauchen kommt dazu. Aber selbst mit 256k liefert sie nur maximal 4bpp. Typisch IBM, welche Auflösung mehr schätzt als bpp. So verliert sie bereits gegen dem Amiga seinen 6bpp aus nur 48k! Ebenso fehlen Overscan und Sprites. Damit könnte sie noch auf dem zweiten Platz, wenn nicht mit ihrem 8 mal mehr Speicher massiv teurer als dem Atari ST, der somit hier vorbeizieht. Die Sega Mega Drive und SNK Neo Geo und Nintendo SuperFamicom/SNES verlieren an der Auflösung, mit zudem Mega Drive und SuperFamicom/SNES an fehlenden Bitmaps. Auch die fehlenden Tastaturen und Disks können alle drei nicht mehr retten. Sie werden somit von der EGA geschlagen. Aber gegen deren Sprites und sonstigen Effekten und Farben kann die EGA nichts anrichten, noch ohne dem 8bpp MCGA Modus der VGA. Den "graphischen" Mac schlägt sie aber locker, schlicht weil der keine Farben kann, oder auch nur Graustufen, und weniger Auflösung hat. Auch der QL hat keine Chance, mit nur 4 oder 8 festen Farben.

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


Home | Artikel | VCFe Videoarchitekturen als visuelles Medium

Diese Seite ist von Neil Franklin, letzte Änderung 2020.11.27