Diese bisher ausgeklammerte Ein-/Ausgabe ist nun aber das einzige das noch verbleibt. Als die aktuellen Vorträge sind daher verschiedenste Varianten dazu an der Reihe. Hier wird nun ein zweiter Ausschnitt davon nachgeholt. Verbleiben tun dann nur noch, exotischere Varianten nachzuliefern.
Die Frage welchen Teil der verbleibenden vielen Varianten als Zweites kommt beantwortete sich gleich selber, aus dem vorletzen Vortrag seiner Kommunikation von CPU zu CPU, dass nun Kommunikation zwischen Benutzer und CPU an der Reihe ist. Diese ist sehr vielfältig, und kann daher einen kompletten langen Vortrag ausfüllen, ohne dass weitere Themen addiert werden müssen.
Weil dazu Daten erzeugt oder verwertet werden müssen, welche eine Bedeutung für den Benutzer ausserhalb des Rechners haben, kommen hier notgedrungen auch die ganzen Probleme mit Datenformaten zum Zug, wie Sachen aus der realen Welt im Rechner als Daten repräsentiert und codiert werden, sowie die ganzen Konvertierungen die dabei vorgehen. Hier kommen aber nur einfache Datentypen zum Zug, keine aufwendigen Fileformate.
Dieser Vortrag ist der vierte Teil zu drei früheren Vorträgen, der erste 2006.05.01 - Rechnen mit Bauklötzchen - Rechnergrundlagen und deren Implementationen, der zweite 2008.04.26 - 8008 8080/8085 und Z80/U880 - Maschinencode und Assembler, und der dritte 2010.05.01 - Kommunikation - Schnittstellen für Datenübertragung von CPU zu CPU. Darin wurden bisher im ersten die Bits und ihre Implementation in Hardware als Gatter und daraus zusammengebaut Speicher und Prozessor gezeigt, sowie im zweiten die ganzen Prozessordetails wie Register und Rechnen und Befehle und Programmierung in Maschinencode und Assembler, sowie in dritten wie Daten per einfachen Ports oder PIOs grundsätzlich kommuniziert werden und wie der Prozessor diese abschickt und empfängt.
Daneben wurde schon bisher in einem weiteren Vortrag 2009.05.01 - Softe Hardware - Emulation von hochintegrierten Chips auf Mikrocontrollern neben dem Mikrocontroller auch minimalste PIO Ein-/Ausgabe für das SoftVGA Video generieren eingeführt. Also dient diesen wiederholen gleich als Ausgangspunkt für den Videomonitor Teil von diesen Vortrag.
Ausserdem ist Ausgabe historisch leicht älter als Eingabe, da ganz alte Rechner Eingaben nur als Teil des Programmes schreiben und laden entgegennahmen, und damit nur ihre beereits vorhandenen Speichermedien als Eingabe kannten. Die Ausgabe nur auf Speichermedien ausgeben (z.B. Lochstreifen oder Lochkarten von Auge auslesen) war mühsam und viel zu limitierend, und musste ohnehin immer separat von Programm laden sein, und sei dies auch nur auf einen Drucker ausgeben, welcher damit auch zum ersten Peripheriegerät aller Zeiten wurde.
Das einzige was man am Rechner braucht ist dazu eine Parallel/Seriell Wandlung, um die seriellen Signale zu simulieren, wie sie ein anderer Fernschreiber sein PISO erzeugen würde. Diese kann aus Ports oder PIOs mit Software bestehen, um Zeichen in Bits zu zerlegen und diese zeitlich richtig abzuschicken (das nennt man Bitbanging), oder aus einem Hardware PISO Schieberegister in dem man einfach ein Zeichen als Datenbyte einschreibt (wie in einen Port) und wartet bis es vom PISO weggeschiftet worden ist. Letzteres ist einfach eine elektrische Reimplementation dessen was der Fernschreiber auch in Elektromechanik macht.
Nachdem ein Zeichen wie bekannt seriell beim Fernschreiber angekommen ist, und in dessen Relais der Seriell/Parallel (SIPO) Wandlung durchgeführt und das Zeichen gespeichert ist, wird nun gedruckt. Dazu müssen 2 Sachen vom internen Controller das Fernschreibers unterschieden werden: Druckbare Zeichen (ASCII Codes 32 bis 95) (die 96 bis 126 existierten damals noch nicht), sowie nichtdruckbare Steuercodes (ASCII Codes 0 bis 32, sowie 127), was damit einfach ein Test auf Bit5 ungleich Bit6 war. Die nutzbaren Zeichen (inklusive die späteren 96 bis 126) sind:
ASCII ISO 646 7bit
(Hex 0_ und 1_ sind Steuerzeichen)
(Hex 2_ bis 6_ sind druckbare Zeichen, = 32 bis 95)
(Hex 6_ und 7_ sind druckbare Zeichen, = 96 bis 126)
(Hex 7F ist gelöschtes Zeichen, DELete, = 127)
| _0 _1 _2 _3 _4 _5 _6 _7 _8 _9 _A _B _C _D _E _F
---+---------------------------------------------------------------
|
0_ | NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI
|
1_ | DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US
|
2_ | ! " # $ % & ' ( ) * + , - . /
|
3_ | 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
|
4_ | @ A B C D E F G H I J K L M N O
|
5_ | P Q R S T U V W X Y Z [ \ ] ^ _
|
6_ | ` a b c d e f g h i j k l m n o
|
7_ | p q r s t u v w x y z { | } ~ DEL
Erstere (32 bis 95/126) werden einfach gedruckt. Dazu wird ein senkrecht stehender zylindrischer "Finger" benutzt, der aus 4 Scheiben besteht, die jeweils auf ihrem Umfang 16 Zeichen haben. Bits 0 bis 3 vom ASCII Code drehen den Finger um 8/16 8/16 2/16 bzw 1/16 falls sie "1" sind. Dies geschieht durch 4 Elektromagnete, welche von "1" Bits eingeschaltet werden, mit geeigneter Mechanik dahinter, welche einen Seilzug mehr oder weniger weit zog. Dieser lief um eine Scheibe, welche dadurch um 0/16 bis (8+4+2+1=15)/16 Drehung rotiert wurde und den Finger so in 16 Positionen 0..15 drehte. Strikte ist dies ein elektromechanischer 4bit Digital/Analog Wandler. Bits 4 und 5 heben dem Finger um 2/4 oder 1/4, für 0/4 bis (2+1=3)/4 dessen Höhe, ein weiterer 2bit Wandler. Mit diesen beiden Bewegungen wird das richtige der 4*16 = 64 Zeichen in die vorne/oben Position gebracht. Dann wird der Finger durch einen weiterem Elektromagneten auf das Papier geschlagen. Danach wird der Schlitten mit dem Druckkopf darauf per weiterem Elektromagneten oder als Seiteneffekt das Schlagmagneten loslassen um eine Stelle nach rechts bewegt.
Zweitere (0..31,127) werden nicht gedruckt. Vielmehr müssen deren Bitkombinationen erkannt werden und dann das Druckwerk möglicherweise speziell beeinflusst werden:
Ab der Selectric III gab es einen neuen 4*24 = 96 Kopf, mit 12 der 16 Rotierer Kombinationen ausnutzend, und damit der ganze ASCII Zeichensatz mitsammt Kleinschrift darauf passend, ohne 95-88 = 7 Sonderzeichen opfern zu müssen. Dies wurde so gemacht trotz dass die Tastatur nur 92 Zeichen erzeugen konnte, womit die anderen 4 nur in Terminal Modus sinnvoll waren, und auch dort nur 3 davon genutzt wurden.
Dies ist einfacher, weil es nur eine mechanische Bewegung und Richtung von dieser gibt, Rotation um eine Ache die in Richtung vorne-hinten läuft. Dazu ist nur ein einzelner (aber aufwendigerer) 7bit Digital/Analog Wandler nötig, um das Rad in 128 Positionen zu drehen. Wobei sehr oft statt dessen ein Elektromotor zum rotieren benutzt wird, der solange dreht, bis an der Welle angebrachte 7bit Winkelsensoren die richtige Position vermelden (mit dem 7bit Zeichencode verglichen, 7 XOR und ein 7-AND Gatter).
Dies ist schneller, weil die Radnabe und Drehmechanismen zum Drucken nicht bewegt werden müssen. Vielmehr befinden sich die Zeichen an den Enden der "Speichen" des Rades, welches keinen Aussenring hat. Zum Drucken wird nur mit einem Elektromagneten ein Hammer von hinten auf das Zeichen geschlagen. Dies erlaubt etwa 30 (Diablo) statt 10 (Fernschreiber) oder 13.45 (Selectric) Zeichen pro Sekunde.
Der Weg zur Beschleunigung bestand darin eine ganze Zeile aufs mal zu drucken (parallel), statt individueller Zeichen (seriell), weshalb diese auch als Zeilendrucker bezeichnet werden. (Dies ist im Englischen als Lineprinter bekannt, was auch die Bedeutung vom LPT: als Druckername in MS-DOS ergab, sowie des lpr Kommandos in Unix.)
Da diese keine bestehenden Fernschreiber sind, sondern speziell für Rechner gemachte Drucker, wird hier auch nicht mehr deren serieller Datentransfer per PISO und SIPO nachgebildet werden, sondern die Zeichen können direkt parallel über 6 bis 8 Leitungen geschickt werden. Der Rechner schreibt diese direkt auf einen Port oder PIO Pins, mit einem simplen automatisch beim Schreiben generierten Strobe, und muss dann nur noch warten bis ein Zeichen verarbeitet worden ist, wozu ein Acknowledge Signal vom Drucker kommt. (Daraus entstand auch zur Minirechner Zeit die parallele Centronics Schnittstelle, die etwas variert im PC zur Druckerschnittstelle wurde, und in MS-DOS eben LPT: als Namen bekam.)
Ebenfalls wurden anstelle vom ASCII Code der Fernschreiber diverse herstellerspezifische oder gar gerätspezifische Codes benutzt, oft nur 6bit, teils aber auch 8bit. Der 8bit EBCDIC Code der IBM Grossrechner stammt von solchen Druckern ab.
Um zu drucken muss der Drucker zuerst eine ganze Zeile an Daten bekommen, um sie danach beim Drucken alle vorzu zu vergleichen. Also werden diese beim Empfang nur in einen internen Speicher geschrieben. Daher kann der Rechner oft eine Zeile mit maximaler Geschwindigkeit dort hinein schicken, als Speicher-via-Kabel-zu-Speicher Kopie, ohne jegliche Warterei. Gewartet wird erst nach dem Zeilenende, auf den eigentlichen Druckvorgang.
In diesem werden während einer Trommeldrehung vorzu für alle zu druckenden Zeichen mit dem Zeichen des aktuellen Trommelwinkels verglichen, und die Hammer zur passenden Zeit "abgefeuert". Leerzeichen werden schlicht nirgends abgefeuert. Da die Trommel dauernd dreht, ist deren Position nach Ankunft der Zeile variabel, was aber nicht stört, weil einfach ab dann eine ganze Umdrehung Druckzeit ist, und dies nur die ohnehin irrelevante Druckreihenfolge variert.
Dies erzeugt aber alle identischen Zeichen aufs mal, was gerade bei Zeilen mit horizontalen (Unter-)Strichen einen massiven Schlag erzeugen würde, und das Netzteil mit vielen Hammern antreiben überlasten würde. Weshalb manche Trommeln je nach Position für identische Zeichen den Winkel der "Scheiben" varieren. Dies macht aber die Steuerung aufwendiger, weshalb teilweise mit "Gruppen" identisch angeordneter Scheiben gearbeitet wird als Kompromiss.
Nach einer Trommelumdrehung sind alle Zeichen vorbeigekommen und gedruckt worden, und das Papier wird vorgeschoben. Ab diesem Zeitpunkt kann auch parallel zum Vorschub die nächste Zeile Zeichen vom Rechner angenommen werden, womit keine Kopierzeit verschwendet wird. Dies reicht für 300..600 Zeilen/Minute (= 5..10 Zeilen/Sekunde), was bei angenommenen 0..80 Zeichen/Zeile auf (300..600)*(0..80)/60 = ca 300 Zeichen pro Sekunde hinausläuft, 10 mal die 30 des Typenrades, oder gar 30 mal Fernschreiber.
Es gibt keinen Druckkopf und ebenso keinen Kopfrücklauf, womit ein Zeichen analog zu ASCII CR und/oder BS bedeutungslos wird, und diese genauso wie NUL und DEL ignoriert werden. Ein BEL wird ohne Signalglocke genauso ignoriert. Ein HT könnte mehrere Leerzeichen erzeugen, aber wird selten angeboten da die Leerzeichen &Uuuml;bertragung schnell ist.
Erst ein LF ist der Auslöser, sowohl des ganzen Druckvorganges wie auch des Vorschubes danach. Dieses kann aber auch, als einziges verbleibendes Steuerzeichen, um die ganze Druck-/Nichtdruckzeichen Unterscheidung einzusparen, sehr oft mit einer separaten Anschlussleitung ausgelöst werden, z.B. indem der Rechner nach 0..80 mal Schreibzugriffen auf den Datenausgangsport 1 mal auf einen Steuerausgangsport schreibt (mit Datenwert egal). Wieder könnte ein VT benutzt werden um mehrere Zeilen vorzuschieben, aber wird genauso selten angeboten, da die Zeilenvorschub &Uuuml;bertragung schnell ist.
Nebenbei: Wenn man dann auch noch mit Lochkarten oder mit Records auf Disk arbeitet, wo wegen fest gegebener Zeilenlänge gar kein LF oder vergleichbares darin ist (nur mit Leerschlag oder Null aufgefüllt), kann sogar ein Zeichensatz ganz ohne ein LF Steuerzeichen (oder jeglichen anderen) benutzt werden.
Will man auf einem Drucker mit Auslösung erst durch LF oder separatem Drucksignal nur drucken aber keinen Vorschub haben, für Fettdruck oder Unterstreichen, oder anderseits mehrzeiligen Vorschub um schneller zu sein, kann man bei manchen Druckern als erstes Zeichen der Zeilen sogenannte ASA Steuercodes schicken:
Bei Band- bzw Kettendruckern wird obiges Problem dadurch gelöst, dass die Zeichen nicht mehr auf einer Trommel sind, deren Fläche sich vertikal dreht, sondern einem Band oder Kette, welches horizontal durch den Drucker gezogen wird. Damit sind die Verschiebungen und Verschmierungen nun horizontal, womit das Zeilenbild nicht mehr unruhig wird, und damit weit lesefreundlicher.
Dazu braucht es auch nicht mehr jedes Zeichen für jede Position wiederholt, weil das eine Band an allen Positionen vorbeikommt. Das spart Aufwand um die Zeichen herzustellen. Damit ist es aber auch automatisch unmöglich dass alle identischen Zeichen ihre Hammer gleichzeitig gefeuert werden. Anderseits ist ebenfalls damit aufwendigere Steuerung nötig, weil unvermeidbar jede einzelne Position ein anderes Zeichen vor sich hat, und theoretisch dabei gerade eine Ausgabezeile aufs mal passieren könnte, oder eher ein zu grosser Anteil einer Zeile.
Die Bandlänge ist aber, weil mindestens 2 mal Papierbreite plus 2 mal Umlenkung, zu lang für den Zeichensatz, also wird dieser mehrmals wiederholt. Das kann einfach identische Wiederholung sein, oder es werden häufiger benutzte Zeichen (z.B. Ziffern) zwecks Verteilung derer Abnutzung häufiger wiederholt. Wenn man ausschliesslich Zahlenkollonnen druckt kann man damit auch die Wartezeit reduzieren, nur bis diese 10 Zeichen überall einmal vorbeikamen, womit schneller gedruckt wird. Dies gilt erst recht wenn man ein spezielles Band mit nur Ziffern und ein paar Zeichen wie +/-/./,/etc einlegt.
Die normale Form war der Stiftplotter. Hierbei wird ein Filzstift (oder Tuscheschreiber) in einen "Druckkopf" eingehängt, der den Stift mit einem Elektromagneten auf das Papier senken/drucken kann. Der Kopf befindet sich auf einem Schlitten, der mit einem Elektromotor in "Y" Richtung des Papiers (die kleinere Richtung) bewegt werden kann, sowohl mit dem Stift oben (Positionierung) wie auch mit dem Stift unten (Zeichnen). Für die "X" Richtung gibt es 2 verschiedene Bauformen:
Zumeist wird mit Schrittmotoren gearbeitet, die mit jedem elektrischen Impuls um einen bekannten Schritt bewegt werden, oft um 0.1mm. Zumeist haben solche Motoren 4 Anschlussleitungen a+c und b+d, die in 4*2 Schritten von a+c, 0, b+d, 0, c+a (negativ), 0, d+b (negativ), 0 pulsweise mit Strom versorgt werden. Dazu werden alle 4 Anschlüsse per je 2 Transistoren entweder zu + oder - verbunden. Dann werden diese wiederum mit normalen Port oder PIO Pins angesteuert. Ebenso wird auch der Stiftmagnet aktiviert.
Dies ergibt nur relative Bewegung. Damit man die absolute Postiton weiss wird beim Einschalten solange in eine Richtung gefahren bis der Schlitten an Ende auf einen Schalter oder durch eine Lichtschranke auffährt, welche per Eingabeport oder PIO Eingabe gelesen werden kann. Dies ist die Nullposition, 0/0, zumeist links/unten. Ab hier wird bei jedem Impuls die Position mitgezählt, je nach Richtung der Pulse +1 oder -1, bis man am angezielten Ort ist.
Dies ist für genau horizontale oder vertikale Linien problemlos, nur ein Motor bewegen, aber aufwendiger für schräge. Genau 45grad ist einfach stets beide Motoren, alle anderen ist einer bewegt und der andere manchmal. Für diese notwendige koordinierte zweidimensionale Bewegung entscheiden wird der Bresenham Algorithmus verwendet. Dabei werden die aktuelle Position und die Zielposition verglichen, und aufgrund der beiden X und Y Differenzen ihrer Richtungen, sowie welche Differenz grösser ist, 8 verschiedene Formeln benutzt. Diese unterscheiden sich in der Richtungen X = -n/+n, Y = -n/+n, sowie ob n für X oder Y stets 1 ist (für den mit der grösseren Differenz) und für den anderen teils 0 oder 1 wird. Der Rest ist nur noch bestimmen, ob letzteres n dann 0 oder 1 sein muss. Dies geschieht indem zu einer Hilfsvariable (die anfangs 0 ist) die kleinere Differenz addiert wird, mit 1 falls das Resultat die grosse Differenz erreicht oder überschreitet, sonst 0. Falls es 1 ergab wird auch die grosse Differenz von der Hilfsvariable abgezogen. Damit hat die Hilfsvariable ein Zickzack bzw Sägezahn Verhalten, das den Stift im richtigen Verhältnis fährt.
Als Beispiel das Pythagorasdreieck mit seinen 3:4:5, als 40mm:30mm:50mm, bei 0.1mm Schritten als 400 horizontal (von 0/0 zu 400/0), 300 vertikal (von 400/0 zu 400/300), 500 schräg (von 400/300 zu 0/0). Für die 500 ist Diff-X = -400, Diff-Y = 300, damit ist Richtung X = -1 und Y = -1, und X wird immer 1 geschritten, 400 mal, Y teilweise, Hilfs = 0. Stift geht bei 400/300 herunter. 0+300 = 300 ist unter 400, also Stift links zu 399/300 gehen. dann 300+300 = 600 über 400, also -400 zu 200, und Stift 45gad schräg zu 398/299. Dann 200+300 = 500, über 400, also -400 zu 100, Stift schräg zu 397/298. Dann 100+300 = 400, erreicht 400, also -400 zu 0, Stift schräg 396/297. Ab jetzt wiederholt sich dieser 4er Zyklus, links/schräg/schräg/schräg, l/s/s/s, l/s/s/s, für 400/4 = 100 mal 4 links und 100 mal 3 schräg, womit der Stift von 400/300 zu 0/0 geht.
Kreise kann man mit einer erweiterten Version des Bresenham zeichnen, bei dem der Kreis in 8 Segmente aufgeteilt wird, die durch horizontale und vertikale und 2 45grad Linien begrenzt werden, und in denen die gleichen -1/+1 und 1 bzw 0 oder 1 Kriterien wie oben gelten. Was modifiziert wird ist wie die 0 oder 1 Auswahl funktioniert, welche von immer 0 zu immer 1 bzw immer 1 zu immer 0 übergehen muss, um den Bogen zu erzeugen.
Es entstehen dabei nur Linien. Gefüllte Flächen müssen daher ausschraffiert werden, zumeist mit 0/45/90/135grad Linien, um schneller hin und her zu fahren. "Helligkeit" kann man dabei nur mit dem Schraffurabstand beeinflussen. Diese Linien müssen einzeln einzeln vom Rechner aus bestellt werden, mitsammt ihren Koordinaten erzeugen.
Stiftplotter können sehr einfach mehrere Kurven auch mit mehreren Farben zeichnen, indem sie Stifte auswechseln gehen. Bei allen anderen Druckern ist dafür ein mehrfarbiges Druckband nötig (oder mehrere verschiedenfarbige Druckbänder), mitsammt einer Umschaltvorrichtung, und mehrmals die Zeile drucken, einmal pro Band. Beim Plotter ist dies weit einfacher. Die Stifte können entweder in einer Leiste entlang dem Rand abgelagert werden (nur bei Flachbett möglich), oder in einer Revolvertrommel (bei Rollen als einziges möglich). Der Wechsel besteht daraus, in die Position zu fahren, und dann mit dem Stift nach unten in die Halterung (und Kappe) fahren, und dann "unten" wegzufahren, braucht also keine weitere Elektronik (ausser beim Revolver einen Motor um diesen zu drehen).
Zumeist wird all dieses vom Controller des Plotters gemacht. Der Rechner selber muss nur X/Y Koordinaten liefern, und die Angabe ob dies eine Bewegung mit Stift unten oder oben ist. Dazu kommen Stiftwechselkommandos. Zumeist wird dies alles in Form von ASCII Kommandobuchstaben und Zahlen gesteuert, die wiederum mit einer normalen seriellen oder parallelen Schnittstelle verschickt werden. Bekannt und oft benutzt ist der HPGL Kommandosatz, vom HP 7470A Rollenplotter her.
Ziffern und Schrift (und auch beliebige andere Symbole wie Kreuzchen und Sterne auf Graphen) können aus Liniensegmenten gezeichnet werden. Hier muss zumeist der Rechner diese als einzelne Linien errechnen und schicken, ausser der Controller hat einen Font eingebaut. Dazu sind die Zeichen zumeist als Serien von relativen Koordinaten zum aktuellen Ort beschrieben, teils mit Stift oben oder unten, die der Rechner zum aktuellen Zeichenort addiert, ausser der Plotter kennt Kommandos für Relativbewegungen.
Dabei wird zumeist als Anfang eines Zeichens ein Punkt unten/links angenommen, und das Ende einer Serie derart gelegt, dass es unten/rechts landet, damit die weitere Serie des nächsten Zeichens ohne zuerst zu verschieben automatisch danach auf einer Zeile ausgegeben wird. Ausnahme sind für Graphenzeichen, die Anfang und Ende in der Mitte des Zeichens legen, damit man nach an einem Graphenpunkt ankommen ein Zeichen setzen kann, und dann gleich zum nächsten Punkt weiter fahren. All dies ist ist weit langsamer als jeder langsamste Drucker, aber immer noch schneller als als gar keine Graphikausgabe und Graphen von Hand zeichnen.
Nebenbei: Die Stiftplotter bildeten, von 2D auf 3D erweitert, und massiv stabiler gebaut, auch die Basis der ganzen CNC Maschinen ihrer X/Y/Z Robotter. Dabei wird oft eine Richtung der X oder Y das Flachbett auf Rollen bewegt, und in Z und dem verbleibenden eine Kombination, zumeist als erstes Z, und dann dessen Träger horizontal in die andere. Wieder alles mit Schrittmotoren, nur viel stärkere, passend zur robusteren Mechanik, die eben Metall mit einem Bohrer/Fräser/etc bearbeiten muss statt nur Papier mit einem Stift beschrieben. Angesteuert wird der Controller wieder mit ASCII Kommandobuchstaben, die von 2D Plotter Codes erweitert wurden auf 3D, und statt Stiftwechsel Werkzeugwechsel kennen. Bekannt und oft benutzt ist der G-Code, der bereits ohne Rechner mit reiner Lochstreifensteuerung benutzt wurde.
Beim Nadeldrucker werden nur noch sehr leichte "Nadeln" bewegt. Strikte sind diese ein vertikaler Stapel von Plättchen, die am vorderen Ende zu einer abgerundeten Spitze als Stempel auslaufen, welche gleich breit ist wie die Plättchen dick sind. Hinter jedem Plättchen steht ein Elektromagnet, abwechselnd links und rechts angreifend. Damit kann eine Spalte von Punkten gedruckt werden. Danach wird der Druckkopf nur um Spaltenbreite verschoben und wieder gedruckt. Erst nach mehreren Spalten ist eine ganze Zeichenposition gedruckt. Trotz dieser mehrfachen Druckerei sind sie schneller, weil sie keine Finger oder Typenrad Drehzeit abwarten müssen. Normal waren 80 bis 160 Zeichen pro Sekunde, das mehrfache der 30 vom Typenrad, aber unter den 300 der Trommel oder Band/Kette. Wieder werden die Elektromagnete mit normalen Ports oder PIO Pins angesteuert.
Wegen vertikalen Mittellinien will man eine ungerade Anzahl Punktespalten, wegen dünnen Linien mindestens 5, dazu ein Zeichenbstand. Das gibt bei 12 Zeichen/Zoll * (5+1) Punktespalten/Zeichen die 72dpi Auflösung. Zeichen sollen höher als breit sein, und wegen horizontalen Mittellinen auch eine ungerade Anzahl Punktezeilen haben. Daher hat der standard Nadeldrucker 7 Nadeln, wegen quadratischen Punkten ebenfalls mit 72dpi Abstand. Das ergibt bei 6 Zeilen/Zoll dann 12 Punktezeilen/Zeichen (7 genutzt und 5 Durchschuss). Das führte zum normalen 5x7 Font. Wegen den vielen kleinen Spaltenschritten werden zumeist Schrittmotoren wie bei den Stiftplottern verwendet, zumeist mit 144dpi (=0.176mm) Schritten, und wieder mit normalen Ports oder PIO Pins angesteuert.
Dieser Standarddrucker kann aber keine Unterlängen haben, was zu den hässlichen "hochgestellten" Zeichen für g j p q y _ , ; führt. Dies kann man sukzessive verbessern mit einer Erweiterung auf billigstes 8 oder zumeist 9 oder selten aufwendige 10 Nadeln. Selbst mit nur 7 Nadeln kann man wahlweise einen 5x6 Font nehmen, und damit minimale Unterlängen haben.
Bedingt durch die Nadeln als Spitzen der Plättchen können sich deren Punkte vertikal nicht überschneiden, was die klassische Punkterasterschrift ergibt. Um diese zu verbessern kann man horizontal einfach in 144dpi Schritten vorgehen, um überlappende Punkte zu bekommen. Dies kostet fast gar nichts, und wurde daher ziemlich verbreitet, fast universell bei Thermo und Tintenstrahl Druckern wo es gar nichts mehr kostet (siehe jeden beliebigen Kassenzettel oder Verpackungsaufdruck). Vertikal kann man dagegen nur nach einem Zeilendurchlauf um 144dpi vorschieben und dann einen zweiten Satz von Punkten drucken, und dann erst die restlichen (6*72-144)dpi vorschieben. Dazu muss man erst noch beide Durchläufe in der selbigen Richtung machen, und Versatz durch mechanische Toleranzen zu vermeiden, es dauert also 3 mal so lange. Also wird die nur explizit für gutes Schriftbild gemacht, wo die Zeitkosten akzeptabel sind.
Um zu verhindern, dass obiger Druckvorgang so lange dauert wurden 24 Nadel Drucker gemacht, die 2 Sätze von 12 Nadeln haben, um 1*144dpi vertikal und 6*72dpi horizontal zu einander versetzt. Damit wird jedes Zeichen zuerst mit den ersten 12 Nadeln (rechts) gedruckt, und parallel zum nächsten Zeichen seinen ersten 12 Nadeln mit den zweiten 12 Nadeln (links) das erste Zeichen vervollständigt. Es werden also pro Zeile 1*1 + 79*2 + 1*1 Halbzeichen gedruckt. Damit werden obige Zeitkosten durch Hardwareaufwandkosten ersetzt.
Ultimativ schnell aber auch recht teuer sind Kammdrucker. Diese sind die Kombination von Nadeldrucker und Zeilendrucker. Hierbei wird für jede Zeichenposition eine Nadel und Elektromagnet vorgesehen, zusammen eben der Kamm, was diese zu 80-Nadel Druckern macht. Gedruckt werden dabei alle Zeichen gleichzeitig, aber nur je einen Punkt, alle deren Punkte hintereinander, von oben/links nach rechts 5 Punkte, dann Vorschub um 72dpi, dies 7..10 mal, gefolgt von 5..2 reinen 72dpi Vorschüben. Insgesammt werden damit 80*((7..10)*5) Punkte gedruckt und 12*72dpi Vorschub gemacht, in nur 7..10 Zeichen an Nadeldrucker Druckzeit, was etwa 10 mal schneller wird, also etwa 800 Zeichen pro Sekunde, das mehrfache selbst von den Trommel- und Band/Kettendruckern.
Wenn es anderseits langsam sein darf, aber billig sein soll, gibt es den Hammerdrucker. Dieser kann mit nur einem Hammer statt mehreren Nadeln arbeitet (und ebenso mit nur einem Elektromagneten). Dieser Hammer hat die Form eines "\" mit 72dpi Punkt Breite, und 7*72dpi Höhe und ist oben um 6/7 von 72dpi nach links versetzt. Dieser wird zusammen mit einer "Sprossenwalze" eingesetzt, die die Form eines papierbreiten Zahnrades hat, mit der Aussenseite der Zähne 72dpi breit und die Zähne in 7 mal 72dpi im Abstand. Ein Zeichen wird links/unten mit dem ersten Punkt angefangen. Dann wird mit jedem Schritt die Walze um 72dpi nach oben verschoben und der Kopf/Hammer um 1/7 von 72dpi nach rechts, damit die Punkte vertikal bleiben. Nach dem siebenten Punkt links/oben kommt der achte Punkt wieder unten, weil die Walze einen Zahn weiter ist, und mit dem Hammer wieder unten benutzend um 7/7 mal 72dpi nach rechts. Nach 6*7 Punkten (davon 5x7 Font) ist eine ganze Position fertig. Dies reichte trotzdem für 35 Zeichen pro Sekunde, etwa dem Typenrad. Es reichte nicht für Unterlängen, weil diese mehr Zeit bei allen Zeichen addiert hätten.
Der Font selber (und damit auch der Zeichensatz) ist bei allen 3 Varianten nicht mehr durch die Hardware des Druckkopfes/Typenrades/Trommel/Kette gegeben, sondern wie beim Stiftplotter durch das Timing/Muster der Nadeln/Kamm/Hammer Bewegungen. Es muss als Bitmuster im Controller des Druckers vorliegen. Der normale 5x7 Font braucht bei 95 Zeichen (ASCII 32..126) 95*5*7 = 3360 Bits, bzw 95*5 = 475 Bytes mit je 7 Bits genutzt.
Neben Schrift kann ein Nadeldrucker aber auch beliebige Graphiken ausdrucken. Horizontal ist das kein Problem, man muss einfach Gruppen von 7..10 Punkte schicken, eine für jede Spalte, 6 für jede Position. Offen bleibt nur zwischen Schrift und Graphik hin und her zu schalten, und ob man bei Graphiken eine n*6 Punkte Breite erzwingt, und sei das nur mit Leerspalten anhängen. Vertikal wird zum Problem, weil in einer Zeile 12 Nadeln Platz sind, aber nur 7..10 im Kopf. Dies wird mit 2 Durchgänge mit nur 6 Nadeln nutzen gemacht, mit halbierten Zeilenvorschüben dazwischen. Hier muss wieder um Versatz zu meiden immer von der gleichen Seite her gedruckt werden. (Graphik kann auch horizontal 144dpi mit mehr Spalten oder vertikal mit 2*2 6-Punkte Durchgänge gemacht werden.24 Nadel Drucker erwarten auch bei 144dpi einfach 24 Punkte und geben in einem Durchgang alles aus, zuerst 12, mit den anderen 12 um 12 Spalten verzögert.)
Weil zumeist nur 6 Nadeln benutzt werden, müssen pro Spalte 6 Punkte geschickt werden, die Sixel (von Six Pixel) genannt werden. Diese Punkte werden als Bitmuster aufaddiert, mit aus/ruhen = 0, ein/feuern = 1, zumeist mit Bit0 = 1 oben und Bit5 = 32 unten, was den Wertebereich 0..63 ergibt. Um Probleme mit auf ASCII benutzen ausgelegten Speichern, Disks, Kommunikationsleitungen, Betriebssystemen, Programmiersprachen, Libraries, etc auszuweichen, werden diese Werte in den ASCII 32..126 Bereich "verschoben", entweder mit +32 zu 32..95 (bei dem erst noch alle 6 Punkte aus = 000000 zu 32 = Space wird) oder mit +33 zu 33..96 (um Space zu vermeiden weil manche Systeme damit speziell umgehen) oder mit +63 zu 63..126 (um viele Buchstaben auszunutzen, und ausserdem die Zeichen 0..9 für Punktemuster n mal wiederholen frei zu haben, wie es beim DEC Sixel der Fall ist). (24 Nadel Drucker erwarten einfach 4 Sixel pro Spalte, und erachten diese als rechts+links 2*6+2*6 oder vermischt 4*3 Punkte.)
Die meisten Nadeldrucker mit Graphikfähigkeit sind umschaltbar zwischen Zeichenmodus und Bitmapmodus, zumeist mit Escapesequenzen, die auch gleich die Graphikauflösung vorgeben (und auch andere davon die Fontauflösung). Auch der LF wird dabei tellweise je nach Mode automatisch in verschiedene Mengen an Vorschub umgewandelt. (24 Nadel Drucker ihr LF kann dagegen stets eine volle Zeile sein.)
Teils kann man Text und Graphik in einer Ziele mischen, was sehr nützlich ist um nicht-ASCII Spezialzeichen oder Symbole auszugeben.
Teils hat es zur Vermeidung der dauernden aufwendigen Umschalterei auch die Möglichkeit, einmal mit Sixel weitere Zeichen in den Drucker zu laden, um dessen Font mit einem RAM basierten Font zu erweitern oder ersetzen, wozu weitere Fontmode Escapesequenzen benutzt werden.
Der Druckkopf ist wie beim Nadeldrucker eine Spalte an Punkte (zumeist nur 7), aber diese sind hier kleine Heizelemente. Diese erhitzen die Beschichtung, die dabei chemisch zerfällt und Kohlenstoff freisetzt, welcher zur "Druckfarbe" wird. Daher wird Thermopapier auch schnell vergilbt wenn es an der Sonne liegt. (Ebenso sieht man den Effekt wenn Thermopapier über eine Kerze gehalten wird, zuerst anbräunen, dann die Farbe wegverdampfen und wieder blank werden, lange bevor das Papier selber verbrennt und dabei schwarz wird oder sich auflöst.)
Auch Thermodruck kann mit Zeilendruck kombiniert werden. Dabei hat es für jede Spalte ein Heizelement. Dieser Drucker hat ausser der Walze keinerlei beweglichen Teile. Er kann in nur 7..10 Zeilen Heizschritten (und 12 Zeilen Vorschubschritten) eine ganze Schriftzeile drucken. Wegen der vielen Elemente werden diese zumeist nicht mit so vielen Port oder PIO Pins angesteuert. Vielmehr werden sie als Kreuzungspunte einer Matrix von Leitungen verdrahtet. Ein 20 Zeichenpositionen (bzw 20*6 = 120 Punktespalten) Drucker wird zumeist etwas wie eine 10x12 Matrix haben, bei der eine Punktezeile in 10 Gruppen von 12 Spalten gedruckt wird, also 2 Zeichen aufs mal. Bei einem 8bit Rechner wären die 12 Spalten (und die 10 Gruppen) 2*6 (und 2*5) an Ports, also je 2 Schreibzyklen. Eine Punktezeile ist damit 2 mal Gruppe und 2 mal Spalten, warten, Spalten aus, das 10 mal wiederholt, dann Vorschub, all das für eine Schiftzeile 7..10 mal wiederholen, dann die verbleibenden 5..2 Vorschub.
Thermodrucker sind auf billig ausgelegt, und haben daher zumeist keinen Controller oder eingebauten Font. Daher müssen alle Heizelement (bzw Matrix) und Schrittmotor Signale und ihren Timings per Ports oder PIOs mit Software erzeugt werden. Dabei muss verhindert werden, dass Elemente zu lange eingeschaltet bleiben, weil sie sonst sich selber verheizen. Die Software muss logischerwiese auch den Font beinhalten.
Photokopierer sind noch extremer als Zeilendrucker, weil sie die ganze Seite aufs mal drucken. Dabei wird das zu kopierende Papier auf einem durchsichtigen Flachbett an einer starken zeilenbreiten Lichtquelle vorbeigezogen. Das reflektierte Licht trift eine elektrostatich aufgeladene rotierende mit Selen beschichtete Trommel und "löscht" die Ladung dort wo das Original hell und reflektierend war. Die Restladung wird auf das Kopie-Papier übertragen, welches dann am ebenfalls elektrostatisch aufgeladenen Toner (Farbstaub) Behälter vorbeigezogen wird, von dem es nur dort Toner annimmt wo Ladungen auf dem Papier verbleiben sind, also das Original dunkel war. Dann werden Kopie-Papier und Toner durch eine Druck+Heiz Rolle geführt, dem Fixierer, wo der Toner geschmolzen wird und ins Papier eindringt bzw daran festklebt. Daher kommt Papier auch warm aus Photokopierern oder Laserdruckern heraus.
Für den Rechnergebrauch wird die Lichtquelle/Papier/Flachbett Einheit ersetzt durch eine rechnergesteuerte Beleuchtereinheit, in der die Daten in hell/dunkel Muster gewandelt werden. Dabei gab es 3 Verfahren, von denen heute nur noch eines relevant ist. Alle verwenden analog zum Kammdrucker bzw noch analoger zum Zeilenthermodrucker eine "Punktezeile aufs mal" Ausgabe. Die horizontale Auflösung ergibt sich aus der Belichtungseinheit ihrer Punktefrequenz, die vertikale aus dem Selentrommel (und Papier) ihrem Vorschub pro Belichtungszeile:
Bei allen wird wegen der schnellen Signale kein PIO mehr ausreichen, und daher ein spezieller Controller vorhanden sein. Dies auch weil der ganze Papierdurchlauf nur ungenau gestartet und gestoppt werden kann. Daher sind diese Drucker alle Seitendrucker. Daher muss auch das ganze Bild vor loslaufen der Mechanik in Punkte umgewandelt (rendern genannt) worden sein, weshalb diese Controller entweder viel Speicher beinhalten müssen, oder aber das Bild von Rechner in dessen Speicher gerendert werden muss, und dann nur als Bitmap zum Drucker gehen. Bei 300dpi und 8x12" sind dies immerhin 8*300*12*300 = 8'640'000 Punkte = 1'080'000Bytes, leicht mehr als 1MByte (1'048'576)!
Im minimalen Fall wird der Drucker mit direkten nicht-ASCII/nicht-Sixel 8bit Punktemustern beschrieben (GDI/Windows Drucker) und der Rechner muss das ganze Bild zuerst als Punkte in seinem Speicher aufbauen, wozu die selbige GDI Renderengine (und dessen Fonts) benutzt werden kann wie für die ohnehin vorhandene Bildschirmausgabe, was auch bestes WYSIWYG ergibt. Im maximalen Fall wird mit PostSript Kommandos gearbeitet, und alles im Controller gerendert (oder im Rechner, und dort idealerweise auch benutzt als DisplayPostscript). Dazwischen liegen normale ASCII+Escapsequqnzen Systeme analog zu bei Nadeldruckern (PCL Drucker), oder einem anderen Code wie EBCDIC (Grossrechner Drucker).
Wegen der hohen Auflösung kann dieser Controller (oder der Rechner je nach wer rendert) sehr detailierte Fonts benutzen, und damit auch mehrere Fonts anbieten, mitsammt Umschalterei. Diese können in mehreren Auflösungen gezeichnet/vorgegeben werden, oder automatisch skaliert werden.
Beides befördert per Druckstoss einen Teil des Kammerinhaltes als Tintentropfen aus der Düse hinaus aufs Papier. Nach loslassen des Piezo oder abkühlen des Heitzelementes wird von hinten her aus einem Tintenfass weitere Tinte nachgezogen. Die Elemente ansteuern ist identisch wie bei einem Nadeldrucker oder Thermodrucker, per Port oder PIO.
Diese waren anfangs wie Nadeldrucker und Thermodrucker nur 72dpi, mit nur einer Farbe. Beide Verfahren sind aber ideal geeignet um mit immer feineren Strukturen des Druckkopfes auf immer mehr vertikale Aufläsung gesteigert zu werden. Ebenso kann Nachladen dabei recht einfach beschleunigt werden, und damit wird mehr horizontale Auflösung machbar ohne Verlangsamung. Damit haben sie laserartige Auflösung erreicht. Das geht bis zu photographischer Auflösung (erst recht in Kombination mit speziellen Photopapier welches im Laser nicht möglich ist).
Auch sind bei beiden die Druckköpfe schmal, und arbeiten ohne Farbbänder, womit mehrere Köpfe neben einander mit mehreren Farben möglich ist, und damit einfacher CYMK 4-Farbendruck. Dies ist weit einfacher als beim Laserdrucker, der dazu 4 Selenwalzen und Toner braucht. Daher dominieren Tintenstrahldrucker heute im Billigmarkt und im Farbmarkt.
Weit besser zur elektronischen Natur eines Rechners passt die Ausgabe von Daten auf Lampen, die lediglich per Ports oder PIOs festgehaltene Bits und dahinter Transistoren als Verstärker zu ihrer Ansteuerung brauchen, ohne jegliche aufwendige Controller. Sie können auch beliebig schnell vorzu ein und aus geschaltet werden. Schlimmstenfalls entsteht bei zu schnell blinken einfach ein Durchschnittswert an Helligkeit.
Das Problem hier ist die Menge an Lampen sowie deren Grösse, also die niedrige Auflösung der Anzeige und damit die geringe Menge an darstellbaren Daten, deren Steigerung beides in schnell massiv steigende Kosten ausarten. Immerhin entspricht eine einzelne 80 Zeichen Druckerzeile auf einem 5x7 Drucker 80*(5x7) = 2800 Punkten. Daher sind Lampen nur für geringe Datenmengen geeignet.
Binärzahlen haben schnell viele Stellen und werden damit bald unübersichtlich. Diese kann man aber lesbarer machen, indem man sie gruppiert. Dies wird zumeist in 3bit oder 4bit Gruppen angeordnet. Hierzu gibt es einige visuelle Varianten:
Diese kann man auch vom Rechner selber umrechnen lassen, wozu man die Daten von Binär in Dezimal umwandeln lässt. Hierbei werden die entstehenden Dezimalziffern bearbeitet als je eine 4bit Binärzahl mit nur dem Bereich 0..9 davon genutzt, was als Binär Codiertes Dezimal (BCD) bekannt ist. (Zumeist werden dann 2 4bit BCD Ziffern in ein 8bit Byte abgelegt, was als gepacktes BCD bekannt ist.)
Danach können die entstandenen BCD Ziffern bereits mit jeder beliebigen Form obiger 4-er Gruppierungen dargestellt werden, und mit einer recht einfachen Logik gelesen werden: Falls Bit3 = 1 ist, ist es 8 oder 9, je nach ob Bit0 eine 0 oder 1 addiert. Ansonsten falls Bit2 = 0 ist, ist es geradeaus 0123, je nach ob keine=0/Bit0=1/Bit1=2/beide=3 1 sind, sonst mit Bit2 = 1 ist es dazwischen die 4567, je nach Bit0 und Bit1, einfach obiges mit 4 addiert.
Um Zahlen grösser 9 (und damit in BCD mehrziffrig) auszugeben muss man aber zuerst Binär in BCD umwandeln/zerlegen (= in Ziffern aufspalten). Dazu muss eine Modulodivision durch 10 gemacht werden, wobei der Rest eine 0..9 Ziffer ergibt (die hinterste Ziffer), und der Quotient (falls er nicht 0 wird) rekursiv wiederholt modulodividiert wird um weitere Ziffern als Rest(e) zu generieren (bis der Quotient zu 0 wird). Dabei fallen die Ziffern in der Reihenfolge von hinten/rechts/Einer nach vorne/links an, also gespiegelt, und müssen in dieser Reihenfolge in die Ausgabe positioniert werden. Daher werden Anzeigen teils derart gebaut, dass deren erste Adresse die Elemente rechts sind, letzte Adresse links. Oder man zählt die Position einfach rückwärts.
Nebenbei: Daher muss man Zahlen, um sie auf einen Drucker ausgeben, welcher normalerweise links nach rechts druckt (und damit spiegelverkehrt), in einen Zwischenspeicher/Buffer schreiben, diesen dann möglicherweise mit Leerzeichen auffüllen (falls rechtsbündige Zahlenkollonnen erwünscht sind), und dann in umgekehrter Reihenfolge (= entspiegelt) ausgeben (wobei obige Leerzeichen dann zuerst kommen).
Falls man vorzeichenbehaftete Zahlen hat, funktioniert obiges nicht bei den negativen Werten. Daher muss man für diese zuerst auf negativ testen, und falls dem so ist den Minus Indikator setzen und dann die Zahl (ent-)negieren. Danach wird wie eine positive Zahl normal gewandelt. (Für obige Druckerausgabe wird statt einem Indikator ein Flag gesetzt, und nach der Wandlung getestet falls gesetzt dann das Minus in den Buffer addiert (nach/links von den Ziffern), dann allfällig die Leerzeichen aufgefüllt, und dann wie gehabt umgekehrt ausgegeben.)
Weil diese Umwandlung ziemlich viel an Aufwand ist, haben manche Rechner Spezialbefehle um dies schneller und einfacher zu machen, z.B. die IBM 360er ihr CVD Befehl (und CVB für BCD nach Binär).
Nebenbei: Dies kann man auch mit beliebigen anderen Zahlenbasen machen, z.B. für 12er einfach Modulo 12 nehmen. Wenn man dies mit 8 oder 16 macht, degeneriert die Modulodivision zu Shift-rechts um 3 oder 4bit. Man kann dies auch variabel machen, z.B. um Sekunden in Stunde:Minute:Sekunden umzuwandeln oder auszugeben, einmal Mod 10, dann Mod 6, dann : addieren, Mod 10, Mod 6, :, Rest Mod 10. Ebenso kann man genereller Festkommazahlen ausgeben indem man Kommastellen mal Mod 10 macht, dann . addiert, dann Rest Mod 10 (z.B. Buchhaltungsrechnungen mit alles in Cent gerechnet und 2 Stellen vor dem . ausgeben, oder elektrische Rechnungen alles in mV und uA gerechnet und 3 Stellen vor dem . ausgeben und V bzw mA anschreiben).
Ein anderer Ansatz ist sich die Umwandlungen ganz zu sparen, und alle Daten intern in BCD zu halten, und auch direkt in BCD zu rechnen, weil dies bei viel Ein-/Ausgabe und wenigen Rechnungen weniger Rechenmehrzeit braucht als die Umwandlungszeit. Der Aufwand ist nur nach jeder Addition oder Subtraktion jede einzelne Ziffer (= 4bit Gruppe) auf ungültige Werte 10..15 zu testen, und falls in diesem Bereich gelandet wurde weitere 6 zu addieren bzw subtrahieren. Dieser Aufwand tritt aber bei jeder Rechnung wiederholt auf, was dann zum Kriterium wird, weil bei vielen Rechnungen die einmalige Umwandlung doch weniger Zeit kostet. Daher ist direkt BCD im kommerziellen Rechnen verbreitet und Binär wandeln im technisch-/wissenschafltichen.
Um auch diese direkte BCD Rechung weniger aufwendig zu machen, haben manche Rechner Spezialbefehle um diese Tests und Korrekturen schneller und einfacher zu machen. Dies ist bei der 4004 (die für einen Tischrechner designt wurde) der Fall und die 8080 ihre DAA (Decimal Adjust Accumulator), sowie die 8086/8088 ihre DAA/DAS (Decimal Adjust Addition/Subtraction) Befehle, ebenso einige Taschenrechner Prozessoren (vor allem von TI). Eine Alternative ist dem 6502 sein Dezimalmodus (der per SED/CLD Befehle ein/aus geschaltet wird, und direkt dezimal rechnet ohne separate Korrektur danach), ebenso weitere Taschenrechner Prozessoren (vor allem von HP). Eine weitere ist die 68000 ihre separaten ADDD/SUBD Dezimalrechenbefehle (die ohne Modus schalten direkt Dezimal rechnen). Noch mehr geben die ganzen IBM 360er ihre Dezimalrechenbefehle (welche mit fast beliebig langen Dezimalzahlen im Speicher rechnen). Extremfall waren wohl die IBM 1401 und 1620 Rechner (von 1959), die nur in BCD rechnen konnten, selbst mit Dezimalzahlen als Speicheradressen (und dies stets mit fast beliebig langen Dezimalzahlen im Speicher, diese hatten auch gar keinen Akkumulator oder Register, Adressen waren genormt als 3 bzw 5-stellig). (Digitaluhren arbeiten ebenfalls mit BCD und je nach Stelle 10 bzw 6 gültigen Werten, bzw zweitvorderst 10 oder 2 bzw 4 je nach ob vorne 0 oder 1 bzw 2 ist.)
Nebenbei: Diese Binär zu BCD Wandlung muss man auch machen, um Zahlen in Dezimal auf einen Drucker auszugeben. Dort muss man danach zusätzlich noch das BCD in ASCII oder EBCDIC oder anderen Zeichensatz umwandeln, wozu man die 4bit Gruppen zu 6bit/7bit/8bit erweitern muss. Dazu muss man sie auch von 1 2*4bit in 8bit zu 2 8bit entpacken und den Code der Ziffer 0 addieren (in ASCII Code 48 oder EBCDIC Code 240).
Nebenbei: Auch hier hat der 360er einen UNPACK Spezialbefehl (und PACK für von Zeichen nach BCD), welcher 1 2*4bit zu 2 8bit entpackt, der auch im 68000 Mikroprozessor kopiert wurde. Beim 360er wird danach ein ASCII/EBCDIC Modusflag benutzt, beim 68000er (erst ab 68020 vorhanden) muss eine Konstante Hex 3030 oder Hex F0F0 im Befehl mitgegeben werden. Andere Prozessoren verwenden langsamer die bereits vorhandenen AND mit Konstante 15 (= nur unterste 4bit bleiben erhalten), kombiniert mit 4 mal Shift rechts (= Division durch 16), was wiederum manche Prozessoren mit einem SWAPD oder ROTD Befehl etwas beschleunigen, welcher die oberen und unteren 4bit in einem Schritt austauscht. (Eines der 8080 zu Z80 Erweiterungen sind RRD und RLD Befehle welche 4bit im Akkumulator und 2*4bit in einem Speicherbyte um 4bit rotieren, nach rechts oder links.)
Eine Form ist die Abakus Balkendarstellung, welche 9 vertikal stehende Lampen pro Dezimalstelle braucht, von oben mit 9..1 beschriftet, und davon je nach Daten 0..9 einschaltet. Das ist analog zu einer Audio Lautstärkeanzeuge. Technisch kann man dies als 4bit Port/PIO mit danach einen 4:9 Decoder machen, oder in Software mit einer 10*9bit Tabelle und 9bit Port/PIO mit direkt Lampen dahinter. Egal wie, muss der Decoder oder die Tabelle die Logik beinhalten, damit jede Lampe n bei ihrer Kombination von n..9 aufleuchtet und bei 0..n-1 dunkel bleibt, letztlich eine Serie von NOT-AND-OR Formeln.
Während Werte nahe 0 oder 9 relativ leicht ablesbar sind, sind Werte in der Mitte nur mühsam abzählbar. Wie beim echten Abakus kann man das Lesen vereinfachen, mit horizontalen Streifen von verschiedenen Helligkeiten oder Farben der Lampen, oder zwischen ihnen horizontale Balken und/oder Linien addieren (oder gar diese mit Ziffern anschreiben). Das kann in einer 4+1+4 Anordnung geschehen (wie beim traditionellen Abakus) oder 3+3+3 (so wie man es lesen tut). Dies kann man dann schneller als 1/2/3, bzw (5-1=)4/5/(5+1=)6, bzw 7/8/9 lesen.
Man kann auch die "lange"/"hohe" 9 Lampen Form kompaktieren, mit einer teilhorizontalen Anordnung, zickzack in 2 Spalten zu 5+4, links 9/7/5/3/1 und rechts, 8/6/4/2 womit auch schnell ungerade/gerade sichbar wird. Oder sogar in 3 Spalten zu je 3, womit man links 9/6/3 mitte 8/5/2 und rechts 7/4/1 zu sehen bekommt, womit auch oben 9/8/7 mitte 6/5/4 und unten 3/2/1 automatisch sichtbar wird.
Eine andere Form ist die Unärdarstellung, welche 10 vertikal stehende Lampen pro Dezimalstelle braucht, von oben mit 9..0 beschriftet, und davon je nach Daten eine andere einzelne einschaltet, was analog zu Zahlen an den Fingern abzählen ist. Technisch kann wieder mit 4bit Port/PIO und einem 4:10 Decoder (z.B. 7442 Chip) oder einer 10*10bit Tabelle und 10bit Port/PIO gearbeitet werden. Die Logik ist bei beiden gleich, und bei beiden anderst als beim Abakus, da jede Lampe nur genau bei ihrem Wert aufleuchten darf, hier nur eine NOT-AND Formel ohne -OR.
Auch hier kann man mit Helligkeiten oder Farben der Lampen oder dazwischen die Lesbarkeit verbessern. Wobei obige 4+1+4 oder 3+3+3 dann zu 4+2+4 bzw 3+4+3 werden. Auch Linien mit Ziffern anschreiben wirkt hier.
Nebenbei: Strikte waren Lochkarten schon in der vor-Rechner Zeit in Unärdarstellung codierte und in Stanzlöchern speichernde Datenträger, welche man im Gegensatz zu den binär in ACSII codierten Lochstreifen auch manuell recht einfach als Anzeige auslesen konnte. Dies erst recht wenn die Karten mit horizontalen Linien für 0..9 bedruckt waren, oder gar bei Spezialkarten vertikal mit Feldnamen. (Diese wurden dann für Text speichern mit 3 weiteren Zeilen 10..12 erweitert, welche dann binäre 0..7 Werte beinhalteten, und damit 8*10 = 80 Codes erlaubten, wobei 0 = Ziffern sind (kompatibel), 1/2/4 Buchstaben sind (wieder alle unär), und 3/5/6/7 anderes.) (Natürlich verbraucht dies wie bei Druckausgabe Material, und erst noch einiges mehr davon, eine Karte pro Zeile.) (Bei der Lochkarte musste man zumeist ohne Encoder deren 10+3 = 13 Stanzbits ausgeben.)
Auch hier kann man eine teilhorizontale 5+5 Anordung verwenden, mit den 10 Lampen im Zickzack angeordnet, diesmal links 97531 und rechts 86420, nur die Ziffer 0 unten-rechts addiert.
Eine verbesserte Form von obigem besteht aus einem 2x5 Feld von Lampen, mit je einer zifferförmigen Lochblende davor.
Komfortabler wird dies, wenn die Lampen/Blenden danach schräg auf eine davor liegende Fläche (rück-)projezieren, womit sich die Ziffern an einer Stelle überlagern statt verstreut sind.
Hierfür gab es aber auch spezielle Elektronenröhren, technisch eine Form von Glimmlampen, mit in Blick oben drauf 10 Leuchtpunkte, in 30grad Winkel angeordnet (10/12 eines Analoguhrzifferblattes, aber zumeist wie bei einem Tachometer angwordnet). Solche Winkel sind kompakter und einfacher zu erkennen als Spalten.
Die ultimative Form davon war dann die Nixieröhre, die technisch wiederum ein Glimmlampe ist, mit einem Stapel von 10 zifferförmigen Elektroden, welche mit der richtigen eingeschaltet die entsprechenden Ziffern anzeigen. Charakteristisch ist hier dass sich die Ziffern beim Umschalten wegen der Elektrodenstapelung vor-/rückwärts bewegen.
Nebenbei: Alle diese Anzeigen können auch als Subset nur die oktalen Ziffern 0..7 ausgeben, was auch der Grund ist, warum früher oktal so beliebt war. Dabei werden je 3bit für die 4:10 Decoder auf 4bit erweitert, mit stets einer 0 als Bit3 einfügen (nur die unbenutzten 8 und 9 haben ein Bit3=1). Dedizierte Oktalanzeigen liess man einfach die 8 und 9 Lampen ganz weg, reduzierten den Decoder auf 3:8, und liess die 3 zu 4bit Erweiterung fallen. Z.B. die Frontpannels der PDP-8/A oder der PDP-11/34.
Man kann aber auch direkt lesbare Ziffern haben, ohne diesen Aufwand. Die ganzen Segmentanzeigen basieren darauf, dass Segmente nebeneinander liegen, und nicht vertikal gestapelt sind, aber trotzdem Ziffern als Segmentmuster darstellen können, aus Kombinationen von Segmenten. Das ganze wurde anfangs mit normalen Lampen gemacht, aber sehr schnell auf LEDs gewechselt (weil diese kühler und zuverlässiger waren), oder teils auf Glimmröhren (und letztere auch als mehrere Positionen in einer horizontalen Röhre, als Vakuumfluoreszensanzeige (VFD)), sowie später die LCDs.
Am bekanntesten sind die 7-Segment Anzeigen, wie man sie von Taschenrechnern her kennt. Hier werden nur 7 Lampen benutzt. Die Segmente werden traditionell von oben/links im Uhrzeigersinn als a..f, sowie der Strich in der Mitte als g bezeichnet. Sie können wie bei obigen Anzeigen mit 4bit Port/PIO und einem 4:7 Decoder (z.B. 7447 oder 74247, je nach welcher Font bei 6 und 9 erwünscht ist) oder mit einer 10*7bit Tabelle und 7bit Port/PIO betrieben werden. Weil 7bit einiges weniger als 9bit oder 10bit ist, und insbesondere auf 8bit Rechnern weit besser passen, und anderseits ein Font erzeugt werden muss, ist die Tabellenform hier weitaus üblicher.
Bei Tabellenform und 7bit Port/PIO ist es Tradition, die Segmente a..g mit Bit0..6 zu verdrahten, womit folgende Tabelle für Ziffern 0..9 (und die Hexziffern A..F) entsteht:
Segname gfedcba Bitnummer 6543210 Dez Hex Okt
Ziffer 0 = Segmente -fedcba = Bitmuster 0111111 = Wert 63 3F 077
1 = ----cb- = 0000110 = 6 06 006
2 = g-ed-ba = 0100100 = 91 24 044
3 = g--dcba = 1001111 = 79 4F 117
4 = gf--cb- = 1100110 = 102 66 146
5 = gf-dc-a = 1101101 = 109 6D 155
6 = gfedc-a = 1111101 = 125 7D 175
7 = ----cba = 0000111 = 7 07 007
8 = gfedbca = 1111111 = 127 7F 177
9 = gf-dcba = 1101111 = 111 6F 157
Hexzif A = Segmente gfe-cba = Bitmuster 1110111 = Wert 119 77 167
b = gfedc-- = 1111100 = 124 7C 174
C = -fed--a = 0111001 = 57 39 071
d = g-edcb- = 1011110 = 94 5E 136
E = gfed--a = 1111001 = 121 79 171
F = gfe---a = 1110001 = 113 71 161
Die Dezimalpunktlampe, falls vorhanden, wird traditionell dp oder DP genannt und auf Bit7 vom Port/PIO gelegt, was dann mit Segmentwert+128 angesteuert wird. (Eher selten wird eine Dezimalpunkt zu Dezimalkomma Erweiterung angeboten, die dann an 8bit-unfreundlichem Bit8 hängt, womit Punkt = 128 und Komma = 128+256=348 wird.)
Mit 7-Segment Anzeigen kann man problemlos die 10 Ziffern anzeigen. Mit Tabelle und 7bit Speicher sind aber strikte 127 Muster (und "aus" als 128stes) möglich, und damit auch limitierte Graphiken. Das ist ein weiterer Grund gegen feste Decoder. Ebenso können feste Decoder zwar oktal 0..7 Ziffern darstellen, versagen aber zumeist bei hexadezimal 0..9A..F an den letzteren ihren 6 Buchstaben "Ziffern" (z.B. liefern die 7447 und 74247 bei 10..14 zufällige Segmente und 15 alles aus). (Daher kam Hex auch erst mit 7-Segment wirklich auf, zusammen mit 8bit Prozessoren und Tabellen, auch gerade weil deren 2*8 = 16bit Adressen mühsam als 2*3 Oktalziffern einzugeben waren, weil dies 2*9bit ergab, man daher 2+3+3 + 2+3+3 eingeben musste.)
Aber wenn man für beliebige Zeichen die ganzen 26 Buchstaben anzeigen will, wird es schnell schwierig. Bereits die 6 Buchstaben A..F um Hexadezimal darzustellen müssen als AbCdEF dargestellt werden. Für alle Buchstaben wird es noch schwieriger. Gross kann man A B C D E F G H I J K L M O P S U V Z haben (aber B D I O Z duplizieren die Ziffern 8 0 1 0 2, und K M V sind nicht intuitiv), klein kann man b c d f h i j l n o p q r t u y haben (aber f l p duplizierten F 1 P), beides unterscheidbar sind B b C c D d H h I i L l O o U u (empfohlen wird b d h i o u um 8 0 X 1 0 W auszuweichen. sowie L um 1 auszuweichen), komplett verwechselbar sind W und X (sehen aus wie H und U, daher muss man dort h und u benutzen). Daneben liegen auch andere Zeichen halbwegs gut darin + - / ^ = [ ] @, sowie recht problematisch % ! ? mit dem Dezimalpunkt zusammen. Ein * kann praktisch nur als "grossen Punkt" mit einem hochgestelltem kleinem o dargestellt werden.
Die Problemkinder sind alles mit Schräglinien (K M N Q R V W X Y Z * / < > %) oder Mittelsekrechten (B D I T + * { }). Die Antwort darauf sind 16-Segment Anzeigen, welche die Segmente a d g in je 2 Horizontalen unterbrechen, neben b c und e f eine weitere mittlere Senkrechte addieren, sowie vier von der Mitte ausgehende halbe Diagonalen, was dann wie eine hochkannt gestelle britische Flagge aussieht. Damit lassen sich alle 26 Grossbuchstaben problemlos darstellen, ebenso die meisten Kleinbuchstaben, wenn auch manche davon vergleichbar nicht intuitiv werden wie obige K M V. Solche Anzeigen waren nie Lampen, selten LED und zumeist VFD (wie z.B. im Mikroprofessor MPF1+ verwendet, aber auch vielen Autoradios) und selten LCD (wie z.B. im HP 41C Taschenrechner).
Nach einer Weile wurde festgestellt, dass die halbierten a und d Segmente nur selten benutzt werden (nur J und g f l t y werden leicht verbessert), während das halbierte g sich gut bewährt hat (nötig für B K und e g p q s), weshalb man den Aufwand zu 14-Segment Anzeigen reduzierte (was der HP 41C sein LCD eines ist). Zumeist wurde bei diesen, analog zum 7+1=8bit der 7-Segment eine 14+2=16bit Anordnung gemacht, mit DP und Komma. Teils aber auf 17bit erweiter um : und ; anzuzeigen, oder gar auf 18bit um davor ein ' anzuzeigen. Aber auch manche vollen 16-Segment haben diese Additionen, zumeist die vollen +4bit, auf 20bit hinauf.
Neben der traditionellen Drucker 5x7-Matrix ihrem Aufwand kann auch eine minimale 3x5-Matrix (=15bit) Version genutzt werden, für nur 3/7 des Aufwandes (und auch halbwegs zwischen 14-Segment und 16-Segment). Bei diesem liegt auch ein 3x5+1=16bit für einen DP nahe.
Dazwischen liegt noch eine 5x5-Matrix (=25bit) Variante. Diese kann/muss dann vertikal "gestreckt" werden, mit oben/mitte/unten 3 mal 1x5 Punkten und dazwischen 2 mal 1x5 doppelhohe "Punkte", diese idealerweise als vertikal/diagonal/vertikal/diagonal/vertikal Segmente, was quasi ein um 9 (Kreuzungs-)Punkte erweitertes 16-Segment ergibt, und die Vorteile der 16-Segment und der 5x7-Matrix fast optimal kombiniert, bei nur 5/7 des Aufwandes der letzteren.
Wie bei Segmenten wird hier erst recht mit Tabelle und Speicher danach gearbeitet, schon einmal um einen sehr grossen Decoder zu vermeiden. Das ergibt als Nebeneffekt eine geringe Graphikfähigkeit, die aber eher für beliebige Zeichen darstellen benutzt werden kann (bei 5x7 reicht es selbst für die japanischen Katakana Zeichen). Solche Anzeigen sind in Grossformat oft LEDs, aber im kleinen selten LEDs und fast immer LCDs.
Ein Weg dies auszuweichen, besteht darin, nur einen Decoder oder nur einen grossen Port/PIO Bitsatz zu nehmen, und diesen mit allen Anzeigepositionen zu verbinden. (Dies kann man strikte auch bei Binär oder BCD machen, ab dann wenn gruppiert wird, oder gar nur als extern unsichtbare interne Gruppierung, oder alle Bits einzeln.)
Um zu verhindern, dass alle Positionen das gleiche anzeigen wird nur eine aufs mal eingeschaltet, durch nur diese mit Strom versorgen (bzw auf 0V legen, die Segmente werden als Strom angeliefert). Dies ist als multiplexen bekannt. Nach einer kurzen Weile wird die Position aktuelle abgeschaltet, der Datenwert der nächsten in die Speicherbits geladen, und dann diese eingeschaltet. Dies wird für alle Positionen wiederholt, zyklisch, mindestens 30 mal pro Sekunde, besser 100 mal. Dies ist als scannen bekannt. (Dies alles ist analog zu der Seriellen Logik, wieder n Logiken/Leitungen + 1 Clock ersetzt durch 1 Logik/Leitung + n Clocks, also dass Logiken/Leitungen/Platz gegen Clocks/Zeit ausgetauscht werden.)
Dabei muss aber auch verhindert werden, dass Strom von einem aktivierten Segment via der Positionsleitung einer deaktivierten Position zu anderen Segmenten "überläuft" und diese auch schwach aufleuchten. Dies ist bei LEDs automatisch gegeben, weil diese Dioden sind. Bei anderen Lampen muss diesen je eine Diode in Serie geschaltet werden.
Um die aktuelle Anzeigeposition auszuwählen hat es einen weiteren Port/PIO. Dieser kann analog zu den Daten ihren 1 Bit pro Segment als 1 Bit pro Position gemacht werden. Oder er kann ein kleinerer sein (von 3 bis 5bit), mit einem n:2^n Decoder danach (für 3:8 oder 4:16 oder 5:32), welcher die Aktivierung von maximal 8 bzw 16 bzw 32 Positionen vornimmt.
In zweiterem Fall ist es vielleicht gar nicht möglich, keine Position aktiv zu haben. Hier gearbeitet man alternativ mit Daten=0 gefolgt von neuer Position schalten und dann neue Daten laden. Das wiederum versagt wenn die Daten per Decoder kommen, ausser dieser hat eine "alles aus" Kombination (wozu bei BCD eben traditionell die 15 missbraucht wurde, bei ASCII das Leerzeichen,Space,32).
Die optimierte Variante besteht darin, den Datenwert und die Aktivierung gleichzeitig umzuschalten, indem der Prozessor auf den selbigen Segmentmuster Port/PIO mit mehreren Adressen (8 bzw 16 bzw 32) zugreifen kann, und die ungenutzen Adressbits (3 bzw 4 bzw 5) welche diese Adressen unterscheiden in den zweiten kleinen Port mit dem Decoder abgelegt werden, und damit automatisch die Aktivierung umschalten während die Daten ändern.
Egal was oben gemacht wird, gibt es dabei sowohl die Aktivierung der Positionen mit Anordnung von 0=links (naheliegend von links nach rechts lesen her), wie auch von 0=rechts (besser für obige rechts/Einer zuerst Logik derModulodivision von Binär zu BCD Wandlung welche Ziffern von rechts her generiert). (Wie bei den Bits und Bytes von links oder rechts nummerieren ist hier nichts einheitlich, wobei in all diesen 3 Fällen "links"/"bigendian" eher Tradition/Kultur und "rechts"/"littleendian" eher Mathe/Formel denkende Personen anspricht.)
Der Nachteil dieser Ersparnis durch Multiplexen ist, dass der Prozessor wiederholt dabei arbeiten muss, neben seiner eigentlichen Arbeit. Oft besteht letztere aber zumeist aus auf Tasten warten, von kurzen Arbeitsphasen unterbrochen. In diesen Fällen kann er auch nur Anzeige machen, und wenn eine Taste erkannt wurde und abgearbeitet wird kurz die Anzeige ausfallen lassen, was als Nebeneffekt in Form einer flackernden Anzeige einen automatischen "ich bin beschäftigt" Hinweis ergibt (mitsammt Mass der Beschäftigungsmenge), wie man es gerade auch von Taschenrechnern her kennt, die es aus genau der Limite heraus machen.
Sind die Arbeitsphasen zu lange, kann auch zwischendurch ab und zu die Anzeige beschrieben werden. Teils wird dies auch mit einer reduzierten Anzeige gemacht, um die Arbeit nicht allzusehr auszubremsen. Teils wird dazu einfach eine Ziffer/Zeichen Position fest auf ein spezielles Muster gestellt. Dies alles kann man kombinieren, wie z.B. beim HP 41C, der während normalen Rechnungen nichts darstellt, aber während Programablauf (was lange dauern kann) eine "fliegende Gans" (Figur aus den Segmenten e f g), welche ganz links anfängt, und um Aktivität zu zeigen bei jedem Programmsprung um 1 nach rechts verschoben wird, zyklisch wieder von links anfangend.
Der weiterer Nachteil dieser Ersparnis ist, dass die Lampen nur einen Teil der Zeit Strom bekommen, und damit dunkler sind. Dies kann man aber, da sie nur einen Teil der Zeit Strom bekommen und davon erwärmt werden, mit einer grösseren Stromstärke kompensieren, ohne sie zu zerstören. Dabei muss man aber sicherstellen, dass die nicht dauereingeschaltet werden, weil sie sonst daran kaputtgehen (wie die Thermodrucker Heizelemente). Dies kann man auch in der Stromversorgung sicherstellen, indem diese nur einen Puls für jeden Schreibvorgang von sich gibt. Für Dauerdarstellung einer Position ohne schreiben muss die Stromversorgung nach dem Puls auf Normalstrom statt Null fallen.
Eine Alternative zu selber Multiplexen sind fixfertige Module, die neben der eigentlichen Anzeige auch einen Controller beinhalten, der sowohl Speicher für jedes Zeichen, wie auch ein Font ROM, wie auch eigene interne Multiplex Logik beinhalten. Beispiele sind die DL1414T, 4 * 16-Segment LED Module, mit 4*6bit Speicher und 64*16bit ROM, die ASCII 32..95 darstellen können. Oder ihre grossen Brüder DLR1414 (pinkompatibel) und SLR2016 (kompakter und damit mehrzeilenfähig), 4 * 5x7-Matrix LED Module, mit 4*7bit Speicher und 128*35bit ROM, die ASCII 32..126 und 32+1 weitere Zeichen darstellen können (darunter auch mit Akzenten). Angesteuert werden sie wie normale Speicher, mit 6 oder 7 Datenleitungen, 2 Adressleitungen und ein Schreibsignal. Eine Gruppe von 4 oder 8 Modulen (16 oder 32 Zeichen) ihre Schreibsignale können von normalen halben 74139 2:4 Decoder oder ganzen 74138 3:8 Decoder getrieben werden.
Diese wurden entwickelt als Messgeräte, um über die Zeit variable elektrische Spannungen in ihrer Form als x/t oder [xy]/t Kurven anzuzeigen und auszumessen. Sie können auch ohne Zeitbezug für beliebige x/y Funktionsplots benutzt werden, z.B. um Spannung/Strom Kurven von nichtlinearen Bauelementen auszumessen.
Technisch sind sie elektrisch per Spannungen/Felder ablenkbare Elektronenstrahlgeneratoren, mit 2 Sätzen von je 2 Platten für die Ablenkfelder, mit einer beschichteten Zielfläche vorne wo die auftretenden Elektronen Lichtpunkte erzeugen. Damit sind sie strikte betrachtet per elektrischer Spannungen auf die Plattenpaare ansteuerbare X/Y Elektronenstrahlplotter. Damit können auch sie wie Plotter benutzt werden, solange man die Koordinaten in Spannungen umwandelt, sowie das nach einer kurzen Weile verlöschende Bild immer wieder neu zeichnet, wie bei gemultiplexten Lampen.
Als Messgeräte waren sie in den Entwicklungslabors der Rechnerbauer bereits präsent, um die Interna der Rechner auszumessen. Es war damit naheliegend, sie im X/Y Modus an einen Rechner anzuhägen, als explizite Ausgabe errechneter Graphen, die nicht nur wie bei Multiplexen wiederholt nachgezeichnet werden müssen, sondern auch dadurch vorzu verändert gezeichnet werden können. Der Rest war nur die Interfaces dazu entwickeln und ausbauen.
Bei den normalen 10..15cm Messgerät Röhren wurden oft 8bit Port/PIO + Digital/Analog Wandler verwendet. Das ging bis 10bit für Präzisionsanzeigen. Bei den grossen 20..40cm Radarbildschirm Röhren sind bis zu 12bit hinauf benutzt worden. Während über 8bit mehr und genauere Pixelpositionen ergab, waren aber zumeist die erzeugten Punktgrössen so gross, dass man die Positionen nicht alle einzeln ausnutzen konnte.
Um einen Punkt zu feuern wurde entweder ein Zugriff auf eine dritten Adresse (ohne Daten, ohne Port/PIO) als Auslöser/Strobe benutzt um einen Pixel "abzufeuern", oder der zweite Port/PIO Speicherschreibvorgang konnte benutzt werden um einen separaten dritten Vorgang einzusparen, und so die Rechenzeit besser auszunutzen. Damit man letzteres mit minimalem Aufwand flexibel machen konnte, war es sinnvoll die 2 Ports/PIOs mit 4 Adressen anzusprechen, beide jeweils ohne Strobe (erste Koordinate die geschrieben wird) und mit Strobe (zweite die geschrieben wird).
Horizontale Linien konnten dann als einmal "Y-ohne" und mehrmals "X-mit" gezeichnet werden, vertikale Linien als einmal "X-ohne" und mehrmals "Y-mit". Bei schrägen Linien kam der normale Bresenham Algorithmus zum Zug, mit der immer +1/-1 Richtung als "X/Y-mit" Strobe zeichnen, und der 0 oder +1/-1 Richtung nur beim +1/-1 Fall als "X/Y-ohne" nur die Koordinate ändernd.
Weil Oszilloskope wie Stiftplotter benutzt werden, kann man hier auch problemlos Graustufen umschalten, indem man die Pulsintensität mit einem weiteren Port/PIO und Digital/Analog Wandler am Z Eingang variert. Mit einer Farbröhre kann man mit 3 RGB Pulsintensitäten auch beliebige Farben erzeugen.
Dazu wird statt nach dem Port/PIO verändern mit Strobe den Strahl einschalten, bereits mit dem alten Wert der Strahl eingeschaltet, und dann durch den Schreibvorgang der Strahl bewegt, und danach abgeschaltet, was ein Linienstück gibt. Dies wiederholt ergibt dann eine volle Linie.
Ein Seiteneffekt von Vektorplotten ist, dass man nicht mehr mit nur 1er Schritten arbeiten kann, sondern auch 2er oder 3er oder gar 4er Schritte akzeptabel sind, was den Rechenaufwand reduziert. Die ist bei horizontalen und vertikalen Linien kein Problem, aber bei schrägen Linien versagt dies, weil man den 0 oder 1 Sprung (bzw dessen mehrfaches) nicht während dem Zeichen der anderen Richtung synchron ändern kann, was Treppen statt Schräglinien ergibt.
Ein Weg dies zu umgehen ist beide Port/PIO Speicher doppelt zu haben, einen Satz für "jetzt" und einen für "neu", und beim Strobe den Strahl einzuschalten und dann erst beide "neu" gleichzeitig in die "jetzt" zu kopieren um zu bewegen, und dann den Strahl auszuschalten. Dies kann aber bedingt durch die Schaltgeschwindigkeit nur eine Kurzstrecke sein, sonst ist die Linie dazwischen sehr schnell/schwach gezeichnet. Man kann die Schaltgeschwindigkeit bremsen mit nach jedem D/A Wandler einen Kondensator in der Analogelektronik nachschalten. Aber diese haben exponentiell an die Zielspannung annäherndes Ladeverhalten, und ergeben daher eine unregelmässige ausbremsende Geschwindigkeit und Helligkeit. Also sind nicht mehr als etwa 4er Schritte sinnvoll.
Aus diesem Grund gab es bald Kombinationen von Oszilloskop und Kamera, bei der der Verschluss geöfnet wurde, dann gezeichnet wurde, dann Verschluss zu. Aber selbst mit einer Polaroid Kamera, und deren "Softbildern" ihrer 1/2 bis 2 Minuten Entwicklungszeit, war dies alles andere als direkt, und es verbrauchte Photos. (Es war aber immerhin schneller als ein Stiftplotter, und weniger aufwendig um es zu benutzen, und vermutlich immer noch mechanisch billiger.)
Aus diesem Grund erschienen bald Koprozessoren um Linien schneller als obige 10'000..15'000 Stücke/Sekunde zu zeichnen, zumal die Oszilloskope selber ohne Probleme über Millionen/Sekunde Punkte ertragen, also über das 100fache dessen was der Rechner liefern kann. Um derart schnell zu plotten kann ein Vektorgenerator einen internen Bresenham rechnen, indem die ganze Formel ihre Variablen und Operationen in dedizierter Hardware implementiert werden, ein Schritt pro Taktzyklus, etwa 30 mal schneller (und damit auch für jeden einzelnen Punkt machbar ohne unregelmässige Helligkeit). Der Rechner muss schlimmstenfalls alle Variablen einzeln vorbesetzen und dann den nur-Schleife Zeichenvorgang auslösen oder bestenfalls nur die Anfangs- und Zielkoordinaten eingeben und der Rest wird dann voll automatisch aufgelöst, bis zu den alten Zielkoordinaten zu neuen Anfangskoordinaten umkopieren (bzw letztere nach und nach an erstere angleichen als Teil der Rechnerei).
Beliebige Kurven können als Serien von Linien approximiert werden, solange dies kurz genug sind, dass die Abweichung nicht zu gross wird. Wieviel es erträgt hängt von der Kurve ab. Manche sind tolerant, manche nicht, je nichtlinearer umso schlimmer. Kreise können recht gut mit Linien approximiert werden, daher ist Kreis-Bresenham in Hardware selten geblieben.
Aus diesem Grund erschienen auch bald Koprozessoren um Zeichen schneller zu zeichnen. Ein Ansatz sind als (Matrix-)Charaktergeneratoren bekannt. Hierbei wird die Position des Zeiches mit den normalen X-ohne und Y-ohne Ports/PIOs festgelegt. Danach wird das Pixelmuster auf einen weiteren Port/PIO gegeben, was auch gleich den Zeichenvorgang als Strobe auslöst. Dabei werden mit einem internen Zähler der von Bit0 bis BitN geht diese vom Port/PIO genommen, und jeweils dazu benutzt um den Strahl bei 1 zu pulsen oder bei 0 nicht.
Parallel dazu werden mit dem Zähler als Adresse die In-Zeichen-Koordinaten-0..n aus einer internen kleinen Tabelle (etwa (15..35)*2*(2..4)bit) genommen und auf 2 separate kleine Digital/Analog Wandler (obige 2..4bit breit) gelegt, deren Ausgänge zu den grossen X/Y analog addiert werden, und damit die Pixel positionieren bzw scannen.
Ein Beispiel dazu ist die DEC PDP-1, ein 18bit Rechner von 1960, deren Type-30 Oszilloskopanzeige einen 5x7 Font Charaktergenerator beinhaltete, welcher 2 mal pro Zeichen mit je 18bit an Pixelmustern gefeuert wurde, und dabei 18 bzw 17 Pixel zeichnete. Dies brauchte insgesammt etwa 15 Befehle pro Zeichen, was bei der 200'000 Speicherzugriffen dann 200'000/2/15 = 6000 Zeichen/Sekunde und damit 200 Zeichen/Bild erlaubte, statt nur 10, immerhin 20 mal beschleunigt.
Alternativ wird explizit nur spaltenweise gepunktet, mit eigenem kleinen Digital/Analog Wandler der zu Y analog addiert wird. Für die nächste Spalte wird aber der vorhandene X Speicher mit +1 digital verändert. Dieses +1 geschieht durch eine simple Schaltung, mit pro Bit invertieren falls alle kleineren Bits 1 sind, was nur ein breit-AND und ein XOR Gatter pro Bit braucht. Neben geringerem Hardwareaufwand kommt man damit zu einem automatischen Fortschreiten in X Richtung, ohne nach jedem Zeichen X+Breite rechnen zu müssen, was noch schneller wird.
Ein Primitivbeispiel ist der HP 9100A, ein Tischrechner von 1968, der in etwa einem 1978er programmierbaren Taschenrechner entsprach. Dieser hatte als Anzeige eine kleine Oszilloskopröhre, deren einzige Ausgabe aus 3 Zeilen von 16 Ziffern bzw Vorzeichen sowie Dezimalpunkten bestand, quasi 3 Stück recht breite 1980er Taschenrechner Anzeigen über einander. Der Charaktergenerater erzeugte dazu eine normale 7-Segment Darstellung, mit der leichten Erweiterung dass die 1 mit einer zusätzlichen Mittelsenkrechten gezeichnet wurde, was also eine 9+2 = 9-Segment Anzeige ergab. Der Dezimalpunkt brauchte eine eigene Stelle, weil er ebenfalls in dieser Mittelsenkrechten Position gezeichnet wurde, nicht zwischen zwei Zeichen.
Ein aufwendigeres Beispiel ist der Imlac PDS-1, ein 16bit Rechner von 1970 mit einem Vektor-Charaktergenerator als Koprozessor, der dazu einen eigenen Befehlssatz hat, der neben langen (1..3)*16bit Befehlen mit 2*11bit Absolutadressen Vektoren (Prozessormode genannt) auch mit Listen von 8bit Befehlen mit 2*3bit Relativadressen arbeiten kann kann (Incrementmode genannt). Am Anfang einer Liste muss ein 0011???? ???????? stehen, um in den Incrementmode zu schalten. Die Zeichenbefehle sind dann im Format 1sxmmynn angeben, bei dem angegeben wird ob ohne(s=0)/mit(s=1) Strahl, x +m(x=0)/-m(x=1), m=0..3, y +n(y=0)/-n(y=1), n=0..3). Ein 0??????? Element bedeutet Ende der Liste, wieder in den Prozessormode schalten. Damit sind alle Zeichen als Font erzeugbar, als "Unterprogramme", die dazu noch mit einem 00001??? ??1????? Rücksprung enden müssen (diese ??? steuern andere Features). Der Rücksprung kann, weil mit 0 anfangend, auch gleich als Ende dienen, um Platz zu sparen.
Dessen eigentliche Bildspeicher besteht dann aus 16bit "CALL" Befehlen des Formates 0101aaaa'aaaaaaaa, mit den Adressen (12bit aaaa...) der jeweiligen Zeichen ihrer Listen, beendet und wiederholend mit einem "JMP" 0110aaaa aaaaaaaa an den Anfang. Der Koprozessor kann dazu den Speicher per DMA (nur) lesen. Dabei wird im Prozessormodus 100% und Incrementmode 50% der Speicherbandbreite verbraucht. Es hat mangels eines Stacks (weder im Speicher noch intern) nur eine einzelne Unterprogrammsprungebene (per "Link" Hilfsregister). Das Programm wiederum wird generiert vom Hauptprozessor. Mit 500kHz Speicher und 1 Zugriff pro Befehl und etwa 15 Befehle/Zeichen reicht dies für 500'000/1/15 = 30'000 Zeichen/Sekunde, bei 30 Bilder/Sekunde immerhin für 1000Zeichen/Bild, also ein voller 40x25 Homecomputer oder halber 80x25 PC im Zeichenmodus.
Anstelle einer Kamera und auf Photos warten, kann man auch diese benutzen um wiederholtes Neuzeichnen zu vermeiden, und damit ein aufwendigeres Bild zu bekommen, ohne mit Koprozessoren nachhelfen zu müssen, oder gar ein sehr aufwendiges Bild zeichnen welches diese überfordern würde. Im Gegensatz zum Photo kann man beim Zeichen zuschauen, und das Ergebnis bereits auswerten und beurteilen, sowie falls es unpassend ist die Rechnung abbrechen. Wie beim Photo kann es aber nur mit Löschen und nochmals von Vorne neu/anders gezeichnet verändert werden, wobei aber immerhin kein Verbrauch an Photos anfällt.
Das wohl bekanntest Beispiel dieser Technik war wohl das Tektronix 4014 Terminal von 1974, das mit einem grossen Oszilloskop und 10bit Koordinaten arbeitete, und einen eingebauten Controller hatte, der wie ein Plotter via eine serielle Schnittstelle mit ASCII Zeichen angesteuert wurde, mit einbuchstabigen Kommandos gefolgt von dreiziffrigen dezimalen Zahlen.
Fernseher und Videomonitore sind ebenfalls auf Kathodenstrahlröhren basierte Bildschirme, die gezielt entworfen wurden um Bildsignale über lange Distanzen zu (fern-)transportieren und verteilen um sie darzustellen. Wie bei den asynchronen seriellen Schnittstellen, wo Datenbits und Clock (bzw ein Strobe um einen am Ziel erzeugten Clock anzustossen) zu einem separierbaren Signal gemischt wurden, wurden hier Bild und Horizontal- und Vertikalsignale (bzw Horizontal- und Vertikalpulse um am Ziel generierte Horizontal- und Vertikalsignale anzustossen) mit einander separierbar gemischt, wie in Video gezeigt.
Genauso wie die asynchrone serielle Schnittstelle aus dem Elektromechanik Zeitalter stammt, kommt das Fernsehsignal aus der Analogelektronik Zeit, und ist daher genauso primitiv und recht einfach vom Rechner zu erzeugen.
Eine zweite weit langsamerere Bewegung verschiebt die folgenden Zeilen immer weiter von oben nach unten, gefolgt von einigen komplett schwarzen Zeilen um dieser Bewegung Zeit zu geben um wieder nach oben zu gelangen. In dieser Zeit wird der 0.0V Synchron Puls einiger Zeilen stark verlängert, um auch den Vertikalgenerator zu synchronisieren (der auf die kurzen Pulse nicht reagiert, wegen eines analogen Frequenzfilters davor).
Zeitlich besteht ein Fernsehsignal aus 50 bei PAL (bzw 60 bei NTSC) Halbbildern pro Sekunde. Diese bestehen je aus 625/2 = 312.5 (bzw 525/2 = 262.5) Zeilen. Die Halbzeile ist dazu da, dass die beiden Halbbilder abwechselnd die andere Hälfte der 625 (bzw 525) Zeilen beschreibt. Das ergibt 50*625/2 = 15625 (bzw 60*525/2 = 15750) Zeilen/Sekunde, also 64us (bzw 63.5us) Dauer. Davon sind 4/5 (= 51.2us) Bild und 1/5 (= 12.8us) Rücklauf.
Weil ein Fernsehbild bis zum Rand der Röhre geht, und teils darunter, kann man nicht die ganzen 51.2us ausnutzen. Vielmehr wird ein etwa 40us breiter Bildauschnitt in der Mitte benutzt, mit 2*5.6us auf beiden Seiten ungenutzt, was dann die Breite des klassischen Textrechteckes ergibt. Daher ist:
Bei 4 oder 6 oder 8 Pixel/Zeichen ist damit eine Pixelfrequenz von (4..8)*(0.8..2) = 3.2..16MHz zu erwarten. Da die meisten Videomonitore bei etwa 5..6MHz Schluss machen (und Fernseher nochmals darunter), wurden oft Fonts benutzt, in denen vertikale Linien mindestens 2 Pixel breit sind (und Platz dazwischen ebenfalls, soweit noch möglich). Daher sind die 8Pixel/Zeichen (mit 6 benutzt und 2 Abstand) so sehr beliebt gewesen (neben dass sie gut zu 8bit breiten Speichern passen), was zu den verbreiteten 40*8 = 320 oder 80*8 = 640 Pixel/Zeile führte. Weit seltener waren die eigentlich binär naheliegenderen 256 oder 512 Pixel/Zeile, und wenn fast immer als 32*8 = 256 oder 64*6 = 512 benutzt. Dies weil sie als 40*6 = 240 bzw 80*6 = 480 nutzen (mit den verbleibenden 2*8 bzw 2*16 im Rand draussen), mit 6ixel/Zeichen (mit 5 benutzt und 1 Abstand, was erst noch dem standard 72dpi 6x12 Druckerfont entsprechen würde), keine 2-breit Regel erlaubt (der Apple II ist einer dieser Ausnahmen, mit einem 6x8 Font, ebenso der Tandy TRS-80 mit 6x12). (Selbst 4 Pixel/Zeichen mit 3 benutzt und 1 Abstand waren daher lesbarer als diese 5 benutzt und 1 Abstand, wie es auch im SoftVGA verwendet wurde.)
Video hat aber derart hohe Geschwindigkeitsanforderungen (im MHz Bereich), dass ein Prozessor damit nicht nachkommt, es nur mit dedizierten Controllerschaltungen erzeugt werden kann, den Videocontroller oder Videogenerator, und nicht mit Software und Ports/PIOs. Ausser man hat einen schnellen Rechner wie dem AVR in der SoftVGA, der mit 18.3MHz Takt und 3 Befehle/Pixel und 1 Takt/Befehl gerade noch 6.1MHz Pixel und damit 160 Pixel/Zeile schaffte, und damit Platz für 40 Zeichen zu je 4 Pixel Breite anbot (das gerade noch zu schaffen war genau das speziell herausfordernde an diesem Projekt).
Da der Speicher eines Rechners mehrere Bits breit ist, beinhaltet ein Speicherwort mehrere Pixel ihre Bits. Diese werden en bloc vom Speicher geladen, und dann nach und nach zum Monitor hinausgeschoben, wozu ein PISO Schieberegister benutzt wird. Dabei kann sowohl Bit0..n von links nach rechts oder rechts nach links dargestellt werden, je nach Hersteller ihrer Verdrahtung der Schieberichtung. Weil man zumeist BitN als 2^(n-1) links zeichnet, und Bit0 = 2^0 = 1 rechts, wird häufig BitN = links und Bit0 = rechts ausgegeben, wozu BitN zuerst geschickt werden muss, was nach links schieben braucht. Aber weil man die Adressen aufsteigend nach rechts ausgibt werden auch teils Bit0 = zuerst/rechts und BitN = zuletzt/links verwendet, was dann nach rechts schieben braucht. Hier muss man in der Doku des Rechners nachlesen.
Mit 0.8..2MHz Zeichenfolge mal 4..8 Pixel/Zeichen, geteilt durch die Speicherwortbreite, sind dazu immer noch 100e kHz bis mehrere MHz Speicherzugriffe nötig. Bei dieser Geschwindigkeit kommt auch eine Prozessor Kopierschleife auch nicht nach, es müssen die Bitmaps daher ohne Umweg über den Prozessor direkt vom Videocontroller aus dem Speicher geholt werden, per DMA. Dazu muss in diesem ein "aktuelle Adresse" Register vorhanden sein, um den Bildspeicher zu adressieren, sowie ein "Anfangsadresse" Register, um ersteres bei jedem Bildrücklauf wieder auf den Bildspeicheranfang zu setzen.
Selbst mit DMA kann der dadurch verbrauchte Speicherzugriff den Prozessor massiv ausbremsen, in manchen Fällen bis zum Stop herunter, mit 40us von 64us Stillstand, ein Verlust von 62.5% der Leistung während eine Bildzeile am zeichnen ist! Mit 200 von PAL 312 (bzw NTSC 262) Zeilen sind das dann immer noch 40.1% (bzw 47.7%) an Verlust von der Gesammtleistung.
Nebenbei: Die 6800/6809 und 6502 haben hier einen Vorteil, dass ihr 1 Takt pro Speicherzugriff Verhalten genau vorhersehbar ist. Zusammen mit einem doppelt so schnellen Speicher (nur 2MHz/500ns Speicher bei 1MHz Proz, oder 4MHz/250ns Speicher bei 2MHz Proz), kann man es einrichten, dass abwechselnd (= 180grad Phasenverschoben) Prozessor und Videocontroller je 50% der Zeit auf den Speicher zugreifen, ohne einander gegenseitig auszubremsen.
Nebenbei: Der Commodore 64 hat hier eine Sonderstellung, dass er bei 2MHz Speicher und 1MHz Proz die eigentlichen Bitmapdaten jeder Zeile verschoben holt, aber jede achte Zeile auch die unverschobenen Zugriffe benutzt, um Farbcodes (im Bitmapmodus) oder Zeichencodes (im Zeichenmodus) zu lesen, auf Kosten des Prozessors, mit nur 5% (bzw 6%) der Leistung verlierend (statt 40% (bzw 48%)), aber diese blockweise mit einer Zeile Komplettstillstand (weshalb diese als "Badlines" bekannt sind). (Die 1541 Floppy ist gegenüber der 1540 Floppy genau darin geändert, dass ihr Software Bitbanging ohne Bithandshake mit Warteschleifen ausgebremst wurde um diese 40us Pausen zuzulassen, was sie so langsam machte. Das ist weshalb die einfacheren "Turbodisk/Schnelllader" Programme einfach die Bilddarstellung ausschalten und dann die Warteschleifen wegliessen.)
Nebenbei: Die 8080/Z80 und 8086 haben 3..6 Takte pro Speicherzugriff (am häufigsten sind 4), und benutzen den Speicher für die ersten 3 davon. Man kann obigen Trick benutzen, wenn man 3er auf 4er sowie 5er und 6er auf 8er streckt, und dann dem Prozessor für Takte 2 und 3 den Speicher gibt, und dem Videocontroller für 4 und 1 (bzw für 4 und 5 sowie 8 und 1, mit 6 und 7 unbenutzt). Dieser Trick wurde im Amstrad/Schneider CPC benutzt und bremst deren Z80 um etwa 10..20%. Alternativ kann man wie beim IBM PC seiner 8088 einen separaten Videospeicher benutzen, und den Prozessor nur bei Zugrffen auf diesen ausbremsen. Auch die ganzen auf TMS9918 Chips basierten Rechner benutzen einen separaten Videospeicher, mitsammt aller Verwaltung davon auf dem Chip, auf den man nur durch einen Port auf der Adresse 1 vom Chip hindurch zugreifen kann, neben noch ein Kommando/Status Register auf Adresse 0 vom Chip haben.
Mir ist nur eine Ausnahme bekannt welche komplett ohne DMA auskommt, den Atari VCS (bzw später umbenamst zu Atari 2600), der in seinem TIA Chip drinnen 2*8+1*4 = 20bit(!) an Bildspeicher Register hat (auf welche dieser strikte mit internem Lesebus zugreift), die auf einer Zeile von 40Pixel als 1bpp zweimal dargestellt wurden, mit der zweiten Hälfte wiederholt, fakultativ in spiegelverkehrter Richtung. Diese 20bit Daten wurden dann für alle Zeilen wiederholt, was nur vertikale Streifen ergibt, ausser die CPU überschreibt diese 2.5Bytes vorzu für jede Zeile welche vom Vorgänger abweicht! Wozu die 6507 pro Zeile die etwa 64us Zeit hatte, bei 3.58MHz genau 228 Zyklen, wodurch sie mit /3=1.2MHz Speicher und typisch 3 Speicherzugriffe/Befehl sich gerade einmal 76/3 = 25.33 Befehle erlauben konnte, dann ist bereits die nächts Zeile zu machen!
Eine Halbausnahme ist der RCA CDP1861 "Pixie" Chip, der speziell zu deren CDP1802 "Cosmac" Prozessor passte, und dessen bereits eingebaute DMA Einheit und dessen Adressregister ausnutzen konnte, und daher selber keine Adressen generierte, nur das Timing mit dem es das nächste Byte anforderte. Die DMA Adresse wieder auf den Bildspeicheranfang setzen musste dann die Software machen.
Auch der Xerox Alto hat für DMA seinen speziell designten Prozessor eingespannt, der auf Hardwareebene Mikrocode Multithreading beherrschte, in Form eines Bildzeilen Mikrocode Moduses, in dem dieser nicht nur die Adressen generierte, sondern auch das Timing dazu, während von extern nur der Modus für jede Pixelzeile angeworfen wurde. Dieses kostete einen ansehnlichen Teil der Rechenleistung, trotz etwas Hardwaresupport um es zu beschleunigen.
Auch die Sinclair ZX80 und ZX81 schaffen dies gerade noch, ohne Mikrocode und ohne eingebautem DMA, mit einem Trick. Dies indem sie die Videodaten im Speicher vom Prozessor als Serien von 1-Byte/1-Speicherzugriff/4-Zyklus Befehlen holen lassen, indem die gelesenen Bytes nach einen "Zeile zeichnen einschalten" Befehl durch 0 (8080/Z80 NOP Befehl) ersetzt werden. Diese "Programme" wurden von der Z80 wie alle anderen aus dem Speicher gelesen (schneller als jede Software Daten lesen kann!) und ausgeführt (sofern man bei NOPs von ausführen reden kann). Sie wurden aber zudem nebenbei als 1 Befehl/Byte = 1 Zeichencode mitgezeichnet, solange bis ein Befehl mit Bit7=1 auftrat, welcher nebenbei als "Zeile zeichnen abschalten" und "nicht mehr NOPs machen" wirkt, und somit als Zeilenende. Dieses Bit7=1 limitiert die ZX80 und Zx81 auch auf 128 Zeichencodes, 64 plus Reverse. Dieses erlaubte es aber auch, unvollständige Zeilen als kürzere Programme abzulegen (wichtig bei nur 1k RAM im ganzen Rechner!). Dies kostete aber einen Grossteil der Rechenleistung, weshalb die ZX80 nur entweder anzeigen oder rechnen kann (wie viele 7-Segment Rechner auch), und die ZX81 zwei Modi kennt, "FAST" schnell ohne Bild wie die ZX80, oder "SLOW" mit NMI Interrupt gesteuert langsam (etwa 25% verbleibend) aber mit Bild bleibend (wiederum wie ein 7-Segment Rechner arbeitend). (Die SoftVGA verwendet vergleichbare Interrupt Techniken um zu zeichnen (und auch Syncimpulse zu erzeugen) und trotzdem mit etwa 10..30% Leistung (alle leeren Zeilen) anderes zu rechnen, was dank dem weit schnellem AVR immer noch mehr verbleiben lässt als eine ungebremste 8080/Z80 hat.)
Für eine Zeile werden damit 32/40/64/80 Bytes Daten verbraucht. Auf diese Art werden dann zumeist 192 oder 200 Zeilen mit Inhalt gezeichnet, zumeist im Speicher direkt hinter einander folgend. Bei 160 oder 320 oder 640 Pixel/Zeile 1bpp passen 200 Zeilen mit wenig Rest gerade in 4kByte bzw 8kByte bzw 16kByte an Speicher (genau sind es 4000 bzw 8000 bzw 16000Bytes). Bei 128 oder 256 oder 512 Pixel/Zeile 1bpp werden zumeist 192 Zeilen gezeichnet, weil dies genau in 3kByte bzw 6kByte bzw 12kByte passt. Es gab aber auch anderes, wie die KC-85/2 und /3 ihre 320x256 1bpp in 10kBytes, oder die /4 320x256 2bpp in 2*10kBytes, oder die Acorn BBC ihre 640x256 1bpp in 20kBytes.
Die restlichen Zeilen eines Bildes sind wiederum komplett schwarz, ohne nachladen. Wozu wieder Zeilen gezählt werden, um zu pausieren, bzw um Vertikalimpulse zu erzeugen. Um dies zu vereinfachen, und Halbzeilen zu vermeiden, wird ein Bild zumeist auf 312 PAL (bzw 262 NTSC) Zeilen pro Halbbild gekürzt (die Fernseher/Videomonitor Analogelektronik erträgt diesen 0.16% Fehler locker), womit man strikte 50 Vollbilder mit je halben 312 (bzw 262) Zeilen generiert. Dies vermeidet das bei Halbbildern entstehende Flimmern an scharf begrenzten horizontalen Linien, wenn diese mit 50/2=25Hz auf/ab "wackeln". Das ist aber auch der Grund für die "streifige" Darstellung auf Videomonitoren, weil nur eine halbe Zeilenzahl angezeigt wird, dazwischen nichts beleuchtet wird.
Allenfalls wird als Seiteneffekt dieses Zeilen abzählens auch am Anfang des "leeren" pausierten Teils dem Prozessor ein Interrupt geschickt, was als Vertikalblankinterrupt bekannt ist. Dieser erlaubt es Routinen auszuführen, welche die Videodaten fürs nächste Bild synchron abändern, z.B. Animationen einen Schritt weiter zu bewegen. Manche Rechner, wie Dragon 32/64 und Atari ST, liefern auch einen höher priorisierten Horizontalrücklaufinterrupt Dieser belastet aber den Prozessor massiv, weshalb solche per Default ausgeschaltet sind.
Videogeneratorn sind mit Bildspeicheradresse plus Pixel/Zeilentiming plus Zeilen/Bildtiming in erster Linie mehrstufige komplexe verschachtelte Zähler. Dies wiederum mit einer genau definierten Aufgabe. Dementsprechend wurden diese bereits in den 1970ern das Ziel von speziellen hochintegrierten Chips. Ein bekanntes Beispiel ist der Motorola MC6845, der auch von IBM in den PC MDA (und wegen kompatibel MGA) sowie CGA Karten verbaut wurde (und wegen Kompatibel in den EGA/VGA/etc emuliert wird, aber nur teilweise), und ebenso von Amstrad/Schneider in den CPC verbaut wurde, sowie von Acorn im BBC. Um diesen Universalchip auf die gewünschten Frequenzen zu konfigurieren/programmieren musste man 16 Zahlenwerte in dessen ebensovielen internen Register schreiben. Um Adressen (und vor allem Adressleitungspins) zu sparen waren nur 2 sichtbare Register vorhanden, ein "Auswahlregister" das die Adresse des zu beschreibenden Registers bekommt, und das gerade aktuell von obigen adressierte eigentliche Zielregister das die Daten bekommt. (Diese erscheinen auf der MDA/MGA bei Adressen Hex 03B4 Auswahl und 03B5 Ziel, bzw bei CGA/EGA/VGA/etc auf 03D4 und 03D5. (Die ersten 8 der 16 Register sind die von der Linux X Server Konfiguration bekannten 2*4 "ModeLine" Zahlen.))
Daher wurde zumeist bei mehr Graustufen die Auflösung passend reduziert. z.B. eine 40Byte Zeile wahlweise als 320 Pixel 1bpp/2Grau, bzw 160 Pixel 2bpp/4Grau, bzw 80 Pixel 4bpp/16Grau, oder eine 80Byte Zeile als 640 Pixel 1bpp/2Grau, bzw 320 Pixel 2bpp/4Grau, bzw 160 Pixel 4bpp/16Grau, bzw 80 Pixel 8bpp/256Grau. Dazu wurden statt einem 8bit PISO Scheiberegister (SR), entweder 2 4bit SR (bits 7+5+3+1 und 6+4+2+0) oder 4 2bit SR (bits 7+3 und 6+2 und 5+1 und 4+0) benutzt, bzw bei 8bit gar kein Schieberegister mehr (direkt alle 8bit).
Dieses war teilweise zwecks Optimalpunkt auswählen umschaltbar, je nach ob man mehr Auflösung will (für viel Schrift) oder mehr Stufen (für abgestufte Schattierung). Dazu waren mehrere Sätze von Schieberegistern vorhanden, und zwischen denen und dem Digital/Analog Wandler ein Umschalter. Bei z.B. einem 1/2/4bit waren dies ein 4bit Wandler, und davor 4 Umschalter mit je 3 Positionen, verdrahtet von den 4 4bpp-SR (von Bit0,1,2,3) sowie den 2 2bpp-SR (von Bit0,1,0,1) und dem 1 1bpp-SR (von Bit0,0,0,0), was insgesammt 7 SR braucht.
Dazu muss auch der Pixeltakt umgeschaltet werden. Alternativ kann man stets 8bit SR nehmen, mit festem Takt, aber die weniger Bits mehrfach benutzen, z.B. 2bpp die Bits 7+7+5+5+3+3+1+1 und 6+6+4+4+2+2+0+0. Das Resultat sind stets 2,4,8bpp, die an einen passen breiten 2/4/8bit Digital/Analog Wandler gehen, der dann die 4,16,256 Graustufen darstellen kann, indem er soviele Schritte zwischen 0.3 und 1V erzeugt.
Bild löschen oder scrollen ist wie oben, ebenso die Adressrechnung. Das Bitmuster muss nun aber anderst generiert werden. Bei 8bpp wird einfach der Helligkeitswert als 8bit Zahl direkt geschrieben, ohne jegliche Umrechnung oder Tabelle. Ansonsten setzt der Wert sich per AND zusammen aus 2 Sachen: Dem Helligkeitsmuster und dem Pixelmuster. Ersteres ist der Helligkeitswert (2bpp 0..3 oder 4bpp 0..15) dann mehrfach wiederholt (2bpp 4*2bit oder 4bpp 2*4bit), wieder oft als Tabelle oder gar eine Konstante. Zweiteres ist erst recht eine Tabelle, mit Bitpaaren oder Bitquads darin, wieder mit anderer TabelleB[X AND Pixel-per-Speicherwort-minus-1] ausgelesen, wobei letzteres aber eine kleinere Tabelle ist (z.B. bei 8bit 2bpp TabelleB2[X AND 3] bzw 4bpp TabelleB4[X AND 1]).
Um diese U und V separierbar ins Y zu mischen wurden sie auf 2 um 90 grad zu einander phasenverschobene 4.43MHz (bzw 3.58MHz) Träger moduliert, was als QAM Verfahren bekannt ist. Diese UV-QAM "Farben" ins BAS gemischt ist dann als FBAS bekannt. Da wir Farben mit weitaus weniger Auflösung sehen als Helligkeit, wird das QAM mit nur 1.3MHz/6.5MHz = 1/4 bei PAL (bzw 1MHz/5.5MHz = 1/5 bei NTSC) Datenrate verschickt. Da die Phase entscheidend ist um U und V aus dem QAM zu trennen, wird ein fest um 45grad (= U und V maximal) gephaster Träger während einem Teil des horizontalen Rücklaufes (nach dem Horizontalpuls) im FBAS mitgeschickt, was als Farbburst bekannt ist. Letzterer identifiziert auch den Unterschied von Schwarzweisssendung zu Farbsendung (ohne Farbburst wird einfach R = G = B = Y genommen).
Weil Fernseher und Videomonitore Farben können war es nur eine Zeitfrage bis jemand dies ausnutzen wollte. Dazu müssen neben dem Y Schwarzweissignal auch die U und V erzeugt werden, bzw deren QAM Signal.
Am einfachsten geht dies, indem man die vierfache QAM Frequenz 4*4.43 = 17.72MHz bei PAL (bzw 4*3.58 = 14.32MHz bei NTSC) nimmt (was ohnehin Standardquarze sind), und damit ein kurzes 4bit Schieberegister benutzt, dessen Ausgang immer wieder zum Eingang wird, womit ein sich alle 4 Pulse wiederholendes Signal entsteht (und damit auch 4.43MHz (bzw 3.58MHz)). Lädt man einen der Werte 1100 0110 0011 oder 1001 entsteht (nach Wegfilterung der Oberwellen per einfacher Analogelektronik) eine 4.43MHz (bzw 3.58MHz) Welle mit 4 möglichen Phasen (und damit 4 primäre Farbtöne). Mit 1010 und 0101 entstehen wegen des Filters ein halbes Signal und damit blasse Töne. Mit Kombinationen von 3*0+1*1 oder 1*0+3*1 kann man verschiedene halb-blasse Töne erzeugen. Insgesammt sind mit 4bit 16 Töne möglich.
Mischt man diese mit 4bit Helligkeit sind damit 256 Farben möglich (bzw strikte 241, weil Hell=0 nur 16 "Farbtöne" von Schwarz ergibt). Logisch braucht man hierzu wieder 8bpp, was die Auflösung massiv reduziert.
Nebenbei: Der hierfür nötige 17.72MHz (bzw 14.32MHz) Quarz wurde oft zwecks Kostenersparnis auch für den Prozessortalk mit benutzt, sei das mit strikter 2er Teilung (/2 /4 /8 oder /16), was dann mit 14.32MHz Quarz die oft gesehenen 7.16MHz bzw 3.58 MHz bzw 1.79MHz bzw 0.895MHz "Serie" ergab (welche dann oft mit 7.16MHz Pixel und 0.895MHz Speicher liefen). Oder mit "queren" Teilern (z.B. beim Commodore 64 mit NTSC 14.32/14 = 1.023MHz bzw mit PAL 17.72/18 = 0.985MHz).
Ohne Kompatibilitätsforderungen konnte auch die Signalisierung einfacher gestaltet werden. Dabei wurden nicht mehr Bild und Syncpulse gemischt (und auch letztere horizontal und vertikal separat gehalten), sondern einfach 3 Leitungen benutzt. Da das Bild bei dieser Auflösung zumeist nur 1bpp war, ohne umschaltbare Auflösung oder Graustufen, wurde es einfach ohne Wandlung in 0.3..1V als störsicherere volle 5V Logik verschickt (und die beiden Sync Signale ebenfalls).
Wurden doch (wenige) Graustufen vorgesehen (wie die 2bpp/4Graustufen der NeXT Workstations), wurden die Grauwerte zumeist als wenige Bits auf separaten Logikleitungen geschicht, mit dem Digital/Analog Wandler erst im Monitor darin. Ein Spezialfall sind hier die PC MDA Karte und ihr Monitor, welche eine ein=1/aus=0 Leitung haben, und eine weitere Leitung welche bei "ein" zwischen hell=1/mittel=0 unterscheidet, zwar 2bit, aber nur 3 der 4 möglichen Graustufen benutzend.
Auch erlaubte dies erst vertikale (portrait) Bildanordnung, wie beim obigem Alto seine 600x800, oder viele dedizierte Textverarbeitungssysteme, oder den Radius Monitoren für die Macintosh II Rechner (und auch obigem Imlac PDS-1 seinem Vektordisplay). Diese erlaubten weit mehr Textzeilen zu sehen (z.B. 80x50 statt 80x25, immerhin das doppelte, oder gar teils volle 80x66 Druckerseite) und waren damit für jegliche Texte editieren (inklusive Programcode!) weit besser als die vom Fernseher kommende horizontale (landscape) Anordnung, welche nur bei Tabellenkalkulation oder CAD Vorteile bringt.
Nebenbei: Auch Autorennen und Vertikalscroller Spiele bevorzugten die Portrait Anordnung, allerdings laufen diese zumeist mit normalen Fernsehmonitoren, um 90grad nach links gedreht, mit den Zeilen von unten nach oben statt von links nach rechts gezeichnet, was gerade bei einer "gestreiften" Bilderzeugung schlecht aussah, und wegen grossem Zeileabstand und geringer horizontaler Auslösung für Text ungeeignet ist.
Teils Hersteller lösten dieses "portrait oder landscape besser" Problem, indem sie um 90grad drehbare Monitore herausbrachten, zum Teil sogar mit automatischer Dreherkennung (wie bei heutigen Smartphones) und damit den Videocontroller umkonfigurieren (z.B. den Radius Pivot für den Macintosh II).
Erst mit den grossen (19..21") Monitoren, deren landscape Anordnung etwa der Fläche von 2 normalen (14..15") Portrait neben einander entspricht (bzw 4 normalen (9..11") Landscape), verschwand Portrait als Anordnung da diese auch ohne Rotation sowohl eine grosse Tabelle/CAD (und heute auch Photo/Video) wie auch zwei volle Seiten Texte/Programe (und heute auch Mails/Websites) Platz anbieten.
Nebenbei: Erstaunlicherweise hat der ansonsten graphisch exzellente Amiga weiter am FBAS Videomonitor festgehalten, weshalb er seine 640 Pixel nie wirklich ausfahren konnte, und erst recht nicht seinen 640x400 Modus, welcher 2*25Hz Halbbilder machen musste. Dies kommt vermutlich daher, dass dessen Chipsatz anfangs für eine Spielkonsole designt wurde.
Dabei werden diese teils als 3 mal 0..0.7V Analog (z.B. PC VGA und Atari ST Farbmonitor und einige Workstations) oder als 3 mal n Bits Logik (z.B. PC CGA und EGA und PGA) verschickt. Letzteres artet in viele Leitungen aus (CGA 3+1 oder EGA bereits 3*2 oder die seltene PGA sogar 3*4).
Nebenbei: Dazwischen liegt der Atari ST, als Zwitterding. Mit entweder im 640x200 Farbmodus Amiga-artige Videomonitor Frequenzen aber mit RGB Analog Signalen, oder im 640x400 Schwarzweissmodus Macintosh-artig Spezialmonitor Frequenzen mit 1bit Digital Signalen. Dies bis zu bei Monitortyp umstecken auto-rebooten und die passenden Frequenzen (und Pixelanordnung im Videospeicher) zu sichern! Eben ein Zwitter.
Bei rein Logik sind die Syncpulse stets eigene Logik Leitungen (PC MDA sowie CGA und EGA). Bei RGB Analog können sie eigene Logik sein (PC VGA), oder mit dem grünen Videosignal vermischt als Sync-on-Green (viele Workstations oder Amstrad/Schneider CPC).
Für jedes Pixel bei QAM 8 Bits bzw bei RGB 3*n (n=2..10) Bits spendieren kostet viele Bits pro Pixel und damit niedrige Auflösung. Anderseits sind beliebige QAM 256 bzw RGB 64/512/4096/... Farben für jedes Pixel genauso wenig nötig wie stets 256 Graustufen. Man kann auch hier nur 1/2/4bpp benutzen, und damit mehr Auflösung haben. Dazu muss man die 2/4/16 Pixelwerte im Bitmap als Indizes einer (2/4/16)*(8oder3*n)bit grossen Farbtabelle anschauen, in der dann die eigentlichen 4+4bit QAM oder 3*nbit RGB Farbwerte stehen. So eine Tabelle wird als Colour Look Up Table (CLUT) bezeichnet.
Diese kann aus ROM mit festen Werten darin bestehen, z.B. Commodore 64 ein 16-zeiliges 4+4bit ROM (was dessen 16 Farben ergab), oder PC CGA ein 16-zeiliges 3*2bit (im Monitor mit den DA Wandlern, nicht auf der Karte!) (was dessen 16 RGBI Farben ergab).
Oder aus RAM mit ladbaren Werten, z.B. Atari 800 mit 1/2/4bpp ein 2/4/9-zeiliges RAM mit 3+4=7bit (8 Graustufen) im alten CTIA Chip bzw 4+4=8bit (16 Graustufen) im neuen GTIA Chip (was dessen 128(113) bzw 256(241) Farben ergab), oder Amstrad/Schneider CPC mit 1/2/4bpp ein 2/4/16-zeiliges 3*2bit RAM (von dem aber wie bei der PC MDA nur aus/mittel/hell als 3*3*3=27 der 4*4*4=64 Werte genutzt wurden), oder PC EGA mit 1/4bpp ein 2/16-zeiliges 3*2bit RAM (was dessen 64 Farben ergab), oder PC VGA mit 1/4/8bpp ein 2/16/256-Zeilen 3*6bit RAM (was dessen 266144 Farben ergab).
Man kann auch mehrere CLUTs stapeln, z.B. Commodore 64 mit 1/2bpp zuerst ein 2/4-zeiliges 4bit RAM das dann wiederum obiges 16-zeiliges ROM anzuspricht, oder PC CGA mit 1/2bpp zuerst zwei umschaltbare 2/4-zeilige 4bit Karten-ROMs welche wiederum obiges 16-zeiliges Monitor-ROM anzusprechen (diese extrem primitiven 2ROM+ROM CLUTs waren auch schuld an der CGA ihren sehr limitierten entweder Schwarz/Rot/Grün/Gelb (ohne Weiss) oder Blau/Magenta/Cyan/Weiss (ohne Schwarz und hässliche Kombination) Auswahl, welche die frühen PC Spiele so lange kennzeichnete), oder PC VGA in CGA oder EGA Modus, zuerst die EGA ihr 16-zeiliges 3*2bit RAM (mit CGA Monitor Werten vorbesetzt) welches dann wiederum 1/4 der VGA ihrem obigen 256-zeiliges 3*6bit RAM anspricht.
Den ultimativen CLUT-losen Farbspartrick zieht aber der Apple II in seinem "hi-res" Bitmapmodus ab. Dieser hat stets 1bpp, von denen zudem nur 7bit als Pixel benutzt werden (mit 40Bytes/Zeile zusammen für 280 Pixel/Zeile). Diese werden mit etwa 1MHz eingelesen, und direkt wie bei schwarzweiss ausgegeben, aber die nur 7 Pixel mit 7.16MHz auf genau dem Doppeltem vom NTSC 3.58MHz Farbträger (die 7bit erlauben damit genau einen 1.023MHz Speichertakt). Damit werden wie zu erwarten 0-er als Schwarz und 1-er Weiss ausgegeben, aber abwechsende 01-er oder 10-er erscheinen als Seiteneffekt der QAM Decodierung im Fernseher als grün bzw violett. Das läuft über die 7-er Grenzen hinweg, mit 2*7bit als 7 2bit Paare verwertet. Das pixellose achte Bit wird dann noch genutzt um die 7.16MHz um einen halben Takt zu verschieben (bzw auf inverser Taktflanke zu laufen) womit dann 01-er und 10-er zu orange bzw blau werden. Das erlaubt 4 Farben (bzw mit Limiten 6) aus nur 1bpp, und das erst noch ohne CLUT Aufwand! Ein typisches Wozniak Spardesign.
Eine Methode, derart grosse Datenmengen zu schaufeln, gerade auch wenn man viele Farben und gleichzeitig grosse Auflösung haben will, besteht darin die unvermeidbaren Speicherkosten zu akzeptieren und die Bandbreite per sehr breiten Bildspeicher zu liefern. Dieser ist aber schwierig vom Prozessor aus zu beschreiben. Zumeist wird der Speicher 2/4/8 mal breiter als der Prozessor gemacht, und dann die unteren 1/2/3 Adressbits als Speicherauswahl missbraucht, erst der Adresseanteil darüber adressiert innerhalb der Speicher.
Ein Umweg besteht darin, mehrere separate 1bpp Speicher zu haben, mit der ganzen Adresse in jeder wirkend, plus dazu ein Auswahlregister welcher Speicher gemeint ist. Diese Speicher werden Bitplanes genannt. Alles in einem Speicher, mehrere Bits pro Pixel in einem Byte, wird dagegen als Chunks bezeichnet. Dann kann man alle Planes vom Videocontroller gleichzeitig/parallel auslesen lassen, aber vom Prozessor separat/seriell beschreiben, dies mit dem ganzen Adressbus. Ein Nebeneffekt ist, dass man je nach Farbbedarf mehr oder weniger Planes vorsehen kann, als Feature-/Kostenoptimierung, oder gar nur als Aufteilung der Speichermenge und/oder Bandbreite auf Video und Prozessor.
Als Beispiel die PC EGA. Diese konnte mit 64k RAM nur 1Plane/1bpp/2Farben oder mit einer +192k RAM Erweiterung auch 4Planes/4bpp/16Farben haben (die Planes sind nur je 640/8*350=28000=27.3kByte, aber 64k hat nur Bandbreite für eine). Dabei konnte mit einem Register angewählt werden, welche Plane gelesen und welche Planes(s) beschrieben werden kann/können. Zudem war es auch möglich mit einer Hilfslogik alle 4 Planes gleichzeitig zu modifizieren, indem man Adresse/Bitmuster wie bei 1bpp benutzte, aber ohne OR/invers-AND/XOR Operationeb einfach alles gerade als 8bit Werte "abspeicherte". Die EGA Karte errechnete mit einer eigenen 4*8bit Logik die 4 Planes ihre separaten OR/invers-AND/XOR, nachdem man ihr vorgegeben hatte welche Funktion man wollte, und auf welche Planes diese angewandt werden sollte. Man konnte sogar eine Farbe spezifizieren, und es gab je nach Plane OR oder invers-AND, passend zum den 0 oder 1 Bitmustern der Farben. Zudem kann während ein Plane vom Prozessor gelesen wird die 4*8bit Logik alles Planes bekommen, und auch mit geeignetem Modus alle aufs mal an andere Adresse schreiben, für schneller umkopieren/scrollen. Der VGA ihr 16-Farben 640x480 ist der selbige Modus, nur mit mehr Zeilen (und Planes von 640/8*480=38400=37.5kByte).
Commodore Amiga benutzte im Vergleich nur einen 16bit Videospeicher, mit max 4*16bit pro 1us Bandbreite, diesen aufgeteilt in 4 oder 8 virtuelle Bitplanes (für je nach ob 640 bzw 320 Pixel/Zeile, 1us oder 2us pro 16Pixel). Danach mit je nach Anzahl aktivierter Planes 640Pixel (1..4bpp) oder 320Pixel (1..5bpp) geholt, mit dahinter einer 32-Zeilen RAM CLUT mit davon 3*4bit RGB, was die 16-oder-32 von 4096 Farben ergab. Solange maximal 640Pixel mit 2 Planes oder 320Pixel mit 4 Planes (= halbe Bandbreite) benutzt wurde, konnte der 8MHz 68000 Prozessor mit voller 2*16bit pro 1us Geschwindigkeit arbeiten (selbiger Trick wie eine 2MHz 6800/6809 und 6502), darüber wurde er nach und nach ausgebremst. Das war auch der Unterschied von Chip-RAM (mit Video geteilt und gebremst) und Fast-RAM (nur Prozessor ungebremst), mit dem zusätzlichen Problem dass auch Sound und Floppydisk DMA nur mit Chip-RAM gingen, weil zusammen mit Video den nur-Chip-RAM adressierenden DMA Controller im DRAM Controller Chip nutzend. Hilfslogik für mehrere Planes aufs mal bearbeiten hatte er keine, das musste dann der Blitter mit Geschwindigkeit erschlagen.
Atari ST war auch hier ein Zwitterding. Gleicher 4*16bit pro 1us Speicher (und 8MHz 68000) wie im Amiga (aber auf volle 8MHz laufend statt nur 7.16MHz), mit maximal halbe vom Amiga seiner Planezahl/Bandbreite für 640Pixel mit 2 Planes oder 320Pixel mit 4 Planes, daher nur 4*16bit pro 2us holend, die CPU damit nicht ausbremsend. Zudem noch mit einem "1280Pixel" 1bpp Modus, welcher aber per Zeilenzeit halbieren in 640Pixel 1bbp mit 400 Zeilen ohne Interlace umgewandelt wird. Dabei sind die eigentlichen 16bit Worte plane-artig organisiert, aber die Byteadressen sind dann chunk-artig angeordnet. Auch hier ein Zwitter.
Nebenbei: Alle CGA Modi, sowie VGA ihre 256-Farben 320x200 sind dagegen mit Chunks. Ebenso alle späteren VGA oder danach 256 oder mehr Farben Modi. Ebenso alles davor in den 1970ern, von Cromemco Color Dazzler bis zu allen 8bit Atari und Commodore Homecomputern. Anderseits sind Mitte 1980er EGA/VGA 16-Farben und Atari ST und Commodore Amige wie gesehen mit Planes. Ebenfalls viele Mitte 1980er Workstations. Das scheint damals eine Mode gewesen zu sein. Wohl aufgekommen weil einfach zu bauen, dann untergegangen weil mühsam zu programmieren.
Am besten ist dazu dem Amiga sein Hold-And-Modify (HAM) Modus bekannt. Dieser setzt den 320Pixel Modus voraus, und verwendet dann 6 Bitplanes und 6bpp (der originale HAM) oder gar 8 Planes und 8bpp (der neuere HAM8). Diese werden als 2+4bit bzw 2+6bit verwertet. Sind die 2bit=00 werden entweder die anderen 4bit als 16 CLUT Indizes benutzt, bzw die 6bit als 3*2bit direkte 64 Farben. Das reichte bei 320 Pixel/Zeilefür 40 8-Pixel oder 80 4-Pixel Zeichen Schrift, in 16von4096 oder 64 Farben.
Sind die 2bit aber 01 10 oder 11 werden die 4bit oder 6bit dazu benutzt um eine der 3 R oder G oder B Komponenten zu ersetzen (= modify), während die beiden anderen Werte unverändert bleiben (= hold). Technisch ist der Aufwand pro Farbbit (3*4=12 mal) ein 4:1 Multiplexer, mit den 2bit als gemeinsame Auswahlsignale. Wenn man alle 3 Pixel abwechselnd R/G/B ersetzt, reicht das für 320/3 = 107 Pixel-3er Farbauflösung und immer noch 320 Pixel Helligkeitsauflösung.
Dazu konnte man jederzeit, innerhalb jeder Zeile, und beliebig oft von 01/10/11 zu 00 wechseln, und damit volle 320 Pixel Details addieren, solange die 16von4096 oder 64 Farben dabei reichten. Sei das Text oder scharfe Kanten in Bildern. Das alles gab dem Amiga seine dazumals atemberaubende Graphik.
Nebenbei: Beim Xerox Alto brauchten die massiven 600x800 Pixel trotz nur 1bpp immerhin 60000Bytes von seinen 128kByte Speicher, fast 50%, und das in 1973 mit sehr teuren (64k/4k=16)*16bit = 256Chips zu je 4kx1 DRAM (die 1972 Prototypenw aren noch 1kx1 DRAMs), was bei angenommenen 256*$30 = $7680 waren, Inflation korrigiert *5 heute $38400, nur das RAM ohne Rest-Rechner! Beim IBM PC CGA, 10 Jahre später, waren es dann 640x200 1bpp = 16kByte Bildspeicher, 4 mal weniger, immer noch 8Chips an 1982 recht altem 16kx1 DRAM, mit 8*$10 = $80, korrigiert *3 heute $240.
Dabei hatte man aber früher wenig Speicher, und Programme und Daten sollten da auch noch mit hinein. Dabei ist schnell aufgefallen, dass ein einzelnes Zeichen zwar (4x8)..(8x16) an Pixel hat, und damit 4..16Bytes an Videospeicher verbraucht, trotz nur aus 64..256 Zeichen ausgewählt werden muss, wozu 6..8bit ausreichend sind, selbst mit 8x16 Pixel/Zeichen. Damit würden eigentlich ausreichen:
Der Hauptunterschied kommt von im Speicher nur noch eine Zeile Zeichencodes pro Zeichenzeile zu benutzen, statt eine Zeile Bitmapmuster pro Pixelzeile. Dabei werden die selbigen Daten für alle Pixelzeilen einer Zeichenzeile wiederholt gelesen, was Platz spart. Dazu wird zumeist anfangs erster Pixelzeile einer Zeichenzeile die aktuelle Adresse in ein Temporärregister gespeichert, und dann bei allen anderen weiteren Pixelzeilen dieser Zeichenzeile dieser Anfang wieder geholt, mit erst bei nächster Zeichenzeile nicht mehr (und gleichzeitig neu gespeichert). (Oder es werden die Zeichencodes nur einmal in einen Hilfsspeicher gelesen, und von dort mehrmals wiederholt. Dieses Vorgehen bei den Erstzeilen erzeugt genau die Badlines vom Commodore 64.)
Neben Speicher sparen ist dies auch schneller um Bild zu löschen oder scrollen, ideal bei CPU mit langsamen Kopierschleifen. Man muss auch keine Pixelmuster mehr setzen, sondern nur noch ganze Zeichen, indem man einfach direkt den Zeichencode in den Bildspeicher schreibt, ohne Bitmaps aus einer Fonttabelle zu kopieren. Die Fonttabelle im Speicher spart man sich auch noch dazu.
Dies verlangt aber nach einer Umwandlung von Zeichencode in Bitmap während das Bild dargestellt wird. Dies kann analog zu CLUTs mit einer Fonttabelle von Zeichenmustern in Hardware gemacht werden, dem Charaktergenerator (CG). Dies ist wieder ein Speicher. Dabei werden Zeichencode und Pixelzeile-im-Zeichen als Adresse benutzt, um die Pixel-der-Zeile zu bekommen. Daher brauchen sie bei 64 Zeichencodes und 8x8 Pixel ganze 64*8 = 512Bytes, oder bei 128 Zeichencodes und 8x12 Pixel 128*12 = 1.5kByte, bis zu 256 Zeichencodes und 8x16 Pixel 256*16 = 4kByte. Dies addiert sich wieder zum kleineren Bildspeicher, ersetzt auch gleich die Fonttabelle im Speicher, kostet also nicht extra, spart dort aber auch nichts mehr. (Der ganze Mechanismus erzwingt aber dass alle Zeichen gleich breit sind, erlaubt also nur Monospace Fonts, kann keine keine schmalen "i"s und breiten "m"s wie bei Proportionalfonts, welche erst mit Bitmap möglich sind.)
Dies erlaubte auch mit nichts mehr als nur CG und PISO Schieberegister verbreitern horiziontal sehr hoch aufgelöste Fonts, z.B. das VT320 Terminal mit Spezialmoni und 80x25 Zeichen mit 15x12 Pixel/Zeichen (bzw 132x25 Zeichen immer noch mit 9x12 P/Z), bei dem die recht niedrigen 25*12 = 300 Zeilen mit 80*15 = 1200 = 132*9 Pixel kompensiert werden, mit derart genau positionierten Fonts (und mit trotz Spezialmonitor 3 Pixel breiten vertikalen Strichen). (132-Spalten mit 40 Zeilen ist das normale Querformat für breite Drucker, mit dem normalen 66-Zeilen und 80 Zeichen Papierformat, aber quer/landscape statt längs/portrait eingelegt, mit den üblichen Zeichen im 6x12 Font (1/12x1/6 Zoll) halb so breit wie hoch.)
Gerade bei 256 ist aber offen was eine gute Erweiterung darstellt. Atari und Commodore haben beide einfach 128 Zeichen mit 8tes Bit für normaler und reverser Darstellung schalten genommen (Sinclair hat das bereits mit dem 7ten Bit gemacht, für 2*64 Zeichen). Andere haben weitere 128 Zeichen addiert, neben teils Graphik vor allem akzentierte Schriftzeichen (plus ein paar mehr Sonderzeichen), IBM ihr PC Codepage 437, DEC ihr VT220 Multinational Character Set (DEC-MCS), Macintosh etwas weiteres (Mac Roman), Windows ihr Win-1252, Atari ST und Amiga auch eigenes, andere ebenso, aber alle zu einander stets inkompatibel. Die ISO hat dann, nach schon 7bit mit ISO 646 standardisieren (ASCII ist nur die US Version davon, mit parallel dazu andere nationale Varianten), mit ISO 8859 auch die 8bit Erweiterung standardisiert. 8859-1 ist darin deren von DEC-MCS abgeleitete Latin-1/Westeuropa Grundvariante, mit parallel dazu weiteren Varianten. Diese ursprünglich -1/-2/-3/-4 (Westeuropa Zentral("Ost")europa Südeuropa Nordeuropa), grossteils einander überlappend. Dann erweitert mit -9/-10/-13/-14 (Türkisch Nordisch Baltisch Keltisch). Dann wurden wegen Eurozeichen noch -15/16 (Nordwest Südost) nachgeschoben. Das alles ergab (als Fortsetzung von ASCII ISO 646):
ISO 8859-1 (= Latin-1) 8bit Erweiterung
(Hex 8_ und 9_ sind weitere Steuerzeichen)
(Hex A_ bis F_ sind weitere druckbare Zeichen, = 160 bis 255)
| _0 _1 _2 _3 _4 _5 _6 _7 _8 _9 _A _B _C _D _E _F
---+---------------------------------------------------------------
|
8_ | IND NEL SSA ESA HTS HTJ VTS PLD PLU RI SS2 SS3
|
9_ | DCS PU1 PU2 STS CCH MW SPA EPA CSI ST OSC PM APC
|
A_ | NSP ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ SHY ® ¯
|
B_ | ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿
|
C_ | À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï
|
D_ | Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß
|
E_ | à á â ã ä å æ ç è é ê ë ì í î ï
|
F_ | ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ
Davon in allen 10 Latin 8859-* Varianten überlappende
8_ and 9_ sind immer identisch
A_ und B_ identisch nur A0 NSP, A7 §, AD SHY
A4 ¤ identisch in -1/-2/-3/-4 und -9/-10/-13/-14, nur Euro in -15/16
A8 ¨, B4 ´, B8 ¸ identisch in -1/-2/-3/-4
B0 ° identisch ausser in -14
B2 ², B3 ³ identisch in -1/-3/-13/-15
C_ bis F_ immer identisch sind ohne [] oder {} oder <>
mit [] = zumeist identisch
C7 Ç, E7 ç identisch ausser in -4/-10/-13
D3 Ó, F3 ó identisch ausser in -4
D4 Ô, DA Ú, F4 ô, FA ú, FF ÿ identisch ausser in -13
D7 ×, F7 ÷ identisch ausser in -10/-14/16
mit {} oder <> = in -1/-3/-4/-9/-14/-15 auch identisch
aber davon mit {} = nicht in -3, <> = nicht in -4
| _0 _1 _2 _3 _4 _5 _6 _7 _8 _9 _A _B _C _D _E _F
---+---------------------------------------------------------------
|
C_ |<À> Á Â {Ã} Ä {Å} {Æ} [Ç] <È> É <Ê> Ë <Ì> Í Î <Ï>
|
D_ | <Ñ> <Ò> [Ó] [Ô] {Õ} Ö [×] {Ø} <Ù> [Ú] <Û> Ü ß
|
E_ |<à> á â {ã} ä {å} {æ} [ç] <è> é <ê> ë <ì> í î <ï>
|
F_ | <ñ> <ò> [ó] [ô] {õ} ö [÷] {ø} <ù> [ú] <û> ü [ÿ]
8859-15 (Latin-9) sind alle C_ bis F_ identisch mit 8859-1 (Latin-1)
(es fehlen nur A4 ¤ (Euro), A6 ¦, A8 ¨, B4 ´, B8 ¸, BC ¼, BD ½, BE ¾)
Nebenbei: Bei nur 7bit mussten für akzentierte Zeichn teils der ASCII Sonderzeichen geopfert werden, nach ISO 646 davon sind 12 der Zeichen ersetzen erlaubt (genauer die # $ @ [ \ ] ^ ` { | } ~). Davon wurde # nur durch £ (GB FR IT), sowie $ nur durch ¤ (HU FI SE) ersetzt, womit noch 10 verbleiben. Dies reichte nur für wenige akzentierte Schriftzeichen bekommen, pro Land einen eigenen Satz, und diese zumeist aus Platzmangel mit anderen Sätzen inkompatibel. Selbst in mehreren Sätzen vorhandene Zeichen sich nicht immer am gleichen Ort. erst recht wenn diese noch nachträglich erweitert wurden (hier mit [] gekennzeichnet). Bei Französisch und Italienisch reicht es sogar nur für die Kleinbuchstaben. Das alles ergab:
ISO 646 7bit 12 ersetzbare Stellen
Position | 23 24 | 40 | 5B 5C 5D 5E | 60 | 7B 7C 7D 7E
---------+--------+----+----------------+----+---------------
| | | | |
ASCII | # $ | @ | [ \ ] ^ | ` | { | } ~
| | | | |
---------+--------+----+----------------+----+---------------
| | | | |
DE | | § | Ä Ö Ü | | ä ö ü ß
| | | | |
HU | ¤ | Á | É Ö Ü ? | á | é ö ü ?
| | | | |
FI,SE | ¤ |[É] | Ä Ö Å [Ü] |[é] | ä ö å [ü]
| | | | |
DK,NO | |[Ä] | Æ Ø Å [Ü] |[ä] | æ ø å [ü]
| | | | |
FR | £ | à | ° ç § | µ | é ù è ¨
| | | | |
IT | £ | § | ° ç é | ù | à ò è ì
(Erst mit obigem 8bit gab es volles ASCII plus viele nationale Varianten gleichzeitig. Das mit allen 8 ersetzten deutschen Zeichen in allen Latin-* Varianten drin, weil der deutsche Sprachraum in Mitteleuropa liegt.)
Nebenbei: Solches 8bit erlaubte auch neben dem lateinischen Alphabet erweitern andere Schriftsysteme zu unterstützen. Einerseits das russische KOI-8 für Kyrillisch. Oder das japanische JIS-0201 für Katakana. Die ISO 8859 standardisierte auch 8859-5 Kyrillisch und 8859-6 Arabisch und 8859-7 Griechisch und 8859-8 Hebräisch, sowie später -11 Thai, aber -12 Devanagari wurde aufgegeben. (Bei nur 7bit mussten dazu die lateinischen Kleinbuchstaben geopfert werden, für nur kyrillische (in KOI-7) oder griechische Grossbuchstaben bekommen. Mit 8bit gibt es hier volles ASCII grosse und kleine von Latein plus den Anderen ihre grosse und kleine alles gleichzeitig.)
Alternative zu ROM und fest gegeben ist RAM und damit ladbar/anpassbar. Ein solcher RAM CG ist aber teurer pro Bit. Er ist auch aufwendiger, weil CGs im Auslesemodus nicht mit dem Prozessor verbunden sind, hier also ein Umschaltmechanismus für deren Adressen und Daten hin muss, um den Font zu laden. Dieser muss auch wie beim DMA Zugriff auf den Videospeicher derart benutzt werden, dass keine Konflikte entstehen.
Solches RAM muss auch anfangs von einem ROM geladen werden. Dort wird aber um Platz zu sparen vielleicht mit komprimierten Daten gearbeitet, z.B. die bei vielen Zeichen vorhandenen Leerzeilen und Leerspalten ihre Pixel weglassen. Dies kann optimiert werden, durch die wenigen Zeichen mit Unterlängen ohne abzuspeichern, und diese als Additionen separat halten. Ebenso akzententierte Zeichen als Kopien der Basiszeichen mit Modifikatoren. (DEC VT220 und VT320 Terminals haben solche komprimierte ROMs und nach Entkomprimierung noch RAM Platz für bis zu 96 Zeichenmuster hinzuladbar, und anstelle des DEC-MCS aktivierbar. HP 71B Taschencomputer LCDs haben neben reinem ASCII bis zu 128 Zeichenmuster hinzuladbar.)
Alternativ zu RAM wurden teils austauschbare ROMs benutzt (Atari VCS und Nintendo NES, ihre ROM Programmmodule hatten stets auch die zum Spiel passenden Graphikelement Fonts darin). Oder man nimmt ROM/(Haupt-)RAM umschaltbar (Atari 800, Commodore VC20 und 64, PC EGA/etc) was aber im Haupt-RAM den Prozessor weiter ausbremsen kann (die C64 Badlines kommen genau daher) und noch mehr Aufwand ist. Oder teils-teils ROM+RAM gemischt (Hitachi HD44780U und kompatible LCD Controller).
Dabei kann man oft nicht nur den Font erweitern (bei ROM+RAM), sondern auch komplett ersetzen (bei immer RAM oder ROM durch RAM ersetzbar oder bei ROM Modulen strecken). Damit kann man dann Graphiken aus speziell dafür designten Elementen/Kacheln zusammensetzten, was als Cellgraphik bekannt ist, weil RAM (oder Modul-ROM) CGs "Zeichen" mit (fast) beliebigen passenden Formen/Pixelmuster erzeugen können. Dies war die Basis der meisten schnellen Spiele, weil es flexible Graphik mit schnellem Scrollen verband (auch der Pacman Automat verwendet dies, wie ein Bug beim Wechseln von Level 255 zu 256 aufzeigt). Aber auch Darstellungen von Gleisanlagen für Eisenbahnsteuerung oder Chemieanlagen für Prozesssteuerungen oder Wetterkarten kann man auf diese Art machen (und wurde für Wetterkarten bereits bei mechanischen Fernschreibern mit Austausch des "Finger" Zeichensatzes gemacht).
Selbst pixelweises verschieben von Elementen ist dabei möglich, indem man ein Graphikelement in ein paar wenige als "Mini-Bitmap" verwendete Kacheln verschoben hineinrendert. (Die SoftVGA verwendet genau einen solchen RAM CG, mit Zeichen 32..126 ASCII, 127 unbenutzbar, und 0..31 für Kacheln benutzbar (mit Farbwechselcodes und Blockgraphikzeichen vorbesetzt), von denen im Demo ein 3x3 Block für den animierten Ball rendern benutzt wurde.)
Normalerweise sind Charaktergeneratoren immer 1bpp, für nur 2 Farben (Vordergrund und Hintergrund). Aber gerade bei Spielen ist auch hier 2bpp mit einer halbierten horizontalen Fontauflösung nützlich, für 4 Farben (3 Vordergrund), wie bei den Atari 800 sowie Commodore VC-20 und 64 ihren Multicolor Modi.
Eine andere Methode ist neben dem Zeichencode für jedes Zeichen noch weitere Bits zu speichern, welche das Bild wie es vom ROM (oder RAM) CG kommt zu modifizieren. Diese sind als Attributbits bekannt. Verschiedene Effekte die man mit Attributbits auslösen kann sind:
PCs kennen an Attributen gerade einmal beide Farben 2*(RGB+I)=8bit, mit den beiden I Bits umnutzbar für Unterstreichen bzw Blinken, bzw ab EGA als weitere Zeichencodebits. Die DEC VT220 und VT320 Terminals waren hier weit fähiger, fast alle obigen Attribute, insbesondere auch strecken (aber vertikal nur pro ganze Zeile, nicht pro einzelnes Zeichen einstellbar). Der rein schwarzweisse Zeichenmodus des Apple II konnte sogar nur reverse und blinkend.
Bei 64 Zeichen oder 128 Zeichen ROMs werden ohnehin nur 6bit bzw 7bit als Zeichencode benutzt. Damit sind 2bit bzw 1bit unbenutzt und als Attributbits kostenlos vorhanden. Diese werden beim MC6847 Chip für seine 1+1+6bit als Modusschalter+Revers+64Zeichen benutzt, oder bei Atari 800 und Commodore 8bit ihre 1+7bit als Revers+128Zeichen (bei Atari 800 ein 128 Zeichen Font plus Bit7 Reversierhardware, bei Commodore 8bit stets 256 Zeichen Font mit Defaultfont 128 Zeichen und reversen Bitmustern), oder beim Apple II seine 1+1+6bit als 128Zeichen Normal plus je 64 Zeichen Reversiert bzw Blinkend.
Bei 1+7bit kann man auch 128 Zeichen und trotzdem 7 Attribute haben, falls 0..127 ein Zeichen mit den selbigen Attributen wie dem davor darstellt, und 128..255 ein Leerzeichen und 7bit Attributwechsel erzeugt. Was aber etwas limitierte Darstellung ergibt, insbesondere bei Satzzeichen ohne Leerzeichen nach einem speziell attributiertem Wort mit betroffen. (Die SoftVGA benutzt dies um die CLUT Farben in einer Zeile zu ändern.)
Bei 256 Zeichen werden normalerweise weitere Bits benötigt, wozu man entweder einen parallelen zweiten Attributspeicher braucht (z.B. Commodore 64), oder in einem Speicher abwechselnd Zeichen und Attribute hat (IBM PC alle Videokarten). Parallel kann nur 4bit (Commodore 64, mit nur Vordergrundfarbe ausser mit revers) oder voll 8bit (diverse) sein, was 12bit oder gar 16bit Speicher ergibt, mit mehr Bandbreite. Abwechselnd sind stets die selbigen 8 Bits gegeben wie bei den 256 Zeichen ihren Codes (PC alle, mit je 4bit Vordergrundfarbe und Hintergrundfarbe aber je 1 Bit für unterstrichen und blinkend abzweigbar), und kann als 8bit oder 16bit Speicher gebaut werden.
Alternativ werden ohne weiteren Speicher die obersten Bits des ohnehin vorhandenen Zeichencodes doppelt benutzt, umschaltbar um entweder mehr Zeichen oder um Attribute zu haben. Der Atari 800 hat dies, Font auf 64 Zeichen reduzierend plus dann Bit6+7 für 4 Vordergrundfarben. Die TMS9918 haben dieses, mit Bits 3..7 als Auswahl von 32 Vordergrundfarben (für je 8 Zeichencodes eine), mit stets 256 Zeichen, im sogenannten "Graphic 1" RAM CG Modus.
Einerseits gibt es Strichgraphik. Diese besteht darin, 16 Zeichen zu belegen mit einem Punkt in der Mitte, und dazu noch selektiv 4 von diesem in alle Richtungen links/rechts/auf/ab bis zum Zeichenrand gehende Striche. Damit entstehen 2^4 = 16 Kombinationen. Davon sind "0 Striche" und "nur 1 Strich" nicht wertvoll, womit 16-1-4 = 11 verbleiben, 2 durchgehende Linien, 4 Ecken, 4 T-Stücke und 1 Kreuz. Die Atari und Commodore 8bit Rechner hatten dieses.
Reicht dies nicht, kann man es auch mit Doppellinen oder Breitlinien wiederholen (nochmals 11), sowie Ein-plus-Doppel/Breit Kombinationen (2 2D/B+2E Kreuzungen, 4 2D/B+1E T-Stücke, und vielleicht noch 4 3D/B+1E Kreuzungen, oder gar 4 2D/B+2E Ecke+Ecke). Auch weitere Zeichen mit gerundeten oder abgeschnittenen/45grad Ecken passen hierher. Die IBM PC Karten haben dieses in der Doppellinen Form.
Anderseits gibt es Blockgraphik. Diese besteht darin, 16 oder 64 oder gar 256 Zeichen zu belegen mit 2^4 bzw 2^6 bzw 2^8 Kombinationen von 2x2=4 bzw 2x3=6 bzw 2x4=8 Feldern/Blöcken. Bei 32x24 und 40x25 Zeichen ist 2x2 ausreichend, weil dies etwa quadratische Blöcke ergibt (und 64x48 bzw 80x50 Graphik). Bei 32x16 ist 2x3 passender um quadratische Blöcke zu bekommen (und ebenfalls 64x48 Graphik). Bei 64x16 oder 80x25 sollte man 2x4 haben (und bekommt immerhin eine recht passable 128x64 oder gar 160x100 Graphik davon). (Z.B. sind beim MC6847 Chip seine 1+1+6bit als Modusschalter+Revers+64Zeichen bzw 1+3+4 als Modusschalter+8Vordergrundfarben+16Blöcke2x2, bei 32x16 Zeichen damit nur schwache 64x32 Blockgraphik.)
Die 16 2x2 Blockgraphikzeichen sind wie obige 16 Strichgraphikzeichen kein Problem. Beide 2*16 passen sogar zusammen mit den 95 ASCII Zeichen gerade noch in 128. Auch die 64 2x3 Blockgraphikzeichen passen mit 95 ASCII und 16 Strichgraphik und einiges anderes problemlos in 256. (Der Tandy TRS-80 hat seine 64 2x3 Blockgraphik Zeichen einfach als Codes 128..191 (binär 10xxxxxx), was mit seinen 64x16 Zeichen für 128x48 Blöcke ausreichte. Ebenso kann dies der Galaksija, ein Yugoslavischer erweiterter ZX80/ZX81 Clone, den ich verdächtige 64 ASCII + 64 Blockgraphik in 128 Zeichen zu haben.) Oder sie passen gar als 2*32 aufgeteilt als 32 mit den 95 ASCII in ein 2*(32+95), mit 1 revers Attributbit freibleibend. (Die Atari 800 und Commodore PET bis C64 und Sinclair ZX80/ZX81 hatten alle für ihre 16 2x2 Zeichen auch nur derartige 2*8 der Kombinationen mit 8 in ihren 2*128 bzw 2*64 Zeichen, und benutzten revers für die anderen 8.)
Nur passen keine 256 2x4 Blockzeichen zusammen mit allen anderen Zeichen in 256 Zeichen. Das galt daher lange als unmöglich, trotz gerade bei einer 80x25 Maschine sehr erwünscht sein (mit resultierenden 160x100). Der IBM PC hat daher nur 1x2er Blockgraphik, ganze 4 Zeichen (strikte hat es nur 2 Zeichen, Leerzeichen und halb/halb, sowie reverse davon), und ist damit wieder auf schwache 80x50 limitiert. Besser machte dies der Kaypro, welcher 128 Zeichen mit dem halben 2x4er Satz belegte, und dann für die anderen 128 Zeichen das separate revers Attributbit als "neuntes" ausnutzte.
Reicht dies nicht, kann man es auch mit 50% gerasterten Blöcken wiederholen (sowie halb-halb horizontal und vertikal gemischt schwarz und gerastert, mit revers als weiss und gerastert nutzbar). Ebenso passen hierher 4 dreieckige Halbblöcke (mit revers nur 2 Zeichen).
Weiterhin gibt es Balkengraphik, welche aus 2 Sätzen von Zeichen besteht, welche in vertikaler bzw horizontaler Richtung von 0 bis n Pixel in kleinen Schritten gehen, aber in der anderen Richtung immer alle Pixel haben. Damit kann man in der Balken Längsrichtung/Datenrichtung mit maximal 1 Pixel Genauigkeit zeichnen, solange die Balkenbreite einfach n Zeichen (Positionen oder Zeilen) ist. Das braucht, neben 0=Leerzeichen, und n/2=Halbblockzeichen und n=Vollblockzeichen in beide Fontdimensionen weitere n-2 Teilzeichen, also bei 4x8 Font (4-2)+(8-2) = 8 Zeichen, bei 8x8 Font (8-2)+(8-2) = 12 Zeichen, bei 8x16 Font (8-2)+(16-2) = 20 Zeichen. Wieder kann man das revers Attributbit ausnutzen, um nur die halbe Menge Teilzeichen zu brauchen. Sind das immer noch zuviel kann man auch nur 0,1/4,1/2,3/4,1 anbieten, wobei 0,1/2,1 bereits in der Blockgraphik vorhanden sind, nur noch 1/4 und 3/4 beider Richtungen gebraucht werden.
Logischerweise verkomplizieren und verlangsamen solche nichtlinearen Anordnungen die Berechnungen der Adressen um Pixel anzusprechen. Bei Apple II, Amstrad/Schneider CPC und IBM CGA bleibt die X Rechnung normal, aber die Y Rechnung muss einerseits durch 8 bzw 2 geteilt werden und anderseits der Rest AND 7 bzw 1 und dann mit 1024 bzw 2048 bzw 8192 multipliziert und addiert werden. Beim Commodore 64 und 9918A muss die Division bei X durch AND mit 256-8=248 ersetzt werden, und Y einerseits AND 7 (innerhalb 8-Zeilen Band) und anderseits durch 8 (Bandnummer) dann mal 320 bzw 256 (Bytes in Band). Daher wird hier erst recht zu Tabellen gegriffen in denen die Adressen vorausgerechnet abgespeichert werden.
Dazu hat es einen mehrteiligen Videocontroller, der nur eine Zeitsteuerung hat, aber zwei Bildspeicher (Bitmap und Zeichen+Font) und ihre jeweiligen Adresses und Schieberegistern. Sowie zwischen diesen und dem Digital/Analog Wandler eine Schaltung welche die beiden Videosignale kombiniert:
Ein Nebeneffekt aller solcher Systeme ist, dass die Zeichenanzeige ihren Speicher normal scrollen kann, während die Bitmapanzeige ihr Speicher stehen bleibt, wie es bei einem heutigen Fenster auf Vollbild gestellt und mit durchsichtigem Hintergrund und einem Desktopbild dahinter aussieht.
Selbst bei manchen Workstations mit viel Speicher für Bitmaps mit Auflösung und viel Bits/Pixel wurden Overlays teilweise beibehalten. Dies zumeist als ein gross-Bitmap für Graphik, und ein klein-Bitmap für Zeichen. Gerade bei Systemen welche Planes verwenden waren dies oft ein grosser und ein kleiner Planesatz gleicher Auflösung. Diese benutzen zwar keinen Charaktergenerator, aber erlauben wenigstens noch schnelleres Scrollen von Text weil weniger Speicher umkopiert werden muss, sowie Scrollen ohne die Graphik zu verschieben.
Die Antwort dazu sind Sprites, kleine zusätzliche Bitmap Graphiken welche nachträglich während der Bildausgabe zum Monitor in das normale Bild eingeblendet werden, quasi eine Art von mini-Overlays. Dies geschieht gerade bevor die Farbbits in den Digital/Analog Wandler gehen. Sprites haben dazu jede ihren eigenen Musterspeicher (mit hoher Auflösung), ihre eigene Farbe (oder gar mehrere), und eine frei wählbare Einblendposition (welche mit wenig Aufwand verschoben werden kann, zumeist nur mit einem Koordinatenregister modifizieren), sowie ein paar Modusbits.
Weil während einer Zeile zeichnen der Speicher ohnehin bereits vom Videocontroller ausgelastet ist, und anderseits 1/5 der Zeit im Rücklauf dieser nichts mit dem Speicher macht, werden die Sprite Musterspeicher während dem Rücklauf ausgelesen. Das limitert deren Menge/Zeile. Dazu kommt, dass Sprites als Einblendungen auch ausserhalb des normalen Text Rechteckes angezeigt werden können, also in den ganzen 51.2us der Bildzeile, womit nur die 64-51.2 = 12.8us zum Laden verbleiben, was die Anzahl Sprites weiter limitiert (beim C64 auf 8*3Bytes, in 12us mit 2MHz geladen), ausser man achtet darauf welche Sprites wann geladen werden, und welche Positionen diese zulassen (was 64-40 = 24us Ladezeit erlaubt).
Nachdem die Sprites geladen sind, in eigene Schieberegister, können diese in der Zeile zu jedem beliebigen Zeitpunkt "losgelassen" werden, sobald der Pixelzähler ihre X Koordinate erreicht (dazu ist pro Bit ein XOR nötig um zu vergleichen und ein NOR um alle Bits auf "gleich" (XOR=0) zu einem "start" zu sammeln), vorausgesetzt sie sind eingeschaltet (per separates Einschalt Modusbit oder einfach per X in/aus dem gültigen Bereich liegend). Dabei gilt bei 1bpp Sprites stets 1=Spritefarbe und 0=durchsichtig, wobei letzteres das normale Vordergrund/Hintergrund Gemisch darstellen lässt ist. Dies alles ist als Spritegenerator bekannt.
Für mehrere Farben in einem Element gibt es mehrere Methoden. Am einfachsten ist pro Element mehrere Sprites mit verschiedenen Farben welche synchron bewegt werden (wie beim Atari VCS und 800 sowie TMS9918 Chip basierte als einziges möglich), was aber linear mehr Sprites pro Farbe kostet. Oder man kann mehrere Bits mergen, was mit 2bit ausgewertet als 1,2,3=Spritefarben und 0=durchsichtig dann 3 statt 2 Farben erlaubt, ohne 3bit Verbrauch. Dies kann man entweder analog zu 2bpp machen, mit halbierter Zahl doppelbreiter Pixel (wie beim Commodore 64), oder analog zu Bitplanes mit 2 Sprites kombinieren (wie beim Amiga).
Bedingt durch die dazu verwendeten Sprite/durchsichtig Schaltungen, und deren Reihenfolge im Signalpfad, haben Sprites eine Priorität, wenn mehrere an den gleichen Ort sich überdecken. Manche Systeme erlauben es auch, Sprites vor den Hintergrund aber hinter dem Vordergrund dazwischen zu schieben, wieder mit einem Modusbit dazu, was letztlich auf eine recht aufwendigere Einblendschaltung hinausläuft. Manche Systeme können auch Spritekollisionen (beide wollen das gleiche Pixel haben) erkennen, und der Software per Flag setzen melden (dieses wird vor Bild zeichnen gelöscht und nach Bild zeichnen überprüft).
Ein Sprite kann mehrere Zeilen haben, welche es ab einer per Y Koordinate spezifizierten Bildzeile dann ausgibt. Manche Systeme sparen sich aber diese Logik ein:
Bei Bitmapmodus reicht das bereits, aber bei Zeichenmodus ist dies auch vertikal ein Problem, was mit einer weiteren Verschiebbarkeit lösbar ist. Nur ist sind es hier die Zeitpunkte von erste Zeile zeichnen relativ zum Vertikalpuls. Auch auf nicht-Spiel Terminals wird dies zum Teil als nur-vertikal angeboten, als Softscroll (z.B. in den VT220 und VT320). Hier zeigten die TMS9918 ihre Schwäche, kein derartiger Modus, mit im erweiterten Yamaha 9938 nur vertikal für Terminals addiert, und erst im 9958 auch horizontal, als diese Chipfamilie lägst am Ende war.
Ein Problem ist aber noch, dass dabei das Spielfeld und dessen Bildrand "mitscrollt" und zurückspringt wenn dann der Speicher Byteweise umkopiert wird und der Pixelzähler auf den Anfangswert kommt. Daher wird zusätzlich das sichtbare Feld um eine Spalte oder Zeile Text reduziert, indem der Bildrand beidseitig für eine halbe (oder gar ganze) Zeichenbreite (bzw Höhe) leer gelassen wird. Dies mit in Software dort keine Pixel aktivieren, bzw sogar in Hardware mit an den Rändern ausblenden (bzw hinter der Randfarbe "versteckt"), womit während dem Zeichnen die erste und letzte Textspalte/-Zeile nur teils dargestellt wird, und das sichtbare Bildrechteck stabil am Ort bleibt. (Das ergab z.B. beim Commodore 64 die bekannte Reduktion von 40 auf 38 Zeichen Breite, bzw von 25 auf 24 Zeilen.)
Der Amiga bot hier das ultimative an scrollbaren Bildinhalt an: Ein Modus mit 2 mal 3 Planes, als zwei separate Vollbilder, mit einem "hinten" mit 8 Farben, und einem "vorne"/"overlay" mit 7 weiteren Farben und 0=Durchsichtigkeit. Letzteres war mit separat scrollen als ein "Monstersprite" verschiebbar. Dies ist ideal für schneller horizontal scrollenden nahen Vordergrund, als pseudo-3D, was als Parallaxscrollen bekannt ist. (Die normalen Sprites konnten auch eingestellt werden, dass sie hinter dem Hintergrund (nur bei Pixel=0 sichtbar) oder zwischen dem "hinten" und "vorne" Hindergrund oder ganz vorne priorisiert werden, was wiederum ideal für Horizontalscroller Spiele war.)
In all diesen Fällen ist wieder der Prozessor mit umkopieren gefordert, und damit einerseits die Menge welche er zeichnen kann beschränkt, und anderseits die für das eigentliche Program verbleibende Rechenleistung reduziert. Auch dies ist ein Problem für das ein spezieller Koprozessor designt worden ist um Bildteile umzukopieren, der Blitter, dessen Name von BLIT kommt (kurz für BLock Image Transfer). Bereits die Xerox Alto (dessen Erbauer den Namen BLIT definierten) hatte einen halben Blitter (ein Spezialmodus im Prozessor seinem Mikrocode). Aber wirklich bekannt wurden Blitter erst mit dem Amiga, den ich hier nun teilweise beschreibe.
Der Blitter kann bis zu 3 Quellblöcke (A B und C) Daten nehmen, sie mit einander beliebig kombinieren, und dann in einen vierten Zielblock (D) schreiben, der wiederum mit den Quellen überlappen kann (oder gar mit einem identisch sein, um diesen zu modifizieren). Dabei werden jeweils 1 Bit aller 3 Quellen als 3bit Index in eine vom Programm gegebene 8x1bit Funktionstabelle mit 1 Resultatbit genommen (auch eine Art von Look Up Table, als 3LUT bekannt). Dies wird für parallel für alle 16 Bits der Speicherworte gemacht, 16*3bit zu 16*1bit. Danach wird das ausgewählte 16bit Resultat geschrieben. Die Videoausgabe hat beim Speicherzugriff stets Vorrang vor dem Blitter, dieser aber wiederum einstellbaren Vorrang vor dem Prozessor. Weil der Amiga mit Bitplanes arbeitet, mit fest 1bpp, muss die Operation für alle Planes wiederholt werden.
Daher sind stets 16 Pixel von 16bit betroffen. Da aber die Blöcke nicht in 16-Pixel Gruppen synchron zu einander liegen müssen, kann für jedes der 16 Quellen zuerst ein "voraus" 16bit Wort gesetzt werden, und dann bei jedem "normalen" Wort die voraus16+normal16 = 32bit Kombination um 0..15bit verschoben werden, und dann 16bit genutzt und der Rest als neuer "Voraus" aufbewahrt werden. Für konstante Daten kann auch der "Voraus" gesetzt werden, mit 0 Verschiebung, und dann das "normale" Laden abgeschalten werden, z.B. weil ein festes Pixelmuster verwendet werden soll.
Weil auch der Zielblock nicht genau auf 16er Pixel liegen muss, können für das linke und rechte Wort einer Serie nur 1..16bits verändert werden, bzw 0..15 unverändert gelassen werden (das nennt man ausmaskiert). Die ganze Operation kann für 1..n Worte in einer Zeile ablaufen (mit bei nur 1 Wort mit links und rechts makieren in diesem einen Wort).
Diese Zeile von n Worten wird dann gefolgt von alle 4 Blockadressen um Worte/(Block-)Zeile - n erhöhen, womit alle auf ihre nächste Zeile ihrem Anfang zeigen, und damit 2D Operationen automatisch sind. Dies wiederholt sich so oft wie in einem Zeilenzähler verlangt wurde (der nach jeder Zeile -1 rechnet, bis 0 erreicht wird und Abbruch auslöst).
Typische Operationen sind:
Auch hier ist der Versager PC komplett im Abseits gewesen, sowohl CGA wie auch EGA/VGA/etc. Erst um 1990 erschinen Videokarten mit sogenannten "Videobeschleunigern" (später nach dem Erscheinen von 3D Beschleunigern und Videobeschleunigern in 2D Beschleuniger umbenamst), welche nichts anderes als simple Blittersubsets waren, welche nur genau obige paar wenigen Operationen können, mit einer Quelle, plus feste Farbe, und dem Ziel, als die 3 Bits des 3LUT Tabellenindexes. (Anderseits kam bereits der Ur-PC mit dem REP MOVSB Befehl der 8088 recht weit, welcher bei 4.77MHz mit /8= 590kByte/s umkopieren/scrollen kann, die 16k einer CGA in nur 27ms, zumindest solange nur auf 8bit ausgerichtet kopiert wurde.) (Ebenso haben sämtliche Z80 Rechner ihren LDIR Befehl, welcher bei 4MHz mit /20= 200kByte/s umkopieren/scrollen kann, die 16k einer Amstrad/Schneider CPC in 82ms, aber bei der KC-85/4 ihren 1.79MHz und 2*10=20k schon sehr merkbare 230ms braucht.)
Dazu muss der Prozessor vorzu die aktuelle Bildzeile im Auge behalten, um in 64us Genauigkeit aktiv werden zu können. Wozu der Videocontroller deren Nummer auslesbar anbieten muss (und auch alle manipulierbaren Videodaten). Dazu muss aber das ganze Program um dies steuern herum aufgebaut/geschrieben werden, was mühsam und fehleranfällig ist.
Beim Atari VCS ist das die einzige Methode überhaupt Bitmapzeilen oder Spritezeilen von der vorherigen Zeile verschieden zu machen, weil dessen Hardware nur interne Register darstellt, alles Speicher zu Register laden vom Prozessor kommen muss, weil keien DMA Hardware im TIA Chip. Weshalb dort alle Programme fast komplett aus einer Bildzeilenfolge erzeugen bestehen, andere Aktionen nur während dem (Bild-)Rücklauf. Aber Spiele sind in der Hinsicht recht tolerant, andere Programme nicht so sehr.
Eine Erweiterung besteht darin, im Videocontroller die aktuelle Pixelzeile mit einer Zielzeile zu vergleichen, und wenn diese erreicht wird einen Interrupt auszulösen, was als Rasterinterrupt bekannt ist, wie dies z.B. in Commodore 64 bekannt ist. Dies ist eine Erweiterung vom Vertikalblankinterrupt, an beliebiger Zeile, ohne gleich zum belastenden Horizontalrücklaufinterrupt zu greifen. Dies erlaubt es, Aktionen in einer Serviceroutine zu erledigen, ohne das restliche Program danach ausrichten zu müssen. Was auch benutzt wird um mehr Sprites zu haben, durch nach Benutzung umkonfigurieren. Aber der Prozessorverbrauch bleibt, und wird wegen dem Interrupt Overhead sogar etwas grösser.
Die Alternative dazu gab es im Atari 800, in Form der Displayliste. Diese wird vom Videochip im Horizontalrücklauf gelesen, wie die Sprites. Sie kann direkt automatisch manche Sachen einstellen, insbesondere auch die ganzen Videomodi Zeichen vs Bitmap und Auflösung vs bpp vs Speichermenge umschalten. Ebenso kann sie die Speicheradressen für das weitere Bild umschalten für Scrollen. Ebenso das Bild aus diversen Bändern zusammensetzen (Menu/Inhalt/Fusszeilen), sowie zeilenweise festlegen ob sie pixelweise gescrollt wird oder nicht (Inhalt ja, Menu+Fuss nicht). Zudem kann diese zeilenwiese festlegen ob ein Rasterinterrupt erzeugt wird, für alles andere was die CPU braucht, inklusive wieder die Sprites umkonfigurieren.
Noch weiter geht es dann im Amiga, mit dem Copper Koprozessor. Dieser ist nicht unähnlich dem Imlac PDS-1 seinem Vektor-Charaktergenerator. Er besteht einfach aus WAIT (= warte bis Pixel X von Zeile Y) und SKIP (= lasse nächsten Befehl aus falls Pixel X von Zeile Y schon vorbei ist) sowie MOVE (= schreibe Adresse A mit Daten D) Befehlen. Mit diesen können auf Mikrosekunden synchron beliebige Moduswechsel oder CLUT Farbwechsel oder Adressen umstellen oder was auch immer gemacht werden, solange der dazu zu modifizierende Videogenerator status als Register im modifizierbaren Adressbereich auftritt. Selbst seine eigenen Steuerregister kann er auf diese Art mit MOVE modifizieren, bis hin zu zwei Programmzählern haben und mit anderen setzen dann auf diesen umschalten Programmsprünge zu machen. Um all dies zu benutzen wird dem Copper ein eigenes Program gegeben, was als dessen Displayliste bekannt ist. Damit können auch hier Sprites ohne Software beliebig oft umkonfiguriert werden, wobei einfach Serien von Sprites nutzen bereits automatisch vom Spritegenerator selber gemacht wird.
Einen Spezialfall davon kannte der 16bit Xerox Alto, weil er seine ganze Videoausgabe in Mikrocode implementierte, und darin neben 1bpp Zeilenbändern mit Bildinhalt auch explizite 0bpp Leerzeilenbänder kannte, welche nur alle Pixel in Hintergrundfarbe darstellten (kein nachladen des Schieberegisters), und damit gar keinen Speicher für ihre Pixelmuster benutzten (und keine Prozessorleistung zur ihrer Ausgabe). Das ergab bei einer Textdarstellung mit "7..10 von 12" Zeilen Font immerhin 5..2 von 12 Zeilen Speichereinsparung, was 41.6..16.6% sind, und bei 60000Bytes Vollbild immerhin 25000...10000Bytes spart, was neben den anderen 128k-60000 = 71072Bytes immerhin 35..14% mehr an nutzbaren Speicher ergab.
Auch die ZX80 und ZX81, mit ihrem Zeichnen direkt per CPU als DMA per Befehle holen, können Zeilen auslassen. Dies indem sie einfach passende Befehle (alles mit Bit7=1) als Ende anschauen, und dann nicht mehr weiter zeichnen. Das ergibt variabel lange Zeilen, bis zu auch als minimalen Fall mit Länge = 0. Auch können beliebige andere Befehle danach am Ende angehängt werden. Dies erst recht beim ZX81, wo der Zeichenvorgang ohnehin per NMI Interrupt angeworfen wird.
Dieses hätte bereits zur 16bit Zeit zum Standard werden können, parallel zu per 8086/8088 Segmentregistern oder 68000 Indexadressmodus mehrere Programme im Speicher halten und adressieren können, auch deren Ausgaben auf die Bildfläche verteilen, seien dies Filemanager und Benutzerprogramm, oder diese und Popups/TSRs. Dies erst recht zumal damals auch gerade Portraitmonitore machbar wurden, welche mit doppelter Zeilenzahl mehr Fläche dafür boten. All das ohne die massive prozessorkillende Ausschnittrechnerei (Clipping) von GUIs, welche den Ur-Macintosh (und andere ihn kopierende 16bit GUI Rechner) derart langsam machten.
Selbst der Amiga wurde, trotz seiner Displaylisten, auf diese Art ausgebremst, durch einer fensterbasierten GUI statt einem zu seiner Hardware passenden bandbasierten Aufteilung. Zudem wurden alle Programme dadurch in eine feste Auflösung und bpp gezwungen, mit für 4bpp/16Farben ohne Prozessor ausbremsen nur 320x200, was für eine GUI zuwenig war, und das ausgerechnet auf dem Rechner mit der stärksten Graphik. (Dies alles ist besonders eklatant wenn man bedenkt, dass bereits der Apple II einen primitiven Bandmodus namens "Split Screen" hatte, mit oben 20/24 im Bitmapmodus und unten die restlichen 4/24 im Zeichenmodus angezeigt.)
Mit aufwendigerer Umschaltung, pixelsynchron innerhalb einer Zeile, kann man sogar richtige Fenster in Hardware machen, welche alle auf diese Art vom Speicher geholt/gesammelt und ausgegeben werden können. Dies erlaubt auch Fenster innerhalb von Fenstern, und damit beliebige Ausschnitte mit vielen Farben aber niedriger Aufösung, und darum herum viel mehr Auflösung aber weniger Farben. All dies erlaubt Auschnitte ihre Auflösung/Farben zu varieren ohne einen speziellen HAM Modus zu brauchen und dessen 2bit 00 oder 01/10/11 Umschalter in jedem Pixel (und wegen 6oder8bpp nur 320 statt 640 Pixel/Zeile Modus als Vorbedingung zu verlangen). Das erlaubt sogar beliebige Bitmapfelder und darum herum speichersparenden Zeichenmodus oder gar speicherlose Leerzeilen mit 0bpp Modus, nur horizontale Striche mit fester (Hintergrund-)Farbe.
Ebenso erlaubt es mit geeigneten Displaylisten für jedes Fenster beliebige Ausschnitte ihre Speicheradressen umstellen. Dies erlaubt in jedem davon einen nichtlinearen Bildspeicher zu haben, wieder (Soft-)Scrollen superschnell per umschalten statt per Blitter oder gar Prozessor umkopieren. Damit kann man auch schnell Ausschnitte scrollen und trotzdem den aufwendigen (Hardware und Benutzung) Blitter ganz weglassen.
Das erlaubt auch Fensterrahman, aus pro Seite einem kleinen/schmalen Fenster zusammengesetzt, Seiten gleich hoch wie das Fenster, oben/unten so breit wie Fenster+Seiten mit den Bitmaps aller Fenster ihrer Rahmen aus einem einzigen Satz von 4 maximal langen 1oder2bpp Rändern (strikte wären sogar speicherlose 0bpp Fensterränder möglich mit nur fester (Rand-)Farbe).
Dies geht bis zu Ausschnitte/Fenster um Videos abspielen, mit zur Darstellzeit automatisch in Hardware auf die Pixelbreite und Zeilenhöhe skalieren, statt mit dem Prozessor zur Decodierzeit. Ebenso mit einem geeignetem Videogenerator Modus von Speicherplatz sparendem YUV zu RGB zur Darstellzeit in Hardware umrechnen.
Die Bildspeicherteile diverser Programmes können auch auf deren 4kByte Pages der Speicherverwaltung ausgerichtet werden, und deren PMMU geeignet konfiguriert werden, um sie den jeweiligen Programmen direkt zugäglich zu machen. Die Programme könnten dann ihre jeweiligen Fenster direkt bearbeiten, in ihrem bevorzugten Modus, ohne deren Position auf dem Bildschirm zu kennen, mit nur der Höhe und Breite varierend (und vom System teils nicht ausgegeben oder mit Neutral-/Hintergrund-/Randfarbe gefüllt).
Dies hätte alles bereits zu der Zeit der ersten Generation 32bit zum Standard werden können, parallel zu per PMMUs mehrere Programme im Speicher verteilen, auch mehrere Fenster auf die Bildfläche aufteilen. Dies erst recht zumal damals auch gerade 17..21" Doppelseitenmonitore machbar wurden, welche auch horizontal mehreren Fenstern Fläche boten. Diese Rechner hatten auch genug Prozessor für GUIs (was 16bit Rechner auch ohne Ausschnittrechnerei nicht wirklich hatten). Leider kann nicht einmal der Amiga so etwas, weil 16bit Generation und auf 32bit nur leicht erweitert!
Auch Sprites lassen sich hiermit verbessern. Entweder kann man mit genug Bandbreite 2 Fenster ihre Daten parallel laden, analog zu Overlays und Parallaxscrolling, das Spritefenster vielleicht nur mit wenigen bpp, und dieses mit 0=durchsichtig vor das andere setzen. Oder aber man lädt weiterhin während dem Rücklauf, aber mit von der Displayliste gesteuerter variabler Menge an Pixeln zusammensammeln, um danach nur noch einen normalen Spritegenerator mit dieser Menge ablaufen lassen.
Wen wundert es, dass der Versager PC bis heute null Ansätze in diese Richtung zeigt. Ausser einer sehr seltenen späte-1980er Spezialgraphikkarte namens Tektite, welche volle Fenster in Hardware anbot, aber wegen geringer Verbreitung von Windows zu früh kam. Im Zeitalter heutiger "dichter" virtualisierender Multitasking Kernels und MByte tiefem Treibersumpf und Libraryschichten (oder gar Displayserver) zwischen Benutzer und Hardware ist wohl kaum mit Besserung zu rechnen. Das obwohl es direkt in den Bildspeicher schreiben wieder ermöglichen würde, immer noch 100% sicher, aber trotzdem ohne Umweg durch Kernel und Treiber und Libraries, mit weit geringerer Prozessorlast. (Wozu wurden schon wieder die viele-milliarden-teuren Chipfabriken gebaut, um 100-Millionen Transistor Chips zu bauen, damit wir GHz Multicore MByte Mehrfachcache Prozessoren haben können? Ah, stimmt, um ihre Rechenleistung mit Bloatware zu verheizen.) (Wobei die Linux Welt in Form des Wayland Projektes (als Ersatz von X Displayserver) auf dem Weg dazu ist, via dem 3D Beschleuniger seinem Videotexturen Skalierer solches Fenster Compositing zu bekommen.)
Alles kein Problem auf einem Schreibtisch, aber in einem portablem Gerät ist hierfür zumeist kein Platz. Daher blieben diese lange bei Lampen oder LEDs oder VFDs. Aber auch diese brauchen einiges an Strom, und damit Batterie Volumen und Gewicht. Als Alternative schlechthin dazu verbreiteten sich die Flüssigkristall Anzeigen (Liquid Crystal Displays, LCDs), welche heute dominieren, und auch CRT Bildschirme vom Schreibtisch verdrängen.
Die Innenseite der beiden Glasplatten sind mit zwei Mustern aus durchsichtigen Leitern beschichtet (soweit mir bekannt Zinnoxid), die analog zu Platinen durch beschichten und ätzen hergestellt werden. Die Kreuzungspunkte dieser Leiterschichten können benutzt werden um die Flüssigkeit dazwischen mit einem elektrischen Feld zu ordnen. Strikte sind sie daher Kondensatoren, mit der Flüssigkeit als Dielektrikum. Dazu müssen diese Leiterschichten auch ausserhalb der Abstandshalter herausragen, und dort via Gummistreifen mit dünnen querverlaufenden Drähten darin zu einer unterliegenden elektrischen Platine verbunden werden.
Die Flüssigkeit kann, je nach ob im elektrostatischen Feld, das durchgehende Licht in seiner Polarisierungsrichtung beeinflussen (was diese zu nematischen Flüssigkeiten macht), und diese wenden (twist) oder eben nicht. Daher nennt man solche Anzeigen genauer Twisted Nematic (TN) LCDs.
Daher hat es ausserhalb der beiden Glasplatten auch noch zwei Polarisierungsfilter. Mit Filter-Glas-ohneFelddreh-Glas-Filter ist das ganze durchsichtig, F-G-mitFelddreh-G-F dagegen undurchsichtig. Kombiniert man das alles mit einem Reflektor zwischen hinterem Glas+Filter und der Platine (zumeist hellgrau, teils nur bedruckter Karton, selbstklebend auf der Platine drauf), entsteht eine Anzeige welche entweder durchsichtig-Reflektion-durchsichtig = hellgrau oder mit undurchsichtig = dunkelgrau darstellen kann. Dazu kommt ein Metallrahmen um alle Schichten zusammenzuhalten. Das ist die normale kleine graue LCD wie man sie in jedem Taschenrechner oder auch von vielen Druckeranzeigepannels oder Haushaltsgeräten kennt.
Die Alternative besteht darin, einen der Filter um 90grad zu kehren, womit es ohne Feld undurchsichtig/dunkel wird, und mit Felddrehung durchsichtig/hell machen. Diese Variante wird zumeist ohne Reflektor benutzt (weil es zuwenig Licht dafür durchlässt), mit stattdessen einer Leuchtschicht dahinter, zumeist ein Lichtstreuer, der mit zwei FL Röhren links/rechts (die kurzen Kanten) beleuchtet wird, oder aber mit mehreren LEDs von allen Seiten. Das ergibt die ganzen "selbstleuchtenden" LCDs, wie man sie in Laptops oder Smartphones/Tabletts oder LCD Monitoren oder LCD Fernsehern kennt.
Farbige LCDs brauchen drei mal mehr Spalten, mit je einem R G und B Subpixel pro Pixelposition. Diese drei Subpixel haben jeweils noch eine transparente Farbschicht darauf, welche nur R G oder B durchlässt, wenn dieses Subpixel aktiv ist. Manche Hersteller geben die Subpixel Anzahl als "volle" Pixelzahl an, falls sie für jedes Subpixel die Daten anpassen (wenn auch davon nur 1/3 sichtbar wird). Das ergibt eine Darstellung analog zum Amiga HAM Modus seiner mehr Helligkeit und 1/3 Farben Auflösung, weshalb das gerade bei Digicam (und Smartphone) Anzeigen beliebt ist (bei letzteren aber bei Schrift dann versagt).
Genau diese FL Röhre und Farbfilter Anordnung machte LCDs so lange für Photo/Video unattraktiv, wegen den flauen Farben, dwelche von den FL Röhren ihren nur teilweisen Lichtspektrum her kommen. Mit separaten RGB LEDs kann kann dies komplett behoben werden. Aber mit den häufigeren billigeren weissen LEDs bleibt das Farbproblem weiterhin bestehen, wenn auch inzwischen geringer.
Varierende Helligkeit (und bei RGB Farbtöne) kann nur gemacht werden, indem die (Sub-)Pixel nur einen Teil der Zeit offen sind. Genau dieses ist schwierig richtig hinbekommen, was so lange LCDs für Gamer (und Video) problematisch machte.
Im Gegensatz zu LEDs, welche als Dioden Strom nur in einer Richtung durchlassen (und damit problemlos multiplexbar sind), sind LCDs technisch Kondensatoren, welche dann eine Serieschaltung bilden. Im Gegensatz zu bei Lampen ist im Glas auch kein Platz um separate Dioden einzubauen. Noch problematischer wird es, dass ein LCD nicht einfach Dauerspannung erträgt, daher muss der Strom gepulst werden, und das erst noch abwechselnd positiv und negativ, also generierte Wechselspannung.
Zum Glück hat die Flüssigkeit eine gewisse Resistenz gegen Felder, und wird erst darüber beeinflusst. Damit kann man die Anzeige mit 4 Spannungen fahren, heute oft 0.0, 1.1, 2.2, 3.3V. Dabei wird die aktive Zeile mit 0.0V und alle inaktivem mit 2.2V, sowie aktive Spalten mit 3.3V und inaktive mit 1.1V gefahren. Damit haben aktive Pixel 3.3V, inaktive auf der aktiven Zeile 1.1V, und alle Pixel auf anderen Zeilen 1.1V bzw -1.1V. Mit der Grenze bei 2.2V liegend erscheinen so nur die aktiven Pixel. Das alles muss danach mit reversen Spannungen wiederholt werden, also Zeilen aktiv 3.3V und inaktiv 1.1V, Spalten aktiv 0.0V und inaktiv 2.2V, und damit aktive Pixel -3.3V und inaktive -1.1V bzw 1.1V.
Dies alles muss der LCD Controller liefern, mit zumeist nur wenigen Zeilen (um jede möglichst lange zu beliefern) und vielen Spalten (um doch zu vielen Pixeln zu kommen), was Treiberchips mit vielen Anschlüssen braucht. Hinter jeder Spaltenleitung sitzen pro Spalte/Zeile ein Speicherbit, bei kleineren LCD Controllern gleich im Treiberchip darin. Diese werden abwechselnd auf die Spaltenleitung geschaltet, parallel zu den Zeilenleitungen aktivieren. Weil dies viele Pins braucht, sind die Controller oft über mehrere Chips verteilt. Dabei teilen sie sich teils auch die Zeilenleitungen treiben auf.
Eine Alternative sind die ganzen Aktivmatrix LCDs, in denen bei jedem Pixel ein Speichertransistor auf dem Glas aufgedampft werden muss, mit einer aufwendigeren Leitungsführung. Dies erlaubt erst viele Zeilen, weil mehr als 1/Zeilenzahl Zeit ein Feld da ist. Hierbei werden zeilenwiese die Speichertransistoren "updatet". Die vielen Transistoren erzeugen bei Herstellfehler "fest" ausgeschaltete/tote oder noch schlimmer eingeschaltete/dauerleuchtende Defektpixel wo diese kaputt sind, und bedingten früher viele als defekt weggeworfene Exemplare und machten diese Displays daher so lange teuer, und Laptops infolge auch (und hielten Desktop LCD Monitore so lange zurück, neben den Farbproblemen).
Beispiel eines Kleincontrollers hat der HP 41C Taschenrechner: 12 Positionen zu je 14-Segment + 3-Punkt/Komma/Doppel + 1 Statussymbol = 12*(14+3+1=18) = 216 Segmente, angesteuert als 3 Zeilen zu je 72 Spalten, von 2 Chips zu je 36 Spalten, mit eingebautem Font ROM (ASCII 32..95 plus Erweiterungen), sowie Bildspeicher RAM je Chip 6 Zeichen zu je 7bit (weil Erweiter-ASCII) und 2bit aus/Punkt/Komma/Doppelpunkt (kein Strichpunkt!) und 1bit Status.
Grösser ist der Hitachi HD44780U: 2*40 (geplante Originalanordnung) oder 4*20 (heute häufigste Anordnung) oder 1*80 oder 8*10 (beide sehr selten) Positionen Text, zu je 5x8 (bzw 5x10) Pixel, angeordnet als 2*8 = 16 Zeilen zu je 8*5 = 40 Spalten, womit ein Einzelchip für 2*8 oder 1*16 reicht, mehr mit separaten speicherlosen Decodererweiterungschips. Eingebautes 208 Zeichen zu 5x8 (plus 32 Zeichen zu 5x10) an Font ROM (in 2 Standardausgaben, "A00FS" mit JIS-0201 (beinahe-ASCII + Katakana japanische Zeichen) und "A02FS" mit ISO 8859-1 (ASCII + Latin-1/Westeuropa Zeichen)), plus weitere 8 Zeichen zu 5x8 (bzw 4 Zeichen zu 5x10) von Font RAM, plus achte/zehnte Zeile als Unterstrich addierbar, sowie Bildspeicher RAM (2*40=80)*(7+1=8) = 640bit.
Graphisch wird es mit dem Epson SED1520 (und kompatible AX6120 oder PT6520): 122x32 Pixel Graphik, angeordnet als 32 Zeilen zu je 122 Spalten (gibt Platz für 4x20 Zeichen in 6x8 Font), wobei ein Einzelchip für 16 Z und 61 S reicht, 2 davon für 2*16=32Z und 2*61=122S (das ist vermutlich was im Epson HX-20 darin ist), danach erweiterbar in 80 Spalten Gruppen mit SED1521/AX6121/PT6521, alles ohne Font ROM, nur ein Bitmap Bildspeicher RAM zu je 61 Spalten (+ n mal 80 Spalten) zu je 4*8bit, Font muss der Prozessor bzw seine Software liefern.
Heute gibt es das alles auch bei Mikrocontrollern mit on-chip LCD Controller. Dies z.B. Atmel AVR ATmega329/649 bzw 3290/6490 Serie: 4 Zeilen * 25 Spalten = 100 Segmente (9er Modelle) oder 4 * 40 = 160 (90er Modelle), wieder ohne Font ROM (dazu ist das Program im AVR da, mit Font in desse nProgramm ROM), nur Bitmap Bildspeicher RAM 4*(5*8) = 160bit. Oder z.B. dessen grossen ARM Prozessor basierten Bruder AT91SAM7L128: 10 Zeilen * 40 Spalten = 400 Segmente, wieder ohne Font ROM, Bildspeicher RAM 400bit.
Alle diese Controller haben interne Bildspeicher, in die ein Program einfach Zeichencodes bzw Bitmaps hineinschreibt, wie bei den Bildschirmen ihren Bildspeichern. Wobei die HP und Hitachi Zeichencodes brauchen, wie bei Zeichenmodus Video. Die Epson brauchen Bitmap Bytes als vertikale 8 Pixel Streifen (wie bei 8pin Nadeldruckern) mit Bit0 oben (statt horizontal wie bei Bildschirmen), dann alle 61 Bytes einer Schriftzeile/Pixelband, dann die Bytes weiterer Zeilen/Bänder (wieder wie bei Nadeldruckern). Die AVR haben horizontale Anordnung mit 3.125 bzw 5 Bytes/Zeile.
Die ganzen "grossen" Laptop/Monitor/Fernseher LCDs, mit ihren 100en oder gar 1000en Zeilen und noch (viel) mehr Spalten verwenden viele Decoderchips, mit nur wenigen Speicherbits darin (zumeist nur zwei Zeilen), weil sie ihre Daten analog zu CRT Bildschirmen von einem externen Videocontroller zeilenweise angeliefert bekommen, und nur eine Zeile anzeigen während sie die nächte empfangen, und danach die beiden Speicher austauschen. Dementsprechend werden sie genauso wie Bildschirme benutzt. Irgendwann wurde dann die zu CRT VGA kompatible Signalisierung mit Digital/Analog - Leitung - Analog/Digital wegoptimiert und durch direkte digital Signale ersetzt. Seither haben wir das ganze Durcheinander mit alle paar Jahre neuen Videostecker (LVDS/DVI/HDMI/Displayport/etc).
Strikte könnte man gerade beim Fernseher/Videomonitor, mit nur seinem Bildzeile/Hsync/Vsync Signalgemisch, und nur einem simplen Koax Kabel dafür nötig, den Benutzern einfach je einen blanken Monitor ohne jegliche Digitalelektronik hinstellen (sowie eine Tastatur, z.B. mit einem separatem 3-Draht Signal+0V+5V Kabel, bzw 4-Draht mit separate Daten+Clock Signalen), und den/die ganzen Videocontroller (und auch Tastaturinterfaces) beim Rechner lassen, mit deren Speicher wie bisher im direkten Prozessorzugriff. Das bräuchte nur diese zwei langen Kabel dazwischen, welche nicht viel aufwendiger wären als die doppelten (weil bidirektionalen) Twistedpairs für einen Fernschreiber oder 3+ Drähte für ein RS232 Terminal.
Man bräuchte im Controller zwar pro Benutzer einen Datenpfad, bestehend aus Bildspeicher und Schieberegister und Analogelektronik und Ausgang zu Kabel+Monitor (und vielleicht noch dazwischen einen Charaktergenerator, sowie allfällig Cursorposition Register), aber könnte anderseits die ganze Zeitgenerierung nur einmal vorsehen (und abgeleitet davon auch die Adressgenerierung für die Speicher). Auch der Zugriff vom Prozessor auf die Bildspeicher (und die Prozessor oder Videocontroller DMA Steuerlogik) braucht es nur einmal (und falls mit Zeichenmodus allfällige von ASCII Steuerzeichen getriebene Cursor Positionssteuerung). Auch braucht es nur einen Bildspeicher an Adressraum (aber dafür einem Umschalter welcher Benutzer/Monitor sein Speicher gerade damit bearbeitet wird), sofern nicht mit nur einem Datenausgabe Register (und dahinter ASCII auswerten um (Cursor-)Adressen zu generieren). (Ideal wird es, wenn dieser Speicherauswahlschalter parallel zum Timesharing Prozesswechsel geschaltet wird, und das gerade laufende Programm stets den Bildspeicher vom seinem Bildschirm sieht und direkt bearbeiten kann, wieder ohne Multitasking Kernel und Treibersumpf und Libraryschichten im Weg.)
Das Augment Projekt vom Stanford Research Institute hat bereits in 1968(!) fast das gemacht, sogar ohne Videocontroller. Sie hatten einen CDC 160A Minirechner mit mehreren Oszilloskopen direkt daneben als Anzeigen, und auf diese wiederum normale schwarzweiss Videokameras zeigend, und dann deren Signale zu den Videomonitoren beim Benutzer herausgeführt. (Sie haben auch anfangs 1970er(!) als Eingabe die Maus erfunden.)
DEC offerierte anfangs 1970er zum PDP-8/E Minirechner auch einen VT8-E Videogenerator (plus Tastatur und Drucker und damit teuer), mit umschaltbar Zeichenmodus 20 Zeilen zu 32 oder 64 64-ASCII Zeichen sowie Bitmapmodus 200 Zeilen von 189 Pixel, diese auch auf abwechsenden Frames darstellbar als Pseudo-Overlay. Dies kostete aber (20*32|64=640|1280)*12bit bzw (200*12=3200)*12bit vom nur 4069*12bit Hauptspeicher (kein TMS9918-artiger oder PC-artiger separater Adressraum), und bremste die CPU um 25% aus (wie bei Homecomputern ohne separaten Videospeicher). Vor allem aber war es nicht kompatibel mit den normalen Fernschreibern oder dem LA30 DECwriter Druckerterminal oder einem RS232 Interface zum VT05 Videoterminal (oder auch nur zu einem RT01 12*7-Seg ASCII Nixie bzw RT02 32*64-ASCII VFD), mangels einem Datenregister+ASCII Ansatz im Zeichenmodus (was im VT05 aber schon drin war). Womit die meiste Software davon keinen Gebrauch machen konnte (daher auch der eingebaute DECwriter-artige Drucker, und damit alles teurer als nur ein DECWriter alleine). Daher konnte es auch nur mit seltener Spezialsoftware als "Zusatz" laufen, wie auch beim VR14 Oszilloskop mit VC8-E Controller, welche aber zudem wenigstens keinen Speicher verbrauchten, und erst noch 1024x1024 schafften, aber dafür die CPU während dem anzeigen voll auslasteten, und damit max 1500 gesetze Pixel erlaubten statt beliebige der 189x200=37800, und Speicher für dieses Programm brauchten.
Vermutlich wegen all diesen Problemen (und geringer Anzahl davon verkauft) haben sie für dessen Nachfolger PDP-11 gar kein direktes Video mehr angeboten. Dieser konnte nur RS232 zu Terminals, oder ein VR14 Oszilloskop ansteuern mit dem VT11 (bzw erweitert VT40) Controller. Erst anfangs 1980er gab es wieder Video, für die Pro350 von 1982 mit PDP-11/23 Prozessor (aber komplett inkompatibler IO), sowie für die MicroVAX, mit dem VCB02 Bitmap Controller, als diese zur VAXstation Workstation erweitert wurde. Aber das war bereits zu spät gegen die Mikros und zu teuer gegen die PCs, weil auf Workstations zielend.
Das entstehende Loch wurde dann von anderen teilweise gefüllt, in der Form von Bildschirmterminals, wie obige VT Terminals. Letztlich erscheinen diese als abgewandelte Fernschreiber (minus Drucker plus Bildschirm), aber ansonsten die selbige RS232+Tastatur+Ausgabe+Controller Idee, leicht modifiziert. Bei jedem Gerät alles pro Benutzer dupliziert, plus die RS232 Übermittlichg dazu, und damit unnötig teuer, und damit den ganzen anzezielten Preisvorteil von Timesharing eines Minis ad absurdum führend.
Im Minimalfall konnte deren eingebaute Controller nicht viel mehr als bei einem Fernschreiber, was diese zu gläsernen Fernschreibern machte. Wenigstens waren sie damit papierlos und lärmlos und abnutzungsfrei sowie zumeist etwas schneller, zumindest sofern dem Rechner seine seriellen Schnittstellen dabei mitmachten. Real waren Fernschreiber 110bit/s, mit Schnittstellen um 1965 maximal 300bit/s, 1970 max 1200bit/s, 1975 max 2400bit/s, 1980 max 9600bit/s, 1985 max 19200bit/s, 1990 max 38400bit/s zu erwarten. Also im Vergleich zu MByte/s an Speicherzugriffen um 1980 sowie MHz Videosignalen bereits seit den 1930er Fernsehern schlicht steinlangsam.
Die auf Fernschreiber ausgelegten Rechner und deren Systemsoftware wussten aber nichts davon, rechneten einfach mit ASCII Zeichen und CR/LF/etc ausgeben können. Also mussten die Terminal Hersteller innerhalb dieses vorgegebenen Gerüstes eine Speicherbearbeitung steuern "nachflicken". Diese bestand anfangs aus dem (Miss-/Ge-)brauch der ASCII 0..31 Steuerzeichen, und später Escapesequenzen (welche mit ASCII 27 (Escape,ESC)) anfangen.
Bereits als Teil des minimalen Controllers war es notwendig eine Cursorposition zu speichern, in Form einer Speicheradresse, und bei jedem ankommenden Zeichen es in diese Adresse schreiben und den Cursor nach rechts zu bewegen, also die Adresse +1 zu rechnen. 13,CarriageReturn,CR musste die Adresse wieder auf die Adresse des ersten Zeichens der Zeile setzen, und 10,LineFeed,LF eine Zeile Länge dazu addieren (ausser man war in der untersten Zeile und fiel bei LF unten zum Speicher hinaus, dann war statt dessen scrollen angesagt, wie es ein Drucker mit seinem Vorschub immer macht, weil dort der "Cursor" (bzw Druckkopf) immer auf der "untersten" Zeile ist).
Bald hat man gemerkt, dass abwärts,10,Linefeed,LF,Ctrl-J und links,8,Backspace,BS,Ctrl-H gerade neben einander auf den Tasten liegen, und dass 11,Ctrl-K,VerticalTab,VT als aufwärts recht gut passt, und 12,Ctrl-L,FormFeed,FF entbehrlich ist (es hat kein Papier zum auswerfen, das Zeichen wurde aber teils als Bildschirm löschen missbraucht), womit dort 4 Zeichencodes <-/v/^/-> lagen, welche man benutzen kann um den Cursor beliebig zu bewegen. Schnell wurde auch gemerkt, dass man mit <- + Space + <- ein bereits ausgegebenes Zeichen löschen kann, wozu manche Terminals dann kompakter das ASCII 127,Delete,DEL reinterpretierten von "Deleted" zu "Delete".
Leider haben jede Menge Hersteller andere Kombinationen genommen. Manche haben ASCII 8,Backspace,BS als obigen Löschcode benutzt. Aber auch mit 127,Delete,DEL hatte ein DEC VT05 von 1970 z.B. 8,Backspace,BS als links aber dann 8+16=24 als rechts (das lies 12,FF,Formfeed frei, welches aber für nichts benutzt wurde, Bild löschen war hier 31), und verwendete dann statt 10,Linefeed,LF das 11,VerticalTab,VT als abwärts, hatte aber 10+16=26 als aufwäts. Konfus.
Danach hat man gemerkt, dass dies viele links/rechts Zeichen ergibt, was bei langsamen 300..1200bit/s Leitungen (30..120Zeichen/s) lange dauert. Da ein CR ein "ganz-links" abgibt, war dann schnell nach rechts kommen wichtig. 9,HorizontalTab,HT konnte dies 8 aufs mal. Noch besser war aber ein ein "n nach rechts", oder besser gleich ein direktes "gehe zu X = n". Letzteres wurde im VT05 dann mit 27,Escape,ESC gefolgt von Werte 32/Space..103/g für Spalte 1..72 gemacht (das VT05 hatte 72x20 = 1440 Zeichen, von der 72 Zeichen Breite von Fernschreibern her).
Die DEC VT50 von 1974 (= gleiches Jahr wie 8080 und 6800) und VT52 von 1975 (= gleiches Jahr wie 6502 (und ein Jahr vor Z80), MK4069 4kx1 DRAMs gibt es auch schon ein Jahr, sowie den MITS Altair 8800 (und ein Jahr vor Apple 1)) hatten einen kleinen aus TTL Chips zusammengesetzten bitseriellen Prozessor, der generell 27,Escape,ESC gefolgt von Buchstaben als Befehle erwartete, beim VT52 waren diese:
Leider waren auch solche Codes alles andere als standardisiert, wenn auch einige andere Terminals das VT52 kopierten (z.B. dem Atari ST sein TOS System seine Bildschirmausgabe) oder als Alternativmodus anboten (z.B. DEC ihre VT100 und spätere).
Die VT55 ist eine VT52 mit einem auf Kurvengraphen basierten Pseudographik Overlay addiert.
Die VT78 von 1977 ist eine VT52 mit eingebautem Mikroprozesser (Intersil 6100) basierten beinahe-PDP-8 Rechner und RX02 2*8" Floppy daneben, als eine Art von Mikrocomputer, für Textverarbeitung gedacht trotz nur mit Textmodus via den VT52 Escapesequenzen (keine VT8-EE drin).
Die DEC VT100 von 1978 (zwei Jahre nach Z80 und CP/M (und eines nach 8085), 8086 ist frisch draussen, ein Jahr nach Apple II und Commodore PET und Tandy TRS-80, bzw ein Jahr vor Atari 800, MK4116 16kx1 DRAMs sind seit 2 Jahren vorhanden) verwendete dann sogar einen 8080 um die endlich halbwegs standardisierten (und dabei auch ziemlich komplex gewordenen) ANSI Escapesequenzen (und einige eigene Erweiterungen dazu) zu verwerten (und der MS-DOS ANSI.SYS implementierte etwas halbwegs dazu kompatibles, vermutlich ohne/teils der DEC Erweiterungen):
Die VT105 ist eine VT100 mit VT55-artiger Pseudographik addiert. Die VT125 dagegen ist eine VT100 mit echter Bitmapgraphik addiert, mit einer (nur-Vektor) Graphikfähigkeit namens ReGIS (Remote Graphic Instruction Set) und einem per Escapesequenz ESC-P-p aktivierten Spezialmodus dafür, der dann Buchstaben als Kommandos benutzte wie beim Tektronix 4014.
Die DECmate (bzw VT278) von 1980 ist eine VT100 mit einer VT78-artigen beinahe-PDP-8 drin. Die VT103 dagegen ist eine VT100 mit eingebautem Q-Bus und LSI-11 4-Chip Mikroprozessor basierten vollen PDP-11/03. Die VT180 wiederum ist eine VT100 mit einem Z80 Rechner drin, mitsammt CP/M darauf, und damit ein ganz normaler terminalbasierter Mikrocomputer. Alle haben wie die VT78 nur Textmodus via den VT100 Escapesequenzen.
Die DEC VT220 von 1983 (bereits neuer als ein Commodore 64 und IBM PC/XT! und 64kx1 DRAMs sind bereits 2 Jahre vorhanden) wechselte dann zu einem 8051 als Prozessor, mit "erweiterten" ANSI Escapesequenzen (eigentlich mit mehr nicht-ANSI addiert), wie ESC-P-parameter-{-daten...-ESC-/ um Softfonts mit Daten im Sixel Format in eine RAM CG zu laden. Auch kam hier endlich 8bit RS232. Das erlaubte den DEC-MCS 8bit Zeichensatz mit seinen Zeichen 161..254. (Dessen 128..159 und 160 bzw 255 wurden absichtlich freigelassen damit ein 8bit zu 7bit Bitverlust eines kopierten Textfiles kein Zeichen in ein 0..31 oder 32 oder 127 Steuerzeichen bzw Space verwandelt.) Ebenfalls erlaubte es im freigehaltenen 128..159 Bereich weitere Steuerzeichen. Vor allem dem Zeichen CSI 91-64+128=155 (Hex 5B-40+80=9B) als kürzerer Ersatz für die ANSI Escape-[ 27 und 91 (Hex 1B und 5B), und genereller mehrerer -64+128 Kombinationen wie DCS 80-64+128=144 (Hex 50-40+80=90) statt Escape-P.
Die VT240 (schwarzweiss Bitmap) und VT241 (farbig Bitmap) haben wieder echter Bitmapgraphik, analog zum VT125, aber wieder nur-Vektor mit ReGIS, mit zusätzlich zu ESC-P-p auch DCS-p.
Die DEC VT320 von 1987 (inzwischen neuer als Macintosch und IBM PC/AT und Atari ST und Amiga, gleiches Jahr wie 386er, 256kx1 und 64kx4 DRAMs sind normal) benutzte eine 8051 als Prozessor, aber addierte lediglich noch eine 25ste Zeile sowie den ISO 8859-1 (= Latin-1) 8bit Zeichensatz neben DEC-MCS.
Die VT330 (schwarzweiss Bitmap) und 340 (farbig Bitmap) addierten endlich direkte Sixel Bitmaps mit ESC-P-parameter-q-daten...-ESC-/.
Die DEC VT420 von 1990 (das ist sogar neuer als 486er und 68040er, gleiches Jahr wie Windows 3.0, 1Mx1 und 256x4 DRAMs sind normal) addierte dann noch einen 80x50 Zeichenmodus, sowie eine zweite RS232 Schnittstelle um zwei Logins gleichzeitig zu benutzen, sowie Umschaltsequenzen um eine RS232 Leitungen zwischen mehreren Logins zu teilen..
Wie man sieht war der Fortschritt hier weitaus langsamer als bei den Mikros und PCs ihren direkt benutzbaren Videocontrollern. Aber trotzdem brachte jedes dieser kleinen Upgrades neben dem stets unvermeidlichen neuen erweiterten Videocontroller und dessen neuen Prozessor (und neuer Software dazu) auch einiges an vermeidbarem Aufwand. Immerhin mussten dabei auch der Monitor, der Lautsprecher, die Tastatur, das Netzteil und das Gehäuse mit ersetzt werden. Diese waren zumindest bei VT05 zu VT52 zu VT100 etwa gleichwertig (alles standard schwarzweiss NTSC Videomonitore). Oder gar komplett identisch innerhalb einer Familie bei VT50 (Grossschrift) zu VT52 (Gross/Klein) zu VT55 (plus Pseudographikoverlay) oder bei VT100 (80x24 und 132x14 erweiterbar auf 132x24) zu VT101 (nicht erweiterbar) zu VT102 (immer erweitert) zu VT105 (plus Pseudographikoverlay) zu VT125 (plus Bitmapgraphikoverlay).
Mit einem separaten Monitor und Tastatur, sowie einem Videocontroller direkt beim Minirechner mit Software auf dessen CPU, wäre dazu nur ein Videocontroller Ersatz (oder innerhalb einer Familie gar nur Erweiterung anhängen) oder teils sogar nur ein Softwareupgrade (für neue Escapesequenzen) nötig gewesen, wie das bei PCs jeweils auch gemacht wurde. Dazu käme auch die Möglichkeit den Rechnerspeicher als Scrollback Buffer zu nutzen, bis hin zu virtuellen Terminals für n Logins und Taskswitching, was alles in PCs bereits in den 1980ern erschien, z.B. unter Xenix. (Selbst allen Benutzern als Basis den Zeichenmodus zu geben, und jeweils einem Benutzer in einer Gruppe einen geteilten Graphikoverlay als ERweiterung anbieten wäre damit möglich gewesen.)
Bereits für die PDP-4/7/9/15 18bit Rechnerserie (ab erster Hälfte 1960er) hatte DEC die PDP-5 geschaffen (Mitte 1960er), als kleinen 12bit Hilfsrechner um jedem Benutzer eine eigene Oszilloskopanzeige zu zeichnen. Prompt wurde dieser von einigen als alleinigen Rechner benutzt. Dieser wurde deswegen zur PDP-8 optimiert, mit 2..3 mal schneller bei unter 10% Mehraufwand (mit Programmzähler als Register statt Speicherwort 0), sowie mehr adressierbarem Speicher (8 schaltbare 12bit/4k Speicherfelder). (Der 8er wurde in dieser speichererweiterten Form prompt wieder mit Timesharing aufgeteilt, mit pro Benutzer ein Speicherfeld, wieder mit Fernschreibern bzw mit VT05 Terminals.) (Auch die PDP-11 wurde wurde auf diese Art als Hilfsrechner benutzt, als GT40 Verktorgraphik Terminal von 1972, welches aber nur eine PDP-11/05 mit 4|8k Speicher und VT40 Controller mit VR14 Oszilloskop war, als Konkurrent der Imlac PDS-1. Wie diese und der PDP-5 wurde sie auch als alleinigen Rechner benutzt.)
Auch der Datapoint 2200 in 1970 (identisch mit dem Erscheinen der VT05!) war ein prozessorbasiertes Terminal mit einem bitseriellen 8bit Prozessor (vergleichbar wie beim späteren VT50/52!), aber mit 4|8kByte Speicher aus 512bit MOS Schieberegistern gemacht (und damit frei programmierbar wie eine PDP-5/8). Auch diese wurde prompt von manchen als alleinigen Rechner benutzt. Aus einem Versuch der Kostenreduktion der 2200 entstand der Auftrag an Intel, aus dem der 8008 Prozessor 1972 entstand, welche danach erweitert zur 8080 in 1974 und dann Z80 in 1976 wurde, was später zur 8086/8088 und folgenden führte. Damit entstand die Basis der Mikrocomputer und der PC Revolution, welche dann den Untergang der Minirechner und deren Timesharing und Terminals erzeugte.
Addiert man zu obigen Darstellungslimiten und dieser Kostenrechnung noch die Langsamkeit von RS232, von 110bit/s (= 10Zeichen/s bei 11bit/Zeichen, = 8Sekunden pro 80 Zeichen Zeile!) bis 38400bit/s (= ganze 3840Zeichen/s bei 10bit/Zeichen, = über halbe Sekunde um ein 80x25=2000 Zeichen Bild zu füllen!), und man sieht warum niemand mehr Mini+Terminal haben wollte nachdem die Mikros und PCs erschienen.
Die Benutzerausgabe derart zu vernachlässigen wurde damit für die Minirechner ihren kommerziellen Fortbestand tödlich, und in Folge davon auch für ihre Terminals, deren Prozessoren aber wenigstens teils zu PCs evolvierten. Damit haben die erwachsen gewordenen Terminals ihre eigenen Minirechner terminiert, als Aufstand der Sklaven.
Der Gipfel davon war wohl der 2*Z80 Rechner auf dem ich programmieren gelernt habe, ein Columbia Commander. Eine Haupt-Z80 mit 64k RAM und 2 160k Floppys und mehrere externe PIO und RS232, sowie ein internes RS232 an eine Terminal-Z80 mit 32k(!) eigenem RAM und einer MC6845 welche aus den zweiten 16k ein 512x256 1bpp Bitmap Bild erzeugte, welches für etwa 80x24 Zeichen mit 6x10 Font ausgenutzt wurde. Auf der Haupt-Z80 lief das USCD p-System, mit Editor und Pascal Compiler, erweiterbar mit einem Assembler. Ungewöhnlich an diesem war, dass man mit einer Escapesequenz eigenen Code in den Rest-Speicher der Terminal-Z80 ablegen konnte (dabei einen beim Aufstarten/Reset hingeschriebenen RET(urn) Befehl überschreibend). Mit einer leeren Taste (zwischen Pfeil-links und Pfeil-auf) konnte dieses Program (oder das Return) aufgerufen werden. Bei Absturz der Terminal-Z80 konnte man diese mit einer weiteren leeren Taste (zwischen Pfeil-auf und Pfeil-rechts) teil-rebooten (vermutlich per NMI Interrupt), wobei das 16k Schriftbild aus einem 2k Textbuffer (ein Teil der ersten 16k) wieder aufgebaut wurde. Das war geeignet um mit obigem Assembler (welcher die Escapesequenzen in seinem Ausgabefile gleich mit einbaute) und eigenen Terminalprogrammen die langsame RS232 und die limitierten Terminalgraphik Escapesequenzen zu umgehen. Das ergab sogar mit Terminalprogram plus Hauptrechnereditor eine primitive Form von 2-Prozessor basierten 2-Task Switching, mit Terminal Benutzerprogram und Hauptprozessor Editor laufend.
Ein Beispiel ist der Acorn BBC, bei dem aber auch zusätzlich das Basic leicht erweitert wurde, mit dem VDU Befehl, der aber nur eine Liste von Ausdrücken mit Resultatwerten 0..255 erwartete, welche als einzelne Zeichen ausgegeben wurden, statt Escapesequenzen mit aufwendigem und langsamen "string"+CHR$(Audruck)+... zusammenbauen zu müssen.
Manche haben diesen Ansatz simpel gemacht, mit nur einem minimalen VT05-artigen ASCII 0..31 (und 128..159) Befehlsatz im Treiber. Einer davon der Commodore 64 auf/ab/rechts/links als 145/17/157/29, Cursor home als 19, Bild löschen als 147, Zeichen löschen als 20, revers Attribut ein/aus als 18/146, sowie 2*8 Werte für die 16 Schriftfarben hatte. Auch die KC-85/2 /3 und /4 haben diesen Ansatz genommen.
Manche machten etwas mehr. Einer davon der Atari ST mit einer VT52 Escape Sequenzen Emulation. Manche noch einiges mehr, bis zu vollem ANSI bzw gar VT100. Einer davon war Xenix (und als Folge davon auch die Linux Console).
Manche machten auch gar nichts, aber mit etwas nachladbar. Einer davon ist MS-DOS im IBM PC, mit dessen CON: als BIOS basiertem reinem gläsernen Fernschreiber, aber ANSI.SYS nachladbar. Letzteres wundert nicht, da MS-DOS als CP/M Clone auch mit Terminals laufen kann, und IBM bei seinem Bildschirmtreiber (im IO.SYS welches einfach das BIOS benutzt) genauso geschlampt hat wie beim BIOS selber (und der Hardware), und Microsoft dann als Erweiterung/Reparatur ANSI.SYS nachgeschoben hat.
Dies machte als bekanntes Beispiel der Acorn BBC (mit dem PIO Interface als "Tube" bezeichnet, mit einer zweiten 2MHz 6502 oder einer Z80 oder gar einer 32016, und später auch einen ARM anbietend). Ebenso die KC-85/2 /3 und /4, deren CP/M Erweiterung dies machte, mit einer zweiten schnelleren Z80/U880 (welche aber auch selber die Disks ansteuert, der Basisprozessor hat nur Kassetten). Oder ebenso manche IBM PC Erweiterungskarten, wie IBMs PC/360 und AT/370 Karten, aber auch Dritthersteller ihre 32032 Karten, Transputerkarten (mit statt PIO einem C012 10Mbit/s Seriellinterface), oder auch 80860 Karten, diese alle disklos. Hierbei wurden Programme zumeist auf beide Prozessoren verteilt, mit der Darstellung und Userinterface auf dem Basisprozessor, und nur der harten Rechenarbeit auf dem Zweiten, um beide auszunutzen und Datentransfer zu minimieren.
Auf Rechnern wo der Zweitprozessor die Disks hat war es auch möglich das Interface dazwischen wie ein schnelles 2-Rechner Netzwerk anzuschauen, und die Programme auf die beiden Prozessoren nach Client-Server Methoden zu verteilen, mit dem "Terminal" Prozessor als Editor und dem "Disk" Prozessor als Datenbank. Wenn letzterer schneller war (und sei das auch nur weil nicht von Video Ausgabe DMA gebremst) konnte man auch mit vergleichbaren Methoden wie oben Programem verteilen, selbst wenn diese keine Disks oder Datenbanken benutzten.
Beim Fernschreiber hatte es daher bereits die eingebaute Signalglocke, welche mit BEL (ASCII 7) angeschlagen werden kann. Ohne Fernschreiber wurde dies sehr bald vermisst und ersetzt. Die analoge Hardware dazu war simpel und naheliegend, ein normaler Lautsprecher mit Verstärker davor. Speziell ist nur, dass man dazu einen Audiosignalgenerator braucht, welcher vom Rechner angesteuert werden kann. Da ich mich nie gross mit Sound beschäftigt habe, werde ich mich hier kurz halten.
Die wohl eigenartigste Form dieser Methode beinhalteten die frühen DEC PDP Serie Rechner, dies wiederum von ihren Vorfahren geerbt, den MIT Whirlwind und TX-0. Bei diesen wurde zwecks Debugging eines der Bits vom Akkumulator mit einem Verstärker/Lautsprecher verbunden. Dieses erzeugt den Datenabfolgen im Akkumulator folgend ein dauerndes brummendes oder quietschendes Signal. Dieses war von den jeweiligen Programmpassagen ihren Daten abhängig, und damit brauchbar um typische Ablaufstrukturen zu erkennen (z.B. erscheinen Endlosschleifen als simple Repetitionen). Da bei 100en kHz die Frequenzen unhörbar hoch wären, wurde dazu ein Bit das seltener geschaltet wird als optimal erkannt und benutzt, irgendwo im Bereich 2^10..2^15 oben.
Diese Frequenzgenerierung brachte Leute auf den Gedanken, gezielt Programme zu schreiben, welche beabsichtige Tonfolgen erzeugten. Dies ging sogar soweit, dass ein Compiler geschrieben wurde, welcher mit Musik in Notenbeschreibung gefüttert automatisch solche Programme erzeugte. Damit wurde das Zeitalter von computergenerierter Musik eröffnet.
Die einfachste Form eines derartigen Generators ist schlicht ein Datenwert via einen Digital/Analog Wandler auf einen per Spannung stimmbaren Schwingkreis, der einen Sinus variabler Frequenz erzeugen kann. Das ergibt einen flötenartigen Ton, der aber recht langweilig ist. Daneben kann man aber auch Dreieck oder Rechteck oder Sägezahn recht einfach erzeugen, die jeweils progressiv härtere/harschere Töne sind, und auch alle vier Varianten davon mischen.
Man kann auch mehrere Generatoren mit verschiedenen Frequenzen nehmen, und diese dann mischen, so dass dabei gemischte Muster entstehen, mit weiteren Frequenzanteilen dabei anfallend. Das war die Basis vom Xerox Alto seiner FM Synthese, welche auch in frühen PC Soundkarten benutzt wurde.
Sobald man ein Gemisch hat, kann man dieses auch durch programmierbare Filter schicken, welche nur einen Teil der Wellen durchlassen, und damit den Klang weiter färben, für eine grössere Tonauswahl. Diese gibt es als Tiefpass/Bandpass/Hochpass als auch Bandsperre.
Danach kann man auch die Lautstärke nicht nur ein/aus steuern, sondern mit einem variablen Verstärker in der Zeit varieren, von Anfang zu Spitze (Attack/A), von Spitze zu Bleibend (Decay/D), Länge des bleibenden (Sustain/S), Bleibend zu Ende (Release/R), was als ADSR Hüllkurve bekannt ist. Diese Fähigkeit ist vor allem die entscheidende Eigenschaft vom Commodore 64 seinem SID Chip, der Schritt von Geräuscherzeugern zu Musikinstrumenten erlaubend, zusammen mit auch noch drei Generatoren mit je eigener Frequenz und schaltbar Sinus/Dreieck/Rechteck/Sägezahn, und einem Rauschgenerator, und deren Mischung, und einem Frequenzfilter, sowie auch mit einer langsamen Frequenz einen anderen Generator in Frequenz (Vibrato) oder Lautstärke (Tremolo) zu beeinflussen (das braucht allerdings Arbeit vom Prozessor). Dementsprechend hat der SID auch mehrere 10 Register zu beschreiben. (Der SID Designer war auch später Entwickler der Synthesizer von Ensoniq, und Mitbegründer der Firma.)
Erheblich spezialisierter ist eine andere Sorte Tongeneratoren, die Sprachgeneratoren. Diese basieren darauf, dass Sprache in erster Näherung aus einzelnen Lauten bestehen, den sogenannten Phonemen. Diese kann man als Frequenz und Zeit Gemische abstrahieren, und in ein ROM stecken, welches dann einige spezielle Generatormuster anstösst. Dazu muss man nur ein einzelnes Register mit der Phomennummer beschreiben. Am bekanntesten war hier wohl der Votrax SC-01 Chip, welche die typische "Robotterstimme" der frühen 1980er erzeugte.
Dazu wird nur ein Digital/Analog Wandler benötigt (bzw zwei bei Stereo) und mit einer Folge von Samples (Zahlen welche den aktuellen Wert der Welle zu einem Zeitpunkt darstellen) versorgt. Im Gegensatz zu obigem Beep, wird hier nicht die Samplefrequenz modifiziert, sondern mit einer festen Frequenz gearbeitet (wie bei der festen Pixelfrequenz), mit der Soundfrequenz als Folge der Daten in den Samples (wie bei dem Bild das Pixelmuster als Folge der Daten in dem Bitmap). Dementsprechend können die Daten per einfachem konstant schnellem DMA gelesen und ausgegeben werden, aus einem Audiospeicher. Dazu muss nur der Audiospeicher mit einer Serie von Samples beschrieben werden, und der Abspielvorgang (mitsammt Anfangsadresse Samplezahl setzen) durch einen Strobe ausgelöst werden.
Die Samples müssen mindestens 2 mal die höchste nutzbare Frequenz sein bei Rechteck, mindestens 4 mal bei Dreieck, und mindestens 8 mal für beliebige Wellenformen. Die normale musikalische C-Dur Tonleiter erwartet als "unteres" C (C4 genannt) 261.63Hz und "oberes" C (C5) 523.25Hz (alles verdoppelt sich pro Oktave), und ist "festgenagelt" bei A (englisch) bzw H (deutsch) = 440Hz (strikte 439.96Hz). Minimal braucht man also Mono mit ab 8*523 = etwa 4kHz Samples zu 6bit (der Dragon 32/64 nahm z.B. die Fernseh Zeilenfrequenz von 15625 (PAL, bzw 15750 NTSC) mit 6bit). Telephon ist Mono mit 8kHz zu 8bit. Normale 1980er Rechner ihre Frequenzgeneratoren arbeiten intern mit etwa 10..30kHz 8..12bit (Pokey Chip im Atari 800, SID im C64 oder AY-3-8910 in den MSX), in mono. CDs sind mit 44.1kHz und 16bit Stereo beschrieben.
Der Macintosh war einer der ersten Rechner welcher von Soundgeneratoren zu Wavetables wechselte, kurz danach gefolgt vom Amiga. Beide arbeiteten mit 8bit, beide mehrkanalig (Amiga sogar stereo), sowie beide mit der Video Zeilenfrequenz als Samplerate weil Samples während der Video Strahlrücklauf Datenpause geholt wurden.
Die Aufgabe des Prozessors besteht darin, entweder vorgefertigte Samples gemäss Datenbeschrieb in Abspielauftrag zu geben, oder die Samples vorzu zu generieren/errechnen, zumeist mehrere Töne skalieren und kombinieren. Letzteres ist rechenintensiv, wegen der dabei oft verwendeten Multiplikationen oder gar Fouriertransformationen oder einer verwandten Mathematik, all das oft mit mehr als 8bit Endresultat, und wegen Rundungsfehler meiden in skalierter Genauigkeit, oft auf 24bit. Weshalb dazu schon früh spezielle Digitale Signalprozessoren (DSPs) erschaffen wurden, welche die dafür benutzten typischen Rechenschrittkombinationen als fertige Elemente beinhalteten, auf Kosten der hier nicht benutzten bei normalen Prozessoren vorhandenen komplexen Abläfen. Zumeist haben DSPs auch separate Programm und Datenspeicher (Harward Architektur) und auch mehrere Datenspeicher und Datenbusse, um ihren Durchsatz zu erhöhen, aber weiter auf Kosten der Flexibilität.
Hier tauchen aber auch mit der Laufzeit Interaktion die ganzen Probleme auf, mit Programme auf den Benutzer warten, und aus mehreren Eingabegeräten das richtige erkennen und darauf reagieren. Hierzu gehört auch dessen Aktionen auszuwerten, die eigentlichen Daten von Kommandos zu trennen, was weit mehr Programmlogik erzeugte. Heutige Programme sind oft weit über 50% (und teils weit über 90%) Eingabe auswerten, und nur ein geringer Rest eigentlicher Ablauf (und dieser Teil besteht oft auch mehr aus Ausgabe als eigentlichem Rechnen).
Wie bei Lampen gelten hier die selbigen Probleme und Lösungen bezüglich den vielen Stellen von Binärzahlen und diese in 3er oder 4er Gruppen anordnen, mechanisch oder farblich. Oft werden die Schalter genau unter die passenden Lampen gestellt, wieder auf passende 2^n in einer Spalte ausgerichtet. Sie sind damit Teil derer Gruppierung, bis hin zu Schalter in verschiedenen Farben passend zur farblichen Markierung der Lampen.
Neben Daten will man auch Zeitpunkte eingeben (z.B. "jetzt speichern"), wozu 2 Schalterbewegungen unnötiger Aufwand sind, weshalb man dazu Taster nimmt, welche nach loslassen per Feder wieder herausspringen und somit abschalten, welche damit Signalpulse/Strobes ergeben. Generell gilt hier Schalter=Daten und Taster=Kommandos.
Danach muss die derart eingegebene BCD Zahl (falls über 9, und damit in BCD mehrstellig) in Binär gewandelt/zusammengesetzt werden (= Ziffern addieren), um mit ihr zu rechnen. Dazu muss jeweils eine Multiplikation mit 10 gemacht werden auf alle bisherigen (= davorliegenden) Ziffern, wonach die nächste Ziffer addiert wird als neue hinterste/rechts/Einer. Dazu wird anfangs eine Variable auf 0 gestellt. Danach muss für jede Ziffer die Rechnung Variable = 10*Variable+Ziffer gerechnet werden. Dabei werden die Ziffern in der Reihenfolge von vorne/links nach hinten/rechts/Einer benötigt. Dies passt gerade zur Eingabereihenfolge, ungespiegelt, es braucht keine Buffer oder Entspiegelung.
Nebenbei: Diese *10 Multiplikation kann man oft schneller mit 4 Additionen machen, Temp = Var (= *1), Var = Var+Var (= *2), Var = Var+Var (= *4), Var = Var+Temp (= *5), Var = Var+Var (= *10), und danach das Var = Var+Ziffer (= *10+Ziffer).)
Auch dies funktioniert nicht mit negativen Werten, also wird mit einer Minus wieder nur ein Flag gesetzt, dann normal wie eine positive Zahl eingelesen, dann nachdem die Zahl fertig gewandelt ist dieser Flag getestet und falls gesetzt die Zahl erst dann negiert. Oder das Minus nach der Zahl eingeben erwartet, teils per -/Ende Taste statt normalem Ende.
Weil dies immer noch einiges an Aufwand ist, haben manche Rechner auch Spezialbefehle um dies schneller und einfacher zu machen, z.B. die 360er ihr CVB Befehl (das Gegenstück zum CVD für Binär zu BCD).
Nebenbei: Dies kann man ebenfalls mit beliebigen anderen Zahlenbasen machen, diesmal einfach Multiplikation mit Basis. Wenn dies mit 8 oder 16 gemacht wird, entsteht Shift-links um 3 oder 4 bit. Auch Zeit geht hier, mit einfach nach jedem : einmal 6er Multiplikation benutzen statt der normalen 10er.
Auch dies entfällt wenn direkt mit BCD gerechnet wird. Also muss man beide Umwandlungen ihre Zeit mit den Rechnungen ihre Zeitzunahme bei BCD vergleichen.
Nebenbei: Diese BCD zu Binär Wandlung muss man auch machen, um Zahlen in Dezimal von einer ASCII oder EBCDIC oder anderen Tastatur entgegenzunehmen. Hierbei muss man davor zusätzlich die 6bit/7bit/8bit reduzieren zu 4bit Gruppen, durch den 48 oder 240 Teil abziehen. (Danach muss diese zumeist als 2 8bit zu 2*4bit packen und ablegen.)
Nebenbei: Auch hier hat der 360er einen PACK Spezialbefehl (analog zu UNPACK für vom BCD nach Zeichen), welcher 2*8bit zu 2*4bit verpackt, der ebenfalls im 68000 (ab 68020) Mikroprozessor kopiert wurde. Andere Prozessoren verwenden bereits dazu vorhandene 4 mal Shift links (= Multiplikation mit 16) und OR Befehle, oder ebenfalls beschleunigt mit einen SWAPD oder ROTD Befehl falls vorhanden.
Genauso wie bei der Anzeige ein 4:10 Decoder und 10 statt 4 Lampen in Unär eingesetzt wurden, kann man auch hier in Unär mit 10 Taster und einem 10:4 Encoder statt 4 Schalter vorgehen.
Neben dem eigentlichen 4bit Code kann dabei auch noch per OR Gatter als fünftes Bit ein weiteres "beliebiger Schalter ist aktiv" Signal generiert werden. Bei 10 Tasten statt Schalter kann dieses OR auch als Signalpuls/Strobe dienen, ohne eine separate Strobe Taste drücken zu müssen. Daher ist es hier sinnvoll statt 10 Schalter und einer Taste, direkt mit 10 Tasten zu arbeiten, wie man es von Taschenrechnern her kennt.
Technisch kann man dies in einem 10:4 Hardware Encoder mit 4+1 Eingabeport/PIO Bits machten, oder wieder mit 10 Eingabeport/PIO Bits und in Software mit einer Tabelle. In letzterem Fall ist kein Strobe mehr vorhanden, diese kann aber schlicht mit ganzer Tastensatz ungleich Null vergleichen erkannt werden.
Nebenbei: Strikte waren Lochkarten schon in der vor-Rechner Zeit wegen ihrer Unärdarstellung auch manuell recht einfach als Eingabe stanzbar, sogar mit einer simplen Knipszange, solange die Lochungsorte mit einem Aufdruck für 0..9 vorgegeben waren. Dieser Vorgang war als Ablochen der Daten bekannt. Sogar bestehende ausgestanze Karten modifizieren/erweitern war möglich. (Ebenfalls verbraucht dies wie bei Lochkarte als Ausgabe Material, ausser es wird eine bestehende Ausgabe modifiziert.) (Bei der Lochkarte bekam man auch zumeist ohne Hardware Encoder deren 10+3 = 13 Eingabebits.)
Binärzahlen können beliebig breit sein, brauchen aber nur ein Schalter pro Bit. Dezimal hat nur den Bereich 0..9, muss daher mehrmals wiederholt werden. Für jede Dezimalstelle 10 Tasten vorsehen, in 10er Spalten wie bei Lampen, ist aber weit aufwendiger (Schalter sind grösser und teuerer als Lampen), und nicht komfortabel (Handbewegungen von Satz zu Satz). Trotzdem wurde so eine Anordnung in manchen mechanischen Rechenmaschinen (z.B. Registerkassen) verwendet, und von dort in manche frühe Rechner übernommen.
Die bessere Alternative besteht darin, nur einen Tastensatz zu haben, kombiniert mit einer Anzeige (und ihrem Register dahinter), und mit den Tasten jeweils nur die Einerstelle rechts zu ersetzen, und parallel dazu alle bereits eingegebenen/gespeicherten Stellen um eines nach links zu schieben (und dabei auch den angezeigten Wert mit 10 zu multiplizieren und danach die neue Ziffer zu addieren). Dazu reicht es, die normale BCD zu Binär Wandung mit *10+Taste Rechung zu benutzen, und dann mit der normalen Binär zu BCD Wandlung die Anzeige richtig machen zu lassen.
Nebenbei: Eine solche Eingabe kann wieder auch für Oktal benutzt werden. Dazu muss jeweils 4bit zu 3bit reduziert werden, indem das Bit3 das stets 0 ist eliminiert wird. Dedizierte Oktaleingaben liess man einfach die 8 und 9 Tasten weg, reduzieren den Encoder auf 8:3, und liess die 4 zu 3bit Elimination fallen. Z.B. wieder die Frontpannels der PDP-8/A oder der PDP-11/34, deren Tasten/LED-Anzeigen strikte oktale Taschenrechner ohne Arithmetik sind.
Weil Fernschreiber schon früh als Drucker erscheinen, und ihre Lochstreifenstanzer und -leser auch als Speichermedium benutzt wurden, waren deren Tastaturen bereits vorhanden, und da sie parallel zum Lochstreifenleser verdrahtet waren auch sofort nutzbar. Trotzdem wurden sie erstaunlich lange ignoriert. Diese Fernschreibertastaturen funktionierten genau so wie oben. Jede Taste hatte einfach 7 Kerben in ihrer Stange, deren Vorhandensein (oder eben nicht) ein 0 (bzw 1) vom Code dieser Taste ergab, indem ohne Kerbe ein Kontakt entstand, und mit Kerbe dieser vermieden wurde. Dazu kam eine weitere immer vorhandene nicht-Kerbe, welche etwas später kontaktierte und damit den Strobe ergab, der den Tastendruck dann abschickte. Danach kam die elektromechanische Parallel/Seriell (PISO) Wandlung.
Ein Rechner muss um diese zu nutzen eine passende Seriell/Parallel (SIPO) Auswertung haben, um die Signale zu verwerten, wie sie ein anderer Fernschreiber ausdrucken würde. Diese kann wieder aus Eingabeports oder PIOs und Software bestehen, um Zeichen aus Bits zu sammeln, oder aus einem Hardware SIPO Schieberegister aus dem man einfach fertige Zeichen als Datenbyte Eingabeport ausliest, nachdem eines angekommen ist.
Dies könnte man strikte auch elektronisch so nachbauen, was aber nach 7 Kontakten bei jeder Taste verlangen würde! Anderseits kann man mit nur einem Kontakt arbeiten, mit einer Leitung pro Taste, und die ganze Zusammenfassung/Codierung mit einer Encoderschaltung lösen, was aber elektronisch aufwendig ist. Eine weit einfachere Alternative zu einem solchen vollen grossen Encoder besteht darin, die Tasten als n (=Tasten/8) Zeilen zu je 8 Spalten anzuschauen, was als eine nx8 Tastenmatrix bekannt ist, und dann nur n+8 Leitungen durch diese zu schicken. Danach wird ein 0..(n-1) laufender Zähler mit einem Decoder an die n Zeilenleitungen angeschlossen, welcher diese nach und nach separat aktiviert, was als die Tastatur scannen bekannt ist (und analog zu einer multiplexten Anzeige scannen ist). Dabei werden pro Zeile nur ihre 8 Spaltenleitungen an einen simplen 8:3 Encoder geschickt, welcher Bit0..2 erzeugt, während parallel dazu der Zähler die anderen Bit3..m bereits beinhaltet. Mangels Fernschreiber sein kann man dabei die ganze PISO und SIPO Geschichte weglassen, wie es auch bei Druckern ab den Zeilendruckern gemacht wurde.
Bei nur ASCII Grosschrift bräuchte es strikte bei 7bit und 96 Codes eine n=12 Matrix, aber wegen Shift und Ctrl reichen etwa 55 Tasten. Daher reichen auch nur 8 Zeilen, wobei der Zähler in Bit3..6 die Folge 0,1,6,7,8,9,10,11 machen muss, da der ASCII Code aus 8 Spalten zu je 16 Zeichen besteht, deren 16 Zeichen mit Bit0..2 und Bit3 erzeugt werden, und alle ungeschifteten Zeichen in den Spalten 0,3,4,5 davon liegen (obige 8 Zählerwerte sind diese mit *2 und dann jeweils +0 bzw +1). Shift erzeugt dabei falls ASCII 48..63 (bit6/5/4=011) eine -16 (bit4 von 1 zu 0). Ctrl erzeugt dabei falls ASCII 64..95 (bit6/5=10) ein -64 (bit6 von 1 zu 0). Im Fernschreiber waren die Shift und Ctrl nur Leitungsunterbrecher. Diese simple Shiftlogik ist auch als "bit paired keyboard" bekannt.
Im Gegensatz zum Fernschreiber und Drucker, wo die ASCII 32..95bzw126 Druckzeichen von den ASCII 0..31 und 127 Nichtdruckbaren unterschieden werden müssen, und anderst darauf reagiert werden muss, mit drucken oder auswerten,, kann dies der Tastatur egal sein, Taste ist immer einfach Taste, stets nur ein Code zu erzeugen und verschicken.
Mit der ASCII Kleinschrift Erweiterung wurde es schwieriger, weil die A..Z Tasten ungeschiftet zu a..z wurden (Zähler=12..15, nicht-shift macht 32), aber die anderen Zeichen im Bereich 96..126 am Ort bleiben (Zähler=8..11, shift macht +32). Daher wird oft ein simpler 0..7 Zähler genommen, welcher Bit3..5 erzeugt und diese mit Bit0..2 sowie Shift und Ctrl Bit6..7 als 8bit Adresse an ein 256x7bit ROM benutzt. (Man könnte damit auch ohne jeglichen Aufwand den Shift+Ctrl Kombinationen ihre eigenen Codes geben, wenn nicht alle 128 Codes bereits vergeben wären. Dies kann man mit einem 256x8bit ROM machen, das 256 Codes erzeugen kann, von denen man dann halt nur 2*96 ausnutzen kann.)
Hier gab es schnell die Addition einer weiteren dritten Control-artigen Taste, sei diese "Alt" oder "Meta" oder "Command" genannt, welche oft einfach Bit7=1 setzte, was als Buckybit bekannt wurde. Diese konnte mit allen Zeichencodes kombiniert genausoviele Kommandos abgeben.
Den Rekord hielt hier die MIT Lisp Machine ihre "Space Cadet" Spezialtastatur auf der neben Shift und Ctrl noch fünf(!) weitere modifizierende Tasten waren, 2 Shift-artige FRONT und TOP (mit Shift zusammen erlaubten diese 8 Zeichen/Taste!), sowie 3 Ctrl-artige Meta und Hyper und Super (mit Ctrl zusammen erlaubten diese 16 Kommandos pro Zeichen, und damit 16*8=128 pro Taste!). Das alles mit einem 13bit/8096Zeichen Code (und folglich einem 13bit Eingabeport). Dem Emacs Editor seine Steuerung und seine "Escape-Meta-Alt-Ctrl-Shift" Namensauslegung kommt von dieser Tastatur her (das moderne in Lisp statt TECO geschriebene Emacs entstand auf diesem Lisp Rechner).
Um diese einzugeben wurden einerseits mehr Tasten oder andere Tastenbelegungen benutzt, wie bei den Akzenten, welche aber durch die Tastenzahl auf wichtigstes limitiert sind. Anderseits wurden dann beim PC die rechte Alt Taste zu AltGr und damitals zweiter Shift benutzt. Dazu kann man wiederum mit Shift+Ctrl+AltGr und 512x8bit an ROM arbeiten (was alles ein Teil vom PC BIOS ROM ist).
Mit all diesem kann dann 8bit erweitertes ASCII erzeugt werden. Dies geschah leider mit jedem Hersteller eine andere Zeichenauswahl/Anordnung, oder gar noch schlimmer, weil 8bit bald nicht mehr ausreichen, mehrere verschiedene Auswahlen beim gleichen Hersteller. All dies kann wieder in einem Hardware Encoder oder ROM Tabelle gemacht werden. Je komplexer es wird, und erst recht wenn umschaltbar gewollt ist, wird es einfacher in Software. Dabei werden alle Tasten, teils sogar inklusive die Shift und Ctrl in allen ihren Varianten (und ihren separaten Positionen), in die Matrix aufgenommen, welche nur noch Orte/Zustände von sich gibt. Auch der Zeilenzähler ist in Software, selbst der Decoder dazu. Der Decoder ist ein Port/PIO mit 1bit pro Zeile. Ebenso wird eine Zeile als ganzes eingelesen durch einen Eingaberport/PIO mit 1bit pro Spalte, und der Encoder ist bereits wieder in Software.
Im Commodore 64 ist dies alles nur eine PIO (CIA1) mit PortA Ausgabemodus 8bit Zeile auswählen und PortB Eingabemodus 8bit Spalte einlesen, was 8x8 = 64 Tasten in der Matrix gibt (die Taste Restart ist nicht Teil davon, sondern ein direkter NMI Interrupt um den Rechner zu teil-rebooten). Diese 64 werden je nach ob normal/Shift/Ctrl/C= gedrückt ist mit 4*64Byte grosse Tabellen im Kernal ROM in 8bit Zeichencodes umgewandelt.
In der IBM PC Welt gehen nur Matrixkoordinaten über die PC Tastaturleitung, nachdem alles davor in einem separaten 8bit Mikrocontroller in der Tastatur passierte. Dieser sendet einzelne Bewegungen als "Taste runter (=Make)" und danach auch "Taste rauf (=Break)" Codes über die serielle Leitung. Mit dem PC/AT gab es eine neue Tastatur, mit anderen Codes und Signalen, und auf dem Motherboard als Tastaturinterfacecontroller eine Konvertierung zu PC Codes, in einem 8042 Mikrocontroller, welcher zudem auch gleich das PIO Interface bildet. Mit der MF-2 Tastatur (die heutige) gab es einen dritten Code, mit in der Tastatur zwischen PC/AT und MF-2 umschaltbar. Mit der PS/2 wurde nur der PC/AT DIN Stecker durch einen Mini-DIN ersetzt, mit den gleichen Signalen drauf.
Alle Umwandlung von Make/Break, inklusive Shift/etc geschieht erst im PC drin. Dabei werden in Software Shift/Ctrl/Alt/AltGr erkannt und davon Modifikatorbits gesetzt. Am Schluss werden Koordinate und Modifikatorbits als Adressen in eine 8bit Tabelle benutzt, und dort die erweiterten ASCII ausgelesen. Hier passiert auch der Autorepeat (daher auch der "Taste rauf" Code um diesen zu stoppen, und um Shift/etc zu beenden). Genau diese Tabelle wird bei der PC Installation nach der Tastaturlayout Frage gesetzt. All dies könnte automatisch sein, wenn bloss der Tastatur Mikrocontroller sein Layout identifizieren würde. Oder dieser gar gleich die ganze Umrechnung in erweiteres ASCII selber machen würde, aber die Tastatur benimmt sich trotz eigenem Prozessor nur wie eine dumme Matrix.
Weil mit Shift/Ctrl/Alt/AltGr und mehrere Tasten in der Matrix gedrückt werden kann ein Problem auftreten, dass wenn diese 3 Tasten genau 3 von 4 Ecken eines Rechteckes sind, dann durch diese hindurch die vierte Ecke kurzgeschlossen wird, und damit als vierte "Phantomtaste" gesehen wird. Dieses Problem kann man beschränkt mit Anordnung der genutzten 3er Kombinationen umgehen (wie im IBM PC gemacht), oder generell indem man jeder Taste eine Diode in Serie gibt, analog angeordnet zu den Dioden bei den Bits in einem Dioden-ROM (und auch den Dioden in den LEDs einer multiplexten Anzeige). Alternativ kann man die Shift/Ctrl/Alt/AltGr Tasten separat von der Matrix machen, was billiger ist. (Solche Dioden habe ich selbst in einer China-Plastik 2-Oktaven billig-Kinderspiel-Orgel mit 5x5 = 25 Tastenmatrix und 25 Dioden gesehen.)
Bei einer direkt am Rechner angeschlossenen Tastatur konnte man einfach mehr Bits und Leitungen und Eingabebits addieren, wie obige Space Cadet bis zu 13. Beim PC sind Shifts sogar nur Matrixorte und dann rechnerinterne Bits, nicht einmal Leitungen. Womit die externe Hardware nichts davon wissen muss, Das BIOS verwendet den PC Tastaturmodus (oder ab PC/AT in PC umgerechnet, und MF-2 den PC/AT Modus) und macht dann für alle erweiterten ASCII Zeichen 8bit Codes daraus (und liefert auch den 8bit Matrixort damit man die Numeriktastatur von der Haupttastatur unterscheiden kann). Es representiert nicht-Zeichen indem es eine ASCII 8bit 0/NUL benutzt, gefolgt von 8bit Shift+Matrixort Kombinationswerten, womit Zeichencodes im BIOS stets 16bit sind.
Mit Windows oder Linux wird das BIOS gekillt, das Interface auf ohne Umwandlung und die Tastatur auf MF-2 gestellt, und in einen eigenen Code gewandelt (bei Linux ein VT100-Teriminal-artiger Code). X unter Linux schiebt wiederum den Kernel beiseite und macht seinen eigenen 32bit Code, den xterm wiederum in etwas VT100-artiges verwandelt. Kein Wunder das ab und zu einmal Tasten nicht das machen was man von ihnen erwartet!
Bei Terminals und ihrer festen 7bit oder 8bit Fernschreiber Serialleitung, und wieder auf nur ASCII ausgelegten Rechner und deren Software, waren aber keine Bits mehr frei, und erst recht keine 16bit oder 32bit Codes möglich. Also wurde dies hier wieder alles mit Escapesequenzen gelöst. Die DEC VT05 und VT52 und VT100 und folgende verwendeten für ihre Pfeiltasten die selbigen Codes wie bei der Ausgabe für die Cursorsteuerung. Ab der VT52 kamen Escapesequenzen für Edittasten und Numerikblock etc, ESC-O-etwas.
Dementsprechend mussten Programme bei Eingaben auswerten ESC erkennen, und dann weiter warten bis sie die anderen Bytes bekamen, und diese dann auswerten. Dies lief oft auf eine Form von Statemachine hinaus, abhängig vom aktuellen "wo in einer Sequenz" (inklusive gar nicht in Sequenz) verschieden reagieren. Diese sollte bei einer zu langen Zeit "in Sequenz" warten dann automatisch abbrechen, falls der Benutzer wirklich die ESC Taste benutzte oder Ctrl-[.
Im erstern Fall muss der einfach Rechner warten, bis eine Taste gedrückt wird. Bei einzelnen Schaltern kann er nur erkennen in welcher Stellung sie sind, es gibt keine Zeitangabe seit wie lang. Bei Tasten kann er wenigstens annehmen, dass solange sie aktiv sind der Benutzer darauf drückt. Daher hatten die Frontpannels neben einer Schalterreihe Daten auch immer ein paar Taster Kommandos, welche als Strobe Signale die Schalter zu gültig erklärten.
Bei mehreren Tasten und einem Hardware Encoder ist genau aus diesem Grund ein weiteres "beliebige Taste ist aktiv" Signal vorhanden, und es wird nur wenn dieses Aktiv ist die Tastennummer verwertet.
Aber bei einer Matrix wird dies problematischer, weil je nach aktiver Zeile andere Tasten sichtbar sind, und damit je nach ob die gedrückte dabei ist auch das Signal variert. Die primitivste Lösung ist normal alle Zeilen zu aktivieren, um dann wenn irgendeine Taste gedrückt wird das Signal zu bekommen, und danach nur noch Zeilenweise aktiv zu gehen um die spezifische Taste zu ermitteln, und danach wieder alle Zeilen zu erlauben. Dazu muss der Zähler vom Rechner aus manipuliert werden, sofern nicht gleich alles mit Port/PIO und Software gelöst wird.
Der zweite Fall ist schwieriger, wenn der Benutzer bereits getippt hat, und diese Tastendrücke inzwischen verloren gegangen sind. Dies gibt massiven Fehler und ist frustrierend, muss unbedingt vermieden werden. Daher muss hier der Rechner wiederholt die Tasten lesen gehen, genug oft dass keine "übersehen" wird.
Wenn er ohnehin auf Tasten wartet ist dies einfach. Dies kann auch problemlos zusammen mit einer multiplexten Ausgabe scannen erfolgen.
Wenn der Rechner anderseits arbeitet, muss er entweder analog zu nichts anzeigen nicht nachschauen (und Tastendrücke verpassen riskieren), oder er muss regelmässig die Arbeit unterbrechen um nachzuschauen. Letzteres kostet Prozessorleistung und ist programmtechnisch schwierig 100% sicherzustellen. Dies nicht machen ist ein Problem beim Apple II, welcher nur in Kommando oder INPUT nachschaut, sonst verliert.
Die Tastendrücke sichern kann aber bei Tastaturen welche einen Strobe erzeugen einfach durch diesen ausgelöst werden, wieder vielleicht mit normalerweise alle Zeilen aktiv geschaltet. Dabei wird mit dem Strobe ein Interrupt ausgelöst, dessen Serviceroutine die Tasten in einen Zwischenspeicher (Tastaturbuffer genannt) ablegt. Programme schauen zuerst dort nach, ob bereits Tasten da sind, und erst wenn dieser leer ist warten sie auf Tasten direkt von der Tastatur.
Bei Tastaturen ohne Strobe, z.B. nur ein dummes PIO mit einer Matrix dahinter (wie im Commodore 64), kann auch mit einem in Hardware wiederholt ausgelöstem Interrupt gearbeitet werden, mit dabei jeweils die Tasten scannen. Das kann ein beliebiger Timer Interrupt sein (so im ca 10..100ms Bereich ist dazu normal), oder man kann dazu den ohnehin vorhandenen 50/60Hz Vertikalblankinterrupt des Videogenerators nehmen.
Bei der PC Tastatur verwendet deren Mikrocontroller normales nachschauen (er rechnet ja sonst nichts!), und verschickt dann Zeichen an den PC (der selber den Empfang der Koordinatencodes mit Interrupt nutzen kann, oder seinen alle 18.2ms laufenden Timer).
Addiert man eine vierte Taste hinten für zurück oder bremsen, und man hat den standard Atari Joystick der 1970er/80er. Vier Richtungen, und als Kombinationen von je 2 benachbarten Tasten auch 4 Diagonalen, weshalb man das einen 8-Richtungs Joystick nennt (ausser die Diagonalen werden mechanisch verhindert, was einen 4-Richtungs Joystick ergibt). Das ganze mit einem 6poligen Kabel an einen 9poligen DE9 weiblich Stecker. Pins 1=auf 2=ab 3=links 4=rechts 5=Y 6=feuer 7=5V 8=0V 9=X (mit im standard Joystick unbenutztes 7=5V sowue 5=Y und 9=X, alle für die Paddles versorgen gedacht, wobei 7=5V aber auch für Autofeuer/Seriefeuer Schaltungen versorgen umgenutzt wurde). Beim Atari VCS, wo dieser Joystick erstmals auftrat, waren die 2*4 Richtungsbits an einem 8bit Port des eingebauten 6532 RAM+PIO+Timer Chips, und die 2*1 Feuerknöpfe wurden vom TIA Videocontroller nebenbei gemacht (trotz freier PIO Bits!). Beim Commodore 64 waren dies einfach 2*5bits der selbigen beiden CIA1 PIO Ports an denen auch die Tastaturmatrix angeschlossen war, wozu für Joystick 2 dessen Port A "Zeile Auswahl" von Ausgabemodus auf Eingabemodus umgestellt werden muss, während Joystick 1 mit Port B "Spalte Einlesen" bereits richtig auf Eingabemodus steht, solange keine Zeile mit gedrückter Taste selektioniert wird und stört.
Optimierungen waren neben dies so machen nur noch mechanisch. Einerseits robustere Spielhallenmechanik, Stahlhebel mit oben fester Kunstoffkugel zum greifen, montiert auf einem flachen/abstüssigen schweren Basisbrett, sowie darin eingelassen massive Feuertasten, was als Joyboard bekannt ist. Anderseits Feuerknopf oben am Hebel montieren. Oder gar den Hebel zur Pistolengriffform ausbauen, und Feuerknopf als Abzugshebel vorne. Wieder alles nur spezielle Tasten. Da das ganze reine Elektromechanik war, konnte auch jeder etwas anderes basteln. (Daher konnten damals die meisten Joystick Spiele auch mit etwas Komfortverlust mit den 4 Pfeiltasten und der Leerschlagtaste einer Homecomputer Tastaturmatrix gespielt werden, oder mit einigem Verlust bei nur 2 Pfeiltasten mit shift für die anderen Richtungen.)
Danach kamen beim SNES weitere X und Y Feuerknöpfe und die L und R Schultertasten dazu. Um bei NES 8 (bzw SNES 12) Tasten Kabel und Pins zu sparen haben diese beiden Pads ein PISO Schieberegister (z.B. 74165 oder 166 Chip) eingebaut, mit den Tasten an dessen parallelen Eingängen und zum Rechner hin die 5 0V/5V/Load-Shift/Clock/Serial-Aus Pins des Chips, Load-Shift und Clock kommen von Port/PIO Ausgabebits, und Serial-Aus geht zu einem Port/PIO Eingabebit, dies alles mit 7Pol Stecker. Beim SNES wurde dieser PISO einfach von 8 auf 12bit verlängert.
Sega war anfangs näher bei Atari als bei Nintendo. Beim Master System war das Joypad nur D-Pad und 2 Feuer ohne Modustasten, wie beim Atari ohne PISO, mit 7poligem Kabel, selbigem DE9 weiblich Stecker, aber ein anderes Pinout. Wieder nur 6bit Port/PIO Eingabebits dahinter. Daher addierten sie beim Mega Drive nur eine Modus Taste für Start, aber gaben mit A und B und C mehr Feuertasten, den 9pin Stecker voll ausnutzend, mit 8bit Port/PIO Eingabebits.
Später kamen mit X und Y und Z mehr Feuertasten sowie eine Schultertaste dazu, aber auf Kosten eines 6 * 2:1 Multiplexer Chips im Joypad, einer Leitung als Port/PIO Ausgang um diesen zu schalten, sowie 5V um ihn zu versorgen, und nur 6 Eingabeport/PIO welche nun die 2*6 = 12 Tasten erlaubten. Eine zweite Schultertaste kam erst mit dem Saturn, die Verdrahtung mir unbekannt.
Sony kam erst spät mit der Playstation, welche sie für Nintendo entwickelt hatten. Die hatte daher auch eine direkte SNES Kopie als Joypad, das gleiche D-Pad, die gleichen ABXY Tasten (nur zu Kreuz/Ring/Quadrat/Dreieck umbenamst), gleiche Select und Start, gleiche Kabel/Signale (nur anderer Stecker), und gleiches PISO (nur hier 14bit). Lediglich die L und R Schultertasten wurden von 2 auf 4 erweitert zu L1, R1, L2 R2 (was die 14bit ergab). Aber alles immer noch bloss eine 14-Tasten Tastatur, nicht einmal eine Matrix. Daher sind bis heute Konversationen von Joyboards problemlos, einfach einem billig-Joypad ihre Elektronik/Kabel/Stecker mit der erwünschten Mechanik kombinieren.
Technisch sind hinter den Drehknöpfern Potentiometer (kurz Pot(s) genannt), also Widerstände mit einem variablen Widerstandswert (bzw strikte einem variabel in 2 Teile aufgeteilten festen Widerstandswert). Diese können wenn zwischen 0V und 5V verbunden eine variable Spannung, oder wenn nur mit 5V verbunden einen variablem Strom nach 0V generieren. Beides davon kann gemessen werden, und der Messwert wird als Daten benutzt. (Strikte gibt es neben den üblichen Drehpots auch die weit seltener genutzen Schiebepots, welche aber mechanisch wackelig sind, und damit als Spielecontroller weniger geeignet, trotz näher bei der realen linearen Pingpong Bewegung sein!)
Eine Spannungsmessung basiert auf einem Analog/Digital Wandler, wozu im billigen Fall (und hier völlig ausreichend schnell) das "Sukzessive Approximation" Verfahren benutzt wird. Dabei wird das Eingangssignal mit dem Ausgang eines Port/PIO plus Digital/Analog Wandlers verglichen, per Analogdifferenzverstärker, und das mehr/weniger Ergebnis als 1bit per Port/PIO Eingabe einglesen. Der D/A wird zuerst auf binär 1000... gesetzt, und damit die Spannung mit über/unter 50% verglichen, dann wird falls dies versagte auf 0000... gestellt, und dann stets 0100... addiert, zu 0100... oder 1100.... Damit entsteht ein 25% bzw 75% Vergleich, bei dessen Versagen die 0200... wieder subtrahiert wird, und dann mit 0010... addieren probiert für 12.5% bzw 37.5% bzw 62.5% bzw 87.5%. Dies wiederholt man mit einem Schritt pro Bit, als sukzessive feinere Messung, egal ob man 6/8/10/12bit will. Der Dragon 32/64 machte dies so, mit dem selbigen 6bit PIO und D/A welche schon für den Sound generieren und Kassettenband schreiben verwendet werden, mit nur dem Vergleicher und PIO Bit addiert für die Analogjoysticks ausmessen (es waren keine Digitaljoysticks vorgesehen), mit 2 PIO Bits als Joystick A/B und Richtung X/Y Auswahl zur Messung (und auch selbige Schaltung für Kassettenband lesend verwendet).
Eine Strommessung ist einiges billiger wenn kein Digital/Analog Wandler benutzt/vorhanden ist, aber langsamer/aufwendiger zu benutzten. Hierbei wird einfach ein Kondensator aufladen via dem Pot seinem Widerstand (der ergibt die Stromstärke), und dabei die Zeit gemessen, bis eine gewisse Spannung (zumeist etwa die halbe 5V) erreicht wird. Spannung am Kondensator = feste Menge Ladung = Strom*Zeit, und damit ist Strom = Ladung/Zeit, woraus per Strom = Spannung/Widerstand = der Widerstand und Drehwinkel vom Potentiometer als Eingabestellung ermittelt wird. Normales analog Elektronik Verhalten.
Dazu wird beim Kondensator entladen auch parallel ein Zähler auf 0 gestellt, und dieser von einer regelmässigen Zeitimpuls Quelle her +1 gerechnet, solange bis der Spannungsvergleich erreicht ist, was ein Stop Signal von sich gibt (oder bis bei unendlichem Widerstand und 0 Strom und keiner ansteigenden Spannung der Maximalzeitwert erreicht wird). Dieses Verfahren ist im Atari VCS (auch im TIA Videochip) und im 800 (im Pokey Pots+Tastatur Chip) darin, ebenso im Apple II (in Analog+TTL Elektronik), sowie im Commodore 64 (im SID Soundchip), und auch dem IBM PC seinem Gameport (wieder in Analog+TTL Elektronik). Angesprochen wird es per PIO Ausgabepin um den Kondensator zu entladen und den Zähler löschen, gefolgt von Port/PIO Eingabe um den Zähler auszulesen. Wieder sind teils PIO Bits als Joystick Auswahl vorhanden, oder aber mehrere gleichzeitig/parallel arbeitende Zähler, oder beide Methoden gemischt (Commodore 64 sein SID hat 2 Zähler (X und Y) und eine 2-Position Auswahl (Joystick/Paddles Port 1 oder 2)).
Nebenbei: Neben Spiele steuern sind solche Potentiometer plus Wandler auch als Analoge Werteingabe nutzbar. Diese waren bereits mit einem Oszilloskop als Ausgabe zusammen sehr effektiv, mit darauf Kurven gerechnet darstellen, mit mehreren Potentiometer(n) um Parameterwerte einzugeben. Damit konnte man bereits in den 1950/60ern interaktiv das Verhalten von Formeln erforschen, um per Simulation passende Eigenschaften von Konstruktionen zu ermitteln, z.B Dämpfungselemente optimieren auf gerade noch genug wirkend ohne unnötig bremsend zu sein.
Beide Richtungen werden mit einer Stellfeder in die Mittelstellung gebracht, und gegen diese von Hand ausgelenkt (beim Digitaljoystick wirken hier die internen Federn der Tasten), mit mehr Kraft je weiter. Oft werden bei einem solchen Joystick auch 2 kleine Hebel oder Schieber angeboten (mit dahinter normale oder linearschieber Pots), mit denen der Mittelpunkt leicht verschoben werden kann, um die unvermeidlichen Messabweichung durch die Analogelektronik ihrer Herstelltoleranzen auszukorrigieren. Teils konnte man auch die Stellfeder deaktivieren und eine Ratsche aktivieren um die Position zu halten, z.B. für Motor oder Bremsen steuern. (All diese Mechanik war schon weit vor Spielen auf Rechnern in Produktion, in Fernsteuerungen für Modellflieger bzw Modellschiffe bzw Modellautos, ohne Änderungen übernommen.)
Atari hat, trotz nur Drehknopf Paddles in Pong, wohl in Hinblick auf obiges ihre Joystick/Paddle Anschlüsse auf je 2 Pots ausgelegt, mit den Pins 5=PotY 7=5V 9=PotX. Die Pots selber sind 1Mohm, gefolgt von VCS intern noch 1.8kohm als Kurzschlussschutz und dann 68nF Kondensatoren. Dies hat Atari dann ausgenutzt um einen Stecker zu sparen, indem sie zwei Paddles als Paddlepaar mit einem gemeinsamen Stecker versahen. Damit wurde auch nur ein Port benutzt, und damit waren mit 2 Ports mal 2 Paddles auch Spiele mit 4 Paddles/Spieler möglich. Damit waren aber auch zwei Feuerknöpfe pro Paar notwendig, weshalb für diese dann die digitalen links/rechts Pins missbraucht werden mussten. Der Apple II und der PC haben dagegen zwei Ports mit je 2 Pots und 2 Feuertasten (aber keine Digitaljoystick Leitungen), trotz beim PC immerhin 15 Pins pro Joystickanschluss, mit der ganzen unteren Reihe ihre 7 Pins auf GND (und oben nochmals 4 von 8 GND), was erst die 1-Anschluss mit 2-Joystick und Y-Kabel Konfiguration ermöglichte.
Dann kamen auch spezielle Flightsticks auf, wie z.B. das Microsoft Sidewinder, mit nur einem Quer/Hoch Stick aber einer dritten Achse mit dem Hebel drehen für Seiten, sowie einem in der Basis eingebauten Paddle/Drehrad für Motor, plus Feuerknöpfe am Griff.
Den Luxus bieten spezialisierte nachgebildete Flugzeugcockpits, einerseits Quer/Hoch als Joystick (oder gar als Yoke/Steuerhorn) mit Kommandoknöpfen (bis hin zu einem "Coolie Hat" Digitaljoystick oben drauf für die Bildschirm Blickrichtung umschalten) sowie anderseits separatem Schubregler mit daran anhängbar Seitenruderfusspedalen (Schub und Pedale sind je eine Achse, mit den Seitenruderpedalen wie bei Fliegern mechanisch gegenläufig, mit nur einem Pot dahinter) und mehreren Feuerknöpfen. Die ganzen Ruder und Motor sind elektrisch wie gehabt, nur eine andere mechanische Anordnung der 4 Pots. Die vielen Knöpfe (und der Coolie Hat) wurden elektrisch möglich, indem ihre mehrereb Signale auf wenige Leitungen gemultiplext wurden, deren Signale an die 2*2 Feuertastenpins gehen, wonach die Software dann Pinkombinationen und/oder Signalfolgen als einzelne Knöpfe auswerten muss.
Schon vor Flugsimulatoren waren Autorennspiele weit verbreitet, weil mit wenig Rechenleistung und Graphik machbar, selbst auf dem Atari VCS. Hier reichen 2 Pots für Lenkung und Gas/Bremse (anfangs nahm man sogar bloss ein Paddle, gerade auch beim VCS, sein Pot um zu lenken plus Knopf als nur Gas). Das führte bereits bei ferngesteuerten Autos zu Sendern mit nur 2 vereinfachten Hebeln mit nur einer Bewegungsrichtung und Pot. Diese Designs wurden alle auch als Joysticks adaptiert, da wieder nur andere mechanische Bauformen. (Neuere kleine Modellauto Fernsteuerungen sind sogar teils nur noch ein Griff mit Gas und Bremse als 2 "Feuerknopf" Zughebeln und einem Lenkrad (teils in Form eines Rennwagen Slicksreifens). Auch diese wurden hier adaptiert.)
Den Luxus bieten auch hier analog zu Flugcockpits spezialisierte Autocockpits, mit Steuerrad und Gas-/Bremspedalen. Im Gegensatz zu den Fliegerpedalen sind letztere separat bewegend, mit je einem Pot, aber teils elektrisch in Serie geschalten und so dem Rechner als einen Pot erscheinend. Im Ruhezustand ist ein Pedal bei minimal und das andere bei maximal, was zusammen Halbe/Mitte ergibt, je nach Pedal benutzen werden sie dann zu beide-min oder beide-max. Beide Pedale durchtreten gibt min-zu-max plus max-zu-min und damit immer noch halb, was auch zu Gas und Bremsen gleichzeitig drücken passt. Erst später wurden separate Pots normal. Ebenfalls wurden Ganghebel addiert, intern nur normale Digitaljoysticks mit einer mechanischen "H" Laufwegsvorgabe. Diese benutzen wieder die Feuerknopfleitungen in Kombinationen, wie beim Coolie Hat.
Wieder (nach NES D-Pad und SNES Schultertasten) war es Nintendo, welche bei dem N64 einen kleinen Analogknubbel in die Mitte eines dadurch (zu) breit gewordenen Pads einbauten (zwischen D-Pad und Feuertasten), stets mit Federn, nie Ratsche. Dieser war wie der D-Pad wieder vorgesehen um mit dem Daumen benutzt zu werden. Das war in keinerlei Weise realistisch wie ein Cockpit, aber wieder kompakt und universell. Sega liess dabei als Verbesserung im Dreamcast die breite "Mitte" weg, und schob den Analogknubbel oberhalb des D-Pad.
Sony hat dieses Prinzip dann weit ausgebaut, zum Doppelanalogknubbel in Padform mit dem Playstation Analog Controller, mit beiden Daumen zu benutzen, in Anordnung wie bei einer klein geratenen Fliegerfernsteuerung, dazu kam noch der gewohnte D-Pad und die Feuertasten. In der PS2 Dual Shock 2 kam dazu noch dass Feuertasten die Druckmenge analog registrieren (darunter auch die Schultertasten). Dazu beinhaltet der Joypad einen eigenen Mikrocontroller, welcher aber mit der Playstation kommuniziert wie wenn er nur ein sehr langes PISO wäre. Damit wurde der heutige Maximalstand der Digital+Analog Joypads erreicht. Microsofts Xbox und Nintendos Gamecube haben nur links Analogknubbel und D-Pad ausgetauscht, und wurden damit unfreundlich asymmetrisch. (Anderseits haben manche kleineren Modelautofernsteuerungen auch diese Doppelknubbel Bauform kopiert, weniger extrem als dem Steuerrad plus 2 Zughebel.)
Gerade beim Editieren will man eigentlich die Zieldaten direkt ansteuern, was auf den Cursor herumschieben hinausläuft, direkt der Handbewegung folgend, und das ohne Limiten wie die Hand sich bewegt. Was nach nur relative Position bzw Bewegung aufnehmen verlangt. Das Resultat der Suche nach einem dazu geeigneten Eingabegerät führte zur Maus. Dies sogar erstaunlich früh, am Projekt NLS, in der zweiten Hälfte der 1960er, auf einem 12bit 4kWort Minirechner CDC160 von 1960 laufend!
Mit diesem 2bit Zähler seiner Relativbewegungsdifferenz kann dann ein grösserer Absolutposition Zähler in der Mauselektronik in die passende Richtung angetreiben werden (0-1 1-3 3-2 und 2-0 Wechsel sind alle +1, 0-2 2-3 3-1 1-0 Wechsel sind alle -1). Dieser kann dann wiederholt vom Treiber ausgelesen werden, und dabei auch ausgenullt werden, für die weitere Bewegung von neuem Null aus zählen, was wieder einen grösser aufgelösten Relativwert gibt, welcher zudem eine ganz normale Binärzahl sein kann. Diesen kann dann das System oder die Benutzerprogramme benutzen um die aktuelle (Maus-)Cursor Position passend zu verändern, inklusive die sichtbare Cursordarstellung zu verscheiben (sei dies durch löschen und neu zeichnen, oder durch ein Sprite mit dem Cursor darauf verschieben).
Als Interface dienten am Anfang noch PIO Ports mit den beiden Zälern dahinter. Plus noch PIO Pins für die Mausknöpfe, welche genau wie bei Joystick/Paddle Feuerkn&umul;pfe arbeiten. In der IBM PC Welt wurde schon im PC/AT das Tastaturinterface auf Benutzung eines 8042 umgestellt, weshalb die Busmaus (auch als InPort Maus bekannt) ebenfalls eine 8042 bekam, welche auch die ganze Zählerei machte (die Maus lieferte nur über einen 8pin Mini-DIN Stecker die rohen die 4 Quadraturbits und 2 Maustastenzustände (restliche 2 waren Strom). Daher mussten die Mausbewegungen (und Knopfbewedungen) dann als Serie von Bytes codiert werden, welche die 8042 ihre PIO transferieren kann, dem MS Maus Protokoll. Dieses besteht aus drei Bytes zu je 7bit, im Format 0ttxxyy 1xxxxxx 1yyyyyy, bei welchen die 0,1 nur erstes/anderes Byte erkennen und synchronisieren lassen, tt die Tastenpositionen sind, und xx xxxxxx bzw yy yyyyyy die 8bit Bewegungsmenge seit letzter &Uuuml;bermittlung sind. Die Bytes mussten vom Rechner aus wiederholt abgefragt/gepollt werden, mangels Interrupts.
Nur wollten viele Leute nicht mit ISA Bus Karten herumhantieren. Anderseits hatte der PC zwei RS232 Seriell/COM-Ports, von denen zumeist nur eine für ein Modem benutzt wurde. Die logische konsequenz war dann die Maus selber mit einem eingebauten Mikrocontroller auszustatten, welcher dann das Protokoll erzeugt und seriell verschickt. Dabei wurden zudem Interrupts benutzbar. Strom für die Maus wurde vom DTR Pin der RS232 genommen. Standard wurde dann COM1=9pin=Maus und COM2=25pin=Modem. Weil dieser Controller auch kein PIO vorgeben muss, kann man auch einen beliebigen Typ davon benutzen, wie auch in der Tastatur drinnen. Das ergab dann sie ganzen Serialmaus Varianten. Bei der PS/2 wurde dann aber statt RS232 und UART Chip im Rechner dann analog zu bei der Tastatur seriall mit einer weitern 8042 im PC benutzt. Seither benutzen Tastatur+Maus 2+2 Mikrocontroller!
Andere Rechner waren weit vernünftiger. Der Macintosh welcher erst die Maus zum Standard machte, hatte anfangs schlicht 4 RS232 Ports (bzw eigentlich RS425, ohne die +/-12V Wandler, mit 5V differential), bestehend aus 2 Zilog ZSCC 2-Port UART Chips, mit Tastatur Maus Drucker und Modem angeschrieben, und in allen vier Gerätesorten einen einzelnen dort passenden Mikrocontroller. Ab Mac SE wurden dann die beiden Tastatur und Maus Anschlüsse durch einen einzelnen ADB Anschluss ersetzt, technisch ein auf UART Chips aufbauendes langsames Netzwerk, welches durch alle Geräte hindurchgeschleift wurde. Dies it jeweils der Maus als letztes/abschliessendes, weil sie um beweglich zu sein nur einen Anschluss/Kabel hat. (Vergleichbares geschah mit dem Drucker Anschluss zu Localtalk erweitern, als langsames Netzwerk für geteilte Drucker und Fileserver, sowie später dem Modem Anschluss zum Geoport Netz werden, Anwendung mir unbekannt, bevor dann ab dem iMac alle kleinen Ports durch USB ersetzt wurden.)
Der Atari ST vereinfacht dies noch weiter. Dort hat es neben dem RS232 Port (ein 68901 MFP Chip) sowie dem MIDI Anschluss (ein einfacher 6850 Chip) einen weiteren internen 6850er als seriellen Link zu einem 6301 Mikrocontroller auf der Tastaturplatine, welcher dann neben der Tastatur scannen auch Joysticks (nur digital, keine Paddles) und Maus (vergleichbar mit der PC Bus/InPort Maus) macht, und dazu erst noch die Echtzeituhr liefert! (Diverse andere Rechner haben ebenfalls ihre Maus an der Tastatur angesteckt, mit der Maus selber nur PC Bus/InPort artig, z.B. der NeXT.)
Der Amiga ist hier ein totales Gemisch. Tastatur ist Mikrocontroller, aber nur für Tasten wie beim PC, dann mit einen UART am generellen IO Chip (Floppy+Serial), und damit eher wie vor-ADB Macintosh. Joysticks und Maus sind dagegen Ports am Rechner selber, aufgeteilt auf Feuertasten bzw Mausknöpfe an obigem IO Chip, und Joystick/Paddle/Maus Bewegungen am Videocontroller. (Im Atari 800 vom gleichen Chipdesigner waren die Paddles am generellen IO Chip (Sound+Paddles+Tastatur), keine Maus. Analog hatte der Commodore 64 seine Paddles am SID Soundchip, mit der später erhältlichen Maus an den Joystick Ports, welche normale 6526 PIOs waren, Signalformen mir unbekannt.)
Die erste NLS Maus war ein Holzklotz mit oben Knöpfe und unten zwei Schlitze mit je einem Rad darin mit Gummiring darum, direkt mir der Unterlage kontaktierend. In passender X oder X Drehrichtung wurden diese jeweils vom Gummiring mitgezogen und gerollt (weil beide Achsen horizontal waren), in der anderen Richtung nur seitlich geschleift (weil in Achsen Lägsrichtung). Rotation der Achsen drehte auch die Scheiben neben den Sensorpaaren welche die Graycodezähler antrieben, schleifen lies alles unverändert während der andere zählte, schräg zählten beide. Ähnliches wurde andernortes später mit fast vertikalen Achsen (leicht gekippt) und Radkanten auf der Unterlage liegend gemacht, als "rotierende Füsschen" bezeichnet.
Die weit werbreitetere Variante wurde aber die Rollkugelmaus. Hier hat nur eine gummierte Kugel Berührung mit der Unterlage. In der Maus drin hat es dann zwei Achsen mit Rollen/Walzen, welche von der Kugel angetrieben werden (und ein drittes gefedertes Rad welches die Kugel in Richtung Walzen drückt). Auch hier hat es auf den Achsen Scheiben, gefolgt von Sensorpaaren und den Graycodezählern. Dabei gibt es zwei Sensorformen, elektromechanische Maus mit einer Scheibe mit strahlenförmiger Kontaktfläche und die Sensoren nur zwei Kontakte welche darüber schleifen, und elektrooptische Maus mit einer Scheibe mit strahlenförmigen Lamellen und die Sensoren zwei Lichtschranken welche davon geschnitten werden. Letztere dominierte ab etwa 1990 weil robuster.
Weit billiger (und potentiell kleiner) war die optische Maus. Diese hat keine beweglichen Teile (ausser den Maustasten). Sie hat nur eine einzelne Lichtquelle, welche auf eine in beiden Dimensionen mit halbtransparenter Farbe im Quadraturcode von 2+2 Farben beschichteter Spezialmatte aus Aluminium. Dazu kamen dann 2+2 Lichtdetektoren, welche je nach der Farbkombination des aktuellen Punktes aktiv wurden, und genau den 2+2 Sensoren bei einer elektrooptische Maus entsprechen, mit identischer Elektronik dahinter. Neben billig waren diese aber wegen der Spezialmatte benötigen unbeliebt. Die Rollkugel Maus mit fakultativ direkte Oberfäche oder Mausmatte (und diese aus beliebigem Stoff oder Plastik) war einfach flexibler und damit akzeptierter.
Ebenso billiger (und potentiell kleiner), aber ohne Mattenprobleme ist die Kameramaus. Diese hat ebenfalls nur eine einzelne Lichtquelle, welche auf die Unterlage leuchtet. Aber diese kann eine beliebige Unterlage sein, solange sie irgendeine Musterung aufweist. Weil statt 2+2 Sensoren hat es hier eine kleine ca 100x100 Bildpunkte aufnehmende Kamera darin, welche sehr schnell mit ca 1kHz Rate Photos schiesst. Dahinter stehen Chips welche das aktuelle Bild mit dem vorhergehenden vergleichen, und daraus Bewegung erkennen. Dies braucht enorm viel mehr Rechenleistung, mehr als in den 1980ern der ganze Rechner hatte, aber heute sind Controller mit derartiger Leistung billig, weit billiger als Mechanik. Ohne Probleme mit Spezialmatte haben sich diese ab etwa Jahr 2000 vollends durchgesetzt. Lediglich Leute welche sich am Geblinke stören, gerade auch wenn dieses als "fortschrittlich" demonstrierende Show gut sichtbar herausgeleitet wird, blieben bei Rollkugeln. Eigentlich wäre dies alles auch durch Infrarot benutzen lösbar, aber das scheint sich nicht durchgesetzt zu haben, entweder weil die Köufer Show wollen, oder die Verkäufer ohne Show nicht anbieten wollen.
Neben der Sensorik kann man aber auch die grundlegende Gestaltungsform varieren. Dabei entsteht auch der Trackball, als "auf dem Rücken liegende Rollkugelmaus". Dabei wird die Kugel direkt von Hand gerollt, womit keine Fläche zum herumschieben gebraucht wird, und die Unterlage egal ist, Matten ebenso. Daher sind diese auch ideal bei portablen Geräten, wie in einigen 1990 Laptops. Problem hier ist, dass ohne bewegte Mausgehäusemasse (und Handmasse), mit nur der Kugel bewegt, diese schwer (und gross) sein muss um flüssige Bewegungen vom Mauscursor zu erzielen, während die Hand umgreift, wie es in manchen Videogame Automaten verwendet wurde. Was sie wiederum aber nicht portabel machte. Dazu gab es kleinkugelige nur mit dem Daumen zu benutzende Trackballs, teils sogar neben dem Laptop Deckel Bildschirm eingebaut, mit Maustasten auf der Deckel Rückseite/Aussenseite, welche aber wegen unruhigem Lauf unfreudlich blieben.
Auch hier gab es neben mechanischer Abtastung die Variante mit der Kamera. Hier bleibt zwar die Kugel, aber ohne restliche Mechanik. Diese ist dazu gezielt mit einem Punktemuster bedruckt, damit sie nicht einfarbig ist. Damit kann auch die Bewegung der Punkte von der Kamera registriert und vom Chip ausgewertet werden. Rest wie gehabt.
Aber auch ganz ohne Kugel geht hier. Analog zur ersten Radmaus gab in "Kleinversion" bereits schon seit den 1960ern auf Graphikterminals das Scrollrad, oder gar ein Scrollradpaar welches man aber separat und damit umständlich positionieren musste. Daraus entstanden auch als generelle Eingabe analoger Werte neben echten absoluten ortsgebenden Potentiometern auch scrollrad-artig laufende Pseudo-Potentiometer, mit Achse aus dem Gehäuse kommend, und einen Drehknopf oben drauf, mit relativen bewegungsgebenden Eingaben. Manche Workstations der 1990er hatten dann Achtersätze davon in 4x2 Anordnung, etwa halb gross wie die Tastatur. Auch hier kann Gewicht helfen, was in Videogame Automaten verwendet wurde, wo solche schweren Drehknöpfe als Spinners bekannt sind.
Dies änderte sich erst Mitte 1990er, nachdem Kontextmenus erschienen waren, die Maus dann einen Entwicklungsschub durchlief. Die dritte Taste wurde zum Standard, bzw genauer wurde sie "hinter" dem Scrollrad eingebaut. Teils wurde sogar ein seitlicher Scrollkipper versucht, aber das setzte sich nicht durch, da scrollen vor allem vertikal ist, weil Text auf die Fensterbreite umgebrochen wird. Hier kamen dann auch mehrere seitliche Tasten auf, gerade auch bei Gamermäsen. Auch die Kameramaus erschien gegen Ende dieser Zeit.
Diese Seite ist von Neil Franklin, letzte Änderung 2015.09.06