Home | Artikel | VCFe Video als visuelles Medium

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


Inhalt

Einführung

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

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

Heute sind wir uns im PC Zeitalter gewohnt, dass auf einem Bildschirm beliebiges angezeigt werden kann, auch Photos oder gar Videos, egal ob mit einer Kamera aufgenommen, oder im Rechner gerendert. Dies setzt aber hohe Ansprüche wegen Bilddatenmenge an einen Rechner, sowohl was den Speicherplatz wie auch insbesondere die Speicherbandbreite anbegeht. Dies wurde erst Ende 1980er bis Anfangs 1990er generell machbar. Etwa ab der 1988er IBM VGA Karte ihrem MCGA Modus mit dessen 320x200 8bpp (=64k) wurde es benutzbar (wie in vielen damaligen Spielen gesehen), und ab SVGA 640x480 8bpp (=300k) auch komfortabel. Dies weil 8bpp für RGB 6*6*6=216 Farben oder RRGGBBII 4*4*4=64 Farben in 4 Helligkeitsstufen tauglich ist, sowie 320x200 bis 640x480 die untere Grenze an für alles brauchbarer Auflösung ist.

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

Genau wie man beim Zeichnen aber wissen muss, wie man mit dessen gestalterischen Limiten und Möglichkeiten umgeht, wie man das Entscheidende trotzdem trifft, mussten auch Spielkonsolen und Homecomputer Videochip Designer dies wissen, aber ebenso alle auf diesen Rechnern gestaltenden Graphiker und codierenden Programmierer. Dieser Vortrag beleuchtet genau die dazu relevanten Eigenschaften, und wie damit umgehen. Dabei liegt der Fokus vor allem auf Spielszenen und bewegten Objekten darin, weil das die grössten Ansprüche stellt, und somit einen kritischen Test abgibt. Aber auch Text editieren muss effektiv gehen, und sei das nur um Programmcode in den Rechner einzugeben!

Die Spielregeln

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

Es verbleiben damit vor allem farbige Homecomputer (plus ein paar Videokarten), welche interessanterweise fast alle entweder auf TTL Logik basieren, oder Videochips haben welche eigentlich für Spielkonsolen designt wurden. Daher werden auch dedizierte Spielkonsolen als solches hier addiert.

Die Kontrahenden

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

Cromemco TV Dazzler von 1976

Kein Rechner, sondern ein Paar vom Karten (Digital bzw Analogteil) für S100 Bus Rechner (wie dem MITS Altair 8800 von 1975). Früh erschienen, daher alles reine TTL Logik, keine VLSI Chips, dementsprechend primitiv. Nur 4 Bitmap Modi, weil technisch einfacher als Textmodi oder gar Zellmodi. Kein eigenes RAM, um solches mit dem restlichen System zu teilen, um Kosten zu sparen, auch so schon 2 Karten Digital und analog. Braucht wegen Timing aber SRAM, was damals mit 1kx1 SRAMs nur 1k mit 8-Chip bzw 2k mit 16-Chip pro Karte ergab. Bitmap daher nur 2 Grössen 0.5k oder 2k Speicher umschaltbar, kombiniert mit 2 Modi 4bpp "normal" sowie 1bpp "X4". Ergab Auflösungen von nur 32x32 oder 64x64 4bpp sowie 64x64 oder 128x128 1bpp. Farben bei 4bpp sind bereits volles 2*8=16 RGBI, sowie bei 1bpp Schwarz+1*RGBI-Register. Selbst bei 128x128 1bpp erlaubt dies aber nur gerade 32x16 Zeichen mit 4x8 Font, bzw eher 20x10 mit dem damals gewohnten 6x12 Font.

Apple II von 1977 (und II+ sowie IIe)

Nachfolger des Apple I (hatte nur Text, 40x24, 64 Zeichen Font, keinerlei Grapik, dieses war eine Variante des Don Lancaster TV Typewriter 2*(32x16) von 1973). Früh erschienen, daher alles reine TTL Logik, keine VLSI Chips, dementsprechend primitiv. Trotzdem aber umschaltbar 3 Modi, Text und Blockgraphik und Bitmap:

Commodore PET 2001 von 1977 (und CBM Serie)

Früh erschienen, alles reine TTL Logik, keine VLSI Chips, und billig, dementsprechend noch primitiver. Nur 1 Textmodus. Text 40x25 Zeichen, mit 8x8 Font und zwei festen ROM Sätzen von 128+revers Zeichen. Diese haben neben 64oder96 ASCII auch 2x2 Blockgraphik drin (gibt 80x50) und viele andere Graphikelemente, die beste Pseudographik weil auch noch einen zweiten Satz Zeichen ohne Kleinbuchstaben für mehr Elemente. Nur Schwarzweiss, auf dem eingebauten Spezialmonitor. (CBM Serie 3000er von 1979 sind leicht überarbeitet für mehr Speicher, 4000er und 8000er von 1980 haben noch mehr Speicher, sowie MOS6545 Timing Chip (eine Variante des MC6845) und grösseren Monitor, 8000er sind dabei Modelle mit 80x25.)

Tandy TRS-80 von 1977

Früh erschienen, alles reine TTL Logik, keine VLSI Chips, und billig, dementsprechend auch sehr primitiv. Nur 2 Textmodi. Text 32x16 oder 64x16, mit ?x? (unbekannt) Font (angenommen 6x12) und festem ROM Satz von 64 (oder amgeblich 96) ASCII Zeichen (je nach ob mit 7bit oder 8bit Videospeicher laufend). Dazu vom achten Bit zeichenpositionweise gesteuert mischbare 2x3 Blockgraphik ohne Font hartverdrahtet (gibt 64x48 bzw 128x48). Nur Schwarzweiss.

Atari VCS/2600 von 1977

Reine Spielkonsole, schritt aufwärts zu Prozessor und Module benutzen, statt nur hartverdrahteter Pong (und Derivate) Logik. Chip TIA (Television Interface Adaptor), für Video und Sound und Paddles und Feuerknöpfe, dementsprechend primitiv. Nur 1 Bitmapmodus, wegen einfacher als Textmodi und auch passender für Spiele, aber dies trotz extrem wenig Speicher, nur 128 Bytes! Bitmap ist nur 40x1(!) 1bpp, genauer sogar nur 20 Pixel/Bits an chipinternem(!) Videospeicher (4+8+8=20)bit an Register in der TIA) welche 2mal pro Zeile ausgegeben werden, das zweite mal wiederholt oder gespiegelt. Alle Zeilen werden identisch wiederholt, was nur vertikale Streifenmuster ergibt, ausser die Software überschreibt vorzu die TIA Register! Dafür ist zwecks synchronisierung die aktuelle Zeilennummer auslesbar, sowie der Prozessor bis zum nächsten Zeilenanfang per Waitstates pausierbar.

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

2Bild+2Player/Missile+1Ball=5 Farben aus 16*8=128 (16 NTSC Farbtöne "Chroma", und explizit 8 Helligkeitsstufen "Luma"), und damit eigentlich völlig überdimensioniert.

(VCS Spiele ihre Software besteht wegen alle Zeilen gleich sein vor allem daraus, die Zeilen Pixel und Player Muster und Missile/Ball Breite/Aus während dem Bild zeichnen vorzu umzuschreiben, sowie zwischen den Bildern die Joysticks bzw Paddles abzufragen und mit der Spiellogik auszuwerten inklusive Sprite Positionen setzen.)

Atari 800 von 1979 (und wenig-RAM plus Folientastatur Subset 400)

Anfangs als Spielkonsole designt, als "etwa verdoppelten" Nachfolger der VCS/2600, weil dieser wegen primitiv zurecht auf nur 3 Jahre benutzbar angenommen wurde. Aber 1978 von Management geblockt, um das bestehende Produkt nicht zu konkurenzieren. Dann das Design als Homecomputer 800 recyclet und erweitert (und Subset 400). Dann doch noch 1982 als Konsole 5200, aber nicht zu den 400 und 800 kompatibel (und auch nicht zum VCS/2600). Dann 1983 verbilligt zu 800XL (und Subset 600XL). Zum Schluss noch 1985 umgestylet als 65XE (und speichererweitert 130XE). Dann kam 1986 eine 5200+2600+neueres Kombination als 7800 Konsole, aber bereits 1987 durch die XE basierte und damit schwächere XEGS ersetzt, was Atari bei den Spieleherstellern endgültig diskreditierte. Tod durch Kopfschuss per Management.

Chips CTIA/GTIA (Color Television Interface Adaptor, einst geplante bessere Bitmap Konsole) und ANTIC (AlphaNumeric Television Interface Controller, Textmodi bzw eben Zellmodi weil spieletauglicher Mechanismen addiert zum Homecomputer), sowie für nicht-graphisches POKEY (Paddles plus Tastatur plus Sound plus UART), alle 3 zusammen die kleinere TIA im VCS ersetzend, und damit weit mehr leistend. Umschaltbar 6 Zellmodi und 8 Bitmapmodi:

Zellmodi zwischen verschiedenen Auflösung und bpp und Farben abgestuft:

Bitmapmodi zwischen verschiedenen Auflösung und bpp und Speicherverbrauch abgestuft:

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

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

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

1Rand+4Bild+4Player/Missile=9 Farben (alle Missiles als fünften Player nehmen die vierte Bildfarbe) aus 16*8=128 (16 Farbtöne und 8 Helligkeitsstufen (ausser GTIA "$40" mit 16 Hell), vermutlich die identischen wie im VCS/2600). Wie man sieht ist dies ein massiv komplexer Chipsatz, nur noch vom Amiga überboten, der vom gleichen Designer stammt, und seine nachfolgende Arbeit ist!

Texas Instruments TMS9918 VDC Chip von 1979 (erweitert zu TMS9918A in 1981)

In diversen Geräten, darunter TI-99/4(A) von 1979 bzw 1981, sowie Coleco Colecovision von 1982 (Konsole) und Adam von 1983 (Homecomputer), sowie Sega SG-1000 (Konsole) und SC-3000 (Homecomputer) von 1983 (und auch erweiterte im Master System von 1987), sowie am bekanntesten in allen MSX ab 1983 (dort auch erweiterte Yamaha 9938 in MSX 2 ab 1985, bzw 9958 in MSX 2+ ab 1988).

Einzelner Chip TMS9918 VDC (Video Display Controller), mit separatem 16k Speicher (VRAM) (bzw ab 9938 sogar 128k+64k), mit eigenem Bus zu diesem, daher asynchron von beliebigem Prozessortyp (9900 in TI-99/4(A) und Z80 in den anderen obigen), sowie diesen nur bei Videozugriffen bremsend, und nicht wie im Atari 800 den ganzen Prozessortakt auf 7/8 bremsend. Aber mangels Pins keine 16k Abressierung vom Prozessor und seinen Adressmodi her, braucht eigene Adressregister, umständlich und langsam (ist dafür aber auch nicht auf 64k limitiert). (All dies gilt auch für die in der Einleitung erwähnten µPD7220 und EF93xx Chips.)

Umschaltbar 1 Text und 1 Zell und 1 Blockgraphik und 1 Bitmap Modi:

Dafür fehlen jegliche 2bpp Sachen (ausser ab 9938). Kein fein scrollen (die 9938 addiert vertikal, die 9958 auch horizontal, auch das Sega Master System addiert fein scrollen). Die 9938 erlaubt auch vertikalen Overscan, mit 212 statt 192 Zeilen, sowie interlacing auf 2*192=384 bzw 2*212=424. Ebenso statt 15 NTSC Farben auch 16 aus 512 RGB Farben (ausser G7 feste 256 Farben).

Dazu Sprites, in allen Modi ausser "0" weil dies anderes Timing hat, 8x8 oder 16x16 1bpp (genauer 1x1 oder 2x2 Zeichen auf dem Font(!) (die 9938 erlaubt neben 1bpp auch 2/3/4bpp Sprites), mit horizontal volles 256 oder halbes 128er Pixel Raster, auf 256er positionierbar, gleichzeitig auch vertikal ihre Zeilen doppelgezeichnet. Jedes hat eine eigene Farbe. Wobei entweder alle 8x8 oder alle 16x16 sind ("Size"), sowie alle 256er+normal oder alle 128er+doppelt ("Magnification") (es hat dazu nur 2 global wirkende Flags). Stets automatisch geladen pro Zeile, nur für 8 oder 16 Zeilen statt alle Zeilen von Bild, daher neben horizontal auch vertikal positioniert per Register. Zeigt dann die erstpriorisierten 4 aktiven einer Zeile, von 32 angemeldeten (die 9938 zeigt erste 8 von 32), dies nur möglich weil Sprites nicht alle Zeilen hoch sind. (Die Sprites werden erstmals hier so benamst, nach einer Sorte Spuk den man sieht aber, der nicht dort ist, weil man hier die Sprites im Bild sieht, sie aber nicht im Bildspeicher vorhanden sind.)

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

In diversen Geräten, darunter TRS-80 CoCo und Acorn Atom und Dragon 32/64, sowie dem oben erwähnte NEC PC-6001, aber auch viele Hongkong Rechner wie dem Laser 200. Ein Chip MC6847 VDG (Video Display Generator), bzw zwei mit dem MC6883 SAM (Synchronous Address Multiplexer). Wie beim Atari 800 den Prozessortakt auf 7/8 bremsend. Umschaltbar 1 Text und 1 Blockgraphik und 8 Bitmapmodi:

Kein fein scrollen. Keine Sprites. Der schwächste Chip in dieser Liste, unterhalb von einigen TTL Rechnern.

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

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

Umschaltbar 2 Zellmodi. Diese wegen viertel bzw halbe Breite nur 22x23 Zeichen (wenigstes etwas besser als strikte viertel bzw halbe mit 20x25 zu benutzen) (mit Overscan kann er angeblich bis zu 28x32), mit 8x8 1bpp bzw 4x8 2bpp (wie Atari 800) Font und variablem ROM/ModulROM/RAM Satz von 256 Zeichen. Braucht so nur die Hälfte von etwa 2MHz Speichertakt. ROM hat 2x2 Blockgraphik (gibt 44x50) sowie alle PET/CBM Graphikzeichen darin. Dazu 4bit FarbRAM mit Vordergrund Farbattribut (jedes Zeichen hat eigenes von 16 NTSC Farben, ohne Helligkeitsstufen), mit den identischen unteren Adressbits A0..A9 nutzend, womit dies strike ein 8+4=12bit Videochip ist! Kein Prozessortakt auf 7/8 bremsen, weil bei diesen breiten Pixeln auch so wenig Verfärbung entsteht, selbst mit beliebigen Farben, nur 6von8breite Zeichen mit 2breiten Vertikalen reicht. Die aktuelle Zeilennummer ist auslesbar, aber kein Interrupt davon. Kein Bitmap. Kein fein scrollen. Keine Sprites. Wie die TIA im VCS auch Sound und Paddles im selbigen Chip.

Sinclair ZX80 von 1980 (und ZX81 von 1981)

Absoluter Minimalstrechner, nur ein Schritt oberhalb eines Hextasten plus 7-Segmentanzeige Maschinencode Lernsystemes, quasi Basic Lernsysteme. ZX80 noch reines TTL, neben Prozessor und 1*4k ROM und 1*1k SRAM und 1 7805, noch genau 18 Chips, dementsprechend extremst primitiv, selbst die Videospeicher Bytes werden vom Prozessor ausgelesen und Werte 0..127 vom Videogenerator "nebenher" ausgegeben, dem Prozessor dabei NOP Befehle vorgaukelnd (128..255 brechen die Ausgabe ab und werden dem Prozessor durchgereicht, Zeilen enden soweit mir bekannt mit RETurn Befehl (C9,201)). Nur 1 Textmodus. Text 32x24, mit 8x8 1bpp Font und festem ROM Satz von 64+revers Zeichen (0..127). Trotzdem mit 2x2 Blockgraphik und 1x2 halbhell Raster, weil nur einen Teil von ASCII64 drin (Zeichensatz ist: Leerzeichen 7*Blockgraphik 3*Raster " £ $ : ? ( ) > < = + - * / ; , . 0..9 A..Z)! Um Platz im nur 1k grossen Speicher zu sparen werden Zeilen ohne rechts verbleibende Leerzeichen und das Bild ohne unten verbleibende Leerzeilen gespeichert. Je mehr Platz der Benutzer mit Programm und Variablen verwendet, umso weniger Zeilen verbleiben bevor der Rechner alte wegscrollt trotz noch Bildschirmplatz! Nur Schwarzweiss. Kein fein scrollen. Erst recht keine Sprites.

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

IBM CGA von 1981

Kein Rechner, sondern eine Karte für IBM PC Bus. Umschaltbar 2 Text und 2 Bitmap Modi. Von Prozessor separate Karte, mit eigenem Speicher (wie TMS9918), daher auch asynchron. Aber mit Adressen vom Prozessor mit dessen Adressmodi nutzend (ungleich TMS9918, als entscheidenden Vorteil). Für Timing und Adressen MC6845 Chip, Datenpfad TTL, daher auch halb-primitiv. Trotzdem aber umschaltbar 3 Modi, 1 Text und 2 Bitmapmodi:

Kein fein scrollen, ausser byteweise durch MC6845 Anfangsadressen setzen. Keine Sprites. Viel Speicher und hohe Auflösung aber Bitmapmodi keine vielen bpp oder Farbwahl, und Textmodi welche weder mit RAM Font noch guter Blockgraphik aushelfen können. (Ausser man nimmt Text 80x25, stellt es um auf 80x100 Zeichen(!), aber mit flachem 8x2 1bpp Font kompensiert, dann gibt es mit 8k mit den 2x1 Blockgraphik Zeichen 221 bzw 222 gefüllt, und 8k nur die beiden Farben für die zwei 4x1 grossen Pixel nutzen brauchbare aber undokumentierte 160x100 in 16 Farben, was als "Tweak Mode" bekannt ist.)

Acorn BBC Micro von 1981

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

Farben 2/4/16 von 8 RGB (plus blinkend durch reversieren), auf Fernseher oder Videomonitor oder RGB Monitor. Kein fein scrollen, wieder ausser durch MC6845 Anfangsadressen. Keine Sprites, aber kann dies mit den 4bpp kompensieren im Gegensatz zur CGA, nur leicht mehr Shifter Logik und Umschalter (etwa +10%). Genau dieses kleine Mehr macht den Unterschied aus von CGA schrottig zu BBC anständig!

Commodore 64 von 1982 (bzw VIC-II Chip auch 1982)

Anfangs auch als Spielkonsole Max-Machine (bzw Ultimax oder VIC-10) mit nur 4k Speicher designt, aber dann als Nachfolger vom VC-20 mit 64k verkauft. Dann erweitert auf 128k als Commodore 128 (mit einem VIC-II E, sowie einem zusätzlichem VDC Chip, dieser wie bei TMS9918 mit eigenem 16k oder 64k Speicher asynchron vom Prozessor mit eigenen Adressregistern). Der VIC-II (Video Interface Chip II) als erweiterten VIC vom VC-20 hat fast all dessen guten Eigenschaften geerbt, aber alle Schwächen fehlen. Zudem kamen weitere nette Sachen dazu. Die Designer hatten explizit Features anderer Chips und Rechner verglichen, und daraus ihre Wunschliste erzeugt. Die Sprites wurden explizit wegen der TMS9918 addiert, und daher auch so benamst.

Umschaltbar 3 Zellmodi und 2 Bitmapmodi:

Trotz beliebigen Farben kein Prozessortakt auf 7/8 bremsen (weshalb auch 320 Pixel aber schmales Bildfenster wie ein 256er Pixel Rechner), nur bessere Schaltung mit 6von8breit Zeichen mit 2breit Vertikalen reicht. Wohl vor allem weil der ca 8MHz Pixeltakt seine /2=4MHz Wellen nicht auf die 14.318/4=3.579MHz oder 17.734/3=4.434MHz fallen, erst recht nicht mit einem 2breiten Vertikalen Font seinen 2MHz Wellen. Weshalb man sich fragt, warum andere so sehr 1/8 Prozessortakt zu opfern bereit waren. (Vermutlich wegen billigem 14.318/16=0.895MHz Divisor bei NTSC, aber bei PAL dann aufwendigen 17.734/20=0.8867MHz, ausser man nimmt den Apple II analog Umwandler. Womit der C64 bei PAL den identisch teuren 17.734/18=0.985MHz benutzt, und bei NTSC konsistent einen 14.318/14=1.023MHz nimmt.)

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

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

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

1Rand+4Bild+(8+2)Sprite Farben plus FarbRAM für jedes Zeichen, aus 16 NTSC (vermutlich identisch mit VC-20). Wie man sieht ist dies ein mengenmässig sehr leistungsfähiger Chip, trotz strukturell weit einfacher zu sein als beim Atari 800.

Sinclair ZX Spectrum von 1982

Nachfolger der ZX80 und ZX81. Wie ZX81 alles in einem ULA (Uncommitted Logic Array) Gate Array, auch dessen Video, daher halb-primitiv. Nur 1 Bitmapmodus, da ausreichend Bitmap Speicher jetzt billiger ist als Text oder gar Zell Logik! Bitmap 256x192 1bpp (wie beim TMS9918A "2" ("Graphic 2")). Aber mit nur alle 8x8 Pixel (wie beim C64) 2 Farben aus 16bzw8 plus blinkend (wie bei der CGA). Aber dies ohne dem C64 seinem 2bpp "Multicolor", was oft in "Attribute Clash" resultierte, wenn in einem 8x8 Feld mehr als 2 Farben gebraucht werden (was beim TMS9918 wegen dessen kleinerem 8x1 Feld weit weniger zutraf, dort als "Color Spill" bekannt ist). Erlaubt daher auch 32x24 Zeichen mit 8x8 Font. Kein fein scrollen. Keine Sprites.

Nintendo Family Computer (Famicom) von 1983 (bzw NES von 1985)

Hauptsächlich als Spielkonsole designt, aber erweiterbar mit Tastatur (und anderem) an Erweiterungsport, sowie einem Floppylaufwerk mit BootROM plus ErweiterungsRAM plus Controller Untersatz (DiskSystem) am Modulport zu einem vollen Homecomputer (im Gegensatz zu Sega ihren separaten SG-1000 und SC-3000 Modellen). Beim Export mechanisch umgebaut und funktionell reduziert zum Nintendo Entertainment System (NES) in 1985, ohne Tastatur oder DiskSystem, nur noch eine reine Spielkonsole. Keine Paddles, aber dafür der erste Rechner mit Joypads neben Joysticks (wobei zu Atari Joysticks kompatible Joypads problemlos machbar sind).

Chip PPU (Picture Processing Unit), sowie Sound im Prozessorchip integriert. Nur 1 Zellmodus, kein Bitmap, mangels Speicherplatz. Benutzt wie TMS9918 separates VRAM, aber nur 2k davon (und nur 2k sonstiges RAM, sogar unter der VC-20). Dieses mit eigenem Bus, und den Prozessor bei Videozugriffen während der ganzen Bildausgabe komplett stoppend (kein schneller Speicher wie bei der TMS9918), man kann nur während dem Bildrücklauf zeichnen. Wenigstens ist er vom Prozessor direkt adressiert (wie bei der CGA).

Zell 32x30 Zeichen. Was aber bereits inklusive Overscan ist, wegen 4/3 breiten Pixeln relativ zu Atari 800 oder TMS9918 oder MC6847. Womit die 32 dort etwa 44 Zeichen entsprechen würden, weshalb hier real etwa 28 Zellen breit für Text nutzbar sind. Dies dafür aber mit 8x8 2bpp Font (sehr detailiert und farbig, ohne auf 4x8 Font halbieren zu mössen) und variablem ROM/ModulROM/RAM/ErweiterungsRAM Satz von 256 Zeichen. Jeweils 2x2 Zeichen (also 16x16 Pixel) haben ein 2bit FarbRAM Attribut, für 1 von 4 Sätzen von 3 Vordergrundfarben. Wie viele obige Rechner auch mit den Prozessortakt auf 7/8 bremsen.

Weiterhin fein scrollen horizontal mit pro Zeile variabler Menge, was Parallaxeffekte erlaubt (vorne/unten schneller scrollend als hinten/oben), und vertikal innerhalb eines Zeichens (erlaubt Splitscreen Effekte).

Dazu Sprites, 8x8 oder 8x16 2bpp, mit horizontal volles 256Pixel Raster, auf 256er positionierbar, sowie horizontal und vertikal spiegelbar. Stets automatisch geladen, aber 8 sichtbare von 64 angemeldeten (somit gleiche maximale Pixelmenge wie die TMS9918, aber wegen 2bpp farbiger doppelte Datenmenge).

1Rand/Hintergrund+4*3Zeichen+4*3Sprite=25 NTSC Farben aus 12*4+2*3=54von64 (12 Farbtöne in 4 Helligkeiten plus 2*4 Graustufen mit 2 Duplikaten). Wie man sieht ist dies ein mengenmässig graphisch sehr leistungsfähiger Chip, aber textuell gering, trotz immer im Zellmodus!

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

Gemacht als verbesserten VC-20 Nachfolger, doppelt getaktet (aber dann wie beim Atari 800 auf 7/8 gebremst) und mit mehr Speicher und besserer Graphik, aber trotzdem billiger als dem Commodore 64, aber ebenso weniger leistungsfähig als dieser. Ein Chip TED (TExt Display, trotz dass er auch Graphik kann). Alle 2+1 Zell und 2 Bitmapmodi vom Commodore 64, mit leichten Änderungen, aber keine Sprites. Damit sind die Zellmodi "normales" 40x25 Zeichen (den grossen VC-20 Mangel korrigiert), mit 8x8 1bpp bzw 4x8 2bpp Font (sowie "Extended" mit 4 Hintergrundfarben) und variablem ROM/ModulROM/RAM Satz von 128+invers oder 256 Zeichen, sowie Bitmapmodi 320x200 1bpp oder 160x200 2bpp.

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

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

(Damit waren C16 und C116 gute VC-20 Upgrades im Billigmarkt, vor allem in Mexiko bzw Ungarn, zumal sie neben mehr Video und Speicher auch noch schnelleren Prozessor hatten. Der Plus/4 hatte zudem als reinen "farbigen PET" Homebusiness Rechner mehr in Basic nutzbares RAM, eine bessere 4 statt 2 Tasten Cursorsteuerung, ein am Modulport passendes 1551 Floppylaufwerk (welches mit Parallelkabel etwas schneller war als dem C64 seine sehr lahme bitbanging 1541 Floppy mit Serialbus), sowie eine Hardware UART für Modems (der Atari 800 verwendet seine UART im POKEY für dessen schnelleren SIO Port Serialbus und 810 Floppy).)

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

Ziel besser als den "schwangeren Taschenrechner" (O-Ton Herstellers) des Sinclair Spectrum zu sein, mit echter Tastatur und 80 Zeichen, aber billiger als einen Acorn BBC, mit dafür einfachste Hardware. Er verwendet sogar den selbigen RGB Monitor Stecker wie der BBC, und das selbige Basic wie der Z80 Zweitprozessor zum BBC. Für Timing und Adressen MC6845 Chip (wie BBC und CGA), Datenpfad ein Gate Array, daher auch halb-primitiv. Umschaltbar nur 3 Bitmap Modi, kein Teletext:

Farben 2/4/16 aus 27 RGB auf mitgeliefertem RGB Monitor (zugleich Netzteil vom Rechner). Kein fein scrollen, wieder ausser durch MC6845 Anfangsadressen. Keine Sprites, aber kann dies wieder mit den 4bpp kompensieren im Gegensatz zur CGA, nur die etwa 10% mehr Shifter und Umschalter. Genau dieses kleine Mehr macht wieder den Unterschied aus von CGA schrottig zu CPC (und BBC) anständig, und hier noch mit mehr RGB Farben erweitert! (Die 464plus und 6128plus von 1990 addierten 32 von 4096 Farben und fein scrollen sowie Sprites, waren aber 5 Jahre nach den 16bit Atari ST und Commodore Amiga erschienen als 8bit nicht mehr relevant.)

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

Mit 85 im Namen weil in 1984 noch als HC900 Homecomputer geplant, in 1985 zum Kleincomputer umspezifiziert und neu nummeriert. DDR Rechner, keine VLSI Chips, alles reine TTL Logik, dementsprechend sehr primitiv. Nur 1 Bitmapmodus (wie beim Spectrum, auch weil DRAM billiger als Logik). Bitmap 320x256 1bpp (256 weil nur 50Hz Moni wie beim Acorn BBC, mehr als Commodore 64 320x200), für alle 8x4 Pixel 2 Farben aus 16 (mehr als Spectrum alle 8x8, aber weniger als TMS9918 alle 8x1, so immer noch auf "Attribute Clash" halb anfällig). Erlaubt daher sogar 40x30(von32) Zeichen mit 8x8 Font. Dazu wird die ohnehin langsame 2oder2.5MHz UB800 auch noch im Prozessortakt auf 1.75MHz gebremst. Warum keine 4MHz UA880 drin ist weiss ich auch nicht, vermutlich weil eben als Homecomputer konzipiert, und auch beim KC 85-4 erweitern mit 1.77MHz nicht korrigiert. Wie CGA eigene 16k Videospeicher, vom Hauptspeicher abgetrennt, aber vom Prozessor adressiert.

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

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

Apple Macintosh von 1984

Halb ausser Konkurrenz, weil 16bit. Nur 1 Bitmapmodus. Alles reine TTL Logik, keine VLSI Chips, teils noch PALs, dementsprechend sehr primitiv für seine Zeit. Nur 1 Bitmapmodus aus 16bit Speicher grosse 512x384 1bpp, aber nur Schwarzweiss auf dem eingebauten Spezialmonitor, daher auch keine Farben möglich. Nicht mal 2bpp Graustufen gibt es (daher wurde auch selektierter Text früher in revers statt mit Grau hinterlegt angezeigt). Eigenartig ist 0=weiss und 1=schwarz, weil Apple glaubt Bildschirme (selbtleuchtend) wie Papier (reflektiv) behandeln zu müssen. Erlaubt 85x32 Zeichen mit 6x12 1bpp 72dpi Font (womit halbe Auflösung für 2bpp selbst mit einem 4 Pixel breitem Font nur auf 64 Zeichen breiten Text kommen würde!), minus GUI Platzverlust erlaubt noch etwa 80x24. Kein fein scrollen. Keine Sprites.

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

IBM EGA von 1984

Ganz ausser Konkurrenz, weil aus gigantischem 4*64=256k (und damit 32bit breitem!) Speicher laufend! Hier nur als Beispiel, was man damals schon mit Masse machen konnte. Kein Rechner, sondern eine Karte für IBM PC Bus (auch für 8bit PC/XT, nicht nur 16bit PC/AT ISA Bus!). Wie CGA mit eigenem Speicher und asynchron, aber ebenfalls mit Adressen vom Prozessor mit dessen Adressmodi nutzend (aber nur 1*64k Adressraum davon nehmend, weil als 64kWorte@32bit verwertet!). Als zwei Gate Array Chips gebaut, die eine einen erweiterten MC6845, die andere den Datenpfad. Dies weil IBM grosse leistungsfähige Gatearrays verwendet hat, wie sie auch in Grossrechner Prozessoren verbaut werden, weshalb IMB solche CHips selber herstellen konnte.

Zellmodus statt Textmodus zu 80x25 Zeichen CGA kompatibel, aber mit neu 8x14 1bpp Font und RAM Satz von 256 Zeichen (strikte schaltbar zu mit Attributbit3 2von4 mal 256 wählbar), sowie 80x43 Zeichen, mit altem 8x8 Font. Bitmapmodi einerseits CGA kompartibel 640x200 1bpp und 320x200 2bpp. Mit anderseits dazu auch 640x350 1..4bpp. Dies mit Bitplanes statt Chunks (wie beim KC 85-4), mit gleichem Font bei variablen bpp Vorteil, aber ohne "Ghosting" weil mit einem aufwendigen 8zu(1..4*8)=32bit Pixelprozessor die Planes synchron bewegbar sind (neben auch bewegen beschleunigend und den Adressraum auf die 64kWorte erweiternd). Davon 4*28k nutzend (oder einen solchen Ausschnitt aus bis zu 4*64k Bild), mit 16 Farben aus 64 RRGGBB. Wie beim Mac geht dies nur auf einem EGA Spezialmonitor. Ebenso wurde ein Vertical Blank Interrupt (VBI) addiert.

(S-EGA Clones konnten mit gleichem Speicher auch 640x480 4bpp (4*38k) oder nachdem Multisync Monitore erschienen auch mit ausreichend Bandbreite sogar 800x600 4bpp (4*60k). Nur die Bitplanes 4bpp Limite verhinderte obiges 64k 320x200 8bpp oder gar 640x400 8bpp mit dieser Masse zu erschlagen!)

(Noch mehr ausser Konkurrenz ist die davon erweiterte VGA von 1988. Als 1 Gaterarray, mit EGA-erweitertem MC6845 als Teil davon. Zell 80x25 CGA kompatibel, aber nun mit (8+1=9)x16 1bpp Font, sowie 80x50, mit (8+1=9)x8 Font (sowie mit 2oder4von8 mal 256 Zeichen). Bitmap addierte als MCGA Modus genau obige 320x200 8bpp (mit Chunks), sowie offiziell 640x480 4bpp (mit Bitplanes), mit 256 bzw 16 Farben aus 262144. Erlaubt 80x30 mit 8x16 1bpp 100dpi Font, sowie 80x40 mit 8x12, sowie 80x60 mit 8x8. Wieder nur mit VGA Spezialmonitor, dem ersten mit dem HD15 VGA Stecker.)

((Wieder gingen S-VGA Clones weiter, mit 256k Speicher bis zu 640x400 8bpp, oder gar mit 512k Speicher 640x480 8bpp oder mit genug Bandbreite bis zu 800x600 8bpp (und 1024x768 4bpp). Aber alle 8bpp Chunks Modi sind inkompatibel zu einander über 64k hinaus adresserweitert. Erst spätere S-VGA addierten 1 Sprite, oft 16x16 2bpp (sw+ws+invert), als Hardware Mauscursor. Ebenso kamen mit 1M Speicher auch 1024x768 oder gar 1152x864 8bpp, mit 16/256 Farben aus 16M, sowie 800x600 3*5=15bpp mit 32k Farben direktem RGB. Von hier stammen alle modernen PC Karten ab, dabei die Inkompatibilitäten immer schlimmer werdend.))

Atari ST von 1985

Halb ausser Konkurrenz, weil 16bit. Einfacher geradliniger Rechner, der in unter 1 Jahr von Entwurf in den Verkauf sein ging. Eigentlich Tramiel Corp, welche den Namen Atari Inc aufgekauft haben, dann zu Atari Corp wurden. Strikte ein C64 mit doppelter Speicherbreite (von 8bit auf 16bit), doppeltem Speichertakt (von 2MHz auf 4MHz), gibt vierfache Bandbreite, kann vierfachen Videospeicher (von (8+1=9)k auf 32k), und daher den Featuresatz abgebaut/vereinfacht (nur Bitmap, keine Sprites, unter TED auf fast Apple II Niveau). Auf 2 Chips basiert, Speicher/Adressen Controller/Generator, und Daten/Pixel Chip ("Shifter"). Umschaltbar 3 Bitmap Modi aus 16bit Speicher, aber diese abhägig vom Monitortyp:

Mit dem Schwarzweiss Spezialmonitor ist stets 640x400 1bpp (1/3 mehr als beim Mac). Wieder nicht mal 2bpp Graustufen, trotz dass die Hardware eigentlich 2bpp kann. Auch mit 0=weiss und 1=schwarz. Erlaubt 80x25 Zeichen mit 8x16 1bpp 100dpi Font (könnte also mit halber Auflösung für 2bpp mit 4 Pixel breitem Font doch noch auf 80 Zeichen breiten Text kommen), oder 80x50 Zeichen mit 8x8 (könnte also mit halber vertikaler Auflösung für 2bpp mit 8x8 Font auch auf 80 Zeichen breiten Text kommen). Minus GUI Platzverlust erlaubt nicht mehr 80 Zeichen breite Platz.

Mit dem RGB Monitor (vergleichbar den BBC und CPC ihren) sind es dann 640x200 2bpp (und das kann auch 2bpp Graustufen sein) oder 320x200 4bpp (auch 4bpp Grau), mit 4/16 Farben aus 4096 RGB (und damit genau ein in bpp verdoppelter CPC). Verwendet Pseudobitplanes statt Chunks, also Pixel in Worten wie bei Planes behandelt (mit den Font Vorteilen), aber Worte im Speicher wie bei Chunks liegend (und so auch ohne Pixelprozessor resistent gegen "Ghosting"), das beste von beiden Welten! Erlaubt 80x25 bzw 40x25 mit 8x8 Font. Wieder minus GUI Platzverlust nicht mehr 80 Zeichen breit. Keine Sprites (kompensiert mit den 4bpp, wie beim BBC und CPC).

Ob er fein scrollen kann ist mir unbekannt. Aber das Bild kommt stets aus einem 32k Speicherblock, der soweit mir bekannt nur in 32k Schritten angeordnet werden kann, vom System jeweils auf das Ende vom Speicher gesetzt. Für einen derart einfachen Rechner erstaunlich gut, weil er bereits Auflösung und 4bpp Masse ausnutzt. Das einzige was man vermissen kann wäre ein 160x200 8bpp.

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

Commodore Amiga von 1985

Halb ausser Konkurrenz, weil 16bit. Trotz von Commodore eigentlich der Nachfolger vom Atari 800 (weil selbiger Designer Jay Miner, nach Atari verlassen, Firma HiToro von Commodore aufgekauft), der Atari ST ist dagegen trotz von Atari eigentlich Nachfolger vom Commodore 64, weil selbiger Firmenbesitzer Jack Tramiel eben Atari aufgekauft). Strikte ein Atari 800 mit doppelter Speicherbreite (von 8bit auf 16bit), doppeltem Speichertakt (von 0.89 MHz auf 3.57MHz), gibt vierfache Bandbreite, kann mehr als vierfachen Videospeicher (von 1..8k auf 8..48k), und daher den Featuresatz abbaut/vereinfacht (nur Bitmap). Daher auch ein 3er Chipsatz, mit Agnus (Address GeNerator UnitS) statt ANTIC, Denise (Display ENabler) statt GTIA, sowie Paula (Ports, Audio and UART) statt POKEY. Ebenfalls deswegen gebremst auf 7/8 Prozessortakt, 7.16MHz bzw 7.09MHz statt 8MHz.

Umschaltbar 2 Bitmap Modi aus 16bit Speicher 640x200oder256 1..4bpp (16..64k oder 20.5..82k) oder 320x200oder256 1..6bpp (8..48k oder 10.25..61.5k). Dies mit Bitplanes statt Chunks (wie KC 85-4 2bpp und EGA und VGA 1..4bpp), mit wieder gleichem Font bei variablen bpp, aber dadurch ebenfalls massiv anfällig auf "Ghosting", zumal ohne jegliche Synchronisierung durch einen Pixelprozessor (wie in der EGA). Erlaubt 80x25oder30 bzw 40x25oder30 Zeichen mit 8x8 Font, minus GUI Platzverlust ebenfalls nicht mehr 80 Zeichen breit Platz. All dieses gibt es auch mit Overscan bis 768x256 bzw 384x256, sowie mit doppelter Zeilenzahl durch Interlacing, auf einem Fernseher oder Videomonitor oder RGB Monitor. Keine mehr als 200bzw256 Zeilen, und keine Spezialmonitor Option, weil auch hier wie beim Atari 800 anfangs als Spielkonsole designt und dann zum Homecomputer recyclet. Hat fein scrollen vertikal und horiontal.

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

Zudem hat er einen Blitter um beliebige rechteckige Speicherblöcke zu füllen oder umkopieren (inklusive beliebige Ausschnitte im Bild scrollen, Breite in 16Pixel Blöcken, Höhe in Zeilen), oder gar zu verknüpfen (inklusive für Font rendern), oder einfach zu füllen (inklusive mit Muster). Dies mit Zielblock "D" jedes Pixel = beliebige Logikfunktion der korrespondierenden Pixeln in Bloecken "A" "B" und "C", nachdem diese 0..15 Pixel geschoben wurden, sowie bei ersten und letzten Wort von Zielblock auch Teilworte maskiert (= nicht verändert) werden können. Was aber wegen dieser Blöcke ebenfalls bitplaneweise bearbeiten genau das "Ghosting" beim scrollen maximal verschlechtert. Mit Hilfe des Coppers das Bild aus einzelnen Zeilengruppen zusammensetzen reduziert "Ghosting", als halbe Form der Atari ST Pseudobitplanes, nur auf Zeilen(-block) statt Wort Auflösung. Es reduziert aber den Blitter Nutzen auf innerhalb eines Blockes, weshalb um Fonts zu rendern die Blöcke alle Bildzeilen einer Textzeile beinhalten müssen, was den Nutzen von diesen Ansatz wiederum etwas reduziert. Dazu Sprites, 8 16xN 2bpp, aber wieder horizontal nur im halbierten 320Pixel Raster, und soweit mir bekannt auf 320er positionierbar (das ganze Timing wird sogar in 160ern gemessen). 2 Paarweise zusammensetzbar zu 4bpp. Wie im Commodore 64 keine Prioritätslogik (wie in der TMS9918 oder der Famicom/NES), aber die Spriteposition+Höhe+Modus+Farbe können mit Copperinterrupt und Prozessor oder direkt per Copper die Sprite Register beschreiben umstellt und mehrfach verwendet werden. Dazu ist noch mit Dual Playfield der Hintergrund als 2*3bpp nutzbar mit 8 Farben plus darueber ein 7 Farben (plus 000=durchsichtig) als "Monstersprite" von ganzer Bildgrösse mit separatem fein scrollen. Zumeist für fein gemusterte Parallaxeffekte benutzt.

32 Farben aus 4096 RGB, ausser Extra Half Bright (EHB) 2*32 voll+halb und Hold And Modify (HAM) Modus alle 4096 (letzteres mit 1/3 Auflösung ausser 16 Startfarben mit voller Auflösung, diese auch per Copper zeilenweise anpassbar). Auflösung plus Overscan plus viele Farben plus grosse Sprites und Parallax gaben ihm zurecht seinen Ruf als das Graphikwunder schlechthin. Auch hier kann man nur noch ein 320x200 8bpp vermissen, weil die Bitplanes auf 6bpp limitiert sind (analog zu der EGA ihre maximalen 4bpp), wenn auch nur wegen der Registerzahl (EGA wegen der Busverdrahtung).

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

Vergleich als Medien

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

Bitmapmodi

Die einfachste Form von Graphik ist genau das was man von Papier und Stift bzw Mosiken her seit langem kennt, eine Fläche von Pixeln, welche man jede einzeln beliebig auf eine Farben setzen kann, komplett flexibel. Also Bitmapmodi. Genau daher verwenden wir heute ausschliesslich solche. Nur deren Platzbedarf ist problematisch, sonst sind sie universell.

1bpp/2Farben Bitmap Modi

Der einfachste Weg obige 320x200 8bpp ihre 64k zu reduzieren besteht darin, schlicht die 8bpp zu reduzieren, mit bei 320x200 mit nur 1bpp nur noch 8k brauchen. Was genau einer Zeichnung mit einfarbiger Zeichenfläche mit nur einem anderfarbigem Stift entspricht. Wenn dies ausreicht zählt als Vergleich von Rechnern nur noch wieviele Pixel an Bitmap in 1bpp sie jeweils liefern können:

Ohne jegliche Bitmapmodi scheiden alle anderen 8bit Rechner hier ganz aus. Darunter Commodore PET und VC-20, Tandy TRS-80, Sinclair ZX80 und ZX81, sowie die Nintendo Famicom und NES.

Die 16bit schlagen hier zu, dank mehr Speicher und Bandbreite. Am besten mit 640x400 der Atari ST als doppelte 640x200 aus 32k. Weniger mit 512x384 der Apple Macintosh als doppelte 512x192 aus 24k. Beide brauchen dazu aber wegen doppelten Zeilen einen Spezialmonitor, bei Atari separat wählbar oder beim Mac fest eingebaut, und das bei beiden nur in Schwarzweiss. EGA liefert dazwischen 640x350 (Breite von Atari, Höhe von Macintosh), auch mit einem Spezialmonitor, aber dafür in Farbe. Die bereits beim BBC und CPC gesehenen 640x256 bzw 640x200 auf einem Fernseher oder Videomonitor oder RGB Monitor kann der Amiga (und ebenso deren Speicher sparenden 320x256 bzw 320x200) (sowie mehr mit Overscan wie beim Atari 800), dafür kann er doppelte Zeilen nur mit Interlace statt Spezialmonitor.

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

1bpp/2Farben Farbzellen Modi

Obiges erlaubt trotzdem nur 2 Farben auf dem ganzen Bild, weil 1bpp nun mal Monochrom ist, auch wenn wie oben eingefärbt. Etwas verbessern kann man mit Display Listen Interrupt oder Rasterinterrupt die Farbwahl zeilenweise vorzu ändern, was von obigen aber nur der Atari 800 kann. Weit besser ist aber, dies in Hardware zellenweise schalten zu können, jeweils 8 Pixel breite Zellen, passend zu Schriftzeichen und/oder Objekte in Szenen eher rechteckig denn zeilenbreit sein. Dies entspricht mit mehrerer Stiften colorieren können, solange einzelne Objekte nur je eine Farbe haben, und in die Zellen passen.

Dies kann man mit Stiftfarbe und Flächenfarbe machen. Oft mit 4+4bit für 2 von 16 Farben in einer Zelle benutzen, dies mit 8x8er Zellen im Commodore 64, sowie im Sinclair Spectrum, mit 8x4er Zellen im KC 85-2 und 85-3, oder gar mit 8x1er Zellen im KC 85-4 und TMS9918 "Graphic 2" Modus. Oder 1+7bit nur 1 von 128 Farben (plus blink) mit 8x8 Zellen im TED.

Dabei wird aber für die Zellenfarben festlegen mehr Speicher (plus 1/8 oder 1/4 oder 1/1 (=doppelt)), und um diesen zu lesen erst recht mehr Bandbreite (stets doppelt in der ersten/einzigen Zeile der Farbzellen) benötigt. Dabei wird entweder der Prozessor vom Speicher ausgeblockt und angehalten, beim Commodore 64, sowie vermutlich im Sinclair Spectrum und in den KC 85. Was auch ein Grund ist nur 8x8 Zellen zu benutzen, weil das die Ausblockzeit auf nur jede achte Zeile reduziert, beim 64er als "Badlines" bezeichnet, oder beim TED sogar 2 von 8 wegen 2*7bit Farben. Oder man akzeptiert mehr Prozessor ausblocken, wie beim KC 85, die 8x4 von 85-2 und 85-3 sind durch den 16k Videospeicher limitiert, die 8x1 vom 85-4 werden erlaubt durch (2*)2*16=64k Videospeicher. Oder man benutzt weit schnelleren und teuren Speicher, beim TMS9918 seinen 4*0.895=5.58MHz statt 2*0.895=1.79MHz, was dann dessen 8x1 Zellen ohne den Prozessor ausblocken erlaubt.

(Man beachte hier noch, dass KC 85-4 und TMS9918 mit ihren 8Pixel*1bpp=8bit plus 8x1 Zelle 2*4=8bit Farben sogar gleich viel Speicher und Bandbreite verbrauchen wie wenn sie eine doppelt so breite Auflösung ohne Farbzellen hötten! Damit könnten diese auch 640x256 (einen vollen Acorn BBC!) bzw 512x192 1bpp liefern, wobei dieses dann nur noch mit im ganzem Bild 2 Farben wie oben gehen würde (und wie im BBC gemacht). Dabei würden dem TMS9918 die 12k sogar in seine 16k passen, aber der KC 85-4 müsste die 20.5k in 2*10.25k auf 2 seiner 16k Seiten (zu je 640x128) verteilen.)

2bpp/4Farben Bitmap Modi

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. Oder zellenweise Farben sind in einem Rechner gar nicht vorhanden. Der andere Ansatz zu mehr Farben besteht darin, 2bpp statt 1bpp zu verwenden, für 4 statt 2 Farben, bei jedem einzelnen Pixel im Bild. Dies entspricht mehrere Stifte bleibig einsetzen, aber auf Kosten von mehr bpp, und damit mehr Speicher, oder wegen Bandbreite zumeist halbierter horizontaler Pixel:

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

Die 16bit ziehen teilweise genauso mit. Ein paar von ihnen haben bei 1bpp nicht mal ihre ganze Bandbreite ausgenutzt, und gehen daher für 2bpp mit gleicher Auflösung auf doppeltem Speicherplatz. Logisch sind dies nur Rechner mit massiver Bandbreite, genauer den Amiga der auch bei 2bpp (und auch bei 4bpp) 640x200oder256 kann (plus Overscan) sowie die IBM EGA die ebenfalls bei 2bpp (und 4pp) 640x350 kann. Nach diesen verbleibt nur noch mit 640x200 der Atari ST mit Farbmonitor, mit halbierter Zeilenzahl. Der Apple Macintosh fällt weg, ebenso der Atari ST falls mit Schwarzweiss Monitor.

Irgendwas 8bit sucht man bei dieser Verdoppelung fast vergebens, nur die KC 85-4 schafft es, weil sie von 320x256 1bpp plus 8x1 Farbzellen auf 2bpp umschaltet, was aber auch nur die Häflte vom nicht vorhandenen 640x256 1bpp wäre. Die TMS9918 mit ebenfalls 8x1 Farbzellen hätte Platz und Bandbreite, aber ein 256x192 2bpp Modus ist nicht mal implementiert, und auch sonst gar nichts mit 2bpp, und auch kein 512x192 1bpp.

Die Farbauswahl hier kann wieder sehr verschieden sein. Schlimmstenfalls gibt es nur 2 feste 4er Sätze, wie beim MC6847 (gn+gl+bl+rt oder ws+cy+mg+or). Etwas besser kann eine Farbe gewählt werden, wie bei der IBM CGA eine Farbe aus 16 und 3 feste 3er Sätze für den Resten (gn+rt+ge oder cy+vt+ws oder cy+rt+ws). Noch besser als das können alle 4 Farben gewählt werden, aus 8 beim Acorn BBC, aus 27 beim Amstrad/Schneider CPC, aus 64 bei der EGA, aus 128 beim Atari 800, und 4096 beim Atari ST und Amiga.

2bpp/4Farben Farbzellen Modi

Mit 2bpp gibt es zwar 4 unabhängige Farben. Aber das sind immer noch weniger als die oft 16 Farben welche man mit Farbzellen bekommt. Also gibt es auch die Kombination der beiden Ansätze, welche aber recht selten ist. Der Apple II mit Farbmonitor offeriert dazu nur 2 feste 4er Sätze (sw+gn+vt+ws oder sw+or+bl+ws), aber kann diese für jede 7x1 Zelle wählen (mit dem achten Bit). Die Commodore 64 und TED dagegen machen auf volle Farbzellen, wegen 160x200 nun in 4x8 Grösse, aber mit 4+4+4=12bit 3 (C64) bzw 1+7+1+7=16bit 2 (TED) "Stifte" der 4 Farben aus 16 wählbar (und eine vierte (C64) bzw zwei weitere (TED) als zellenlose "Zeichenfläche" fürs ganze Bild), mit dem dritten "Stift" beim C64 aus der 8+4=12bit Erweiterung kommend, während der TED mit zwei "Stiften" bereits seine 8+8=16bit vom Hauptspeicher ausschöpft.

4bpp/16Farben Bitmap Modi

Auch so bleibt eine Zelle auf 2bpp und 4 Farben beschränkt, falls überhaupt vorhanden. Der 2bpp Ansatz kann auch erweitert werden auf 4bpp oder gar mehr. Das erlaubt jedem Pixel unabhängige 16 oder mehr Farben. Diese mehr bpp gehen wieder zumeist auf Kosten nochmals halbierter horizontaler Pixel, falls sie überhaupt hierhin kommen:

(Die TMS9918 könnte eigentlich mit gleicher Schaltung und nur anderem vertikalen Timing auf 64x96 oder gar 64x192 gehen, aber dies wird nicht angeboten. Wenn man seine 256x192 1bpp mit 8x1 Farbzellen mit leichter Erweiterung der Schaltung auch als 512x192 1bpp nutzen könnte, würden neben 256x192 2bpp sogar noch 128x192 4bpp nur mit anderem Timing drin liegen, aber dieses wird auch nicht angeboten.))

Ohne jegliches 4bpp Bitmapmodi kommen neben all den Rechnern ganz ohne Bitmap, und den bereits bei 2bpp schon ausgeschiedenen, weitere welche welche wegfallen. Dazu gehören auch alle MC6847, die IBM CGA (wäre 160x200 wie CPC), alle Commodore, und die KC 85-4 (wäre 160x256 wie BBC). (Letztere beide können sich aber wieder mit ihren Farbzellen retten.)

Die 16bit ziehen teilweise genauso mit. Ein paar von ihnen haben bei 2bpp immer nicht ihre ganze Bandbreite ausgenutzt, und gehen daher für 4bpp mit gleicher Auflösung auf doppeltem Speicherplatz weiter. Wieder der Amiga 640x200oder256 (plus Overscan) sowie IBM EGA 640x350. Wobei der Amiga bei 3bpp und 4bpp den Prozessor immer mehr ausbremst, zu 3bpp 22% bzw 4bpp 44%. Oder es wird jetzt doch reduziert. Der Atari ST macht trotz 16bit auf halbiert, mit noch 320x200. Der Amiga kann neben 640x200oder256 durchziehen auch 320x200oder256 (plus Overscan) ohne Prozessor bremsen.

Die Farbauswahl geht jetzt immer auf 16 Farben, die Frage ist nur noch welche. Am schlechtesten ist es beim Acorn BBC der nur 8 Farben kennt und das vierte bpp nur für (reversfarbig) blinken benutzen kann. Etwas besser beim Atari 800 mit GTIA, der entweder 16 Helligkeitsstufen eines Farbtones oder 16 Farbtöne in einer Helligkeitsstufe oder nur 9 Farben aus 128 bietet. Volle 16 RGBI Farben gibt es beim Cromemco TV Dazzler. Andere feste 16 beim TMS9918 "Multicolor". Sogar 16 aus 27 der CPC, 16 aus 64 die IBM EGA, 16 aus 4096 beim Atari ST und Amiga.

Mehr als 4bpp/16Farben Bitmap Modi

Mehr als 4bpp liefert der Amiga mit bis 6bpp. Dazu muss aber auch er die Auflösung stets halbieren auf 320x200 (plus Overscan). Bei 5bpp kann er noch volle 32 aus 4096. Bei 6bpp liefert er nur selbige 32, aber in voller und halber Helligkeit im EHB (Extra Half Bright = zusätzlich halb hell) Modus. Ebenfalls bei 6bpp gibt es dann schliesslich alle 4096 Farben aufs mal, im HAM Modus (Hold And Modify = beibehalten und modifizieren), mit dazu setzen 0..15 normal 16 aus 4096 Farben, und dann 16..31,32..47,48..63 modifizieren jeweils eine der drei RGB Komponenten direkt mit 4bit mit den beiden anderen beibehalten. All diese auf kosten von nur noch 320x200oder256 falls 0..15 benutzt bzw 106x200oder256 bei vollen Farben. All die enorm guten fast photorealistischen Bilder welche dem Amiga seinen Ruf aufbauten wurden in diesem Modus erzeugt. Auch hier wird der Prozessor etwas gebremst, zu 5bpp 11% bzw 6bpp 22%.

Mehr als 6bpp liefert die 9938 mit "G7" 256x192 8bpp in 48k. Der Atari ST könnte von seinem Speicher/Timing her diese mit 160x200 8bpp liefern, es scheitert nur an den internen Leitungen im maximal 4bpp "Shifter" Chip. Er könnte mit Amiga-artigem Prozessor bremsen auf 40% es sogar bei 320x200. Der Amiga könnte mit seinem Timing auch auf 320x200oder256 liefern, mit wie beim 640x200oder256 4bpp den Prozessor 40% ausbremsend, es scheitert nur an den maximal 6 Bitplane Adressregistern. Die IBM EGA könnte dies sogar mit grossen 640x200 liefern mit ihrem 4*8=32bit Bus, es scheitert hier an der hart in 4 Bitplanes aufgeteilten Schaltung. Die IBM VGA lieferte dies dann, wenn auch nur mit 320x200, und so nur 1/4 ihres 256k Speichers nutzend, trotz ausreichend Bandbreite, wie es S-VGA zeigen.

Zellmodi

Bitmaps sind flexibel aber aufwendig an Speicher und Prozessor. Der ganz andere Weg zumindest Speicher (aber nicht Bandbreite, der Bedarf daran steigt sogar noch!) zu sparen ohne die Pixelzahl abzubauen besteht darin, nicht jedem Pixel im ganzen Bild seinen eigenen Speicherplatz zu geben, sondern das Bild aus Zellen zusammenzusetzen, mit statt einem einzelnen bildgrossen Bitmap aller Pixel nur einem kleinen Satz von zellengrossen Bitmaps (dem Font) sowie einer Liste von Zellnummern (dem nun weit kleineren Bildspeicher). Der Font ist dabei in RAM, und somit durch passende Softfonts ersetzbar. Problematisch dabei sind die fest gegebene Zellengrösse/Zellengrenzen sowie die limitierte Anzahl Zellensorten im Font.

1bpp/2Farben Pixelzellen Modi

Analog zu obigen 1bpp/2Farben Bitmap Modi kann man auch hier mit nur 1bpp arbeiten, was wieder einer Zeichnung mit einfarbiger Zeichenfläche mit nur einem anderfarbigem Stift entspricht, bzw wegen fixer Zellen eher einem Stempeldruck mit nur einer Farbe. Auch dabei gilt nur noch, wieviel Menge man an Pixel bekommt, hier aber statt Menge Bitmap nun zusammengesetzt aus Anzahl Zellen mal Pixel in einer Zelle, sowie noch wieviele Zellen man im Font definieren kann:

Alle mit nur Bitmapmodi scheiden hier aus. Das sind Cromemco TV Dazzler, Atari VCS/2600, Acorn BBC, Sinclair ZX Spectrum, Amstrad/Schneider CPC, alle KCs, sowie alle 16bit ausser der IBM EGA.

Ohne jegliche Zellmodi scheiden hier alle mit festen ROM Textmodi statt ladbarem RAM Zellen aus. Das sind Apple II, Commodore PET, Tandy TRS-80, Motorola MC6847, Sinclair ZX80 und ZX81, sowie IBM CGA.

Zudem scheiden die Nintendo Famicom und NES aus, weil Zellmodi aber nur 2bpp.

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

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

1bpp/2Farben Farb+Pixelzellen Modi

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

2bpp/4Farben Pixelzellen Modi

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. Das vorhandene streut wieder massiv:

2bpp/4Farben Farb+Pixelzellen Modi

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

Textmodi

Bitmaps sind flexibel aber aufwendig an Speicher und Prozessor. Zellen sind genügsam an Prozessor, und mittel an Speicher, aber intensiv an Bandbreite und Logik, und die letzte Neuentwicklung. Etwas weniger Logik, und zwei separate Speicher um Bandbreite zu verteilen, mit Font nur in billigem ROM und zudem technisch uralt, zeichnet diese Gruppe von Textmodi aus. Jedes Texterminal basiert nur auf ausschliesslich diesen.

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

Sprite Additionen

Bitmaps sind flexibel aber aufwendig an Speicher und Prozessor. Dies erst recht wenn man Auflösung für Details und viel Farben für Spielfeld und sich bewegende Objekte haben will. Dies ist machbar, wie es Acorn BBC und Amstrad/Schneider CPC zeigen, zum Preis von 160x256 bzw 160x200 4bpp und somit 20.5k bzw 16k an Speicher und viel Prozessor. Auch Atari ST und IBM EGA verwenden den selbigen Ansatz, nur mit 16bit bzw 32bit und 32k bzw 4*28k Speicher. Zellen sparen Prozessor und etwas Speicher, aber sind noch inflexibler wenn Objekte nicht in die Zellen passen, und erst recht 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. Das sind die Sprites. Diese sind stets kleine Bitmaps wie in den Zellen, wenn auch oft grösser als diese. Die Grösse und Anzahl und Anordnung streut extrem massiv. Der Aufwand diese zu verwalten und einblenden ist gross, daher sind sie nur in wenigen grossen Chips enthalten. Diese streuen erst recht massiv:

Rangliste nach Fähigkeiten

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, mit und 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 eindeutig an den Commodore 64. Ein 320er Pixelraster statt bloss 256er. Mit Zell und Bitmapmodi, beide in 1bpp und 2bpp. Vollen 256er Font in den Textmodi. All das zusammen mit dem 8+4=12bit Datenbus von RAM+FarbRAM, 16 Farben pro Zeichen bzw pro 8x8 Pixel Zelle, plus noch mit "Extended" 4 Hintergrundfarben von 2bpp auf Kosten von 64er Font. Mit Bitmap 1bpp 2von2 bzw 2bpp 3von4 zellenweise und Text immer noch 1bpp 1von2 bzw 2bpp 1von4 zellenweise. Dazu die grösste Menge Spritebits pro Zeile. Und noch jede Menge flexiblen Komfort wie fein scrollen und lesbarer Zeilennummer und Rasterinterrupt, und ungebremsten Takt vom Prozessor. Das einzige was einem hier wirklich fehlt ist Overscan (ausser bei den Sprites). Nett wäre noch die 16 Farben aus mehr auswählen können (wie beim Atari 800 und dem TED). Verschmerzen kann man dass intensivere Effekte nach Software vorzu umkonfigurierend verlangen. Die Designer vom VIC-II haben ihre Erfahrungen von PET/CBM und VC-20 sowie die "beste Features anderer Chips und Rechner vergleichen" Logik voll durchgezogen. Das Resultat ist saugut, der beste Videochip der 8bit Generation, er ist so gut wie sein Ruf. Kein Wunder fängt die Demoszene mit dem C64 vorzeigen an, hier ist viel zum ausnutzen drin!

Platz 2 geht überraschend an den Nintendo Famicom. Abstriche gibt dessen 256er Pixelraster trotz dass dies inklusive Overscan ist, was an Text nur etwa 28 Zeichen breit erlaubt (was somit einem 28*8=224er Raster entspricht), sowie die fehlenden Bitmaps, und gebremst. Das vernichtet jede Chance auf den ersten Platz. Aber ein 256er Font, zusammen mit der konsequenten 2bpp Logik welche viele Farben erlaubt, ohne halbierte 4x8 2bpp Fonts, volle 8x8 2bpp, was von der Font Bitmenge her einem 512er (bzw eher 448er) Pixelraster mit 1bpp entspricht, und damit einem Textfeld von etwa 56 Zeichen. Die 8x8 2bpp brauchen dafür 2 Bytes Font pro Pixelzeile eines Zeichen, mit daher nur bei jedem zweiten Fontbyte ein Zeichenbyte holen, was 2/3 statt 1/2 Bandbreite an Fontdaten erlaubt, und damit erst obiges Pixelraster. Damit gibt es trotz gebremsten Speichertiming wie beim Atari 800 und TMS9918 und MC6847 zwar nur 3/4 1bpp Pixel (was Text kostet), aber 3/2 2bpp Pixel (was Graphik addiert), was genial ist und der Famicom ihren zweiten Platz sichert. Danach werden selbst die auf 16x16 limitierte Farbzellen zu akzeptabel, zumal diese dann gleich zellenweise 3 Farben von 4 Sätzen erlauben. Dazu kommen die zweitmeisten Spritebits pro Zeile. Man merkt wie bei Atari die Erfahrungen aus Spielhallen Automaten herstellen (teils ihrer Automaten beinhalten von NTSC auf RGB modifizierte Famicoms). Aber ebenso die Limiten von einer Spielkonsole zu einen Homecomputer ausbauen wollen, wie nur etwa 28 Zeichen breit nutzbar für Text. Was Tastatur und DiskSystem wenig attraktiv machte, weshalb die Famicom als Zwischending von Konsole zu Homecomputer eben als Familiencomputer bezeichnet wurde. Massiv nervig ist zeichnen nur während dem Bildrücklauf, weil dem TMS9918 sein schneller Speicher fehlt. Zudem fehlen Paddles, es gibt nur Joystick bzw eben Joypad.

(Obiges gilt nur für die volle Famicom. Die reduzierte NES ohne Tastatur und DiskSystem verliert massiv weil gar kein Homecomputer mehr, nur noch reine Spielkonsole. Damit ist sie nicht selber programmierbar, braucht externe Programmerstellung und Modulproduktion. Dazu kommt erst noch dass zwecks Spielezensur mit einem Lockout Chip und Regioncodes eigene Module herstellen verhindert wird, nur das erlaubt ist wofür Nintendo einem Module herstellen willig ist. Damit ist noch Konsumieren erlaubt, es versagt somit als Medium. In Zahlen, für die etwa 2mio Atari 800 gab es in 13 Jahren um 1000 Spiele, für 12..17mio C64 gab es in 12 Jahren um 2000, für 60mio NES gab es trotz 20 Jahren aber nur um 1400. Was der NES eine Disqualifikation wegen Foul einbringt!)

Platz 3 geht noch überraschender an den TMS9918. Auch nur 256er Raster, aber das wenigstens im Bild drin, für volle 32 Zeichen. Kann 256er Font, sogar mit Farben auf 1x8 ("Graphic 2") oder aber 8x8 an 32 8er Gruppen Zeichen gebunden ("Graphic 1"). Dazu noch die drittmeisten Spritebits pro Zeile. Und keine Prozessorbremse. Abstriche gibt es nur für das komplette fehlen jeglicher 2bpp Farbigkeit, und damit nur den dritten Platz. Auch die fehlenden Overscan und Feinscrolllogik stören etwas. Die 9938/9958 korrigieren all dies, mit ihren massiven G4..G7 Modi, 8 statt 4 Sprites, vertikal etwas Overscan (212 statt 192 Zeilen), und fein scrollen (9938 aber nur vertikal, 9958 auch horizontal), aber nur sehr spät. Nervend ist erst recht die Programmierung wegen keine Prozessor Adressenmodi benutzen können, was aber nur Aufwand und Geschwindigkeitsverlust ist, einem nicht graphisch limitiert. Ebenso fehlen praktisch allen TMS9918 Rechnern die Paddles. (Bonuspunkte gibt es für den genauen Gegensatz zur NES, dass der Chip in vielen verschiedenen Rechnern erhältlich ist.)

Platz 4 geht enttäuschend an den Atari 800. Er hat zwar theoretisch ein 320er Raster, aber dieses nur in Modi "2" und "3" und "F" mit deren "1.5" Farben Logik benutzbar. Sonst ist dies nur ein 160er Raster (mit Overscan bis 192) Rechner (und damit unter dem Famicom 224 bzw 256, sowie beim VC-20 160+), und auch so dokumentiert als 160er Pixelclocks (die 320er werden offiziell als "Halfclocks" bezeichnet). Zwar guten 2bpp Support in 160er Text und Bitmapmodi, aber dahinter gibt es kein zellenweises Farben setzen, mit nur 4 Farben auf dem ganzen Bildschirm, ausser man geht diese per Display List Interrupt und Software umkonfigurieren, was aber wegen Timing nur zeilenweise wirken kann, und ihn so klar auf den vierten Platz verweist. Dazu kommt nur 128er Font, bzw wenn man die Modi "6" und "7" für 2bit an Farbauswahl nutzen will sogar nur 64er Font, nicht mal 2*64 Zeichen geschweige denn 4*64 (was der C64 erst für seinen 4 Hintergundfarben "Extended" Textmodus opfert). Man merkt hier dass Atari eine Spielhallenfirma ist und erstmals einen Homecomputer aus einer Spielkonsole macht, und das mit der Auflösung nicht im Griff hat, während Commodore als Bürofirma zum zweiten mal einen Spielerechner macht. Dazu kommen noch die zweitgeringsten Spritebits pro Zeile, was auch nicht bei korrigieren von obigen Limiten helfen kann. Dies noch mit 160er Rasterm gerade die Sprites nicht detailiert. Das ist besonders schwach bei einer Spielefirma, und dazu dem Erfinder der Sprites (Pong Geräte waren praktisch nur Sprites ohne Hintergrund). Dies wurde dann besonders kritisch als aus dem Atari 800 die 5200 und XEGS Konsolen abgeleitet wurden. Es ist aber unvermeidbar wegen des gebremsten 7/8 Prozessortaktes, und so nur 112 von den 128 Speicherzyklen/Zeile vom C64, mit davon wegen dem Overscan 2*48=96 statt 2*40=80 für den Hintergrund reserviert, nur 112-96=16 statt 128-80=48 im Rücklauf (wo die Spritedaten gelesen werden). Nach Abzug vom Speicherrefresh (etwa 4), sowie bis zu 6 weitere für die Displayliste reserviert (maximal Pseudomodus "1" plus Adresse plus Modus plus fakultative Adresse), verbleibt die Differenz von 8*3=24 zu 5*1=5 Spritebytes/Zeile. Da kann auch die Displayliste nichts mehr retten. Sie spart zwar selektiv RAM (und damit Bandbreite/Prozessorbremse) bei variabel aufwendigem Hintergrund, sowie Prozessor bei Modi im Bild umschalten bzw scrollen, aber bei Farben oder Sprites aufbessern ist sie wirkungslos, also doch wieder Software gefragt. Dabei sind Text oder Paint Programme alles nur 1 Modus, Games mit mehreren Modi nutzen den Prozessor nur im vertikalen Rücklauf, haben ihn im Bild frei um Modi zu wechseln, also ist hier Hardware Aufwand und 6 Speicherzyklen/Zeile blockieren am falschen Ort. Zudem ist noch die Displayliste ihre Scrollmethode nicht mit einem 8+4=12bit FarbRAM welches die unteren Adressbits nutzt kompatibel (mit dazu 2 separate Adressen und Pins benötigen). Damit fällt der Atari 800 wegen Bremse plus Overscan statt Spritemenge, sowie Displayliste statt FarbRAM, auf den vierten Platz, weil mit viel komplexem Aufwand am Ziel effektiver Leistung vorbeigeschossen!

Platz 5 und damit letzter geht dann wie zu erwarten an den Atari VCS/2600. Der erste VLSI Chip mit Sprites, bereits in 1977, was absolut gut für damals war. Aber ansonsten praktisch unbrauchbar. Der als erweiterte Pong Konsole mit 40er Raster grobpixelige Hintergrund kann fast gar keinen Text darstellen (selbst mit 4x8 Font nur 10 Zeichen pro Zeile, und das erst noch als 2*5 wiederholt!). Die Sprites liefern nur 2*8 und 3*1 Pixel. Ausser man programmiert sehr aufwendige "Racing the Beam" Techniken, womit Pong Spiele genau ihre 3x5 Font Spielstandanzeige bekommen. Und dann kommt noch der Programmaufwand, um alle Zeilen in Software umkonfigurieren zu müssen, was garantiert dass mit maximal 4k ROM adressieren nur wenig Spiellogik verarbeitet werden kann.

(Der VCS/2600 hielt wegen billig und früh etabliert sein mit vielen Spielen die bessere (aber inkompatible) Konkurrenz aus dem amerikanischen Markt heraus. Was ihn ab 1977 von 3 auf 6 Jahre zu 1983 "streckte", bis die Homecomputer den Markt wegnamen. Seine Limiten und Programieraufwand führten nachdem Atari viele Entwickler herausekelte zu eigenen unfertigen/schlechten Spielen (Pacman und E.T.) und deren Drittfirmen ihren oft überhasteten aber überhypeten Spielen. Nicht verwunderlich führte diese Flut von Schrott zu einem Vertrauenszusammenbruch der Käufer und dem Nordamerikanischen Videogame Crash von 1983. Dabei verlor Atari massiv. Europa und Japan waren davon wenig betroffen, Europa weil bereits auf Homecomputer umgestiegen, Japan dominierten immer noch Spielhallenautomaten.)

8bit mit Customchips ohne Sprites

Platz 1 geht eindeutig an die TED Rechner (Commodore 16 und 116 und Plus/4). Mit einem überarbeiteten und ordentlich erweiterten VC-20 VIC nicht verwunderlich, mit spritelos reduzierten C64er VIC-II erst recht nicht. Sofern man keine Sprites braucht ist der TED mit dem Commodore 64 auf obigem Platz 1 graphisch 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 auch mit den Farbzellen von Commodore, und somit das beste von beidem! Selbiges gilt beim Font, umschaltbar Commodore 256er flexibel oder Atari 128er sparsam. Lediglich der Overscan fehlt, wenn auch nur teilweise (nicht horizontal, aber kann mit Rasterinterrupt ausnutzen vertikal, es hat hier keine FarbRAM Limite), plus vor allem die Sprites. Was bei einem Homebusiness Chip auch nicht verwundert, der Name TED (TExt Display) ist hier eindeutig Programm! Spielerechner sind die TED Rechner ohne Sprites und auch ohne Paddles ohnehin nicht. Aber selbst so sind sie besser als den Atari, mit Farben pro Zeichen haben, welche das fehlen dessen schwachen Sprites zumeist aufwiegen! Trotzdem wurde der Plus/4, nachdem er als angeblichen C64 Homecomputer Nachfolger vermarktet wurde, wegen fehlenden Sprites und schwachem Sound unterschätzt und verspottet als Minus/60, trotz in allem anderen gleich gut oder gar besser zu sein!

Platz 2 geht erstaunlich an den VC-20. Er leidet zwar massiv an seiner "halbierten" 160er Raster Auflösung, und nur 23 Zeichen breitem Text. Bitmaps fehlen auch. Aber abgesehen davon hat er einen 256er Font mit 1bpp und 2bpp, und dazu noch FarbRAM auf 8+4=12bit, und sogar Overscan. Als einzigen in dieser Kategorie hat er auch noch Paddles. In obiger Kategorie hätte er nicht nur den VCS/2600 klar geschlagen sondern auch den 800er bedrängt. Hätte er nur 40 Zeichen bekommen wäre er wie beim TED am 800er vorbeigezogen, erstaunlich für Commodore erstmals eine Spielkonsole machen! Damit ist dessen VIC ein erstaunlich guter Chip, der nur wegen seiner geringen Auflösung (sowie dem kleinen 5.5k RAM im VC-20, aber mehr als die 2+2k im NES!) massiv unterschätzt wurde, noch weit mehr als der TED später. (Ebenso unterschätzt wird damit Al Charpentier als Designer von VIC und VIC-II, sowie als einen Einfluss auf den TED, der mit Jay Miner als Designer von TIA und ANTIC/CTIA und Agnus/Denise vergleichbar ist.)

Platz 3 geht dann noch wie erwartet an die MC6847. Hat nur 256er Raster, und das auch nur mit festem 64er ROM Font oder 1bpp Bitmap ohne Farbwahl. Sonst nur 128er Raster 2bpp (und das ohne Schwarz), oder 8+1 Farben mischbarer 2x2 Blockgraphik oder 4+1 Farben unmischbarer 2x3 Blockgrpahik mit Schwarz (aber nur 2*32=64 breit, und ohne SAM Tricks nur 2*16=32 oder 3*16=48 hoch). Dazu noch Prozessortakt 7/8 gebremst. Da hilft auch nicht mehr, dass er oft mit einer 6809 daherkommt (wie in TRS-80 CoCo und Dragon 32/64, aber im Acorn Atom mit einer 6502, oder gar im NEC PC-6001 mit einer 8049(!)). Damit ist er der mit Abstand schwächste Chip hier, unterhalb einiger TTL Rechner.

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

Platz 1 und 2 gehen mit Abstand gleichauf an den Acorn BBC Micro und den Amstrad/Schneider CPC. Deren 640er Raster liefern bis zu 80 Zeichen trotz 8Pixel breit, für viel Text. Aber viel entscheidender sind beim 320er Raster bereits 2bpp und vor allem beim 160er Raster volle 4bpp. Damit können diese selbst ihre primitive Logik und das Fehlen von Sprites komplett wettmachen! Mit in 4bpp nur 2 160er Pixel in einem Byte ist selbst fehlendes fein scrollen mit den MC6845 Anfangsadressen problemlos. Wo exakt sie in obiger "mit Sprites" Kategorie landen würden ist offen. Wohl irgendwo unter dem Commodore 64 aber über dem Atari 800, ziemlich sicher oberhalb vom TMS9918, vermutlich zwischen diesem und der Famicom. Damit schlagen sie erst recht locker alle in der "ohne Sprites" Kategorie, und hier in dieser sowieso. Einziger Preis ist der Verbrauch sehr von viel Videospeicher (beim BBC 20.5/16/10.25/8k, im CPC fest 16k), und viel CPU um diesen umzuschaufeln. Was deren 2MHz 6502 bzw 4MHz Z80 aber auch recht gut können (gerade auch die Z80 mit ihrem eingebauten LDIR/LDDR Blockkopierer, die 16k werden in etwa 0.1s gescrollt). Damit sind diese eigentlich erstaunlich moderne Rechner, welche die Methoden heutiger (S-)VGA Rechner vorwegnahmen. Unter einander kann der BBC mit 256 statt 200 Zeilen und variabel grossem Speicherplatz punkten, aber der CPC mit 3^3=27 statt 2^3=8 RGB Farben gleichziehen.

Platz 3 geht überraschend in die DDR an den KC 85-2 (und 85-3 und erst recht dem 85-4). Bereits beim 85-2 und 85-3 volles 320er Raster mit FarbRAM auf 8x4. Beim 85-4 das FarbRAM sogar auf 8x1 verbessert, und dazu noch die 2bpp Alternative angeboten. Mit 640x256 1bpp und 160x256 4bpp addiert würde das Teil mit obigem BBC gleichziehen, bzw mit 16 Farben statt 8 darüber! All das in nur reines TTL, einfache Struktur, aber sehr wirksam, weil genau das was man braucht, auf etwas über TED Niveau! Auch hier sind in der 85-2 und 85-3 dann 10.25+2.5=12.75k bzw in der 85-4 gar 10.25+10.25=20.5k an Speicher (plus weitere 1.25k simulierter Textmodus Speicher) und viel CPU um diesem umschaufeln der Preis. Was die nur 1.75MHz bzw 1.77MHz gebremste UB880 aber ordentlich belastet (trotz LDIR/LDDR haben), mitsammt ghosting, was bei der ineffizienten eingebauten Software der 85-2 sehr langsames scrollen in 0.6s ergab!

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

Platz 5 geht erst an die IBM PC CGA. Die kann eigentlich ein 640er Raster, oder 320er mit 2bpp, und damit zwei Modi der BBC und CPC, mit dem selbigen 16k Speicher dafür, welchen die 4.77MHz 8088 erst recht problemlos umschaufeln kann. Aber genau der weitere Modus mit seinen 4bpp fehlt hier massiv. Auch bei 2bpp ist nur eine Farbe frei wählbar, und an die Randfarbe gekoppelt. Dazu kommen noch die festen 3er Sätze ohne Schwarz Farbauswahl, welche das Register/Rand praktisch auf schwarz zwingen. Daher kommen die vielen für die CGA typischen Spiele mit sw+gn+rt+ge oder sw+cy+vt+ws. Zudem kann die CGA dies nicht bei 1bpp dies mit FarbRAM und Attributen retten, weil sie nur in Textmodus Attribute hat. Hier wenigstens mit schwarz plus freier Farbe. Damit fehlen bei Bitmap alle Methoden um die Effekte von Sprites zu ersetzen. Auch im Textmodus wird es nicht besser. Zwar hat es hier Attribute, aber kein RAM Font. Was zu dessen Blockgraphik zwingt, welche aber auch nur 1x2 Blöcke liefert, zu 80x50. Egal was man es versucht, die CGA macht einem einen Strich durch die Rechnung, verhindert gute Graphik und frustriert! Nur mit dem "Tweak Mode" kommt man mit 2x1 Blockgr und 8x2 Font noch auf halbwegs ordentliche 160x100 mit 16 Farben. Weshalb sie trotz Pseudo-Bitmap in der Auflösung selbst hinter dem Spectrum Billigrechner landet.

Platz 6 geht dann an den Apple II. Zwar noch ein 280er Raster, aber nur mit 1bpp (mit Schwarzweissmonitor), sonst nur noch 140x192 wenn mit 2bpp (mit Farbmonitor) mit seinen ganzen 2*4 Farben und geringer Auswahl. Dazu kommt dass die 140 Pixel aus 40*3.5 bestehen, weil in 7bit 3.5*2bpp passen, also ein "Zwischenpixel" seine beiden Bits auf 2 Bytes beziehen muss, was diesen sehr schwierig zu programmieren macht! Wenn man schon eine solche Sparschaltung macht, wäre Prozessor auf 7/8 bremsen und Bild 8/7 breiter (wie im Atari 800) angebracht gewesen, für voll C64 Geschwindigkeit muss man mit mehr Schaltung dahinter gehen. Blockgraphik liefert 16 Farben, aber auch nur in 1x2 Blöcke, zu 40x48, und erst noch nicht mit Text mischbar. Text sind nur 64 Zeichen ROM Font, ohne Blockgraphik. Es hat damit zwar 3 Modi aber keiner davon ist wirklich gut, vergleichbar frustrierend wie die CGA, aber noch schwächer. (Bonuspunkte gibt es für die extrem gute Dokumentation, die ganze Schaltung ist im Referenzhandbuch abgedruckt!)

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

8bit ohne Bitmapgraphik

Platz 1 geht eindeutig an den PET bzw die CBM. Ohne Bitmap oder RAM Font oder Farben, zählen in dieser Kategorie nur noch anzahl Zeichen und der ROM Zeichendatz und dessen Anzahl an Graphikzeichen. Hier sind immerhin 40x25, mit 128+revers Font, und das erst noch mit 2 Fonts zur Auswahl, volles ASCII96+Graphik32 oder ASCII64+Graphik64, was die beste Pseudographik aller Zeiten ergibt, das Vorbild für alle anderen.

Platz 2 geht dann an den TRS-80. Wahlweise 32x16 oder 64x16, mit immer noch volle ASCII96, plus damit mischbare 2x3 Blockgraphik (aber keine weiteren Graphikzeichen), erlauben noch recht viel Auflösung von 64x48 bzw 128x48.

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

16/32bit Systeme

Platz 1 geht wie zu erwarten an den Commodore Amiga. Mit 640er Raster und bis zu 4bpp oder 320er bis zu 6bpp sind das bis um 64k an Speicher. Damit geht er bis an die Grenze von 320x200 8bpp ihren 64k. Dazu kommen jede Menge Features, von vielen Farben ((2*)32 normal/EHB oder 4096 HAM) und Overscan und fein scrollen, bis zu mit Copperliste alles umstellbar (und diese bis beliebiger Zeile pausierbar), sowie viele grosse Sprites. Damit ist er eine sehr gute Erweiterung des Atari 800, praktisch alle dessen Schwächen beseitigt. Lediglich die Bitplanes und ihr "Ghosting" beim scrollen störten gross, hier am schlimmsten. Der Blitter ist eher überbewertet, zumal er nur Umkopieren beschleunigt, und das wegen Setup Aufwand erst bei grossen Flächen sich lohnend, wo genau "Ghosting" dann am schlimmsten wird. Der Copper ist da einiges wertvoller, aber nicht wirklich dringlich, weil er letztlich nur alle Rasterinterrupt Techniken beschleunigt. Und den Prozessortakt auf 7/8 gebremst macht er gerade mal wett. Damit gewinnt der Amiga aber trotzdem als den besten Chipsatz der 16bit Generation, aber das vor allem wegen den vielen bpp, und erst noch trotz grosser Auflösung, wenn auch damit weiter bis zu 40% der 7/8 gebremst. Aber auch wegen vieler ausnutzbarer Möglichkeiten, kein Wunder ging die Demoszene vom C64 zum Amiga weiter!

Platz 2 geht auch nicht überraschend an den Atari ST. Selbst mit dem Schwarzweiss Monitor schlagen seine 640x400 1bpp den Mac seine 512x384 1bpp locker, mit 32k um ein Drittel mehr als dessen 24k. Dazu ohne wie im Mac den Prozessor wegen dessen langsamen Speicher zu bremsen. Mit dem farbigen Monitor sind seine 640x200 2bpp und 320x200 4bpp mit 32k genau ein verdoppelter Amstrad/Schneider CPC seine 16k, und damit das doppelte vom ersten Platz dessen Kategorie. Sie sind sogar identisch mit einem Amiga solange man nicht dessen Prozessor für mehr bpp opfert! All das aus einem sehr einfachen simplen auf billig gebauten Rechner, Anfangs nur $1000 (ohne Monitor und Floppy), trotz 4 mal soviel Speicher wie beim Mac (komplett $2500), bzw 2 mal soviel wie dem Amiga, sowie gleichem Prozessor wie dem Mac aber ungebremst, und 1/8 mehr als Amiga falls ungebremst. Er wurde damals ebenfalls ziemlich unterschätzt, gerade auch im Vergleich mit dem Amiga, wenn nicht ganz so extrem wie den TED oder gar dem VC-20. Selbst fehlender Blitter und Copper und Sprites sind mit 4bpp und schnellstem Prozessor nicht so kritisch, wie es damalige Spiele oft zeigten. Fehlende mehr als 1bpp in Schwarzweiss, nicht mal 320x400 2bpp geschweige denn 160x400 2bpp, machen das für Spiele unattraktiv, verlangen Farbmonitor. Lediglich dort keine über 4bpp und 16 Farben haben, sowie kein Overscan, verweisen ihn auf den zweiten Platz. Nur mit 8bpp addieren, trotz damit nur 160x200 haben, hätte er bereits den ersten Platz gleichauf genommen. Mit zudem fakultativ doppeltes Bild mit 40% Prozessor opfern wie im Amiga, 640x400 2bpp bzw 640x200 4bpp oder 320x200 8bpp, hätte er den ersten Platz alleine genommen!

Platz 3 geht dann erst an den Apple Macintosh. Die für die 16bit Generation eher niedrige Auflösung, sowie mit nur 1bpp keine Farben (und nicht mal 2bpp Graustufen) geben ihm keine Chance. Dazu wegen langsamen alten Speicherchips den Prozessor um etwa 25% bremsend. Erst recht ohne Overscan oder Sprites. Das schwächste Bitmap dieser Generation, mit Abstand. Nur die Hälfte mehr Speicher als beim CPC, und nicht mal ein Viertel mehr als beim Acorn BBC und KC 85-4, sowie ohne deren Farben und Modi, alles Rechner welche ich daher über den Mac setze (und diese unter dem Commodore 64). Eigentlich eine dumme primitive Kiste, anfangs as Billigrechner mit Ziel von $1000 designt, aber dann wegen der Software als teuren Komfortrechner vermarktet, mit alleine wegen der Werbekampagne finanzieren von $2000 auf $2500 angehoben! (Selbiges hatten sie schon mit dem Apple II gemacht, als Minimalistikrechner designt, aber dann wegen Graphik haben als teuren Powerrechner vermarktet.) Der angeblich "graphische" Macintosh bezieht sich so nicht auf die Hardware, zu welcher sein Spitzname "Macintrash" bestens passte, sondern nur auf die Software, welche in 64k ROM mehr leistete als dem Atari ST seine 192k ROM, das Resultat von 4 Jahre Entwicklung und Optimierung, statt nur in unter einem Jahr durchgezogen.

(Trotzdem war die GUI Software für den gebremsten 16bit Prozessor zu viel, und damit schnachlangsam. Was auch für den Atari ST (trotz mehr Prozessor) und dem Amiga (mit dort untertaktet und noch mehr gebremst) ihre GUI Softwares galt (plus noch unpassender in deren 200 Zeilen Modi, und ohne 6x72 Font keine 85 Zeichen breit). Ebenso für Microsoft Windows auf 16bit/286er oder gar 8bit/8088er PCs (egal ob CGA 200 Zeilen unpassend oder EGA erst recht langsam). Weil erst die 32bit Generation genug Prozessor (ab 30MHz) und Speicher (ab mehrere MBytes) für GUIs lieferte, sowie neben ausreichend Auflösung für Fenster (mehr als 640x480, für mehr als 80x30 Zeichen in 8x16 100dpi Font), auch genug Farben für Graphik (ab 4bpp aber besser 8bpp, mit 800x600 zusammen dann ab 256k bzw 512k Bildspeicher). Also S-EGA bzw S-VGA oder Macintosh II oder Atari TT oder Amiga AGA.)

Ganz ausser Konkurenz ist die IBM PC EGA. Ihre massiven 4*64=256k stellen sie weit ausserhalb der 64k Grenze. Aber selbst mit 256k liefert sie nur maximal 4bpp, typisch für IBM welche Auflösung mehr schätzt als bpp, und verliert zumindest gegen den 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 dies gewinnt. Den "graphischen" Mac schlägt der PC mit EGA aber locker, schlicht weil der keine Farben kann. (Die VGA kommt dann als allererste auf 8bpp, und damit vor alle anderen Rechnern, wenn auch nur mit dem bloss 1/4 von ihren 256k ausnutzenden 320x200 8bpp, bis die S-VGA kamen.)


Home | Artikel | VCFe Video als visuelles Medium

Diese Seite ist von Neil Franklin, letzte Änderung 2016.05.17