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, sind 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 gegen Z80 Debatte mit Hilfe von Benchmarks in Forth vergleichen entstand, wo ich die Forth Interna als Einschub brachte, kommt hier wieder etwas vergleichbares dazwischen.

Diesmal eine Atari 800 gegen Commodore 64 Debatte, welche dazu führte, dass ich den Atari genauer anschaute und mit dem mir bestens bekannten C64 verglich. Gefolgt von nach einem letztjährigen Vortrag diese noch mit den TMS9918 basierten Rechnern vergleichen, und auch gleich mit dem Nintendo Famicom / NES. Weil dieses Jahr gerade 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", bzw genauer als "was können diese damit anstellen", was sehen sie dabei, was müssen sie dazu wissen. Dazu werde ich vor allem die Videomöglichkeiten von ein paar guten als "Super Spielkonsolen" designten Homecomputern als visuelle Medien vergleichen. Der immer grösseren Vollständigkeit halber hab ich dann nach und nach weitere graphischen Rechner als Übersicht dazugenommen. (Diese Menge ist seit dem Vortrag erstmals halten deutlich weiter angewachsen. Ebenso die Details an Details zu den einzelnen Systemen.)

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 64kByte) 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 Super-VGA 640x480 8bpp (braucht 300kByte) wurde es komfortabel (nur 640x400 passten noch in 256kByte), mit 80x30 (bzw 80x25) Zeichen in 8x16 Font zulassen. Ab 800x600 16bpp (braucht schon 1024kByte) 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 mehrere sichtbare Fenster erlauben. Somit sind 320x200 8bpp in 64kByte 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 Adresserweiterung maximal 64k Speicher adressieren können, beinhaltend System plus Bild plus Benutzerprogramm plus Daten. 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 64kByte (und selbst viele vor 256kByte) 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, aber 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, wie damit umgehen ist. Dabei liegt der Fokus vor allem auf Spielszenen mit bewegten Objekten darin, weil das die grössten Ansprüche am Graphik stellt, und somit einen kritischen Test abgibt. Aber auch Text editieren muss effektiv gehen, und sei das nur um Programmcode und Objektdaten der Spiele in den Rechner einzugeben!

Die Spielregeln

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

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

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. 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, trotz mit 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. Eigentlich 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. (Zudem 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 2504 Schieberegister als Bildspeicher, was mangels Adressierbarkeit keine beliebige Cursorsteuerung erlaubt, somit kein veränderbares Bild, nur reine Fernschreiber Emulation, und diese zudem 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, sowie alle Cursorsteuerung in Software implementiert. Er kann sogar mit einem Umschaltbit 2 Bildseiten zu je 1k benutzen, was Animation vereinfacht. Dieses geht bei 1k Videospeicher noch problemlos mit umkopieren, aber bei 8k Bitmap Videospeicher wird es langsam. 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 Versuches diesen an Commodore zu verkaufen, der scheiterte weil Steve Jobs zu gierig war. 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 zur Apple 1 als zur Apple II Situation passt. Weitere Aussagen besagen, dass Chuck Peddle den PET als Fortsetzung der TIM Serialterminal und KIM-1 Hexkit Rechner ausdachte, die zwecks Vermarktung des 6502 Prozessors und als Entwicklungssysteme entwickelt wurden. 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 Jack Tramiel davon überzeugte. Mit dann nach obigem Apple II Verkauf scheitern den PET umsetzen. Die Fortsetzung könnte auch erst nach den 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, 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 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 25 Zeilen 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) nun als 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, dass Farbfernsehen als Erweiterung vom bestehenden 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 obige 4bit als "Viertelwellen" 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, weil beide eine 14.31818/2=7.1591MHz Schwingung erzeugen, keine 3.5796MHz und damit total entsättigt! Mit 3.5796MHz 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), mit dabei Farbton aus der Bitanordnung und Phase der 1er, sowie Helligkeit aus der Anzahl 1er. 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 erzeugen. 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 gemäss Handbuch "abweichen können" (im Original: "colors generated may differ").

(Blockgraphik wurde für Breakout-artige Spiele addiert, wo solche Klötzchen graphisch ausreichen. Der Apple 1 und II Designer Steve Wozniak hatte für Atari am Breakout Spielautomaten optimieren gearbeitet. Aus selbigem Grund hat der Apple II auch Paddle/Analogjoystick Anschlüsse und Beep Audio bekommen.)

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 aber vorne an die bestehenden 10bit Adressen angelegt! 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 aber weit komplizierter, das Bitmap wird dabei als direkt binär codierte "Halbwellen" 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. Dieses 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 25% oder 75% entstehen, ebenso kein Grau 50%.

Dabei entsteht in erster Näherung eine Art pseudo-2bpp, mit 3.5(!) Pixel pro Byte, und so 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 pseudo-Pixel) ergibt, statt alle 8 (bzw 4), mit so nur Zeit um 7 Bits als Pixel zu versenden.

Strikte 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 Monitortyp. Der Monitor bekommt ohnehin nur 280 Pixel ihre Wellenformen, keine 40 Bytes zu 1+7 Bits! Ein Schwarzweissmonitor zeigt sie direkt als 280 Pixel 1bpp an. Erst ein Farbmonitor "verschmiert" sie zu 140 pseudo-Pixel für 140 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.

Damit sind aber 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 grauen Ü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. Genauer kann sie 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 Systemsoftware, sowie Power-On Reset Logik, und ein paar anderen kleinen 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. Ebenso gab es im Apple II J-Plus passende japanische Katakana Schriftzeichen. (Wegen der inkompatibel erweiterten Systemsoftware gab es zudem die "ROM Card", welche alte und neue umschalten erlaubte.) (Wegen UCSD Pascal aber auch die "Language Card" mit weiteren 1*16k RAM als ROM Ersatz, welche beliebige Systemsoftware von Disk laden erlaubte. Diese wurde aber sehr bald auch für grössere Usersoftware genutzt, mit bei Systemaufruf ROM reaktivieren.))

(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. Weiter kann man nun auf vertikalen Rücklauf testen, um synchron mit der Bildausgabe zu zeichnen, um Flackereffekte bei Animation zu vermeiden. Speicher ist nun 64k, die bisherigen max 3*16k plus weitere 1*16k der "Language Card". Am wichtigsten ist aber der neue Text 80x24 Modus. Dieser braucht neben den 64k DRAM noch +1k SRAM Speichererweiterung "80-column". Video ausgelesen werden Speicher und Erweiterung gleichzeitig, womit dies strike 8+8=16bit Video ist! Damit kann weiterhin ein 2MHz Speicher mit je 1MHz Prozessor und 1MHz Video laufen, erst der Font läuft mit 2MHz. Es sind aber bereits die ganzen 64k Adressen im Gebrauch. Daher erscheinen beide 1k "Main" und 1k "Aux" im selbigen 1k Adressraum 0400..07FF, mit dem Bildseiten Umschaltbit nun als Speicher Umschalter, für welche der 2*1k aktuell im Prozessorzugriff sind. Was als Banking bezeichnet wird. Das ist noch nichtlinearer, mit alle Zeichen 0,2,4,..,78 im "Aux" 1k, sowie 1,3,5,..,79 im "Main" 1k Speicher. Dazu kam ab Revision B noch "Double Hi-Res" Bitmap 560x192 1bpp bzw 140x192 pseudo-4bpp in 15 Farben wegen vollem 14.31818MHz Pixeltakt. Dieses braucht aber statt den +1k SRAM eine +64k DRAM Speichererweiterung "extended 80-column". Hier sind ebenso beide 8k "Main" und 8k "Aux" im selbigen 8k Adressenraum, wieder mit dem Bildseiten Umschaltbit für 2*8k. Das "Double Hi-Res" wird so nochmals schlimmer, weil jetzt 40x25 nichtlinear, plus 280x192 verachtfachen, plus doppel Speicher, plus darin nun 7 Pixel a bis g sogar in 4 Bytes als Bits aux:0bbbaaaa main:0ddccccb aux:0feeeedd main:0ggggfff (ohne verzögern Farbattribut Bit7). Aber dafür hat es alle 15 Farben weil mit 4bpp volle "Viertelwellen" Muster (daher auch kein verzögern mehr nötig, nur 7bit genutzt). Auch das ist strikte nur ein Signal, bei Schwarzweiss 560 Pixel, bei Farbe "verwischt" zu 140 pseudo-Pixel in 560er Raster. (Weitere Umschaltbits erlauben, das ganze 64k "Aux" für erweiterten nicht-Video Speicher zu nutzen. Zwei Umschaltbits schalten separat für Schreib- bzw Lesezugriffe die bisherigen 48k (aber minus deren ersten 512bytes). Geschrieben wird einfach mit ersterem, auslesen mit zweiterem verlangt aber zuerst Programteile dazu mit ersterem in das "Aux" kopieren! Ein drittes Umschaltbit gilt egal ob schreiben oder lesen für diese 512bytes, plus die oberen 16k falls diese mit der "Language Card" Logik durch RAM ersetzt sind.))

(Die Variante Apple IIc (1984) ist ein kompakter IIe, mit stets 128k, keine Slots, sowie eine eingebaute Disk. Hat selbiges Video.)

(Der Apple IIgs (1986) ist ein massiv erweiterter und schnellerer IIe, mit 2*14.31818/10=2.863636MHz in 128k "fast" RAM (erweiterbar bis 8M), plus IIe kompatible 2*14.31818/28=1.0227MHz in 2*64k "slow" RAM (mit Bild stets aus diesem ausgegeben). Kann neben IIe Modi auch noch 640200@2bpp oder 320200@4bpp, mit 4 bzw 16 Farben aus 4096. Dies nun mit linearen Videoadressen und nur eine Bildseite. Sehr nett ist, dass man sogar 16 Sätze zu je 16 Farben definieren kann, und pro Zeile mit einem Steuerbyte einen Satz aktivieren (Bit0..3). Weiter kann man pro Zeile einstellen, ob Farbe 0 = von letztes Pixel zu übernehmen ist (Bit5), sowie ob Zeileninterrupt auslösen (Bit6), sowie 320 oder 640 Pixel Modus (Bit7). Dazu kommt noch, dass man bei 640x200 die 16 Farben als 4 Subsätze zu je 4 definieren kann, mit diese alle 4 Spalten abwechselnd genutzt um mehr Farben zu rastern. Die weit mehr als 64k Speicher sind ohne Umschaltbits ansteuerbar, dank einem erweiterten 8/16bit Prozessor 65816, der mit neuen Adressmodi direkt 24bit Adressen erzeugen kann.)

(Der zuerst vorgesehene Nachfahre Apple III (1980) konnte eigentlich mehr als der IIe, mit stets vollem 8+8=16bit Speicher (wie bei "extended 80-column"). Video ist erweitert, wie bei "80-column" plus "Double". Es braucht aber kein 2 Speicher Umschaltbit, weil mit einem Adressbit auf die beiden 8bit Speicher verteilt wird (je nach wo im Adressraum, 0000..1FFF und A000..FFFF mit A11 in 2k Schritten, oder 2000..9FFF mit A13 in 8k). Zellmodus 40x25 wie in II, dazu 4+4bit Vordergrund und Hintergrund Farbattribute pro Zelle (aus der zweiten Bildseite ihre 1k Adressen, die im zweiten 8bit Speicher liegen), sowie 80x25 ohne Farben (mit 0,2,4,..,78 in der ersten Bildseite, 1,3,5,..,79 in der zweiten, also revers zu obigem "80-column"!). Daher sind keine 2 80x25 Text Bildseiten nutzbar, bzw das Umschaltbit reversiert nur die Anordnung der 2*1k (zu wie bei "80-column"). Mit 8x8 Font aus RAM Satz von 128+revers in separatem Fontspeicher, der aber mangels Adressen unsichtbar ist, durch einen langsamen Mechanismus geladen werden muss, der etwa 1s braucht! Keine Blockgraphik, weil Farbattribute mit 1x2 Blockgraphikzeichen in RAM Satz diese ersetzen, oder gar mit beliebigen Graphikzeichen weit verbessern. Bitmapmodus 280x192 wie im II, dazu auch obige Farbattribute (nun in 40x192 Segmenten statt 40x24 Zellen), sowie 560x192 1bpp welche zu 140x192 pseudo-4bpp werden (wie 80x25 verteilt auf Apple II Bildseiten). Hier sind aber mit 2*2*8=32k Speicher nutzen 2 "Double" Bildseiten nutzbar. Ein Teil von dies landete reduziert im IIe. Wegen derart Adressen auf die beiden 8bit Speicher verteilen sind nur 2*32=64k aufs mal sichtbar. Er hatte aber 96oder128k (mit "12V" 16k DRAM Platine), bzw 128oder256k (mit "5V" 64k DRAM Platine), und konnte sogar bis 512k (mit Dritthersteller 256k DRAM Platine). Diese konnte er aber dank einer ausgefeilten Adresserweiterung einfach nutzen. Für Programm und Variablen als 32k "System" fest (in 0000..1FFF und A000..FFFF) plus (n-1)*32k "User" gebankt (in 2000..9FFF). Für Daten mit "erweitertem Zero Page Indirekt" Adressmodus, bei dem der 16bit Speicher genutzt wird, um bei der Zieladresse neben dem zweiten Byte noch Modus und erweiterte Adresse zu holen.)

(Der III ist aber komplett gescheitert, weshalb der eigentlich weniger fähige IIe 3 Jahre später nachgeschoben wurde. Ursachen waren mehrere, die sich aufsummierten. Als erstes zu kleines Gehäse und davon Layout Fehldesign, mit Durchkontakte zu nahe zu Anschlüssen und davon schnell mal Lötbrücken. Dazu kamen Chip Montagerobotter Fehler, nur 2/3 Distanz eingesteckt, sie lockerten sich. Was beides in viele baldige Ausfälle resultierte. Ebenfalls von Platz RTC Oszillator Anordnung welche Signalstörungen ergab und davon Zeit zu schnell oder langsam, was unzuverlässig wirkte. Dazu kam noch übereilt auf dem Markt geworfen, aus panischer Angst, dass der II Plus in 6 Monaten zusammenbrechen wird. Daher ohne die wegen allem obigem problematische Hardware auskurieren oder die wegen Second System Syndrom sehr komplexe Systemsoftware fertigstellen, mit daher Hardware 1 und Software gar 3 Jahre lang beim Kunden reifen<. Dazu noch wegen Software unfertig knausrig sein mit der Dokumentation, was in wenige Programme resultierte. Bestehende Apple II Software lief nur in Emulation, die aber zu sehr inkompatibel zum II Plus war, vor allem weil keine 48+16=64k DRAM mit "Language Card" kompatibler Logik nutzbar (die Logik fehlt, das Apple II ROM Image wird bereits in dem RAM Bereich geladen), und Videomode Softswitches umdefiniert wurden. Was alles bei der Kundensorte welche einen $3500 Rechner kauft nicht akzeptabel war. Während der totgesagte II Plus die Firma 3 Jahre am Leben halten musste, dann der IIe nochmals 3 Jahre, dann der IIgs weitere 3 Jahre, bis der unterdimensionierte Macintosh endlich ausreichend ausgewachsen war! (Falsch sind Gerüchte zu Platinenhersteller der mehrere Leiterbahnen zwischen Chip Pins versprach, was zu Rissen in resultierenden dünnen Leitungen führte. Es hat keine solche mehreren Leiterbahnen. Auch falsch sind Gerüchte wegen zu heiss werden und Chips versagen wegen gedrängt und ohne Lüufter. Was aber nur zu schneller altern führen würde, nicht zu viele davon innert kurzer Zeit ausfallen, und ohnehin durch ganzes Gehäuse als Kühlkörper designen behoben wurde, was aber genau zu Platzmangel und deswegen Layout Fehldesign führte.))

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), und 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 1k 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 Videomonitor (eigentlich ein passend gestyleter RCA Schwarzweissfernseher ohne Tuner). Hat ebenfalls separates Kassettenlaufwerk (wieder passend gestylet). 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 eben als 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 ein 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). Optional gab es eine 640x240 Bitmap Erweiterung, sogar mit scrollbarem Auschnitt von einem 1024x256 Bild. (Es hatte zudem volles 64k RAM statt max 48k. Konnte dazu die ROMs abschalten, und somit auch CP/M fahren neben TRSDOS. Sowie weiter beschleunigt auf 4MHz, aber reduziert auf 2MHz im III Modus.))

(Die Seitenlinie Model II (1979) und Model 12 (1983) waren volle Bürogeräte und keine Homecomputer. Textmodi 40x24 und 80x24 (kein 32x16 oder 64x16). Mit 6x12 Font, wegen somit 480x288 Pixel auf eingebautem Spezialmonitor, aber mit separater 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, hatte nur 2k abschaltbares BootROM, was 64k RAM erlaubt, und somit auch CP/M fahren neben TRSDOS-II. Mit 4MHz statt 1.77MHz weit schneller. Das Model 12 erweiterte auf über 64k DRAM. (Obiges Model 4 somit hat praktisch die III und II zusammengeführt, abgesehen von den Floppys.))

(Die Model 16 (1982) und Model 16b waren auf selbiges Gehäuse wie II bzw 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 als Terminal mit Disks und allenfalls Ports für 2 weitere Terminals. Damit Video identisch mit Model II bzw Model 12. Model 6000 war ein schnelleres 68000 Board. Es war 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 plus 3 standard Portchips (2* 6520 PIA + 1* 6522 VIA), 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. Es fehlt 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. Dagegen kann man ganze Videodarstellung abschalten (was die Systemsoftware beim scrollen macht) oder mit vertikalen Rücklauf testen abwarten (was die Systemsoftware bei einzelne Zeichen ausgeben macht). Aber das verlangsamt zeichnen massiv und wird daher von Fremdsoftware (insbesondere Spielen) 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 neben vollem Zeichensatz mit Kleinbuchstaben und 32 Graphikelemente auch einen zweiten speziellen ohne Kleinbuchstaben für 64 statt 32 Graphikelemente. 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 Homecomputer. Er ist somit auch der ideologische Vorläufer vom Macintosh. (Commodore war von Anfang an ein Büroausrüstung Hersteller, der von Schreibmaschinen via Tischrechner und Taschenrechner, mit dazu Chips brauchen, zu die schwer kriselnde MOS Technology aufkaufen kam. Dabei haben sie auch 6502 Designer Chuck Peddle aufgenommen, der Jack Tramiel von seinem PET Konzept überzeugte.)

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 unbenutzte 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ählerchips spart) und die unteren 2 X Koordinate Bits nutzen (was den Adresszähler von 10 auf 8bit reduziert).

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 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 Graphikelemente 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. Das sogar direkt im Font, weshalb 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 komfortabel war.

(Die Nachfahren PET 2001-Nxx bzw CBM 30xx Serie (1979) sind leicht überarbeitet für mehr Speicher, mit 1* oder 2* 16k DRAM (je nach ob xx=16 oder xx=32) 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 statt "Chicklet" Tastatur eine echte Schreibmaschinen Tastatur (und diese auch in "Graphic" und "Business" Versionen), aber brauchen daher externes Kassettenlaufwerk. Ebenfalls besseres Basic 2.0, vor allem Bugfixes. Die älteren PET/CBM 40xx Serie (1980) haben selbigen Speicher und Video, sind nur mit verbessertem Basic 4.0, vor allem beschleunigt und mit komfortablen DOS Kommandos.)

(Die PET/CBM 80xx Serie (1980/81) und neuere PET/CBM 40xx (1981) haben einen MOS6545 CTRT Timing Chip (eine Variante des später beschriebenen MC6845), und einen grösseren 12" statt 9" Monitor (daran kann man frühe und neue 40xx auseinanderhalten). Die 80xx haben 80x25 Zeichen. Dazu haben sie 2*1k Bildspeicher B¨nke aus SRAM, welche parallel als 8+8=16bit gelesen werden (wie Apple IIe mit "80-column"), statt allen anderen ihren 40x25 aus 1*1k. Aber selbst dabei liegen alle Zeichen komfortabel linear im Speicher, weil ohne Umschaltbit mit Adressbit A0 zwischen den beiden SRAM B¨nken gewählt wird (analog Apple III), und dann A1..10 statt A0..A9 innerhalb der 1k SRAM Chips addressieren. Die neuen 40xx sind selbige MOS6545 basierte Schaltung, aber ohne die zweiten 1k und umschalten. Deren Universalplatine ist für 40xx oder 80xx konfigurierbar, mit A0 bzw A10 an die 1k und nichts oder A0 an den Umschalter. (Die 8096 addiert nur noch +4*16k von 32k auf 96k mit RAM als ROM Ersatz (analog Apple II "Language Card" +16k von 48k auf 64k, nur mehr davon, 2* 16k ROM ersetzbar und diese je mit 2* +16k RAM).))

(Deren Nachfahren PET-II (Bxxx sowie CBMxxx-80) bzw CBM-II (B6xx sowie B7xx) Serie (1982) haben 2oder4*64k DRAM (je nach xxx=128 oder xxx=256 bzw xx=10 oder xx=20). Sie verwenden 2k Bildspeicher aus einem einzelnen 2kx8 SRAM Chip, da dieser inzwischen 4MHz fähig ist, womit keine 8+8=16bit mehr nötig sind. Die Bxxx/B6xx haben nun separaten Monitor. Die CBMxxx-80/B7xx haben eingebauten drehbaren Spezialmonitor mit 350 Zeilen und Ersatz vom bisherigen 8x8 Font durch 8x14, sowie separierbare Tastatur (sie kann aber auch am Grundgerät festhaken). Die mehr als 64k Speicher sind ohne Umschaltbits ansteuerbar, dank einer im erweiterten 6509 Prozessor integrierten Adresserweiterung per Banking. Diese als volle 64k Indirektbank wenn LDA/STA mit (zp),Y Adressmodus benutzt wird, plus volle 64k Basisbank für alles andere, mit beide per 2* 4bit Register aus 16 Bänke = 1024k Speicher! Das erlaubt Progamme in Basisbank mit Indirektbank ausgelagerte Daten schreiben/lesen, sowie System in Basisbank mit Indirektbank ein Programm laden und Daten schreiben/lesen. Sprung von System zu Programm muss aber, wegen beide selbige Basisbank benutzen, mit Fortsetzung an gleicher Adresse erfolgen, wozu das System einen Proxy im Program seine Basisbank stellen muss. (Selbiges muss auch bei Apple IIe gemacht werden, wenn restliches "Aux" nutzen, mit per Schreibzugriff Proxy laden, erst danach kann Lesezugrff dorthin, weil sonst kein Programm mehr.) Sie waren wegen zu sehr inkompatibel zu den bestehenden PET/CBM ein Misserfolg. (Das parallel zu Apple III selbiges Problem.))

(Nach Misserfolg obiger Serie wurden die bestehenden CBM 8032 und 8096 moderner gestylet, durch ihre Schaltung in das neue CBMxxx-80/B7x0 Gehäse mit Monitor und separierbarer Tastatur stecken, als CBM 8032-SK bzw 8096-SK. Das SK steht für "Separate Keyboard". Die zuletzt erschienene CBM 8296 wurde auch technisch moderner, hat ebenfalls 2*64k DRAM, aber jetzt angeordnet als 32k PET und +6*16k von 32k auf 128k, somit 8096-kompatibel, aber nun mit je 3* 16k RAM. Zudem erstmals ohne separaten Bildspeicher, mit Bild aus dem ersten der 64k DRAM. Wie bei CBM-II ihren 2k SRAM ist Video nur noch 8bit breit, weil inzwischen sogar bei DRAM Chips 4MHz Zugriffe machbar geworden sind.)

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 aber nur max 8k Speicher nutzen kann) und 6532 RIOT (RAM 128Bytes + IO 2*8bit + Timer) und steckbares ModulROM (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 Joystick Feuerknöpfe. Aber Joystick Bewegungen und Moduschalter gehen an die 6532 RIOT. 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 einem separaten Bildspeicher im TIA Chip drin! Dieser besteht aus nur 40x1(!) 1bpp Pixel, aus ganzen 20 Bits(!) als (4+8+8=)20 in 3 Registern gespeichert, 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 ergeben würde, 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. Dieser Ansatz ist absolut einmalig.

Dazu Sprites, 2 Player 8x1 1bpp (8bit Register) in horizontal 160/80Pixel schaltbarem Raster und auch wiederholbar, sowie 2 Missile und 1 Ball nur 1x1(!) 1bpp (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 als Player Missile Graphics (PMG) bezeichnet 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 mit deren Missiles, sowie 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 horizontal streifigen Farben mancher VCS/2600 Spielobjekte 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 96 bzw 114 Doppelzeilen statt allen 192 bzw 228 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 ist reiner Konsum aber keine Kreativität, was für Konsolen typisch ist, im Gegensatz zu Homecomputer welche kreativ sein erlauben, was sie 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/Zellmodus (wie VDM-1/Sol-20 und PET/CBM). Text/Zell 64x30 Zeichen (fast doppelte VDM-1/Sol-20 und TRS-80). Mit 8x8 Font. Aus festen ROM Satz von 128 Zeichen mit vollem ASCII96 plus variablem RAM Satz von weiteren 128 Zeichen. Von letzteren 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 man mit 2D Elementen arbeitet und nicht mit 3D Vektoren. Man merkt hier, dass Exidy ein früher Spielautomaten Hersteller war.

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 an einem Rechner genutzt werden. Diese können sogar synchron laufen, mit n Karten dann n Bitplanes als n bpp, für 2^n Graustufen oder Farben. Das wird aber mit 16 4kx1 DRAM Chips pro Karte sehr teuer, weit oberhalb der 3'000$/DM/Fr/Eur Limite, genauso wie die in der Einleitung erwähnte Scion MicroAngelo, nur mit 1/4 so grosse Chips und kleinerer Anzahl Pixel!

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 und damit beliebig beschreibbar (wie Apple II). 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 im Bild 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 einem 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, Kinoprojektoren sind featurefest.) Dann wurde das Design als Homecomputer 800 recyclet und erweitert. Dazu kam ein Subset 400, mit 8k statt (1..3)*16k RAM, vor allem als Spielkonsole gedacht. Mit dann aber eine Folientastatur addiert, die Differenzierung aufgeweicht. Was sich trotzdem etwa doppelt so viel verkaufte wie der volle 800, dank etwa 60% vom Preis.

Basiert auf Drei Customchips: CTIA/GTIA (Color/Graphic Television Interface Adaptor) arbeitet wie VCS/2600 nur mit Bitmap und liest auch die Joystick Feuerknöpfe, sowie ANTIC (AlphaNumeric Television Interface Controller) holt Bilddaten per DMA aus dem normalen DRAM Hauptspeicher und wandelt dabei auch Textmodi zu Bitmap, sowie POKEY (POtentiometer KEYboard) liest Paddles und Tastatur mit auch Audio und UART. Joystick Bewegungen werden durch 1* 6520 PIA abgehandelt. Mit so alle zusammen als dreier Chipsatz die kleinere TIA im VCS/2600 ersetzend, und damit weit mehr leisten.

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 erzeugen zulassen will. Weshalb sie bei 320 Pixel nur eine Wellenform an "Chroma" mit zwei Signalstärken an "Luma" zulassen.

(Dieser Modus "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 wieder 4 "Halbwellen" Muster Farben (wie Apple II, die selbigen wie sein Sw+Bl+Or+Ws Farbsatz), nur mit wegen breiterem Bild des 800 sogar 160x192 pseudo-2bpp statt 140x192, und damit genau 4 pseudo-Pixel" pro Byte statt 7 pseudo-Pixel in 2 Bytes. Das alles versagt aber wieder auf einem PAL Farbmonitor, weil dieser dazu 17.734472/2=8.867MHz Pixel bräuchte. Es ist zudem sinnlos zu benutzen, da der Modus "E" 160x192 echt-2bpp in beliebigen 4von128 Farben erzeugen kann.)

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 bzw PMG, 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 Programm 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 horizontal 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 "Viertelwellen" Muster umgesetzt. Man beachte, dass die Videodaten beim 800 nur zwischen Farbregister schalten (wie Apple II "Low-Res"), nicht selber die NTSC Muster beinhalten (wie Apple II "Hi-Res"), 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 so viele Designer darauf bestanden, die Pixelrate genau auf die NTSC Farbwellenhälften auszurichten, mit dazu den Prozessor von seinen 1oder2MHz auf 7/8 Takt von 0.98oder1.79MHz gebremst, statt 14.31818/14oder7=1.0227oder2.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!

(Der Nachfahre 1200XL (1983) erwies sich vor allem wegen geänderter Systemsoftware als inkompatibel, die Kunden bleiben beim 800. Daher wurde er nach nur 4 Monaten abgesetzt und ein rein verbilligter und umgestyleter aber kompatibler 800XL (1983) nachgeschoben. Subtrahiert wurden bei beiden 2 der 4 Joystick Anschlüsse. Deren Bewegungsrichtung Portregister wurde neu zum Speicherkonfigurationsregister, mit 3 Umschaltbits. Wovon Bit0 Adressen C000..FFFF auf RAM statt System ROM stellt (weil nun 64k statt (1..3)*16k RAM, analog zu Apple IIe mit eingebauter "Language Card") und Bit1 A000..BFFF auf Basic ROM statt RAM (weil es kein Modul mehr ist) und Bit7 5000..57FF auf Selbsttest ROM statt RAM (weil von IO verdeckte 2k D000..D7FF vom 14aus16k SystemROM so genutzt wird). Dazu kam ein Subset 600XL, mit 16k statt 64k RAM.)

(Nach einem zweitem Firmenaufkauf durch Tramel Technology wurde der 600XL eingestellt und der 800XL noch passend zum von ihnen designten Atari ST umgestylet als 65XE (1985). Hat identisches Video. Dazu kam ein 130XE mit erweitertem Speicher auf 64+64k DRAM. Wieder je 64k "Main" und "Extra" (wie Apple IIe mit "extended 80-column", aber stets eingebaut wie Apple IIc). Aber statt mit Banking die ganzen +64k in "Extra" umzuschalten, hat es Paging um nur die 16k an Adressen 4000..7FFF von "Main" zu ersetzen. Obiges Speicherkonfigurationsregister wurde dazu erweitert, Bits2+3 als 2 Pagebits wählen welche von 4*16k "Extra" Pages aktiv sind, und Bit4+5 als 2 Umschaltbits ersetzen diese Page für Prozessor bzw Video. Dies ist weit einfacher zu programmieren, weil feiner steuerbar. Ist nutzbar als 48+n*16k (analog zu Apple III 32+(n-1)*32k), mit 48k System+Program+Daten in "Main" plus n*16k Program+Daten in "Extra". Für Program kann man feste Basis in "Main" und schaltbare Segmente in "Extra" benutzen, mit schaltende Einsprünge und Aussprung in "Main". Für Daten kann man "Extra" direkt nutzen, oder mit umkopieren in "Main" nur als RAMdisk, wobei aber direkt auf "Extra" Daten zugreifende Programmteile die 16k umschalten, also selber in "Main" liegen müssen. (Weiter kann mit Bastelei das "Extra" auf 2*(4*16k) anwachsen, mit weitere 64k an Chips Huckepack aufsetzen und unbenutztes Bit6 als weiteres Pagebit verwerten. Oder gar auf +1oder2*(16*16k), mit "Extra" durch 256k DRAM Chips ersetzen (allenfalls zweiten 256k Huckepack) und weitere 1oder2 bereits genutzte Bits zweckentfremden. Zumeist nimmt man zuerst das fast nutzlose XE Video Bit5 (mit stets 1 = in "Main") und dann das selten genutzte XL Selbsttest ROM Bit7 (mit stets 1 = kein Test), für maximal 64main+2*256extra=576k.) (Dazu kam noch die XEP80 (1986) Text 80x25 Zeichen Erweiterung, ohne Farben, sowie am einten Joystickport(!), nicht am SIO Bus oder ECI Erweiterungsport. Das ist zu wenig und zu langsam für Spiele. Also laufen diese nur auf unerweiterten 130XE, auf XEP80 hat es nur Büro.))

(Daneben 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. Dazu noch mechanisch fehldesignte Joysticks, mit Analog statt Digital Signalen und inkompatiblen Steckern. Daneben kam weiter noch eine erweiterte 2600 Konsole 7800 (1984), inkompatibel zu 800 und 5200! Diese wurde wegen dem zweiten Firmenaufkauf zuerst fallengelassen (1984) aber verspätet doch rausgelassen (1986). Aber fast parallel dazu kam eine 65XE 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 traf insbesondere auch dem Jaguar (1993), für den Atari den ST/TT/Falcon weiterentwickeln aufgab, und dann unterging nach dessen Versagen mangels Software. All das trotz diese Lektion schon beim selbigem Versagen vom Lynx (1989) nicht gelernt zu haben. Tod durch wiederholtem Kopfschuss per Management.)

(Obiges neues Management von Warner Brothers 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 benutzen kaufen und die Muster nur Dekoration sind, aber Spielmodule nicht wegen ROM Chips kaufen sondern nur wegen den Spielen darin! Das restliche Management hat diesen Fehler nicht bemerkt und korrigiert, trotz dass eine Filmfirma eigentlich wissen sollte, dass Leute auch Filme nicht wegen dem Filmstreifen anschauen, sondern nur wegen der Handlung darin. Und jeder weiss, dass Leute Bücher nicht wegen dem Papier kaufen, sondern wegen dem Text darauf. Aber dies wurde scheints nicht verstanden. Die Spieledesigner wollten daher zumindest wie Autoren und Graphiker behandelt werden, oder gar wie Regisseure und Schauspieler. Was ihnen bei Atari mit obiger Missachtung versagt blieb, weder namentliche Nennung noch prozentuale Beteiligung am massiven Gewinn. Dazu kam mit Buchhaltungstricks um Steuern zu sparen auch nebenbei die Ingenieure und Programmierer um versprochene Erfolgsboni betrügen. All das hat viele bedeutende Leute vertrieben. Was einerseits die wenigen verbliebenen massiv überlastete, und zu eigenen schlechtgemachten oder unausgereiften Spielen führte (Pac-Man bzw E.T.). Dazu kamen anderseits mehrere von Ehemaligen gegründeten Drittfirmen, welche wegen schnell Profit einnehmen müssen überhastete, aber wegen viele Konkurrenten trotzdem überhypete, Spiele produzierten. Nicht verwunderlich führte dies, zusammen mit den technischen Limiten der VCS/2600, zu einer Flut von Schrottspielen, gefolgt von Käufer Vertrauenskrise und Marktzusammenbruch, der den Nordamerikanischen Videogame Crash von 1983 auslöste. Addiert man noch Hardware billig verkaufen und erst an den Spielen Profit machen, und Atari verlor massiv bei den Konsolen. Dann kam in 1983 ein Preiskrieg zwischen Commodore und Texas Instruments, wo Atari wegen teuer zu produzierendem 800 nicht folgen konnte. Dazu kamen der verpatzte 1200XL und wegen Probleme bei der Fabrikation verzögerte Einführung des verbilligten 800XL. Womit auch die Computer Atari nicht retten konnten, sie ihre Marktstellung verloren. Schliesslich kam noch 1983 ein Insidertrading Skandal um obigen Manager, der kurz vor bekanntgeben der Verluste ein Teil seiner Aktien abstiess, wie später bekannt wurde nur wenige Prozent um Kapital freizubekommen, aber zu dem Zeitpunkt wurde Atari deswegen Überbrückungskapital bekommen versagt. Was alles zu obigem zweiten Firmenaufkauf durch Tramel Technology führte. (Der Atari Gründer Nolan Bushnell hat in einem Interview den Verkauf an Warner als grössten Fehler seines Lebens bezeichnet.))

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. Eigentlich 8x8 1bpp Daten aber mit jeweils Bit0+1 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, er ist dafür aber auch beliebig modifizierbar, alle 256 Zeichen. Wie Atari 800 Zell "2" nur 2 Farben fürs ganze Bild (aber volle 2, nicht "1.5" Farben). 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 (die 16te "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 Farbregister) 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 Vergleiche 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.

(Mit manchen Zellen ihre Farben auf Schwarzweiss gestellt, zusammen mit dem 7.1591MHz Pixeltakt, erzeugt auf einem NTSC Farbmonitor die 4 "Halbwellen" Muster Farben (wie Apple II und Atari 800 ihren Sw+Bl+Or+Ws Farbsatz), nur wegen schmalerem Bild des TMS9918 lediglich 128x192 pseudo-2bpp. Es ist immer noch besser als das ansonsten stets 1bpp. Das versagt aber wieder auf einem PAL Farbmonitor, weil dieser dazu 17.734472/2=8.867MHz Pixel bräuchte.)

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). Leider kann man nicht die 64 horizontal mit 96 oder gar 192 vertikal kombinieren.

Ab TMS9918A Bitmap "2" ("Graphic 2") 256x192 1bpp. Technisch 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 (bzw mit 1 Zeile hoch eher Farbsegmente). 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. 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. Wobei entweder alle 8x8 oder alle 16x16 sind ("Size" = 0 oder 1), sowie alle 256 Pixel mit Einzelzeilen oder alle 128 Pixel mit Doppelzeilen ("Magnification" = 0 oder 1), es hat dazu nur 2 global wirkende Flags. Jedes hat aber eine eigene Farbe. 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 sichtbaren 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 Zell/Block/Bitmap 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. Nur die Adressierung ist und bleibt problematisch.

(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 mehr nutzen, 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. Grob scrollen muss mit umkopieren gemacht werden, was aber mit einem internen Blockkopierer schnell gemacht werden kann. Beide zeigen erstpriorisierte 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.) (Hat jetzt volle 16k. Dazu noch 8k SRAM Hauptspeicher.) 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 sichtbaren pro Zeile von 64 angemeldeten. Ebenso hat es statt 15 NTSC Farben nun 32 RGB (16 für Zellen und 16 für Zellen oder 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. Die 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 seinem "32x16 angelehnten Videoformat für Fernseher. Weiter soll der MC6883/74LS783 zwecks Reduktion der Chipzahl zur Verbilligung des Prototyprechners entstanden sein. Nach anderen Aussagen hat Motorola den Chipsatz alleine 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 CoCo 2 ist vor allem eine mechanisch überarbeitete Version, mit echter Schreibmaschinen Tastatur statt einer "Chicklet" Tastatur.

Der Dragon ist dem CoCo sehr ähnlich (noch mehr dem CoCo 2), sogar mit identischer Tastaturanordung zum CoCo 2 (und auch identische gegenüber TRS-80, selbige Matrix, nur rotiert zu 8 Auswahl und 7 Lesen), sowie Stecker (aber die 7 Lesen Kante ihre Leitungen sind darauf vertauscht), fast identischem Erweiterungsport (Pin für fehlende -12V sind zweites 12V statt leer), kein 3-Draht bitbanging RS232 (aber Dragon 64 hat einen 6551 Chip) weil die 2 Portleitungen für den addierten Druckeranschluss umgenutzt wurden (CoCo hat keinen solchen), und fast identischem Basic (das CoCo Extended Basic, mit stets beiden 8k ROMs anwesend oder gar als ein 16k, aber inkompatible Tokennummern und Einsprungadressen).

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

Text 32x16 Zeichen (wie TRS-80). Mit 8x12 Font (fast wie TRS-80). Aus im Chip selber eingebautem festen ROM Satz, von ASCII64+revers Zeichen (wie TRS-80). Der vermutlich hässlichste Font aller Homecomputer. 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 9 NTSC Farben (8 Vordergrund Gn+Ge+Bl+Rt+Ws+Cy+Mg+Or und 1 Hintergrund Sw ), die 8 in Bit6..4, was 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 sehr 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 wieder 4 "Halbwellen" Muster Farben (wie Apple II und Atari 800, selbigen Sw+Bl+Or+Ws Farbsatz), nur wegen schmalerem Bild des MC6847 lediglich 128x192 pseudo-2bpp (Apple II 140x129, Atari 800 160x192). Im Gegensatz zum Atari 800 ist dieser Farbsatz besser als beide festen "C" echt-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), bekannt als Semigraphic24. 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 nur benutzt um bei Bitmap die 8 Modi 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. Dies kann mit einem externen Font ROM umgangen 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 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 bei dessen TIA auch Audio und Paddles im selbigen Chip drin. Stand damit als Standardchip in direkter Konkurrenz zur MC6847. Wie diesen mit Bild aus dem normalen SRAM oder DRAM Hauptspeicher, wenn auch im VC-20 von der Verdrahtung her limitiert auf das interne SRAM, kein Speicher von den Erweiterungsmodulen nutzbar.

Der VIC verkaufte sich aber nicht, trotz eigentlich weit besser zu sein. Vermutlich wegen seiner sehr niedrigen horizontalen Auflösung. Daher nur von Commodore verwendet, für den VC-20 (bzw VIC-20 im englischen Sprachraum, bzw davor schon VIC-1001 in Japan). Logik ist neben volle 6502 und VIC nur noch genau 2* 6522 VIA. Wegen einem Überschuss an 1kx4 SRAM Chips bei MOS wurde der VC-20 mit solchen gebaut, was wegen dem angezieltem $300 Billigrechner 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 zu können ohne den Prozessor NTSC 48% bzw PAL 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. Das ist die schlechteste Eigenschaft vom ganzen VIC Chip!

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 NTSC, sowie Bildrand ebenfalls eines der ersten 8), diese als Farbton+Helligkeit Kombinationen ohne separate Helligkeitsstufen (genauer sind sie beinahe-RGB, in Reihe Schwarz Weiss Rot Cyan Magenta Grün Blau Gelb, dann nur Hintergrund noch Hellbraun und Pastellbraun sowie Pastelle der Rot bis Gelb). Das erlaubt 256 Zeichen Font mit 8 Vordergrund Farben zu kombinieren.

Dazu kommt mit dem verbleibenden 1 der 4 extra Bits zeichenweise(!) die 1bpp/2bpp umschalten, mit bei 2bpp 3 statt 1 Hintergrundfarben (obiges Hintergrund und ein "Auxillary" von allen 16, und die Randfarbe von 8, das bei diesem fehlende Bit reversiert das ganze Bild). 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 vertikalen Rücklauf Interrupt und davo VIA Timerinterrupt setzen kompensierbar ist, wenn auch mit Aufwand. Kein Bitmap. Aber der 256 Zeichen RAM Font und nur 22x23=506 Zeichen Bild kann man dies teilweise kompensieren mit in Zellen rendern. Auch die 2bpp kompensieren es teilweise weiter, wenn auch auf Kosten von nur noch 22*4=88 statt 22*8=176 Pixel pro Zeile, von denen es wiederum 23*8=184 hat, wegen den 22x23 Zeichen statt 20x25. Strikte kann man sogar bei PAL bis auf 26x32 mit Overscan hinauf (NTSC wohl etwa 26x27). Kann zudem halbwegs fein scrollen, vertikal in Zeilenpaaren (also Viertelzeichen) und horizontal in Speicherzugriffszeiten (also Halbzeichen) Schritten.

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, wenn auch stark erweitert.

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, einfach machbar durch 1 der 5 kByte als separaten 1kx8bit Bildspeicher (wie PET/CBM) verwenden (bei 40x25=1000 Bytes wären ohnehin praktisch 1k Zeichencodes), und dann nur den Font via Systembus von ROM/HauptRAM holen, was auch bei 40 Zeichen in dessen 1von2MHz Bandbreite passen würde, und der VIC wäre ein sehr guter Chip gewesen. Noch besser wenn dank doppelter Pixelzahl kein gemischtes 1bpp/2bpp, und statt dessen volle 16 Farben pro Zelle. 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 mit 16k sogar mit font-artigem Bitmap Modus (wie TMS9918 "Graphic 2"), weil das wäre bereits fast ein spriteloser Commodore 64 gewesen!

(Die geringe horizontale Auflösung war der häufigste Grund um keinen VC-20 zu kaufen, der vermutlich Commodore die Verkaufsmenge halbiert hat! Trotzdem war dies der erste Computer der 1 Million Exemplare überschritt und sogar 2mio erreichte, wegen dem $300 Billigpreis. Mit 40 Zeichen und ohne halbe verlieren wären das 4mio gewesen. Mit 16k DRAM, und somit keine 3k plus 8k Erweiterungen notwendig nur um auf 16k zu kommen, was weitere etwa halb so viele als Grund hatten um keinen VC-20 zu kaufen, wären das sogar 5mio gewesen. Allerdings gibt es eine Aussage vom damaligen Marketingleiter und VC-20 Projektleiter, dass dieser nur als Hinhaltetaktik gedacht war, um die Japaner mit Reaktionsfindung 1 Jahr zu blockieren, bis etwas besseres fertiggestellt werden konnte. Was dann der Commodore 64 wurde.

(Es gab 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 40x25 Zeichen und 16k DRAM gedacht war (oder aber nach manchen Angaben für einen farbigen PET). Dies ohne separatem 1k Bildspeicher, wegen in unveränderter Schaltung laufend (vermutlich mit einem eine Zeile langen Schieberegister Buffer (wie Atari 800 im ANTIC)). War sogar als Aufrüstsatz aus Austausch VIC-1.5 + SystemROM für den VC-20 vorgesehen! Hätte die doppelten 40x25 gehabt, sowie den VIC Farbsatz. Vermutlich aber ohne Bitmap und sicher ohne Sprites. Er wurde deswegen abgeschossen, wegen schwächer als dem VIC-II, mit statt dessen den auf letzterem basierten Commodore 64 herausgebracht.)

Sinclair ZX80 (1980)

Absoluter Minimalstrechner, mit dem Ziel designt, billigst möglicher Rechner zu sein, anfangs £100 (Bausatz £80) (und Steckernetzteil +£9). 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. (Im Vergleich zu den 17 TTLs haben Apple II und Tandy TRS-80 etwa 55 TTLs, und PET 2001 40 TTLs + 2 PIA + 1 VIA.)

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 schwarzweiss. Dazu passend nur Folientastatur mit lediglich 40 Tasten. Trotz geringer Anzahl Tasten mit einzelnen Graphikzeichen drauf, wie PET/CBM, mit Shift benutzt. Weil die untersten 2 Zeilen für System reserviert sind, hat die Blockgraphik noch 32x22 * 2x2 = 64x44. Ebenso Gehäuse kein Kunststoff Spritzguss, sondern nur Plastik Tiefzug wie bei einem Joghurtbecher, daher sind 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 Signal aktiv) und 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 00=NOP Befehl vorgaukeln (alle Programme/Daten von RAM und ROM kommen durch 1k Widerstände zum Prozessor, der NOP Generator besteht aus direkt mit diesem verbundene OC Inverter, welche aktiviert hart nach 0 ziehen aber sonst nur loslassen.) Bytes mit Bit6=1 (64..127 und 192..255) werden aber vom Videogenerator ausgelassen (werden als Leerzeichen ausgegeben), und ohne den NOP Generator zu aktivieren an den Prozessor durchgelassen.

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 Refreshsignal in der zweiten Hälfte von jedem M1 Zyklus ausgenutzt! Dabei wird neben R Register auf A0..7 auch der Inhalt vom I Register auf A9..15 ausgegeben. Es werden hier aber A3..8 vom gelesenen Zeichencode Bit0..5 und A0..2 vom Videozeile in Zeichenzeile Zähler her eingefügt, womit das eigentliche R komplett ignoriert wird, nur I ist relevant um den Font zu finden (es wird auf Hex 0E gesetzt, wegen Font in 0E00..0FFF). Daher ist auch kein RAM Font möglich, weil diese Einfügelogik nur auf 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.

Um Platz im nur 1k grossen SRAM Speicher zu sparen werden Zeilen ohne rechts verbleibende Leerzeichen gespeichert und 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 oben aus dem Bildspeicher wegkürzt, trotz noch Bildschirmzeilen Platz frei haben! Weshalb auch die Kommandozeile sich stets auf der unteren Zeile befindet. Ist der (erweiterte) Speicher mehr als 3.25k, werden alle Zeilen aber 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 zu brauchen, 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 mehr HALT Zustand hat und wieder M1 Zykluse macht, aber die Interruptroutine wieder aus dem ROM an 0000..0FFF liest, womit ohne A15=1 auch nichts mehr ausgegeben wird und der Prozessor alles bekommt, egal was für Datenbytes. Dabei wird auch noch nebenbei die Bildsynchronisation vom Prozessor erzeugt, mit den Horizontalpulsgenerator durch das Z80 Interrupt bestätigen Signal anstossen. Die Videozeile in Zeichenzeile wird in externer Hardware 0..7 gezählt, welche von obigem Horizontalpuls +1 geht, und vom Software generierten Vertikalpuls auf 0 synchronisiert wird. Der Vertikalpuls wird vom Tastatur lesen nebenbei gestartet und explizit mit beliebiger Ausgabe beendet. 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 jedem Taskendruck zuckt, weil der Fernseher zuerst wieder neu synchronisieren muss.

Eigentlich 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 würden sogar 40x25 drin liegen. Zumal das Problem mit 40 Zeichen pro Zeile keine 2^n sein hier irrelevant ist, weil die Zeichencodes als Programm mit dem Programmzähler lesen praktisch auf einen separaten Adresszähler wie in der 6845 hinausläuft! Und mit den variabel langen Zeilen 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 ungeplanten und daher 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 serzen), und dann Zeilenrücklauf abwarten, dann ab I und R neu setzen, wiederholt. All das ohne Halt, weil ohne Interrupt eingeschaltet, weil ohne R als Timer. 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 (bis zu 5 Module zu je 1..3 Paare 1kx4 SRAMs) machen dabei zumeist nicht mit, ausser man modifiziert sie (nur 2 Dioden und 1 Widerstand addieren), damit sie auch bei Refreshzyklus einen Lesezyklus machen. (Dies wäre aber mit Quarz auf 8MHz inkompatibel, weil R nur Bits0..6 zählen kann, was auf 128er Gruppen limitiert. Ausser man legt die 192 Zeilen als 64* (3*40=120 + 8) unbenutzte in die 128er ab. Am besten weil /64 einfacher ist als /3 zuerst alle 64 erstem dann 64 mittleren dann 64 letzte.)

(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. Speichererweiterung is nun 1 Modul zu 16k DRAM, welches die internen 1k abschalten muss. 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 erweitertem 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 Programm rechnen, Video Bild ausgeben, Programm 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 sind in den 54+56 Zeilen 58 Takte NMI sowie 149 Takte rechnen, von insgesammt 207 Takten. Das 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.

Dabei 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äter 80x24 Ausschnitt 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 Banking (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. Läuft so in IBM PC (1981) und PC/XT (1983) und PC/AT (1984). Wegen Karte mit separatem 2+2=4k Bildspeicher aus SRAM, aufgeteit in je 2k Zeichenspeicher und Attributspeicher, daher auch asynchron und nicht Prozessor bremsend (wie TMS9918). 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 auch 2x1) Blockgraphik aber trotz 256 Zeichen keine 2x2 (es gibt also doch nur maximal 80x50 (bzw 160x25) Blöcke).

Aber mit 8bit Attributen, als (1+3)+(1+3)bit, mit Hintergrund (Bits 7..4) und Vordergrund (Bits 3..0) je 3 Graustufen (Werte 0,7,15 für Schwarz Normal und Intensiv) was "1.5bpp" ergibt. Manche Monitore erlauben noch 8 als vierte Graustufe, was volle 2bpp ergibt. Hintergrund Bit7 ist 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 sogar 8+8=16bit Video, aus eigentlich 2k 16bit Worten an SRAM!

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

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.

(Erweiterte graphische Alternative zu der MDA ist die Hercules Graphics Card HGC (1982), manchmal auch als Monochrome Graphics Adapter MGA bezeichnet. Sie hat den selbigen Textmodus 80x25 mit 9x14 1bpp ROM Font, und benutzt daher auch dessen Spezialmonitor 720x350. Scheidet damit auch strikte hier aus, wird aber als erweiterte MDA gerade noch der Vollständigkeit wegen durchgelassen. Kann neben dessen Textmodus auch einen Bitmapmodus mit hoher Auflösung. Wegen Karte mit separatem 32k Bildspeicher (strikte sind es sogar 64k, als 2 32k Bildseiten) aus DRAM (wie TMS9918), daher auch asynchron und nicht Prozessor bremsend. Aber mit Adressen vom Prozessor, auch dessen Adressmodi ausnutzend (wie MDA (und auch 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. 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! Dies mit den zwei Videozeile in Zeichenzeile Bits A13+A14 vorne an die resultierende 87*80=6960 = 8k ihren 13bit Adressen zusammengelegt, und somit die 32k als (0..86)*80+(0bis3)*8k genutzt.)

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 dazu normalen NTSC Videomonitor oder digitalem IRGB 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 (einiges mehr TTL als MDA), keine Customchips, daher ebenfalls primitiv. Kann wegen 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 deren 5MHz auf 14.31818/3=4.77273MHz reduziert wurde, nur um einen Quarz zu sparen, der erst noch bei MDA nicht mal eingespart wird! Hat trotz 256 Zeichen aber nur horizontal 1x2 oder vertikal 2x1 Blockgraphik aber kein volles 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. Signal wird digital an Monitor geschickt, erst dort zu analog und Farben. Manche Monitore erkennen intensiv Schwarz als Dunkelgrau, was 16 statt normal 15 Farben ergibt. Hintergrund Bit7 ist umschaltbar zu nur 8 RGB (0..7) plus blinkend statt intensiv. Kein Unterstreichen. Ein einzelnes Register liefert in Bit3..0 die IRGB Randfarbe. Ist damit wieder 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. Dagegen kann man auf Rücklauf testen (wie PET/CBM), sogar auf horizontal und vertikal, aber das verlangsamt ebenfalls zeichnen (wenn auch dank horizontal nutzen weit weniger als PET/CBM) und wird daher von Software oft nicht gemacht, aber war bei mancher wenigstens als Option einstellbar.

Bitmap 320x200 2bpp in 1*IRGB-Register plus festen-3er-satz. Braucht die ganzen 16k Bildspeicher an Bitmap, und hat daher keine Farbattribute mehr (aber auch ohne diese zu lesen kein "Snow" mehr). Somit nur feste Farbsätze, mit den 2bpp direkt an Rot und Grün, aber 3 Varianten für Blau, mit bei Pixel=01+10+11 entweder B=0 mit RG ergibt Gn+Rt+Ge oder B=1 mit RG ergibt Cy+Vt+Ws oder (B=G) mit RG ergibt Cy+Rt+Ws. Obiges einzelnes Register liefert hier neben IRGB Randfarbe auch für Pixel=00 den Hintergrund(!). Das ist aber sehr limitierend, weil ohne 00=Schwarz gesetzt man kein solches in allen drei Sätzen hat! Und die Randfarbe will man ohnehin zumeist Schwarz haben. Weiter liefert dieses Register ein weiteres Bit f¨r on Pixel=01+10+11 Intensiv addiert wird. Am ehesten war der Gn+Rt+Ge Satz mit Hintergrund=Blau nutzbar, was dann genau dem MC6847 "C" Bitmap mit Gn+Ge+Bl+Rt Satz entspricht, nur mit besserem Blau statt Grün Rand, sowie 320x200 statt 128x192 Pixel. Also keine echte Farbauswahl.

Zudem liegen die Bitmapzeilen nichtlinear im 16k Bildspeicher, weil die MC6845 nur bis 128 (Zeichen-)Zeilen zählen kann. Also werden die 200 (Video-)Zeilen als 100 (Zeichen-)Zeilen 0,2,4,..198 zu je 2 Videozeilen pro Zeichenzeile angeordnet! Dies mit dem Videozeile in Zeichenzeile Bit als A13 vorne an die resultierende 100*80=8000 = 8k ihren 13bit Adressen zusammengelegt, und somit die 16k 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. Obiges einzelnes Register liefert hier wenigstens Pixel=1 Vordergrund, mit Hintergrund und Randfarbe stets Schwarz, was weit besser ist. Wobei dieser Mode 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 als 640x200 statt max 128x128.)

(Strikte hat 640x200 auf einem NTSC Farbmonitor wegen 14.31818MHz Timing die 15 "Viertelwellen" Muster Farben wie Apple IIe "Double Hi-Res", nur mit wegen breiterem Bild der CGA sogar 160x200 pseudo-4bpp statt 140x192, und damit genau 2 pseudo-Pixel pro Byte statt 7 pseudo-Pixel auf 4 Bytes verteilt. Aber dies ist mit dem üblicherweise verwendeten digitalen IRGB Monitor nicht benutzbar.)

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 aushelfen (wie Microtan 65) noch mit Font aus SRAM (wie Sorcerer), weil nur selbiges ROM mit 1x2 und 2x1 wie in der MDA. Egal was man hier versucht, es fehlt stets genau das was gute Spiele erlaubt!

(Ausser man nimmt Text 80x25, stellt dann den MC6845 um auf 80x100(!) Zeichen, zusammen mit passendem flachen 8x2 1bpp "Font". Dann wird der Zeichenspeicher (jedes erste von zwei Bytes, 8von16k) fest mit dem ROM 2x1 Blockgraphik Zeichen 222 (links aus und rechts ein) gefüllt, was statt dessen 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 auf die resultierenden zwei 4x2 grossen Block-Pixel verteilend (wie Apple II Blockgraphik ihre 2*4bit, aber hier neben einander statt über einander). Dieses ergibt absolut brauchbare 160x100@4bpp mit den vollen 16 Farben! Bonuspunkte, wenn man auch noch beliebige andere Zeichen ihre oberen 2 Zeilen als feinere 640x200 Musterung nutzen kann. Das wird als "Tweak Mode" bezeichnet. Nur war dies vielen Programmierern damals kompett 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 zudem nicht mal eine Anleitung wie man es macht, nur eine Aussage "requires special programming", mit dabei erst noch fälschlich behauptet, dass es "set up as the 40 by 25 alphanumeric mode" ist, statt "80 by 25". Auf der Basis vom 40x25 Modus würde mit 40x200 Zeichen und 8x1 1bpp Streifen-Pixel ein weit weniger nützliches 80x200 entstehen.)

(Der IBM PCjr (1983) verwendet selbigen MC6845, aber mit einem Datenpfad Gate Array Semicustomchip. Er addiert den bei CGA fehlenden naheliegenden 160x200@4bpp Modus, mit doppelter Menge der "Tweak Mode" Pixel, weil als volles 16k Bitmap formatiert. Mit Bild aus dem normalen DRAM Hauptspeicher, bzw eigentlich dem erweiterten CGA Bildspeicher von 64k statt 16k, mit 48k von diesem als Hauptspeicher verbleibend! Weiter gibt es noch verdoppelte 32k Modi 320x200@4bpp und 640x200@2bpp, sofern wegen Bandbreite den Speicher +64k auf 16bit erweitert, mit so 2*64k vorhanden, davon 96k als Hauptspeicher. Weitere +128k Hauptspeicher konnten per Erweiterungsport an der Seite addiert werden. Mit 2 oder 4 oder 16 von 16 RGBI Farben. Eigentlich das beste Video bisher! Zudem addierten sie für Audio einen SN76496 Soundchip. Das alles in einem kompakten und relativ billigen 8088 Home-PC Subset. Das hätte ein grosser Erfolg werden können, oder gar sollen. Nur war der Rechner zwar besser als 8bit Rechner, wenn auch teurer, und billiger als PCs, aber nicht genug kompatibel. Video war zwar zur CGA bitmapkompatibel, aber die Modusumschaltung doch nicht registerkompatibel. Die Tastatur mit "Chicklet" Tasten (damit Schablonen dazwischen passen) war tippfeindlich, und deren Infrarot Kabellosverbindung (damit frei im Raum bewegbar) war unzuverlässig und batteriefressend, und damit genau für einen Home-PC untauglich. Ebenso wurde sie empfangen per NMI Interrupt gefolgt von Bitbanging, was IRQ 4.8ms ausblockte, und somit mehr als 1200baud RS232 Empfang und gleichzeitig tippen unmöglich machte. Weiter gab es erst mit dem +128k Hauptspeicher einen DMA Chip, mit welchen RS232 Download und gleichzeitig Floppy schreiben erst möglich wurde. Zudem hatte er wegen billig oder wegem Platz keine standard Portstecker, was mit Spezialkabel oder Adapter teurer wurde. Mit all dies wurde der PCjr ein massiver Flop.)

(Tandy hat als Nachfolger der TRS-80 Serie und MC6847 Color Computer auf IBM kompatiblen Home-PC 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 sinnvollerweise verschwiegen, dass sie dazu kompatibel sind, den Rechner nur als MS-DOS kompatibel vermarktet, und die Kritik an nicht volles aber impliziertes PC kompatibel sein weggesteckt. Hatte mit PC Game Adapter softwareseitig kompatible Anschlüusse, welche aber hardwareseitig Tandy ihre bestehenden Color Computer Joysticks aufnahmen. Wegen billig und ordentlich wurde dieser prompt zum erwarteten Erfolg, bewies das PCjr Konzept als richtig, mit nur dessen Implementation massiv verbockt. Wonach die erweiterten PCjr Videomodi sogar als Tandy Graphics Adapter TGA bekannt wurden (bzw teils auch als Tandy Color Graphics Adapter TCGA)!)

(Andere haben bereits davor CGA Klone erweitert auf doppelte 32k. Bekannt wurde die noch in 2 Platinen voller TTLs gebaute Plantronics ColorPlus (1982), mit verdoppelte 32k Modi 320x200@4bpp und 640x200@2bpp (aber ohne 160x200@4bpp Modus). Mit Customchips kam die Paradise PVC-4 mit ColorPlus Modi. Maximal war mit Customchips die ATI Graphics Solution, welche MDA und sowie CGA und ColorPlus Modi konnte, und wegen den für HGC notwendigen 64k auch vervierfachte CGA mit 640x200@4bpp, und sogar alle Modi auf beiden MDA und CGA Monitor Typen mit Signalkonversion bei Ausgabe! Deren /G Version liess der CGA ihren NTSC Ausgang fallen, zugunsten von einem eingebauten Game Adapter. Aber echte PC Gamer wollten ohnehin eine Soundkarte, welche zumeist auch gleich den Game Adapter mitlieferte. (IBM selber hätte, parallel zum PC von "Type 1" mit 4* 8*16kx1 = max 64k DRAM auf "Type 2" mit 4* 8*64kx1 = max 256k upgraden, auch die CGA von 1* 8*16kx1 = 16k auf 2* 2*16kx4 = 32k erweitern können, sogar mit dabei auch auf 8+8=16bit verbreitern und so Textmodus "Snow" eliminieren, hat dies aber verpennt.))

Acorn BBC Micro (1981)

Nachfolger des Acorn Atom von 1980 (mit MC6847). Anfangs als Acorn Proton bezeichnet (ein kleineres späteres System hiess 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. In allen Bitmap Modi geht dies nicht mehr (wie CGA). Hier werden die 256 oder 200von250 Zeilen aber als 32 bzw 25 (Zeichen-)Zeilen zu je 8 Videozeilen angeordnet, statt 100 zu je 2 (wie CGA). Aber mit den Videozeile in Zeichenzeile Bits hinten als A0..2 zusammengelegt, womit die 8 Bytes einer Zeichenposition direkt hinter einander im Speicher liegen (wie TMS9918 "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(!) analog 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 analog RGB Monitor (inklusive SCART Fernseher). Weil keine Rücksicht auf NTSC oder PAL, geht er mit geraden 2MHz auf den Prozessor los.

Keine Textmodi (ausser Teletext), 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.25 oder 8k, statt "volle" Modi 0..3 mit 20.5 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%, und diese erst noch in der ULA drin). Genau dieses kleine Mehr macht den Unterschied aus, von der CGA schrottig zum BBC anständig und modern!

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 VC-20 und mit 64k DRAM verkauft. Hat 2 Umschaltbits, welche A000..BFFF und D000..DFFF und E000..FFFF auf RAM statt ROM oder IO stellen (analog zu Apple IIe eingebaute "Language Card" und Atari 800XL addierte Umschaltbits), sowie 1 Umschaltbit welches D000..DFFF auf FontROM statt IO stellt. (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 40xx/80xx Gehäsuse). (Die Max-Machine ihre nur-NTSC MOS6566 benutzt hingegen aus dessen SRAM, der P500 Prototyp hatte auch dies 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. 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. Logik ist neben 6510 (Variante der 6502 mit 6bit Port auf dem Chip) und VIC-II und SID nur noch genau 2* 6526 CIA und wenige TTLs.

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 wiederholen (wie Atari 800). Dies kostet dem Prozessor bei 40/65 Zeichen * 200/(262bzw312) Zeilen = 48bzw40% Ausgabezeit nur noch *1/8 = 6bzw5% an Leistung. Diese Anhalter sind hier als die 1/8 * 200 = 25 "Bad Lines" bekannt.

Dies mit schaltbar reinem 8x8 1bpp Modus mit 16 Farben, oder gemischtem 8x8 1bpp 4x8 2bpp "Multicolor" Font mit 8 Farben (wie VIC), leider aber keinem reinen 4x8 2bpp mit 16 Farben. 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, diesmal 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). Daher ist der interne Buffer sogar 40*(8+4)bit. Das erlaubt wieder 256 Font mit vollen 16 (bei reinem 1bpp Modus) bzw noch 8 (bei gemischtem 1bpp und 2bpp Modus, zeichenweise geschaltet, wie VIC) Vordergrund Farben zu kombinieren. 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 mit 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", beide stets volle 16 Farben. Technisch sind dies nur 1000 von 1024 Zeichen von 4 linear durchlaufenen 256er Fonts (analog TMS9918 "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 (genau 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/weniger NTSC Farbmonitor 4 Farben Effekte, weil diesem Pixeltakt seine /2= etwa 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 (wie Atari 800) und deren 2MHz Wellen. Weshalb man sich erst recht ernsthaft fragt, warum so viele andere Designer so sehr bereit waren, mit auf 7/8 Prozessortakt bremsen 1/8 Leitung zu opfern!

(Vielleicht weil andere bei NTSC den billigen 14.31818/16=0.895MHz Divisor im PLL Oszillator nutzen wollten, aber bei PAL ohnehin einem aufwendigeren 17.734472/20=0.8867MHz brauchten. Während C64 bei PAL den identisch kostenden 17.734472/18=0.985MHz benutzt, und bei NTSC konsistent selbigen auf 14.31818/14=1.0227MHz stellt (was der Apple II auch schon hatte) (der VC-20 reversiert dies sogar, mit NTSC 14.31818/14=1.0227MHz und PAL das billigere 17.734472/16=1.1084MHz). Oder weil andere 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 versagen wird. Der C64 (und die VC-20) zeigt, dass das Bild dadurch nicht schlechter wurde. Wobei dem C64 seine für das *8 erzeugen benutzte PLL Logik den Nebeneffekt hat, dass eine 14 bzw 18 Wellenviertel Folge sich genau mit einer 8 Pixel Folge deckt, und damit mit allen Farbattribut Wechseln, was vielleicht ein besseres Bild ergibt.)

Das einzige was hier aber komplett fehlt ist Overscan. Vermutlich weil das nur 1k an Farbspeicher mit 40x25=1000 bereits voll ist, es keine dabei zu erwartenden 48x30=1440 oder gar 52x32=1664 an Zeichen abdecken kann. Es hat nun aber volles fein scrollen horiontal und vertikal, wenn auch 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).

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 reserviert oder für Displayliste verbraucht wird.

Farben mit Register auswählbar aus 16 festen NTSC Farbton+Helligkeit Kombinationen, mit leicht andere Farben als beim VIC, selbige erste 8 Schwarz Weiss Rot Cyan Magenta Grün Blau Gelb, dann Hellbraun aber mit Dunkelbraun statt Pastellbraun, sowie die Pastelle von Rot * * Grün Blau *, aber dann die * als Graustufen 25%/50%/75% statt Pastell Cyan/Magenta/Gelb. Hat 1 Register für Bildrand (alle 4 Bits), 4 für Bild/Spielfeld Vordergrund und Hintergrund (und damit mehr als nur 1 Hintergrund + 1 "Auxillary"), 8 für 1bpp Sprites, 2 geteilte für 2bpp Sprites, zusammen 15, plus den Farbspeicher für jedes Zeichen. Besser als alle anderen Rechner ihre Farben bisher!

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. Dies inklusive der Randfarbe vom Overscanbereich umschalten, um Hintergrundfarbe Bänder bis in den Rand hinauszuziehen, oder fein scrollen selektiv einschalten um nur Bänder zu scrollen. Kann keine Zeilen zusammensammeln, also muss grob scrollen per umkopieren geschehen. Kann ebenso 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, was dann den vielen grossen Sprites zugute kam.

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 4bit Port addiert (wie 6bit von 6502 zu 6510 Prozessor), sowie dem 1zu2MHz Modusschalter. Ein doppelter VIC-III war nicht mehr machbar, weil VIC/VIC-II und SID Entwickler die Firma verlassen hatten. Statt dessen einen VDC Chip (MOS8563) addiert, eigentlich entwickelt als Terminalchip für den 16bit nur-Büro nicht-Spiele Multiuserrechner Commodore 900, der bereits fertig zum Verkauf war, als er zugunsten vom Amiga abgeschossen wurde. Benutzt wie TMS9918 separaten Bildspeicher von 16k, daher auch asynchron und nicht Prozessor bremsend, wichtig bei einem Multiuserrechner. Wie dieser mangels Pins keine Adressierung vom Prozessor, braucht eigene Adressregister, aber verhindert Prozessor Adressmodi ausnutzen. Langsamer Zugriff, kann aber selber mit einem Blockkopierer im Bildspeicher umkopieren, allerdings das nur max 256 Bytes aufs mal, und er vergisst unvorhersehbar manchmal das letzte Byte einer Serie! Für Timing und Adressen aufbauend auf erweiterten MOS6545 Registersatz, dabei sogar Adressregister kompatibel mit der erweiterten Rockwell 6545-A1 (im Kaypro 10). Text 80x25 Zeichen. Mit 8x8 1bpp Font, stets aus RAM Satz, von 2*256 Zeichen (weit besser als CGA nur ROM Satz, von 1*256). Mit vollen 8bit Attributen (wie CGA), aber nur Bits 3..0 Vordergrund RGBI Farben ohne Hintergrund Farben (wie C64, von Register), weil Bits 7..4 für alternativen 256er Zeichensatz (erlaubt auch mischbare 2x4 Blockgraphik, mit 80x25 Zeichen 160x100 Blöcke) und revers und unterstrichen und blinkend (analog VDM-2 und Kaypro 10). Hat aber kein 2bpp "Multicolor", weil nur-Büro, was dem C128 keine verbesserten Spiele erlaubt! Daher in Bitmap Modus nur 640x200 1bpp, kein 320x200 2bpp, geschweige denn 160x200 4bpp (damit sogar schlechter als CGA, und erst recht weit unter PCjr oder BBC). Bitmap braucht die ganzen 16k, also kein Platz mehr für Attribute (wie CGA), daher Farben aus 2 RGBI Register (besser als CGA 640x200 mit nur 1 RGBI Vordergrund). Strikte kann er Overscan durch den MOS6545 umprogrammieren, aber kein Speicherplatz dazu. Kann eigentlich 64k nutzen, aber das wurde erst ab dem C128DCR verbaut, kann also nicht von Software vorausgesetzt werden. Erstaunlich hat er fein scrollen horizontal und vertikal. Sprites gar keine, wie zu erwarten, kann auch nicht so die fehlenden 2bpp kompensieren. Ausgabe auf digitalem IRGB Monitor (wie CGA), kann mit dem VIC-II zusammen entweder Dualhead oder einzelnen Monitor der beide Signale umschaltet. (Hat zudem erweiterten Speicher auf 2*64k. Mit sehr aufwendiger 11* 8bit Register MMU, aber trotzdem sehr unflexibel nur Banking Speicher Umschalter (wie Apple IIe "extended 80-column"). Hat zwar "durchfallen" auf Bank 0 einstellbar unten/oben/beide/keines und 1/4/8/16k, statt fest 48+16k, sowie untere 2*256bytes beliebig verschiebbar, aber keine separaten Schreib-/Lesezugrffe (wie Apple IIe), sowie erst recht nicht nach Adressmodus (wie PET-II/CBM-II). Daher sind selbst einfache fest System+Program+Daten Basis plus schaltbar Program+Daten Extras Techniken schwierig zu programmieren. Eigentlich auf 256k ausgelegt, aber nur 2*64k im MMU Chip implementiert.) (Mehr Speicher gab es nur mit den REU 1700/1750/1764 Modulen (1986) von +128k/512k/256k, welche aber reine RAMdisks für Daten waren. Programme kann man lediglich als Overlays umkopieren (wie es GEOS macht). Diese haben eigene byteweise Adressregister (wie VDC) und kopieren Daten per DMA sehr schnell (etwa 900kByte/s). Laufen daher auch am C64! Haben deswegen aber ebenso aufwendige 11* 8bit Register. Der C128 wäre trotzdem bereits ernsthaft verbessert gewesen, durch den Banking Speicher weglassen, mit statt dessen die +64k als eingebaute kleine REU! Deren REC Chip könnte sogar mit Bastelei auf +1oder2*256k hinauf (analog Atari 130XE "Extra" anwachsen bis maximal 64main+2*256extra=576k).))

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 um Pins zu sparen. (Plus 4 weitere falls Spectrum 48k, bestehend aus Spectrum 16k sein Grundspeicher plus 32k Erweiterungsspeicher, letztere 4 entsprechen also dem ZX81 DRAM Modul seinen TTLs.) (Es gibt einige Spectrum Klone, welche nahelegen dass die ULA etwa 35 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 die Ausgabe zu bremsen. Mit Bild aus dem ersten 16k DRAM (analog TMS9918), daher auch asynchron und nicht Prozessor bremsend. Aber mit Adressen vom Prozessor, bei 16k die ganzen 16k DRAM, bei 48k die ersten 16k davon, 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 "Graphic 2") mit 8x8 Font und somit 32x24 Zeichen (wie ZX80/ZX81). Wieder die untersten 2 Zeichenzeilen für System reserviert (wie ZX80/ZX81), und somit 32x22 * 8x8 = 256x176 Bitmap nutzbar. Bei 32*8=256 von 7MHz Pixeltakt ein schmales 36.6µs Textfeld. Pixeltakt is von NTSC/PAL komplett unabhängig, zwei separate Oszillatoren mit eigenen Quarzen. Damit kein Nebeneffekt von Wellenviertel Folge sich genau mit Pixel Folge decken, und trotzdem hat der Spectrum keinen Ruf von schlechtem Bild.

Trotz Bitmap und nicht Zellgraphik hat er wie her für jeweils 8x8 Pixel Zellen Farbattribute (wie VC-20 und C64). Diese sind voll 8bit, aber 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 angeordnet), 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 Randfarbe im Overscan Bereich (wie VC-20 nur 8 von 16 Randfarben). (Wäre ohne blinken leicht billiger gewesen, und mit dem Bit7 nutzbar für I Vordergrund und Hintergrund beide volle 4bit IGRB leicht besser, ohne teurer.)

Die Farbattribute sind aber mit nur alle 8x8 Pixel eine Farbzelle, für nur 6+0.75k statt 6+6k Bildspeicher, was öfter 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.) Fehlendes 2bpp ist wohl die grösste Schwäche dieser ansonsten erstaunlich guten Graphik. Das ist der Grund, warum man Bilder von Spectrum Spiele problemlos erkennt an rechteckige Bereichen mit je nur 2 Farben, und diese fast immer reines RGB benutzt, aber mit sehr feinen Details drin. Das traf gerade scrollende Spiele besonders schlecht, weshalb viele Spectrum Spiele ein statisches Spielfeld haben, zumeist mit schwarzem Hintergrund, nur bewegte Figuren in Bereichen mit deren Vordergrundfarbe nutzen, oder bei Objekten einander zu nahe kommend sich verfärbend.

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 vergleichbar viele 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 aber nur falls der Prozessor auf die ersten 16k vom DRAM Speicher zugreift, wenn auch der Videogenerator dies macht, was als "Contention" bekannt ist, und den Prozessor per Waitstates anhält bis der Speicher frei wird.

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% angehalten, hier ist 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 und Erweiterungsspeicher 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 48bzw40%/8=6bzw5%). 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 32k Erweiterungsspeicher.

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 für 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 aktuelle Zeilennummer (wie VC-20), geschweige denn Rasterinterrupt (wie C64), nicht mal vertikalen Rücklauf testen (wie PET/CBM und CGA) geht. Trotzdem kann Software synchronisieren. Einerseits einmalig indem sie vom Rücklauf Interrupt getriggert wird. Dieses ist aber nur zwischen Bildern der Fall, es müssen ab dann durch das ganze Bild ausgeben Zyklen abgezählt werden! Anderseits vorzu synchronisieren, indem sie Eingabe liest von nicht vorhandenen Geräten, und dabei mangels aktiver Datenquelle den Video Lesevorgang mitbetrachtet! Dieses kann ausgewertet werden mit spezifischen Pixelmustern sehen statt dem Defaultwert $FF wenn kein Video gelesen wird. Mit Attribute Vordergrund = Hintergrund können diese Pixelmuster sogar visuell unsichtbar im Bild versteckt sein.

(Der Nachfahre Spectrum 128 (1985) hat identisches Video. Dazu Bildausgang neben PAL Fernseher auch direktes analog RGB an Monitor (inklusive SCART Fernseher). Weiter für Audio einen AY-3-8912 Soundchip. Vor allem aber erweiterten Speicher von 16+32=48k auf 64+64=128k DRAM (wie Apple IIe und Atari 130XE und Commdore 128). Mit Paging (wie 130XE). Mit Speicherkonfigurationsregister. Bits0..2 wählen als 3 Pagebits welche von 2*(4*16)=128k Gesamtspeicher in C000..FFFF erscheinen, alle von "Grund" (mit "Contention") als xx1 und "Erweiterung" als xx0. Bit3 wählt ob Bild von Page 5 oder 7. Für Programme als 16+16k Basis +n*16k Segmente nutzbar. Für Daten direkt nutzen, oder nur RAMdisk. Zudem gab es 32k ROM, mit Bit4, welches von 2*16k Pages in 0000..3FFF erscheint. Schliesslich kann Bit5 das Register gegen Veränderung sperren. (Weiter kann mit Bastelei der Speicher auf 2*(16*16)=512k anwachsen, mit unbenutzte Bits6+7 als weitere Pagebits verwerten (fast analog Atari 130XE "Extra" anwachsen bis maximal 64main+2*256extra=576k).))

(Die Nachfahren +2 (1987) und +3 (1987) von Amstrad nach dem Firmenaufkauf von Sinclair sind auch 128k Modelle, mit identischem Video, aber mit besseren CPC-artigen Gehäusen+Tastaturen (+2 mit Tape vom CPC464 und +3 mit Disk vom CPC646/CPC6128). Aber die Zuordnung, welche Pages "Contention" haben bzw ohne diese sind, ist teilweise inkompatibel (neu sind 4,5,6,7 in den 64k mit). Zudem gab es ein zweites Speicherkonfigurationsregister, mit Bit0 0 = bisherige "Normal" ROM+RAM Modi oder 1 = neue "Special" nur-RAM Modi. In "Special" wirken Bits1+2 als eine Kopie der Amstrad CPC6128 CP/M 3.0 Modi 001..011 (aber mit Pages0..3 Benutzer und Pages4..7 System). Wobei mit nur 32 Zeichen pro Zeile der Einsatz von CP/M ohnehin sinnlos ist. Von diesen beiden Pagebits kann Bit2 zudem bei "Normal" von 2*16=32k auf 4*16=64k ROM erweitern. Dieses wegen +3DOS ROM addieren, was weit mehr Sinn macht als CP/M.)

Jupiter Ace (1982)

Abgeleitet von ZX80/ZX81 sowie insbesondere von ZX Spectrum, weil von teils Spectrum Designern ihre Nachfolgearbeit. Hat gleichen Z80A Prozessor und 3.25MHz Takt 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, aber ohne deren Zeichencodes per Prozessor aus dem Speicher holen Ansatz. Dementsprechend ziemlich primitiv.

Nur 1 Zellmodus. Zell 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 schwarzweiss. Kein Bitmap.

Aber hat 3 Paare 1kx4 SRAM Chips statt nur 1 Paar, als 1k für System und Benutzer, plus 2* 1k separate Bildspeicher als Zeichenspeicher und Fontspeicher (wie Sorcerer). Wegen separatem Fontspeicher ist beim Fontzugriff kein I Register als Basis ausnutzen notwendig (wie ZX80/ZX81 mussten). Der Font muss daher vom System aus ROM ins RAM geladen (und dabei auch dekomprimiert) werden, er 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 seine Details komplett ignoriert. Also war dieser völlig überraschend gut.

Der Bildspeicher hat stets Platz für ein volles Bild (braucht 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. Video wird ohnehin voll in Hardware ausgegeben, ohne den Prozessor zu benutzen oder NOPs vorzugaukeln, mit so stets Bildausgabe und Sync. Das alles ohne den Prozessor zu bremsen, ausser er greift auf den Bildspeicher zu.

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 (wie CGA). Das sogar mit wählbarer Priorität. Mit Adressbit10=1 bekommt Prozessor per Hardware Waitstates bis eine Videozeile ausgeben fertig ist, trotz dass der Speicher eigentlich Zugriffe zwischen Videodaten holen aushalten würde. Mit 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 sogar mit 3 TTLs weniger (2 für Fontspeicher schreiben/lesen Adressen und 1 für Hardware reverse), mit nur noch 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 wiederum obige 4 TTLs addiert auf 20, aber auch nur 3 mehr als ZX80, 2 oder 3 unter ZX81, trotz einiges besser mit 128 Zeichen. Er beweist so, 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 eingesparte zweite Paar 1kx4 SRAM Chips als entscheidend. Wobei diese Reduktion auch auf Kosten von Bildzeilen zusammenstreichen geht, sobald etwas Programspeicher benutzt wird.

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 davon 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 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 schwarzweiss (wie TRS-80).

Ohne den Gebrauch von I Register um Font zu adressieren, weil dieser in einem separaten 2k Font EPROM ist (wie TRS-80), was gegenüber ZX80 4 TTLs einspart (3 Adresse umschalten und 1 Zeichencode). Auch ohne HALT mit Datenbit6=1, sowie ohne Adressbit6 = 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 insgesammt weniger Chips! (dies kostet nur 2 TTLs plus 2 CD4000 anstelle 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 Pixeltakt durch 12*32=384 teilen nur 62.5us statt 64us (-2.344%), was die 320 grossteils kompensiert.

Auch ist keine Zeichencodes als Programm auslesen mit NOPs vorgaukeln nötig (was 2 weitere TTLs der ZX80 spart), weil erst der Refreshzyklus mit Register I und R für die Zeichencodes auslesen benutzt wird (wie ZX80/ZX81 im undokumentierten Bitmapmodus den nicht-Font) während der Prozessor einfach vom EPROM eine "Zeile" NOPs gegeben bekommt. (Strike sind beliebige 1-Byte 4-Takt Befehle erlaubt, solange sie für die Ausgabe benutzte Register nicht verändern. Was ausgenutzt wird um dem Prompt seinen Text dort abzulegen!) Daher keine Limite auf Bit6=0, womit volle 256 Zeichen machbar wären. Dies werden aber vom nur 2k Font EPROM mit den 13 Videozeilen/Zeichen ihren 16 Bytes Platzbedarf limitiert auf 2048/16=128, als 2*64=128 ASCII64 plus 2x3 Blockgraphik (wie TRS-80).

Mit IRQ Interrupt wird einmal pro Bild die Ausgabe angestossen. Dazu wird nur die Zeichenfolge lesen ihre I und R bestimmt sowie die Zeile in Font ausgewählt und am Ende die Zeilenausgabe blank per Programm gestoppt. Mit daher während der Zeile ausgeben zuerst 31 1-Byte 4-Takte Befehle notwendig sein, sowie als letzten 32sten Befehl den Opcode für Ende der Zeilenausgabe auf blank stellen, mit Videozeile in Zeichen auf eine der ungenutzten 3. (Diesen Befehl sein Datentransfer macht keinen Refresh, gibt also nichts aus, und erst danach kommende Befehle sind wegen nun Zeile in Font auf blank gestellt irrelevant. Bis als letzter Befehl vor der nächsten Zeile ausgeben wieder auf eine der genutzten 13 gestelt wird.) Das 8te Bit von R wird in Hardware nachgeflickt, und 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 und daher mit IRQ statt NMI um zeichnen auszulösen, einfach durch diesen mit DI aus- bzw EI einschalten erreicht werden (ohne ZX81 extra Schaltung), Die Bildausgabe und Prozessorbedarf sind dann weg, aber Sync bleibt weiterhin 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 2 TTLs. 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 entscheidend (aber das könnte hier auch teilweise gespart werden, die Zeilenanzahl mit nur die Ausgabe schneller beenden, was untere wegkürzt, oder obere mit warten auslassen, sowie Zeichen/Zeile mit NOP Serie Anfang überspringen und danach warten passend verlängern). 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.

Eigentlich ist damit die Auflösung nur von der Software her gegeben. Es können mit nur anderen Schleifen Konstanten in Register laden und anderes Font EPROM 8x8 1bpp auch 32x24 oder gar 32x27 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 24 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 24 oder 27 Zeilen als 8* oder 9* (3*40=120 + 8) unbenutzte in 128 ab, wie bei ZX80/ZX81 im ungeplanten und undokumentierten Bitmapmodus beschrieben. Weiter ist 8MHz Pixeltakt durch 16*32=512 zu teilen, was aber die 320 Zeilen nicht mehr kompensieren kann.)

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 74174 Hilfsregister an Bit2..7 mit einem 7474 an 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 nur 128 Zeichen in den 2k dort Platz haben, Bit6 als Adresse ignoriert wird. Das resultierende Verfahren ist praktisch identisch mit dem ZX80/ZX81 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, und 8k mehr ROM für die Graphikroutinen und einen Vollbild Editor, sowie für Audio einem AY-3-8910A Soundchip, ist als Galaksija Plus bekannt.

Nintendo Famicom (1983) bzw NES (1985)

Als Family Computer (Famicom) hauptsächlich als Spielkonsole designt. Aber erweiterbar zu einem vollen Homecomputer (im Gegensatz zu Sega ihren separaten SG-1000 und SC-3000 Modellen), mit Tastatur (und anderem) an Erweiterungsport, sowie mit DiskSystem (1986) mit Floppylaufwerk als Untersatz mit BootROM plus ErweiterungsRAM plus Diskcontroller im Modulport. Aber beim Export mechanisch umgebaut und funktionell reduziert zum Nintendo Entertainment System (NES), ohne Tastatur oder DiskSystem, nur noch reine Spielkonsole, mit 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, aber verhindert Prozessor Adressmodi ausnutzen. Hat nur 2k SRAM (sowie nur 2k SRAM Hauptspeicher, und damit selbst zusammen noch unter dem VC-20 seinen 5.5k SRAM!). Beide sind aber 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. Obiger "DMA" kann 256byte vom Prozessor Adresspages 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 Rü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 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, mit nun 8 sichtbaren 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 Bildrand, weil permanenter Overscan!). Dazu 4 Sätze von 3 für Bild/Spielfeld Vordergrund (viertes ist durchsichtig), 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, mit je 1 der 4 Sätze von 3 Vordergrundfarben auszuwählen. Aber nur jeweils 2x2 Zellen (also 16x16 Pixel!) haben ein 2bit Attribut (wegen Speichermangel, ausser das Spielmodul hat einen MMC5 Erweiterungschip drin, der mit mehr SRAM auf einzelne Zeichen (8x8 Pixel) genau spezifizieren erlaubt). 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 TED: 16 und 116 und Plus/4 (1984)

Designt als verbesserten 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 Graphik und Speicher als ersterer sowie weniger Graphik und Audio als letzterer. Damit explizit auf Niedrigpreis Small/Home Business ausgerichtet, nicht auf Videospieler.

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). Er ist damit eigentlich ein teilweises Wiederaufleben des zugunsten vom C64 abgesetzten VIC-40/VC-40, aber zu keinem der beiden kompatibel. 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. (Der TED Serie Entwickler hat, nach Kritiken bekommen, wegen diese inkompatibel mit C64 sein, danach den C128 als erweiterten C64 designt.)

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, statt wie PET/CBM und C64). Damit bis auf die bewusst weggelassenen Sprites fast das beste was man kombinieren konnte. (O-Ton TED Serie Entwickler: "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 Bildrand, 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 einen internen 40*(8+8)bit Buffer (statt C64 40*(8+4)bit). 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 51bzw43% * (2+8)/16 = 32bzw27% davon verloren gehen. Hat einen 2MHz Prozessor, aber unnötig auf 7/8 gebremst (wie Atari 800), was ihn mit 1.79 * (100-32bzw27) = 1.217bzw1.307MHz verbleibend im Vergleich zum C64 1.0227bzw0.985 * (100-6bzw5%) = 0.9613bzw0.9358MHz verbleibend, nur noch etwa 26.6bzw39.6% schneller sein erlaubt.

Overscan fehlt wie C64, trotz keinen separaten Farbspeicher welches dies auf 1k limitiert. Wiederum ist auch ohne bereits ein 44.7µs Textfeld, und Overscan ist im Bürobereich ohnehin irrelevant. Das kann zudem mit sehr extensiven Rasterinterrupt Techniken teilweise kompensiert werden, solange nur etwas 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 und stets ganzes Bild. 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 weil im Bürobereich irrelevant. Aber solange man keine Sprites oder Paddles braucht ist er auch ein guter abgerundeter Chip.

Der C116 ist das eigentliche ursprüngliche Design mit Gummimatte Tastatur. Er wurde in C16 mit Volltastatur umgewandelt für C64-ähnlicher, entgegen dem Niedrigpreis Ziel, ist dann aber wegen zu teuer geworden doch noch als C116 herausgekommen. Er wurde sogar als Serie zum C232 und C264 erweitert, entgegen dem Minimalrechner Ziel, aber nur letzterer ist herausgekommen als Plus/4, mit 4 in ROM eingebauten Applikationen. Weiter erweitert mit Numerikblock und Sprachausgabe als C364, aber dieser wurde ganz fallengelassen. 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). Das zumal sie neben mehr Video und Speicher auch noch schnelleren Prozessor als VC-20 hatten (wenn auch vom Video mehr ausgebremst, wie Atari 800).

Der Plus/4 hatte zudem als reinen "farbigen PET" mehr in Basic nutzbares RAM (und alle hatten besseres Basic). Ebenso hatte er die namensgebenden 4 in ROM eingebauten Applikationen. Welche aber trotz in ROM sein, um von Band laden zu sparen, ihre Daten nicht auf Band speichern konnten(!). Womit diese nach Floppylaufwerk verlangten, was sie platzlimitiert und teurer in ROM einbauen statt flexibel von Floppy laden sinnlos machte.

Das wären eigentlich ordentliche Lowcost Small/Home Business Rechner gewesen. Nur hat Commodore nach Managementwechsel entgegen dem explizitem Designziel von Billigmarkt unterhalb des C64 versucht, den C116 als C16 umgewandelt C64-ähnlicher zu machen, und alles zu einer Serie auszubauen. Gefolgt von den Plus/4 gar als Nachfolger vom C64 vermarkten versuchen, trotz explizit als schwächer designt ohne Sprites. Was ihm prompt seinen Spitznamen Minus/60 einbrachte.

Amstrad/Schneider CPC464 (1984)

Ziel war, besser als den "schwangeren Taschenrechner" (O-Ton Amstrad Firmenchef(!)) des ZX Spectrum zu sein", mit echter Tastatur und 80 Zeichen, aber weit 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 analog 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). (Beim in TTL Chips gebauten Prototyp, zwecks Logik verifizieren bevor Customchips hergestellt wurden, besteht der Gate Array Simulator (so sein offizieller Name) aus 38 TTLs plus 8 PALs. Mit PALs vergleichbar zu etwa 3..10 TTLs, also 6 im Schnitt, entspricht das 8*6+38=86 TTLs. Dazu kommen je nach Modell etwa 10..15 TTLs ausserhalb.) 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 aber mit max 1MHz Speicherzyklen nur 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 Doppelzugriffe 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 Commodore 64 "Bad Lines" einsetzen verhindert), und wegen viele bpp keine separaten Attributbytes (was ZX Spectrum Bildspeicher so nichtlinear macht). Die reinen Bitmap Bytes liegen daher immer in Serien vor, stets 80 pro Zeile. Was 80 Bytes 2MHz statt 40 Bytes 1MHz Videodaten erlaubt, und 16k statt nur 8k Bildspeicher (wie Atari 800 und C64) oder gar nur 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 mal gebremst wird, abgesehen von 3-Takt Zugriffe auf 4 Takte ausdehnen sowie 5oder6-Takt auf 8, was aber wegen ohnehin zumeist 4-Takt unter 10% kostet. Damit weniger im Vergleich zu ZX Spectrum auf 3.5MHz und MSX auf 3.579646MHz bremsen. Damit war der CPC der schnellste aller 8bit Homecomputer!

Auch hier kann die MC6845 nur bis 128 (Zeichen-)Zeilen zählen. Hier werden die 200 Zeilen als 25 (Zeichen-)Zeilen zu je 8 Videozeilen angeordnet (wie BBC und C64), statt 100 zu je 2 (wie CGA). Aber mit den Videozeile in Zeichenzeile Bits vorne zusammengelegt (wie CGA), und damit als A11..13. Womit die 200 (Video-)Zeilen als 25 (Zeichen-)Zeilen 0,8,16,... zu je 8 Videozeilen pro Zeichenzeile angeordnet sind (wie Apple II mit "Hi-Res" Bitmap), statt die 8 Bytes einer Zeichenposition direkt hinter einander im Speicher (wie BBC oder TMS9918 oder C64). Hat keinen vollen Rasterinterrupt, aber mehr als nur Vertical Blank Interrupt (VBI), mit 6 mal pro Bild (jede 52 von 312 Zeilen).

Farben 2/4/16 + Bildrand, aus 27 analog 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 ist in Software mit in vertikalen Rücklauf Interrupt die Farbzuordnungtabelle modifizeren, was komplett sinnvoll Hardware spart. Insgesammt werden 6 Interrupt pro Bildausgabe erzeugt, damit man nicht ganzes Bild abwarten muss. Benutzt mitgeliefertem RGB oder Grün Monitor (deren Netzteile auch gleich den Rechner versorgen), sowie Fernseher oder Videomonitor (brauchen separates Netzteil mit einem RGB zu Video Umwandler drin), oder analog RGB Monitor (inklusive SCART Fernseher) (brauchen dann separates Netzteil). Weil keine Rücksicht auf NTSC oder PAL genommen wurde, 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, und hat wegen stets 200 Zeilen somit immer 16k. Diese 16k werden hinter dem Basic ROM "versteckt", welches schaltbar ist (analog Apple IIe eingebaute "Language Card" und Atari 800XL addierte Umschaltbits und Commodore 64 Umschaltbits). 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 hat es 80 Bytepositionen 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 (wieder unter +10%, und im Gate Array drin). Genau dieses kleine Mehr macht wieder den Unterschied aus, von der CGA schrottig zu CPC (und BBC und PCjr) anständig und modern. Und hier zudem noch mit ordentlichen 3*3*3=27 statt 2*2*2=8 RGB Farben erweitert!

Die MC6845 ihre Adresse MA0..9 wird als A1..10 an den Speicher angelegt (nach A0 um die Bytes im Paar zu unterscheiden). Dann kommen die Zeile in Zeichen Bits als A11..13. Die MA10..11 werden ignoriert. Erst die MA12..13 ergeben die fehlenden A14..15. Damit ist das Bild in einem 16k Adressblock "gefangen" (strikte in 8 2k Blöcken davon), läuft nach hinten raus wieder vorne rein, weil der Übertrag nach MA10 verloren geht! Damit kann man grob scrollen ohne umkopieren, durch das Bild irgendwo in den 16k anfangen und einfach 16000 Bytes laufen lassen. Damit werden aber die 40 Bytepaare einer Zeile zu nichtlinear, sobald diese genau über die 2k Grenzen zu liegen kommen. Was im Programm abgefangen werden muss, und dieses langamer macht, weil der Prozessor sonst in die nächsten 2k schreibt, und somit in eine andere der 8 25er Zeilengruppen. Zudem ist die Schrittweite wegen MC6845 ihre Adresse für Bytepaare holen genutzt, bei 160@4bpp 4 Pixel oder 320@2bpp 8 Pixel oder 640@1bpp 16 Pixel stets mit nur in 40 Schritten. Weshalb dies das fehlende horizontal fein scrollen nicht ersetzen kann (vertikal wäre es völlig ausreichend, wenn nicht die Zeilen in 8er Abstand angeordnet wären). Weshalb man ohnehin mit zwei Bildspeicher und jeweils im inaktiven ganzes Bild neu aufbauen arbeiten muss, wonach der grob scrollen Effekt zu praktisch wertlos wird.

Durch die Anzeige umprogrammieren kann man Overscan bekommen. Dazu muss man das Bild in die mittleren 2*16k legen, und setzt dazu die Anfangsadresse mit MA12..13 = 01 auf den ersten dieser beiden Blöcke, und MA10..11 so dass sie rechtzeitig auf 00 überlaufen und damit MA12..13 +1 werden, womit die Anzeige in den zweiten dieser Blöcke "ausbrechen" kann. Dies erlaubt einen Overscan von (192|384|768)x240 Pixel in 23k Speicher, oder gar (208|416|832)x288 in 30k.

(Die Variante CPC664 (1985) hat identisches Video und auch restlicher Rechner. Er unterscheidet sich nur durch weglassen des eingebauten Kassettenlaufwerkes zugunsten eines eingebauten Diskettenlaufwerkes. Der CPC464 kann mit einem externen Diskettenlaufwerk erweitert werden, der CPC664 mit einem externen Kassettenlaufwerk. Egal welche Disk wird selbiges AMSDOS benutzt, in C000..FFFF, als eines der bis zu 256 schaltbaren ROMs, mit Basic Nummer 0 und AMSDOS Nummer 7.)

(Die Variante CPC6128 (1985, nur 3 Monate nach CPC664!) hat ebenfalls identisches Video und Rechner, sowie selbiges Diskettenlaufwerk wie CPC664. Er unterscheidet sich nur durch erweiterten Speicher auf 64+64k DRAM (wie Apple IIe und Atari 130XE und Commdore 128 und Spectrum 128). Wieder je 64k "First" und "Second". Ein Speicherkonfigurationsregister Bits 0..2 wählen Modus und Page. Mit 000 = 64k "First" (wie CPC664). Mit 1xx = ersetze 4000..7FFF mit xx für 4*16 vom "Second" (wie Atari 130XE, Paging). Mit 010 = ersetze alle 64k durch "Second" (wie Apple IIe mit voll 48k und 16k, Banking). Mit 0x1 = ersetze nur C000..FFFF durch obere 16k von "Second", mit restliche 48k "durchfallen" zu "First", was Sprung zwischen System zu Programm erlaubt. Mit falls x=1 ersetze auch 4000..7FFF durch verschobenes C000..FFFF von "First". Für Programme mit 1xx als 48k Basis +n*16k Segmente nutzbar. Für Daten mit 1xx direkt nutzen, oder nur RAMdisk. Mit 1xx kann System das "Second" mit Benutzerprogramme füllen, dann mit 010 laufen lassen, mit 0x1 für Systemaufrufe ins "First", und so mit separat 64k System und fast 64k Benutzer ein CP/M 3.0 fahren. (Die CPC464 und CPC664 können mit externen Modulen erweitert werden, aber Modus 0x1 mit x=1 verschieben funktioniert nicht. Ebenso wird stets dem "First" sein 16k mitbeschrieben, wenn auf "Second" geschrieben wird. Der CPC6128 kann auch externe, sogar mit verschieben und ohne mitbeschreiben.) (Externe gab es in +1oder2*(4*16k) und +1oder2*(16*16k) Versionen, für 64+(64..512)k, mit unbenutzte Bits3..5 als weitere Pagebits verwerten (analog 130XE "Extra" anwachsen bis maximal 64main+2*256extra=576k). Womit xxx010 Banking sogar Multitasking erlaubt, wie es SymbOS macht. Das ist aber unter CP/M 3.0 nicht ausnutzbar, weil kein Multitasking.))

(Die Nachfahren 464plus und 6128plus (kein CPC mehr im Namen) (1990) erweiterten dies. Sie addierten fein scrollen horizontal und vertikal, zusammen mit einem Zeilenvergleichsregister um zu einem zweiten Speicherauschnitt zu springen, für grob scrollen ohne umkopieren. Zudem Sprites, 16 16x16 4bpp, separat horizontal und vertikal streckbar *2 oder *4, in internem SRAM des ASIC Customchips (ersetzt MC6845 und Gate Array und AY-3-8912 und 8255 PIO), weshalb sie nur aufwendig per Rasterinterrupt explizit mehrfach verwendbar sind. Sowie 32 von 4096 RGB Farben (16 Spielfeld + 1 Rand + 15 Sprites). Weiter DMA für Sound abspielen. Sowie noch analog Paddles/Joysticks, neben vorher nur digital. Waren aber weit zu spät um noch relevant zu sein.)

(Die Seitenlinie PCW 8256 (1985) (bzw Schneider Joyce in Deutschland) war ein volles Bürogerät und kein Homecomputer. Hat neben Z80A Prozessor und 8* 41256 DRAMs und uPD765 Floppycontroller und 8041 Drucker Mikrocontroller genau noch ein 80pin(!) Gate Array. Hat nicht mal ein ROM, da der Drucker Mikrocontroller bei angehaltenem Prozessor einen Teil von seinem ROM via dem Gate Array ins DRAM lädt, dieses bootet dann 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)*16k Seiten an DRAM verstreut sein, mit einer 256*16bit Tabelle (3bit Seite + 10bit A4..13 + 3bit A0..2, kein A3) ihrer Adressen um sie zu finden (wie Atari 800, wenn Displayliste ohne Modusbyte nur stets die Datenadresse setzen würde, dies aber in jeder Zeile). Videozeilen benutzen, um schnell zu rendern, nur jedes achte Byte, damit 8 Bytes/Zeichen in Zeilengruppen 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, und richtete diesen rein auf das aus. Hat Rechner mit 256k DRAM und Floppy 180k im Monitor drin, aber separate Tastatur (wie TRS-80 Model II), sowie stets mitgeliefertem Nadeldrucker. Das Netzteil im Monitor versorgt auch Rechner und selbst Drucker, mit nur 1 Stromkabel+Schalter. Hat weit aufwendigere beliebige (4vonN)*16k Paging Adresserweiterung, mit maximal N=128 bis zu 2MByte. Hier mit N=16, genutzt als 5*16=80k System + 4*16=64k Benutzer + 7*16=112k RAMdisk (Bootdisk minus System wird dorthin geladen bevor Benutzerdisk einlegen, spart zweites Laufwerk). Lief nur noch mit CP/M 3.0 System und stets mitgelieferter Locoscript Textverarbeitung. Dies alles passend zum Einsatz als bessere elektronische Schreibmaschine. Insbesondere war es weit besser als die Konkurrenz durch aufgerüstete elektrische Schreibmaschinen, mit Rechner plus Floppy in einem kombinierten Tastatur+Druckwerk, sowie separatem Monitor. (PCW 8512 (1985) hat 512k statt 256k Speicher für +16*16=256k an RAMdisk, sowie zweite Floppy mit 720k.) (PCW 9512 (1987) hat Typenrad- statt Nadeldrucker.))

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 separater 16k Bildspeicher. Wie diese vom Prozessor adressiert, dessen Adressmodi ausnutzend. Bitmap 320x240 1bpp, mit PAL Monitor Zeilen ausnutzen (wie Microtan 65 und BBC), trotz dass die DDR eigentlich SECAM Fernsehen benutzte! Erlaubt daher sogar 40x30 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..239 an A0..7 und X 0..39 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, die ersten 10k nutzend (der Rest beinhaltet 2.5k Farbattribute und 1.25k Zeichencodes). Eigentlich ist das Resultat wie bei 5 linear durchlaufenen 256er Fonts (wie TMS9918 "Graphic 2") 3 Fonts und C64 4 Fonts), aber mit deren Zeichenfolge 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" bzw "Color Spill" ziemlich anfällig.

Mit 10k Bitmap plus 1/4= 2.5k Farbattributen (plus 1/8= 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 umplatziert, und dann als Ausbildungsrechner benutzt, weil mit DDR Wirtschaft weder massentauglicher Preis noch Fabrikationsmenge drin lagen.

(Der Nachfahre KC 85/3 (1986) hat identisches Video und auch restlicher Rechner. Er 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. Bildspeicher ist als 2*(2*16k) aufgeteilt, mit in 2*16k nun 10+10k statt 10+2.5k an Bild (wieder plus 1.25k Zeichencodes). Hat nun 2 Bitmapmodi. Obiges 320x256 1bpp (aus ersten 10k), aber mit jede 8x1 Pixel Farbattribute 2 aus 16 (wie TMS9918 "Graphic 2"), 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 2bpp für R und G=B). Letzteres aber wegen dem aus 10+10k zusammengesetzen Bildspeicher mit zwei 8*1bpp Bitplanes statt 20k von 4*2bpp Chunks (mit R in ersten 10k und G=B in zweiten). Es ist damit wie der Amiga sehr anfällig auf "Ghosting" beim scrollen, wenn das ausgegebene Bild Pixel anzeigt 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, vergleichbar dem "Snow" Problem. (Beim 1bpp plus Farbattribute kombinieren sich lediglich neues Muster mit alten Farben, was weit weniger flackert.) Es kann allerdings egal ob 1 oder 2 Bitplanes wegen 8*1bpp mit dem gleichen Font beschrieben werden, statt bei Chunks mit auf 2 Bytes von je 4*2bpp verteilten Font. Wiederum sind je nach der zu setzenden Farbe ihrer Nummer die Bits der verschiedenen Planes in diversen Kombinationen zu setzen oder zu löschen, was mühsam zum programmieren ist! (Zugriff auf den Bildspeicher ist nur 16k aufs mal, eine Bitplane. Dazu hat es Paging (wie Atari 130XE und CPC) aber mit 2*(4*16)=128k Gesamtspeicher in 8000..BFFF (analog Spectrum 128). Für Programme als 32k Basis +n*16k Segmente nutzbar. Für Daten direkt nutzen, oder nur RAMdisk.))

Apple Macintosh (1984)

(Davor war die Apple LISA (1983). Diese hatte selbigen 68000 Prozesser (aber mit nur 5MHz), erstaunlich grosse 1024kByte RAM (das wären 8*128k aus je 16 64kBit DRAMs, also 128 Chips!), nur 1 Bitmapmodus, 720x364 Pixel in 32k, auf eingebautem 12" Monitor. Es passen 120x45 Zeichen vom default 6x8 Font (horizontal 90dpi, vertikal 60dpi). Dieser kostete aber mit $10000 weit oberhalb der 3'000$/DM/Fr/Eur Limite, und scheidet damit hier aus.)

Hat auch 1 Bitmapmodus. Mit Bild aus dem normalen 16bit DRAM Hauptspeicher. Hat keine Customchips, alles reine TTL Logik, aber teils kompaktiert mit PAL Chips, dementsprechend sehr primitiv für seine Zeit. Genauer hat es neben Prozessor und 2*32kByte ROMs (64k) und 16*64kbit DRAMs (128k), sowie standard 6522 VIA (Konfig+Laustärke+Tastatur+Maus) und 8534 SCC (Drucker+Modem+Maus), sowie Apple eigene IWM Floppy und STF Uhr, noch genau 6 PAL Chips (seine simple Form von Programmierbarer Logik) und 15 TTLs. Mit PALs vergleichbar zu etwa 3..10 TTLs, also 6 im Schnitt, entspricht das 6*6+15=51 TTLs.

(Das ist vergleichbar wenig Logik wie beim "Trio von 1977" benutzt! Die Apple II und TRS-80 haben (ohne Maus und Drucker+Modem und Floppy+Uhr) etwa 55 TTLs, aber keine grossen Chips, die VIA Funktionen müssen mit teils derer TTLs ersetzt werden. Die PET 2001 hat (ohne Maus und Modem und Uhr) nur 40 TTLs, sowie 1* 6522 VIA und 2* 6520 PIA, wobei eine der PIA bereits Drucker und Floppy Anschluss ist.)

Hatte 128k Speicher, im Vergleich zum Apple II statt 4..48k, daher den Featuresatz abgebaut/vereinfacht, nur noch Bitmapmodus wie bei "Hi-Res", keine Textmodi oder Blockmodi mehr. Daraus dank 16bit recht hohe (aber wegen langsamem Speicher für 16bit eher niedere!) 512x342 1bpp (und damit selbst unter den 720x348 einer HGC Bitmap). Nur auf dem eingebauten 9" schwarzweiss Spezialmonitor. Hat dabei exakt quadratische Pixel. Eigenartigerweise aber keine 512x384, was ein echtes 4:3 Bild ergäbe. 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 eigentlich 8MHz fähige 68000 Prozessor wird etwas gebremst auf eigenartige 7.8336MHz. Dies weil Hälfte vom 15.6672MHz Pixeltakt, welche wiederum auch /4.25(!) die 16*230400Hz für SCC Drucker+Modem abgeben. Dies nur so um einen zweiten Quarz zu sparen, der so billig wäre, dass selbst der ZX Spectrum sich zwei davon leisten konnte! Damit 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 "Hi-Res" 8k, und nur 1/3 mehr als Apple IIe und Apple III "Double Hi-Res" 16k.

Aber weit schlimmer wird es, weil wegen langsamen 2MHz 64k Speicherchips während den Videozeilen ausgeben der 2MHz nutzende Prozessor für jeden zweiten Speicherzyklus angehalten wird (alle Bildzeilen sind somit halbe "Bad Lines"). Video kann damit halbe 1MHz nutzen, was eigentlich nur 16kByte erlauben würde, wären die Rücklaufzeiten nicht durch geringeren Bildrand reduziert worden. Der Bremser wegen Videozugriffe ist somit um 0.5 * (512/(512+192=704)) * (342/(342+28=370)) = 0.336 = 33.6%, von 7.8336MHz auf 5.2338MHz. Allerdings gilt dies nur bei RAM Zugriffe, ROM und IO sind ungebremst. Womit am Schluss beobachtete etwa 6MHz Durchschnitt herauskommen, nach Apple ihrer offiziellen Dokumentation.

Das gilt auch im Mac 512K, weil nur 1*128kByte aus 16 64kBit DRAMs ersetzt durch 1*512kByte aus 16 256kBit, sonst identisches Board. Selbiges gilt immer noch im Mac 512K Extended, weil nur Floppy von 400k auf 800k verdoppelt. Ebenso noch im Mac Plus (1986), weil nur ROM Chips von 2*32k auf 2*64k, sowie 16 DRAMs ersetzt durch Paare von SIMMs mit je 8 DRAMs (zu wahlweise 256KByte oder 1024kByte), und zudem doppelt so viele möglich (für 256k oder 512k bzw 1M oder 2.5M oder 4M), sowie SCSI addiert (für externe Harddisk). Erst im Mac SE (1987) wurde die Videologik neu designt, welches diesen Bremser etwa halbiert haben soll (aber immer noch nicht ganz eliminiert!), sowie nun 2*128k ROM und 2 Laufwerke Platz (Zweitfloppy oder Harddisk) und ADB addiert (für beliebige Eingabegeräte). (Die LISA hatte, trotz nur 5MHz Prozessor, vermutlich mit 2.5MHz Speicher zu je 1.25MHz nutzen durch Prozessor und Video, die 32k entweder mit Pagemode Doppelzugriffe geholt (wie CPC) oder mit 16+16=32bit doppelbreit (analog Apple IIe und III 8+8=16bit doppelbreit).)

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

Es passen 85x28 Zeichen vom default 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. (Dies vielleicht wegen selbigen 6x12 Font, der typisch für Nadeldrucker ist, auch auf dem ImageWriter benutzten, einem auch etwa 512 Pixel breit nutzbaren 72dpi 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, kostet so nur 2 Adressmultiplexer + 2 PCM Zähler = 4 der 15 TTLs, und tut zusammen mit nur einem PAL Chip auch die Floppy Drehzahl steuern.

Ursprünglich mit Ziel als Billigrechner von $1000 designt, zu nutzen als "Information Appliance" (= Informations Haushaltsger¨t). Eigentlich eine bessere elektronische Schreibmaschine, mit Rechner plus Floppy im Monitor eingebaut sowie separater Tastatur, statt mit Rechner plus Floppy in einem kombinierten Tastatur+Druckwerk eingebaut sowie 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 mit 8bit Technologie weit billiger und sehr erfolgreich umsetzte.)

Man beachte hier noch, dass der Mac anfangs Entwicklung in 1979(!) einen 8bit 6809 Prozessor hätte haben sollen, mit 256x256 8kByte Bitmap. Dann wurde Ende 1980 auf eine 16bit 68000 mit Adapter zu 64k 8bit Speicher mit dem Prozessor 2*8bit Pagemode Doppelzugriffe benutzen umgestellt (die 16/8bit 68008 existierte damals noch nicht), mit 384x256 12kByte Bitmap. Erst nach wegen Software Platz geben ohnehin 2 Bänke DRAM und 2 ROMs brauchen, wurde Herbst 1982 auf vollen 16bit Speicher erweitert, mit dann 512x342 Bitmap. Einfach und billig war dabei stets wichtiger als Leistung! Erst nach dem Wechsel von 6809 zu 68000 (und dabei Preis von geplant $1000 auf $1500 angehoben) wurde der Mac von Steve Jobs zu einer billigeren Alternative zur schweineteuren $10000 LISA aufgebauscht, nachdem er dessen Entwicklerteam wegen Streit verlassen hatte. Die dazu notwendige komplexe GUI Software erstellen dauerte weit länger als geplant, verzögerte den Rechner um Jahre, bis Anfang 1984, wonach der 128k Speicher schon veraltet war, und inzwischen auch unterdimensioniert für die gewachsene Software. Trotzdem wurde anfangs diese Konfiguration verkauft, statt direkt auf 512k zu gehen. Nach Apple ihrer Weigerung eine Upgrade Eintauschaktion anzubieten entstanden Firmen, welche Macs von 128k auf 512k umlöten, sogar genügend konkurrenzierende davon, dass manche selbst Ersatz der verfallenden Garantieleistung anboten!

(Der anfängliche Mac Projektleiter ist frustriert von diesem Kurswechsel 1982 bei Apple weggegangen, und hat 1984 Information Appliance Incorporated gegründet, um seine ursprüngliche Vorstellung doch noch herauszubringen. Zuerst als Apple IIe Karte SwyftCard (1985), dann aber als 68008 Laptop Swyft (nur Prototyp) und 68000 Desktop Canon Cat (1987). Letzterer hat auch die anfangs geplante "Schreibmaschine mit eingebauter Tastatur aber Bildschirm statt Druckwerk sowie Disk neben Bildschirm" Bauform, im Gegensatz zum Mac "Klötzchen mit Bildschirm und Disk darunter sowie separate Tastatur". Daher hatten beide Tastaturen auch keine Cursortasten, weil Schreibmaschinen keine haben, und diese "unerfahrene Benutzer abschrecken" (O-Ton Projektleiter). Zudem hatte es beim Mac keine Cursortasten um Benutzer zur Maus angewöhnen zu zwingen, und ebenso beim Canon Cat auch keine Maus mehr, um Benutzer zur schnellen Suchfunktion angewöhnen zu zwingen. Er wurde dann aber nach anfangs Erfolg trotz wenig Marketing, nach wenigen Monaten bei Canon abgeschossen, ohne offizielle Grundangabe. Der Projektleiter verweist auf mangelhaftes Marketing, erwähnt aber auch zwei annonyme Telephonate, welche zwei verschiedene Gründe ausgaben: Einer behauptet er sei Opfer eines internen Machtstreites zweier Abteilungen geworden, anderer behauptet er sei als Teil des Laserdruckermechanismus 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! Der Mac 512k war sogar $3200, von 128k auf 512k +$700, bzw da der Mac 128k gleichzeitig auf $2300 gesenkt wurde +$900. Der Mac verkaufte sich anfangs recht gut, wegen einzigartig, aber brach innert Monaten ein, weil nur wenige Leute sich den Preis leisten konnten, und noch weniger für einen bald als total unterdimensioniert erkannten Rechner leisten wollten. Versagen dem Preis der Hardware oder die Umsatzerwartung dem Interesse anzupassen führte zu massiver Überproduktion und Verlusten, gefolgt von Personalentlassungen und Absetzung von Steven Jobs durch das Management, gefolgt von dessen Weggang von Apple.

(Im Vergleich war die LISA (1982) wegen 1024kByte DRAM aus 64k Chips und 5MB Harddisk und trotzdem 2 Floppylaufwerke noch $10000, aber die LISA 2 (1984, gleichzeitig mit dem Mac) war nur noch $3500 bis $5500 (je nach ob keine/5MB/10MB Harddisk, mit 256k Chips und 1 Floppylaufwerk). Damit war der Mac nicht mehr wirklich billiger, nur noch $2300 oder $3200 statt $3500, für 128k oder 512k statt 1024k DRAM, sowie 512x342 statt 720x364 Pixel auf 9" statt 12" Monitor, sowie keine Option auf Harddisk, sowie Tastatur Numerikblock als Option statt eingebaut, sowie limitiertere Software wegen auf 128k Billigrechner mit wenig Speicher ausgelegt. Also ein sehr schlechter Deal. Mit dem 512k auf $2300 und 128k auf etwa $1500, oder besser 128k ganz abgeschossen und allen frühen Käufern als Entschuldigung einen kostenlosen 512k Upgrade abgeboten, wäre der Mac akzeptabel gewesen. Im Vergleich mit der Konkurrenz war der Atari 520ST mit 512kByte nur $800 mit 12" schwarzweiss Spezialmonitor bzw $1000 mit 12" RGB Videomonitor, trotz einiges mehr an Bauteilekosten als der Mac. Ebenso war der Amiga 1000 mit 256kByte noch $1300 ohne Monitor (sowie +$150..200=1450..1500 mit Schwarzweissmonitor bzw +$300..400=$1600..1700 mit Farbmonitor), trotz dessen teureren aufwendigen Customchips.)

(Selbige Preisvorstellungen hat Steve Jobs bei seiner neuen Firma NeXT wiederholt, mit erstem 68030 Rechner geplant $3000 aber dann verkauft $6500. Er ist damit gnadenlos gescheitert.)

(Vergleichbares hatte Steve Jobs schon davor mit dem Apple II gemacht. Eigentlich als minimalistischen Rechner designt, aber wegen Farben und Bitmapgraphik als teuren Powerrechner vermarktet. Das ergab je nach 4..48k Speicher von $1300 bis $2600 (+4k war +$100, von 4k auf 16k war +$400, +16k war +$500). Das nur für den Rechner ohne Monitor und Kassettenlaufwerk (diese addierten noch etwa +$200 Schwarzweissmonitor bzw +$500 Farbmonitor, sowie +$50 Kassettenlaufwerk). Die in 1977 gleichzeitigen herausgekommenen Tandy TRS-80 und PET 2001 waren weit billiger. Ersterer mit 4k Speicher war im Paket Rechner+Monitor (und Kassettenlaufwerk als Dreingabe) 400+200(+50) = $600 (von 4k auf 16k war +$300). Zweiterer mit 4k Speicher sowie Monitor und Kassettenlaufwerk fest eingebaut war $600 (+4k war +$200).)

(Ganz ausser Konkurrenz kam erst beim 32bit Nachfahren Macintosh II (1987) eine Auswahl von Graphikkarten mit separatem Bildspeicher. Darunter auch farbige, anfangs mit VGA-artigem 640x480 4bpp, sowie grössere schwarzweisse, anfangs mit vertikalen 600x800 2bpp (A4 Portrait Monitor). Später auch 8bpp farbig bzw A3 Landscape. Der Macintosh IIcx (1989) mit A4 war der erste richtig ausgereifte und kompakte.)

Sinclair QL (1984)

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 und RS232 und Laufwerke ist wegen Pinzahl in einer zweiten ULA ausgelagert, auch die Laufwerke haben je eine weitere ULA drin). Daher halb primitiv. Mit Bild aus dem normalen DRAM Hauptspeicher. Strikte halbes 16bit, weil anstelle der vollen 68000 wie in den meisten anderen 16bit hier, nur den kleinen 16/8bit 68008.

Aber wegen 8bit auch zur ULA, trotz 2* 64kByte an DRAM Chips drin, mit massiv "Contention" und Prozessor per Waitstates anhalten, vergleichbar bei einem Spectrum mit nur 16k. Genaue Dokumentation zu den Taktdetails ist nicht aufzufinden, aber Aussagen, dass Software aus einem ROM Modul oder der externen 512k Speichererweiterung doppelt so schnell läuft als aus dem eingebautem 128k RAM, lassen schliessen auf Prozessor während der Zeile ausgeben zu 100% anhalten (statt Spectrum nur 50%), und das in jeder Zeile! Mit externer Speichererweiterung (oder auch nur den eingebauten Speicher als 64k plus 64k aufgeteilt!), wäre dies eher wie beim Spectrum 48k seinen 16k plus 32k gewesen. Oder ansgesichts von 2 Sätze an DRAM Chips und auch 2 ROM Chips gleich eine volle 68000 nehmen (wie ab 1982 auch im Macintosh erweitert), was nur mehr Pins an dieser und an der ULA sowie eine zweite 74245 kosten würde, aber doppelte Speicherbandbreite und keine "Contention" mehr 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 die umschaltbare KC 85/4 an einem Spectrum bzw einem QL Modus. Nur hier bei 2bpp mit B=R&G für grün statt dort B=G für cyan, und hier 512x256 statt dort 320x256 Pixel.) Das ist fast so schwach wie die MC6847 basierten Rechner (aber hat wenigstens schwarz in der Auswahl, und hier mit 512x256 statt dort nur 128x192 Pixel). Allerdings sind die 2bpp angeordnet als zwei 8*1bpp Pseudobitplanes (wie KC 85/4). Das trotz dass diese beiden Bytes nicht auf 10k+10k Speicher verteilt sind, sondern direkt hinter einander im einen ansonsten linearen Bildspeicher liegen. Es ist damit wenigstens nicht mehr anfällig auf "Ghosting" beim scrollen. Es ist aber weiterhin mühsam zu nutzen, oder gar wegen der anderen Bitplane ihre 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 Byte0 4*BR und Byte1 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!

Zudem 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 plus Attribute (wie Spectrum) wäre für Text weit besser, zumal bei Text Attribute Clash irrelevant ist.) Anderseits hat der spieleorientierte 256x256 Modus blinken, trotz dass er dieses kaum nutzen kann. Er verliert dafür die Hälfte der möglichen 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. Wenn schon schalten, dann beides 512x256 mit 1bpp plus Attribute und 2bpp ohne. Für einen reinen Businessrechner wäre sogar nur 512x512 1bpp (oder besser 640x400 1bpp) auf einem schwarzweiss Spezialmonitor sinnvoller gewesen. Oder auch nur 512x256 2bpp (oder 640x200 2bpp) mit Graustufen auf normalem schwarzweiss Videomonitor. Womit er ein besserer PCW 8256 gewesen wäre. Oder gar auf 512x256 1bpp (oder 640x200 1bpp) reduzieren, ohne "Contention".

Weitere Aussagen berichten von anfangs zwei separate Projekten, Nachfolger vom Spectrum sowie dem Businessrechner, welche dann wegen fast gleicher Spezifikation zusammengelegt wurden, sinnvollerweise. Aber die waren vermutlich genau in allem gleich ausser bei Video, was richtigerweise zu einem beide Nutzungen abdeckenden 2-Modi Design führte. Aber das wurde beim zusammenlegen verborkst, wie wenn jemand die Spieleanforderung "keine Attribute" auch unnötig auf die Business Seite angewandt hatte, daher dort unpassendes 2bpp machte, dabei Blinken verlor, dieses statt weglassen noch irgendwo unterbringen wollte, es auf die Spiele Seite verschob, daher dort unpassendes 3bpp+blink machte, die angezielten Farben verlor, so beide Modi verbockte. Resultat war zuviel für Businessrechner aber zuwenig für Nachfolger vom Spectrum, trotz zwei Modi genau dafür!

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 und 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 1bis4 Sätze zu je 4* 8bit Bänke, von je 4 Paaren 16kx4bit DRAM Chips, erster Satz auf der 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 hat, weshalb IBM solche Chips selber herstellen kann. Verwendet einen zwischen MDA und CGA kompatibel umschaltbaren Adressbereich (A000:xxxx) von Bildspeicher und Steuerregister (03Cx und entweder 03Bx oder 03Dx), 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 ihre 9x14). Braucht dazu einen separaten EGA Spezialmonitor, analog zu bei MDA. Würde auch damit hier auscheiden, wenn nicht bereits an der Speichermenge. Aus RAM Satz, von 256 Zeichen (mit schaltbar so dass Attribut Bit3 für 2* 256 geht, mit dann aber nur noch je 8 Farben). Weiter gab es einen 80x43 Zeichen Modus, mit dabei dem alten 8x8 CGA Font nutzen.

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 dazu inkompatibel). Davon aber (1oder4)*28k nutzend (bzw einen solchen Ausschnitt aus bis zu (1oder4)*64k an Bilddaten). Daher auch angeordnet zu vier 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 die 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 den vieren 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 die spezifizierte 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 beliebige 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 Farbe 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 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 bei 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. Weiter wurde fein scrollen addiert, horizontal nach links mit Pixel verzögern, vertikal nach oben mit Font obere Zeilen auslassen (wie Atari 800). Zudem kann man mit einem Offset Register nach Ende jeder Videozeile weitere Bytes überspringen, um einen horizontalen Ausschnitt aus einem breiteren Videospeicher anzuzeigen. Weiter mit einem Zeilenvergleichsregister zum anfang vom Videospeicher springen, für grob scrollen ohne umkopieren, zusammen mit den Bildanfang nicht auf Speicheranfang setzen.

(Erweiterte Super-EGA Klone 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 festen 4 Bitplanes ihre 4bpp Limite verhinderte noch auf diesen ein 320x200 8bpp machen, oder gar mit ausreichend Bandbreite sogar 640x400 8bpp mit dieser 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. Weiter 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. Dies erst noch mit Chunks statt Bitplanes, weil als Verdoppelung der PCjr 32k 4bpp designt, die schon eine verdoppelte CGA 16k 2bpp war, alle mit Chunks. Aber kein 640x400 8bpp, trotz dass dies noch in die 256k Speicher passen würde. In diesem Modus 256 aus 262144 analog 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 den RAMDAC losgelassen. Wieder nur mit externem VGA analog RGB oder Multisync Spezialmonitor, dem ersten Monitor mit dem HD15 VGA Stecker.)

(Erweiterte Super-VGA Klone konnten mit 256k Speicher bis zu 640x400 8bpp (und 800x600 4bpp). Oder gar mit 512k Speicher 640x480 8bpp oder sogar mit genug Bandbreite bis zu 800x600 8bpp (und 1024x768 4bpp). Die 1024x768 4bpp brauchen aber mehr als die 4*64k Adressraum, benutzen zumeist einfach 4*128k, mit Segmentregister zeilenweise umsetzen. Deswegen gehen bis zu 800x600 4bpp mit einer MDA oder HGC, aber 1024x768 4bpp nicht mehr. Bereits alle oberhalb 320x200 8bpp Chunks können aber keine vier Bitplane Logik nutzen für mehr als 64k Adressen, brauchen eine von IBM mangels 640x400 8bpp in der VGA nicht vorgegebene Adresserweiterung, und wurden daher zu einander inkompatibel! Daher kann auch 320x200 8bpp zusammen mit MDA oder HGC als Dualhead laufen, aber je nach Karte ihre Erweiterung ist darüber stets machbar oder stets nicht oder je nach Auflösung. All die Einstellungen wenigstens etwas standardisieren resultierte in der Video Electronics Standards Association (VESA). 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 weit später kamen "True-Color" 3*8=24bpp direkt. Neben Beschleuniger wurde auch schnellerer Zugriffe auf Karten verbessert, mit VESA zuerst eine den ISA Bus voll ausnutzende lineare 24bit 286 Protected Mode Adressierung des ganzen Videospeichers definieren, und danach sogar eine 32bit 33/40/50MHz Erweiterung vom ISA Bus namens VESA Local Bus (VLB) erzeugen, der selbst lineare 32bit 386/486 Adressierung erlaubte. Das war die letzte Evolutionsstufe des "klassischen" vor-PCI/AGP+USB+Windows95 PCs. Von letzteren stammen dann alle modernen Videokarten ab. Dabei "dank" Windows Treiber statt Hardware Register die Inkompatibilität immer schlimmer werdend. Zudem ab PCI und USB wegen undurchsichtigen Plug&Play Automatismen, bzw wenn es nur zu oft versagte auch als Plug&Pray bezeichnet, immer unvorhersehbarer und unkorrigierbarer werdend.)

Atari ST (1985)

Stammt eigentlich von Tramel Technology, der neuen Firma vom Commodore Gründer und Präsidenten Jack Tramiel, nachdem er dort wegging wegen massivem Krach mit dem Hauptinvestor. Tramiel als Unternehmer wollte in bessere Produkte expandieren, mit für Kapital dazu mehr Aktien ausgeben und schuldenfrei werden, aber Hauptinvestor als Kapitalist wollte den Wert seiner Aktien nicht reduzieren, mit daher lieber mehr Kreditschulden machen. Zudem wollte Tramiel als Patriarch seine nun ausgelehrten Söhne in Positionen bringen, aber der Hauptinvestor misstraute Tramiel nach den Verlusten von dessen Preiskrieg mit Texas Instruments in 1983, wollte daher "professionelles" Management einstellen, blockte die Söhne. Es krachte und Tramiel ging Jan 1984 in den Ruhestand. Nach 2.5 Monaten reisen wurde es ihm langweilig. Dazu gefiel ihm die sich anbahnende Hochpreisfokus Entwicklung in der Branche nicht, er zieht Niedrigpreis und Umsatzmenge vor, "für die Massen, nicht die Klassen". Also hat er nach 4 Monaten Tramel Technology gegründet, damit solche Angebote weiterhin angeboten bleiben. Strikte haben seine Söhne die Firma betrieben, er war deren interner Berater. Im Mai 1984 sind bei Commodore etwa 35 Kernmitarbeiter in nur einer Woche gegangen, weil sie mit dem neuen Kurs unzufrieden waren, und einige davon sind zu Tramiel gestossen, inklusive dem 16bit Projektteam um Shiraz Shivji. Das neue "professionelle" Management hat nicht mal sie zu bleiben überreden versucht, trotz dem massiven Verlust an Knowhow! Diverse "professionelle" Manager haben danach Commodore in 10 Jahre in den Konkurs gewirtschaftet. Das auch weil der Hauptinvestor jeden absetzte, der kompetent genug war um etwas aufzubauen, nur eine "spare an der Entwicklung und plündere die Firma zutode" Politik zuliess. Womit er den ganzen Wert aller Aktien vernichtete. Im Juni 1984 hat Tramiel die beinahe konkursite Atari Konsolen und Homecomputer Abteilung gekauft (der zweite beim Atari 65XE/130XE erwänhte Aufkauf) und ausgeschlachtet für Mitarbeiter und Ausrüstung. Hat dabei auch seine Firma in Atari Corporation umbenannt, um den etablierten Namen zu nutzen, trotz nicht die bei Warner Brothers verbliebene Spielautomaten Abteilung zu sein, die in Atari Games umbenannt wurde. Seither gibt es zwei Firmen namens Atari! Trotz mit Namen Atari ist der ST damit eigentlich der ideelle Nachfolger vom Commodore 64. (Oder mangels dessen Sprites eher von den TED Rechnern, oder wegen seinem Timing noch eher von den PET/CBM.)

Ist damit 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). Mit Bild aus dem normalen DRAM Hauptspeicher. Hatte damals riesigen 512k Speicher im ersten Modell 520ST, 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". Ebenso ohne die Sprites. Selbiger 68000 Prozessor wie der Macintosh, aber wegen reinem RGB Video und kein Quarz mit RS232 teilen mit vollen 8MHz laufend. Dank den neueren 4MHz 256kbit DRAM Chips auch ganz ohne dem Macintosh seinen halben "Bad Lines", abgesehen von 6-Takt Zugriffe auf 8 ausdehnen, was aber wegen ohnehin zumeist 4-Takt weit unter 10% kostet (wie CPC). Damit war der ST der schnellste aller 16bit Homecomputer! (Der erweiterte 1040ST (1986) war dann auch der erste Rechner mit 1MByte unter $1000, und wie es die Presse bemerkte auch der erste mit soviel unter $3000!)

Basiert auf vier Customchips, MMU DRAM Speicher Adressen/Steuersignale Generator, sowie Shifter Video Pixel/Farben Ausgabe, und Glue Timing/Adressdecoder/Synchronisation, plus noch DMA ACSI (SCSI-artig) Bus zu Harddisk (und auch zum Floppycontroller). Hat für Audio (und Drucker) einen YM2149F Soundchip (ein Nachbau des AY-3-8910), plus RS232 und Interrupts einen 68901 MFP, plus Tastatur/Maus/Joysticks sowie MIDI 2* 6850 ACIA. Damit ein einfacher geradliniger Rechner, der in nur etwa 1 Jahr von Entwurf bis in den Verkauf sein ging!

Er hat umschaltbar 3 Bitmapmodi, aber welche davon benutzbar sind ist abhängig vom Monitortyp (der dies via einem Pin des Videosteckers an einem Bit des MFP 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 LISA 720x364 und HGC 720x348 in 32k). Mit 32MHz Pixeltakt, 31.5kHz Zeilen (wie VGA), 72Hz Bilder (sehr hoch, mehr als VGA 70Hz, gibt bockstabiles flimmerfreies Bild). Würde mit nur Spezialmonitor auscheiden, aber hat weiter unten auch normalen Video Monitor. Wie Macintosh nicht mal 2bpp Graustufen, auch nicht optional. Dies trotz dass der Shifter es eigentlich könnte, mit dann 320x400 erzeugen, aber der Monitor kann es nicht, weil mit nur 1bit digital Videosignal angesteuert, unterhalb des MDA seinen 3 Graustufen mit "1.5bpp". Also ist wieder mit Schwarzweiss rastern (wie Macintosh). Mit umschaltbar normalem 0=schwarz und 1=weiss (als revers bezeichnet), oder eigenartigem 0=weiss und 1=schwarz (wie Macintosh, als normal bezeichnet). Erlaubt 80x25 Zeichen vom 8x16 100dpi Font. Minus dem GUI Platzverlust sind das 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 womit sogar mehrere 80x25 Fenster erst sinnvoll sein würden. Aber die Systemsoftware hat keinen solchen Font drin. Es hat noch einen 6x6 für die Icon Unterschriften.

Alles in allem somit ein besserer Macintosh, der prompt als Spitzname Jackintosh genannt wurde. (Wobei er von Pixelmenge und Monitorplatz und Tastaturumfang und Harddiskanschluss her weit näher bei LISA ist.) All das aus einem einfachen simplen auf billig gebauten Rechner (Projektname war RBP, Rock Bottom Price). Es gab sogar zwei Module für dem ST seinen 128k Modulsteckplatz, The Magic Sac von Data Pacific und Spectre 128 von Gadgets by Small, mit eigenen ROMs für ST spezifische Treibersoftware vom ihnen, sowie Sockel für 2*32k Mac ROMs, offiziell von einem toten oder aufgegebenen Mac 128k zu entnehmen (oder real eher von einem lebenden zu kopieren). Diese verwandelten einen schwarzweissen ST in einen weit billigeren aber zugleich besseren 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 Macintosh-artigen Floppy Controller gelöst wurde. (Diesen Ansatz hätte auch der anfängliche Macintosh Projektleiter nach dem Untergang vom Canon Cat benutzen können. Einfach analog zur SwyftCard für Apple IIe ein CatModule für Atari ST machen. Oder gar gleich anstelle vom Canon Cat nur dieses. Er wäre damit schneller auf den Markt gekommen, und mit einem Hardwarehersteller dahinter, der den ST als sein zentrales Produkt millionenfach verbreitete.)

Mit dem 12" analog RGB Monitor SC1224 (vergleichbar BCC und CPC ihren) (oder SCART Fernseher) sind es dann umschaltbar 640x200 2bpp in 32k (und das kann auch mit 2bpp Graustufen sein) oder 320x200 4bpp in 32k (aber das kann kein 4bpp Grau mehr sein, weil nur 8 Stufen an RGB Farbtiefe im Shifter Chip). Dies mit 4oder16 Farben aus 512 RGB. Mit 16MHz Pixeltakt, 15.75 kHz Zeilen (NTSC Fernseher), 50Hz (PAL) oder 60Hz (NTSC) Bilder. STM und STFM Modelle (M = Modulator) können auch einen normalen Fernseher benutzen (STF und STFM sind mit F = Floppy und Netzteil eingebaut). Ist damit ziemlich genau ein in allem verdoppelter CPC, aber kein vierfacher CPC für parallel zu einem vierfachem C64 sein. Ebenso verdoppelte CGA 16k Bitmapmodi, und sogar genau die PCjr und ColorPlus 32k Modi, aber mit 512 statt 16 Farben. Es sind ebenso gleiche 2oder4bpp wie QL 32k, aber wegen Farbregister ohne dessen Limite auf feste 4 Farben bei 2bpp, und ohne blinken 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 Font benutzbar, weil das mit 200 statt 400 Zeilen zu einem schwer lesbaren 6x6 Font füren würde! Der 8x8 ist zudem ein 6von8Pixel Font (wie Atari 800 und C64), damit er 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 im einem ansonsten linearen Bildspeicher (wie QL bei 2bpp, nur hier auch bei 4bpp ohne gemischte Pseudobitplanes+Chunks). Es ist somit ebenfalls resistent gegen "Ghosting" beim scrollen, ohne den Aufwand von vier Bänken an separatem Bildspeicher und dem EGA Pixelprozessor. Es ist aber weiterhin mühsam zu nutzen, oder gar wegen der/den anderen Bitplanes ihre Worte überspringen noch etwas mühsamer. Ausser man verzahnt die 2oder4 Rechenlogiken welche bei Bitplanes in 2oder4 Schleifen kommen würden, was aber immer noch die 16 4bit Farbnummer Kombinationen von nur Datenmustern zu Codesequenzen macht, und damit inflexibel und mühsam. Zudem ist es schlicht langsamer. Dies alles wird auch als "woven layout" (= gewobene Anordnung) bezeichnet, und damit umgehen als "woven hell" (= gewobene Hölle). (Schuld daran war scheints, die Implementation vom GEM Treiber zu vereinfachen, der auf Mac-artigen 1bpp Pixelmuster und separaten Farbcodes basierte.)

Das Bild kommt aus einem Speicherblock, der vom Speicher/Adressen Chip in 256Byte Schritten angeordnet werden kann, und vom System jeweils auf das je nach Speichergrösse variable Ende von diesem gesetzt wird. Hat zwar wegen je nach Modus passende 80 oder 160 Bytes pro Zeile, keine 2^n um einfach die X und Y Koordinaten als Adresse zusammenlegen. Verwendet daher einen simplen separaten Adresszähler (wie PET/CBM). Hat dabei keine Zeichenmodus Zeilenwiederholungen, auch keine MC6845 Limiten, und keine Farbzellen Limiten. Er kann damit rein linearen Bildspeicher benutzen (wie Macintosh). Dies macht Bild vertikal fein scrollen sowie Objekte vertikal anordnen oder verschieben trivial.

Die aktuelle Videoadresse (aber nicht die Videozeile) ist auslesbar, weil Adressen im MMU Chip sind (der 8bit Datenbus hat um Adressen in 3*8bit zu setzen lesen) aber Zeilentiming im Glue Chip ist (der nur 2bit Datenbus hat um (Timing-)Modi zu setzen). Es hat daher auch keinen Rasterinterrupt, was aber mit vertikalen Rücklauf Interrupt und davon MFP Timerinterrupt setzen kompensierbar ist, wenn auch mit etwas Aufwand. (Strikte kann er auch horizontal Rücklauf Interrupt, auf jeder Zeile, aber der verheizt massiv Prozessorleistung, mit einem Interrupt alle 508 Taktzyklen.) Man kann damit Farben zeilenweise ersetzen für mehr als 4 oder 16 von 512, inklusive Farbe 0 = Randfarbe vom Overscanbereich, um die Hintergrundfarbe als Bänder bis in den Rand hinauszuziehen. Es hat ansonsten keinen echten Overscan. 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 64k der MCGA in der Einleitung nur noch Faktor 2 entfernt.

Keine Sprites, und damit eben kein vierfacher C64. Kann dies wieder mit den 4bpp kompensieren (wie BBC und CPC), ist damit aber bloss ein verdoppelter CPC, was den CPC Ansatz von fehlenden Sprites mit doppelter Speichermenge und bpp des C64 kompensieren verhindert. Weshalb er eher bloss ein vierfacher Apple II Plus ist. (Damit ist er auch das was Apple an Videomenge beim Macintosh hätte liefern sollen, und das erst noch ohne dessen halben "Bad Lines". Ebenso das was sie bei LISA geliefert haben.)

Das einzige was vom C64 wirklich schmerzhaft fehlt ist horizontales fein scrollen (vertikal fein scrollen ist bei rein linearem Bitmap eh trivial). Auf dem ersten Blick wären bei 320@4bpp ganze 16bit Worte nur 4 Pixel, und so mit schnellem nur Worte umkopieren (die 68000 kann bei Wort/Langwort Speicherzugriffen keine Byteadressen nutzen!) 80 Positionen horizontal machbar (wie CPC), und mit etwas langsameren Byte Speicherzugriffen sogar 160, was dieses fehlen grossteils mit grob scrollen kompensieren könnte.

Aber die Pseudobitplanes resultieren in 1 Wortgruppe stets 16 Pixel sein, womit bei 320 Pixel nur noch 20 Positionen horizontal sind, bzw selbst mit Byte Speicherzugriffen erst 40. Bild pixelweise horizontal scrollen braucht also sehr langsame Rotationsoperationen, sowie ist dank den Pseudobitplanes auch noch aufwendig (in 4-Wort Schritten 4 mal durch jede Zeile hindurch). Weshalb Horizontalscroller für 80 oder 160 oder gar 320 Positionen scrollen wegen flüssiger Bewegung mit zwei Bildspeicher und jeweils im inaktiven ganzes Bild neu aufbauen arbeiten müssen. Was als Doublebuffering bekannt ist. Dazu braucht es aber 4 oder 8 oder gar 16 Kopien von vorgeshifteten Elementen um sie schnell einzukopieren. Was massiv Speicher und Prozessor verheizt, wenn auch viel Speicher vorhanden ist, und mehrere Bildlaufzeiten pro Neubild aufbauen an Prozessor erlaubt sind (aber zuviele ruckeln dann). Dabei kann man auch gleich Objekte ohne Sprites ins Bild hineinrendern. Was als Compositing bekannt ist. Das wird aber durch den verbleibenden Resten an Prozessor limitiert. Zudem ist es auch noch wegen den Pseudobitplanes ineffizient, weil sie zeichnen von horizontal schmalen Elementen und Objekten ausbremsen, um Faktor 2oder4, weil mit n* 2oder4Wort = 16Pixel statt mit n* 1Wort = 8oder4Pixel breiten Streifen arbeitend.

Was weiter vom C64 fehlt, ist dass mehr als 320 Pixel nur mit Reduktion auf 2bpp machbar sind. Nett wäre 640 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 besser beide Varianten zur Auswahl. Diese Verbesserung wäre mit nur dem Shifter Chip leicht erweitern machbar gewesen! Auch Farbmodi mit Chunks statt Pseudobitplanes wären nur eine leichte Erweiterung im selbigen. Selbiges fein scrollen. Ebenso 4oder16 Farben aus 4096 RGB, wenn auch letzteres nur mit Pinout vom Chip erweitern machbar.

(Der Nachfahre MegaST (1987) addierte einen bereits anfangs geplanten aber aus Zeitmangel nicht umgesetzten Blitter, um Objekte ohne Sprites ins Bild hineinzurendern durch wortweise umzukopieren inklusive shiften. Was den Prozessorverbrauch der Pseudobitplanes reduzierte. Aber dieser Blitter ist schwächer als dem Amiga seinem, weil die Spezifikation nicht in der Zwischenzeit verbessert wurde. Allerdings war der MegaST ohnehin auf den Büromarkt ausgerichtet, wo dieser Blitter ausreichte, um in GEM proportionale Fonts beliebig positionieren zu beschleunigen in DTP und CAD Anwendungen auf schwarzweiss Monitor. Spieler blieben beim normalen ST und damit ohne Blitter. (Namensgebend sind die 1MBit DRAM Chips, 16 in MegaST2 und 2*16=32 in MegaST4, statt bisher 256kbit, 16 in 520ST und 2*16=32 in 1040ST. Der nachgeschobene MEGA1 musste von 1024kx1 auf 256kx4 Chips wechseln, damit nur 2*4=8 davon ausreichend breit sind.))

(Der Nachfahre STE (1989) erweiterte auf 4oder16 Farben aus 4096 RGB. Als wichtigstes konnte er aber endlich pixelweise horizontal fein scrollen, statt das ganze Bild sehr langsam bitweise zu shiften, oder eher mit Doublebuffering es immer wieder neu aufzubauen. Er konnte auch die Speicheranfangsadresse wortweise setzen, sowie die aktuell ausgegebene Videoadresse nicht nur in Software lesen um Bildsynchron den Farbsatz anzupassen, sondern auch umschalten für Zeilenblöcke in beliebiger nichtlinearer Reihenfolge anzeigen, inklusive damit grob scrollen mit einen zirkulären Bildspeicher rollen statt umkopieren. Ebenfalls war der Blitter vorhanden, aber weiterhin ohne verbesserte Spezifikation. Es fehlen aber nachwievor jegliche Chunks. Weiter addierte er per DMA ausgegebenes PCM (Samples) Audio. (Speicher sind nun Paare von SIMMs mit je 8 DRAMs (zu wahlweise 256KByte oder 1024kByte), 1 oder 2 davon (für 256k oder 512k bzw 1M oder 4M, kein 2.5M) (wie Mac Plus).))

(Ganz ausser Konkurrenz kamen beim 32bit Nachfahren Atari TT (1990) weitere vierfache 128k Videomodi (genauer waren es wegen noch etwas mehr Zeilen 150k), Schwarzweiss 1280x960 1bpp sowie Farben 640x480 4bpp (und 320x200 8bpp in nur 64k), mit beide letzteren sogar VGA kompatibel, mitsammt dem HD15 Stecker benutzen. Es wird nun in kompatibles "ST RAM" mit Bildspeicher und Disk DMA sowie "TT RAM" für maximale Geschwindigkeit aufgeteilt, womit das "ST RAM" zu separatem Bildspeicher aus DRAM wird. Der Blitter wurde wieder weggelassen, weil der alte 16bit Blitter bei weit schnellerem 32bit Prozessor eher Programme gebremst hätte, und sie keinen inkompatiblen 32bit Blitter entwickeln wollten! Kompatibel bleiben mit den wenigen Programmen welche ihn direkt nutzten war nicht genug relevant.)

(Im Falcon 030 (1992) wurden es sogar 640x480 16bpp, und die 2/4/8bpp Modi konnten 4/16/256 aus 262144 RGB wie VGA. Dies erst noch trotz wieder Bild aus dem normalen DRAM Hauptspeicher, und dieser zudem nur 16bit breit, mit auch den Prozessor Pagemode Doppelzugriffe benutzen. Der 16bit Blitter ist wieder vorhanden, nur wegen kompatibel sein.)

Commodore Amiga (1985)

Stammt eigentlich von Hi-Toro (später in Amiga umbenamst), die neue Firma einiger ex-Atari Leute, nach bei Atari weggegangen, wegen keine Nennung und Beteiligung, sowie dem Erfolgsboni Betrug. Mit dabei war der VCS/2600 und Atari 800 Chipdesigner Jay Miner, weggegangen nach der Ablehnung seines 68000 basierten Nachfolgeprojektes. Wie beim 800 eine Spielkonsole welche zu einem Homecomputer erweitert wurde, wobei das diesmal von anfang an so eingeplant war. Bekamen später einen Finanzschubs durch Atari, welche den Chipsatz im geplanten 1850XLD nutzen wollten, dazu Amiga so am Leben hielten, aber dann wegen Atari ihrem Firmenzustand die Verhandlungen nicht hinbekamen. Nach dem Weggang von Jack Tramiel bei Commodore hat er Atari aufgekauft, und nach entdecken derer Verhandlungen mit Amiga ein weit unzureichendes Angebot gemacht. Inzwischen hatte Amiga andere Geldquellen gesucht, und wurde dabei von Commodore aufgekauft, welche dann Atari ihren "Kredit" auszahlten. Weshalb Tramel Technology den "Atari" Chipsatz verloren, trotz Atari Corporation werden. Wonach sie ihr eigenes, bereits vor vom Amiga erfahren vom 16bit Projektteam mitgebrachtes, "Commodore" Design als Atari ST herausbrachten. Während Commodore das aufgekaufte "Atari" Design als Commodore Amiga herausbrachte. Also total verdrehte Welt! Trotz mit Namen Commodore ist der Amiga eigentlich der direkte Nachfolger vom Atari 800.

Ist damit ein Atari 800 mit doppelter Speicherbreite (von 8bit auf 16bit), und doppeltem Speichertakt (von 1.79MHz auf 3.5796MHz), das ergibt auch vierfache Speicherbandbreite. Mit Bild aus dem normalen DRAM Hauptspeicher. Hatte 256k davon im ersten Modell A1000, konnte weitere 256k in einem Modul addieren. Wieder daher den Featuresatz abgebaut/vereinfacht, nur noch Bitmapmodi, keine Zellmodi mehr. Kann aber sogar mehr als vierfachen Bildspeicher (von variable 1/8..8k Bitmap auf variable 8..64 NTSC bzw 10.25..82k PAL). Dank 4MHz 256kbit Speicherchips kann er bis 32k NTSC bzw 41k PAL ohne den Prozessor anhalten (wie ST). Aber mehr als das geht auf Kosten vom Prozessor ausbremsen. Alle Zeilen werden erst dabei zu teilweisen "Bad Lines" (wie Macintosh), aber mit variabler Menge an "Bad", mit (1..4)*12% an Leistung verlieren.

Ausser es wird neben dem "ChipRAM" (unterste 2MByte Adressen) auch ein "FastRAM" (nächste 8MByte Adressen) addiert, also DRAM auf welches Video (und auch 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 bei allen PC Videokarten und ZX Spectrum). Amiga 1000 und Amiga 2000A konnten maximal 512 "ChipRAM", Amiga 500 und 2000B maximal 1024k. Amiga 2000A hat daher noch 512k "FastRAM" im "MMU" Slot. A2500 hat sogar in diesem Slot Prozessorkarten mit 32bit (A2500/20 mit A2620 hat 68020 und 14.2MHz, A2500/30 mit A2630 hat 68030 und 25MHz) sowie passend breitem eigenem "FastRAM", mit abbremsen auf 16bit und normalem Takt nur für aufs "ChipRAM" losgehen.

Basiert wie Atari 800 auf drei Customchips: Agnus (Address GeNerator UnitS) Speicher+Adressen Controller+Generator (entspricht dem ANTIC), sowie Denise (Display ENabler) Videodaten+Pixel und Maus+Joysticks (entspricht dem GTIA), sowie Paula (Ports Audio Uart Logic) Paddles und Audio und Teil-UART und Teil-Floppy (entspricht dem POKEY). Die Rest-UART und Rest-Floppy sowie Tastatur und Drucker werden durch 2* 8520 CIA abgehandelt (entspricht dem 1* 6520 PIA).

(Diese Customchips haben massive Mengen an Logik darin. Beim in TTL Chips gebaute Prototyp "Lorraine", zwecks Logik verifizieren bevor Customchips hergestellt wurden, bestehen Agnus+Denise+Paula aus 8+5+3=16 Platinen, mit je 5 Felder zu je 5x5=25 mal 20pin Chipsockeln, also 16*125 = 2000 Sockel an Platz. Diese wurden zu etwa 90% gefüllt, also entsprechen sie etwa 900+550+350 = 1800 an TTLs! Dazu kommt noch die Grundplatine mit Prozessor und DRAM und EPROM und Gluelogik. Das ist das 30..100-fache der meisten 1970er Rechner ihren jeweils etwa 50 TTLs. Mit TTL Chips im Bereich 10..100 Transistoren, 30 im Schnitt, haben sie somit etwa 27000+16500+10500 = 54000 Transistoren in sich, fast 50% mehr als die 38000 Transistoren im 68000 Prozessor! Der Amiga brauchte dazu mehrere Jahre Designzeit, und mittlere 2-stellig $-Millionen an Budget. Er kostete aber trotzdem einiges weniger als der weit einfachere Macintosh.) (Der Atari ST Prototyp hat im Vergleich nur 1+1+1=3 Platinen, etwa 130 TTLs Shifter, etwa 70 TTLs MMU mit dem DRAM hinten drauf, etwa 60 TTLs DMA/ACSI, sowie Grundplatine mit Prozessor und EPROM und Glue nur wenige TTLs, zusammen unter 300 TLLs statt 1800, sowie unter 1 Jahr Designzeit. Er kostete nicht überraschend einiges weniger als der Amiga.) (Nochmals weit einfacher ist dem Macintosh seine einzelne Platine, trotz ohne Customchips, mit nur 6 PALs und 15 TTLs, entsprechend etwa 50 TTLs. Er war trotzdem teurer als der Amiga.)

Ebenfalls wegen Nachfolger vom Atari 800 mit NTSC 14.31818/16*8=7.1591MHz bzw PAL 17.734472/20*8=7.0938MHz 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 Timing 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 gewesen, weil PAL ohnehin keine exakten Wellen bekommt (wie Atari 800), womit NTSC /14*8=8.1816MHz bzw PAL /18*8=7.880MHz besser wären (wie Commodore 64).

Er hat umschaltbar 4+6=10 Bitmapmodi, aus 16bit Speicher mit 640x200 NTSC bzw 640x256 PAL in 1..4bpp (gibt 16..64k bzw 20.5..82k) (3bpp bremst 24% Prozessor, 4bpp gar 48%), oder mit 320x200 NTSC bzw 320x256 PAL in 1..6bpp (gibt 8..48k bzw 10.25..61.5k) (5bpp bremst 12% Prozessor, 6bpp gar 24%). 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 schwer lesbarem 6x6 Font füren würden (wie Atari ST mit RGB Monitor). Wieder ist es ein 6von8Pixel Font (wie Atari 800 und Commodore 64 und Atari ST), damit er auch auf Fernseher gut benutzbar ist.

(Strikte hat es noch, wegen 14.31818MHz Pixeltakt, bei nur 1bpp 640x200 in schwarzweiss auf NTSC den zu erwartenden 160x200 pseudo-4bpp Modus, identisch mit CGA. Oder gar bei nur 1bpp 320x200 in schwarzweiss auf NTSC den zu erwartenden 160x200 pseudo-2bpp Modus, identisch mit Atari 800. Aber nur sofern man einen NTSC Farbfernseher oder Farbmonitor benutzt. Dies ist mit dem häufig verwendeten RGB Monitor nicht mehr benutzbar (wie CGA), ebenso nicht auf PAL Farbfernseher oder Farbmonitor. Aber diese Wirkung berücksichtigen führte zu der Schwarz/Weiss/Blau/Orange Farbkombination vom GUI Desktop, genau passend zu den 4 Farben von 7.1591MHz Pixeltakt auf NTSC.)

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 dann mit über 44.7µs breit in den Bildrand hinausgehend. Kann bei NTSC etwas mehr horizontal wegen leicht mehr Prozessortakt. Kann als einzigen Rechner hier auf einen PAL Monitor/Fernseher volles vertikales Overscan. Kann weiterhin bei all diesem doppelte Zeilenzahl anzeigen mit interlaced. Hat aber keine setzbare Randfarbe, muss dies mit Overscan machen.

Ausschliesslich auf einem Fernseher oder Videomonitor oder RGB Monitor (oder SCART Fernseher). Daher keine mehr als 242bzw288 Zeilen Spezialmonitor Option, weil wie Atari 800 anfangs als Spielkonsole designt und dann zum Homecomputer erweitert. Hat davon fein scrollen horiontal und auch vertikal (trotz dass letzteres bei reinem Bitmap eigentlich überflüssig ist!). Kann dazu auch Anfangsadresse beliebig setzen, um Bildausschnitte anzuzeigen. Kann weiter nach Ende jeder Videozeile ein Modulo Register zu den Videoadressen addieren, um weitere Bytes zu überspringen, um einen horizontalen Ausschnitt aus einem breiteren Videospeicher anzuzeigen (wie EGA Offset).

Mit echten Bitplanes (wie KC 85/4 2bpp und EGA 4bpp), statt den Chunks vom Atari 800 und Commodore 64, oder den Pseudobitplanes vom QL und ST. Mit wieder gleichem Font bei variablen bpp. Kann zudem beliebig 1..6bpp je nach Bedarf, weil weder an Anzahl Chunks pro Wort gebunden (wie Atari 800 und Commodore 64), noch an Anzahl Hardware Bitplanes (wie KC 85/4 und EGA), noch an Pseudobitplane Wortserien (wie QL und ST). Aber dadurch auch massiv anfällig auf "Ghosting" (wie KC 85/4), zumal ohne jegliche Synchronisierung durch einen Pixelprozessor (wie EGA einen hat, und Hi-Toro anfangs es in Betracht gezogen hatten, aber doch wegliessen). Ist auch hier logischerweise mühsam zu benutzen. Jay Miner hat in einem Interview ausgesagt, er bedaure den Designentscheid zu Bitplanes mehr als jeden anderen in seinem ganzen Leben!

Strikte kann man obiges Modulo Register einsetzen um die Bitplanes zeilenweise verzahnt im Speicher anzuordnen, alle Planes von einer Zeile, dann erst alle von der nächsten Zeile, durch mit Modulo die anderen Planes ihre Zeilendaten überspringen. Womit zumindest Ghosting reduziert wird, auf praktisch wie bei Pseudobitplanes. Aber es bleibt mühsam, wenn auch leicht weniger so als bei den "gewobenen" Pseudobitplanes vom ST oder gar QL die anderen Sorten Bytes überspringen. Allerdings wurde dies nicht im Programmierhandbuch erwähnt, und auch nicht von der Systemsoftware ihrer "Alloziere Bildspeicher" Funktion angeboten. Weshalb es vielen Programmierern unbekannt war, und selbst die welche es kannten zu System umgehen zwang. Weshalb viele Programme es nicht nutzen, was dem Amiga seinen Ruf wegen "Ghosting" einbrachte.

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 Scrollmenge oder Farbsatz oder Spritespositionen. 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. Alles wie im Atari 800, aber 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 verknüpfen (einer ist üblicherweise der Zielausschnitt, muss aber nicht sein).

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. Es hat einen Linien zeichnen und darauf aufbauenden Polygone füllen Modus, um direkt Objekte zu zeichnen oder Schablonen zu erzeugen. (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", wenn auch 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 geschieht 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 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+STE 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 Bitplanes 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 codiert ist, was der grosse Speicher problemlos erlaubt.)

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 verzahnt anzuordnen. Oft ist es sinnvoller, einfach mit Copper alle Zeilengruppen ihre Reihenfolge der Anzeige umzuordnen, wie es bereits im Atari 800 mit der Displayliste machbar war!

Alternativ wird der Blitter zusammen mit 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, dies erst noch 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 ist der Blitter 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 Elemente. Beide müssen sogar mangels jeglicher Sprites so genutzt werden.)

Dazu Sprites, 8 16xN 2bpp als Pseudobitplanes (2*16bit pro Zeile). Sie sind horizontal nur im halbierten Raster (wie Atari 800, 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 das sind auch nicht viel mehr als die 8*3 Bytes/Zeile vom Commodore 64. Und viel Overscan reduziert die Anzahl Sprites auch noch! (Gerade bei vielen kleinen Objekten muss man daher doch zu Compositing greifen. Nur ist der Blitter gerade bei kleinen Objekten langsam, wegen Aufstartzeit. Also muss man doch auf dem Prozessor arbeiten, und wird dabei vom gebremsten 7/8 Prozessortakt getroffen.)

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 Commodpre 64 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 können 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. Dies wird 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 nutzen. 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 im zweiten Playfield 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), dies sogar ohne Sprite Grössenlimiten der Objekte von nur im horizontalen Rücklauf laden her (was Compositing aber auch kann).

Mit Farben je nach 1bis5bpp als 2bis32 aus 4096 RGB. Dazu noch mit 6bpp entweder Extra Half Bright (EHB) 2*32 (32vollhelle+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 320er Auflösung, weil 01BBBB und 10RRRR und 11GGGG ersetzen jeweils einen der RGB Komponenten, womit erst eine Serie von allen drei beliebige Farben erzeugt, aber vorzu wird jedesmal die Helligkeit (teil-)modifiziert). Einige der enorm guten fast photorealistischen Bilder welche dem Amiga seinen Ruf aufbauten wurden in dem HAM Modus erzeugt. Aber auch einige "nur" im 5bit 32 Farben Modus (inklusive alles mit DeluxePaint I bis III gezeichnete!). Weiter war HAM praktisch nur in statischen Bildern nutzbar, weil für Spiele sobald horizontal scrollend problematisch.

Sprites nutzen paarweise die Farben, mit 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. Sie nutzen dann alle Farben 17..31. Mit Sprites sind daher nur 4 Bitplanes mit Farben 0..15 für den Hintergrubd sinnvoll. Nur bremsende 5 Bitplanes falls man die Spritefarben doppelt ausnutzen will. Sprite Farben werden bei mehrfach verwenden nicht neu geladen, sie können aber per Copper mit Farbregister beschreiben geändert werden.

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 in Hardware auf max 6bpp limitiert sind (analog zu EGA ihre max 4bpp), wenn auch nur wegen der Registerzahl (während in der EGA schon wegen der 32bit Busverdrahtung der 4*8bit Bänke).

(Der Nachfahre Enhanced Chip Set (ECS) der 16bit Rechner Amiga 2000C bzw Amiga 2000 Plus und Amiga 3000 (1990) sowie A500 Plus (1991) und Amiga 600 (1992) konnte weitere Videomodi. Er erlaubt doppelbreite "SuperHires" 1280200 NTSC bzw 1280256 PAL (sowie mit Interlace doppelte Zeilenzahl), plus mit verdoppelter Horizontalfrequenz doppelhohe "Productivity" 640480 (bereits ohne Interlace). Dazu waren nun bis zu volle 2MByte "ChipRAM" nutzbar. Aber alle mit nur 1..2bpp (und max 2..4 von 4096 Farben), weil keine verdoppelte Bandbreite oder maximale bpp. Also kein die bestehenden 640x200 bzw 640x256 oder 320x200 bzw 320x256 mit vollen 4bpp bzw 6bpp ohne Prozessor bremsen, oder gar letztere auf 8bpp erweitern, oder gar noch mit bremsen erstere bis 8bpp und letztere bis 16bpp.)

(Ganz ausser Konkurrenz kamen beim 32bit Nachfahren Advanced Graphics Architecture (AGA) der Amiga 4000 (1992) sowie Amiga 1200 (1992) und CD32 (1993) weitere "doppelte" 64k/82k und vierfache 128k/164k Videomodi. Diese bis zu 800x600 VGA und 1448241 NTSC bzw 1448278 PAL ohne Interlace (sowie mit Interlace doppelte Zeilenzahl). Endlich gab es zudem 8bpp mit 256 Farben aus 16M RGB, oder HAM8 Modus gar 262144 RGB mit 64 3*2=6bit "Startfarben" sowie jeweils 6bit einer der RGB ersetzen. Im CD32 kam sogar ein Chunks zu Bitplanes Umwandler hinzu, aber viel zu spät. Sprites sind neu vierfach 64xN gross. Die Blitter und Copper liefen aber weiterhin mit 16bit, bei zweiterem kein Problem, bei ersterem aber eine grössere Leistung verhindernd.)

Sega Mega Drive (1988) bzw Genesis (1989)

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 Superfami / SuperNES gekommen. Hat fast überall mit der Famicom / NES gleichgezogen oder gar einen massiven Vorsprung herausgeholt, und zumeist auch behalten (ausser in Japan wo die NEC PC Engine sie hinderte, und die SuperFami 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 inkompatiblen 32bit Mega Drive Erweiterung 32X (USA) sowie 32bit Saturn (Japan) kurz nacheinander heraus, gefolgt von der 32X versagen. Weiter hat Sega Japan die Mega Drive abgeschossen, wegen "Misserfolg" dort und Konkurrenz zur Saturn, trotz dass Sega USA damit gerade voll am laufen waren und weit mehr Potential hatten als mit Umstieg auf 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, weil auch im Master System Modus genutzt). 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 "H32" oder bessere "H40" 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.

Grob scrollen muss mit umkopieren gemacht werden, was aber mit einem DMA Blockkopierer Koprozessor gemacht werden kann (wie Famicom / NES), aber im VDP integriert, nicht im Prozessor. Damit kann er nicht nur Hauptspeicher zu Bildspeicher und umgekehrt kopieren, sondern auch Bildspeicher intern. Das 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 prozessoraufwendigen Bitplanes bzw Pseudobitplanes überhaupt so kritisch. Erst die vollen 256 oder 320 Positionen nutzen verlangt hier nach nur 2 vorgeshifteten Kopien, 128 oder 160 gehen selbst ganz 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 sichtbaren pro Zeile von 80 angemeldeten, bzw bei 256x(224oder240) 16 sichtbaren pro Zeile von 64 angemeldeten (mehr als der Amiga, und sowieso mehr als ST und MCGA ihre gar keinen).

Kann noch Dual Playfield (wie Amiga), 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 (strikte durchsichtig plus 15, mit einer weiteren bildweiten Hintergrund Farbe), 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 nur 2 Sätze hatte und Sprites nur einen von diesen nutzen können, und diese nur aus 64 RGB bestanden.

SNK Neo Geo (1990)

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, weil kein 8bit Modus). 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 erweiterte (mehr Sprites) und beschleunigte (12.5MHz statt 7.67MHz NTSC bzw 7.61MHz PAL) Mega Drive eingestuft. Hat aber einen 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 Superfami / SuperNES.

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 braucht 35k davon, ein leicht kleineres 304x208 passt in halbe 32k).

Womit obiges zu einem Bitmapmodus simulieren wird, und keinen Zellmodus. Man könnte 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.

Es sind genug Sprites vorhanden, um sogar bis zu 4(!) Ebenen 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 spezifisches Dual Playfield, weil die Sprites beliebig viele (Teil-)Playfields simulieren können. Aber noch besser erlaubt es, mit weniger hohen Sprites auch nur 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 zu wenigen und zu kleinen Sprites und einer mit nur einem Playfield halb ausgenutzten Bandbreite die letztere 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 einer der 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 für 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 einfaches, aber mengenmässig extrem leistungsfähiges System.

Nintendo Superfami (1990) bzw SuperNES (1991)

Strikte halbes 16bit, oder gar unterhalb halbes 16bit. Hat keine volle 16bit 68000 wie in den meisten anderen hier (und in 16bit 80286 in PC/AT mit EGA). Nicht mal eine 16/8bit 68008 wie im QL (und in 16/8bit 8088 in PC/XT mit MDA oder CGA oder EGA), beide intern volles 16bit, nur extern auf 8bit reduziert. Hat lediglich ein 8/16bit 65816, intern 8bit 6502 auf 16bit Register erweitert (selbiger wie im Apple IIgs benutzt, daher wurden mangels einem DiskSystem und Tastatur für die SNES oft IIgs als Programmiersysteme benutzt).

Ein Customchip Paar S-PPU (Super - Picture Processing Unit). Sowie weiterem Customchip S-DSP für Audio. Benutzt separaten Bildspeicher aus SRAM (wie Famicom / NES), aber nun 64k davon (wie Mega Drive und Neo Geo). Genauer ist dieser hier aber 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 Speicher 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 pro Zelle während Fontspeicher bei 2bpp oder 4bpp aber 2 oder 4 Bytes pro Zelle 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 niedrigem 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 bestehen bleibend. Kann weiterhin doppelte Zeilenzahl durch interlaced (aber nur in Modi 5 und 6).

Mit "HDMA" (Horizontal DMA) kann er während dem horizontalen Rü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 sichtbaren 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 Superfami / SuperNES 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.

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 128, sowie 8bpp alle 256. Modus 0 ist 4*2bpp, 1 ist 2*4bpp+1*2bpp, 2 ist 2*4bpp, 3 ist 1*8bpp+1*4bpp, 4 ist 1*8bpp+1*2bpp, 5 ist 1*4bpp+1*2bpp 512 Pixel, 6 ist 1*4bpp 512 Pixel, 7 ist 1*8bpp. Jedes Sprite kann jedes eines von 8 weiteren Sätzen benutzen.

Hat einfache pseudo-3D Fonttransformationen vom Hintergrund, mit Mode 7. Dieser verwendet stets nur 1 Layer mit dafür aber 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 Zelle ihrer Pixelposition Koordinaten zusammengesetzen Fontspeicher Adressen transformieren, statt innerhalb innerhalb von einem Zeichen linear durchzugehen. Das erlaubt skalieren, verzerren und rotieren von Zeichen. Mit dieser Transformation ihre Schrittweiten per Software zeilenweise vorzu angepasst auch pseudo-3D Texturen im ansonsten 2D vom Spielfeld. Siehe die 3D Wirkung bei Mario Kart. Die Sprites bleiben aber mit stets 4bpp bei 2D, mit jeglichen 3D Ansichten nur durch separate Zeichen im Font durchgehen, wie bei allen anderen Rechnern hier.

(Selbst der Polygongraphik Erweiterungschip Super FX reichte nicht für ordentliche 3D Graphik, weil weit zuwenig Leistung, mit nur 100 Polygone pro Bild rendern. Siehe die Limiten bei Star Fox. Nur 10 von 2000 Spielen nutzen diesen (und noch weniger den Vorläufer DSP-1). Ebenso das stärkere aber sauteure Parallelstück dazu, der Virtua Processor Erweiterungschip des Sega Mega Drive. Nur 2 von 850 Spielen nutzen diesen. Das weil 3D und 16bit (oder gar 8bit) einfach nicht zusammenpassen.)

(Sogar die 32bit Playstation (1994) war noch eher grenzwertiges 3D. Das weil sie zwar bis 640x512 hinauf anzeigen konnte, als beliebigen Ausschnitt aus 1024x512 16bpp(!) Bildspeicher, und diese Auflösung mit Blitter trotz keine Hardware Sprites (wie Atari ST) problemlos in 2D behandeln konnte. Aber bei 3D wurde zumeist weiterhin eine niedere 256 Auflösung wie bei Famicom / NES und Superfami / SuperNES benutzt, mangels GPU Leistung. Zudem hatte sie weder Z-Buffer noch Texturen skalieren oder überhaupt 3D Koordinaten, war eigentlich nur ein 2D Blitter für Compositing, aber mit automatischem Polygon Schablonengenerator (mehr als Amiga Linien und Polygone Füllen und dann Kopieren). Lediglich die CPU hatte eine Geometry Engine um 3D Koordinaten zu transformieren. Erst auf der 64bit Playstation 2 (2000) taugte 3D wirklich.)

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 Programm 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 Homecomputern:

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 weit, 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 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 Superfami / SuperNES.

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 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 Superfami / SuperNES, 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 Schwarzweissmonitor 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 horizontal 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 welche in die Zellen passen nur je eine Farbe haben.

Dies kann man zumeist mit Stiftfarbe und teils auch mit 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/Segmenten 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 oder gar 2x2 im MC6847 in seiner 2+6=8bit 2x3 Blockgraphik "6" oder (1+)3+4=8bit 2x2 "4" mit 2oder3bit als 4oder8 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 48bzw40% auf nur 6bzw5% 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 Zellen/Segmente 2*4=8bit Farben sogar gleich viel Speicher und Bandbreite verbrauchen wie wenn sie eine doppelt so breite Auflösung ohne Zellen/Segmente 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).

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 Schwarzweissem 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/Segmenten 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/Segmente 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), 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.)

(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/Farbsegmente 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 den Prozessor immer mehr ausbremst, bei 3bpp 24% bzw 4bpp 48%. 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 Hi-Res" mit NTSC Farbmonitor offeriert mit seinem pseudo-4bpp 15 NTSC Farben. Vergleichbare 16 hat es beim TMS9918 "Multicolor". TV Dazzler hat 16 RGBI Farben, ebenso PCjr und ColorPlus. 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 für 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 (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 sogar alle 4096 Farben aufs mal, im HAM Modus (Hold And Modify = beibehalten und modifizieren), wobei Werte 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 sie die beiden anderen beibehalten. All dies auf kosten von nur noch 320x200 bzw 320x256 dort wo die 0..15 benutzt werden oder gar nur /3= 106x200 bzw 106x256 bei vollen 4096 Farben. Oder man nimmt sie als 2*3bpp für Dual Playfield, ebenfalls mit 320x200 bzw 320x256.

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 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 48% 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*12%=48% ausbremsend, es scheitert aber an den maximal 6 Bitplane ihren 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, dabei nur 1/4 ihres 256k Speichers nutzend, trotz ausreichend Speicherbandbreite für 640x400 zu haben, wie es die Super-VGA 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).

Wobei die Mega Drive und Superfami / SuperNES sogar nur Zellmodi haben, 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 Superfami / SuperNES 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 Scroll A und B.

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. Damit passen 40 Zeichen. Dazu die grösste Menge Spritebits pro Zeile, 8*24*1bpp=8*12*2bpp=196bit. Dazu 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 wirklich fehlt ist Overscan. Nett wäre noch die 16 Farben aus mehr auswählen können (wie Atari 800 oder TED). Verschmerzen kann man, dass intensivere Effekte nach vorzu in Software umkonfigurieren verlangen. Die Designer vom VIC-II haben ihre Erfahrungen von PET/CBM und VC-20 sowie ihren "beste Features anderer Chips und Rechner vergleichen" Ansatz 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 von Bandbreite. 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 hat der C64 die 8bit Konsolen so geschlagen, beinahe das ganze Konzept der dummen Abspielkonsole gekillt. Genauso kein Wunder ist sein Name auch üer 25 Jahre nach dem Untergang von Commodore (1994) immer noch weitherum bekannt. Das selbst bei Leuten welche damals noch nicht mal am Leben waren, ihn nur vom Hörensagen her kennen. Was ihn als einem von wenigen Rechnern zu im wahrsten Sinne des Wortes legendär macht.

(Der Commodore 128 beinhaltet einen VIC-IIE, graphisch identisch mit dem VIC-II. Er addiert einen separaten VDC, der zwar 80x25 Zell bzw 640x200 Bitmap kann, und sogar 2*256 Font im Zellmodus, sowie 16 RGBI Farben. Aber mit nur 1bpp ist er für Spiele zu schwach. Kann strikte Overscan, und sogar fein scrollen. Aber keine Sprites um die 1bpp etwas auszugleichen, oder auch nur 160x200 4bpp um sie zu ersetzen. Dazu kam die harte Modusumschaltung, die einen gespaltenen Rechner ergab, Spiele laufen nur auf unerweiterten C64, auf C128 VDC hat es nur Büro. Selbst dieser hatte nur wenig neue Software, weil die geringen +64k wenig Anreiz gaben, die aufwendige aber unflexible Speicherbank Umschaltung zu programmieren. Nach C64 als dem Besten der 64k Generation war C128 der Schlechteste von den 128k! Weshalb die meisten C64 Benutzer bei diesem blieben, oder erst zu 16bit weitergingen. Den C128 besorgten zumeist nur Neueinsteiger, welche diesen einfach "auf Vorrat" nahmen. Was zu noch weniger diesen nutzende Software führte, und wenige Umsteiger. Somit konnte der C128 mit nur 5..7mio Exemplaren dem C64 seine 12.5..17mio nicht ablösen, trotz dass eigentlich ein Potential von n*10mio vorhanden gewesen wäre. Ebenso konnte er die anrollende Flut von PC Klonen nicht abhalten, zu denen auch viele C64 Benutzer weitergingen.)

Platz 2 geht knapp dahinter an die Nintendo Famicom. Abstriche gibt es für dessen nur 256 Pixel, trotz dass diese inklusive permanentem Overscan sind, was nur etwa 24..28 Zeichen breit 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 somit etwa (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 ausnutzt. 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 aud 64 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 Famicom / 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 Family Computer bezeichnet wurde. Massiv nervig ist zeichnen nur während dem vertikalen Rü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 versehen wurde, was eigene Module herstellen verhindert, nur das erlaubte wofür Nintendo Module herstellen willig ist, mit vielen fraglichen inhaltlichen Restriktionen. Damit ist nur noch Konsumieren möglich, was deren Spielezensur erlaubt. Es versagt somit als Medium! In Zahlen: Für etwa 62mio NES gab es trotz 20 Jahre verkauft nur um 1400 Spiele, aber für etwa 12.5..17mio C64 gab es trotz nur 12 Jahre verkauft weit mehr als das, die GameBase64 listet über 25'000 Spiele! 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 8x1 Farbsegmenten ("Graphic 2") oder aber 8x8 Farbzellen an 32 8er Gruppen Zeichen gebunden ("Graphic 1"). Dazu noch "Text", 256er Font, ohne Farben und 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 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 zudem 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). Dazu noch grob scrollen mit Blockkopierer. 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 aber 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.)

(Der Sega SG-1000 Mark III bzw Master System erweitern mit deren G4 Zellmodus auf 4bpp, und damit besser als die 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 dessen 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 von 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 (was der SC-3000 vorbehalten war, 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 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, welche erstmals einen Homecomputer machte, aus einer halbfertigen erweiterten Spielkonsole, und das mit der Auflösung nicht im Griff hatte, 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, somit 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 Zeilenrü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 lediglich 5*1=5 zu 8*3=24 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. 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" nach dem VCS/2600! Die in der Einführung erwähnte Atari 800 vs Commodore 64 Debatte wird somit eindeutig von letzterem gewonnen, weil trotz ebenfalls zweites System nach dem VC-20 nicht derart über Bord geschossen, sondern optimal gezielt.

(Der 130XE lieferte analog zu Commodore 128 mehr Speicher. Aber nicht mehr Video. Erst die XEP80 erlaubte Text 80x25 Zeichen ohne Farben. Diese kann weit weniger als dem C128 sein VDC und ist erst noch langsam. Spiele laufen nur auf unerweitertem 130XE, auf XEP80 nur Büro. Wenigstens ist das Paging sehr freundlich zu solchem.)

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 hinbekamen. 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 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 schlechte oder gar kaputte 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 den Videokonsolen Crash von 1983 bezeichnet werden, weil die ganzen Automaten und Homecomputer Spieler dort wenig betroffen waren, ebenso wenig wie in Europa und Japan, wo zumeist bereits Homecomputer bzw noch Automaten verbreitet waren.)

(In Japan fing Automatenhersteller Nintendo gerade den Wechsel an, zu Konsolen als kleiner Automat für zuhause, nur ein Erfolg weil dort Homecomputer wenig verbreitet waren, und nahm danach auch gleich die am Boden liegenden USA mit, zumal dort Homecomputer auch nicht Konsolen verdrängt hatten. 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 Superfami 16bit total verschlief. Aber sie schossen sich selber ab, mit dem Konflikt von Sega 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 Superfami / SuperNES 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 für den VC-20 Nintendos Automatenspiele lizenzieren wollte, aber dann alles fallenliess, wonach zuerst Coleco diese für die ColecoVision bekommen konnte, sowie dann Nintendo selber einstieg und dazu die Famicom / NES erzeugte. Ohne all das alles wäre das Konzept der dummen Abspielkonsole wohl Mitte 1980er ausgestorben, als nun veralteten 1970er Ansatz von "Technologie noch nicht reif für billigen vollen Computer". Ironie, dass die Playstation dann genau im gleichen Jahr (1994) herauskam wie Commodore unterging.)

(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 diese Machtposition missbraucht wie jegliche Zensur, einerseits für diverse "missliebige" Inhalte unterdrücken (mit weit restriktiveren Kriterien als der Hayes Code beim Film hatte!), sowie anderseits um den Spieleherstellern Knebelverträge zu diktieren (max 5 Spiele pro Jahr, keine Spieleports auf andere Systeme). Während nur Qualität fördern bereits mit einem reinen Gütesiegel als Empfehlung machbar gewesen wäre, ohne Gefahr von Missbrauch einer Machtposition. Sega hat im Kontrast dazu diesen Fehler ausgenutzt, bei der Mega Drive alles erlaubt, und die resultierende Auswahl als Coolness vermarktet, was dieser ebenfalls half. Während Nintendos erworbener Ruf als Kinderspielzeug die N64 und auch 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 voll alles machende Gatearrays)

Platz 1 geht eindeutig an die TED Rechner Commodore 16 und 116 und Plus/4. Bei einem überarbeiteten und ordentlich erweiterten VC-20, 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 flexibel 256 Zeichen oder Atari sparsam 128. 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 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 als dieser zu sein!

Platz 2 geht überraschend an den Commodore VC-20. Er leidet zwar massiv an seiner "halbierten" 176 Pixel Auflösung, mit nur 22 Zeichen breitem Text. Bitmaps fehlen auch. Aber abgesehen davon hat er einen 256er RAM Font mit zeichenweise schaltbar 1bpp und 2bpp (was aber bei 2bpp nur noch 88 Pixel ergibt), und dazu noch Farbspeicher auf 8+4=12bit, sowie halbwegs fein scrollen. In obiger Kategorie würde er nicht nur den VCS/2600 klar schlagen, sondern auch den Atari 800 bedrängen. 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! Er legte zudem noch die Basis von C64 und TED. 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 die TED später. (Ebenso unterschätzt wird damit Al Charpentier als Designer vom VIC und auch VIC-II, sowie als Einfluss auf den TED, der vergleichbar bedeutend ist mit Jay Miner als Designer von TIA und ANTIC+CTIA und Agnus+Denise.)

Platz 3 geht erstaunlich an den Sinclair ZX Spectrum. Zwar nur 256 Pixel und 32 Zeichen, wie TMS9918, und auch nur 1bpp als grösste Schwäche, wie TMS9918. Aber zumindest mit Farbattributen, wenn auch wegen diesen mit "Contention". Sowie diese nur in 8x8 Pixel Zellen, was oft in "Attribute Clash" resultierte. Damit konnte man bei einem Billigrechner leben, solange man nicht mehr als 2 Farben in einer Zelle haben muss. Was in den typischen rechteckige Bereichen mit je nur 2 Farben resultierte, und in bewegte Figuren nur in Bereichen mit deren Farbe. Für so billig ist das aber erstaunlich gut und völlig akzeptabel. Nur mit 2bpp, selbst mit 8x8 Farbzellen, wäre er bereits exzellent, würde Platz 2 nehmen. (Er wurde dementsprechend oft geklont, vor allem im Ostblock, massiv 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 40 Zeichen und Farben auf 6x8 Pixel im Zellmodus bzw sogar auf 6x1 im Bitmapmodus. Trotzdem hinter dem ZX Spectrum, weil die Attributschalt Leerpixel bzw Leerzeichen noch schlimmeren "Attribute Clash" erzeugen, und nur 8 Farben. Damit konnte man bei einem Billigrechner aber auch leben. Trotzdem hatte er gegen den Spectrum keine Chance zuhause, wurde nur gerettet dank einem sehr aktiven Importeuer in Frankreich.

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 SVGA 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 analog RGB Farben gleichauf ziehen oder eher leicht voraus. (Beide wären mit 4*4*4=64 optimal.) (An weiterer geringer Schwäche haben beide nur fehlendes fein scrollen.)

(Die 464plus und 6128plus (1990) addierten fein scrollen und Sprites, sowie 32 von 4096 RGB Farben. Sie wären damit 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 mit Floppy 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 65XE basierte XEGS (1987) und gleichzeitig die C64 basierte 64GS (1990).)

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 diese Farbzellen sogar auf 8x1 Farbsegmente 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 statt 8 Farben sogar darüber hinausgehen! All das in reinem TTL, mit 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 (dies wurde im 85/3 seinen neueren ROMs aber weit verbessert)!

Platz 4 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 5 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 selbst ohne Bitmap dank Zellmodus 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 6 geht auch überraschend an den Jupiter Ace. Zwar ohne Bitmap, und nur 1bpp, und keine Farben, und geringere 256x192 Pixel. Aber auch er wird durch die 128 Zeichen RAM Font gerettet, womit selbst ohne Bitmap dank Zellmodus volle 32x24 Zellen mit beliebigen 8x8 Muster machbar sind. Ist damit an Auflösung beim ZX Spectrum, bleibt aber mangels Farben selbst hinter dem Oric zurück. (Damit wäre er anstelle vom ZX80 Gebastel weit besser gewesen, selbst wenn nur mit Textmodus statt Zellmodus. Aber gegen inzwischen Spectrum und Oric mit Bitmap und Farben hatte er keine Chance mehr. Es verkauften sich nur 5000(!) Exemplare in den 1.5 Jahren bis zum Konkurs vom Hersteller, im Vergleich zu ZX80 schon 10'000e und ZX81 dann 100'000e und Spectrum gar Millionen. Die ehemaligen Spectrum Designer hätten besser einfach ein Forth ROM-Ersatz Modul für diesen angeboten.)

Platz 7 geht erst massiv abgeschlagen an die IBM PC CGA. Diese kann eigentlich 640 Pixel mit 1bpp, 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 von 160 Pixel mit 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 das Register und die Randfarbe praktisch auf Schwarz zwingen. Daher kommen die vielen für die CGA typischen Spiele mit Sw/Bl+Gn+Rt+Ge oder gar Sw+Cy+Vt+Ws. Zudem kann die CGA dies bei 1bpp nicht mit Farbattributen retten, weil sie nur in Textmodus solche hat, was ihn selbst hinter den ZX Spectrum und Oric Billigrechnern stellt! Der 1bpp ist aber wenigstens noch mit Schwarz plus einer freien 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 dem Jupiter Ace Billigrechner stellt. Sowie zu seiner 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!

(Nur mit dem vielen Programmierern 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, wenn auch im akzeptablen Masse. 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, wie Apple II "Double Hi-Res". Aber dies ist mit dem üblicherweise verwendeten digitalen IRGB Monitor nicht benutzbar.)

(Das einzig gute am IBM PC war der 8088 Prozessor. Strikte ein reiner 16bit Prozessor, mit billigeren 8bit Daten extern. So auch nur 16bit Adressen und 64k direkt nutzbarem Speicher, das aber mit sehr komfortabler eingebauter Adresserweiterung auf massive 1024kByte. Diese kann spezifisch nach Funktion 4*64k Ausschnitte nutzen, was als Segmentierung bezeichnet wird. Diese Ausschnitte sind zudem in 16byte Schritten anordenbar. Alle nur 64+64k 8bit Rechner (wie Apple IIe und Atari 130XE und Commodore 128 und Spectrum 128 und CPC6128) waren chancenlos. (Mit 64+(2*)256k hätte das wohl noch anderst ausgesehen!) Ausser mit einer 65816 (wie Apple IIgs, aber der war viel zu spät) und dessen 24bit Adressmodi, konnte kein anderer 8bit es damit aufnehmen. Dazu kam beim PC/XT die Option auf Harddisk, die ansonsten bei 8bit fast komplett fehlte. Weiter kam hoher Preis, aber gut dokumentiertes Design, was zur grossen Flut an Taiwan Klonen führte.)

(Bei IBM 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 mit Speicher auf 16bit erweitert sogar 640x200 mit 4 Farben und 320x200 mit 16 Farben in 32k. Was Platz 1 gegeben hätte. Nur ist dieser an nicht genug PC kompatibel und vor allem der gnadenlos misslungenen Tastatur gescheitet. (Der Tandy 1000 zeigte, dass das Konzept richtig gewesen wäre.) (Der Plantronics ColorPlus zeigte bereits davor, dass auch der PC dies voll CGA kompatibel mit 32k Modi hätte machen können. Was auch Platz 1 gegeben hätte. Nur war das Teil wie der "Tweak Mode" vielen Programmierern und Benutzern unbekannt.))

Platz 8 geht weiter hinten an den Apple II. Zwar noch 280 Pixel aber nur mit 1bpp (mit Schwarzweissmonitor), sonst nur noch 140 pseudo-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 voll 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 gar 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!) (Auch hier hoher Preis aber gut dokumentiertes Design, gefolgt von einer kleineren Flut an Hongkong Klonen.)

(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 CGA und BBC und CPC Niveau. Ebenso "Double Low-Res" Blockgraphik auf immerhin 80x48 (wenn auch diese in 1983 total veraltet ist). Weit besser gibt es mit der 64k Speichererweiterung "extended 80-column", einen "Double Hi-Res" Bitmap auf 560er mit 1bpp kann, und somit auch pseudo-Pixel mit pseudo-4bpp in den 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 und 4 mit der KC 85/4 teilen müsste. Mit all dies konnte der IIe aber die II und II Plus ablösen, und wurde nach etwa 3 Jahren praktisch zur Standardanforderung neuer Software, trotz davor bereits 6 Jahre an II und II Plus verbreitet sein.)

(Der Apple IIgs erweitert auf 640x200 mit 4 Farben und 320x200 mit 16 Farben in 32k. Er ist damit fast zu PCjr und ColorPlus identisch. Nur sogar 4096 statt 64 Farbauswahl, und mit 320x200 zeilenweise 16er Farbsätze, und 640x200 spaltenweise 4* 4er Farbsätze. Was erst recht Platz 1 gegeben hätte. Dazu kam der 8/16bit Prozessor 65816, der viel Speicher benutzen konnte. Nur war er 1986 zu spät um noch gross etwas zu erreichen.)

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

8bit ohne Bitmapgraphik oder RAM Font

Platz 1 geht gerade noch an die IBM PC MDA. Ohne Bitmap oder RAM Font oder Farben, zählen in dieser Kategorie nur noch die Anzahl Zeichen im Bild sowie dem ROM Zeichendatz seine Anzahl und Art an Graphikzeichen. Die MDA hat als einzigen stets 80x25 Zeichen, und das erst noch mit vollem 256er Font und separaten 8bit Attributen. Der Font hat aber vor allem viele akzentierte Zeichen, nur wenige Graphikzeichen. Insbesondere hat die im Font eingebaute mischbare Blockgraphik nur 1x2 und 2x1, keine 2x2, und schon gar 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.)

(Bei Hercules HGC gab es dann die fehlende Bitmapgraphik. Diese zudem sehr hoch aufgelöst mit 720x348, mehr als jede andere 8bit Karte oder Rechner, zumal es die selbigen 32k von PCjr und ColorPlus sind, aber mit nur 1bpp! Aber hat keinerlei Farben, als eine mit Bitmap erweiterte IBM PC MDA auch nicht verwunderlich. Er würde damit in obiger Katagorie auf Platz 4 kommen, nach der KC 85/2 (mangels Farben) und vor der (mit mehr Pixel). Scheidet wegen MDA Spezialmonitor aber strikte ohnehin aus.)

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

Platz 3 geht knapp dahinter an den Kaypro II. Hat grössere 80x24, aber nur 128 ohne revers Font. Und nur einen Font mit vollem ASCII96+Graphik32. Somit gleich oder weniger Graphikzeichen als PET/CBM. (Beim Kaypro 10 sind es dann 80x24 von 80x25, mit im Font integrierte mischbare 2x4 Blockgraphik auf 160x100. Damit zieht er am PET/CBM vorbei, auch an den CBM 80xx, und selbst an der MDA, auf 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 aber 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 dem Oric kommen (weil keine Farben) aber vor dem 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 ebenfalls nach dem Oric aber vor dem Jupiter Ace kommen, sowie leicht nach einem modifizierten 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 zu 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 und grob scrollen per Bildausschnitt. 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 1..6bpp Bitplanes und ihr "Ghosting" beim scrollen vom Spielfeld stören massiv, hier am schlimmsten ausser noch beim KC 85/4. Ausser die Bitplanes werden zeilenweise verzahnt im Speicher angeordnet, was aber mit Aufwand braucht um System zu umgehen. Der Blitter beschleunigt Umkopieren und rekombinieren, was sich aber wegen Setup Aufwand erst bei grossen Flächen lohnt, genau dort wo die Sprites versagen, aber auch dort 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, weil flexibler. Er kostet mit Speicherzyklen blockieren aber ebenfalls Spritebits (wie Atari 800). Damit ist der Amiga zwar eine gute Erweiterung seines Vorfahren Atari 800, dessen Schwächen grossteils beseitigt, aber den Prozessortakt auf 7/8 gebremst bleibt bestehen. Weiterhin gibt es Abstriche wegen manchem überflüssig komplexem Hardwareaufwand, aber dann unnötig Takt gebremst. Alleine die Bitplanes verlangen pro Bitplane Adresslogik während Chunks (und auch Pseudopitplanes) nur eine gemeinsame Adresslogik teilen (womit selbst Pseudopitplanes statt echten eine Vereinfachung wären, aber beliebig 1..6bpp verlieren). Der Amiga gewinnt 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 48% 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 und Dual Playfield. Kein Wunder ging die Demoszene vom C64 zum Amiga weiter, hier ist noch mehr zum aufzeigen drin! Genauso kein Wunder ist sein Name fast genauso bekannt wie der C64. Was ihn ebenso zu legendär macht.

(Die Amiga 500 und Amiga 2000 spalteten die Reihe auf. Der Amiga 1000 hatte ein teures aber limitiertes Gehäuse, zuviel für Homecomputer aber zuwenig für Büro-PC. Er konnte sich wegen Kosten nicht gegen den Atari ST verbreiten (Commodore verweigerte jegliche Verbilligung, wie beim C128DCR gemacht) und mangels HD nicht gegen PC Klone antreten (strikte war externe HD machbar, am Expansionsport, im Format eines Sidecar). So war nur eine Kompromissvariante, welche keine Anwendergruppe wirklich befriedigen konnte. Bis er nun 1987 in billigen 500 und intern erweiterbaren 2000 aufgespalten wurde. Was schon am Anfang bei Hi-Toro halbwegs der Plan gewesen war, aber als Spielkonsole plus Bürorechner, aus ihrer Atari 400 plus 800 Erfahrung heraus (wobei dies wohl kompakte Konsole plus nur etwas mehr als der Amiga 1000 gewesen wäre). Dazu kam desorganisiertes Management, mit davon ein Jahr von sehr schlechtem Marketing, welches die Fähigkeiten vom Rechner nicht aufzeigte, gefolgt von weiteres Jahr gar keinem Marketing mehr, weil "bald neue Modelle kommen". Das ergab geringe Verkaufszahlen, trotz dass IBM nach dem Versagen des PCjr als Home-PC auf dem teuren Büro-PC mit schwacher CGA festsass (mangels einer PCjr oder ColorPlus Graphik für PC, und mit EGA sehr teuer), und Taiwan Klone noch nicht flutend waren. Wovon der ST profitierte, neben billiger sein, trotz dass der Amiga 1000 eigentlich dem Home-PC Konzept optimal entsprach! Bis Commodore nun aufspaltete. Wonach der Amiga 500 als Homecomputer bald den Atari ST einholte und überholte, und zugleich das erfolgreichste Modell der Serie wurde, sowie der Amiga 2000 als Büro-PC mit interner Harddisk nutzbar wurde, trotz weiterhin fast nicht vorhandenem Marketing. Damit waren aber 2 Jahre an optimalen Verbreitungschancen unwiederbringlich verloren, und noch schlimmer auch die anfängliche Wahrnehmung vom spektakulären graphischen Auftritt verblasst. Den massiven 12.5..17mio Erfolg vom C64 konnten sie nicht mehr duplizieren. Selbst der C128 mit nur 5..7mio verkaufte sich leicht besser als der Amiga 500 mit 4..6mio, trotz dieser das erfolgreichste Modell der Serie sein! Deswegen konnte er ebenfalls nicht mit Verbreitung die 16bit Konsolen unten halten, nachdem der C64 die 8bit Konsolen dorthin geschlagen hatte. Das wurde so zum Anfang vom Ende des Amiga und Commodore. (Bonuspunkte, dass in der Zeit die 8bit Gruppe den 128 nach oben mit den 128D und 128DCR erweiterte, und Atari den ST nach oben mit dem MegaST, beides Wechsel von Amiga 500 artig Homecomputer in Tastatur zu Amiga 1000 artig Home-PC flach unter Monitor, ohne diese teuer zu sein!) (Strikte hätte der 128 auch Commodore finanzieren können bis der komplexe Amiga reif war, so wie IIe und IIgs Apple finanzierten bis der unterdimensionierte Macintosh reif war. Aber dem 128 sein Versagen gegen den PC anzutreten, mit zuwenig Speicher und aufwendigem aber sehr unflexiblem nur Banking Speicher Umschalter, sowie mühsamem aber limitiertem VDC Video, daher wenig neue bessere Software, verhinderte dies.))

(Der Amiga 500 basierte CDTV (1990) war inzwischen komplett veraltete Technologie, und zudem wieder wie der Amiga 1000 ein (zu) teures Gehäuse, weil als "Super Videorekorder" statt CD-Konsole gestaltet (wie es Philips mit dem CD-i (1991) genauso verbockte).)

(Die Enhanced Chip Set (ECS) A2000-C/A2000+ und A500+ verdoppelten zwar fakultativ die Pixelfrequenz oder gar Horizontalfrequenz, aber nicht die Bandbreite oder maximale bpp. Was in 1990 nicht mehr gegen den schon 2 Jahre alten VGA ausreichte.)

(Die 32bit Advanced Graphics Architecture (AGA) A4000 und A1200 und CD 32 erweiterten endlich mit mehr Bandbreite und 8bpp auf doppelte 64k/82k und vierfache 128k/164k Modi. Das reichte bis zu 800x600 Super-VGA, und die 8bpp mit 256 Farben waren aus 16M RGB, sowie HAM8 Modus gar 262144 RGB gleichzeitig. (Aber all dies war 1992 nochmals später als der Atari TT, und damit weit nach VGA PCs mit 320x200 8bpp MCGA Modus, mit inzwischen Super-VGA sich verbreitend. Also nur noch den Rückstand etwas aufholen statt einst weit vorauslaufen! Es fehlten Commodore inzwischen "dank" krassem Missmanagement die Finanzen um mit verbesserten Chips entwickeln gegen 486er PC Klone mit Super-VGA sowie Macintosh II Stand zu halten. Zudem fehlte allen Homecomputern (und auch den meisten Büro-PCs) ein CDROM, was Spiele auf inzwischen zu kleine langsame Floppys limitierte. Ohne Harddisk war auch nichts mit Floppysätze nur als Installmedium nutzen (wie PCs es machen konnten). Das wurde erst bei der CD 32 (1993) richtig gemacht, als A1200 basierte CD-Konsole plus fakultative Tastatur und Maus. Aber diese kam weit zu spät, gegen inzwischen 486er PC Klone mit Super-VGA. Amiga und Commodore gingen unter (1994).))

(Commodore hat parallel zum Amiga zudem eine PC Linie aufgebaut. Als Teil davon gab es den "Sidecar" (1986) zum Amiga 1000, ein PC/XT Klon, der nur Prozessor und Speicher und 3 Slots und 1 Floppy hatte, alles andere vom Amiga her übernahm, inklusive MDA und CGA Video emulieren via einem 80k Dualport RAM. Dieses Konzept wurde mit dem Amiga 2000 internalisiert, mit den "Bridgeboards" (in 8088/286/368SX Versionen, als A2088/A2286/A2386 in 1987/89/91), welche von einem Amiga Slot zu einem Satz PC/XT Slots gingen. Davor entstanden bereits separate PC-10 und PC-20 (1985), gefolgt von einer Serie PC-30 bis PC-60, alles generische PC Klone, nur mit Name Commodore drauf, und nicht mal billiger als die Taiwan Konkurrenz! Interessant war da nur deren Home-PC PC-1 (1987), ein billiger PC/XT Klon, mit 32k Modi CGA, der in einem kleinen niedlichen Commodore 128 artigen Gehäuse ohne Slots daherkam. Nur fehlten ihm, trotz C64 und Amiga Erfahrung, eine Soundkarte oder ein Joystickanschluss, womit die Slots oft notwendig wurden, in Form einer Erweiterungsbox, welche aber die gesparte Grösse und Kosten negierte. Dazu kam Harddisk nur in Erweiterungsbox als Hardcard. Ansonsten ist nur eine Floppy, und kein System in ROM (wie Amiga es hatte) oder auf RAMdisk (wie PCW8256 es hatte) um ohne zweite Floppy zu arbeiten, was die externe Floppy brauchte und auch da gesparte Grösse und Kosten negierte. Womit das eigentlich gute Konzept pervertiert wurde, zu unterhalb dem Stand von PCjr und Tandy 1000 (welche beide Sound und Joysticks hatten), statt deren Ansatz zu verbessern auf voll PC kompatibel! Also hat das PC Abenteuer Commodore nicht gerettet, nur einen Teil der ohnehin zuwenig Resourcen vom Amiga abgezogen. (Einer der Amiga Designer hat die PC Linie kritisiert, es wäre besser gewesen, den Amiga mit PC datenkompatibler zu machen, mit dessen Diskformat und Zeichensatz sowie Kommandozeile und Schriptsprache als Alternativen anbieten.))

Platz 2 geht auch nicht überraschend an den Atari ST. Selbst mit dem Schwarzweissmonitor schlagen seine 640x400 1bpp dem Macintosh seine 512x342 1bpp locker, mit 32k um ein Drittel mehr als dessen 21.8k. Dazu noch ohne halbe "Bad Lines". Eben der Jackintosh. Fehlende mehr als 1bpp bei Schwarzweiss machen diesen aber für Spiele unattraktiv, verlangen nach dem Farbmonitor. Der hat aber keine Spezialmonitor 400 Zeilen mehr, nur Videomonitor 200. Das spaltete die ST Benutzer klar in Büro/Schwarzweissmonitor und Spiele/Farbmonitor. Mit letzterem ist er ein vierfacher Commodore 64, mit 640x200 2bpp und 320x200 4bpp aus 32k, bis auf die fehlenden Sprites. Er ist sogar identisch mit einem Amiga, solange man dort nicht Prozessor für mehr bpp und/oder Farben opfert! Kann man hier nicht, weil keine echten Bitplanes vom Amiga. Daher aber auch kein "Ghosting" vom Amiga, wenn auch weiterhin Probleme wegen Pseudobitplanes, sowohl mühsam wie auch langsam. Hat gleichen Prozessor, aber volle 8MHz statt die Macintosh 7.8336MHz oder gar nur 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 viel Speicher und 4bpp nicht mehr ganz so kritisch, wie es einige damalige Spiele zeigten. Aber auch er verfehlt ein so abgerundetes Paket zu sein wie der C64, diesmal im Gegensatz zum Amiga wegen zuwenig sein statt zuviel. Insbesondere fehlt horizontal fein scrollen, was alle scrollenden Spiele zu wiederholt rendern mit Doublebuffering zwingt. Wozu er zwar genug Speicher hat, aber massiv Prozessor verheizen muss, der beim Compositing fehlt. Allerdings konnten scroll-lose RPGs und 3D Spiele (und auch Vertikalscroller) unbeeinflusst davon die mehr Prozessor und Speicher zwecks Illustrationen dekomprimieren oder gar Szenen rendern ausnutzen (oder auch nur für viele kleine Objekte bewegen). Selbiges gilt für die fehlenden Sprites. Es fehlen die einfachen aber grossen vom C64. Was wieder wegen Compositing brauchen grosse bewegende Graphiken ausbremst, aber statische RPGs nicht trifft (und auch nicht Spiele mit vielen kleinen Objekten, wo Amiga Spriteanzahl limitiert). Bei letzterem bremsen die Pseudobitplanes aber gerade horizontal schmale Elemente und Objekte mehr aus (vertikal ist der rein lineare Bildspeicher optimal schnell). Generell gewinnt dieser "Big CPU" Ansatz vom ST vor allem bei Illustrationen und 3D Szenen, während der "Koprozessor" Ansatz vom Amiga bei dazu passenden 2D Animationen eher profitiert. Weiter fehlen die Farbzellen vom C64, was 80 Zeichen Textdarstellung farblich limitiert. Am besten wäre 640@1bpp mit 8x1 Farbattribute als Farbsegmente. Das alles weil der ST eigentlich mehr ein vierfacher Apple II Plus ist als ein vierfacher C64. Das anzunehmend weil Atari ST Designer Shiraz Shivji kein VIC/VIC-II Al Charpentier ist, und dessen Spiele Features nicht weiterzog, vermutlich weil mehr an einem vierfachen PET/CBM Nachfolger interessiert. Bonuspunkte für DMA/ACSI Anschluss für Harddisk, wenn auch diese lange auf sich warten liessen. Was alles den ST auf den zweiten Platz verweist, wenn auch recht knapp. Er wurde damals auch ziemlich unterschätzt, gerade im Vergleich mit dem Amiga, wenn auch nicht ganz so extrem davon betroffen wie TED oder gar VC-20. (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 erst recht geteilt. Mit Chunks und fein scrollen noch mehr so. Mit zudem vierfach grosse Sprites vom C64 hätte er den ersten Platz alleine genommen.)

(Der Atari STE erweiterte auf 4096 Farben, sowie dem schwachen Blitter vom MegaST, sowie endlich pixelweise horizontal fein scrollen, und auch ausgegebene Videoadresse umschalten für Zeilenblöcke, sowie per DMA ausgegebenes PCM (Samples) Audio. Er wurde deswegen sogar als "Amiga Killer" ausgegeben, trotz diesen bestenfalls einholen, oder nicht mal das! Er kam zudem 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 anfangs schneller verbreitete ST erst gross gegen dem inzwischen seit 2 Jahre aufholenden Amiga 500 verlor. (Die Erweiterungen benutzen hätte wohl anderst ausgesehen, wenn der STE die inzwischen auch bei billig 5MHz statt 4MHz schnellen DRAMs ausgenutzt hätte mit 2 mal 16bit an Bitmapdaten per Pagemode Doppelzugriffe mit 1*/RAS+2*/CAS (wie CPC, dort mit 2.5MHz statt 2MHz)! Oder besser gar schon der teurere MegaST die damals bereits vorhandenen wenn auch etwas teuren 5MHz genutzt hätte. Das hätte verdoppelte 64k Videomodi erlaubt, auf schwarzweiss Spezialmonitor 640x400 2bpp (oder eher 800x600 1bpp, oder gar 640x800 1bpp Portrait), sowie auf analog RGB Monitor 640x200 4bpp und 320x200 8bpp. Am besten diese neuen Modi zudem mit Chunks, zumindest beim neuen 8bpp, mit so Worte auf 160 Positionen und damit weder fein scrollen noch Doublebuffering mehr nötig, sowie Compositing schnell mit einfachem 1 Byte = 1 Pixel, auch ohne Sprites (wie VGA im MCGA Modus). Er wäre damit zu einem vierfachen CPC geworden, bzw wegen erweitert sein eher einem vierfachen Apple IIe, aber jedenfalls auf parallelem Stand zu einem vierfachen C64 gekommen, die fehlenden Sprites nun mit 8bpp kompensiert (wie PCjr und BBC und CPC). Damit hätte er auch den ersten Platz genommen, selbst vor den ECS Amiga! Dies wäre wohl auch benutzt worden, zumal ein Apple IIe in etwa 3 Jahren praktisch Standardanforderung neuer Software wurde, trotz davor bereits 6 Jahre an II und II Plus verbreitet sein. Er wäre damit ein massiver Erfolg geworden. Dies zu verpassen, plus spät kommen, erlaubte dem Amiga 500 aufzuholen, sowie den 286er PCs mit VGA im MCGA Modus gar überholen. Deswegen konnte auch er ebenfalls nicht mit Verbreitung die 16bit Konsolen unten halten. Das wurde so zum Anfang vom Ende des ST und Atari.))

(Der 32bit Atari TT erweitert auf vierfache 128k Videomodi (genauer wegen noch etwas mehr Zeilen 150k), Schwarzweiss 1280x960 1bpp sowie Farben 640x480 4bpp (und 320x200 8bpp in nur 64k). Nur konnte man diese Graphik ausschliesslich mit 32bit haben, zu 386er Preisen, während bereits 286er PC Klone mit VGA laufen konnten.)

(Der Falcon 030 konnte sogar massive 640x480 16bpp, trotz nur 16bit DRAM. Aber dies war in 1992 nur noch der letzte Aufschrei der ST Serie, kam weit zu spät um den Untergang noch zu verhindern. Weder die zum Amiga 500 abgewanderten, welche vom 386er Preis des TT abgehalten worden waren, und statt nun endlich zum Falcon zurückwechseln einfach zum gleichviel verspäteten A1200 weitergingen. Noch die inzwischen zu 486er PC Klone mit Super-VGA komplett abgewanderten. ST und Atari gingen unter (1996).))

(Auch Atari hat parallel zum ST zudem eine PC Linie aufgebaut. Diese fing an mit ihrem Home-PC Atari PC (1987), später PC1, analog zum Commodore PC-1, ein billiger PC/XT Klon, sogar mit 256k EGA statt 32k CGA, der in einem kleinen niedlichen MegaST artigen Gehäuse ohne Slots daherkam. Nur fehlten auch ihm, trotz C64 und ST Erfahrung, Soundkarte und Joystickanschluss, und es gab zudem keine unpassende Erweiterungsbox, nur einen kleinen Pseudo-Slot. Ebenso fehlte ein ACSI Bus zur Harddisk (oder zu diesem Zeitpunkt gar gleich SCSI), aber immerhin konnte man diesen mit dem Pseudo-Slot addieren, und damit die normalen ST Harddisks nutzen. Was aber schwach war im Vergleich zum ST, wo ACSI seit 3 Jahren in jedem Modell drin war, selbst in den Homecomputer Versionen. Ebenfalls nur eine Floppy, und kein System in ROM (wie ST es hatte) oder auf RAMdisk (wie PCW8256 es hatte) um ohne zweite zu arbeiten, trotz dass für 640k RAM + 384k RAMdisk statt zweite 360k Floppy bereits nur 1M ausreichen würden (weniger als die 2M oder 4M in den gleichzeitig erschienenen MegaST, und er hätte auch gleich passend MegaPC heissen können). Was auch da gesparte Grösse und Kosten negierte. Wobei das eigentlich gute Konzept ebenfalls pervertiert wurde. Danach hat Atari mit den PC2 bis PC5 (1988) generische PC Klone angeboten. Ohne Kompaktierung war wieder kein Vorteil gegen beliebige Taiwan Chip auf Karten Löter und Karten zu PCs Zusammenschrauber. Das zudem mit ausgerechnet dem PC4 mit 286 als letzten bringen (nach PC2+PC3 generische 8088 und PC5 386SX). Wonach sie prompt Lieferschwierigkeiten hatten, welche mit einem 286er von Mitac vertreiben überbrückt wurden. Was dann zur ABC Serie einkaufen und vertreiben führte. Ohne Eigendesign kein Vorteil gegen beliebige Taiwan Wiederverkäufer. Also hat das PC Abenteuer auch Atari nicht gerettet, nur einen Teil der ohnehin wenigen Resourcen vom ST abgezogen, den STE zumindest verzögert und vielleicht auch sein Video ausbauen verhindert.)

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, wenig 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, wenig Speicher, reine Abspielkonsole, kann auch so nicht überholen. Im Vergleich zu seinem Vorfahren Master System neben 320 Pixel breiteres Textfeld vor allem Scroll A und B mit 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 Superfami / SuperNES. 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 (und 286) basierten, selbst hinter 16/8bit 68008 (und 8088). Keine Tastatur oder Disk, wenig Speicher, reine Abspielkonsole, kann auch so nicht überholen. Der Mode 7 mit pseudo-3D Texturen reicht nicht um ihn noch zu retten. Hat im Vergleich zu seinem Vorfahren Famicom / NES vor allem weit mehr Speicher und Bildspeicher (sogar separate Zeichenspeicher und Fontspeicher) statt ModulROM basierte Fonts, sowie mehr Bandbreite und Layer und/oder bpp, ebenso massiv mehr Farben. Trotzdem ist es kein Wunder, dass die Mega Drive die Superfami / SuperNES 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 unpassend für Text wo man die vielen Pixel nutzen will. Ohne Farbattribute oder Farbregister auch nur in 4 festen Farben, fast auf MC6847 Niveau unten (nur leicht bessere Auswahl mit schwarz, und 512x256 statt 128x192 Pixel). Mit 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 aber wegen dem gerade bei Graphiken sinnlosem blinken trotzdem nur 8 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 Apple II und CGA. Das wohl die Folge von sowohl Spectrum Nachfolger wie auch Businessrechner Projekte zu einem Kompromiss zusammenlegen, mit zwar 2 Modi passend zu den beiden Nutzungen angezielt, aber bei beiden davon massiv versagt. (Man kontrastiere dies mit dem Atari ST, mit Schwarzweiss für Business und viele Farben für Spiele, beides richtig gemacht.) Dazu noch keine Sprites (wie Atari ST), aber auch ohne dessen 320 Pixel mit wählbaren 16 Farben. Somit schwächste Farben in der 16bit Generation. Zudem schwach mit dem langsameren nur 16/8bit 68008 Prozessor, und in erste 128k DRAM massive "Contention" davon noch 50% ausbremsen, weit hinter allen echt-16bit 68000 basierten. Er ist zudem mit nur 8 Farben sogar erstaunlich schwächer als sein erstaunlich guter 8bit Vorfahre ZX Spectrum mit dessen 16 Farben. Lediglich mit Prozessor und Speicher schlägt er diesen, und alle anderen 8bit, inklusive IBM PC 8088, sowie vielleicht noch die Superfami / SuperNES ihre 65816. Aber selbst Tastatur und Microdrive Endlosbandlaufwerke, sowie weit mehr Speicher können ihn 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, um mehr Zeilen zu bekommen, was mit dem 6x12 Pixel Font noch halbwegs gerettet wird. Aber gar keine Farben, trotz dass alle anderen 16bit diese haben. Selbst bei Schwarzweiss nur 1bpp, nicht mal 2bpp Graustufen. Damit selbst klar hinter dem Sinclair QL! Dies gibt ihm keine Chance. Somit schwächste Graphik dieser Generation, mit Abstand. Bei 21.8k nur 2/3 von Sinclair QL und Atari ST ihren 32k. Nicht mal dreifacher Apple II, nicht mal die Hälfte mehr als beim CPC 16k, und nicht mal ein Viertel mehr als beim Acorn BBC und KC 85/4 20.5k. Zudem ohne deren Farben und Modi. Alles Rechner welche ich daher über den Mac setze (und diese wiederum alle unter oder bestenfalls gleich dem C64!). Selbst Tastatur und Disk, sowie mehr Speicher, können ihn nicht mehr über die Konsolen hinauf retten. Zudem existierten jahrelang (Jan 1984 bis Sep 1986) keine auf dem Rechner laufende Programmiersoftware! Man musste dazu einen separaten schweineteuren LISA benutzen (und dort dessen separates "Lisa Workshop" Programmiersystem statt dem normalen "Lisa Office System" Desktopsystem). Was mit einem Mac alleine wie bei Konsolen nur Konsum erlaubte. Erst Macintosh Programmers Workshop (MPW) auf dem Mac Plus (1986) erlaubte dort zu entwickeln, als Ersatz nachdem die LISA bereits in 1985 eingestellt worden war! (Eigentlich war ein MacBasic vorgesehen und ist sogar geschrieben worden, aber Microsoft hat dieses mit Erpressung die Apple II Basic Lizenz nicht zu verlängern begraben.) Eigentlich eine sehr primitive Kiste für seine Zeit, weil eben bloss eine 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 nun dem Mac, der einzige 16bit Rechner ohne Farben und ohne Modi. Eigentlich wäre anstelle vom Macintosh ein vierfacher Apple II Plus angebracht gewesen, also etwa Atari ST mit Schwarzweiss Video, eben der Jackintosh! Der Mac ist dagegen bloss etwa der Apple 1 der 16bit Welt, wenn man ignoriert, dass er doch Bild aus DRAM hat. Oder der VC-20 der 16bit Welt, wenn man das halbierte Bild und den kleinen Speicher anschaut, aber ignoriert dass die Farben fehlen und er im Verkauf kein Billigrecher war trotz als solcher designt. 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. Diese leistete in 64k ROM weit mehr als dem Atari ST seine in 192k ROM! Das Resultat von 4 Jahre Entwicklung und Optimierung, statt in nur 1 Jahr zusammengeworfen worden.

(Trotzdem war diese Software für den Rechner zu viel, weil GUI und 16bit einfach nicht zusammenpassen. Zudem waren die Fenster auf dem kleinen 9" Monitor mit nur 512x342 Pixel sinnlos, und mit den ganzen Tests auf im Zeichenbereich bleibend auch noch bremsend. Weiter war der graphische Dateimanager ohne Harddisk sehr langsam. Ebenso war wegen anfangs zu wenig RAM swappen von Floppy langsam, sowie mit lediglich einem Laufwerk und zuwenig RAM für eine RAMdisk (der 512k wurde oft so genutzt) komplett unfreundlich. Was alles mit seiner GUI zum Spitznamen "Mickey Mouse Rechner" führte, sowie zusammen mit seiner Flut von Dialogboxen zum Spitznamen "Meckertopf". Was alles auch für den Atari ST galt, trotz vollem 8MHz Prozessor und 640x400 Pixel. Dazu kam visuell noch unpassender falls mit 640x200 Zeilen im Farbmodus. Selbiges galt beim Amiga, um 1/8 untertaktet und mit 640x200 stets visuell unpassend und dazu noch bei viele bpp gebremst. Ebenso galt bei Microsoft Windows auf 286er mit EGA 640x350 wegen 4bpp langsam. Noch schlimmer war es auf 8bit 8088er mit CGA 640x200, visuell unpassend und weit zu langsam, weshalb GEM und Windows mit 8088 Real Mode belasten statt 286 Protected Mode nutzen Unsinn war.)

(Erst die 32bit Generation lieferte genug Prozessor (über 10MHz) und Speicher (ab 1MByte) und Bandbreite (ab 10MByte/s) für brauchbare GUIs. Insbesondere hatten diese erst ausreichend Auflösung für Fenster, mehr als 640x480 für mehr als 80x30 Zeichen mit 8x16 100dpi Font, plus GUI Elemente, plus Fensterrahmen, mit noch genug von anderen Fenstern sehen, dass diese sich überhaupt lohnen. Dies mit trotzdem genug Farben für Graphik, ab 8bpp, oder zumindest schwarzweiss, ab 2bpp. GUIs wurden somit real brauchbar ab 800x600 8oder2bpp aus 512oder128k Bildspeicher, und erst echt gut ab 1024x768 8bpp aus 3/4MByte oder gar 1152x865 8bpp aus 1MByte. Ebenfalls hatten diese erst Harddisk mit kurzen Zugriffszeiten womit ein graphischer Dateimanager nicht schnarchlangsam wird. Also 386er/486er PC mit Super-VGA oder 68030 in Macintosh IIx bzw Atari TT bzw Amiga AGA. Alle ab um 1990, und somit erst 2 Chipgenerationen nach der Mac Einführung! Auch hatten erst diese ansprechend aussehende GUI Elemente, sowie selektierter Text Grau hinterlegt, angefangen mit dem ebenfalls 68030 basierten NeXT Rechner.)

(Was alles erst noch komplett vorhersehbar gewesen wäre! Zumal der Xerox Alto (1972) das Ziel hatte, als maximalen Forschungsrechner einem durchschnittlichen Bürerechner von +10 Jahre = 1982 zu entsprechen, um Erkenntnisse für diese erstellen und nutzen zu gewinnen. Dieser hatte dazu 606x808 1bpp Bitmap in 61k(!) Bildspeicher aus dem 128k Hauptspeicher mit dazu 100% der Speicherbandbreite plus Pagemode Doppelzugriffe nutzen, auf einem beinahe A4 Portrait Monitor, passend zum US "Letter" Format (8.5x11"), welches mit 6x12 Font und 72dpi Matrix 612x792 Bitmap entspricht. Der 32bit Nachfolger Dorado (1978), für +10 = 1988, war ein vierfacher Alto. Er brachte erst einen A3 Landscape Monitor. Sein Nachfolger Dandelion bzw Xerox 8010 (1980) brachte erst die Star GUI und Fenster und Desktop. Alle GUIs auf 1980er Rechner, mit zumeist sogar nur A5 Monitore, waren damit weit verfrüht! (Hier passende 32k würden auf einem Portrait Monitor 480x540 erlauben mit 80x45 Zeichen in 6x12 Font. Selbst 480x660 mit 80x55 Zeichen in 38.6k wären gerade noch machbar.) Weshalb MS-DOS so dominant werden konnte, ohne GUI Last, mit Auswahl von nur Kommandozeile oder mehreren zeichenbasierten Dateimanagern (wie Norton Commander oder PC Shell oder Xtree) oder falls man will mehreren GUIs (GEM oder Windows). Wobei selbst Dateimanager sich auf PCs erst mit Harddisk durchsetzten, und GUIs sowieso. (Amiga konnte allerdings die ganze Bildausgabe zwischen Programmen umschalten, und zumindest damit entweder Kommandozeile oder Desktop haben. Weiter war sein Bootscript anpassbar, um den Desktop gar nicht zu laden, oder man konnte direkt in ein Spiel booten ohne überhaupt den Desktop auf der Bootfloppy zu haben. Die Shell wurde aber erst in 1.3 addiert. Atari ST erlaubte TOS Programme den ganzen Bildschirm mit VT52 Emulation anzusprechen. Als solche gab es auch ladbare Kommandozeilen Interpreter von Drittanbietern. Macintosh vor MPW hatte nicht mal diese Option, und auch MPW war stets in einem GUI Fenster drin.))

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. Erweiterte Super-EGA Klone addierten nur Auflösung. 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 vorbeizieht. Die Sega Mega Drive und SNK Neo Geo und Nintendo Superfami / SuperNES verlieren maasiv an der Auflösung, mit zudem Mega Drive und Superfami / SuperNES an fehlenden Bitmaps. Auch die fehlenden Tastaturen und Disks verlieren weiter. 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 sowieso locker, schlicht weil der gar keine Farben kann, oder auch nur Graustufen, und weniger Auflösung hat. Selbst der QL hat keine Chance, mit nur 4 oder 8 festen Farben, und weniger Auflösung.

(Die IBM PC VGA kommt mit dem MCGA Modus als allererste auf 8bpp, und damit vor allen anderen Rechnern hier! Wenn auch anfangs nur mit 320x200 8bpp in 64k, bloss 1/4 von ihren 256k ausnutzend. Zumindest bis erweiterte Super-VGA Klone 640x480 oder gar 800x600 8bpp addierten. Es reichten aber bereits die 320x200 dank schaltbaren Modi, solange man keine Sprites brauchte. Was aber mit genug PC Prozessorleistung (spätestens ab 486er) plus 8bpp weniger wichtig wurde, gerade auch bei Illustrationen dekomprimieren oder gar 3D Szenen rendern. Damit wurde der MCGA Modus zum Anfang von allem brauchbaren PC Gaming, und das Fehlen von vergleichbaren bei Amiga und Atari ST zum Anfang von deren Abstieg. Addiert man PCs damals noch kompatibel erweitert, sowie wegen Standarderzeugnis mit vielen Konkurrenten, mit einer Auswahl an vieler beliebiger Taiwan Klone, damit sowohl billig werdend, wie auch versagende Firmen einfach ausgesiebt werdend. Addiert man zudem Amiga und Atari ST versagen die dummen Abspielkonsolen auszurotten, und sie wurden statt dessen zwischen PCs und Konsolen in die Schere genommen, was zum Ende dieser beiden verbleibenden Homecomputer Hersteller führte. Mit der MCGA haben die PCs auch noch genau die 64k Limite in der Einleitung erreicht, und somit ist das auch das Ende dieser Übersicht.)


Home | Artikel | VCFe Videoarchitekturen als visuelles Medium

Diese Seite ist von Neil Franklin, letzte Änderung 2021.11.26