Diesmal war 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 erkennbaren 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 trotzdem das Entscheidende 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!
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.
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 hohen 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, wieder als IBGR aus einem einzelnen 4bit 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. Beides am Rande von unbrauchbar.
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 hat es nur 1k sonstiges SRAM im einem nicht erweiterten Sol-20, weil eben nur als Terminal ausgelegt, aber Platz ausgelegt für bis zu 48k Erweiterung.) Ebenfalls früh erschienen, daher alles reine TTL Logik, keine Customchips, dementsprechend primitiv. Trotzdem aber mit vollem Textmodus, weil eben Terminal.
Dieser 1 Textmodus hat 64x16 Zeichen. Mit 9x13 Font (7von9 breite und 9von13 hohe Zeichen), 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 mangelns Graphik 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.
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 DRAM Speicherchips (1MHz für Prozessor und 1MHz für Video) kann er dies ohne den Prozessor zu bremsen (Apple 1 hatte nur 1MHz 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.)
Dazu kommt aber 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). Erst damit kann er in diesem Vergleich auftreten.
Die Farben 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ättigen! 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").
(Die 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 640×200@2bpp oder 320×200@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 FontRAM, 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 aber ausreichende 3 Jahre später nachgeschoben wurde. Ursachen waren mehrere, die sich aufsummierten. Als erstes um Lüfter zu meiden ein Metalgehäuse, welches zugleich Kühlkörper war. Von dieses schnell festlegen müssen Platzmangel und deswegen Layout gedrängt, 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 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 keine Zeit um alle obige 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. Einerseits 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), womit das extra DRAM nicht nutzbar war. Anderseits weil die 80 Zeichen und Kleinschrift bewusst in Apple II Modus verhindert waren, womit keine schrittweiser Aufstiegspfad bestand, der III praktisch ein Systemersatz war, aber wegen teilkompatibel weit schwächer als auf IBM PC umsteigen! 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, mit "Language Card" und 80 Zeichen Karten. Dann der IIe nochmals 3 Jahre, mit beides fest eingebaut. 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 Layout Fehldesign führte.))
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 zeichenpositionsweise 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 IBM PC AT 16bit geliefert!)
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 leicht besser als 40x24 oder weit besser als 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 waren 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 CRTC 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.)
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.
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.
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!
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.
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 wegen breiterem Bild des 800 sogar mit 160x192 pseudo-2bpp statt 140x192, und dies erst noch mit 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 maximal möglichen 240 NTSC Zeilen (die extra 288-140=48 PAL Zeilen sind stets leer, je 24 unten und oben im Bild, wegen kompatibel bleiben) 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 theoretisch 53.6µs überbreites, was aber gar nicht darstellbar ist, weshalb nur 352von384 Pixel erscheinen).
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 zudem 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 3von8 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 werden). 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 +1*(16*16k), mit "Extra" durch 256k DRAM Chips ersetzen (allenfalls auf +2*(16*16k) mit zweiten 256k Huckepack) durch 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, aber ohne Farben, sowie erstaunlich 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 beinahe Konkurs und 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.))
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 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.)
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.
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.)
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.))
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.
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 horizontal 1x2 oder vertikal 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!
(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 in 32x16 Zeichen 64x64 Blöcke, 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 von 32k auf 64k erweiterbar, kann so geschaltet 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 die MC6845 wegen ihrer Limite auf max 128 Zeichenzeilen mit vertikal 87 Zeichenzeilen zu je 4 Videozeilen betreibt (statt bei den MDA 25 Zeichenzeilen zu je 14 Videozeilen zu bleiben)! Dies mit den zwei Videozeile in Zeichenzeile Bits als A13+A14 vorne an die resultierende 87*80=6960 = 8k ihren 13bit Adressen zusammengelegt, und somit die 32k als 4*(87*80von8k) genutzt.)
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 Blöcke).
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 2+2k 8+8=16bit SRAM, nur 16k 8bit DRAM, nicht mal 16+2k DRAM+SRAM (und erst recht nicht 2*16k DRAM). Was dann bei den 80 Zeichen Breite und 2 Bytes pro Zeichen nach 3.579646MHz an Speicherbandbreite (wie TMS9918) verlangt, und das 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 mangelns weiteren 2k (oder gar 16k) 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 gehend, 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 ob Pixel=01+10+11 Intensiv addiert wird. Am ehesten war der Gn+Rt+Ge Satz mit Hintergrund=Blau nutzbar. Also keine echte Farbauswahl. (Was genau dem MC6847 "C" Bitmap mit Gn+Ge+Bl+Rt Satz entspricht, nur mit besserem blauen statt grünem Rand, sowie 320x200 statt 128x192 Pixel.)
Zudem liegen die Bitmapzeilen nichtlinear im 16k Bildspeicher, weil die MC6845 nur bis 128 Zeichenzeilen zählen kann. Also werden die 200 Videozeilen als 100 Zeichenzeilen 0,2,4,..198 zu je 2 Videozeilen angeordnet (statt bei den Textmodus 25 Zeichenzeilen zu je 8 Videozeilen zu bleiben)! 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 2*(100*80von8k) genutzt. Hat keinen vollen Rasterinterrupt, aber zumindest einen Vertical Blank Interrupt (VBI).
Bitmap 640x200 1bpp in schwarz+1*IRGB-Register. Auch die ganzen 16k Bildspeicher an Bitmap, ohne weitere 2k (oder gar 16k) keine Farbattribute, und zudem 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. (Was in gewissem Masse genau ein Cromemco TV Dazzler im "X4" Modus ist, nur mit 16k statt max 2k und somit 8 mal mehr Pixel, 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 RGBI Monitor nicht benutzbar.)
Hat somit viel Speicher und hohe Auflösung. Aber die beiden Bitmapmodi liefern weder viele bpp noch ordentliche Farbwahl. Und der Textmodus kann weder mit guter Blockgraphik aushelfen (wie Microtan 65) noch mit Font 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" Ausschnitt. Dann wird das ZeichenRAM (jedes erste von zwei Bytes, 8von16k) fest mit dem ROM 2x1 Blockgraphik Zeichen 222 (links aus und rechts ein) gefüllt, was statt normalen 160x25 nun 160x100 gibt. Danach wird nur noch im AttributRAM (die zweiten Bytes, auch 8von16k) gearbeitet, mit Bits 7..4 (Hintergrund) links und Bits 3..0 (Vordergrund) rechts erscheinend, die beiden 4bit Farben als 4bpp 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 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 40x100 Zeichen und 2x1 Streifen-Pixel ein weit weniger nützliches 80x100 entstehen.)
(Der IBM PCjr (1984) 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 der Speicher +64k auf 16bit erweitert wird, mit so 2*64k vorhanden, davon 96k als Hauptspeicher. (Weitere +128k Hauptspeicher konnten am 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 Interrups bei jedem getippten Zeichen 4.8ms ausblockte, und somit mehr als 1200baud RS232 Empfang und gleichzeitig tippen unmöglich machte. Weiter gab es erst mit der +128=256k Hauptspeicher Erweiterung 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 diesen Fehlern 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 (der davor schon erschienene Tandy 2000 ist ein PC XT kompatibler). Nach dem PCjr 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 bezeichnet), welche Ironie!)
(Andere haben bereits davor CGA Clone erweitert auf doppelte 32k. Bekannt wurde die 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. Sie haben dies aber verpennt.))
Trotzdem aber umschaltbar 7 Bitmap und 1 (Tele-)Text Modi:
Auch hier kann die MC6845 nur bis 128 Zeichenzeilen 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 Zeichenzeilen 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.25k oder 8k, statt "volle" Modi 0..3 mit 20.5k oder 16k, für falls 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!
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 ZeichenRAM und AttributRAM 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)).))
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).))
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). Was als "Contention" bekannt ist, wobei den Prozessor per Waitstates anhält bis der Speicher frei wird. Dies aber nur falls der Prozessor auf die ersten 16k vom DRAM Speicher zugreift, gleichzeitig wie der Videogenerator dies macht, nicht auf ROM oder +32k DRAM.
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.)
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 beim ZX80, als 1k für System und Benutzer, plus 2* 1k separate ZeichenRAM und FontRAM (wie Sorcerer). Wegen separatem FontRAM ist beim Fontzugriff kein I Register als Basis ausnutzen notwendig (wie ZX80 mussten). Der Font muss daher vom System aus ROM ins FontRAM 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.
Das ZeichenRAM 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 ZeichenRAM und FontRAM, 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 bei 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 FontRAM, 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 FontRAM schreiben/lesen Adressen und 1 für Hardware reverse), mit nur noch 16 sogar 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 ZeichenRAM und FontRAM 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.
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.
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.
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 separaten 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 eine 256byte Page vom Prozessor ROM oder HauptRAM in den Spritekonfiguration Bildspeicher kopieren, für diese schnell neu positionieren. 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 "DMA" 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 (der Bildspeicher ist zu klein für einen Font!), 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!
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.
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 Zeichenzeilen zählen. Hier werden die 200 Zeilen als 25 Zeichenzeilen 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 Videozeilen als 25 Zeichenzeilen 0,8,16,... zu je 8 Videozeilen 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.))
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.))
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 Pixel pro Zeile = 22.255kHz Zeilen, / 342+28=370 Zeilen pro Bild = 60.15Hz Bilder. Bild ist somit (512/8)*342=21888Byte=21.8kByte, 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, dass während den Videozeilen ausgeben der 2MHz nutzende Prozessor für jeden zweiten Speicherzyklus angehalten wird (alle Bildzeilen sind somit halbe "Bad Lines", oder das ganze ist eher vergleichbar dem Sinclair ZX Spectrum "Contention"). Der Bremser wegen Videozugriffe ist somit (1/2) * ((512+1)/704) = 36.43% der Zeit, von 7.8336MHz auf 4.979MHz. Allerdings gilt dies nur bei RAM Zugriffen, ROM und IO sind ungebremst (wie Spectrum). Woraus am Schluss gemäss Apple ihrer offiziellen Dokumentation etwa 6MHz Durchschnitt herauskommen.
Video kann damit halbe vom Speicher seinen 1.9584MHz nutzen. Was eigentlich nur 16kByte erlauben würde, für 256 Zeilen zu 512 Pixel. Aber die Rücklaufzeiten werden durch geringeren Bildrand reduziert. Statt damit mehr Bildwiederholfrequenz zu holen, werden daraus mehr Zeilen, obige 342. (Wenn man bedenkt, dass 16bit doppelte Breite hat, und hier fast 8/4=2MHz doppeltes 8bit oft 4/4=1MHz ist, sollte der Mac vierfaches Video von 8bit haben. Damit entsprechen dessen 21.8kByte bei 8bit nur 5.36kByte. Das ist sogar unterhalb des Spectrum 6k, wenn man dessen Farbattribute wegfallen lässt, und dessen ungebremstes +32k DRAM ignoriert. Der Mac ist damit unterhalb eines hypothetischen 16bit Spectrums!)
Das gilt auch im Mac 512K, weil nur 1*128kByte aus 16 64kBit DRAMs ersetzt durch 1*512kByte aus 16 256kBit, sonst fast identisches Board, nur neunten Adressmultiplexer TTL Chip addiert. Selbiges gilt immer noch im Mac 512Ke (1986), weil nur ROM von 2*32k auf 2*64k und Floppy von 400k auf 800k verdoppelt. Ebenso noch im Mac Plus (1986), weil nur selbige neue ROM Chips und Floppy, 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 angeblich immer noch nicht ganz eliminiert!), dazu nun 2*128k ROM sowie 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 wohl eher 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 Text 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 verfolgte, aber mit 8bit Technologie weit billiger und trotz weit weniger vermarktet etwa gleich 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 aber 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 derart gewachsene Software. Trotzdem wurde anfangs diese Konfiguration verkauft, statt direkt auf 512k zu gehen, wie es die Designer verlangt hatten. Selbst nach 512k anbieten wurde 128k weiter verkauft. 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, weil manche Kunden weit billigere 128k kauften und sogleich aufrüsten liessen!)
(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 ROM 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 $2800, von 128k auf 512k +$300, bzw da der Mac 128K gleichzeitig auf $2300 gesenkt wurde +$500. Der Mac verkaufte sich anfangs recht gut, wegen einzigartig, aber brach innert Monaten ein, weil nur wenige Leute sich solchen 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 $2800 statt $3500, nur +$700 für hatte Lisa 2 selbige 68000 mit 512k DRAM, aber 720x364 statt 512x342 Pixel auf 12" statt 9" Monitor, sowie Option auf Harddisk, sowie Tastatur Numerikblock eingebaut statt optional, sowie keine limitiertere Software wegen auf 128k Billigrechner mit wenig Speicher ausgelegt. Also war der Mac ein sehr schlechter Deal. Mit dem 512K auf $2000 und 128K auf etwa $1500 (oder besser 128k ganz abgeschossen und allen frühen Käufern als Entschuldigung einen kostenlosen 512k Upgrade angeboten, statt dafür $1000 verlangt), wäre der Mac akzeptabel gewesen. Mac Plus war dann passendere $2600 neben 512Ke inzwischen noch $2000. Mac SE war $2900 (bzw $3900 mit 20MByte HD). Im Vergleich mit der Konkurrenz war der Atari 520ST mit 512kByte ab $800 (Basis $600, +200=$800 mit 12" schwarzweiss Spezialmonitor bzw +400=$1000 mit 12" RGB Videomonitor), trotz einiges mehr an Bauteilekosten als der Mac. Ebenso war der Amiga 1000 mit 256kByte ab $1450 (Basis $1300, +$150=1450 mit normalem schwarzweiss Monitor, +$300=1600 mit 1081 13" Composite+SCART+RGBI Videomonitor), trotz dessen weit teureren aufwendigen Customchips.)
(Selbige Preisvorstellungen hat Steve Jobs bei seiner neuen Firma NeXT wiederholt, mit erstem 68030 Rechner geplant $3000 aber dann verkauft zu $6500. Er ist damit gnadenlos gescheitert, alle Modelle zusammen nur etwa 50'000 Exemplare.)
(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) mit dessen NuBus eine Auswahl von Graphikkarten mit separatem Bildspeicher. Darauf gab es erstmals Farben, mit dem Macintosh II Video Card, in standard 256k mit VGA-artigem 640x480 4bpp, in erweitertem 512k mit SVGA-artigem 640x480 8bpp, auf 13" High Resolution RGB farbigem Monitor. Daneben noch eine Billigkarte Macintosh II Monochrome Video Card mit nur 640x480 1bpp auf 12" High Resolution Monochrome graustufen Monitor. Später zum IIcx (1989) gab es auch grössere schwarzweisse, wie dem Macintosh II Portrait Video Card, mit vertikalen 640x870 in standard 256k 2bpp und erweitert 512k 4bpp auf 15" Portrait Display. Oder gar dem Macintosh Two-Page Monochrome Video Card, mit 1152x870 in standard 512k 2bpp und erweitert 1024k 4bpp auf 21" Two-Page Monochrome Display. (Der Macintosh II war der erste richtig benutzbare und er Macintosh IIcx mit Portrait war der erste richtig ausgereifte und trotzdem kompakte Mac, der erstmals das implizite Potential des Systemes einlöste.))
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. (Man vergleiche dies mit Macintosh, wo von einem 68000 mit Adapter zu 64k 8bit Speicher auf vollen 16bit Speicher sobald genug Chips für 128k notwendig wurden.)
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. Diese 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, und dann 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! Kein Wunder, dass der Rechner ein massiver Flop wurde.
Ebenfalls mit Adressen vom Prozessor, dessen Adressmodi ausnutzend. Aber trotz bis 256k nur 1*64k Adressraum davon nehmend, weil die 256kBytes als 64kWorte von 32bit angeordnet sind! Dies passend zu nur noch 64k Adressen frei haben (A000:xxxx). (Die 4*64k sind in 4 Sätzen zu je 4*16k, aus je 4 Paaren 16kx4bit DRAM Chips, erster Satz 64k auf der Karte, restliche 3 +192=256k auf Erweiterung, zweite dort fest, dritte und vierte als Sockel.) Aus fünf Gate Array Customchips gebaut, wie IBM sie auch in Grossrechner Prozessoren verbaut, weshalb IBM solche Chips selber herstellen kann. Verwendet einen zwischen MDA und CGA kompatibel umschaltbaren Adressbereich von 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.
Verwendet 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. Weiter gab es einen 80x43 Zeichen Modus, mit dabei dem alten 8x8 CGA Font nutzen. Aus RAM Satz, von 256 Zeichen (mit einstellar so dass Attribut Bit3 für 2* 256 nutzbar ist, mit dann aber nur noch je 8 Farben Vordergrund und Hintergrund).
Bitmapmodi einerseits CGA kompatibel 640x200 1bpp und 320x200 2bpp. Aber anderseits eigene 640x200 4bpp und 640x350 1oder4bpp. Bei 640x350@4bpp werden 4*28=112k der 4*64=256k genutzt, was 2 Bildseiten erlaubt. 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 vom Bildspeicher lesen alle 32bits in 4*8 Latches zwischengespeichert. Dann 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, weil mit nur 8bit oder 4bit vom Prozessor 32bit Pixel erzeugt werden. Ein Byte vom Bus kommend geht in eines oder beliebige mehrere der Bänke (Write Mode 0)! Löschen besteht aus 0 in alle Bänke schreiben, egal was die Latches drin haben. Dabei kann man einstellen, welche Bitplanes und welche Bits von Latch oder Prozessor kommen. 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).
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 jedes Bit mit dessen Latch Inhalt OR eingefügt werden können (es hat auch AND zum löschen und XOR zum invertieren sowie obiges voll ersetzen), und dann gleich in nur die erlaubten Bänke schreiben. Aber je nach Farbe teils setzen teils löschen bleibt extrem mühsam, mit 2 Zyklen für AND und OR Modus.
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. Damit kann man einmal Farbe laden und dann direkt schreiben, aber weil damit Prozessor Daten ignoriert nur noch gesteuert vom BitMask Register.
Oder aber die Daten vom Prozessor als Farbe nutzen (Write Mode 2), ebenfalls mit Daten/AND/OR/XOR der Farben. Wonach aber die Auswahl der betroffenen Pixel von der Bitmaske kommen muss. Was Sinn macht wenn man vertikale Linien mit varierender Farbe zeichnen will.
VGA addiert noch Farben von Register mit Daten/AND/OR/XOR aber kombiniert mit bitpositionweise AND ausmaskieren durch Font Pixelmuster vom Prozessor (Write Mode 3). Was dann fast so komfortabel ist wie bei Chunks mit 1bpp, nur mit hier jetzt 2 Zyklen für Hintergrund und Vordergrund Farbe, ausser alles war bereits auf Hintergrund gesetzt.
Mit 16 Farben aus 64 RGB Palette, was auch bei CGA Modi kompatibel benutzt wird, mit dessen 16 festen Farben vorbesetzt. Ebenso bleibt der Vertical Blank Interrupt (VBI) von der CGA. 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 nach schon Bildanfangsadresse beliebig setzen mit einem Zeilenvergleichsregister zum anfang vom Videospeicher springen, für grob scrollen durch Speicher rollen ohne umkopieren.
(Erweiterte Super-EGA Clone konnten mit gleichem Speicher auch 640x480 4bpp (4*38=152k), oder mit ausreichend Speicherbandbreite sogar 800x600 4bpp (4*60=240k), nachdem Multisync Spezialmonitore erschienen. 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 (4*38=152k) mit Bitplanes, dank mehr Speicherbandbreite als EGA. Aber auch die CGA Kompatibilität der EGA wurde erweitert, mit einem vierfachen CGA Multi-Color Graphics Array (MCGA) Modus, genau die in der Einleitung erwähnten 64k 320x200 8bpp. Dies erst noch mit Chunks statt Bitplanes, weil für das PS/2 Model 30 als weitere Verdoppelung der PCjr 32k 4bpp designt, die schon eine verdoppelte CGA 16k 2bpp war, beide mit Chunks. Aber die VGA hatte kein 640x400 8bpp, trotz dass dies noch in die 256k Speicher passen würde, weil die nur 64k an linearen Adressen ohne 4*8bit Bitplanes 32bit Worte es limitierten. In MCGA Modus hat es 256 aus 262144 Farben mit analog RGB dank dem G171 RAMDAC Chip. In EGA und somit auch CGA Modus werden zuerst die 16 Farben aus einer 64 Palette bestimmt (wie EGA), 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 Clone 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 dazu Segmentregister zeilenweise umsetzen. Deswegen laufen bis zu 800x600 4bpp zusammen 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 und somit 4*64=256k, brauchen eine von IBM mangels 640x400 8bpp in der VGA nicht vorgegebene Adresserweiterung, und wurden daher zu einander inkompatibel erweitert! 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 hatten 1 Sprite, oft 16x16 2bpp (transparenz+inversion), als Hardware Mauscursor. Ebenso addierten sie 2D Beschleuniger. Nochmals spätere addierten sie 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 zudem lineare 32bit 386/486 Adressierung erlaubte. Das war die letzte Evolutionsstufe des "klassischen" PCs (= vor PCI/AGP und USB). 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.)
Ist damit ein C64/TED/IIPlus mit doppelter Speicherbreite (von deren 8bit auf 16bit), und doppeltem Speichertakt (von deren 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. Daher kein Zeichencodes holen, und damit ohne jegliche "Bad Lines". Aber ebenso ohne die Sprites, eben eher TED oder II Plus. 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 Chips 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), 71.2Hz 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 die Datenmenge es eigentlich könnte, mit dann 320x400 erzeugen, aber der Shifter und Monitor kann es nicht, weil mit nur 1bit digital Videosignal angesteuert. 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 6x12 Font drin. (Es hat noch einen 6x6 für die Icon Unterschriften.)
Somit alles in allem 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, nur mit quadratischeren Pixeln.) 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, beinhaltend eigene ROMs mit ST spezifischer Treibersoftware von ihnen, sowie Sockel für 2*32k Mac 128k oder 512k ROMs (Magic Sac) bzw 2*64k Mac Plus oder 512Ke ROMs (Spectre), offiziell von einem toten oder aufgegebenen Mac 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 sowie drittel mehr Pixel und Monitorfläche, zu etwa einem drittel vom Preis! Einziges Problem waren das inkompatible Mac Floppy Format, was dann beim Spectre GCR mit einem eigenen Mac-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. Oder gleich von Anfang an, einfach analog zu seiner SwyftCard für Apple IIe ein CatModule für Atari ST machen, anstelle vom Canon Cat. 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 BBC und CPC) (oder einem SCART Fernseher) sind es dann umschaltbar 640x200 2bpp in 32k (und das kann auch 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 16 aus 512 statt aus 64 bzw nur 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, weil bis zu 15 ungenutzte Pixel mitschleppen (mit Chunks nur 7 bei 2bpp und 3 bei 4bpp). 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 Hercules und Mac 1bpp Pixelmuster und separaten Farbcodes basierte, insbesondere 1bpp Fonts direkt nutzen kann ohne sie auf 2bpp/4bpp zu strecken.)
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. Bis auf die etwa 20ms Umkopierzeit (gleich/über 1 Frame bei 50/60Hz = 20/16ms!) bei vollem Bild scrollen, mit Tearing davon (wenn teils Zeilen bereits verschoben sind und andere noch nicht), was in Software mit Timing kompensiert werden muss.
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 oder auslesen) 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 8MHz Taktzyklen, die Systemsoftware disablet diesen bei jedem Aufruf der Defaultroutine.) 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 aber nicht mit 4bpp kompensieren (wie BBC und CPC), ist mit 32k bloss ein verdoppelter statt vierfacher CPC, was den CPC Ansatz von fehlenden Sprites des C64 mit doppelter Speichermenge und bpp 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, nur hier mit besseren quadratischeren Pixeln.)
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!) mit 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 das ganze Bild neu aufbauen arbeiten müssen. Was als Doublebuffering bekannt ist. (Dieses ist auch automatisch sicher vor Tearing, und die Softwaretechnik dagegen.) 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. Dies kann mangels separaten Farbzellenspeicher nicht korrigiert werden, was 80 Zeichen Textdarstellung farblich limitiert auf 4 Farben im ganzen Bild. Nett wäre 640 Pixel mit den 16bit statt 8Pixel@2bpp aufgeteilt als 8Pixel@1bpp plus 2*4bit Farbattribute (wie TMS9918 "Graphic 2"), für alle 16 Farben mit 80 Zeichen (wie CGA Text 80x25), wenn auch zum Preis von nur 2 Farben in einem 8x1 Pixel Feld. 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 modifizieren 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. Vermutlich weil er recht weit reicht. Ansonsten ist MegaST graphisch identisch. Allerdings war er ohnehin auf den Büromarkt ausgerichtet, wo dieser Blitter ausreichte, um in GEM proportionale Fonts beliebig positionieren und Sschraffuren zeichnen 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 MegaST1 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, aber kein 2.5M).))
(Ganz ausser Konkurrenz kamen beim 32bit Nachfahren Atari TT (1990) weitere vierfache 128k Videomodi, genauer wegen noch etwas mehr Zeilen sogar 152k (wie VGA), Schwarzweiss 1280x960 1bpp und Farben 640x480 4bpp sowie 320x480 8bpp, mit beide letzteren sogar VGA bzw MCGA 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 daher wieder vorhanden, nur wegen mit den wenigen Programmen kompatibel sein.)
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 an 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 80bis90% gefüllt, also entsprechen sie etwa 800+500+300 = 1600 bis 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 angenommen, haben sie somit etwa 24000+15000+9000 = 48000 bis 27000+17000+10000 = 58000 Transistoren in sich, mehr als die 38000 Transistoren im 68000 Prozessor! (Offiziell wird der Agnus mit 21000 angegeben, die anderen sind unbekannt.) 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 1600 bis 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 komplett überflüssig ist!). (Dies ist vielleicht der grösste Vorteil gegenüber dem ST, wo dies erst in STE zu spät addiert wurde.) 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) (STE addiert nur in Software aktuelle Adresse ersetzen).
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. Designer 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 auf eine Zeile reduziert wird, auf fast soweinig 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 an 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 wussten 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 Spritepositionen. Weiterhin kann der Copper bis zu erreichen einer Position (nicht nur bis Zeile sondern sogar bis zu genauem Pixel 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 Szenenauschnitte vom Bild. Alles wie im Atari 800, aber hier aufwendiger, weil die Adressen der Zeilen für jede Bitplane einzeln umgeschalten werden müssen, weil die Bitplanes separat im Speicher liegen! Dies gilt selbst wenn sie verzahnt angeordnet sind.
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 Block 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 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 deren 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 kann egal ob mit Blitter oder nur Prozessor bei seinen Pseudobitplanes ebenfalls einfach für Anzahl Bitplanes * AnzahlWorte (=Pixel/16) durchlaufen.)
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 besser 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, um während ein Bild unverändert angezeigt wird ein separates Bild in anderem Speicherausschnitt mit Elemente einkopieren aufzubauen, gefolgt von Bildspeicher umschalteten. Dabei wird sehr viel kopiert, was der Blitter optimal beschleunigen kann, ausser es sind sehr viele kleine Sachen. Dies erst noch ohne dass dabei "Ghosting" sichtbar wird. Der Mehrfachaufwand für jede Plane bleibt aber bestehen, ausser man verzahnt diese. Dies 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 Animationseffekte erzeugen nutzbar, um alle Objekte bitgenau geschoben und ausmaskiert ins neue Bild hineinzurendern, für schnelles 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 dem 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. Man kann aber auch vordere Ebene für einblenden von Statusanzeigen und Steuerelementen nutzen. Mit Copper Speicheradressen umschaltbar auch für verbessertes Mehrfachparallax, mit mehreren Ebenen von denen lediglich pro horizontalem Zeilenband 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 das simples umkopieren ohne einfügen, solange sie nicht überlappen). Erlaubt automatischem einfügen ins Hintergrundbild ohne dieses wegspeichern/modifizieren/wiederherstellen zu müssen. Kommt mit eigenem Farbsatz (wenn auch nur insgesammt 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 Sprites nur im horizontalen Rücklauf laden her (was Compositing aber auch meiden kann).
Mit Farben je nach 1bis5bpp als 2bis32 aus 4096 RGB, die zweiten 16 davon mit den Sprites geteilt. Dazu noch mit 6bpp Hold And Modify (HAM) Modus alle 4096 gleichzeitig, aber nur mit 1/3 Auflösung, ausser bei den 16 "Startfarben" 00TTTT mit voller 320er Auflösung, weil 01BBBB und 10RRRR und 11GGGG ersetzen jeweils einen der RGB Komponenten, womit eine Serie von allen dreien beliebige Farben erzeugen kann, aber vorzu jedesmal die Helligkeit (teil-)modifiziert) wird. Ausser in den ersten NTSC Chips dazu noch 6bpp als Extra Half Bright (EHB) nutzbar für 2*32 (32vollhelle+32halbhelle) Farben. Einige der enorm guten fast photorealistischen Bilder, welche dem Amiga seinen Ruf aufbauten, wurden im 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 zweiten 16 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 Hintergrund 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" 1280×200 NTSC bzw 1280×256 PAL in 128k/164k (sowie mit Interlace doppelte Zeilenzahl), plus mit verdoppelter Horizontalfrequenz doppelhohe "Productivity" 640×480 in 152k (bereits ohne Interlace). Dazu waren nun bis zu volle 2MByte "ChipRAM" nutzbar. Aber wegen weiterhin nur 6 Bitplane Registersätze keine erhöhte maximale bpp, also kein die bestehenden 320x200 bzw 320x256 auf 8bpp erweitern.)
(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 1448×241 NTSC bzw 1448×278 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.)
Einzelner Customchip VDP (Video Display Processor), nicht mehr die TMS9918 Familie wie im 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 Converter"), 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 640x200 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 Parallaxscrollen mit hinterer Ebene durchscheinend, oder auch nur für grosse Objekte. Siehe dazu 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 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. Holt strikte 8bpp aus dem Bildspeicher, aber kann diese nur als 4+4bpp Parallax nutzen, oder als 16+15 Farben, nicht zusammen als 8bpp 256 Farben, mangels Farbregister.
Hat wie Mega Drive neben einer 68000 auch eine Z80 drin, aber stets nur als Audio Koprozessor benutzt. Mit einem YM2610 FM Soundchip. Benutzt separate 64k ("slow") ZellenRAM plus 4k ("fast") ParameterRAM aus SRAM (neben auch 64k Hauptspeicher SRAM, sowie nur 2k Z80 SRAM). Wie bei TMS9918 und Mega Drive mangels Pins keine Adressierung vom Prozessor, braucht eigene Adressregister, verhindert Prozessor Adressmodi ausnutzen. Wird mit diesem Featuresatz von manchen einfach als erweiterte (mehr Sprites) und beschleunigte Mega Drive (AES 12.168MHz bzw MVS 12MHz statt Mega Drive 7.67MHz NTSC bzw 7.61MHz PAL) eingestuft. Hat aber einen total anderen und weit besseren Graphikansatz. Es benutzt dazu wie Famicom / NES separate Busse von Prozessor und Video zu den Modulen, aber hat sogar deren 6(!): 68000 Program + Sprites + FIX (siehe unten) + Z80 Program + 2* Sounddaten, was resultiert in extrem grossen Modulen (mit zwei Platinen drin) mit breiten Steckern (eine pro Platine, AES 2* 2*50pin bzw MVS 2* 2*60pin).
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. Wegen 12.168bzw12MHz Prozessor sind es 6.084bzw6MHz Pixeltakt, was mit 40*8=320 Pixel mehr als volle breites 51.2µs Textfeld erlaubt. Also ist auch Overscan fakultativ abgedeckt, je nach wo/wieviel man Sprites hinstellt. Vertikal PAL 256 und NTSC 224 Zeilen. 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 ModulROM genommen (der Bildspeicher ist zu klein für einen Font, wie Famicom / NES). Mit horizontal und vertikal spiegelbar. Diese bestehen aber aus vertikalen Serien von 32 "Zellen", bis zu 32*16=512 Pixel hoch, welche als "Stripes" bezeichnet werden. Weitere Sprites können zudem mit einem "Sticky Bit" 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 und schnell erlaubt, bis zu volle Bildbreite plus volle Höhe Sprites als Bildhintergrund benutzen. Damit kann man auch einen normalen Hintergrund mit Bitmapmodus simulieren, mit 320/16=20 auf 16x(256oder224) gesetzte Sprites zusammen gruppieren, wenn auch nur mit nicht modifizierbarem ModulROM Inhalt. Damit haben genug universelle Sprites den speziellen Hintergrund komplett ersetzt, was diese Graphik extrem leistungsfähig macht.
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 müssen, sondern auch in den 4/5 des eigentlichen Zeichnens weiter geladen werden können, 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.
Es sind genug Sprites vorhanden, um sogar bis zu 4(!) Ebenen aus je 20 zu simulieren mit nur 80 der 96 pro Zeile, um mit Parallaxscrollen tiefenabhängig zu bewegen, was automatisch durch die Spritesammlung vom Hintergrund passend verschieben entsteht! Es braucht daher auch kein spezielles Dual Playfield, weil 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 wenigen kleinen Sprites und mit nur einem Playfield lediglich halb ausgenutzter Bandbreite die letztere besser auszunutzen mit zweitem Playfield holen. Sobald man gar kein Playfield mehr hat, alle Bandbreite in 5 mal mehr Sprites stecken tut, kann man auch alle einzelnen Objekte als Sprites einzeln scrollen, und damit nochmals weit bessere tiefenabhängige Bewegung 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 diese als Stripes plus mit anhängen bewegbar, bekommt man die für Neo Geo Spiele typischen vielen grossen Sprite Objekte, nur durch die Menge an ModulROM Zellen beschränkt, was diese zur einer der besten 2D Konsole aller Zeiten machte, weil praktisch perfektionierte 2D Techniken.
Weiter kann man die Sprites skalieren, um Objeke tiefenabhängig kleiner erscheinen zu lassen, ohne weitere kleinere Sprites definieren zu müssen, mit dafür mehr ModulROM verbrauchen. Horizontal kann man 1 bis 15 der 16 Sprite Bits nach einem festen Muster gestaffelt ausfallen lassen. Vertikal kann man sogar 1 bis (2*)256 der 512 Sprite Zeilen nach 256 Mustern gestaffelt ausfallen lassen, mit Zeilen 0 bis 255 dem Muster folgend und 256 bis 511 dem reversen Muster.
Erstaunlich gibt es trotz all diesem, und keinem dedizierten Hintergrund, doch einen dedizierten nicht scrollbaren Vordergrund namens FIX, um Userinterface oder Status oder Headupdisplays oder Heathbars darzustellen. Trotz dass all dies auch mit wenigen Sprites problemlos machbar wäre. Aber dieser basiert auf 8x8 Pixel "Zellen", ohne Stripes oder Sticky, und nimmt diese aus einem zweiten von den Sprites separaten ModulROM mit 4096 Zeichen Platz. (MVS kann für Betrieb ohne eingestecktem Spiel auch auf ein fest eingebautes SystemROM umschalten.) Womit man doch noch zu einem texttauglichen Zellmodus kommt. Bildspeicher ist ausgelegt auf 40x32 PAL oder 40x28 NTSC, aber wegen Overscan abziehen reicht das für etwa 36x(28oder24) Zeichen/Zellen.
Farben mit Register auswählbar aus 65536 RGB. Eigentlich sind es RGB je 6bit für 6*6*6=262144 Farben, sogar volles 18bit(!), aber mit dem niedrigsten Bit aller drei identisch für in 16bit passen, also 5R+5G+5B+1LSB. Dazu hat es 2*4096(!) 16bit Register (weitere 16k an PaletteRAM) um 2 256er Sätze von 15Farben+1Transparent festzulegen. Jede 16x16 "Zelle" der Sprites hat eine eigene der aktuellen 256 Sätze zugeordnet, jede 8x8 "Zelle" von FIX kann aber nur die ersten 16 Sätze nutzen. Wie man sieht ist dies eigentlich ein featuremässig sehr einfaches, aber mengenmässig extrem leistungsfähiges System.
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 ZeichenRAM und FontRAM (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 ZeichenRAM auslesend und PPU-2 FontRAM auslesend). Was aber zumeist nicht der Fall sein kann (ZeichenRAM hat Zeichencode+Attribut 2 Bytes pro Zelle während FontRAM bei 2bpp oder 4bpp aber 2 bzw 4 Bytes pro Zelle braucht). Damit genaues Gegenteil der Mega Drive ihres 16bit Rechners mit 8bit Video, hier 8bit Rechner mit 2*8=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, womit es 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, während die Superfami / SuperNES von dem 32k 8bit FontRAM 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 umschalten.
Farben sind 16 Sätze von 4 oder 16, aus 32768 RGB (mehr als alle ausser MCGA und Neo Geo). Jeder Layer kann die ersten 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. Weiter kann er ohne Layer zusammenlegen zu 8bpp mit allen 256 Farben. Modus 0 ist 4*2bpp, 1 ist 2*2bpp+1*4bpp, 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 den zweiten 8 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 ZeichenRAM und FontRAM in 1 FontZugriff = 1 Byte = 1 Pixel resultiert. Mode 7 tut dann nur noch aus ZeichenRAM Zeichencode und Zelle+Pixel ihrer Position die Koordinaten in zusammengesetze FontRAM Adressen transformieren, statt 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 Super 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). Selbiges gilt für das stärkere aber sauteure Parallelstück dazu, dem 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 problemlos in 2D behandeln konnte, trotz keine Hardware Sprites (wie Atari ST). 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. Bei Sega war selbst die Saturn unzureichend, erst die Dreamcast taugte. Bei Nintendo war die N64 grenzwertig, erst die Game Cube taugte wirklich.)
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).
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).)
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.
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.
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.
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. 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 Bitmap, ausser bei V9938.
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.
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.
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.
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.)
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 auch 4bpp und sogar 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. Ebenfalls die Neo Geo, mit dem FIX Vordergrund seinen 4bpp, nach Abzug vom Overscan etwa 32x(29oder25) Zellen.
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:
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:
(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üroftware. 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 Clonen 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 Abstrich für die die fehlenden Bitmaps. Des weiteren geringerenAbstrich für nur ModulROM Font. 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 (Nintendo Playchoice 10 und VS Automaten beinhalten von NTSC/PAL auf RGB modifizierte Famicom / NES Graphikchips, VS auch Famicom / NES Graphikchips und Prozessorchips!). 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 dumme 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). 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 mit 80x25 Zeichen, aber ohne jegliche 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ürosoftware. Wenigstens ist das Paging sehr freundlich zu solcher, und dessen Design auf 320k oder gar 576k erweiterbar.)
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 für die Playstation 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.)
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.)
(Der CPC6128 lieferte analog zu Commodore 128 und Atari 130XE mehr Speicher. Aber nicht mehr Video, weil bereits in der Basisversion Text mit 80x25 Zeichen. Zudem ist das Paging wie beim 130XE sehr freundlich zu Bürosoftware, sogar noch etwas besser (weil CP/M 3.0 Modi), und dessen Design ebenfalls auf 320k oder gar 576k erweiterbar.)
(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, und dort auf ganz zuoberst. 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 Floppydisk 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 2 geht fast gleichauf an den Acorn BBC Micro. Selbige 640 Pixel sowie bei 320 Pixel bereits 2bpp und vor allem bei 160 Pixel volle 4bpp. Preis dafür ist wieder der Verbrauch von sehr viel Bildspeicher (wählbar 20.5/16/10.25/8k, letztere beiden aber mit nur noch 320 Pixel und 160 Pixel 2bpp), sowie viel CPU (was dessen ungebremste 2MHz 6502 ebenfalls auch recht gut kann). Im Vergleich zum CPC kann der BBC mit optionalen 256 statt 200 Zeilen sowie halbierbarem Speicherplatzverbrauch punkten, aber limitiert auf nur 2*2*2=8 statt 3*3*3=27 analog RGB Farben bleibt er trotzdem leicht zurück.
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ürden sie 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 diesen 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 ganz 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 FontRAM Font zusätzlich zu 128 Zeichen FontROM 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 soäten 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 letzterer, 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 mangels dem separatem 2k AttributRAM der MDA nur in Textmodus Attribute hat. Was alles 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 und 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 mit 16bit Adressen und 64k direkt nutzbarem Speicher, das aber mit sehr komfortabler eingebauter Adresserweiterung auf massive 1024kByte. Diese kann spezifisch nach Funktion 4 separate 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 von Hause aus 64+(2*)256k, wie bei erweiterten Atari 130XE und CPC6128, 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 mit der 8088 aufnehmen. Dazu kam beim 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 Clonen 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 128k 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.) (Die 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 Clonen.)
(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 in 1986 weitaus 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 schlicht wegen dem Alter, und den damals sehr kleinen und trotzdem teuren SRAM Speicherchips.
(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! Logisch keinerlei Farben, als eine mit Bitmap erweiterte IBM PC MDA. Damit fast identisch mit der Lisa, trotz nur 8bit. Er würde damit in obiger Katagorie auf Platz 4 kommen, nach der KC 85/2 (mangels Farben) und vor der MTU K-1008 Visible Memory (weil 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.)
(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 Clone antreten (strikte war externe HD machbar, am Expansionsport, im Format eines Sidecar). So war der 1000 nur eine Kompromissvariante, welche keine Anwendergruppe wirklich befriedigen konnte. Bis er nun 1987 in die 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 Clone 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 maximale bpp, kein 320x200oder256 mit 8bpp. Was in 1990 nicht mehr gegen den schon 2 Jahre alte VGA ausreichte, mit dessen MCGA 320x200x8bpp Chunks in 64k.)
(Die 32bit Advanced Graphics Architecture (AGA) A4000 und A1200 und CD32 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 Clone 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 und 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 CD32 (1993) richtig gemacht, als A1200 basierte CD-Konsole plus fakultative Tastatur und Maus. Aber diese kam weit zu spät, gegen inzwischen 486er PC Clone 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 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 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 Clone, 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 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, einen Soundchip 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 Soundchip 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 Anwendung (wie MDA und CGA den IBM PC). Mit letzterem ist er ein vierfacher Apple II Plus, mit 640x200 2bpp und 320x200 4bpp aus 32k. 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, was bei 1bpp Schwarzweiss voll gelungen ist. 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, eben vierfach II Plus. 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, erst recht wegen den Problemen mit Pseudobitplanes sowohl mühsam wie auch langsam. Allerdings konnten scroll-lose RPGs und 3D Spiele unbeeinflusst davon die mehr Prozessor und Speicher zwecks Illustrationen dekomprimieren oder gar Szenen rendern ausnutzen. Selbiges gilt für die fehlenden Sprites, es fehlen die einfachen aber grossen vom C64. Was wieder wegen Compositing brauchen grosse bewegende Graphiken ausbremst, aber statische RPGs nicht trifft, und auch nicht Spiele mit vielen kleinen Objekten wie Puzzles (wo Amiga die Spriteanzahl limitiert). Aber bei Bewegungen bremsen die Pseudobitplanes gerade horizontal schmale Elemente und Objekte mehr aus (vertikal ist der rein lineare Bildspeicher optimal schnell, aber es fehlt zirkulären Bildspeicher rollen). 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 und scrollen eher profitiert. 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. Wenn auf generellen Büro Rechner statt spezifisch auf Spielerechner bewertet hätte er den Amiga gleichgezogen oder gar geschlagen. 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, auch als Spielerechner. Mit Chunks statt Pseudobitplanes (wie BBC und CPC), und damit Compositing schneller, sowie fein scrollen um Faktor 4 weniger wichtig, hätte er erst recht geteilt. Mit Chunks plus fein scrollen noch mehr so. Mit zudem vierfach grosse Sprites vom C64 hätte er den ersten Platz alleine genommen.)
(Der Atari STE erweiterte 1989 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 weiter mangelns Sprites nicht mal annähernd 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. 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 152k), Schwarzweiss 1280x960 1bpp sowie Farben 640x480 4bpp und 320x480 8bpp. Nur konnte man diese Graphik ausschliesslich mit 32bit haben, zu 386er Preisen, während bereits 286er PC Clone mit VGA laufen konnten. Die billige STE versagte das halbe davon zu liefern.)
(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 Clone 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 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, Soundchip 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 Clone 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, Text kann etwa 36x(28oder24) Zeichen/Zellen nutzen. Aber kann kein 640er Raster, auch nicht auf 640-32=608 reduziert oder 64 Zeichen, nicht mal zum Preis von auf 2bpp herunter, was ihn hinter Amiga und Atari ST stellt. Hat keinen Bitmapmodus (und auch keinen Zellmodus), sondern nur Sprites, diese aber 16x512 Bitmaps aus Serien von 16x16 Zellen. Kann aber mit FIX einen 8x8 Zellmodus überlagern. Kein interlaced. Was alles ihn leicht weiter hinter den Amiga stellt. Keine Tastatur oder Disk, wenig Speicher, und damit die Limiten aller reinen Abspielkonsolen gegenüber Homecomputer. Was ihn klar hinter den Amiga und selbst den 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. Holt strikte 8bpp, aber kann diese nur als 2*4bpp Parallax nutzen, und somit als als 16+15 Farben. 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 Bitmap zu simulieren trotz Font in VideoRAM, oder auch nur bandweises Parallax, bleibt so deutlich zurück. 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 mit echten 8bpp diese zu 256 zusammenlegen, neben Parallax mit 4+4bpp oder 2+2+4bpp oder 2+2+2+2bpp. Kann zwei 512 breite Modi mit halben bpp. Hat permanentes Overscan (was etwa (48..56)*8=384..448 breites Textfeld ergibt). Aber all das wurde 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 separates ZeichenRAM und FontRAM) 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 1bpp Schwarzweiss mit Auflösung für Business und 4bpp viele Farben für Spiele, beides richtig gemacht.) Dazu noch keine Sprites (wie Atari ST), aber auch ohne dessen 320 Pixel und ohne dessen wählbaren 16 auf 512 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 allen 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 existierte 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 begraben, mit Erpressung die Apple II Basic Lizenz nicht zu verlängern.) 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, und 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 nur Schwarzweiss Video, was diesen eben zum Jackintosh machte! 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.
Ganz ausserhalb der Konkurenz ist die IBM PC EGA. Ihre massiven 4*64=256k stellen sie weit oberhalb der 64k Grenze, und somit disqualifiziert. Ebenso sind ihre 4*8=32bit ausserhalb dieser 16bit Kategorie, trotz dass sie in 16bit AT und sogar in 8bit PC und XT passt. 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 Clone addierten nur Auflösung bis 800x600. 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, mit nur 4bpp. Den "graphischen" Mac schlägt sie aber sowieso locker, schlicht weil der der gar keine Farben kann, oder auch nur Graustufen, und weniger Auflösung hat. Selbst der leicht bessere QL hat keine Chance, mit nur 4 oder 8 festen Farben, und weniger Auflösung.
(Die IBM PC VGA (1988) kam neben ihrer 640x480 4bpp auch mit dem MCGA 320x200 Modus als allererste auf 8bpp, und damit vor allen anderen Rechnern hier! (SNES 8bpp Mode 7 ist erst 1990/91.) Wenn auch anfangs nur mit 320x200 8bpp in 64k, bloss 1/4 von ihren 256k ausnutzend. Zumindest bis erweiterte Super-VGA Clone 640x480 oder gar 800x600 8bpp addierten. Es reichten aber bereits die 320x200 dank schaltbaren Modi, solange man keine Sprites brauchte. Was aber ohnehin mit genug PC Prozessorleistung (ab 12/16/20MHz 286er) 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. Zudem haben die PCs auch noch genau die 64k Limite in der Einleitung erreicht, und somit ist der MCGA Modus auch das Ende dieser Übersicht.)
(Das Fehlen von vergleichbaren Modi bei Atari ST und Amiga wurde zum Anfang von deren Abstieg. Bei 8bit legte Apple II mit 8k einen Basiswert. Atari 800 und C64 erweiterten dies mit 2bpp und Sprites. Apple IIe und BBC und CPC konterten mit 16k und 4bpp. Bei 16bit erlauben doppelte Busbreite und inzwischen doppelte Taktung vierfache Bandbreite. Atari ST mit 32k ist damit genau vierfach Apple II Plus. Amiga mit 32k und Sprites ist vierfach Atari 800. Was komplett fehlt bei 16bit Rechnern ist vierfach C64 (am ehesten ist der nur-Japan Sharp X86000 dies). Aber vierfach IIe/BBC/CPC mit 64k hätte geschehen sollen, die fehlenden Sprites mit 64k und 8bpp kompensiert (wie PCjr und BBC und CPC die 8k+Sprites mit 16k und 4bpp). Aber Macintosh stagnierte auf 512x342 1bpp, unterhalb 32k. Erst der Macintosh II (1987) lieferte PC-artige Karten, aber nur mit 600x800 2bpp Graustufen und 640x480 4bpp Farben auf VGA Niveau, ohne MCGA. Atari MegaST (1987) und selbst STE (1989) stagnierten auf 32k. Statt mit inzwischen auch bei billig 5MHz statt 4MHz schnellen DRAMs ausnutzen, für 2 mal 16bit per Pagemode Doppelzugriffe mit 1*/RAS+2*/CAS holen für 64k (wie CPC, dort mit 2.5MHz statt 2MHz), am besten diese neuen Modi (zumindest die 320x200 8bpp) zudem mit Chunks (wie MCGA). Atari TT (1990) lieferte sogar 152k wie VGA, aber spät und gekoppelt an teurem 32bit System. Amiga ECS (1990) lieferte 64k/82k, aber nur bis zu 6bpp und das erst 2 Jahre nach MCGA, nicht genug zum aufholen. Amiga AGA (1992) lieferte sogar 152k wie VGA, aber weitaus zu spät. Mega Drive (1988) lieferte mit Amiga vergleichbare Graphik, ebenso SNES (1990/91), beide aufgeholt wegen der Stagnation. Nur PC ist mit MCGA schon 1988 auf 64k und 8bpp aufsteigen, neben VGA die EGA von 112k auf 152k erweitern, und danach mit SVGA weiter davonlaufen. Addiert man PCs damals noch vollkompatibel erweitert, sowie wegen Standarderzeugnis von vielen Konkurrenten mit einer Auswahl vieler beliebiger Taiwan Clone, damit sowohl billig werdend, wie auch fehlerhafte Firmen einfach ausgesiebt werdend. Damit versagen ST und Amiga den Atari 800 und C64 zu folgen und die dummen Abspielkonsolen fertig auszurotten, und wurden statt dessen zwischen Konsolen und PCs in die Schere genommen. Was zum Abwandern der Benutzer und Ende dieser letzten beiden verbleibenden Homecomputer Hersteller führte, und ab 1990 zum Kontrast von einfachen aber zugenagelten Konsolen zu flexiblen aber komplizierten PCs, statt den besseren einfachen und flexiblen aber stehengebliebenen Homecomputern.)
Diese Seite ist von Neil Franklin, letzte Änderung 2024.04.19