Dem Finder seine etwa 50k zusammen mit Videospeicher 2* 22k reserviert liessen von den originalen 128k nur etwa 30k frei! Das eben zuwenig war um benutzbar zu sein. Zudem wird wegen Platzmangel dauernd gerade unbenutztes aus dem Speicher gelöscht und bei Bedarf wieder nachgeladen von Floppy. Was das Laufwerk teilweise blockierte für Files, oft nach externem zweitem Laufwerk verlangte um viel Diskjockey zu vermeiden, und war selbst dann langsam. Was eben zum 512K führte, der nicht mehr dauernd löschem und nachladen musste.

Der 68000 erwartet ROM ab Adresse 0. Aber der Mac stellt dort RAM hin damit die Vektortabelle veränderbar ist. Also muss bei Reset das RAM deaktiviert werden und das ROM auch in den ersten 4M dupliziert sein. Dazu wird ein Bootflipflop benutzt, welches nach Reset in einem Zustand ist wo ROM das RAM ersetzt und nach Programmsprung in die echte ROM Adresslage auf den anderen Zustand gestellt wird. Dazu wird um Chips zu sparen einfach der Pin PA4 von der ohnehin vorhandenen 6522VIA benutzt, welches nach Reset ein Eingang ist, was alle Chips als "1" bewerten! Dieses Signal namens OVERLAY geht wie die Adressleitungen A21 bis A23 und /AS an das BMU1 PAL. Dieses selektioniert /RAM nur an seinem Ort $000000..$3FFFFF wenn OVERLAY=0, sonst an $060000..$07FFFFF, während /ROM an seinem Ort $400000..$7FFFFF wenn OVERLAY=0, sonst reduziert auf $400000..$5FFFFF plus am RAM Ort wenn OVERLAY=1.

(Vergleiche dies mit allen 8080/8085/Z80 Rechnern, welche ab $0000 booten, aber in CP/M Systemen dort Systemdaten und Parameter RAM brauchen, mit System selber oben bei $FFFF, auch mit etwas derartigem daherkommen, oft ein Bootflipflop.)

(Die PC/XT/AT 80x86 Prozessoren sind in der Hinsicht intelligenter designt. Sie erwarten ROM an der Adresse FFFF:0000. Solches ist nicht an Adresse 0000:0000, kollidiert so niemals mit dort RAM haben wegen Vektortabelle. Also haben alle 80x86 Rechner kein Bootflipflop.)

(Vergleiche dies mit allen 6502/6800/6809 Rechnern, welche Zeropage RAM bei $0000 und Boot+Vektoren in ROM bei $FFFF haben, aber in den seltensten Fällen mit einem Bootflipflop daherkommen, weil sie ihre wenigen Vektoren einfach ins RAM zeigen lassen, dort mit Sprung weiter gehen.))

Der Mac Plus hat stets 2 64kx8bit Chips mit 2*64=128k. Wieder wegen 16bit Speicher als 64kWort, nicht 2*64kByte. Da der Plus eine voll kompatible Erweiterung ist, und die neuen ROMs nur mehr Zeugs beinhalten, können diese auch in 128K/512K Hardware verbaut werden, welche dann als 512K enhanced (512Ke) verkauft wurde. Wegen voll kompatibel sind auch bestehende 128K/512K damit nachrüstbar, wenn auch 128K Macs von daran interessierten Benutzern wohl bereits auf 512K erweitert sein dürften. Dazu müssen diese Chips aber selbiges 28pin Gehäuse haben. Weshalb das zusätzliche Adressbit nur anstelle einer der beiden /CE Ansteuersignale sein kann, anzunehmen dem an A20. Womit diese 128k als 2* 64kByte/32kWort erscheinen müssten, erstes 16* wiederholt (wegen keine A16..19 am Chip) in 400000..4FFFFF, zweites 16* in 500000..5FFFFF!

Der Mac SE hat stets 2 128kx8bit Chips mit 2*128=256k. Wieder 128kWort, nicht 2*128kByte. Diese sind nur in diesem nutzbar. Selbst der gleichzeitige Mac II hat bereits andere Version von ROMs.

Der Mac II Familie revidierte das Layout komplett. Der Mac II braucht andere Version von ROMs. Dies wegen nun 32bit sein, als 4er Sätze 8bit breiter Chips. Sie sind auch bei anderen Adressen liegend, 800000..8FFFFF in 16bit Modus, 40000000..4FFFFFFF in 32bit Modus.

(Dies alles in Kontrast zur Lisa, welche nur 2 8kx8bit Chips, als 8kWort, mit 16kByte BootROM hatte, alle Software von Disk ins RAM holte, wie bei PC/XT/AT.)

Floppy

Am Anfang waren die IBM 8" Floppy Laufwerke. Diese bestehen aus dem selbigen Material wie Magnetbänder, seien das IBM Bandlaufwerke oder Musikkassetten. Dies ist eine flexible Kunststoff Folie beschichtet mit Magnetpartikeln, in deren Magnetisierungsrichtung die Bits abgespeichert werden. Im Gegensatz zu Magnetbändern, welche hin und her bewegt werden müssen sind Floppys aber Disks, welche nur in einer Richtung gedreht werden, weil jeder Punkt nach einer Umdrehung wieder erreichbar wird. Die 8" Floppys laufen mit 360rpm, also 1/6 Sekunde pro Umlauf.

Bitrate war anfangs 250kbps mit der simplen Frequency Modulation (FM) Codierung (als Single Density (SD) vermarktet) oder später 500kbps mit der aufwendigeren Modified Frequency Modulation (MFM) Codierung (Double Density (DD)). Bei FM werden abwechselnd Taktpulse (stets vorhanden) und Datenpulse (nur bei Datenbit=1 vorhanden) verschickt, mit Abstand bei mit Datenpuls gleich lang wie Puls und sonst 3 Pulse lang, womit eine Serie 1er doppelte Frequenz hat von einer Serie 0er, daher der Name FM. Bei MFM werden bei genug 1er nur diese verschickt, ohne 50% Platz für die Taktpulse zu lassen, was eben doppelt so viele Daten erlaubt. Aber dort wo zwei 0er hinter einander kommen würden wird um 1/2 Bit versetzt ein Ersatztaktpuls geliefert um Pulslosigkeit zu vermeiden, was die Signalverstärker verstimmen würde, womit FM eben modifiziert ist zu MFM. Damit passen theoretisch kbps*1/6 max 41'666bit bzw 83'333bit auf eine Umdrehung. Die 8" Floppys haben 77 Kopfstellungen und damit Spuren, sowie 1 oder 2 Köpfe/Diskseiten, was dann die theoretisch maximale Kapazität ergibt, üblicherweise als unformatierte Kapazität bezeichnet.

Aber Disklaufwerke müssen in Sektoren unterteilt werden, damit sie blockweise separat beschreibbar sind, um Dateien zu addieren oder zu löschen. Genau dazu müssen die Floppys formatiert werden, wobei deren Platz aufgeteilt wird für Sektoridentifikation und Sektordaten, aber auch Platz ausgelassen werden muss für Umschaltzeiten (von ID lesen zu Daten schreiben und zurück) sowie um Drehzahlvariation ausgleichen (bei formatieren auf langsames Laufwerk sind die Sektoren kürzer, bei beschreiben auf schnellem werden sie länger gezogen) sowie um Gesammtmenge sicher hineinzupassen (auch bei formatieren in schnellstem Laufwerk mit am wenigsten Umfrehungszeit). Wobei ein ziemlicher Anteil vom Platz verloren geht, erst recht wenn man wegen primitiven 1970er Controllern nur 128Byte Sektoren benutzt mit viele Umschaltfelder, zumal der Verlust pro Sektor und auch der am Spurende etwa konstant sind.

Dann kamen die Shugart 5 1/4" MiniFloppy Laufwerke. Diese laufen mit reduzierten 300rpm, also 1/5 Sekunde pro Umlauf. Bitrate war nur noch halbe 125kbps mit FM oder 250kbps mit MFM. Beides um deren geringeren Durchmesser und Umlaufgeschwindigkeit auszugleichen. Damit passten wieder theoretisch kbps*1/5 max 25'000bit oder 50'000bit auf eine Spur. Sie haben 35 oder 40 oder 77 oder 80 Spuren, sowie 1 oder 2 Köpfe/Diskseiten.

Später kamen die Sony 3 1/2" MikroFloppy Laufwerke. Diese laufen ebenfalls mit 300rpm. Bitrate stets 250kbps mit MFM weil niemand mehr um die Zeit dumme FM Controller benutzt. Die geringeren Durchmesser und Umlaufgeschwindigkeit werden aber diesmal mit besseren Materialien ausgeglichen. Sie haben zudem stets 80 Spuren, aber weiterhin 1 oder 2 Köpfe/Diskseiten.

AT

Beim PC verwendete IBM Laufwerke mit 300rpm und 40 Spuren und 1 Kopf. Diese in voller Bauhöhe, identisch hoch wie 8", doppelt was heutige Desktop CD/DVD/Blueray Laufwerke haben. Dazu hat der PC einen NEC D765 Floppy Controller Chip an U6. Dieser kann aber von sich aus keine Laufwerksauswahl oder Motorsteuerung, kann aber im PC unbenutzte Kopfauswahl, also muss ein 74LS273 an U17 alles andere nachliefern. Er hat Bit0+1 Laufwerksauswahl 1..4, Bit2 Reset D765, Bit3 DMA erlauben, Bit4..7 die 4 Motorsteuerungen.

Dieser erzeugt normales MFM, wie bereits bei neueren CP/M Rechnern üblich geworden war, also 250kbps. Es werden 512Byte Sektoren formatiert um die Menge Verluste dazwischen auf 1/4 zu reduzieren (CP/M ging noch von 128Byte aus). Die theoretischen 50'000bit pro Spur wurden so beim PC in 8 Sektoren von je 512Bytes/4kBit aufgeteilt, also 32kbit der 50'000bit genutzt, also 65.5%. Auf der ganzen Floppy ergibt das 40*1*8*512=160kBytes (nicht 360k!).

Um die ankommenden Daten, immerhin 250kbps/8=31kByte/Sekunde, schnell zu lesen werden diese per Direct Memory Access (DMA) ohne Umweg durch den Prozessor in den Speicher transferiert. Dazu ist der Kanal 2 der 8257A DMA fest vom Floppy Controller benutzt. Interessanterweise wird das DRQ Signal der D765 mit dem 74LS175 an U25 um 4 Taktzyklen von 2MHz verzögert.

Da der Prozessor dabei nicht benötig wird, könnte er inzwischen anderes machen. Um ihn von Ende des Transfers zu informieren wird deswegen ein Interrupt ReQuest (IRQ) benutzt. Dazu ist der IRQ 6 fest vom Floppy Controller reserviert. Er wird aber zumeist nicht benutzt, weil der Prozessor unter MSDOS eh nichts anderes zu machen hat als zu warten!

Als IO Adressen nimmt der erste Floppy Controller $3F0-$3F7. Ein allfälliger zweiter $370-$377. Der originale benutzt dazu einen 74LS30 8-NAND Chip an U26 mit daran A4..A9 = 1 sowie A3 = 0 per 74LS02 an U27 (ergibt %11'1111'0xxx = $3F0). Ein zweiter braucht A8 invertierbar. ROM Adressen benutzen sie keine, weil ihre Treiber bereits im BIOS drin sind. Per Floppy Controller sind 2 Laufwerke benutzbar, daher ist der zweite Controller sehr selten.

Beim XT hat IBM einerseits Laufwerke mit 2 Köpfen benutzt. Weiterhin mit 300rpm und 40 Spuren. Ebenso in voller Bauhöhe. Weiter wurde seitens vom BIOS und/oder IBMBIO.SYS/IO.SYS auf 9 Sektoren erweitert, nachdem IBM den Laufwerken etwas mehr zutraute, also immerhin 36kbit der 50'000bit genutzt, nun 73.7%. Alte PC Laufwerke kamen so auf neu 40*1*9*512=180kByte, neue XT Laufwerke auf die weitherum bekannten 40*2*9*512=360kByte. (Strikte können solche Laufwerke sogar bis zu 10 Sektoren, damit 40kBit der 50'000bit, 81.9%, zusammen 400kByte, wie bei manchen CP/M Rechnern gesehen, sogar mit 80 Spuren dann 800kByte. Aber das wurde nicht zum PC Standard, war IBM wohl zuviel des Guten.)

Beim AT hat IBM dann High Density (HD) Laufwerke benutzt mit 360rpm und 80 Spuren und 2 Köpfen. Diese gleichzeitig auch nur noch in halber Bauhöhe. Der neue Controller erzeugt wieder MFM, aber mit 500kbps, also Timing genau wie wenn diese 8" Laufwerke wären! Die geringeren Durchmesser und Umlaufgeschwindigkeit werden ebenfalls mit besseren Materialien ausgeglichen. Die resultierenden 83'333bit pro Spur wurden beim AT in 15 Sektoren von je 512Bytes/4kBit aufgeteilt, also 60kbit der 83'333bit genutzt, 73.7%. Auf der ganzen Floppy ergibt die weitherum bekannten 80*2*15*512=1200kBytes. (Diese 1200kBytes sind keine 1.2MBytes, egal wie oft das aus Schreibfaulheit oder schlicht Ignoranz falsch so geschrieben wird, da solche ja 1.2*1024=1228.8kBytes wären. 1200kBytes entspechen dagegen sind 1200/1024=1.1718MByte.)

Für PC und XT Floppys benutzen bleiben die AT Laufwerke bei ihren 360rpm mit stattdessen die Bitrate auf 300kbps anheben. Was kompatibel bleibt, nur einfach 20% schneller ist. Problematisch ist dagegen der Wechsel von 40 auf 80 Spuren. Weil dazu wurden die Diskköpfe schmaler gebaut. Auf 80 Spur Laufwerken beschriebene Sektoren auf breiteren 40 Spur Laufwerken überschreiben geht ohne Probleme, egal wo man danach liest. Ebenso auf 40 Spur Laufwerken beschreiben und dann auf 80 Spur schmaleren überschreiben und nur noch dort lesen. Aber eine Floppy auch nur einmal in ihrer Existenz mit 40 Spur Laufwerk beschrieben und danach auf 80 Spur überschreiben (mit kein 40 Spur danach) und dann mit 40 Spur lesen ergibt ein Gemisch der neuen schmalen Daten und "Randreste" der alten breiten Daten. Auch darin kann der AT inkompatibel sein zu PC und XT.

Alle PC/XT/AT können fakultativ 3 1/2" Laufwerke benutzen, weil diese mit normalen 300rpm 80 Spur 5 1/4" in Parameter und Timing voll kompatibel sind. Mit 1 Kopf entstehen so 80*1*9*512=360kByte, mit 2 Köpfen 80*2*9*512=720kByte. (Auch hier sind 10 Sektoren und 800kByte machbar, aber nicht PC Standard.)

Der AT Controller kann bessere 3 1/2" Laufwerke und Floppydisks auch mit High Density beschreiben. Dabei bleiben die 300rpm fix, aber es gibt die vollen 500kbps, was bei 80 Spur mit 2 Köpfen die weitherum bekannten 80*2*18*512=1440kByte ergibt. Deren doppelte Bitrate muss komplett mit nochmals besseren Materialien ausgeglichen werden. Dies ist der Standard den IBM bei den PS/2 Rechnern setzte. (Auch diese 1440kByte sind keine 1.44MByte, da solche ja 1.44*1024=1474.56kBytes wären. 1440kBtes entspechen dagegen sind 1440/1024=1.4062MByte.)

Mac

Ab Plus und 512K enhanced (512Ke) und SE stets mit 2 Köpfen. Es ist wegen 100% kompatibel auch in bestehende 128K/512K nachrüstbar, da diese bereits ein Kopfauswahlsignal erzeugen. Nur 1 Kopf Laufwerke in diesen verbauen war wenig Ersparnis (etwa 2% bis 5% vom Laufwerkspreis und 1% bis 2% vom Rechnerpreis), limitierte aber wegen kompatibel bleiben von Install und Datentransfer Floppyformat auf halben Platz pro Floppy. Das war am falschen Ort gespart. Erst recht wenn man die ganze Preissteigerung von $1000 via $1500 und $2000 auf $2500 anschaut.

Ab Mac SE hat es endlich 2 interne Laufwerksschächte, statt externes Laufwerk. Was die oft gewollten 2 Laufwerke platzsparend erlaubt. Ausser der zweite Schacht hat eine Harddisk drin, welche aber ohnehin ein zweites Floppylaufwerk überflüssig macht.

Aber der Mac verwendt eine komplett eigene Codierung. Bereits im Apple II hat der Designer FM als zu ineffizient abgelehnt, weil es nur 50% Datenpulse und 50% Taktpulse benutzt, und MFM als zu kompliziert, weil es 100% Datenpulse hat aber bei 2 einander folgenden Nullen selektiv einen Taktpuls halbwegs dazwischen setzen muss. Er entwickelte statt dessen Group Code Recording (GCR). Dieses nimmt Daten in Bitgruppen und codiert sie in mehr Bits um, bei denen nur ein Teil der Bitkombinationen benutzt werden, bei denen sicher gestellt ist, dass keine zu langen Serien von Nullen vorkommen können. Ein Posting online behauptet, dass dabei 3*8bit auf 4*6bit verteilt werden, und diese per Tabelle auf 8bit umcodiert werden. Danach werden diese als Datenpulse ohne jegliche Taktpulse benutzt. Womit er weit mehr als die FM 50% Datenbits erreicht, mit 3/4 von 100%, trotz nur einem simplen 8 TTL Chips Controller, als die Woz Machine bekannt. Daher hat der Apple II auch nur 130kByte pro Floppy, trotz dessen 35 Spur 1 Kopf Laufwerken mit MFM etwa 150kByte erreichen könnten (sie hätten mit FM aber nur etwa 75kByte).

Der Mac übernimmt dieses GCR Format. Er verwendet dafür einen Customchip namens Integrated Woz Machine (IWM), der auch in Apple IIc und IIGS benutzt wird. Was mit 80 Spur und 1 Kopf (gleichviel wie XT 40 Spur und 2 Kopf) statt dem MFM 360kByte (und FM bloss 180kByte) etwa 270kByte erlauben würde. Aber der Mac kompensiert den Verlust mit variabler Drehzahl. Auf den inneren Spuren gelten die üblichen 300rpm. Aber je weiter aussen, und somit schnellerer Umfangsgeschwindigkeit wird der Motor gebremst auf konstante Umfangsgeschwindigkeit um in mehr Umlaufzeit mehr Sektoren unterzubringen. Damit wird der GCR Verlust sogar etwas überkompensiert auf 400kByte!

Interessanterweise kann der IWM die beiden Laufwerksauswahl Signale und Motorsteuerung erzeugen, aber nicht deren Kopfauswahlsignal. Das wohl weil der Apple II nur 1 Kopf Laufwerke hat. Dieses wird von der 6522VIA nachgeliefert von Pin PA5, Signal HD.SEL. Das ist so bereits im Original 128K so vorhanden, spezifisch auf 2 Köpfe vorbereitet! Die IWM selber erscheint an Adressen $C00000..$DFFFFF. Dessen Registeradressen RS0..RS3 kommen von Prozessoradressen A9..A12, also in 256 Wort Schritten (wie die 6522VIA). Die Datenleitungen sind an Prozessordaten D0..D7, also erscheint sie an Bytes mit ungeraden Adressen (im Gegensatz zur VIA). Offiziell benutzt wird sie ab $DFE1FF. Im Mac Plus ist sie reduziert auf $D00000..$DFFFFF.

Im Gegensatz zum PC/XT/AT benutzt der Mac keinerlei DMA oder Interrupts bei Floppyzugriffen. Dessen 68000 ist ja auch etwa 6* schneller als die 8088 von PC oder XT, und sie muss ohnehin in der Floppy Laufzeit die GCR Umrechnung machen. Der IWM ist dabei lediglich ein Signalkonverter. Dessen Treiberschreiber vom Mac ist stolz darauf, dass er nicht nur wie beim Apple II die Umrechnung beim lesen vorzu hinbekommt, sondern auch beim schreiben dies konnte, statt wie beim Apple II dies im Voraus machen zu müssen.

Der Mac IIx brachte erstmals ein High Density Laufwerk, von Apple anfangs FDHD und später SuperDrive genannt. Dieses verwendet normales MFM und 1440k im HD Modus, bleib aber bei GCR und 400oder800k im DD Modus. Damit dies machbar ist wurde der IWM Chip ersetzt durch einen Super IWM (SIWM).

Harddisk

Als erstes waren Harddisks schweineteuer. Obiger Taiwan AT hatte selbst in 1988 noch mit/ohne Harddisk (stets mit Controller, nur mit/ohne dem Laufwerksmechanismus!) eine Preisdifferenz von SFr1000 (etwa DM1000, Inflationskorrektur über *2, etwa SFr2000 oder Eur2000). Daher war Betrieb mit 2 Floppylaufwerken der Normalfall, wie unter CP/M schon. Das war selbst in 1988 noch so, und war es in 1984 erst recht.

Als zweites waren Harddisks auch noch langsam und klein. Eine Seagate ST225, welche obige SFr1000 kostete, war 5 1/4" halbhoch (gleich gross wie ein AT 1200k Floppylaufwerk). Sie lief mit 3600rpm und 5Mbps, also beides genau Faktor 10 über der 1200k Floppy. Auch die Zugriffszeit war etwa 1/10 so lang. Sie konnte 17 Sektoren zu 512Byte statt 15, aber nur weil die Platten stets im gleichen Laufwerk sind, und keine Reibung in einer Floppyhülle haben, so wenig Drehzahlvarianz entsteht. Die Mehrkapazität kam vor allem von den 615 statt 80 Spuren, sowie noch etwas von 4 statt 2 Köpfen. Das ergab 615*4*17*512=20910kByte statt 80*2*15*512=1200kBytes. (Die real bei mir dann gelieferte ST251 war 820 Spuren und 6 Köpfe, aber ansonsten identisch. Das ergab sogar 820*6*17*512=41820kByte.)

Des weiterem gab es damals eine echte Alternative mit RAM Disks. Diese gab es bereits in CP/M Rechnern. Dort war 64k RAM das nutzbare Maximum vom 8080/8085/Z80 Prozessor. Weshalb grössere Texte editieren nach auf Disk swappen rief, was bei Floppy schneckenlangsam war. (Harddisks waren damals erste Hälfte 1980er nahezu unbezahlbar, bzw vor 1980 schlicht nichtexistent.) Aber 4oder8 Bänke zu 8 64kx1bit RAMs ergaben 256oder512kByte, eine ordentliche Floppykapazität.

Die RAM Disk musste zwar bei jedem einschalten frisch von Floppy geladen werden, aber danach lief sie weit schneller als selbst eine Harddisk. Einmalig beim booten laden kann sie während man etwas anderes macht, die Ersparnis von schneller arbeiten sammelte sich über den ganzen Tag an. Logisch verlor sie bei ausschalten oder auch nur rebooten allen Inhalt, wurde daher nur für Programme und Tempfiles genutzt, reale Daten abspeichern ging stets auf Floppy hinaus. (Manche RAM Disks waren "reset-fest", mussten bei Reboot nicht neu geladen werden.) (Manche hatten sogar einen Akku, der deren Inhalt über Nacht am Leben hielt, seltener übers Wochenende.

Manche Rechner offerierten auch die Alternative einer EPROM Disk mit 8kx8 EPROMs, welche nicht nach jedem einschalten geladen werden muss, aber dafür bei Wechsel der Dateizusammenstellung neu gebrannt werden muss, zumindest die betroffenen n*8kByte der EPROMs.

AT

Daher konnte der AT alles analog übernehmen. Er konnte sogar als Slotkarte einen eigenen 16bit Fixed Disk and Diskette Drive Adapter benutzen. Darauf wurde der Western Digital WD1003 Chipsatz verwendet, der zum XT Xebec Chipsatz komplett inkompatibel ist. Aber das ist kein Problem, weil er mit einem neuen BIOS Erweiterungs ROM daherkommt. Ebenfalls in $C800..$CFFF. Er nutzt IO Adressen $1F0..$1FF (die ersten unterhalb von $200..$3FF vergebenen!) und DMA 3 sowie IRQ 14. Dieser beinhaltet neben Harddisk Controller auch gleich den Floppy Controller, um Slots zu sparen. Da hat IBM früh und solide geliefert, nicht verwunderlich bei einem Grossrechner Hersteller. Wo sie gepatzt haben ist bei der nutzbaren Diskkapazität. Das BIOS kenn nur einen kleinen Satz von festen Spuren/Köpfe/Sektoren Anordnungen. (Clone ihre BIOSe addierten bald benutzerdefinierte Konfigurationen.)

Auch hier bleiben Harddisks teuer. Aber der AT kann ja dank 286 bis zu 16MByte RAM. Spätestens nach erscheinen von 256kx1bit Chips und 1MByte RAM Erweiterungen wurden diese auch für massive RAM Disks benutzt, zumal ja auch von 1200kByte Floppy ladbar. Dies zuerst mit PCDOS VDISK.SYS, später mit MSDOS RAMDRIVE.SYS. (Und selbst nachdem Harddisks billiger wurden, konnten solche RAM Erweiterungen statt dessen als Harddisk Cache dienen, mit MSDOS SMARTDRV.SYS statt durch CONFIG.SYS BUFFERS= Platz in den unteren 640kByte zu verbrauchen.)

Alternativ kann ein PC/XT/AT auch mit Small Computer System Interface (SCSI) ausgestattet werden, und dazu passende Laufwerke nutzen. Auch das ist inkompatibel, aber machbar dank eigenem BIOS Erweiterungs ROM. Dies wurde teilweise in Desktops gemacht aber vor allem in Servern, wegen deren höherer Leistung und wegen bis zu 7 statt nur 2*2 Laufwerke. Weiter waren SCSI Systeme automatisch an das Diskvolumen anpassend, egal was die Spuren/Köpfe/Sektoren waren, weil das SCSI Protokoll nur Sektornummern 0..maximal kennt. Dazu äusserst beliebt waren die Adaptec AHA-1540 (ohne Floppycontroller) bzw AHA-1542 (mit diesem) Adapter, mit Busmaster DMA und eigenem Prozessor (auf AHA-1540/2B 8MHz Z80 und AHA-1540/2CF 10MHz Z80). Diese konnten wegen eigenem BIOS übrigens jedem Laufwerk unter 1GByte als 64 Köpfe und 32 Sektoren und 512Byte Sektoren ausgegeben, mit so genau 1MByte pro Spur, bis zu maximal 1023 Spuren hinauf, nicht ganz 1GByte!

Neben Harddisks wurde SCSI aber auch für Bandlaufwerke und CDROMs benutzt (ersteres vor allem in Servern für Backups, zweiteres vor allem in Desktops). Dazu in letzteren sehr beliebt waren die simplen langsamen aber billigen NCR5380 basierten Adapter, ohne Prozessor.

Später kam der Wechsel auf AT Attachment (ATA) Harddisk Laufwerke. Diese haben den WD1003 Controller gleich eingebaut. Daher auch deren alternativer Name Integrated Disk Electronics (IDE), wobei dieser Begriff strikte sowohl ATA wie auch SCSI Laufwerke abdeckt. Das ATA Kabel ist nichts anderes als ein 40pin Subset vom AT Bus seinen 62+36=98, nur genau die Signale welche der WD1003 davon genutzt hat. Da dieser 2 Laufwerke steuern konnte, hat jedes ATA Interface+Kabel bis zu 2 Laufwerke dran. Weil diese zusammen den WD1003 simulieren müssen, aber auch der erste alleine, werden sie als Master (kann alles) und Slave (kann nur ergäzen) gejumpert. Für mehr als zwei ist ein zweites ATA Interface+Kabel notwendig. Diese beiden erscheinen an IO Adressen $1F0..$1FF (wie gehabt) und $170..$17F (letzeres mit DMA 6 sowie IRQ 15).

Weil nur simuliertes WD1003 haben sie intern mehr eine SCSI-artige Schaltung. Mitsammt die realen Spuren/Köpfe/Sektoren verstecken wie bei SCSI. Hier aber zumeist mit der Kombination von WD1003 Register plus BIOS Parameter Limiten voll ausnutzen auf maximal 255(!) Köpfe und 63 Sektoren, pro Spur nicht ganz 8MByte, mit max 1023 davon nicht ganz 8GByte! Es wurde sogar eine Autokonfiguration addiert, damit Clone BIOSe die Konfiguration auslesen können.

ATAPI CDROMs und Bandlaufwerke sind schlicht SCSI Protokoll über einen ATA Kabel+Registersatz. Auch die moderneren Logical Block Address (LBA) Harddisks benutzen solches ATAPI Protokoll, damit eben wie bei SCSI lineare Sektornummern machbar, mit 28bit bis zu 2^28*512Byte=128GByte! Moderne SATA Laufwerke jeglicher Art, auch Harddisks, sind stets ATAPI, aber über eine serielle Form von ATA. Das alte parallele wird seither in PATA umbenannt.

Mac

Es gab externe Harddisk Boxen, welche man an einen der beiden Seriellports (Drucker oder Modem) anhängen konnte. Nur waren diese nicht bootfähig, weil sie Treiber von Floppy brauchten. Und sie waren wegen Seriellports nur 230.4kbps haben vergleichbar langsam wie die 250kbps einer Floppy, nur komfortabler und implizit ein 2 Laufwerke System. Andere interne Harddisks verlangten nach Mac zum jeweiligen Lieferanten einschicken, der den Prozessor auslötete und eine Hilfsplatine mit Harddisk Controller dazwischen einsetzte. Aber auch diese waren nicht bootfähig.

Erst die Mac Plus und SE addierten SCSI Bus Ports. Beim Plus noch ein semi-SCSI und nur für externe Diskboxen. Beim SE volles SCSI und ein internes 3 1/2" Laufwerk plus externe Diskboxen. Das erweiterte 128kByte ROM des Plus addierte bootfähig von Harddisk. SE behielt dies bei. Im 512K enhanced (512Ke) hat es kein SCSI, weil normale 512K Platine.

Erstaunlich wird deren NCR5380 SCSI Chip adressiert im ROM Platz an $580000..$5FFFFF! Also reduziert der Plus scheints den ROM Platz von 4MByte ($400000..$7FFFFF) auf 1MByte ($400000..$4FFFFF), wie auch den IWM von 2MByte auf 1MByte. Was nahelegt, dass dessen Äquivalent zum BMU1 PAL auch A20 verwertet. Sicher ist, dass der Plus die alte 5er Gruppe 20pin PALs neu aufteilt auf 6, mit 4 davon 20pin und 2 sogar 24pin. Leider gibt es keinerlei Doku zu ihrer Funktionsaufteilung oder gar Signalbelegung.

Video

Mac

Zudem hat es in 2*3 Jahren zweimal vervierfachtes RAM, insgesammt mal 16, was erlaubt auf das kleine 1kByte Textmodus von Apple II zu verzichten, nur noch Bitmapmodus zu verwenden. Zumal auch die von 6502 auf 68000 massiv angestiegene Prozessorleistung problemlos Text zu Pixel rendern und Bitmaps verschieben kann. Damit wird erst beliebige Fonts in beliebigen Bildpositionen ausgeben möglich, statt nur einem festen Font in festen Zeichenpositionen (wie Apple II).

Der Mac verlor daher dem Apple II seine mehrere schaltbaren Modi (nur noch Hires/Bitmap, kein Text oder Lowres/Blockgraphik) sowie dessen Zeichengenerator (weil Fonts nun in Bitmap gerendert, keine Text Hardware) und Zeilenwiederholung (weil stets Bitmap, keine mehrere Videozeilen pro Textzeile). Aber er verlor auch dessen Farben (weil nur auf den eingebauten 9" Schwarzweissmonitor gehend) und sein Zeileninterleave (wegen 32 Worte und 512 Pixel pro Zeile genau in 2^n passen). Beide Rechner und Monitor teilen Netzteil und Stromkabel und Schalter, wie auch das Gehäuse.

Wobei der Mac strikte nicht ein Rechner mit oben aufgesetztem Monitor ist (wie PET), sondern eher ein Monitor mit Rechner unten drin, zumal der Monitor Grösse und Aussehen dominiert. Genauer hat der Mac nur 2 grosse Platinen drin. Vertikal links das grössere "Analog Board" mit Stromanschluss und Schalter sowie Netzteil (inklusive selbst dem Akku für die Echtzeituhr und dessen Ladeschaltung) und alle Leistungselektronik von Monitor und Lautsprecher (inklusive selbst dem Lautsprecher drauf). Horizontal unten das kleinere "Logic Board" mit nur dem Rechner und die Ports (inklusive zu interne Floppy). Dazwischen ein einzelnes Kabel von Analog zu Logic, liefert Strom zu Logic und bekommt Video und Audio zurück.

Der Mac war anfangs als 8bit 6809 Rechner geplant. Dessen 8bit Speicher hätte nur 256x256 Pixel hergegeben (das braucht selbige 1MByte/s Bandbreite und 8kByte Platz wie Apple II seine 280x192). Es war geplant, diesen mit einem sehr schmalem Proportionalfont zu benutzen, "i" und vergleichbares nur 2 Pixel breit, "a" und einige andere 4, nur "m" und vergleichbare 6. Damit hätten etwa 256/4=64 Zeichen pro Zeile gepasst. Aber dann kam wegen Lisa Software nutzen die 68000, anfangs noch mit 8bit Speicher, was aber dank der Logik um 16bit Zugriffe vom Prozessor auf 2*8bit Speicher aufzuteilen auch 384x256 Pixel erlaubte. Mit mehr Zeichen von obigem Font. Schliesslich kam die 68000 doch zu vollem 16bit Speicher, was 512x342 Pixel erlaubte, was auf dem 9" Bildschirm zu etwa 72dpi wird. Mit darauf selbst normalen 6x12 Monospace Font passen, wie er auf vielen Nadeldruckern benutzt wird, inklusive Apple ihrem ImageWriter.

Ein Monitor zeichnet Zeilen bestehend aus Serien von Pixeln, die erste Zeile vom Bild von oben links nach rechts, dann weitere Zeilen direkt darunter, immer weiter abwärts bis zur untersten. Die Pixel beim Mac sind nur 1bpp, pures Schwarzweiss, ohne auch nur Graustufen. Dafür reicht als Signalgenerator bereits zwei 8bit 74LS166 PISO (Parallel In Serial Out) Shiftregister Chips. Sie werden einfach mit dem Pixeltakt von 15.6672MHz gepulst um 1 Bit pro Puls als Pixel auszugeben, mit dem Pixel oben links im obersten Bit vom ersten Wort, gefolgt von 15 weitere Pixel in diesem Wort. Wegen 2*8=16bit breit werden die PISO mit 1/16 Takt 0.9792MHz vom RAM geladen. Mit weitere 16 Pixel im zweiten Wort, 16 im dritten, bis letzte 16 im letzten. Die 512 Pixel pro Zeile sind so in 32 Worte zu je 16 Pixel gepackt. Da der Mac Pixel als 0=weiss und 1=schwarz codiert, haben die PISO ihren seriellen Eingang auf 5V=1 um ohne geladene Worte automatisch den schwarzen Rand und Rücklauf vom Bild zu erzeugen.

Die Speicheradressen vom RAM werden wie bereits beschrieben mit 4 74AS253 Chips angeliefert. Diese 4:1 Multiplexer nehmen 2*8oder9bit (je nach ob 128K oder 512K) Adresseshälften vom Prozessor, sowie weitere 2*8oder9bit vom Video Adressgenerator.

Die jeweils 16 Pixel herunterzählen geschieht im TSM PAL Chip. Dieser ist der eizige Chip im Mac, der die 16 15.6672MHz Takte kennt, muss also alle unter 1µs Signale generieren, oder zumindest anderen Chips dabei helfen. Er erzeugt daher auch nebenbei die meisten RAM Steuersignale. Diese angefangen mit den beiden Adresshälften laden. Stets Signal /RASF für die erste signalisieren. Selektiv /CAS0 und /CAS1 für die zweite, je nach ob die beiden Bytes vom Speicher oder nur eines benutzt werden. Letzteres ist abhängig vom Prozessor seiner Zugriffsart (16bit beide Bytes, oder 8bit nur eins und welches, mit Signalen /LDS und /UDS bekanntgegeben), sowie welcher Speicher gewollt ist (aus Signalen /RAM und /ROM), sowie ob Prozessor oder Video aktiv sind (aus µ/VID). Video auslesen arbeitet niemals mit einzelnen Bytes, stets ganze Worte. Das egal was Prozessor /LDS und /UDS meinen. Dazu noch den Videogenerator steuern mit Signal TC (vermutlich Trigger Counter) und 1M (ein etwa 1µs Wortzyklus Takt).

Dazu muss TSM noch die 74AS253 Chips zwischen den Adresshälften schalten, mit Signal 2M. Dieses ist aber ein L Ausgang und kein R Registerbit! Damit kann es nicht Teil von dessen 4bit Pixelzähler sein. Der besteht angenommen aus dem 8M Eingang vom TSG PAL plus Register 4M und 1M sowie unbekanntem 2MHz. Ich verdächtige hier, dass /RASF der fehlende Unbekannte ist, und 2M davon abgeleitet wird, vermutlich einfach etwas verzögert, um erst nach Adresshälfte angenommen die 74AS253 zu schalten, mit danach die beiden /CASn noch weiter verzögert. Damit wird zuerst eine Hälfte geschrieben mit /RASF, dann die Weiche gestellt mit 2M, dann die andere geschrieben mit beiden /CASn.

Was dem Mac fehlt ist ein doppelt schneller 7.8336/2=3.9168MHz Speicher, also läuft seiner mit nur 7.8336/4=1.9584MHz. Eben obiges "erstaunlich keine zu erwartende verdoppelte Taktfrequenz". Davon wird mit 0.9792MHz die halbe Bandbreite für Videoausgabe gebraucht. Aber der 68000 will von sich aus die ganzen 1.9584MHz nutzen, also muss er während der Zeilenausgabe die halbe Zeit angehalten werden, bzw genauer die kollidierenden Speicherzugriffe um einen Zyklus verlängert werden, durch Signal /DTACK bis dann abwarten lassen. (Mit etwa 4MHz Speicher hätten Prozessor und Video je etwa 2MHz, mit Prozessor nur durch /DTACK auf seine Hälfte hin synchronisieren wenn er daneben liegt.)

Die Videoausgabe läuft pro Zeile 512 von 704 Pixel (32 von 44 Worte), plus Audioausgabe 1 Wort. Dadurch entstehen dem Mac seine 15667.200/704=22.254kHz Zeilen, und davon auch 22254/370=60.15Hz Bild. Daher wird der Mac bei RAM Zugriffen um (1/2) * ((512+1)/704) = 36.43% gebremst, weil auch ausserhalb vom Bild ausgeben angehalten. Letzteres weil es keine Schaltung hat um Refresh der DRAM Speicherchips zu machen (wie auch Apple II), denn das erledigen die Videozugriffe nebenbei! Dies weil DRAM Chips bei auslesen die Kondensatoren voll entladen/louml;schen, weshalb auf jedem lesen ein beschrieben/neuladen folgen muss. Was egal ob Prozessor oder Videozugriffe automatisch im Chip geschieht. Videozugriffe gehen prinzipiell seriell durch den Speicher, reichen also für den Refresh erzeugen! Daher muss aber auch ausserhalb der 342 angezeigten Zeilen in den restlichen 28 von 370 der Refresh aufrecht erhalten werden, sonst geht der Speicherinhalt in diesen 28*44.936=1258.2µs=1.2582ms teilweise verloren. Dies geschieht einfach mit Videozugriffe fortsetzen, nur ohne etwas anzuzeigen (wie Apple II). Ebenfalls werden Audiozugriffe fortgesetzt, nur mit diese stets ausgeben weil sonst Tonaussetzer.

Der 7.8336 Prozessortakt wird dadurch real zu 4.979MHz. Aber dies gilt nur bei Zugrffe auf RAM, weil dessen Ausgabedaten erst nach zu den beiden 74LS166 abgezweigt werden durch die 2 74LS244 Chips gehen. Letztere sind nur bei Prozessor liest RAM eingeschaltet, um nicht ROM und IO lesen oder jegliches schreiben zu stören. Dazu ist das /RAMRD (RAM Read) Signal vom BMU0 zuständig, neben dessen RAMR/W bei Prozessor schreibt. Bei Videoausgabe ist dieses stets aus, RAM vom Bus getrennt. Womit ROM oder IO Zugriffe nebenbei auch ungebremst sein können. Woraus am Schluss gemäss Apple ihrer offiziellen Dokumentation etwa 6MHz Durchschnitt herauskommen.

Unbestimmbar ist wer von BMU0 und TSM das /DTACK erzeugt, welches den Prozessor mitteilt, wann sein Speicherzugriff fertig ist. Bedingt durch wie 16R4 PALs konfiguriert werden können, mit beide Signale an L Pins, und damit Ausgang oder Eingang möglich, kann man nur annehmen, dass einer generiert und der andere mithorcht (der Prozessor hat Eingang, horcht stets). Ich vermute TSM als erzeugend, weil er µ/VID sehen kann, davon weiss ob der Prozessor den ersten Zugriff von zweien verlieren soll. Womit BMU0 dies indirekt aus fehlendem /DTACK horchen folgern kann, um RAMR/W richtig zu setzen.

Dieser Verlust ist so, weil dem Mac seine TSM Timingschaltung kein Prozessor/Video Speicherinterleave kann, trotz vom Apple II inspiriert zu sein, der dies bereits in 1977 hinbekam, als erster überhaupt! Dort mit etwa 2MHz Speicher sowie Prozessor und Video je etwa 1MHz, daher wäre hier eben etwa 4MHz Speicher sowie Prozessor und Video je etwa 2MHz zu machen. Das ist aber nicht so. Dies möglicherweise weil der Mac Designer den etwas schwierigeren Trick für es auf einer 68000 machen nicht kannte, weil er nur aus der 6502 basierten Apple II Schaltung gelernt hat, was dies zu einer Designschwäche macht. Oder er kannte den Trick und wollte schlicht den etwas höheren Aufwand sparen, weil als Ziel bloss einen elektronischen Schreibmaschinenersatz in Sicht, was dafür ein völlig akzeptabler Kompromiss wäre. Gefolgt aber von dies beibehalten nach der Umfokussierung auf Lisa Ersatz, was eine fragwürdige Designentscheidung ist.

Die Videoadressen müssen vom ersten Wort des Bildes durch alle anderen hindurch gezählt werden. Diese können direkt aus dem Pixel und Zeilen Zählern genommen werden, da 32 Worte pro Zeile genau in die 2^n Serie (1,2,4,8,16,32,64,128,256,...) passen. Dazu braucht es 5bit Wort-in-Zeile sowie 9bit Zeile-in-Bild. Diese 5+9bit ergeben eine 14bit Videoadresse. Dazu hat es 2 simple 74LS393 2*4bit Zählerchips. Zusammen ergeben sie 16bit, von denen nur die ersten 14bit genutzt werden. Diese werden von obigem TC angetrieben. Sie reichen mit 14bit strikte für bis zu 16kWort=32kByte Speicher. Davon werden aber nur 342*32=10944Worte benutzt, also 21888Bytes, oft zu 22kByte aufgerundet geschrieben.

Die obersten beiden Adressbits werden etwas modifiziert im BMU0 PAL. Die Signale VA12 und VA13 (Video Address) werden abgeleitet von den 74LS393 ihren VA9 bis VA11 sowie L12 und L13 (Linear). Ich vermute es wird ein Offset addiert, um nicht die ersten 22k von 32k zu benutzen, mit einem Loch danach. Ebenso tut BMU0 die 74LS166 Ausgabe nachbearbeiten von Signal /SERVID zu /VIDOUT, ich vermute Signal invertieren (von 1 = schwarz auf 0 = aus). Sowie weitere RAM Steuersignale erzeugen, RAMR/W (RAM Read / Write) bei Prozessor von dessen R/W Signal genommen bzw bei Video stets R.

Des weiteren kann der Mac wie beim Apple II zwei Videospeicher benutzen, main/primary und alternate/secondary, für Doublebuffer und Compositing Techniken. Dazu wird ein zweiter Bildspeicher angelegt, eben der doppelte Buffer. Dann wird er gelöscht und mit neuem Bild von Null aufbauen gefült, dem Compositing. Nach fertigzeichnen wird auf diesen anzeigen umgestellt, und während er sichtbar ist der alte gelöscht und mit drittem Bild von Null gefült. Danach wieder umschalten, löschen und viertes, und so weiter. Weshalb ein weiteres Adressbit von der 6522VIA geliefert wird von Pin PA6, Signal /VID.PG2 (Video Page 2). Da der Speicher aber 16oder18bit Adressen braucht (je nach ob 128K oder 512K) werden die restlichen hart auf "1" gestellt. Weshalb Video stets in den letzten beiden 32k ist, bei 128K $010000..$0FFFFF, bei 512K $070000..$07FFFFF, mit davon main/primary im allerletzten 32k, ab Adresse $0xA700, bzw alternate/secondary im zweitletzten, ab $0x2700. Die Differenz von $0xA700-$0x2700=$0x8000 ist das VIA Bit als Adressbit A15, für main/primary auf 1 gesetzt. Die $0x2700 sind wohl was BMU0 addiert.

Die ganze Videoablaufsteuerung wird vom LAG PAL gemacht. Er bekommt dazu TC und 1M vom TSM. Damit macht er vieles:

• Er erzeugt den 1-von-16 Pixelpuls zum 74LS166 seinen Lade-oder-Shift Schalter, mit Signal /LDPS (LoaD Parallel Shifter). Dieses ist abhängig davon ob gerade in Bild (1/16 Load) oder nicht (15/16 Shift, ohne Load gibt immer seriellen Eingang 1 = schwarze Pixel). Die dazu nötige nur 1 Pixel Länge kommt vermutlich von Signal TC, weil nur dessen Erzeuger TSM einzelne Pixel zählen kann, und sein Signal 1M sehr wahrscheinlich je 8 Pixel lang 0 und 1 ist.
• Weiter muss LAG noch zwischen Prozessor und Video schalten, mit Signal µ/VID. Dieses ebenfalls abhängig davon ob gerade in Bild (nur jeder zweite Speicherzyklus Prozessor) oder nicht (immer Prozessor). Die dazu nötige Unterscheidung kommt vermutlich von 1M, weil nur noch dieses vom TSM kommt. Sowie neben diesen beiden auch zu Audio schalten, mit Signal /DMA, in der Zeit Prozessor und Video abschalten, mit Signal DMA (im 74LS04 Chip invertiert von /DMA). Dieses muss genau nach den 32 Worten Bild für 1 Wort aktiv sein.
• Weiter können die ersten 5von14bit der 2 74LS399 nur 32Worte pro Zeile zählen. Der LAG muss wegen Rücklaufzeit vom Monitor, während dieser nach einer Zeile von links nach rechts zeichnen wieder sich von rechts nach links positioniert, von 32 Worte auf 44 erweitern, mit dazu nur +12 erkennen, statt nochmals volle +32 weiterzählen lassen. Dies wird abgeleitet von VA0..VA3. Diese laufen pro Zeile zweimal 0..15 gefolgt von drittes mal nur 0..11 mit dann statt 12 zulassen auf 0 setzen, mit Signal RESNYB (RESet NYBble, 1Nybble = 4bit). Genauer muss RESNYB beim VA0..VA3 Schritt von 15 zu 16 auf 0 gehen (wie VA3), womit VA4 linear von 0 auf 1 zählt. Ansonsten muss er aber stets auf 0 sein, weil sonst bleiben VA0..VA3 wegen RESNYB=1 auf 0 hängen, RESNYB geht also erst bei 15 auf 1. Wegen der Wirkung auf VA0..VA3 darf das erst geschehen, nachdem die Videoadresse benutzt wurden ist, also wenn 1M und/oder µ/VID auf Prozessor zeigen. Von in 31 zu 32 darf RESNYB aber nicht pulsen, weil sonst VA4 auf 0 geht, und damit auch VA5..VA13 um eine Zeile erhöhen, was noch warten muss. Erst beim dritten Zyklus bei in 11 zu 12(=0) darf RESNYB pulsen, weil damit zugleich das 12 zu 0 erzeugt wird.
• Um selber die Worte auf 44 zu zählen, trotz dass VA0..VA3 nur 0..15 liefern, braucht LAG 2 mehr interne Bits. Eines ist sicher H4 (Horizontal), das vermutlich parallel zu VA4 läuft, aber bei 32..43 nicht auf 1 stehenbleibt sondern wieder zu 0 wird. Das andere muss nur bei 32..43 auf 1 gehen, ein hypothetiches H5. Es ist aber keines zu sehen! Nach ausschluss aller dazu sicher untauglichen Signale verbleibt nur /HSYNC, welches damit aber die ganze nicht-in-Bild Zeit aktiv sein müsste und nicht nur als Puls innerhalb der Zeit. Das wäre mit normalen Monitoren unmöglich, aber der speziell für den Mac designte kann genau darauf ausgelegt worden sein.
• Ebenso muss LAG innerhalb der +12Worte den horizontalen Monitor Synchronpuls erzeugen, auf Signal /HSYNC. Egal ob dieses ganze Zeit dauert oder nur ein Puls ist, ist sogar einfacher falls ersteres.
• Das H4 geht auch als Signal an die 6522VIA zu Pin PB6. Hinter diesem sitzt dessen programmierbarer Pulszähler/Timer, der somit beliebige Anzahl Videozeilen zählen kann, oder auf 1 gesetzt jede Zeile interrupten kann. H4 statt /HSYNC dazu nutzen erlaubt Interruptverarbeitung früher anzufangen.
• Weiter die beiden 342 Zeilen Bild und 370 Zeilen Frame erkennen, mit nach letzterem die ganze Videoadresse auf 0 setzen, mit Signal RESLIN (RESet LINear), plus allenfalls noch RESNYB. Dazu scheinen die Signale VC0 und VC1 (vermutlich Video Control oder Vertical Control) da zu sein. Diese werden nebenbei in BMU1 erzeugt aus VA6..VA8 und L13 sowie /VCA (das erlaubt 64 Worte = 2 Zeilen Auflösung und erkennen ob in Zeilen 256..369). Das /VCA wiederum wird nebenbei in BMU0 erzeugt aus VA9..VA11 und L12..L13 (erlaubt 512 Worte = 16 Zeilen). Zusammen werden damit 348-6=342 und 348+16+6=370 erkennbar.
• Ebenso muss LAG innerhalb der +28Zeilen den vertikalen Monitor Synchronpuls erzeugen, auf Signal /VSYNC. Vermutlich wie /HSYNC ganze Zeit oder Puls. Wobei /VSYNC auch noch an VIA zu Pin CA1 geht. Das kann für Programme mit Bildausgabe synchronisieren benutzt werden. Vermutlich vor allem die Audiogenerierung nachliefern. Aber auch Cursor blinken wird explizit angegeben.
• All das steckt in einem einzelnen 16R8 PAL Chip LAG! Wenn auch mit etwas Hilfe von drei anderen (TSM und BMU0 und BMU1).

AT

• Die ursprünglichen Monochrome Display Adapter (MDA) und Color Graphics Adapter (CGA) von 1981.
• Später folgten erweiterte Dritthersteller Hercules Graphics Card (HGC) oder Plantronics ColorPlus (C+) von 1982.
• Mit PCjr kam dessen eingebaute verdoppelte CGA von 1984.
• Dann kam der Enhanced Graphics Adapter (EGA) von 1984.
• Später folgten erweiterte Dritthersteller Super-EGA.
• Mit PS/2 kamen Multi-Color Graphics Adapter (MCGA, als vervierfachte CGA) und Video Gate Array (VGA, als erweiterte EGA) von 1987 dazu.
• Später folgten erweiterte Dritthersteller Super-VGA (SVGA).

Das ist ein ziemlicher Haufen, was dementsprechend auf viel Text hinaus läuft. Ich werde hier zwecks Aufbau zuerst alle einfachen Karten vergleichen, also MDA und CGA. Dann erweiterte HGC und C+ bis zu MCGA. Erst dann kommen komplexe dran, wie EGA und Super-EGA sowie VGA und SVGA. Das Resultat ist einiges an Text. Daher wird diese Sektion in mehrere Unterkapitel aufgeteilt, um einen Bandwurm zu vermeiden!

PC/XT/AT: MDA und CGA

• Bei MDA in Segmente $B000..$B7FF, und kompatible wie HGC sowie EGA/VGA in MDA Modus. Die MDA benutzt dazu einen 74LS138 an U51 um die Kombination von A15..A17 = 110 und A19 = 1 sowie A18 = 0 zu erkennen, was %1011'0xxx'xxxx'xxxx ergibt, eben $B000..$B7FF.
• Bei CGA in Segmente $B800..$BFFF, und kompatible wie C+ und MCGA sowie EGA/VGA in CGA Modus. Die CGA benutzt dazu einen 74LS138 an U19 um die Kombination von A15..A17 = 111 und A19 = 1 sowie A18 = 0 zu erkennen, was %1011'1xxx'xxxx'xxxx ergibt, eben $B800..$BFFF.
• Die EGA/VGA können beide obigen wenn sie emulieren und addieren im Eigenmodus $A000..$AFFF oder gar $A000..$BFFF.
• Die MCGA benutzt im Eigenmodus stets $A000..$AFFF, plus dazu $B800..$BFFF wenn nur CGA emulierend, kann kein MDA.

Die Register erscheinen ebenfalls verschieden:

• Bei MDA an IO Adressen $3B0..$3BF. Mit in 74LS08 an U46 A8..A9 = 1 (ergibt $3xx) sowie weitere 74LS138 an U52 A4+A5+A7 = 111 sowie A6 = 0 (ergibt %1011 = $B). Dieser wird gefolgt von einem dritten an U50 um einzelne Register anzusteuern.
• Bei CGA an IO Adressen $3D0..$3DF. Mit in 74LS08 an U41 A8..A9 = 1 (ergibt $3xx) sowie weitere 74LS138 an U18 A4+A6+A7 = 111 sowie A5 = 0 (ergibt %1101 = $D). Dieser wird gefolgt von einem dritten an U17 um einzelne Register anzusteuern.
• Die EGA/VGA und MCGA addieren noch $3C0..$3CF. Die EGA kann mit Jumper P3 umgesteckt werden um $2C0..$2CF (plus $2B0..$2BF oder $2D0..$2DF) zu benutzen, für zwei EGA Karten im System. Das erweiterte BIOS kann aber nur die erste nutzen.
• CGA/MCGA und EGA/VGA können auch IRQ 2 vom vertikalen Bildsignal her treiben, nicht aber MDA.

Es sind deshalb auch beide MDA und CGA Karte gleichzeitig möglich, was dem PC Zweimonitor Betrieb erlaubt. Dieses wurde oft für CAD Arbeitsplätze genutzt. Die EGA kann dabei üblicherweise anstelle von CGA gesetzt werden, oder seltener anstelle MDA, aber nicht zweifach wegen sonst $3C0..$3CF kollidieren, ausser auf $2xx umgestellt. VGA das selbige. (Dies ging erst mit SVGA verloren, als diese anfingen $A000..$BFFF voll zu benutzen, statt nur $A000..$AFFF, so selbst mit MDA kollidierten, und auch keine zwei SVGA mehr erlaubten.)

Bei der MDA ist die Videoausgabe 1.5bpp Schwarzweiss. Genauer hat sie 2bpp TTL auf dem Ausgang seinen 2 Pins, aber von den 4 Helligkeiten sind im MDA Spezialmonitor nur 3 genutzt, 0/3 2/3 3/3, weil das erste Bit als pixelweises 1=ein/0=aus wirkt aber das zweite nur als zeichenweises 1=hell/0=normal erzeugt wird. Manche Monitore(!) erlauben 0=aus+1=hell als 1/3 anzuzeigen, die Karte weiss aber nichts davon. Diese hat nur 1bpp vom Font an ein 8bit 74LS166 PISO Shiftregister an U32, weil alle eingeschalteten Pixel eines Zeichens identisch normal oder hell sind, ebenso alle ausgeschalteten, mit dem feststehenden Intensiv nur alle passenden Pixelbits +1/3 modifizieren.

Bei der CGA im Textmodus ist die Videoausgabe strikte 1bpp. Auch das mit nur ein 74LS166 PISO Shiftregister an U32, weil ebenfalls alle Pixel eines Zeichens die selbigen beiden 1=ein/0=aus Farben haben, mit den feststehenden Attributbits nur zwei Farben pro Zeichen vorgeben. Dieses mit Vordergrund als 16 Farben RGBI in Bits0..3 (strikte als 3..0=IRGB angeordnet), Hintergrund nur 8 Farben RGB in Bits4..6, weil Bit7 blinken aktiviert. Ausser Blink ist abgeschaltet im Steuerregister, dann hat es auch im Hintergrund volles RGBI. Selbst mit Blink eingeschaltet kann man für alle Zeichen Hintergrund Intensiv erzwingen mit dem Farbauswahlregister. Auch hier liegt es beim Monitor, ob Schwarz+I bei 0/3 bleibt oder zu 1/3 dunkelgrau wird (IBM Original bleibt 0/3). Ebenso ob Dunkelgelb als Braun erscheint (IBM Original macht Braun daraus, mit extra Logik dazu).

MDA übernimmt trotz keine Farben die identische Attributanordnung wie CGA. Lediglich mit nur RGB=0 Schwarz und RGB=7 Weiss, sowie bei Vordergrund RGB=1 (wäre Blau) zu Weiss mit Unterstrich versehen. Soweit das ungenaue Handbuch, genauer gilt nach Schaltplan RGB=0 Schwarz und RGB=1..7 alle Weiss, sowie Vorder=1 dieses mit Unterstrich. Dazu noch Vorder=0 blankt, ausser wenn zusammen mit Hinter=1..7 was reversiert, beide 1..7 bleibt aber wie Hinter=0. Ebenfalls mit Bit3 I für obige 1.5bpp Vordergrund normal/hell. Ebenfalls Bit7 Blink oder Hintergrund 1.5bpp.

(Das Steuerregister ist an MDA $3B8 und CGA $3D8. Es besteht aus einem 4bit 74LS175 an U58 bei MDA, bzw einem 6bit 74LS174 an U40 bei CGA. Bit0 CGA 1=80 Zeichen und MDA muss 1=80 sein sonst blockiert die Karte bei RAM Zugriff den Bus(!), Bit1 nur CGA 1=Bitmap 320 Pixel (MDA fehlend, auf =0 zu setzen), Bit2 nur CGA auf Composite Monitor 1=farblos als 4 Graustufen um NTSC Artefakte zu meiden auf Kosten von keine Farben (MDA =0), Bit3 beide Bildausgabe 1=einschalten, Bit4 nur CGA 1=Hires 640 Pixel (MDA fehlend). Bit5 beide 1=Blinkmodus/0=HintergrundI), Bit6+7 unbenutzt (beiden fehlend, =0 setzen).)

Bei beiden wird die selbige DE9f Buchse als Anschluss benutzt, sogar mit fast identischer Belegung. CGA hat 4bpp Belegung: Pin 1+2 GND, 3..5 RGB, 6 I, 7 unbenutzt, 8 Hsync mit Pulse positiv, 9 Vsync positiv. MDA hat 2bpp Belegung: Pin 1+2+6+8+9 sind identisch mit CGA, 3..5 nun unbenutzt, 7 Video, aber mit Vsync Pulse negativ. Trotz beide identisch aussehend und mechanisch verkehrte passend, aber signalmässig inkompatibel, gibt es keine Möglichkeit um in Software auf richtigen Monitortyp zu testen. Aber das bei MDA invertierte Vsync könnte vom Monitor genutzt werden um sich abzuschalten.

Bei beiden kommen die Zeichenmuster aus einem MK36000 Font ROM, bei MDA an U33 und bei CGA an U?? (nicht angeschrieben, weder in Schaltplan noch auf Platinenphotos, scheint von anderen Chips ihre Nummer auch U33 zu sein). Diese 8kx8bit ROMs haben Platz für 4 Fonts 0..3 (Auswahl mit den Adressleitungen A11..A12) zu je 256 Zeichen (A3..A10) zu 8 Zeilen (A0..A2) von 8 Pixel pro Zeile (Datenleitungen D0..D7). Pixeldaten im ROM sind somit jeweils 8 breite horizontale Pixelstreifen.

Bei CGA werden stets nur die 8 Pixel pro Zeichen ausgegeben. Da CGA und MDA Font die Pixel als 0=Hintergrund und 1=Vordergrund codiert, hat die PISO ihren seriellen Eingang auf 0 um ohne geladene Worte automatisch den schwarzen Rand vom Bild zu erzeugen. Der ganze Pixeltakt zu Speicherzyklen zu Font zu PISO Ablauf wird gesteuert von zwei 74S174 an U4 und U5 gefolgt von einigen Einzelgattern.

Bei MDA werden diese 8 erweitert auf 9 Pixel, durch nach dem achten entweder hart neuntes Pixel leer oder eine Kopie des achten. Dieses kommt als Signal SERIN, in 74LS175 an U29 verzögert von SERDATA, mit 74S11 an U26 das Bit liefern falls 74LS139 an U42 passende Zeichencodes erkennt. Daher sind die Graphikzeichen im PC seinen Code Page 437 (CP437) Font auch derart eigenartig verteilt, damit genau bei Zeichencodes $C0..$DF (binär %110x'xxxx) das weitere Pixel vom letztem kopiert werden kann, statt bei allen anderen ausgenullt zu werden! Damit ist die PISO ihr serieller Eingang nicht mehr 0, also muss SERDATA ausserhalb vom Bild mit Signal /CLR VIDEO auf 0 blockiert werden. Der ganze Pixeltakt zu Speicherzyklen zu Font zu PISO Ablauf wird gesteuert von einem 74S174 an U1 plus einen 74S112 an U5 gefolgt von einigen Einzelgattern.

Vertikal unterscheiden sie sich sogar noch mehr.

Die CGA gibt nur genau die 8 Zeilen vom ROM aus. Mit einem von 2 der 4 Fonts, per Jumper an Font ROM Pin A11 einstellbar, default +5V=1 per Widerstand R2=2.2kOhm, Jumper muss nach 0V=0 (A12 ist hart auf +5V=1). Was bei Jumper=0 5x7 dünne Linien Font 2 oder Jumper=1 7x7 dicke Linien (default) Font 3 in 8x8 Feld generiert. Davon sind Grossbuchstaben 7 Zeilen sowie Klein 5 plus Unterlänge 1. Dies ergibt 640x200 Pixel falls 80x25 Zeichen Modus (braucht CGA Digital RGBI Monitor 5153), oder 320x200 Pixel falls 40x25 Zeichen Modus (für NTSC Composite Monitor notwendig).

Die MDA aber erweitert auf 14 Zeilen im ROM, aus 2 der 4 Fonts zusammengesetzt! Mit Signal ROMA11 an A11 für 8+6 Zeilen aus Font 0 bzw 1 ausgegeben, wegen dessen Jumper J1 von +5V=1 invertiert zu 0 an A12 (also Fonts 9 und 1). Was 7x9 Zeichen in 9x14 Feld generiert. Davon Gross 9 Zeilen sowie Klein 6 plus Unter 2 und Leerabstand 3. Dies ergibt stets 720x350 bei immer 80x25 Zeichen.

Komplett nicht erwähnt im MDA Handbuch wird obiger Jumper J1, mit dem man auf diesem entweder MDA Modus 14 oder CGA-artig 8 Zeilen einstellen kann! Dies mit wie oben Widerstand nach +5V=1 und Jumper nach 0V=0. Damit wird Signal -Jumper erzeugt, und als inverses davon +Jumper. Ersteres geht in die Zeitsteuerung vom Pixeltakt, wohl um 8 statt 9 zu erzeugen. Letzteres geht zum Font ROM Pin A12 (damit A12=1 wie CGA, stets Font 3, dicke Linien). Dazu kann es den Pixeltakt umschalten von MDA auf CGA sowie ROMA11 auf +5V=1 festnageln (wie CGA ohne Jumper) mit Signal A an den 74LS153 an U24. Weiter Unterstrich abschalten mit Signal /G2B an den 74LS138 an U47.

Dies alles lässt vermuten, dass die MDA auch einen CGA Monitor treiben könnte. Das sogar mit Farben, weil laut Schaltplan alle RGBI Signale erzeugt werden, mit RGB an Pins 3..5 neben I an 6, entgegen der Stecker Dokumentation im Benutzerhandbuch! Deshalb hat die MDA wohl auch die vollen 8bit RGBI Attribute wie CGA, statt nur 4bit. Geschalten werden sie mit dem 74LS157 an U63. Aber dies ohne CGA Bitmapmodi, mangels 16k Speicher. Ebenso ohne NTSC Ausgangssignal mangels Farbencoder. Sowie ohne 40x25 dafür. Im PC MDA Dokumentation Schaltplan ist dies alles noch vermerkt, aber in der XT MDA nicht mehr, alle RGB Signalleitungen von Attributregister U31 zu U30 zu Schalter U63 zu Verstärker U64 zu Stecker fehlen, trotz die Chips wegen I Signal weiterhin alle dort sein! Es fehlt zudem bei beiden irgendeine Methode um obigen Jumper in Software auszulesen, um Video Timing auf CGA einzustellen. Was nahelegt, dass die 2 Videokarte und Videomodus DIP Schalter auf dem Systemboard einst nur Modus dieser einen Karte machen hätten sollen, bevor sie mit zwei Karten ihre heutige Auslegung bekamen!

Signal B an den 74LS153 an U24 schaltet den Pixeltakt hart auf 0V=0 ungetaktet und ebenso ROMA11. Damit entsteht kein Bild mehr, bzw strikte ein CGA Font Bild mit Pixel alle gleiche Farbe weil eingefroren. Weiter killt es die ganze Pixel-in-Zeichen Zähllogik, und damit alle davon abhängenden Taktsignale! Das Signal B kommt als /HRES vom Steuerregister, wenn Bit0 auf 0=40 Zeichen gestellt ist. Dies erklärt, warum danach bei Prozessor Zugriff auf das Video RAM die Wartelogik auf Speicherzugriff fertig einfriert, somit den Prozessor unendlich warten lässt, den Bus blockiert. Wozu all das gut sein soll hab ich keine blasse Ahnung. Es ist einfach IBM, die machen solche Sachen! Da dieses Problem mit nur eine nutzlose Leiterbahn nicht dort sein behoben wäre, erachte ich dies als groben Designfehler.

Die Zeichencodes und Attribute kommen aus eigenem Video RAM Speicher. Es kommen immer zuerst Zeichencodes (gerade Adressen ab 0) und dann Attribute (ungerade Adressen ab 1). Auf der MDA sind dies 4kByte, in 2kx16bit Anordnung, aus 2*4 2114 1kx4bit SRAM Chips. Bei der CGA dagegen 16kByte, in 16kx8bit Anordnung, aus 1*8 2118 16kx8bit DRAM Chips. Trennung vom Prozessor Datenbus ist bei MDA 2*8bit, mit 2 74LS244 an U22 und U19 bei beschreiben und 2 74LS374 an U21 und U20 beim auslesen, und bei CGA 1*8bit, mit 1 74LS244 an U36 bei schreiben und 1 74LS374 an U37 bei lesen. Beide 74LS374 sind Daten zwischenspeichernd, damit die Karte bereits weitermachen kann während der Prozessor Daten abholt. Dazu noch ein 74LS245 an U23 (MDA) oder U66 (CGA) egal in welche Richtung oder ob auf Video RAM oder Chip Register Zugriff, rein um die Last mehrerer Chips auf den Bus zu reduzieren. (CGA DRAM bekommt wie beim Mac nebenbei von den Videozugriffen seinen Refresh. CGA und erst recht MDA können nicht Prozessor DRAM refreshen, daher muss der 8257A DMA dies machen.)

Bei CGA gehen die Anzeigedaten zu 2 74273 Chips an U34 (Zeichencodes) und U35 (Attribute), in dieser Reihenfolge der Speicherzugriffe. Zeichen gehen weiter zum Font ROM und PISO, mit in letzterem gleichzeitig ankommen wie die Attribute in U35 landen. Attribute gehen zum Farbschalter bestehend aus den beiden 74153 an U9 (Rot+Grün) und U10 (Blau+Intensiv), geschaltet durch Signale MUX A und B, mit 00=Vordergrund, 01=Hintergrund, 10=Bitmapmodus, 11=Randfarbe (schwarzen Rücklauf vom Bild entsteht wenn Signal STR=0). Bei Textmodus und im Bild drin ist MUX A einfach die Pixel vom PISO und MUX B =0. Der 74S08 an U31 in der Leitung von U35 zu U10 killt Hintergrund I falls Bit7=1 auf Blinkmodus ist. Nachher kommt noch ein 74S174 an U101 um sie um ein Pixel zu verzögern, sowie ein 74LS244 an U67 um Monitor Signale zu verstärken/entkoppeln.

Bei MDA gehen Anzeigedaten zu 2 74LS273 Chips an U34 (Zeichencodes) und U31 (Attribute), hier wegen 16bit Video RAM gleichzeitig. Zeichen gehen weiter zum Font ROM und PISO, wie bei CGA. Attribute gehen einerseits analog zu CGA, nur wegen obigem gleichzeitig via einem weiterem 74LS273 an U30 zwecks verzögern bis Zeichen im PISO ankommen, gesteuert vom Signal Q5. Weiter zu 74LS157 an U63 um Vordergrund und Hintergrund RGB Farben zu schalten mit Signal SEL (wenn mit CGA Monitor benutzt) und Intensität (beide Monitore). Der 74LS08 an U46 in der Leitung von U30 zu U63 killt Hintergrund I. Dies treibt den CGA Monitor.

Anderseits gehen sie für MDA Monitor zu decodieren an zwei 74LS138 an U49 (Vordergrund) und U48 (Hintergrund) um spezifische Helligkeitswerte 0..7 zu erkennen. Das erste 74LS02 an U27 erkennt Vorder=0 mit Hinter=0 und killt per Signal -NODISP die Pixel, das zweite erkennt Vorder=0 mit Hinter=7 und reversiert per Signal +RVV die Pixel. (Bei Vorder=7 mit Hinter=0 entsteht normal, bei Vorder=7 mit Hinter=7 auch! Alle 1..6 gelten als 7.) Daneben hat es den 74LS138 an U47 um Unterstrich in Videozeile 12 von 0..13 in der Zeichenzeile zu erzeugen, falls mit Vorder=1 bestellt, gefolgt von 74S32 an U43 diesen als Pixel einfügen. Der 74LS175 an U29 dazwischen verzögert Signale bis Font da ist, auch von Q5 gesteuert. Als letztes kommt noch ein 74LS244 an U64 um Monitor Signale zu verstärken/entkoppeln.

Der Speicher kann hier ein Problem werden. Der Mac braucht nur 32Worte = 64Bytes pro Zeile, aber die MDA und CGA brauchen 80Bytepaare = 160Bytes pro Zeile, was weit schwieriger ist:

Bei MDA mit 16bit braucht das 2 Worte pro µs, also etwa 2MHz Zugriffe. Dessen schnellen SRAM Chips geben das locker her, mit noch genug Bandbreite verbleibend für etwa 1MHz Zugriffe vom Prozessor. Letzterer muss lediglich per Wartesignal am Bus kurz angehalten werden, weil er nicht synchron mit Video läuft. Dies weil seine Frequenz der Speicherzugriffe (4.772727/4=1.193182MHz) von der MDA ihrer (16.257/9=1.8063MHz) komplett abweicht, also nicht synchron sein kann. Genau deswegen braucht es die 74LS374 um Daten zwischenzuspeichern, nachdem die Karte sie mit ihrem Timing hergegeben hat, bis der Prozessor sie dann mit seiner nehmen kann. Ebenfalls deshalb muss der Prozessor angehalten werden bis die Karte mit ihrem Timing Daten hergibt und dann weiter bis dem Prozessor sein Timing passt. Genau letzteres versagt wenn mit Signal B von /HRES der Pixeltakt abgeschaltet ist, und damit die ganze Wartelogik einfriert.

Aber wegen CGA nur 8bit breit muss der Videogenerator in 80 Zeichen Modus die 160Bytes/Zeile als 4 Bytes statt 2 Worte pro µs aus dem Video RAM holen, also etwa 4MHz Zugriffe. All das erst noch mit langsameren DRAM Chips, womit keine Zeit mehr verbleibt für Prozessorzugriffe auf Video RAM. Da der Prozessor aber nicht eine ganze Zeile lang warten kann, wird bei Zugriff einfach der Speicher vom Videogenerator weggenommen, und dieser bekommt den aktuellen Prozessor Datentransfer zu sehen, statt dem bestellten Video Datentransfer! Weil keine Blankinglogik vorhanden ist, um diese Falschdaten auf Leerpixel auszunullen, erscheinen zufällige vom Prozessor transferierte Zeichen ihre Pixelstreifenmuster, statt die von gewollten Ort! Bei einer Serie von Speicherzugriffen erscheinen sie als viele zufällig über das Bild verteilt, kurz aufflackernd. Weshalb diese Auswirkung als Snow (= Schnee, im Sinne von Schneesturm) bekannt ist.

Dies kann nur verhindert werden durch in der Rücklaufzeit vom Monitor zeichnen. Dies muss in Software geschehen, durch Test auf Bit0 vom Statusregister gefolgt von abwarten. Was das BIOS macht. Aber dies kostet Wartezeit, trifft gerade animierende Software stark, wurde daher schnell fallengelassen, sobald genug Clones mit ausreichend schnellem Speicher verbreitet wurden, welche keinen Snow mehr hatten. Oder man schaltet bei grossen Operationen wie scrollen umkopieren einfach das Bild kurz mal ab mit Steuerregister Bit3=0. Was das BIOS auch macht. Aber auch bei animierender Software das Bild flackern lassen würde, nicht benutzt werden kann.

(Statusregister ist an MDA $3BA und CGA $3DA. Es besteht aus einem 4bit 74LS244 an U60 bei MDA, bzw an U24 bei CGA. Bit0 bei beiden obiger Test auf horizontal rücklaufend=1/zeichnend=0 (man wartet bis 0 dann bis 1 und kann dann schreiben), Bits1+2 sind bei CGA Light Pen Eingang (Bit1 Position wurde erfasst, Bit2 rein Knopfstatus), Bit3 bei CGA zweiter Test auf vertikal rücklaufend=1/zeichnend=0 aber bei MDA die aktuell gezeichnet werdenen Fontpixel. Wozu letzteres gut sein soll hab ich keine blasse Ahnung. Es ist einfach IBM!)

Das Video RAM muss addressiert werden. Dazu wird ein 6845 Cathode Ray Tube Controller (CRTC) Chip verwendet, in MDA an U35 in CGA an U38. Dieser macht alles ausser Daten zu Pixel senden! Er tut Zeichen in Zeile zählen, inklusive Rücklauf und Hsync Pulslänge. Dann weiter Videozeilen in Zeichenzeilen. Noch weiter Zeichenzeilen in Bild, inklusive Rücklauf und Vsync. Weiter zäht er separate Videoadressen, damit unabhängig von der horizontalen Auflösung. Mitsammt zeilenweise Wiederholung der Adressen bei Videozeilen in Zeichenzeilen. Und auch beim Font ROM die Videozeilen in Zeichenzeilen bestimmen. Die Adressen zwischen Prozessor und 6845 schalten geschieht bei der MDA mit drei 74LS157 4-fach 2:1 Multiplexern an U18 und U17 und U16, aber bei der CGA mit zwei Paaren 74LS374 8-fach Flipflops mit Tristates (von Prozessor durch die an U60 und U61, von 6845 die an U59 und U58). (Was im Mac die 4 74AS253 machen.)

Alles Timing ist frei programmierbar, passend zu wie der 6845 in der Schaltung verdrahtet ist. Dazu hat er IO an Adressen $3B4+$3B5 bei MDA und $3D4+$3D5 bei CGA, und im BIOS Datenbereich an $0040:0063 die 6845 Adresse der installierten Karte. Von diesen Adressen muss man mit der ersten eines der 18 internen Register (0..17) auswählen, und mit der zweiten dieses beschreiben bzw auslesen. Davon sind nur 0..15 beschreibbar (16+17 sind Lightpen Status). Mit Registern 0..9 formatiert er die Anzeige.

Diese Register sind zumeist nicht lesbar, nur 14..17 lesbar (14+15 sind Cursor Position). Weshalb auslesen für später restaurieren nicht geht. Um diesen Hardwaremangel zu umgehen, hat IBM ein Segment $0040 einen Adressblock namens Video Display Data Area (VDDA) vorgesehen, an Adressen 0040:0049..0066 (MDA+CGA) und 0040:0084..008A (EGA Erweiterung), in den die Videokonfiguration vor setzen abgespeichert werden sollte, damit restaurieren von dort geht. Logisch ist dessen Format nicht einfach eine Kopie der Register, also wird programmieren dadurch aufwendiger. (EGA macht noch zudem 12+13 (Video RAM Anfangsadresse) lesbar. Erst bei MCGA und VGA sind alle davon lesbar.))

Bei CGA ist das Timing somit 14.31818MHz Pixel, 8 pro Zeichen = 1.7897725MHz, mit 80von114 Zeichen = 15.69976kHz Horizontal (nominell 15.750kHz), und dies mit 25von32 Zeichen zu je 8 Zeilen plus 6 Einzelzeilen für 262 = 59.92275Hz Vertikal (nominell 60Hz), weil kompatibel zu NTSC.

Bei MDA ist es dagegen 16.257MHz Pixel, 9 pro Zeichen = 1.8063MHz, mit 80von98 Zeichen = 18.432kHz Horizontal und dies mit 25von26 Zeichen zu je 14 Zeilen plus 6 Einzelzeilen für 370 = 49.816Hz Vertikal (nominell 50Hz). Nur langsame 50Hz würde massiv flimmern, also hat der 12" MDA Spezialmonitor 5151 eine lange Phosphorpersistenz, was aber wegen langsam verlöschend eine verschmierende Cursorbewegung produziert.

Die Bildanfangsadresse der 6845 ist beliebig im Video RAM positionierbar, mit Registerpaar 12+13. Man kann sogar mit dieser +2 oder +160 verschieben zeichenweise oder zeilenweise im Video RAM in Hardware scrollen, ohne Daten umzukopieren! Das geht weil dieses weniger als 32k gross ist, damit bei 4k und 16k 3 bzw 1 Adressleitung ignoriert werden, zirkulärer Speicher entsteht. Dabei wird zuerst der unbenutzte Restspeicher aufgebraucht, dann wegen Adressbits überlaufen der nun nicht mehr benutzte Anfang davon. Dabei kann die Software ebenfalls in zu hohe Adressen aufsteigen, bis zu 2*4=8k oder 2*16=32k hinauf, bevor der Anfang wieder auf richtig zu setzen ist, um zu vermeiden dass irgendwann anderer Speicher ausserhalb der Videokarte getroffen wird. Man kann sogar für vertikal fein scrollen die erste Zeile Text verkürzt erst ab n-ter Zeile Font ausgeben lassen, mit Register 8. Auf der CGA kann man so sogar nebenbei die 16k als 4 Seiten von je 4k benutzen. Damit könnte man sogar bis zu 3 Seiten an oben weggescrollte Zeilen wieder holen, aber das primitive PC BIOS nutzt sowas nicht aus.

Der 6845 kann auch den Cursor automatisch anzeigen lassen, mit Registern 10+11 Form (in welchen Videozeilen des Zeichens) und mit Registern 14+15 Zeichenposition. Zudem kann er auf Lightpen oder Lightgun Eingang reagieren mit aktueller Ausgabeposition aufzeichnen, auslesbar in Register 17+18. (Also alles und viel mehr von was im Mac LAG + 2 74LS393 machen.)

Die 6845 ist wegen Programmierbarkeit auch ideal um mehrere schaltbare Videomodi zu implementieren. Die CGA kann daher neben Farben auch Bitmapgraphik (welches IBM stets APA nennt, All Points Adressable). Dabei wird sie von obigen Steuerregister $3D8 mit Bit1=1 bzw Bit4=1 umkonfiguriert. Die ganzen 16kByte werden damit zu Bitmapdaten, 640x200 Pixel 1bpp (Bit4=1) oder 320x200 Pixel 2bpp (Bit1=1). Diese sind als 8*1bpp bzw 4*2bpp pro Byte im Speicher, mit dem Pixel oben links im obersten Bit bzw Bitpaar vom ersten Byte, gefolgt von 7 bzw 3 weitere Pixel in diesem Byte. Diese werden nach den beiden 74LS273 an U34 und U35 neben an Font ROM und Attributlogik auch mit 2 separaten weiteren 74LS166 PISO Chips an U7 und U8 ausgegeben. Strikte erzeugen sie so nur 320 Pixel 2bpp, für 640 Pixel 1bpp wird schnell zwischen beiden hin und her geschalten mit dem 74LS51 an U48.

Wegen Charaktercodes+Attribute hat es zuerst die Prozessor Adressbits A1..A12 (nicht ab A0, das schaltet Char oder Attr) und 6845 A0..A11 an Video RAM A0..A11 für 2^12=4096 Bytepaare adressieren! Erst danach kommen Prozessor A0 und A13 an Video RAM A12..A13.

Aber anstelle von 6845 ist an A12 nun /HCLK um in Textmodus die beiden Bytes pro Zeichen zu holen, und in Bitmapmodus um zwei Zeichenpositionen ihre einzelnen Bytes zu holen mit dann zweite Zeichenzeit lang Pause machen für Prozessorzugriff. Es werden bei Bitmap nur noch 80*1 statt 80*2 Bytes Bytes/Zeile gebraucht. Damit auch nur 2 Bytes pro µs, also kein Snow mehr hier. Dazu wird die 6845 ihr Takt von /CCLK (Character Clock) umgeschaltet in einem weiteren 7451 an U27, für 80 Zeichen von HCLK (High Clock) bzw für Bitmap (und auch 40 Zeichen) von LCLK (Low Clock). Selbiges gilt auch bei 40 Zeichen mit 4*2, von dem das Timing hier übernommen wird. Daher brauchen beide Bitmapmodi auch im Steuerregister das Bit0 für 80 Zeichen Modus auf aus!

Dagegen kommt A13 von der 6845, aber umschaltbar mit dem 74LS51 an U48, in Textmodus ist es A12 von 6845 aber in Bitmapmodus RA0 von 6845. Das Video RAM muss auch in Bitmapmodus addressiert werden. Aber der 6845 zeigt hier eine Schwäche. Ausgelegt auf Textmodi kann man zwar Videozeilen in Zeichen auf 1 stellen, aber danach Zeichenzeilen in Bild auf 200von256 (plus 6 Einzelzeilen) geht nicht, weil mit 7bit Vertikal Register nur maximal 128 Zeichenzeilen zählbar sind! Also wird in der CGA ein Trick benutzt, die Ausgabe wird als 100von128 Zeichenzeilen zu je 2 Videozeilen eingestellt, statt Textmodus 25von32 zu je 8. Die 3 Video-in-Zeichen Bits RA0..RA2 gingen davor an das Font ROM, nun geht nur eines davon RA0 ans Video RAM A13, oberhalb der fest verdrahteten ersten 13 Zeichen-in-Bild A0..A12 (von denen Textmodus nur A0..A11 nutzt). Weshalb das Bitmap nichtlinear im Video RAM liegt, mit zuerst Zeilen 0,2,4,..,198 und dann 1,3,5,..,199, in Segmenten $B800..$B9F3 bzw $BA00..$BBF3.

(Programzugriff auf derartigen nichtlinearen Speicher macht man am sinnvollsten via einer Tabelle. Die wegen Multiplikation ohnehin langsame Adressrechnung von Videobasis+Y*Zeilenlänge+X wird am besten auf Tabelle[Y]+X verkürzt, mit dann nur noch die Tabelle generieren von nichtlinear sein betroffen. Bonuspunkte falls man die +X Addition auch noch einspart, mit nur X in Adresseregister und in der Tabelle Segmente statt Adressen, nur aus dieser das ohnehin notwendige ES: Register vom Prozessor laden tut, dann einfach die Segmentiereinheit implizit addieren lassen! Die 8088 mag bescheuert sein, aber hier hilft sie sogar. Diese Tabelle kann man schnell füllen, mit Segmente ab $B800 in +80Byte/+5Segmente Schritten in jeden zweiten Tabellenplatz schreiben, dann ab $BA00 in die bisher leer gelassenen Plätze. (Stikte könnte man mit selbiger Methode auch die CGA auf 25*8 lassen statt auf 100*2 gehen, so wie Apple II es macht. Nur ist dazu die CGA Verdrahtung der Video-in-Zeichen Bits ans Video RAM unpassend.)

Bei High Resolution 640x200 sind 0-Pixel und Rand stets schwarz, 1-Pixel bekommen Farbe von Farbauswahlregister Bit0..3. Dazu hat es ein weiteres nur-CGA Register an Adresse $3D9. Es besteht aus einem 74LS174 an U39. Es setzt Farben je nach Modus verschieden.

(Strikte hat 640x200 auf einem NTSC Farbmonitor wegen 14.31818MHz Timing noch die Möglichkeit, mit Farbauswahlregister auf Weiss noch 16 4er Serien von Viertelwellen Mustern von 3.579646MHz Wellen zu erzeugen. Allerdings nur, wenn entgegen der BIOS Konfiguration dieses Moduses das Bit2=0 wieder gelöscht wird, um Farbsignal zu erlauben. Die 80von114*8 Pixel werden damit zu 160von228*4 Wellen an Farbpixel. Diese Wellen werden von einem NTSC Monitor wegen dessen QAM Codierung als Farbsignale missverstanden. Wobei entsteht Pixelfolgen %0000=Schwarz und %1111=Weiss, weil gar keine Schwingung, und %0101=%1010=Grau, weil beide eine 14.31818/2=7.1591MHz Schwingung erzeugen, keine 3.5796MHz. Mit 3.5796MHz werden alle %0011 %0110 %1100 %1001 zu mittlere/50% Farben (Cyan Magenta Orange Grün), alle %0111 %1110 %1101 %1011 zu helle/75% Farben (Hellblau Rosa Gelb Grünblau), alle %0001 %0010 %0100 %1000 zu dunkle/25% Farben (Dunkelgrün Dunkelblau Rot Braun), mit dabei Farbton aus der Bitanordnung und somit Phase der 1er Gruppe, sowie Helligkeit aus der Anzahl 1er. Daher auch 3+4+4+4=15 Farben statt 2^4=16, weil 2 mal Grau. Aber dies geht nur auf NTSC Monitor, ist mit dem üblicherweise verwendeten digitalen RGBI Monitor nicht benutzbar.)

Bei Medium Resolution 320x200 kommen 00-Pixel(!) und Rand von obigem Farbauswahlregister Bit0..3, weil 01/10/11 Pixel feste Farben generieren mit 01 Grün und 10 Rot sowie 11 zusammen Dunkelgelb/Braun. Selbiger Rand gilt auch beim Textmodus. Manche CGA können auch bei 01/10/11 mit Bit4=1 auf Intensiv Farben setzen. Selbiges Intensiv Bit gilt auch bei Blinkmodus für den Hintergrund. Mit Bit5=1 kann der 320x200 Farbsatz Blau addiert bekommen, für 01 Cyan und 10 Magenta sowie 11 zusammen Weiss. Mit Bit2=1 im Steuerregister 3D8 können manche CGA auch Blau=Grün addiert bekommen, für 01 Cyan und 10 Rot sowie 11 zusammen Weiss. Dies geht aber nur auf RGBI Monitor, weil auf Composite wird Bit2=1 zu farblos als 4 Graustufen.

Daneben gibt es ein semi-offizielles Low Resolution 160x100. Dieses ist eigentlich Textmodus 80x25, aber mit der 6845 umgestellt auf 80x100(!) Zeichen, zusammen mit passendem flachen 2 Videozeilen in Zeichenzeilen 1bpp "Font" Ausschnitt. Dann werden die Zeichencodes (jedes erste von zwei Bytes, 8von16k) fest mit dem ROM 2x1 Blockgraphik Zeichen 222 (hat links aus und rechts ein) gefüllt, was statt normalen 160x25 nun 160x100 gibt. Danach werden nur noch die Attribute (die zweiten Bytes, auch 8von16k) bearbeitet, mit Bits 7..4 (Hintergrund) links und Bits 3..0 (Vordergrund) rechts erscheinend, die beiden 4bit Farben als 4bpp auf die resultierenden zwei 4x2 grossen Block-Pixel verteilend.

Dieser ergibt absolut brauchbare 160x100 4bpp mit den vollen 16 RGBI Farben, sogar auf digitalen RGBI Monitor! Bonuspunkte, wenn man auch noch beliebige andere Zeichen ihre oberen 2 Zeilen als feinere 640x200 Musterung nutzen kann. Dies wird manchmal als "Tweak Mode" bezeichnet. Nur war dies vielen Programmierern damals kompett unbekannt, weshalb nur wenige es nutzten! IBM selber bezeichnet dies im offiziellen Handbuch als "Low Resolution". Aber bemerkt noch, dass es "not supported in ROM" ist. Es gibt zudem nicht mal eine Anleitung wie man es macht, nur eine Aussage "requires special programming". Mit dabei erst noch fälschlich behauptet, dass es "set up as the 40 by 25 alphanumeric mode" ist, statt "80 by 25". (Aber auf der Basis vom 40x25 Modus würde mit 40x100 Zeichen und 2x1 Streifen-Pixel ein weit weniger nützliches 80x100 entstehen.)

PC/XT/AT: Verbesserte MDA und CGA

Die MGA wäre sehr einfach besser machbar gewesen, mit nur eines der verschwendeten Attributbits vom Font auf eine hartverdrahtete mit dem Font mischbare 2x4 Blockgraphik umschalten, mit dann die Zeichencode 8bit als 2x4 Blöcke auswerten. Was bei 80x25 Zeichen ebenfalls für 160x100 Blöcke ausgereicht hätte. (Dieses ist, wie der Kaypro 10 zeigt, ganz ordentlich brauchbar.) Das am besten mit neben Vordergrund Blau=unterstrichen entweder Vordergrund Grün=Blockgraphik oder Hintergrund Blau=Blockgraphik. Die Signale dazu sind an U49 bzw U48 bereits decodiert! Aufwand wäre nur 2 TTL Chips gewesen (74LS253 als Blockmuster Codierer und 74LS244 um Muster einzukoppeln). Oder besser falls genug Font ROM für die Blockmuster, diese als zweiten Font ablegen mit nur noch den Decoder an oberstes ROM Adresspin. (Ohne den Jumper für CGA Monitor und dessen Fontverbrauch wäre in 8kx8 ausreichend Platz frei.) Danach noch bei allen als Blockgraphik markierten Zeichen stets die 8 zu 9 Pixel breit Schaltung aktivieren. Oder besser das ganze 9 Pixel Zeugs loswerden, nur 640 Pixel breit, mit statt dessen Horizontalfrequenz erhöhen und 16 Zeilen hoch machen, wozu im Font ROM auch bereits genug Platz vorhanden ist. (Für wie das aussieht siehe Atari ST Mono Modus.)

Die CGA wäre auch einfach besser machbar gewesen, mit nur weiteren 160x200 4bpp Bitmapmodus addieren. (Dies ist, wie Acorn BBC und CPC zeigen, ganz ordentlich brauchbar.) Problem hierbei ist, die zwei Bitmap PISO müssten dazu statt 2*8bit nun 4*4bit sein, und die 640 Pixel hin und her schalten Logik müsste nun 4 statt 2 machen, plus 320 auch zweimal 2 schalten. Oder bei 2*8bit bleiben und fuer 4bpp Pixelpaare zusammenziehen. Wohl beides zuviel Aufwand. (BBC und CPC verwenden dazu einen Gate Array Customchip.)

Sobald Cloner auftauchten, haben manche die PC Graphik nicht nur kopiert sondern auch ausgebaut:

Am bekanntesten ist die Hercules Graphics Card (HGC), eine erweiterte MDA mit Bitmap Modus. Sie ist wie die CGA nur 8bit, aber mit 64kByte Video RAM, in 64kx8bit Anordnung, aus 1*8 4164 64kx1bit DRAM Chips. Wegen schnelleren Chips schafft sie nicht nur 160Byte/Zeile, sondern auch noch Prozessorzugriffe ohne Snow, oder sie hat zumindest eine Blankinglogik. Im Textmodus benimmt sie sich identisch mit der MDA. Parallel zu CGA hat sie im Steuerregister auch das Bit1 für Graphikmodus. Weiter noch eigenes Bit7, um Bild 1von2 Seiten von 32k aus der unteren oder oberen Hälfte vom 64k Speicher anzuzeigen, für Doublebuffer und Compositing Techniken (wie Mac VID.PG2). Statusregister hat wie MDA Bit3 plus Bit7 wie CGA ihr Bit3 wirkend. Dazu kommt ein weiteres Konfigurationsregister an $3BF, Bit0 erlaubt erst Bitmap, Bit1 erlaubt 64k Video RAM dem Prozessor sichtbar zu machen. Letzteres geht aber auf Kosten von der CGA ihre Segmente $B800..$BFFF wegzunehmen (wobei Hercules ihr eigener CGA Clone diesen Gebrauch erkennt und ihren Speicher auf unzugreifbar schaltet). Leider hat es keinen 2*32k von 64k in Segmente $B000..$B7FF sichtbar Schalter analog zu bei anzeigen. Videospeicher ist 90 Bytes pro Zeile, um 720 Pixel zu fassen, für selbige Pixelfrequenz. (Wobei eine Quelle behauptet Pixelfrequenz sei 16MHz statt 16.257MHz, Textzeilen 18.141kHz oder Bitmapzeilen 18.519kHz, Textbild 49.03Hz oder Bitmapbild 50.05Hz.) Damit passen strikte in 32k max 364 Zeilen (genau was Lisa benutzt). Da der MDA Spezialmonitor aber auf 350 ausgelegt ist, limitiert dies die HGC. Dann schlägt der 6845 erneut zu, also werden 87 Zeichenzeilen zu je 4 Videozeilen eingestellt, statt Textmodus 25 zu je 14, was noch 348 statt 350 Zeilen erlaubt. Weshalb das Bitmap im Video RAM liegt, mit zuerst Zeilen 0,4,8,..,344, dann 1,5,9,..,345, dann 2,6,10,..,346, dann 3,7,11,..,347, in Segmenten $B000..$B1E9 und $B200..$B3E9 und $B400..$B5E9 und $B600..$B7E9. (Mit obiger Tabellenmethode wäre 25 zu je 14 benutzen sinnvoller gewesen. Nur wird wohl wieder die HGC Verdrahtung der Video-in-Zeichen Bits ans Video RAM unpassend sein.

Weit weniger bekannt ist die Plantronics ColorPlus (C+), eine erweiterte CGA mit doppeltem Bildspeicher. Sie hat wie MDA 16bit, aber hier in 16kx16bit Anordnung, aus 1*16 4116 16kx1bit DRAM Chips, für 32kByte. Damit erst recht kein Snow. Im Textmodus benimmt sie sich identisch mit der CGA. Im Graphikmodus bringt sie zwei weitere Modi. Leider mir deren Programmierung nicht bekannt, weil die Karte selten ausgenutzt wurde, trotz wiederum von Paradise und ATI geclonet werden. Womit sie unbekannt blieb, daher Programmierinfo nicht gestreut wurde. Sicher ist nur, dass sie in Doppel-320x200 volle 4bpp hat, damit alle 16 CGA RGBI Farben beliebig anordnen kann. In Doppel-640x200 sind es immer noch 2bpp, die bekannten Farbsätze. Das beste was ich gefunden habe ist eine Angabe, dass man passende normale Bitmapmodi per BIOS setzt, dann in IO $3DD Bit4=1 für Doppel-320x200 oder Bit5=1 Doppel-640x200. Die Bits kommen Rot+Grün bzw nur Rot wie gehabt von $B800..$BBFF, mit Blau+Intensiv bzw nur Grün von $BC00..$BFFF, also jedes Pixel in 2*2=4 bzw 2*1=2 zerteilt, unfreundlich. Diese Karte wäre besser gewesen (und auch erfolgreicher?) mit nur 8bit Video RAM, aber dafür 64kByte Video RAM (wie HGC). Am besten mit 2*32k von 64k Schalter bei anzeigen und auch bearbeiten. Das hätte ebenfalls Doublebuffer und Compositing Techniken erlaubt.

IBM selber merkte wie schwach die CGA ist, und hat bei ihrem Versuch mit dem PCjr einen Homecomputer zu erschaffen ausgebaut mit einer doppelten CGA (wie die C+). Auch hier gibt es Doppel-320x200 mit vollen 4bpp und Doppel-640x200 mit immer noch 2bpp, beide aus 32k. Allerdings nur wenn die Speicherweiterung von 64k 8bit auf 128k 16bit eingebaut ist. Ansonsten gibt es weiter die beiden CGA Modi, aber dazu noch 160x200 4bpp, mit doppelter Menge der "Tweak Mode" Pixel, weil als volles 16k Bitmap laufend. Strikte hat der PCjr nur Video RAM, mit Hauptspeicher aus diesem genommen, 64k RAM als 48k Haupt + 16k Video oder das doppelte davon mit Speicherweiterung. Ausser die externen +128=256k oder gar Dritthersteller +512=640k wurden addiert, welche echter Hauptspeicher sind. Egal woher und wieviel Farbbits kommen hat es zudem eine programmierbare Farbtabelle, um die 4bit 16 CGA Digital RGBI Farben umzurechnen auf 3*2=6bit 64 RGB Farben. Die Video RAM Bitanordnung ist CGA kompatibel, aber die Registerprogrammierung nicht, wiederum ist das BIOS aufrufkompatibel.

(Der PCjr wurde aber ein massiver Flop, wegen vielen Fehlern. Angefangen mit fehldesigter "Chicklet" Tastatur (damit Schablonen dazwischen passen). Weiter mit Infrarot Kabellosverbindung (unzuverlässig und batteriefressend). Dazu noch fehlendem DMA Chip (kam erst mit den externen +128=256k dazu). Sowie keine standard Portstecker (was mit Spezialkabel oder Adapter teurer wurde). Leider hat IBM keine vergleichbar erweiterte Karte für die PC/XT/AT gemacht, so ging dieser entscheidende Schritt aufwärts verloren.)

(Der PCjr war zwar ein massiver Flop, aber Tandy hat ihn geclont als Tandy 1000 (1984). Sie wollten einen IBM kompatiblen Home-PC. Sie haben PC/XT+CGA mit PCjr verglichen und sich für PCjr kompatibel entschieden. (Der schon vor diesem erschienene Tandy 2000 ist ein generischer nicht-PC kompatibler 80186 MSDOS Rechner, jetzt wollte Tandy PC kompatibel werden und nahm PCjr.) Nach dem PCjr Flop, hat Tandy sinnvollerweise verschwiegen, dass sie dazu kompatibel sind, den Rechner nur als MSDOS kompatibel vermarktet, und die Kritik an nicht volles aber impliziertes PC kompatibel sein weggesteckt. Wegen billig und ordentlich wurde dieser prompt zum erwarteten Erfolg, bewies das PCjr Konzept als richtig, mit nur dessen Implementation massiv verbockt. Das bessere Video fiel schnell auf, wonach die erweiterten PCjr Videomodi sogar als Tandy Graphics Adapter (TGA) bekannt wurden (bzw teils auch als Tandy Color Graphics Adapter (TCGA) bezeichnet). Welche Ironie!)

IBM hat später die PS/2 Serie herausgebracht. Neben den grossen 286 und 386 Modellen mit Microchannel, haben sie auch ein kleines Model 30 mit 16bit 8086 und 8bit XT Bus geliefert. Dieses bekam, statt bei den grossen EGA erweitert zu VGA, mit 256kByte, eine vierfach erweiterte CGA, als Multi-Color Graphics Adapter (MCGA), mit 64kByte. Wie VGA hat es Pixel mit 25.175MHz zu verdoppelte 2*15.750=31.50kHz Zeilen und schaltbare 400 Zeilen 70Hz oder 480 Zeilen 60Hz (und benutzt auch selbigen Monitor). Verwendet 8x16 Pixel Font, 80x25 Zeichen sind somit 640x400 Pixel (kein 9x16 und 720x400 wie VGA!). Verwendet auch Zellmodus statt Textmodus, Font kommt nicht mehr von ROM sondern RAM, geladen vom erweiterten BIOS ROM. Es kommt in Segmente $A000..$A1FF (und 3 weitere mit +1..3*$0200), also 4* 512 Zeichen zu je 16 Bytes. Weil Font im erweiterten BIOS ist, von diesem ins RAM kopiert werden muss, ist er auch in Bitmapmodi direkt nutzbar. Alle x200 Bitmap Modi werden in x400 dargestellt, mit ihre 200 Zeilen 2 mal wiederholt (was als Doublescan bezeichnet wird). Dazu kamen zwei neue MCGA Bitmap Modi. 640x480 60Hz mit nur 1bpp 2 Farben und 320x200 Doublescan 70Hz mit 8bpp 256 Farben. Die Modi werden im erweiterten 6845 gesetzt, wenn in $3D4 Register 16 angewählt ist (die MCGA hat keinen Lightpen Support mehr).

Dahinter hat es eine programmierbare Farbtabelle um 2/4/16/256 Farben umzurechnen auf 3*6=18bit 262144 Farben Analog RGB, gleich zusammen mit den 3 6bit Digital Analog Converter (DAC) im G171 RAMDAC Chip. Dieser ist an IO Adressen $3C7..$3C9 benutzbar. Gesetzt werden Farben 0..15 als die 16 CGA Farben. Die 16..31 haben einen 16stufigen Grauverlauf. Die 32..247 haben 3*3*24 Kombinationen von Regenbogen Blau-Rot-Grün-Blau (in 3*8=24 Schritten) in je 3 Bleichheiten und 3 Intensitäten. Die 248..255 sind 8 mal Schwarz. Für die bestehenden 1/2/4bpp CGA Modi werden nur die ersten 2/4/16 Farben benutzt. Ein Register an Adresse $3C6 kann die 8bpp Bits abschalten durch AND Funktion, um nur 1/2/4bpp zu benutzen. IBM empfiehlt aber, dieses stets auf $FF zu lassen. Wegen nun Analogsignale gab es die neue HD15/DE15f Buchse. Pin 1..3 RGB, 4 ID2, 5 GND, 6..9 RGB-GND, 9 unbenutzt/Key, 10 GND, 11+12 ID0+1, 13 Hsync, 14 Vsync, 15 ID3. (Seit modernen Monitoren mit DDC Information sind Pin 4+11 unbenutzt, 9 +5V an Monitor (für DDC Chip auslesen auch wenn Monitor ausgeschaltet), 12 SDA (Daten), 15 SCL (Takt).)

PC/XT/AT: EGA und VGA

EGA Spezialmonitor kann mit 3*2=6bit 64 Farben Digital RGB angesteuert werden. Dazu hat es selbige DE9f Buchse, wieder mit fast identischer Belegung. Pins 1+3..5+8+9 sind identisch mit CGA, mit 3..5 die oberen Bits R1G1B1, mit Wert 2/3. dazu kommen 2+6+7 die unteren Bits R0G0B0, mit Wert 1/3, als quasi 3 separate I Signale, sowie mit neben Vsync Puls auch Hsync negativ.

Die Farben kommen aus einer Farbtabelle, um die 4bit 16 CGA Digital RGBI Farben umzurechnen auf 3*2=6bit 64 RGB Farben (analog zu PCjr). Format ist %00rgbRGB, mit RGB Wert 2/3 und rgb=1/3. Diese werden im Attribute Controller Customchip an U24 eingestellt, nur an Adresse $3C0 (es hat kein $3C1!), sowohl für Register auswählen wie auch beschreiben selbige Adresse (ungleich wie bei der 6845!). Dazu hat es einen internen Umschalter, der bei lesen vom $3BA/$3DA Statusregister auf auswählen gestellt wird. Auswahl ist Bit0..4, mit 0..15 die Farbtabelle und 17 die Randfarbe setzen. Andere Register sind Konfiguration vom Chip, 18 erlaubt die 4bpp Bits abschalten durch AND Funktion, um nur 1/2bpp zu benutzen. Falls Farbtabelle schreiben ist bei auswählen Bit5=1 notwendig aber danach um Farbtabelle als Anzeige zu nutzen wieder Bit5=0. Daher sollte man auch nur im Bildräcklauf Farben einstellen.

(Video Gate Array (VGA) erweitert EGA, mit besserem Timing und mehr Farben und HD15 Buchse (wie auch MCGA). Nun auch 25.175MHz bei 640 Pixel, aber zudem noch 28.322MHz bei 720 Pixel. Mit ansonsten selbige verdoppelte 2*15.750=31.50kHz Zeilen und schaltbare 400 Zeilen 70Hz oder 480 Zeilen 60Hz. Um Kosten zu reduzieren wurden alle 5 Customchips plus einiges an weiterer Logik in nur einem Gate Array verpackt, nach welchem sie benammst ist. Diese endlich als 16bit Bus Karte. Farben hat es nun CGA 16 plus obige EGA Farbtabelle 16von64 und dahinter noch MCGA/VGA Farbtabelle 64von256! Es hat auch obiges bpp Bits abschalten durch AND Funktion, sowohl die EGA 4bit Version vor deren 16*6bit Farbtabelle, mit davon 6oder4bit genutzt, plus 2oder4bit feste Farbsatzauswahl, wie auch die MCGA 8bit Version vor der 256*18bit Farbtabelle. Letztere ist wie bei MCGA an IO Adressen $3C7..$3C9 benutzbar.)

Ist zu den 80x25 Zeichen der MDA und CGA kompatibel, aber mit neu 8x14 1bpp Font (fast wie MDA ihre 9x14), und damit 640x350 Pixel. Weiter hat es einen 80x43 Zeichen Modus, mit dabei dem 8x8 CGA Font nutzen. Beide wie gehabt mit Zeichencodes und Attribute, 2*8=16bit in 2k*2=4kByte Video RAM.

Verwendet Zellmodus statt Textmodus, Font kommt dabei nicht mehr von ROM sondern RAM, dorthin geladen vom erweiterten BIOS ROM. Für CGA Bitmapmodi hat es ohnehin eine Kopie der Zeichen $00..$7F für 8x8 im standard BIOS ROM, erweitertes BIOS addiert $80..$FF sowie alles für 8x14. Es kommt in ein Teil vom Video RAM, welches bis zu 4* 256 Zeichen zu je bis 32 Zeilen aufnehmen kann. Wobei dies nur 2oder4oder4 Fonts sind je nach ob (1oder2oder4)*64k RAM installiert sind, in Segmente $A000..$A1FF (und 3 weitere mit +1..3*$0400). Dies gilt aber nur wenn Plane 2 (von 0..3) vom Videospeicher angewählt ist (Planes siehe weiter unten). Weil Font im erweiterten BIOS ist, von diesem ins RAM kopiert werden muss, ist er auch in Bitmapmodi direkt nutzbar.

Font kann gewählt werden mit Sequencer Customchip an U33 seinem Steuerregister. Dieser ist an $3C4+$3C5, mit wie bei 6845 erstes Register auswählen und zweites beschreiben. Hierzu braucht es die Sequenz $3C4 = 0 (Reset), $3C5 = 1 (asynchron Reset), $3C4 = 3 (Character Map), $3C5 = Select, $3C4 = 0, $3C5 = 3 (asynchron und synchron). Wobei Select besteht aus Bit0..3 2*2=4bit, um 2*256 Zeichen aus 4*256 RAM Platz auszuwählen, wonach mit Attribut Bit3 zwischen diese 2*256 umgeschalten werden kann. Man hat dann zwar nur noch je 8 Farben Vordergrund und Hintergrund, aber dafür wird Intensiv zu Bold Font anzeigen nutzbar, mit in beiden Fonts dann voll intensive RGB Farben ausgeben.

(Nicht dass die Software davon gebrauch gemacht hätte. Erst MSDOS 3.3 addierte wenigstens Support für ladbare Fonts von Disk, inklusive Wechsel vom CP437 Zeichensatz zu diversen anderen. Aber auch das ohne Bold Font nutzen.)

(VGA hat Text mit 9x16 Pixel Font, 80x25 Zeichen somit 720x400 Pixel 70Hz. Weiter einen 80x50 Zeichen Modus mit 8x8. Sowie nun bis zu 8 Fonts im RAM, in Segmente $A000..$A1FF (und 7 weitere mit +1..7*$0200). Wozu Select nun auf 2*3=6bit erweitert ist, als 2*1+2*2 angeordnet.)

Bitmapmodi hat es einerseits CGA kompatibel 640x200 1bpp und 320x200 2bpp. Zudem geht auf CGA Monitor 640x200 4bpp und 320x200 4bpp. Weiter auf MDA Monitor 640x350 2bpp (00=schwarz, 01=weiss, 10=blink, 11=intensiv). Aber vor allem auf EGA Monitor eigene 640x350 2oder4bpp. Bei 640x350@4bpp werden erst 4*28=112k der maximal 4*64=256k genutzt, was Doublebuffer und Compositing Techniken erlaubt (nach Anfangsdresse wie gehabt mit 6845 setzen). Die 350 Videozeilen sind nun linear im Speicher, keine CGA 2*100 oder gar HGC 4*87 Anordnung, weil der 6845 durch einen CRT Controller Customchip an U32 ersetzt ist, der ausreichend breite Register hat. Er ist aber grossteils 6845 kompatibel wenn in MDA und CGA Modi. Seine Adressen gehen durch die 74LS374 an U42+U52 (zu RAM Hälfte A) bzw U22+U19 (zu RAM B), während Prozessor Adressen gehen durch 74LS258 an U53+U43 (zu A) bzw U4+U13 (zu B).

(Erweiterte Super-EGA Clone konnten mit gleichem Speicher auch 640x480 4bpp (4*38=152k). Oder mit ausreichend Speicherbandbreite sogar 800x600 4bpp (4*60=240k), nachdem ausreichende Multisync Spezialmonitore erschienen. Das sind aber mehr als die Hälfte der 4*64=256k, verhindert Doublebuffer.)

(VGA hat ebenfalls 640x480 4bpp mit 60Hz. Sowie CGA 400 Zeilen Doublescan mit 70Hz, plus MCGA 320x200 8bpp selbiges. Erstaunlich hat es kein 320x480 8bpp 60Hz oder auch nur 320x400 70Hz, trotz ausreichend Speicher und Bandbreite dafür. Es gibt aber einen inoffiziellen 320x240 60Hz Modus, mit die 6845 umprogrammieren, der als "Mode X" bekannt ist, und beliebt wegen quadratischen Pixeln. Zudem gibt es inoffziellen "Mode Q" mit 256x256.)

(Erweiterte SVGA haben wieder mit ausreichend Speicherbandbreite sogar 800x600 4bpp. Oder gar mit 512k Speicher 640x480 8bpp oder sogar mit genug Bandbreite bis zu 800x600 8bpp und 1024x768 4bpp. Später kamen mit 1M Speicher auch 1024x768 oder gar 1152x864 8bpp. Nochmals spätere addierten sie 16/256 Farben aus 16M RGB statt 262144, sowie "Hi-Color" 800x600 3*5=15bpp mit direkten 32k RGB Farben. Noch weit später kamen "True-Color" 3*8=24bpp direkt.)

Wegen auch in PC und XT nutzbar hat die EGA nur 8bit Bus. Wegen der massiven Datenmenge hat die Basisplatine 64kByte Video RAM, plus mit Zusatzplatine +64k oder +192k auf bis zu 256k(!) erweiterbar. Wegen resultierender Bandbreite braucht sie dies als 4*8=32bit Video RAM, somit in (16oder32oder64k)x32bit Anordnung, aus (1oder2oder4)*8 4416 16kx4bit DRAM Chips. Wegen nur 64k Adressen in Segment $A000..$AFFF wird sie auch 32bit wortweise adressiert. Die 4*8bit Breite sind als 4 Bitplanes 0..3 bekannt. Dazu kann sie auch MDA und CGA kompatibel laufen, aus $B000..$B7FF bzw $B800..$BFFF. Weiterhin hat es eine BIOS ROM Erweiterung in $C000..$C7FF. All das wird decodiert mit einem 24S41 1024x4bit PROM an U48.

Wegen ausreichend schnellen Speicherchips kann die EGA je nach Datenmenge mit 2von5 oder 4von5 Speicherzyklen Video laufen. Prozessor bekommt somit 3von5 oder 1von5. Damit hat es offensichtlich kein Snow. Selbst mit Font aus RAM holen nicht, weil Zeichencodes und Attribute in RAM Hälfte A sind (Planes 0+1), und Fonts in RAM Hälfte B Plane 2 von 2+3). Weshalb der CRT Controller eben zwei separate separate Sätze Adressen verarbeitet. Womit im Textmodes Zeichencodes von RAM A zusammen mit Fontwahlbits nach zwei 74LS374 an U3 und U12 kommen, diese wiederum RAM B adressieren, von dem die Fontpixel zum Attribute Controller kommen via Signale CC0..7. Attribute gehen direkt dorthin mit ATR0..7. Bei Bitmap laufen beide RAM A und B Adressen parallel, mit diese beiden 74LS374 abgeschaltet.

Die RAM Adresslage wird eingestellt mit dem Graphics Controller Steuerregister. Dieser ist an $3CE+$3CF, mit wie bei 6845 erstes Register auswählen und zweites beschreiben. Für Adresslage setzen ist $3CE = 6 (Miscellaneous) mit $3CF Bit2+3 = MemoryMap (00=$A000..$BFFF, 01=$A000..$AFFF, 10=$B000..$B7FF, 11=$B800..$BFFF). Dieses Register hat zudem Bit0 1=Graphik/0=Text und Bit1 für CGA Bitmap A0 umleiten auf 2 Bänke für Text und CGA Bitmap. (Neben diesen muss man Sequencer $3C4 = 4 (MemoryMode) setzen mit $3C5 Bit0 1=Text/0=Graphik, Bit1 1=Speichererweiterung, Bit2 1=linear Worte für EGA Bitmap / 0=abwechselnd Bytes für CGA. Zudem falls dort Bit2=0 auch im Graphikcontroller $3CE = 5 (Mode) jeweils mit Bit4=1 addiert benutzen.) (Auch der Attribut Controller braucht erstes $3C0 = 16 dann zweites $3C0 Bit0 1=Graphik/0=Text.)

IO Adressen kann die EGA MDA $3B0..$3BF oder CGA $3D0..$3DF umschalten. Dazu nimmt sie noch $3C0..$3CF für alle ihre Erweiterungen. All das wird decodiert mit einem weiteren 24S41 1024x4bit PROM an U34 gefolgt von zwei 74LS138 an U25 und U28. IO $3C0 ist Attribute Controller, $3D2 ein weiteres Konfigurationsregister und Statusregister Paar, $3C4+$3C5 Sequencer, $3CE+$3CF Graphikcontroller. All das neben dem CRTC Controller an $3B4+$3B5 bzw $3D4+$3D5. Es hat ebenfalls den IRQ 2 vom vertikalen Bildsignal (wie CGA).

IO $3C2 schreiben ist ein Konfigurationsregister. (Bit0 IO 1=$3Dx/0=$3Bx, Bit1 Video RAM sichtbar, Bit2+3 Pixeltaktfrequenz, Bit4 Videoausgang aus, Bit5 obere/untere 32k wenn in CGA Modi, Bit6=1 Hsync negativ statt positiv, Bit7=1 Vsync selbiges.) $3C2 lesen ist ein neues Statusregister. (Bit4 kann 4 DIP Schalter einlesen, Bit7 zeigt ob in Bild oder nicht.)

(Erweiterte SVGA 800x600 passen noch in die 4*64k Adressraum, 1024x768 4bpp brauchen aber mehr als dies, benutzen zumeist einfach 4*128k, mit dazu Segmentregister im Bereich $A000..$BFFF zeilenweise umsetzen. Deswegen laufen bis zu 800x600 4bpp zusammen mit einer MDA oder HGC, aber 1024x768 4bpp nicht mehr. Bereits alle oberhalb 320x200 8bpp Chunks können aber keine vier Bitplane Logik nutzen für mehr als 64kByte Adressen und somit 4*64=256k, brauchen eine von IBM mangels 640x480 8bpp (oder auch nur 320x480 8bpp) in der VGA nicht vorgegebene Adresserweiterung, und wurden daher zu einander inkompatibel erweitert! All die Einstellungen wenigstens etwas standardisieren resultierte in der Video Electronics Standards Association (VESA).)

Wegen 32bit Video RAM in nur 8bit Bus braucht es Trennung vom PC Datenbus in 4*8bit. Dies geschieht mit einem Paar von IBM designten Graphics Controller Customchips an U31 (macht Planes 0 und 1, in RAM Hälfte A) und U21 (Planes 2 und 3, in B). In diesen werden ebenfalls die Pixel mit einem aufwendigen 8zu(4*8=)32bit Pixelprozessor synchron bearbeitet oder kopiert! Diese lesen auch gleich den Speicher aus für die Anzeige, mit Pixel via Signale C0+C1 bzw C2+C3 an den Attribute Controller senden. Wegen dabei Pins sparen werden die Videodaten als Bitplanes abgespeichert, also von 8 Pixel je 1von4bpp verteilt auf 1von4 Bytes in den 32bit, alle 8*R und 8*G und 8*B und 8*I in jeweils ein Byte. (Im Gegensatz zu CGA und C+, wo Pixel als Chunks abgespeichert werden, also von 4 Pixel die ganzen 2bpp in ein Byte, oder gar von 2 Pixel die ganzen 4bpp in einem.)

Bei vom Bildspeicher lesen werden alle 32bits in 4*8bit Latches zwischengespeichert. Was davon aber vom Prozessor gelesen wird ist einstellbar, als Read Mode, mit $3CE = 5 (Mode) und $3CF Bit3=0oder1:

In Read Mode 0 wird ein einzelnes Byte von den vieren auf den Bus zum Prozessor geliefert. Je nach was mit einer 2bit Planenummer gesetzt ist, mit $3CE = 4 (ReadMapSelect) und $3CF Bit0+1 = Planenummer 0..3.

In Read Mode 1 werden dagegen alle 4 Bytes kombiniert. Dabei entsteht ein Bitmap, wo jede der 8 Bitposition =1 ist, falls die 4 Bytes ihre korrespondierenden 4 Pixelbits zusammen zu einer spezifizierten Farbe passen. Diese ist festgelegt mit $3CE = 2 (ColorCompare) und $3CF Bit0..3 = Farbe. Aber diese Bits wirken nur, sofern die passenden Farbbits aktiviert sind, mit $3CE = 7 (ColorDontCare) und $3CF Bit0..3 = 1.

(Generell wird das $3CE+$3CF Paar für Graphikoperationen Modi und deren Parameter umschalten oft beschrieben. Dies kann man am effektivsten machen (oder zumindest wenigsten ineffektiv), mit einmalig die Adresse $3CE in Prozessorregister DX laden, dann pro Aktion ein 16bit Immediate (Lowbyte = Registernummer, Highbyte = Daten) in AX laden, und beide Bytes mit OUT DX,AX ausgeben. Den Pixelprozessor konfigurieren und benutzen ist aber selbst so aufwendig und alles andere als schnell.)

Bei zum Bildspeicher schreiben wird es aufwendiger, weil aus nur 8bit oder 4bit vom Prozessor 32bit Pixel erzeugt werden. Was dabei aber im Speicher ankommt ist wieder einstellbar, als Write Mode, mit $3CE = 5 (Mode) und $3CF Bit0+1=0oder1oder2oder3:

In Write Mode 0 geht ein Byte vom Prozessor in eines oder beliebige mehrere der Bänke. Bild löschen besteht aus Prozessor Daten 0 in alle Bänke schreiben. Wozu alle Bits mit Daten von Prozessor eingestellt werden muss, mit $3CE = 1 (EnableSetReset) und $3CF Bit0..3 = 0, sowie alle Pixel verändern erlaubt sein muss, mit $3CE = 8 (BitMask) und $3CF = $FF. (Mit Sequencer $3C4 = 2 (Map Mask) kann man zudem in $3C5 Bit0..3=0 die 4 Bänke gegen schreiben inkusive läschen sichern, es braucht dort =1 um schreiben zu können.)

Es ist aber auch möglich, hier eine oder mehrere der Bitposition selektiv mit neuem 4bit Farbmuster zu füllen, mit $3CE = 0 (SetReset) und $3CF Bit0..3 = Farbe, aber nur falls obiges $3CE = 1 (EnableSetReset) und $3CF Bit0..3 = $0F ist, oder weniger um nur teilweise Bitplanes damit zu ersetzen. So könnte man theoretisch einmal Farbe in SetReset laden und dann direkt Pixelmuster schreiben. Nur werden diese Muster in die Prozessor Daten hineingebaut, mit EnableSetReset = $0F diese ganz ersetzend. Die betroffenen Pixel müssen daher mit $3CE = 8 (BitMask) und $3CF = Pixelmuster eingestellt werden. Was aufwendig und ineffizient ist, weil Farbe und Muster beide zuerst setzen und dann Prozessordaten ignoriert werden. Noch schlimmer werden die anderen Pixel einfach mit Prozessordaten auf alles-0 oder alles-1 gesetzt. Womit dies praktisch nutzlos ist.

Weiter kann man dabei die Daten vom Prozessor noch um 0..7 Pixel rotieren um Objekte pixelgenau einzufügen, mit $3CE = 3 (DataRotateFunctionSelect) und $3CF Bit0..2 = 0..7. Aber dies erfolgt nur in einem Byte drin. Es hat kein herausschieben der unbenutzten Bits und mit dem nächstem Byte kombinieren. Also muss man neben rotieren auch mit $3CE = 8 (BitMask) die höherwertigen Bits verhindern und dann nochmals auf die nächste Adresse losgehen mit inversem BitMask um die rechts "herausgeshifteten" Bits dort abzulegen. Mit dann aber nächstes Byte vom Objekt in diese selbige Adresse, nun wieder mit erster BitMask sowie dann mit inversem in dessen nächste. Was extrem mühsam ist. Oder zuerst alle geshifteten Hälften und dann mit nur einmal die BitMask invertieren die "herausgeshifteten" Hälften. Wenigstens etwas weniger mühsam. Immer noch total unfreundlich und ineffizient.

In Write Mode 1 werden dagegen die Daten aus den Latches genommen, nach zuvor gelesen werden, egal welcher Read Mode war. Umkopieren um zu scrollen wird so gemacht, mit alle 32bit auf einmal lesen in die Latches, und dann unverändert am neuen Ort schreiben. Wobei der Pixelprozessor die Daten vom Prozessor ignorieren muss, nur die zuvor gelesenen Latches Inhalte schreiben. Also kann man dazu einen simplen MOVSB Befehl benutzen. (Kein MOVSW, weil dieses zweimal liest bevor schreibt, damit die Latches zerdeppert!) Dies vermeidet eine Plane nach der anderen separat zu kopieren, was vierfache Laufzeit einspart. Vor allem aber verhindert dies während der Kopierzeit (teils Planes ihre Pixel bereits verschoben andere noch nicht) eine Bitanordnung zu erzeugen, bei der nicht mehr zusammenpassende Bitmuster der Planes erzeugen werden, welche als Falschfarben ausgegeben würden, in der Form der verschoben werdenden Objekte, an beiden Positionen! Dieser Effekt ist als Ghosting bekannt. Nur mit alle 4*8=32bit parallel kopieren kann dieser verhindert werden.

Für einzelne Pixel in einem Wort einfügen müsste eigentlich der Prozessor viermal ein Byte zuerst lesen dann mit OR einfügen und wieder schreiben. Man kann aber nun die Pixel nur einmal vom Prozessor schreiben, weil sie im Pixelprozessor für jedes Bit in dessen Latch Inhalt OR eingefügt werden können. Dies geschieht wenn $3CE = 3 (DataRotateFunctionSelect) und 3CF $Bit3+4 = 10. Es hat neben 10=OR zum setzen auch 01=AND zum löschen und 11=XOR zum invertieren sowie 00=DATA zum voll ersetzen wie oben. All dies wirkt in Mode 0 und 1. Nach obigem rotieren der Daten vom Prozessor, welches erst mit OR Sinn macht, für bestehenden Hintergrund plus einzufügende Objekte. Mit zudem in nur die erlaubten Bänke/Planes schreiben. Aber je nach gewollter Farbe muss man die Bits von teils Planes setzen aber andere löschen. Was ebenfalls aufwendig und ineffizient ist, mit 2 Zyklen für AND und OR Modus brauchen, plus dazwischen jeweils Modus schalten. Alle AND zuerst und dann alle OR erzeugt wieder nicht mehr zusammenpassende Bitmuster und Ghosting.

In Write Mode 2 kann man gleich die Daten vom Prozessor als Farbe nutzen. Dies ebenfalls mit Daten/AND/OR/XOR der Farben. Was wegen Daten vom Prozessor nun die Bitplanes auswählen, nicht mehr die Pixel in Byte damit spezifizieren kann. Weshalb die Auswahl der betroffenen Pixel von der Bitmaske kommen muss. Dies macht zumindest Sinn, wenn man vertikale Linien mit konstantem Bitmuster aber varierender Farbe zeichnen will. Was man aber selten macht. Wenn Muster/Text/Objekte zeichnend, müsste man deren Muster zuerst in der Bitmaske ablegen. Und das fuer jede Farbe im Objekt separat. Nochmals sehr mühsam zum benutzen.

(VGA addiert noch Write Mode 3 mit Farben von Register und ebenfalls Daten/AND/OR/XOR, aber kombiniert mit bitpositionweise AND ausmaskieren durch Pixelmuster vom Prozessor. Was fast schon das richtige ist, sich wie 1bpp benutzen benimmt. Nur mit immer noch 2 Zyklen für Hintergrund und Vordergrund Farbe setzen, mit jeweils reversem Pixelmuster. Ausser alles war bereits davor auf Hintergrund gesetzt/gelöscht, nur Vordergrund mit Pixelmuster zu setzen. Leider fehlt immer noch ein Modus mit zwei Farbregister und Prozessordaten nur diese auswählen. Was dann als Modus gleich alle 0+2+3 ersetzen könnte, mit sogar Modus 1 einfach als Sonderfall von Hintergrund = bestehendes.)

(Generell macht der Pixelprozessor den Eindruck, ohne jegliche Beteiligung von Programmierern designt worden zu sein. Resultat ist ein aufwendiges und mühsames und ineffizientes Teil. Ich bin mir nicht sicher, ob ich sie richtig verstanden habe, oder obiges Fehler beinhaltet. Testen/verifizieren geht nicht mangels PC mit original EGA Karte bei mir. Dementsprechend war die EGA extrem unbeliebt. Sobald SVGA den MCGA 320x200 8bpp Chunks Modus auf genug Pixel erweiterte schaltete jeder auf nur noch das benutzen. Wohlgemerkt, das war schalten im Sinne von in 1990 ersetze EGA Karte durch neue SVGA Karte, welche irgendwo $500..1000 kostete.)

(Die VGA gab auch nette mehr Farben, aber vor allem die 8bit Chunks direkt per Prozessor mit 16bit bearbeiten, statt in 4bit Bitplanes per EGA Pixelprozessor mit 4oder8bit herumstochern. Wirkung siehe eine Tseng ET4000 basierte SVGA mit 1152x864 Pixel 8bpp in einem 386 16MHz mit 16bit ISA Bus, Linux XFree Videotreiber scrollt die bis zu 1MByte Bild langsam, also selbige Karte auf EGA 1152x864 Pixel 4bpp Modus umgestellt. Statt schneller wegen halbe Datenmenge und 32bit Pixelprozessor wird es langsamer, dauert mehr als 2 mal so lange! Ich habe erst dabei (erst in etwa 1995) wirklich begriffen, wie schlecht dieses Design ist. Die EGA ist einfach IBM vom schlimmsten, und deren Name hatte schon davor von den Grossrechnern her die Scherzübersetzung als Incredibly Bitchy Machines!)

Auch scrollen wurde verbessert. Schon auf MDA und CGA konnte man mit 6845 Register 12+13 die byteweise/wortweise/zeilenweise Anfangsadresse im Videospeicher setzen und mit Register 8 in-Zeichen vertikal nach oben schieben mit in erster Textzeile vom Font oberste Pixelzeilen auslassen um vertikal fein zu scrollen. Mit Anfangsadresse Zeichenweise konnte man auch horizontal nach links scrollen, aber nur Pixelblockweise (8 Pixel). Hier wurde neu horiziontal fein scrollen addiert, mit im Attribute Controller die Möglichkeit links Pixel auszulassen mit erstes $3C0 = 18 und zweites $3C0 = 0..7 Pixel. Zudem kann man mit einem Offset Register $3B4/$3D4 = 13 im erweiterten 6845 die Zeilenlänge im Videospeicher auf mehr als die angezeigte Menge setzen, um nach Ende jeder Videozeile weitere Bytes zu überspringen, um einen horizontalen Ausschnitt aus einem breiteren Videospeicher anzuzeigen.

Aber irgendwann trifft man das Ende vom Speicherbereich, und umkopieren wird notwendig, was aber einiges an Zeit kostet. Weit besser ist gar nicht umkopieren. Das kann man machen mit den Bildspeicher nichtlinear ausgeben. Der Trick ist, wenn man erstes Bild von Null aufbaut sind die Zeilen in Reihenfolge 0..349 im Speicher, wie gehabt. Jetzt will man nach oben scrollen. Einfach Bildausgabe um eine Zeile von 80Worten weiter hinten im Speicher anfangen, und schon ist die ehemalige zweite Zeile vom Bild jetzt die erste! Dann folgen dritte bis letzte im Speicher als zweite bis zweitletzte vom Bild, womit das ganze Bild verschoben ist, ohne etwas umzukopieren zu müssen. Aber dann muss noch als letzte die nun fehlende Zeile 349 vom Bild kommen. Dies macht man, mit dem Speicherplatz der ehemaligen ersten ersten anzeigen, welche man mit neu eingescrollt werdendem Inhalt füllt. Beim nächsten Scroll sind es dritte bis letzte und dann erste bis zweite. Dann vierte bis letzte und erste bis dritte. Und so weiter bis nach 350 mal scrollen wieder alle linear sind. Sowas ist als rollende Anordnung bekannt.

Die EGA kann dazu einerseits die Anfangsadresse wie bereits bei den MDA und CGA verschieben, in $3B4/$3D4 Registerpaar 12+13. Zudem kann sie nun ein Zeilenvergleichsregister $3C4 = 24 (LineCompare) mit $3C5 = Zeilennummer setzen, so die letzte Zeile im Speicher (nicht letzte im Bild) abwarten. Bei erreichen von dieser Zeile kann sie zum Anfang vom Videospeicher springen, um die oben hinausgescrollten Zeilen ihren ehemaligen Platz als restliche Zeilen vom Bild zu holen.

(SVGA ab etwa 1MByte 1024x786 Generation addierten noch ein Sprite, oft 16x16 2bpp (Transparenz+Inversion), als Hardware Mauscursor, oft als "Mausbeschleuniger" bezeichnet. Ebenso addierten sie automatisch ablaufende Scrollumkopierer, als 2D Beschleuniger bezeichnet. Neben Beschleuniger wurde auch schnellerer Zugriffe auf Karten verbessert, mit VESA zuerst eine den ISA Bus voll ausnutzende lineare 24bit 286 Protected Mode Adressierung des ganzen Videospeichers definieren. Gefolgt von sogar eine 32bit 33/40/50MHz Erweiterung vom ISA Bus namens VESA Local Bus (VLB) erzeugen, der zudem lineare 32bit 386/486 Adressierung erlaubte. Dies war die letzte Evolutionsstufe des "klassischen" PCs (= vor modernen PCs mit PCI/AGP/PCIe Bus und SATA/NMVe Disks und DVI/HDMI/DisplayPort Video und USB/Thunderbolt Interfaces). Von diesen stammen dann alle modernen Videokarten ab. Dabei "dank" Windows Treiber statt standard Hardware Register die Inkompatibilität immer schlimmer werdend. Zudem ab PCI und USB wegen undurchsichtigen Plug&Play Automatismen, bzw wenn sie anfangs nur zu oft versagten auch als Plug&Pray bezeichnet, immer unvorhersehbarer und auch mit Fachkenntnis immer unkorrigierbarer werdend.)

Audio

AT

Es ist aber ebenso möglich, mit direkt an PB1 herumpulsen weitaus differenzierte Signale zu erzeugen. Das ist möglich, weil der Timer Ausgang bei nicht laufend auf 1 steht, und der PB1 mit diesem ANDiert wird. Insbesondere kann man diesen als Pulse Frequency Modulation (PFM) Digital Analog Converter (DAC) missbrauchen (bei CD Playern wird dies auch Bitstream Converter genannt). Dabei werden Serien von kurzen Pulsen von 100% Signal abgegeben, mit 0% dazwischen. Die Analoghardware kann diesen Pulsen gar nicht schnell genug folgen, sie "verschmiert" daher das Signal zu einem Zwischenwert, welcher aus dem Prozentanteil Zeit mit Puls folgt. Um die Pulszeiten zu berechnen kann man den Deltapuls Algorithmus benutzen, bei dem das erzeugte Signal (aufsummierte Pulszeit, als Integral) mit dem gewollten aktuellen Sample verglichen wird, mit davon Puls unter=ein/äber=aus schalten. Wenn auch mit dabei den Prozessor massiv belasten, zumeist volle 100%. Weshalb man dies nur parallel zu zuerst Illustrationen anzeigen und dann auf Tasten warten benutzen kann.

(Das musikalische Resultat davon wird heute 1-Bit Sound genannt. Allerdings ist ein ZX Spectrum die weitaus kompaktere und billigere und einfachere Methode um solchen Sound zu erzeugen. Dieser hat nur Prozessor Beep ohne Timer, und daher Tradition in dies machen seit 1982, und ist damit das Standardinstrument in der Szene.)

(Dies ist übrigens die älteste Methode um Audio zu erzeugen, schon in den 1950ern benutzt. Dies entstand sogar unabsichtlich, weil zwecks Rechnerablauf verfolgen für Debugging einfach ein Lautsprecher an ein regelmässig äderndes Signal gehängt wurde, oft eines der höherwertigen Akkumulator Datenbits. Dabei entstanden charakteristische Klangfolgen, welche man nebenbei mitverfolgen konnte, mit Abweichungen vom gewohnten als Fehlerhinweis! Musik war die logische Folge, mit gezielt spezifische Klangfolgen erzeugen. Man bemerke, dass alles was steuerbare Geräusche erzeugen kann als Musikinstrument benutzbar ist, nur einfach als primitiveres.)

Limitiert wird all das durch einen kleinen Lautsprecher. Dieser steckt zudem im Gehäuse drinnen, statt sinnvollerweise im Monitor oben. Mit deswegen auch nur einem sehr schwachen Verstärker, und zudem keinen Lautstärkeregler, statt einem solchen neben dem Bildhelligkeitsregler. Komplett fehlt jeglicher Kopfhöhrer Anschuss, oder auch nur Audio welcher solchen benutzen rechtfertigt.

Mehr als das geht nur mit Soundkarte. Aber dafür hat IBM keinen Standard definiert. Wieder ausser mit dem PCjr, wo ein Texas Instruments SN76489/SN76496 Digital Complex Sound Generator (DCSG) verwendet wird, ein leicht modifizierter TMS9919. (Der TMS9919 wurde benutzt in TI 99/4 und 99/4A, neben deren TMS9918 Video Display Controller (VDG). Der SN76489/SN76496 neben PCjr auch in Tandy 1000, dazu BBC Micro, ColecoVision, Sega Master System und Game Gear.) Leider hat IBM wie bei PCjr Video keine vergleichbare Karte für PC gemacht, so ging auch dieser entscheidende Schritt aufwärts verloren, weil der PCjr ein Flop war. Folglich gab es einen Wildwuchs von zu einander komplett inkompatiblen Soundkarten. Da diese keine IBM Originale sind, und aufwendig zu beschreiben, und nur für Spieleanwendungen relevant, und daher in den meisten 1980er PCs abwesend, werden sie hier nicht weiter behandelt.

Mac

Die Samples sind 8bit und werden zu Analog gewandelt mit Hilfe eines Pulse Width Modulation (PWM) DAC. Dieser besteht aus nur zwei 4bit 74LS161 Zählern, welche mit der Nummer 0..255 des Samples gestartet werden, wenn das Signal /DMALD kommt. Sie zählen dann lediglich bis 255 durch, somit verbleibende 255..0 Zählpulse lang, mit den 8MHz Prozessortakt 8M an Pins CP (Clock Pulse) dazu benutzt. Womit sie so lang eine 0 am Ausgang Pin TC (Timer Count) als Signal SOUND ausgeben, je tiefer der Sample Wert war umso länger. SOUND wird noch im 74LS04 zu /SOUND invertiert, und geht dann an die 74LS161 Pins CEP um diese anzuhalten wenn eine 1 am Ausgang erscheint (bei erreichen von 255).

Das /SOUND geht aber auch durch 1/4 CD4016 Chip im Audioverstärker, alles aus Analogbauteilen. Dieser hat nach dem ersten 1/2 LF353 Vorverstärker Chip ein Netz von Widerständen plus die restlichen 3/4 CD4016 Analogschalter. Diese werden geschalten von der 6522VIA Pins PA0..PA2, Signale SV0..SV2 (Sound Volume 0..2), was fest 1/8 und schaltbar +1/8 +1/4 +1/2 erlaubt, welche dann aufsummiert werden zu (1..8)/8, was einen rudimentären 3bit Lautstärkeregler ergibt. VIA Pin PB7 geht noch als Signal SND.RES an die beiden 74LS161 um mit 1=aus/0=ein Audio zu schalten. Danach folgt die zweite 1/2 LF353 um die Inversion von SOUND zu /SOUND rückgängig zu machen und als Treiberverstärker an die Gegentakt Endstufe Transistoren Q5 2N4401 und Q4 2N4403 zu wirken. Dieser Verstärker liefert aber nur geringe Leistung an den Kopfhöhrer Ausgang. Für den internen Lautsprecher braucht es noch einen Boostverstärker auf dem Analog Board.

Um die Samples zu holen wird ein einzelner 8bit DMA Kanal benutzt, von Speicher D8..D15 genommen, also müssen die Samplebytes an gerade Adressen. Dieser bekommt seine Adresse vom bereits bestehenden 74LS393 Videoadressenzähler, aber nur die 9bit Zeile-in-Bild, von 0..369 gehend. Damit hat Audio eine Samplerate identisch mit der Video Horizontalfrequenz von 22.254kHz. Zum RAM kommt diese Adressen durch 2 74LS257 2:1 Multiplexer, gesteuert vom LAG PAL sein /DMA. (Auch Prozessor und Video könnten je 2 74LS257 benutzen, selbige Anzahl 4 Chips, aber die Verdrahtung würde dem LAG einen Pin mehr abverlangen, also benutzen diese zusammen die 74AS253, zumal Video bereits vor Audio addieren so designt wurde.)

Wie zwei Videospeicher hat es auch zwei Audiospeicher, main/primary und alternate/secondary, für Doublebuffer Audiogenerierung: Weitere 370 Samples aufbereiten während aktuelle 370 am abspielen sind, mit wenn die fertig sind umschalten, dann weitere 370 aufbereiten. Weshalb ein weiteres Adressbit von der 6522VIA geliefert wird von Pin PA3, Signal /SND.PG2 (Sound Page 2). Da der Speicher aber 16oder18bit Adressen braucht (je nach ob 128K oder 512K) werden die restlichen hart auf "1" gestellt, wie bei Video. (Daher hat der 128k zu 512k keine weitere 74LS257 drin, benutzt einfach die 74AS253 in der Video Stellung, welche ja auch "1" hat.) Weshalb Audio ebenfalls stets in den letzten 32k ist, bei 128K $018000..$0FFFFF, bei 512K $078000..$07FFFFF, ab Adressen $0xFD00 und $0xA100. Die Differenz von $0xFD00-$0xA100=$0x5C00 ist das VIA Bit als Adressbits A6+A7+A8+A10 vier mal angelegt, für main/primary auf 1 gesetzt.

Erst mit der Systemsoftware entstehen 4 Audiokanäle. Aber diese entstehen durch Audiodaten in Samples umrechnen, und brauchen je Kanal 10% Prozessorleistung um zu rendern! Um den Speicherinhalt synchron zu erzeugen und auf Ausgabe zu schalten verwendet sie Software entweder das Timing vom H4 Signal vom LAG an die VIA zu Pin PB6 mit dessen Timer dahinter, oder das vom /VSYNC Signal vom LAG an die VIA zu Pin CA1.

Zudem kann ein reines Beep Rechtecksignal ohne Prozessorlast mit dem VIA Timer 1 erzeugt werden. Dazu den Audiospeicher alle Bytes füllen mit etwas von $00 bis $FF, je nach erwänschter Lautstärke. Dann den Timer 1 einstellen auf Pulslänge und Modus Rechteckwelle ausgeben. Dieser treibt Pin PB7, ihn jeweils reversierend. Dies tut mit 1=aus/0=ein Audio schalten, damit zwischen Null und Audiospeicher Wert schalten. Das Resultat ist analog zum PC Timer Beep.

Weil Audio nur 8bit Samples nutzt, werden die anderen zusammen mit diesen ausgelesenen 8bit teilweise für die Floppy Motorgeschwindigkeit abbremsen steuern benutzt. Dazu gehen 6bit der 8bit an das ASG PAL, von Speicher D0..D5 genommen, der diese zu PWM macht um eine Analogspannung zu erzeugen, diesmal mit Pixeltakt zählend. Nebenbei tut er aus DMA und TC das leicht verzögerte /DMALD Signal für die beiden 74LS161 erzeugen. Abgesehen von letzterem hat dieses PAL gar nichts mit Audio generieren zu tun, es geschieht nur nebendran. Womit das ASG mit Analog Sound Generator benennen komplett daneben ist! Ein Seiteneffekt besteht noch, dass weil die Systemsoftware die Motorsteuerdaten stets neben dem ersten Audiospeicher hinstellt, kein Floppy Betrieb möglich ist, solange Audio mit der VIA auf den zweiten Speicher gestellt ist.

Tastatur

AT

Die originale PC Tastatur hatte ein anderes Layout als was wir heute kennen. In der Mitte zwar Alphanumerisch, aber die 10 Funktionstasten links und kombinierte Numerik mit Cursor+Edit Tasten rechts. NumLock war damals notwendig um den Modus umzuschalten, mangels separate Cursor+Edit Tasten. Es hat stets vertikale Enter Taste. Insgesammt 83 Tasten. Dazu kam noch eine Höhe/Winkel Verstellung mit hinten ausklappbaren Beinchen per Drehknöpfe an den Seiten.

Intern wurde bewährte seit langem in Grossrechner Terminals optimierte Mechanik verwendet, als Model F bekannt. Jede Taste hat eine unvermeidbare Feder um sie herauszustossen. Bei der F ist diese im inneren der Tastenführung, welche aber auf der einen Seite einen Schlitz hat. Beim drücken der Taste wird die Feder nicht nur komprimiert, sondern biegt deswegen in den Schlitz aus, was als Buckling Spring (= buckelnde Feder) bekannt ist. Dies erzeugt einerseits eine ab dann spürbare Reduktion der Kraft, als taktiles Feedback, plus Klick vom aufschlagen der Feder an der Seitenwand, als solides audielles Feedback. Anderseits kippt die Feder die Grundplatte auf der sie montiert ist, was deren Abstand zur Platine reduziert, und somit die elektrische Kapazität zwischen Platte und Platine ihre Metalschichten erhöht. Diese sind isoliert, es entsteht kein elektrischer Kontakt! Damit fallen Kontakt und Feedback genau auf einander, womit das Feedback erst vertrauenswürdig ist, im Gegensatz zu Tasten mit separatem Klickelement.

Die Elektronik muss folglich die Übertragung elektrischer Pulse durch diese Kapazität messen. Dazu hat sie einen schaltbaren 4-kanaligen Messverstärker, welcher ein Bit abgibt, der gewählten Taste entsprechend. Für mehr Tasten hat es eine Matrix, mit 24 Gruppen zu je 4 an Platz, also maximal 96 Tasten, von denen 83 vorhanden sind. Die Anordnung der Tasten in der Matrix ist nicht dokumentiert. Es zählt ein 8048 Mikrocontroller 7bit an Port Pins DB0..DB6 durch (von denen gehen Bit0..1 an den Messverstärker schalten, und Bit2..6 an 4bit:16Leitung und 3bit:8Leitung Tastengruppen Decoderchips). Zudem pulst sie pro Taste P20 einmal und beobachtet die Wirkung an ihrem TI Eingang, vermutlich die Pulsdauer.

Kommunikation zum PC ist synchron seriell mit einem 5-adrigen Kabel mit DIN5 Stecker. Pins 1 Takt (CLK), 2 Datenbits (DATA), 3 Reset (/RESET), 4 0V (GND) und 5 5V (+5V). Die Tastatur macht im 8048 Bitbanging, Bit0 zuerst sendend. Im PC hat es hinter der DATA Leitung ein 74LS322 8bit SIPO (Serial In Parallel Out) Shiftregister an U24 plus danach ein 74S74 Flipflop an U82, zusammen 9bit. Damit kann die Tastatur 9 Bits senden, eine 0 als Startbit gefolgt von 8 Daten, jedes Bit gefolgt von einem CLK Puls, von 1 zu 0 und wieder 1. Wenn das Startbit vom 74LS322 Ausgang QH' invertiert zu 1 ins Flipflop 74S74 durchkommt wird der Tastaturinterrupt IRQ 1 ausgelöst.

Dann kann die 74LS322 via dem 8255PPI an Pins PA0..PA7 eingelesen werden, an IO Adresse 060. Gefolgt von 8255 Pin PB7 auf 1 ziehen, was die 74LS322 und das Flipflop löscht, an IO Adresse 061. (Solange PB7=1 ist (oder noch Eingang nach Reset), gibt der 74LS322 auch keine Daten von sich, weshalb die PA0..PA7 Pins dann via eine statt dessen aufgemachte 74LS244 an U23 die ersten 8 DIP Schalter lesen kann.)

Solange die 1 im Flipflop ist, tut sie mit dem 74LS125 an U80 die DATA Leitung ausnullen, was der 8048 testen kann, um mit nächste Daten zu warten bis diese 1 gelöscht wird, implizit die aktuellen Daten abgenommen worden sind. Weitere Tasten werden gescannt, aber bis dann in einem internen Buffer von maximal 20 zurückgehalten.

Weiter ist die CLK Leitung auch mit Pin PB6=0 ausnullbar, durch 8255 Pin PB6 auf 0 ziehen, was die 8048 ebenfalls sehen kann. Das Signal bei diesem ist mit /REQ angeschrieben, ich vermute als Anforderung ein Lebenszeichen von sich geben, für den "hat es eine Tastatur" Test. Laut einer Quelle muss man dazu 20ms auf 0 ziehen, und die Tastatur resettet sich dann auch. Man kann mit diesen Signal aber auch einfach die Tastatur blockieren, um nicht mit Tasten gestört zu werden. Daher haben beide Signale am Tastatur Ende Tristate Gatter, ebenso haben die Ausnuller im PC solche.

Die Daten von der Tastatur sind Make/Break Codes, mit Bit7 0=Make=gedrückt oder 1=Break=losgelassen plus 7bit Tastennummer. Diese Nummer ist der Ort auf dem mechanischen Layout, nicht die Koordinate in der elektrischen Matrix.

Beim XT hat es eine leicht revidierte Tastatur. Dieser hat nun einen 8-kanaligen Messverstärker. Es hat eine Matrix von nur noch 12 Gruppen zu je 8 Platz, auch maximal 96 Tasten. Der 8048 Mikrocontroller zählt nur P20..P22 an den Messverstärker und pulst direkt 12bit an Port Pins P10..P17 und P24..P27 ohne Decoderchips und beobachtet die Wirkung am TI Eingang. Es entfällt die Resetleitung, die Tastatur hat eine eigene Resetlogik. Der internen Buffer ist ab nun maximal 16. Diese revidierte Tastatur wird neben am XT 5160 auch am PC 5150 Type 2 benutzt.

Beim AT wird es total anderst, weil neu LEDs an der Tastatur sind. Diese sind für CapsLock und NumLock und ScrollLock. Alle davon in einem Feld oben links, wie heute gewohnt. Wenn auch hier naheliegender, weil gerade oberhalb des Numerikfeldes sind die beiden letzteren passend zu ihre den NumLock und ScrollLock Tasten, CapsLock ist bei Esc.

Es gab zudem leichte Änderung vom Layout zwecks Optimierung. Es hat neu 84 statt 83 Tasten (extra ist SysReq, rechts oben am Numerikfeld). Ebenso sind Numerik mit Cursor+Edit Tasten rechts nun von Alphanumerik per Balken abgetrennt, wie es die Funktionstasten links schon immer waren. Die bleiben weiterhin links. Breite Tasten sind bis oben vollbreit, nicht oben normalbreit auf unten verbreitert. Hat stets horizontale Enter Taste. Numerik Enter ist nicht mehr 3 gross, nur noch 2. NumLock und ScrollLock gar nicht mehr breit, nur normal. Weiterhin die Model F Mechanik.

Als wichtigstes gab es aber ein bidirektionales Kabel, um die 3 LEDs anzusteuern. Dies braucht ein neues Interface, auch bidirektional. Dazu hat es auf dem AT Systemboard einen weiteren 8042 Mikrocontroller. Das Protokoll ist mit zwei Mikrocontrollern an beiden Kabelenden weit aufwendiger als beim dummen 74LS322 Chip. Der 8042 kann nun mit DATA=0 jegliches senden verhindern und mit dabei CLK=1 angeben dass er senden will (mit CLK=0 blockiert er alles). Die Tastatur testet bevor senden auf DATA=1 und CLK=1. Zieht dann CLK=0. Daten sind nun 1 Startbit (Tabelle sagt = 1, Text sagt = 0, die beiden widersprechen sich!), gefolgt von 8 Daten und 1 Parity Odd und 1 als Stopbit, jedes Bit gefolgt von einem CLK Puls, von 0 zu 1 und wieder 0, revers zu bisher. Die 8042 zieht CLK=0 falls sie senden will. Dies kann selbst wenn Taste unterwegs ist geschehen, was die Tastatur aber merkt, weil ihr 0zu1zu0 kein 1 mehr ergibt! Nach CLK=0 wartet die 8042 mindestens 60µs, die Tastatur muss schneller als das testen. Die Tastatur erachtet die aktuellen Daten als gescheitert und erwartet nun Kommandos vom 8042, mit erst danach Daten wiederholen und weitere senden. Dazu liefert die Tastatur 10 Taktpulse um Kommandos vom 8042 zu bekommen. Zieht dann DATA=0 und taktet elften Puls, um der 8042 die Ankunft zu bestätigen. Danach muss eine Antwort von der Tastatur kommen bevor die 8042 wieder senden darf. Default ist diese Acknowledge FA. Erst danach ist weiter Daten senden erlaubt.

Kommandos beinhalten neben dem erwarteten LEDs setzen auch Selbsttest und Identifikation, für neu den vollen heutigen "defekte oder keine Tastatur" Test. Tastatur blockieren mit 8255 Pin PB6=0 geht nicht mehr, also hat es auch Tastatur aus und ein. Aber auch die Make/Break Codes von der Tastatur sind nun anderst. Make ist 8bit Tastennummer, Break ist eine Spezialnummer $F0 gefolgt von selbige Tastennummer wie Make, trotz nicht über 128 Tasten. Die 8042 übersetzt diese neuen Codes per Default in die MSDOS gewohnten Codes, kann aber auch per Kommando auf alles durchlassen eingestellt werden. Die Tastatur selber kann beim Aufstarten erkennen ob sie an einem XT oder AT steckt und sich anpassen. (Alles ist trotzdem zu PC und XT nur teilweise kompatibel. Deren 8255 fehlt ohnehin, ebenso die DIP Schalter dahinter, weil Konfiguration nun grossteils per Setup im Echtzeituhr Chip seinem CMOS SRAM abgespeichert ist.)

Der Prozessor muss wiederum mit dem 8042 kommunizieren, an IO Adressen $060 (Daten lesen/schreiben) und $064 (Status lesen und Kommando schreiben). Nach Reset oder seinem Selbsttest Kommando, wird obiges CLK=0 gesetzt (DATA ist dabei egal). Dann wird die 8042 initialisiert, und gibt $55 an den Prozessor als Lebenszeichen. Dann wird dir Kommunikation zur Tastatur freigegeben. Versagte Kommunikation von der Tastatur resultiert in 8042 ein $FF mit in Status Parityfehler (Bit7) oder Timoutfehler (Bit6 empfangen und Bit5 senden) zum Prozessor von sich geben. Konfiguriert wird die 8042 mit Kommando $60 zu Adresse $064 gefolgt von Konfigbits zu $060. Kommando $AA erzeugt 8042 Selbsttest. Kommando $30 liest die DIP Schalter, $D1 gefolgt von Daten setzt das A20 Gate (Bit1) und die Resetleitung zum Prozessor wegen von Protected Mode zurückschalten (Bit0). All dies ein riesiger Aufwand, nur um LEDs zu haben! (Wie der Amiga mit LED zeigt geht es auch ohne all dies.)

Dann kam in 1986 für den AT das Enhanced Keyboard, mit dem Layout das wir heute alle kennen, 101 Tasten ANSI/USA oder 102 ISO/Europa, später mit 3 Windowstasten zu 105 oder 106. Sie hat nun 12 statt 10 Funktionstasten, oben statt links. Wegen der massiven Grösse gibt es auch eine Kompaktversion davon, das Space Saver Keyboard (SSK), ohne Numeriktasten und LEDs, welches aber extrem selten geblieben ist. Protokoll kann sie PC+XT 9bit oder AT 11bit, je nach wo sie angesteckt wird. Dazu hat sie wegen mehr Tasten auch noch 3 auswählbare Sätze von Make/Break Codes. ATs laufen zumeist mit Codesatz 2, Grossrechner Terminals mit 3. (Eine Quelle behauptet aber, dass ATs mit einem modifiziertem 3 laufen, 2 gar nicht benutzt wird.)

Was auch total anders wurde ist die neue Model M Mechanik. Diese hat weiterhin die Buckling Spring und davon kippende Grundplatte, identisches Feedback. Aber alles mit Kapazitäten und Messverstärker ist weg. Statt dessen hat es Membrankontakte, ein verschweisstes Folienpaket von 3 Lagen, mit Leiterbahnen an den Innenseiten von 1 und 3, und dort wo sie sich kreuzen Löcher im Abstandshalter 2. Die Grundplatte hat statt einer Metallschicht einen Noppen, welche Folie 1 durch 2 auf 3 drückt.

Wegen direktem elektrischen Kontakt im Folienpaket braucht es auch keinen Messverstärker mehr, der Mikrocontroller kann direkt 8 Tasten aufs mal einlesen. Aber wegen den mehr Tasten ist die Matrix nun 16 Gruppen von 8 statt 12. So hat es Platz für 128 statt 96. Sie kann wieder direkt ohne Decoder angesteuert werden, vom nun verwendeten 6805 Mikrocontroller, der 32 statt 24 Port Pins hat. Dieser zieht jeweils eine von 16 Ausgangsleitungen PB0..PB7 und PC0..PC7 auf 0, kann damit Strom versenken, weil zu 0V abfliessend. Dies aber nur durch alle gedrückten Tasten von der Reihe, während Tasten aller anderen Reihen mit 1 keinen Strom versenkt bekommen. Daher erscheinen an den 8 Eingangsleitungen PD0..PD7 nur in dieser Reihe gedrückte Tasten als 0, ohne solche ist alles 1. Wenn 2 Tasten einer Reihe und eine gleichpositionierte einer anderen Reihe gedrückt werden entsteht der Eindruck als wenn auch in der anderen Reihe 2 gedrückt sind. Das Extra ist als Phantomtaste bekannt. Daher befinden sich gerade Shift/Ctrl/Alt Tasten vermutlich nur in ihren Paaren in einer Reihe, was dann zu 16 statt 13 Reihen führt, was aber ausreicht.

Ebenfalls wegen Kontaktfolie hat es keine Platine mehr. Vielmehr ist diese zwischen einer schweren Stahlplatte und dem Kunststoffrahmen der Tastenführungen verlegt. Das erlaubt sie konkav zu sein, mit alle Tastenreihen in anderem Winkel stehen, statt mit verschieden angewinkelten Tastenkappen zu arbeiten. Das Resultat ist extrem freundlich und komplett unverwüstlich.

(Ich tippe dies in 2024 auf einer Model M von Baujahr 1989. Diese habe ich irgendwann in 1995 oder 1996 an einer Computerbörse gebraucht aufgelesen und benutzte sie seither 30 Jahre lang fast täglich 5..10 Stunden, als Vieltipper, weil Programmierer und Author. Bis auf eine etwas langsam loslassende rechte Shifttaste ist sie noch komplett gut. Beste Tastatur der Weltgeschichte.)

Die PS/2 hat das Enhanced Keyboard zu Standard gemacht, selbige Mechanik, nur den Stecker ersetzt von DIN5 zu MiniDIN6, aber mit selbigen Signalen. Pinout ist neu als 1 Datenbits (DATA), 2 leer, 3 0V (GND), 4 5V (+5V), 5 Takt (CLK), 6 leer. (Die beiden leeren Pins werden bei IBMs RS/6000 Workstations genutzt, 2 Signal und 6 GND für den Beep Lautsprecher in der Tastatur statt vorne im Rechner, der oft unter dem Tisch steht.) Adapter von AT zu PS/2 sind nur Stecker umverdrahten. Dies definierte den PS/2 Tastatur Standard, der lange anhielt, bis erst nach 2000 die USB Tastaturen aufkamen.

(Zum Glück gibt es PS/2 zu USB Adapter, um die Model M auch an moderne Rechner anzuschliessen. Wenn auch sie beim Stromverbrauch vom alten NMOS Mikrocontroller ab und zu mal spontan sich abmelden und wieder anmelden, Tastendruecke dabei verloren gehen.)

Mac

Im Gegensatz zu IBM hat Apple keine Jahrzehnte an Forschungstradition in Tastaturen herstellen, sind eine reine Rechnerfirma. Also haben sie schlicht Tastaturkomponenten eingekauft. Diese sind vom Hersteller aus zumeist separate Tastenmechanismen, wegen jeder Abnehmer ein eigenes Tastaturlayout machen wollen. Apple ihr genereller Partner für mechanische Teile ist Alps, von denen sie die SKCM Tastenmechanismen verwendet haben. Aber auch von Mitsumi die Standard Mechanical in der zu Alps Tastenkappen kompatiblen Aufsteckform wurden teilweise verbaut.

Als mechanische Kontakte sind sie direkt vom Mikrocontroller lesbar. Das einzige auffindbare Photo mit dem Mikrocontroller scheint ein 8042 zu sein, erstaunlich dieser bustaugliche Spezialist und nicht ein generischer 8048. Inside Macintosh meint es sei ein 8021. Wie beim Enhanced Keyboard werden vermutlich 8 Tasten aufs mal eingelesen. Mit nur 59 Tasten reicht dazu selbst eine Matrix nur 8 lang.

Der Mikrocontroller sendet die Daten zum Rechner synchron seriell. Durch ein 4-adriges Kabel mit 4P4C Stecker (selbigen wie teilweise am Kabel von Telephon zu Höhrer benutzt wird). Pins 1 0V (CGND), 2 Takt (KBD1), 3 Datenbits (KBD2), 4 5V (KPWR). Dies wird sicher mit reinem Bitbanging gemacht. (Achtung! Das verwendete Kabel ist wegen verkreuztem Pinout nicht mit Telephonhöhrer Kabeln kompatibel. Solche hier benutzen legt die Stromversorgung verkehrt an und zerstört den Mikrocontroller.)

Die Daten gehen im Mac zur 6522VIA ihrem Shiftregister. Dieser hat aber im hierzu verwendeten Empfangsmodus einen bekannten Bug, wonach er bei ungünstigem Timing der Tastatur Taktpulse relativ zum Prozessortakt die Impulse verliert und damit Bits! Da er jeweils 8bit zählt, verliert er ab dann die ganze Synchronisation aller folgenden Bytes, was auf ein totes Tastaturinterface hinausläuft. Dieser Bug kann aber mit Takt synchronisieren umgangen werden, das Taktsignal von der Tastatur derart verzögern, dass es niemals im kritischen Zeitpunkt ankommt. Da alle 16R PALs im Mac Pixeltakt haben, wird das nebenbei erledigt im TSG PAL, mit Takt synchron von Tastaturanschluss KBD.ACLK (A=asynchron) zu KBD.SCLK (S=synchron) an die VIA durchreichen. Weil damit der Takt nicht direkt ist, ist reversieren nicht möglich, es muss stets die Tastatur takten, egal ob Daten von ihr zum Rechner gehen oder umgekehrt!

Daten sind wegen der 6522VIA synchron, 8bit ohne Start/Stop, mit Bit7 als erstes. Bitrate Tastatur zu Rechner ist 1/330µs = 3kHz, aber Rechner zu Tastatur 1/400.µs = 2.5kHz. Kommunikation startet vom Rechner(!), Kommando in die 6522VIA legen, und damit nebenbei KBD.DATA=0 setzen (alle Bytes dieser Richtung haben Bit7=0). Die Tastatur taktet dann das Kommando aus der VIA hinaus, welches wiederum mit KBD.DATA=0 enden muss (alle Bytes auch Bit0=0). Der Rechner meldet bereit für Antwort mit KBD.DATA=1 schalten. Die Tastatur sendet dann Antwort. Erstes Kommando nach einschalten ist $16, Tastatur Reset plus Modelnummer von sich geben. Mit $36 Selbsttest und $7D=gut oder $77=schlecht antworten. Mit $10 Anfrage werden Tasten geholt ($7B falls keine), mit bis zu 1/4s abwarten. Mit $14 Anfrage sofort ohne warten. Die Daten von der Tastatur sind Make/Break Codes, Bit7 0=Make=gedrückt oder 1=Break=losgelassen plus Bit6..1 Tastennummer und Bit0 stets 1.

Erst in Mac Plus seinem M0110A wurde die Tastatur verbessert. Mit nun Cursortasten (in Laptop-artiger Anordnung, zuerst links/rechts, dann auf/ab) und eingebauten Numeriktasten. Aber weiterhin ohne jegliche Edittasten, und ohne Funktionstasten, ebenso kein Ctrl/Esc.

Ab dem Mac SE und Mac II gab es einen Wechsel zum Apple Desktop Bus (ADB) statt dem bisherigen Tastaturanschluss (und Mausanschluss). Dieses kam vom Apple IIGS her. Es erlaubt beliebige Eingabegeräte anzuschliessen, verlangt aber, dass jedes davon einen Mikrocontroller drin hat (auch die Maus). An Tastaturen gab es entweder Standard M0116 (selbiges Layout wie Mac Plus) oder Extended M0115 (Layout sehr änlich dem IBM Enhanced, das was heute alle Macs haben).

Joystick

AT

Als IO Adressen nimmt der Game Control Adapter $201 (nicht $200..$20F, nur genau $201, die Adresse wird voll decodiert!). Er benutzt dazu zwei 74LS138, erster an U2 nimmt A9..A4 = %10'0000'xxx, zweiter an U1 obiges plus A3..A0 = %xx'xxxx'%0001, ergibt zusammen $201. ROM Adressen benutzen sie keine, weil ihre Treiber bereits im BIOS drin sind, aber jedes Spiel ersetzt ohnehin diesen durch eigenen. (Später als Soundkarten aufkamen wurde der Game Control Adapter fast stets auf diesen integriert.)

Mechanismus hinter diesen sind Potentiometer (Pots), 1 pro Paddle oder 2 pro Joystick (je 1 pro Achse). Diese in ihrer verstellbaren Widerstand (nur 2 Anschlüsse) Konfiguration, nicht als Spannungsteiler (alle 3 Anschlüsse). Pro Kanal hat es auf der Karte einen Kondensator von 10nF (Apple II 22nF). Der wird anfangs entladen durch einen Impuls per Schreibzugriff auf $201 (Apple II $C070), und danach geladen via dem Pot, mit dazwischen noch einem Widerstand von 2.3kOhm (Apple II 100Ohm) um Kurzschluss zu verhindern. Je nach Drehwinkel vom Pot, und damit dessen Widerstandswert, max 100kOhm (Apple II max 150kOhm), fliesst mehr oder weniger Strom, und laden geht schneller oder langsamer. Der Rechner misst die Ladezeit und schliesst davon auf den Drehwinkel. Formel wird im PC Handbuch beschrieben als "Time = 24.2µsec + 0.011 (r) µsec", mit r max 100'000Ohm ergibt das bis max 1124.200 µsec. Als Analogbauteil wird dazu ein NE558 verwendet (wie in Apple II).

Neben dessen 4 Analogkanälen ihrer nicht=1/schon=0 geladen Ausgabe werden noch 4 Digitalsignale/Tasten (Apple II nur 3) erfasst mit nicht=1/gedrückt=0. Der Prozessor kann all diese 4+4=8 als Bits einlesen, durch einen 74LS244 an U5, mit Lesezugriff auf $201, Analog A..D in Bit0..3, Tasten A..D in Bit4..7 (Apple einlesen durch ein 74LS251 stets an Bit7, Tasten auf $C061..3, Analog auf $C064..7).

Anschluss ist ein DA15f mit Stecker DA15m. Pins sind 1+8+9+15 5V, 4+5+12 GND, 3+6+11+14 Analog A..D via Pots von 5V, 2+7+10+14 Digital A..D via Tasten zu GND. Für 2 Joysticks anschliessen wird ein Y-Kabel benutzt, das einfach ersten Stecker an 1..8 und zweiten an 9..15 zieht (mit 12 dupliziert zu 4+5). (Nach integrieren auf Soundkarten wurden oft einige der duplikaten GND und 5V durch MIDI Signale ersetzt.)

Die Joysticks selber waren (wie bei Apple II), normale Modellflieger Fernsteuerung Steuerknüppel Mechanismen. Dazu noch Tasten. Dann Kabel dran und Gehäuse darum, und schon ist fertig. Wegen PC und erst recht AT genug Prozessorleistung, sowie CGA und vor allem EGA genug Bitmap, waren bald Flugsimulatoren verbreitet (sogar von Microsoft, welche dazu Sublogic aufgekauft haben). Diese Software unterstützte bald auch 2 Joysticks, neben ersten für Quer+Hoch Rudder auch zweiten für Seiten+Motor. Darin Motor mit Stellratsche statt Rückzugsfeder, weil schon bei Fernsteuerungen die Steuerknüppel so umbaubar sind.

Manche Modellflieger haben kurzerhand ausgediente Fernsteuerungen entkernt (Antenne weg sowie Sender und Akku raus) und neu verkabelt, als "Schlechtwetter Flieger". Damit hatten sie 2 Joysticks in einem ohne das Y-Kabel. Folglich entstanden bald spezielle Fliegerjoysticks, mit 2 Achsen plus Motorstellrad (wie CH Products F-16 Combatstick) oder gar 3 Achsen (durch Joystick Hebel verdrehen, wie Microsoft Sidewinder). Als Maximum kamen von realen Privatfliegern abgeleiteten Kombinationen von 2 Achsen Steuerhorn plus 1 Achse Fusspedale. Oder gar von Jagdfliegern abgeleiteten Joystick plus 1 Achse Schubregler plus 1 Ache Fusspedale, für HOTAS (= Hands on Stick and Thrust) betrieb (wie Thrustmaster Flight Control System). Letztere auch mit mehr als 2+2 Tasten, die restlichen in das AT Tastaturkabel einzuklinken.

Andere Spieler wollten aber scharfe schnelle Digitaleingabe wie bei Spielautomaten, entweder als Spielhallenjoystick oder gar als Spielkonsolengamepad (wie Gravis PC Gamepad). Auch hier kann der Game Control Adapter mithalten, trotz auf analog ausgelegt. Trick ist mit durch Joystick oder Steuerkreuz schaltbarem Widerstand zu arbeiten. Dazu wird ab einstecken der Kondensator per kleinen Widerstand geladen. Damit kann der Löschimpuls am 1 zu 0 Wechsel erkannt werden, mit davon einen Timer starten. Bis dieser losgeht sind die Analogeingänge auf unendlich Widerstand, dann wird auf kleinen oder null Widerstand geschaltet und nach 1 erreicht wieder losgelassen. Timer ist je einer pro Richtung horizontal und vertikal, und kann in kurz/halblang/lang geschaltet werden, je nach ob Joystick oder Steuerkreuz auf min/mitte/max sind. Dazu kommen noch normale Taster. (Dank Mikrocontroller drin kann man sogar beim Gravis PC Gamepad auf/ab reversieren für Steuerkreuz auf Linkshand wenden, oder gar zwischen voll 4 Taster oder Y-Kabel kompatibel nur 2 Taster schalten.)

Mac

Ab dem Mac SE und Mac II gab es einen Wechsel zum Apple Desktop Bus (ADB). Es erlaubt beliebige Eingabegeräte anzuschliessen. Darunter auch Joysticks möglich. Aber auch da waren es nur Dritthersteller, mit geringer Verbreitung, weil keiner schreibt Spiele ohne Hardware verbreitet und keiner kauft solche ohne Spiele welche sie nutzen. Henne-Ei Problem. Apple hat sich so selber aus der Spielewelt ausgeschlossen. Und ist es bis heute gebleiben, nur eine Randerscheinung. Erst iPhone/iPad wurden wegen Touch spieletauglich, bleiben aber hinter Android zurück.

Maus

Erfunden wurde die Maus vor langem, bevor Apple überhaupt existierte! Sie entstand Ende 1960er am Augment Projekt der Universität Stanford. Dies war das Resultat von deren Forschung um ein gutes Steuergerät zu haben, um schnell und präzise Textpositionen auf einem Bildschirm auszuwählen. Wohlgemerkt diese Experimente liefen anfangs auf einer CDC160, einem 12bit Rechner von 1960, mit 6kByte (strikte 4kWort zu je 12bit) Kernspeicher, zum Preis von damaligen $100'000 (Inflationskorrektur rechne etwa *10). Xerox Palo Alto Research Centre (PARC) hat 1972 beim Design vom Alto die Maus übernommen und 1978 beim Dorado weitergezogen und schliesslich 1981 mit dem 8010 kommerzialisiert.

Mac

Technisch muss die Maus zwei Bewegungsrichtungen messen. Dazu hatte die originale Stanford Maus zwei Räder, welche auf der Tischplatte abrollen. An deren Achsen befinden sich Winkelmesser. Diese erzeugen Pulse pro Weg, als Ticks bekannt. Pro Rad braucht es zwei Pulserzeuger, welche um 90grad phasenverschoben sind. Drehung in einer Richtung erzeugt somit die Folge 00 01 11 10 00 ..., in die andere Richtung 00 10 11 01 00 ..., womit man den Weg aus der Pulsanzahl und die Richtung aus der Pulsfolge ermitten kann. Sowas nennt man Quadraturcode. Es kann dazu eine elektromechanische Abtastung geben, durch Kontakte auf einer Scheibe mit strahlenförmigen Leiterbahnen, oder eine optische Abtastung, mit Lichtschranke durch eine Scheibe mit strahlenförmigen Lamellen.

Bei der Rollkugelmaus seit Xerox rollt nur die Kugel auf dem Tisch, ohne zu schleifen wie eines von zwei Räder würde. Das weil sie die gewollte Achse mitdreht und die andere nur am Berührungspunkt verdrehend schleift. Vorteil noch dass die Achse weit schneller dreht, weil nur Achsumfang und nicht Radumfang dem Weg entspricht, womit der Mauszeiger weit stufenloser bewegt werden kann.

Die Mac Maus ist eine blanke Rollkugelmechanik mit Analogelektronik um die Winkelmesser zu digitalisieren, damit die Quadraturcode Signale zu TTL Logik kompatibel sind. Dazu kommt noch eine einzelne Taste, trotz dass Xerox bereits beim Alto drei verwendet hat. Die Apple Maus hat keinerlei Mikrocontroller oder sonstige Logik in sich. Sie verwendet eine DE9f Buchse. Pinout ist 1 0V (CGND), 2 5V (+5V), 3 0V (CGND), 4 X2, 5 X1, 6 leer, 7 Taste, 8 Y2, 9 Y1. Wobei X1 und X2 die beiden horizontalen Quadraturcode Signale sind, sowie Y1 und Y2 vertikale. Diese Maus ist bei Apple II und Apple III und Lisa und Macintosh elektrisch identisch!

Beide X1 und Y1 gehen als Signale MSE.X1 und MSE.Y1 an den SCC Serial Chip. Dessen Modemsteuersignal Pins sind vom Mac seinen Seriellports her nur teilweise benutzt. Also werden die beiden Ports ihre /DCD Pins hier missbraucht, weil sie bei gepulst werden Interrupts auslösen können. Die beiden X2 und Y2 gehen dagegen als MSE.X2 und MSE.Y2 an die 6522VIA Pins PB4 und PB5. Die Interruptroutine testet diese für Richtung. Es gilt hier wenn X1/Y1 Wechsel von 0 zu 1, falls X2/Y2=0 ist unterwegs nach links oder abwärts (zu Benutzer), falls X2/Y2=1 nach rechts oder aufwärts (weg von Benutzer). Dazu kommt noch die Maustaste als Signal /MSE.SW and die 6522VIA Pin PB3, gedrückt = 0. Diese wird immer im Vertikalrücklauf gelesen, um Mehrfachclicks zu vermeiden, welche entstehen würden wegen dem Federkontakt der Taste prellen.

Ab dem Mac SE und Mac II gab es einen Wechsel zum Apple Desktop Bus (ADB). Es erlaubt beliebige Eingabegeräte anzuschliessen. Das verlangt aber, dass jedes davon einen Mikrocontroller drin hat. Folglich wurde die Maus mit einem ausgestattet. Man beachte noch, dass ADB von Geräten erwartet, dass sie zwei Anschlussbuchsen haben, um weitere Geräten am Bus zuzulassen. Die Maus ist eine Ausnahme, sie hat keine Anschlussbuchsen nur ihr eines fest eingebautes Kabel, und ist damit immer letztes Gerät am Bus.

AT

Als erstes kommt Microsoft dran, weil sehr früh und sehr ähnlich zum Mac. Microsoft wusste bereits 1983 vom Mac, wegen Word von MSDOS auf MacOS portieren. Sie wussten auch um den Hintergrund bei Xerox. Daher entstand ihr Interesse an Windows schreiben. Aber das braucht eine Maus. Diese kann man aber auch von MSDOS Programmen aus nutzten, mit dem MOUSE.SYS Treiber, sofern die Programme dabei mitmachten.

(Strikte gab es einen Cursortasten mit Mausbewegung emulieren Utility, aber es war je nach Program praktisch unbrauchbar, dies gerade auch in Microsoft ihren Programmeditoren, weil diese gut auf links-rechts reagierten, aber nur minimal auf-ab in einer langen Textzeile nach rechts gehend und der Cursor sprang zum Ende der Zeile oben bzw unten. Nervig wenn man eine lange Zeile abfahren will, aber immer wieder auf das Ende der kürzeren davor und danach zurückgesetzt wird.)

Technisch ist sie identisch mit der Mac Maus, also eine blanke Rollkugelmechanik mit Analogelektronik ohne Mikrocontroller. Nur zwei Tasten statt eine. Sie verwendet einen MiniDIN9 Stecker namens InPort. Pinout ist 1 5V, 2 XA, 3 XB, 4 YA, 5 YB, 6 Taste L, 7 Taste M, 8 Taste R, 9 GND, Schirm CGND. Trotz von Microsoft designt, welche zwei Tasten benutzen, mit Pins für drei Tasten, universell! Angeschlossen wird diese an die Busmaus Karte. Auf dieser sitzt ein Mikrocontroller, vermutlich ein 8042. Microsoft versuchte, dieses zum Standard zu machen, direkt auf Videokarten verbaut, aber mit nur wenig Erfolg.

Grund dazu war, sehr bald kam die Serielle Maus am RS232 COM Port auf, weil sie keine Busmaus Karte braucht, weder eine eigene noch auf der Videokarte. Sie kommt an den oft nicht genutzten bestehenden COM1 Seriellanschluss. Sollte jemand diesen doch für ein Modem benutzen wollen, kann der PC auch mehrere COM Ports haben, Maus an COM1 und Modem an COM2. Anfangs mit DB25f Stecker, und Adapterkabel zu DE9f falls vorhanden wegen AT, aber bald mit DE9f, und Adapterblock zu DB25f falls noch PC oder XT.

Weil RS232 nichts von Maus Hardware weiss, nur einen seriellen Bytestrom zu/von einem Modem erwartet, mit Annahme von anderem Rechner hinter der Modemverbindung, oder direkt mit einem Nullmodem Kabel, haben Serielle Mäuse stets einen eigenen Mikrocontroller eingebaut. Dieser kann wegen nur RS232 und kein PC Bus von beliebigem Typ sein. Die Daten zum PC senden ist einfach, über dessen RxD Leitung. Problem ist Stromversorgung, weil RS232 keine liefert, wegen mit einem Modem rechnen. Also werden Leitungen missbraucht, GND ist an 0V, TxD ohne gesendete Daten bleibt dauernd als -12V sowie RTS und DTR als +12V. Die Maus muss eine 12V zu 5V Reduktion haben um den Mikrocontroller zu versorgen. Weiter muss sie eine 5V zu +/-12V Signalumsetzung haben um das RxD zu treiben, von RTS und DTR sowie TxD versorgt. Mehrere Hersteller haben dies benutzt, logisch die RxD Bytes wieder inkompatibel zu einander.

Microsoft selber definierte einen verbreiteten Standard. Dieser setzt RS232 auf 1200bps Bitrate und 7N1 Bitanordnung. Mausbewegungen erscheinen als Datenpakete von 3 Bytes (naja, 3 7bit Worten): %1LRYYXX %0XXXXXX %0YYYYYY. Dabei markiert 1 das erste Byte, 0 alle anderen. L und R sind die Maustasten, hier nur zwei, mit 1=gedrückt. Die XX und YY sind oberste 2bit und die XXXXXX und YYYYYY untere 6bit der Mausbewegung seit dem letzten Paket. Bei Stillstand und nur Knopfbewegung hat 0, bei langsamer Bewegung stets -1 oder +1, wenn in erster/vorheriger Paketzeit weiter bewegt dann mehr. Weiter gilt RTS aus/ein für >100ms resettet die Maus. DTR aus/ein sendet die Maus ein Identbyte "M" (%1001101 = $4D).

Logitech erweiterte diesen Standard für drei Tasten. Auch hier eine Softwarefirma, welche eine Maus haben wollte, für ihr Modula-2 Editor+Compiler System. Dieses basierte auf der Arbeit von Nikolaus Wirth am Lilith Rechner, der wiederum vom Xerox Alto inspiriert war. Also waren drei Tasten gewollt. Logitech addiert dazu nur ein viertes Byte zum Paket, mit %0M00000. M ist die dritte mittlere Maustaste, mit 1=gedrückt.

Mouse Systems definierte dagegen einen ganzen eigenen Standard. Dieser setzt RS232 auf 1200bps Bitrate und 8N1 Bitanordnung. Mausbewegungen erscheinen als Datenpakete von 5(!) Bytes: %10000LMR %XXXXXXXX %YYYYYYYY %XXXXXXXX %YYYYYYYY. Dabei markiert 10000 das erste Byte. L und M und R sind die Maustasten, hier drei, mit 0=gedrückt. Die XXXXXXXX und YYYYYYYY sind Bewegung. Es hat pro Paket 2 mal Bewegung, damit das Protokoll identisch bleiben kann wenn an der Maus separate Bewegung der beiden Sensoren eingestellt ist, um auch Maus rotieren zu erkennen. Man beachte dazu, dass Maus Systems keine Rollkugel verwendet, sondern 2 LEDs (rot und infrarot), mit denen sie einen speziellen Mousepad aus Aluminium mit einem Gittermuster drauf (Grau und Blau) beleuchtet, gefolgt von das reflektierte Licht auf 2 Streifen Photodetektoren schicken.

Erst später kam die PS/2, mit selbigem Stecker und Signale wie die PS/2 Tastatur. Dies beinhaltet auch Kommandos vom PS/2 bekommen. Deshalb braucht es auch bidirektional. Dazu hat es als Interface auf dem PS/2 Systemboard den selbigen 8042 Mikrocontroller wie die Tastatur. Die Maus wird erst nach $F4 (Enable Data Reporting) aktiv, mit danach $FA (Acknowledge) antworten. Wie Microsoft Maus mit zwei Tasten. Datenformat von IBM ist 3 Bytes: Erstes ein 8bit Muster YO XO YS YS 1 0 R L dann zwei XXXXXXXX und YYYYYYYY. Die L und R sind Tasten. Die XO und YO sind Overflow Angabe (Maus weiter bewegt als gezählt werden kann), die XS und YS sind Sign (Vorzeichen, also Richtung), die XXXXXXXX und YYYYYYYY sind nur Bewegungsdistanz, und zwar vorzeichenlos! Kommandos und Antworten sind also erkennbar an unwahrscheinlichem zu weit in beiden Richtungen. (Logitech erweitert dies für drei Tasten mit 0 ersetzen durch M.)

Seriell

AT

RS232 verlangt nach Signalen mit +/-12V, nicht TTL 5V/0V. (Strikte ist bis 5V hinunter senden und bis 3V empfangen legal, und bis 15V hinauf senden.) Dazu wurden im PC die häufigen Spannungswandler 1488 (von 5V zu +/-12V) und 1489 (von +/-12V zu 5V) benutzt, welche je 4 Signale wandeln können. Wegen 3 Ausgangsleitungen (TxD+RTS+DTR) reicht ein 1488, aber wegen 5 Eingangsleitungen (RxD+CTS+DSR+DCD+RI) braucht es zwei 1489. (Cloner ihre Doppelport Karten benutzen zwei 1488 und drei 1489.)

Der PC kann bis zu 4 Asynchronous Communications Adapter aufnehmen. Als IO Adressen nehmen diese COM1 $3F8..$3FF und COM2 $2F8..$2FF sowie später COM3 $3E8..$3EF und COM4 $2E8..$2EF. Der originale benutzt dazu einen 8-NAND Chip an U2 (Typ nicht dokumentiert) mit daran A3..A7 und A9 = 1 (ergibt %1x'1111'1xxx = $xF8) sowie A8 per Jumper = 0oder1 von Inverter an U3 (ergibt $2oder3xx). Spätere erweiterte Karten müssen noch A4 per Jumper = 0oder1 erlauben. Interupts teilen COM1 und COM3 IRQ 4 sowie COM2 und COM4 IRQ 3. (Oder man nimmt die Parallelport IRQ 7 und IRQ 5, oder beim AT auch IRQ 10 und IRQ 11, vorausgesetzt eine erweiterte Karte kann diese überhaupt per 16bit Bus anwählen.)

In AT mit seinem schnelleren 80286 kamen auch schnellere 16450 Chips zum Einsatz. Diese können bis auf maximal 115'200bps hinauf. Das kommt vom bereits mit der 8250 benutzten 1.8432MHz Quarz, der /192 dessen 9600 erzeugte. Man kann mit statt dessen /48 auf 38'400 hinauf, die 115'200 entstehen mit auf minimales /16 hinaufgehen. Strikte kann die 8250 bis 57'600 hinauf funktionieren, aber IBM limitiert sie auf 19'200 im PC BIOS. Die 16450 ist sogar pinkompatibel, aber inkompatibel mit Software welche direkt auf die 8250 Register zugreift, statt über das langsame und daher oft gemiedene BIOS zu gehen.

Gleichzeitig legte IBM beim AT Seriell und Parallel zusammen auf eine Karte, Serial / Parallel Adapter, um Slots zu sparen. Dabei passten aber zwei DB25 Buchsen nicht auf ein Slotblech, also wurde die ohnehin nur teilweise ausgenutzte DB25m RS232 Buchse durch einen eigenem kompakteren DE9m ersetzt. Pins erstaunlich total anderst angeordnet 1 DCD, 2 RxD, 3 TxD, 4 DTR, 5 GND, 6 DSR, 7 RTS, 8 CTS, 9 RI.

Solange man serielle Daten per Polling direkt ab den 16450 Register liest (BIOS war weitaus zu langsam) waren selbst 115'200bps kein Problem. Sobald aber alles in Multitasking Systemen per Interrupts geschehen musste wurde der Prozessor von diesen geflutet. Also erschien die 16550 mit eingebautem 16Byte FIFO Buffer. Sie startet in 16450 Modus, ist also voll kompatibel, muss aber deswegen auf 16550 Betrieb umgeschaltet werden. Beim ersten Byte gibt es sofort Interrupt, für falls es das einzige ist, aber danach wird eine gewisse Menge Zeit Interrupt intern gesperrt, in der die FIFO aufgefüllt wird, und dann mit nur einem Interrupt in einem Rutsch ausgelesen werden kann.

(Cloner ihre Parallel+Doppelseriell Karten hatten zumeist Parallel und erstes Seriell auf Karte Slotblech und zweites Seriell auf Hilfsslot, seltener nur Parallel auf Slotblech und beide Seriell auf Hilfsslot. Manche dieser hatten auch Game Control Adapter drauf, zumeist auf dem Hilfsslot, seltener auf einem zweitem Hilfsslot. Aber letzteres verschwand bald wegen wenig benutzt und erst recht als Soundkarten aufkamen und Game dort integriert wurde.)

(Um diese Zeit herum wurden die verbleibenden 3 Funktionen auf einen einzelnen Chip integriert. Anfangs 1990er kam dann die Standardkombination auf, von diesem Chip plus Floppy und ATA Harddisk auf eine Kombikarte. Damalige 286/386/486 waren praktisch nur noch Systemboard (mit Tastatur daran) plus Video plus obige Kombokarte (mit Maus an COM1) plus eventuell Sound+Game. Erst zweite Hälfe 1990er kam mit Pentium auch PCI und USB, was den modernen PC brachte und den traditionellen PC beendete (bzw zum Retro PC machte).)

Mac

Buchsen und Stecker sind in RS422 keine definiert. Apple hat am Mac DE9m benutzt, selbiges wie AT für RS232. Pin 1 CGND, 2 +5V, 3 GND, 4+5 TxD+/-, 6 +12V, 7 HSK (Handshake), 8+9 RxD+/-. Da keinerlei Steuerleitungen ausser HSK Eingang, reichen selbst die nur 2 Wandler in einem 26LS30 für beide Ports, und mit HSK die 4 Wandler in einem 26LS32. Das HSK geht an die Seriellchip /CTS Signale, kann von extern /DTR getrieben werden, es geht aber ebenso an /TRxC, kann so für schnelle synchrone Übertragung benutzt werden. Weiter ist beim 26LS30 der Ausgang mit einem /OEBUF Signal abschaltbar, vom /RTS Signale her, um die Ports als Netzwerk zu nutzen. Was genau beim Mac Plus mit LocalTalk gemacht wurde, welches daher auch auf 512Ke nutzbar ist, weil schon am originalen 128K so verdrahtet.

Dahinter sitzt der sehr leistungsfähige 8530SCC Chip, nur einer für beide Ports. Dieser benutzt aber Intel+Zilog Signalisierung mit separaten /WR (Schreibzugriff) und /RD (Lesezugriff) Signalen, statt Motorola+MOS (welche die 68000 generiert) mit /AS (Zugriff) und R/W (lesen oder schreiben), plus noch /LDS und /UDS (wegen Byte/Wort Zugriffen). Also muss der Mac dieses "übersetzen", was das BMU1 PAL nebenbei macht. Gelesen wird mit /UDS und nicht /LDS (Bytezugriffe an geraden Adressen), und geschrieben mit /LDS und nicht /UDS (Bytezugriffe an ungeraden Adressen). Dieser Widerspruch geht, weil die Datenleitungen an Prozessordaten D8..D15 sind, lesen braucht das fest so, aber schreiben kann auch "verkehrt" sein, weil der Prozessor die Daten von D0..D7 auf D8..D15 dupliziert! Damit kann /LDS direkt als /WR Signal genutzt werden, neben /CE von /SCCEN von BMU1 PAL kommen, bei ganze 4MByte Adressen $800000..$BFFFFF aktiv. Dazu kommt ein weiteres /SCCRD vom PAL an /RD, nur in der unteren Hälfte 2MByte Adressen $800000..$9FFFFF. Gelesen wird also insgesammt mit geraden Adressen in $800000..$9FFFFF, geschrieben mit ungeraden in $A00000..$BFFFFF! Die SCC ihre Registeradressen A/B und D/C kommen noch von Prozessoradressen A1..A2, also in 1 Wort bzw 2 Byte Schritten. Offiziell benutzt wird sie lesend ab $9FFFF8, schreibend ab $BFFFF9.

Die SCC können bis zu 230'400bps laufen (das ist doppelt eines AT mit 16450 Chips!). Erst damit wird LocalTalk sinnvoll. Dazu wird der Pixeltakt geteilt, zuerst im TSG PAL von 15.6672MHz /4.25(!) auf 3.6864MHz (mit Namen 3.7M) für zum SCC und in diesem weiter /16, insgesammt /68, auf 230'400. Ein Text online spekuliert, dass das TSG dazu einen selektiven /4 oder /5 Zähler beinhaltet, der jede vierte Runde /5 macht. Die Anzahl unbeschalteter Flopflops (R Pins vom TSG) passen dazu. Der TSG kann dazu neben auf seinem selbst generieres 8M auch auf 4K und TC vom TSM PAL zurückgreifen. Dies ist eigentlich die Hauptaufgabe vom TSG, neben noch etwas Gemischtwarenladen für diverses anderes sein.

Im Mac Plus wird gewechselt von DB9m auf MiniDIN8. Dies ist wegen Platzbedarf reduzieren, um Platz zu schaffen für den SCSI Anschluss.

Parallel

AT

Der PC kann bis zu 2 Parallel Printer Adapter aufnehmen, plus falls MDA Videokarte noch dessen Printer Port. Als IO Adressen nehmen diese erste $378..$37F und zweite $278..$27F. Sie benutzen dazu einen 74LS30 8-NAND Chip an U5 mit daran A3..A6 = 1 sowie A7 = 0 und A9 = 1 per 74LS02 an U9 (ergibt %1x'0111'1xxx = $x78), sowie A8 per Jumper = 0oder1 auf 74LS86 an U11 (ergibt $2oder3xx). Auf MDA hat es IO Adressen $3BC..$3BF, von dessen bereits bestehenden Decodierung her. Interupts gehen an IRQ 7 oder allenfalls zweiten an IRQ 5, zumeist nicht genutzt.

In jedem IO Bereich hat es 3 Register. Basisadresse+0 schreibend Daten an D0..D7, lesend Daten von D0..D7. Basisadresse+1 nur lesend Status Bit3..7 von Eingang Pins 15+13+12+10+11 (Bit0..2 unbenutzt). Basisadresse+2 schreibend Bit0..3 an Ausgang Pins 1+14+16+17 plus Bit4 IRQ zulassen wenn /ACK gezogen wird (Bit4..7 unbenutzt), lesend selbige 5 Bits plus Bit5 Interrupt Status lesen.

Erst in PS/2 wurde dieser Standard Parallel Port (SPP) erweitert zum Enhanced Parallel Port (EPP). Auf diesem ist das bisher ungenutzte Basisadresse+2 Bit5 nun benutzbar um die Basisadresse+0 Daten an D0..D7 ausgeben abzuschalten, wonach diese Pins lesend zu Eingängen werden. Dieses Bit kann aber nicht ausgelesen werden, weil dort schon den Interrupt Status lesen ist. Diese Funktion auf Bit6 zu stellen ist IBM nicht eingefallen.

Mac

Echtzeituhr

AT

Der AT brachte eine standard Echtzeituhr. Diese bestand aus einem Motorola MC146818 RTC+SRAM Chip, an IO Adressen $070..$07F (selbige welche auch das /NMI schalten!). Darin hat es neben 10Bytes Uhr und 4Bytes Status/Konfiguration noch 50Bytes SRAM. Letztere werden ebenfalls per Akku am Leben gehalten, und ersetzen zusammen mit der Setup Floppy die PC und XT 2*8 DIP Schalter an der 8255PPI. Dieses SRAM war oft unter dem Namen CMOS bekannt.

Mac

Der Mac hat einen Apple-eigenen 8pin RTC Chip hinter der 6522VIA. Dieser hat neben 2 Pins 5V und 0V den typischen 32.768kHz Quarz an 2 weiteren. Es hat darin einen 4Byte Sekundenzähler. Neben Uhr hat er ebenfalls SRAM, 20Bytes davon, als Parameter RAM bekannt. Er wird mit 3 Pins angesteuert, von PB0..2 als RTC.DATA RTC.CLK und /RTC. Solange /RTC=0 ist kann mit den beiden ersten kommuniziert werden. Analog zu Tastatur Kommunikation vom Rechner aus angestossen, synchron seriell, aber Rechner taktet immer, Bit7 zuerst. Kommando von Rechner gefolgt von entweder Daten vom Rechner oder von der Uhr. Dazu hat er noch 1 Pin ONESEC zu CA2 um alle Sekunde einen Interrupt zu erzeugen. Dieses Signal sendet er immer, ob Interrupt wird in der VIA konfiguriert.

Software

AT

Es lief lange Zeit eine Geschichte herum, wonach DR Chef Garry Kildall lieber gutes Fliegerwetter ausnutzen wollte, statt die Delegation von IBM zu empfangen, mit Vorwurf von Inkompetenz oder gar Überheblichkeit. Diese ist falsch, ein damaliges Meme. Nach Aussage des IBM Vertreters an dem Besuch hatte er real schlicht eine Terminkollision, ein Besuch bei einem bestehenden Kunden und die Delegation von IBM. Ersteres brauchte aus technischen Gründen seine Anwesenheit, und er nutzte die Reise um Flugstunden aufzubauen. Mit IBM konnte auch seine Frau verhandeln, die waren ja nur ein weiterer Rechnerbauer unter vielen, und es war nur eine kommerzielle Verhandung, und sie machte eh die Buchhaltung.

Aber dann haben die IBMer als erstes einen dicken Non Disclosure Agreement (NDA) Vertrag auf den Tisch gelegt, evolviert aus ihren Jahrzehnten an Erfahrung mit Lecks abschrecken, aber entgegen aller Gewohnheit von DR mit ihren bisherigen PC Welt Kunden. Weshalb sie diesen Vertrag vor unterschreiben zuerst mit einem befreundeten Anwalt überprüfen wollte. Damit war die erste Verhandlung bereits an Verfahrenstechnischem gescheitert, wegen inkompatiblen Firmenkulturen ihrer Erwartungen. Dieser Anwalt fand fragliche Punkte und empfahl Nachbesserung. Aber IBM hatte keinerlei interne Verfahren um diese zu bereinigen, es war schlicht ihr normaler Vertrag, wie es alle Grossfirmen als Formalität behandelten und ohne nachzulesen unterschrieben. Wieder inkompatibel.

Mit dieser blockierten Situation neben sich fand der Besuch von selbigem IBM Vertreter bei Microsoft statt, um deren Basic zu bekommen. Er hat das Problem erwähnt und Bill Gates nutzte die Gelegenheit aus. Er wusste, dass Seatle Computer Producs (SCP) ein Opfer der Verzögerungen geworden war, welche beim Port von CP/M vom 8080/8085/Z80 zu 8086 aufgelaufen waren. Dies dank bei der Revision gleich alles besser machen, zuviel Featurismus einbauen, ein Fall von Second System Syndrome. Weshalb SCP kurzerhand als Notlösung ihren eigenen Port zusammengeworfen hatten namens 86-DOS. (Dieses wird oft als QDOS bezeichnet, angeblich Quick and Dirty OS bedeutend, aber auch das ist auch ein damaliges Meme.)

Also hat Gates dieses lizenziert, und an IBMs Spezifikation angepasst. Es sagt etwas aus zu den Verzögerungen bei DR, dass Microsoft ihren Flick von SCP ihrer Notlösung schneller bei IBM ablieferte als DR ihr seit langem laufendes Projekt, ihr Hauptprodukt auf 8086 nutzbar zu machen! Womit IBM ihre ganzen Utilities alle für MSDOS schrieb. Selbst unter diesen Umständen hat DR nichts kapiert, und als beide (plus UCSD P-System) im IBM Katalog als Optionen auftauchten war MSDOS neben besser supportet auch noch billiger, wohl weil Microsoft weniger Lizenzkosten pro Kopie wollte. (DR hat nach ausgebootet werden reagiert mit einem Concurrent CP/M Subset zu MSDOS kompatibel machen, und anfangs als GEMDOS verkaufen, nach dem Versagen von GEM bald in DRDOS umbenamst.)

So kam der PC zumeist mit MSDOS 1.0, von IBM in PCDOS umbenamst. Dieses verwendete das FAT12 Filesystem, das maximal etwas unter 4096 Sektoren zu 512Bytes verwalten kann, also bis 2MByte ausreichend ist. Genug für die damaligen 160k Floppys (und bis hinauf zu den späteren 1440k). Daher hatte es auch kein hierarchisches Filesystem, keine Subdirectories (wie CP/M auch). 1.1 addierte doppelseitige Laufwerke, aber erst mit 320kByte 8-Sektor Floppys.

Mit dem XT kam dann MSDOS 2.0. Dieses erweiterte FAT12 auf über 2M, mit 2^n der 512Byte Sektoren zu Cluster zusammenfassen, was etwas unter 4096 davon erlaubte. Was mit Clustergrösse von 8*512=4096Bytes selbst bis 16M hinauf erlaubte. Genug für die damaligen 10MByte Harddisks. Preis war aber, dass kleine Files in 4096er statt 512er Schritten Platz verbrauchen. Ebenso kam wegen trotzdem viele Files in diese Grösse passen erst die Subdirectories, die in 1.x noch fehlten (wegen Clone von CP/M sein, welches auch keine hatte). Es addierte ebenfalls Support für die 180/360kByte 9-Sektor Floppys (vermutlich FORMAT Optionen). Zudem kamen ladbare Treiber (wie ANSI.SYS). Des weiteren kamen wegen der längeren Subdirectory Filepfaden die Erweiterung von den alten FCB DOS Aufrufen zu den neuen unixoiden pfadbasierten DOS Aufrufen. Dazu noch pseudo-unixoider Support für Subprozesse (Hauptprozess eingefroren) und Pipes (Programme sequentiell laufend, mit Daten durch automatisch erzeugte und gelöschte Temporärdateien), sowie Terminate and Stay Resident (TSR) Programme. MSDOS wurde erwachsen, und mit 2.11 dann auch ausgereift.

Mit dem AT kam dann MSDOS 3.0. Dieses wurde wegen der schnell wachsenden Grösse von Harddisks mit FAT16 erweitert, das nun maximal etwas unter 65636 Sektoren zu 512Bytes verwalten kann, also 32MByte ohne Cluster, und somit wieder in nur 512er Schritten Platz verbrauchen. Es addierte ebenfalls Support für die 1200kByte Floppys. 3.1 addierte Netzwerksupport. 3.2 addierte 3 1/2" 720kByte Floppys. 3.3 addierte 3 1/2" 1440k Floppys, sowie Extended und Logical Partitionen, sowie Internationalisierung mit COUNTRY.SYS und Codepages. Es wurde von IBM erweitert, nicht Microsoft. 3.31 kombinierte FAT16 plus Clustern, für Harddisks mit einzelnen Partitionen über 32M. Es wurde von Compaq erweitert, nicht Microsoft. Damit wieder ausgereift.

Es gab für AT (und strikte auch bereits PC und XT) auch graphische Benutzerinterfaces, wie GEM und Windows. Aber diese sind praktisch nur Clones von der Mac GUI, oder eher ein billiger Abklatsch davon. Sie werden also dort mitbehandelt, soweit überhaupt relevant.

Ohne obige ist MSDOS ein reines Kommandozeilen System. Aber "dank" PC BIOS plus IBMBIO.SYS/IO.SYS mit nur einer dummen Fernschreiber Emulation als Bildschirmausgabe, trotz dass RS232 Terminals bereits seit Jahren mehr als das konnten. Für solches mehr kann ANSI.SYS aus CONFIG.SYS geladen werden, was teilweise VT100 Emulation addiert. (Strikte ist VT100 ein heftig erweitertes ANSI Terminal, dieses definiert alle Grundfunktionen, ANSI.SYS implementiert nur diese.) Es wurde aber um wenig RAM zu sparen (in MSDOS 3.3 ist es ganze 1647 Bytes) oft weggelassen. Also hat sich kein Program darauf verlassen, alles selber gemacht. Was wiederum alle Programme grösser machte, weiter gegen ANSI.SYS laden wirkte.

Dazu kommt die sehr primitive Kommandozeile von COMMAND.COM. Diesem fehlt ein brauchbarer Kommandozeileneditor. Er kennt kein editieren mit den eigentlich vorhandenen Pfeil Links/Rechts und Home/End und Backspace/Delete Tasten wie in einem Bildschirmeditor. Auch kann er keine bereits benutzten Kommandos holem, um sie weiter zu editieren, mit Pfeil Auf Taste, was als History bekannt ist. All das kam erst mit DOSKEY.COM in MSDOS 5.0, um 1990 herum. Das wurde oft benutzt, trotz 6012 Bytes.

Komplett fehlen dem COMMAND.COM effektive Features moderner guten Kommandozeilen, wie Dateinamen Completion. Dieses erlaubt Directory auszulisten inmitten eines Kommandos editieren. Dazu einmal auf die Tab Taste tippen holt Namen aller Dateien welche zum bereits teilweise getippten passen. Falls nur eines passt wird es gleich vervollständigt (und auch direkt ein Leerzeichen danach gesetzt, oder falls Directory ein \ angehängt). Falls mehrere passen und anfangs die selbigen Zeichen haben werden zumindest diese teilweise vervollständigt (mit dann kein Leerzeichen oder \, als Indikator von unvollständig). Nach zweites mal Tab tippen stellen sie den Cursor unter die Zeile, listen alle zum bereits vorhandenen Namensteil passenden Dateien aus, und dann erneut die editiert werdende Zeile mit Cursor am richtigen Ort. Dann kann man weitere identifizierende Zeichen tippen, bis man mit weiterem Tab den nun eindeutigen Rest vervollständigen kann.

Auch fehlt selbst mit ANSI.SYS geladen mit der Maus etwas passendes markieren und kopieren, egal ob von Programmen oder Completion ausgegeben, egal ob in Kommandozeile oder andere Programmausgaben kopieren. Noch besser wenn bei Doppelklick ganzer Dateiname markiert wird und dann bei einfügen obiger teilgetippte Name im Kommandozeileneditor ersetzt wird. Oder auch nur ohne ein Zeichen zu tippen mit zweimal Tab eine Liste alle Dateien auslisten und mit Maus eine kopieren. Dazu fehlt der Microsoft Maus ohnehin die zumeist für derart Ausgaben als Eingabe kopieren benutzte mittlere Maustaste.

Ebenso fehlt selbst mit ANSI.SYS geladen ein Scrollback von oben hinausgescrollten Zeilen mit Page Up/Down, um selbst ohne Maus weggescrolltes zu lesen. Oder gar um Teile davon mit der Maus zu holen. Erst recht fehlt reduzieren von hinausscrollen oder gar neuestes löschen, mit Bildschirmeditoren in einem Bildoverlay laufen lassen, damit nach deren Ende der vorhergehende Kommandozeilendialog wieder sichtbar werden kann. (Wobei dies wohl nur mit CGA oder HGC oder EGA/VGA laufen könnte, nicht auf MDA, wegen dazu mehr Videospeicher brauchen. Und auch diese bei Graphik nutzen wohl den ganzen Scrollback löschen würden.)

Mac

Dabei verwendete Apple das originale Macintosh File System (MFS). Dieses hat keine Subdirectories (wie MSDOS 1.x und CP/M auch). Daher lagen alle Fonts im einzigen Directory herum, trotz dass sie im Fontmanager wie in Subdirectories erscheinen. Erst der Mac Plus brachte ein verbessertes Hierarchical File System (HFS) mit Subdirectories, notwendig um den weit mehr Platz von Harddisks zu verwalten (wieder wie MSDOS 2.0). Ab dem Mac IIx mit High Density Laufwerk mit MFM konnte die PC Exchange Software auch FAT12 oder gar FAT16.

Aber all das ist uninteressant im Vergleich zu was den Mac zum Mac macht: Die erste weit verbreitete graphische Benutzerinterface (Graphical User Interface, GUI) mit Desktop, anstelle der damals überall sonst normalen Kommandozeile. Der Mac ist vor allem dafür bekannt, wurde damit vermerktet.

Dieses wurde damals aber oft abschätzig Windows Icons Menues and Pointer (WIMP, = Schwächling) genannt, und kontrastiert mit Command Line User Environment (CLUE, = Einsicht). Dieser Streit wurde mit dem Siegeszug der GUIs praktisch gegenstandslos. Der Begriff WIMP wird aber heute wieder aufgenommen, lange nachdem die damalige Kritik unterging (und von vielen vergessen ist?), nun als Unterscheidung von Mac/Windows-artigen Desktop GUIs zu Phone/Tablett GUIs. Ich benutze deswegen hier die Begriffe vom WIMP nun gezielt als Stichwortsammlung, um Elemente der Mac GUI in dieser Reihenfolge zu betrachten!

Windows (Fenster)

Aber trotzdem waren sie auf dem Mac falsch, weil sie hier zuwenig Platz hatten, auf dessen sehr kleinen 9" Bildschirmchen mit nur 512x342 Pixel. Selbst mit 6x12 Nadeldrucker Font hat dieser nur Platz für 85x28 Zeichen. Normale 80x25 (etwa eine halbe Druckseite) nehmen damit 480x300 Pixel auf, lassen gerade noch ordentliche 32 Breite und 42 Höhe für Userinterfaceelemente. Das ist genau passend für den anfangs angezielten elektronischen Schreibmaschinenersatz. Es ist aber total unausreichend für eine fensterbasierte Desktop GUI, weil dazu die Fenster unter 80x25 Zeichen fallen müssen. Schlimmstenfalls wenn schmaler können sie nicht mehr die ganze Textbreite zeigen (mit viel mühsamen hin und her scrollen), weniger schlimmenfalls wenn flacher zwingen sie auf nur sehr wenige Zeilen (und weniger problematischem Mangel an Übersicht).

Strikte is der Mac "Desktop" so klein, dass ich einen hypothetischen "Schreibtisch" mit einer Oberfläche von dieser "Grösse" auf der Beinhöhe eines normalen Schreibtisches als Barhocker bezeichnen würde! Wenn man einen realen Barhocker als Tisch missbraucht, wie wenn unterwegs etwas arbeiten oder nur jemandem schnell etwas zeigen, stapelt man Papiere darauf, statt sie wie auf einem Schreibtisch zu streuen, mit dabei mangels Fläche des Barhockers sie auf den Boden streuen. Dass moderne Smartphones und selbst grosse 14" Tabletts keine Fenster und Desktop mehr haben zeigt, wie inzwischen gelernt wurde. Die Mac Hardware ihr 9" entspricht eher einem 7" Tablett (CRT Monitor ist in Röhrengrösse angegeben, Bild darauf ist etwa 1.5..2" kleiner) und wäre besser mit einem Phone/Tablett-artigem umschaltbaren Vollbild benutzt gewesen. Womit dessen Fenster fast komplett nutzlos waren. Deren Rahmen waren nur Platzverbrauch. Und die Software ist mit den ganzen Tests auf Ausgabe im Zeichenbereich des Fensters bleibend (als Clipping bekannt) nur Prozessor verbratend und bremsend. Ein komplett unpassendes Design für diese Hardware.

(Im Vergleich dazu ist die Lisa grenzwertig. Ihre 720x364 sind deutlich mehr. Auf 12" Monitor sind es selbige 72dpi. Mit 6x12 Font wären dies 120x30 Zeichen. Horizontal gerade noch ausreichend, aber vertikal zuwenig. Wenn man dann auch merkt, dass diese Pixel fast genau 2:1 sind (und damit 4:2), aber der Bildschirm 4:3 Format ist, sollte man die 3/2 Pixelhöhe kompensieren mit 2/3 Pixel im Font, was 6x8 ergibt, und damit 120x45 Zeichen erlaubt. Das reicht in beiden Richtungen gerade noch als grenzwertiger minimalster Desktop. Hier ist eher der langsame 5MHz 68000 Prozessor das grosse Problem, der Rechner ist extrem träge.)

Der echte Wert einer GUI ist ohnehin Daten sichtbar machen, statt sie nur explizit auszulisten. Das zentrale Problem von Kommandozeilen ist Daten unsichtbar sein, der Benutzer arbeitet im Blindflug. Er muss dabei dauernd explizit einen kleinen Teil der Gegend "ausleuchten" mit etwas auslisten und dann sich an alles errinnern, gefolgt von nach jedem Edit sein mentales Bild anpassen, bis genug Zweifel an dessen Deckungsgleichheit erneut nach Gegend "ausleuchten" verlangen. (File Completion vereinfacht lediglich solches vorzu "ausleuchten".) Bestenfalls ist das nur eine mentale Last, aber schlimmstenfalls eine Fehlerquelle bis zu Daten vernichten, mit dieses möglicherweise nicht mal bemerken. Die GUI dagegen zeigt dauernd einen Ausschnitt in dem gearbeitet wird, und gibt sofortigen Feedback was neu ist oder nicht mehr ist. Dieser Schritt war bereits beim Wechsel von Zeileneditoren zu Bildschirmeditoren vollzogen worden. Der Finder lieferte dies nun nach, mit von Kommandozeilen zu Dateimanager. Das ist der reale Mac Vorteil von damals, nicht die unsinnigen zu kleinen Fenster. Es hätte auch Vollbild funktioniert, sogar besser.

(Selbigen Platzmangel trifft auch die PC/XT/AT Welt voll, egal ob mit GEM oder Windows. Selbst die EGA ihr 12" Monitor mit 640x350 1..4bpp aus 1..4*28=28..112k RAM reichen nicht wirklich für Fenster. Selbst mit 6x12 Font und 80x25 Zeichen in 480x300 reichen die 640x350 nicht weit. Sie sind immer noch unterhalb der bereits grenzwertigen Lisa 720x364. Und wegen Bitplanes ist die EGA auch noch langsam. Mit HGC 720x348 1bpp aus 32k RAM sind es fast Lisa. Zumindest die Breite ist ausreichend, aber genau die Höhe ist kleiner als die Lisa, ebenfalls grenzwertig. Und es hat noch schlimmere nichtquadratische Pixel als Lisa, wird auch 6x8 brauchen, was 120x43 Zeichen erlaubt. Komplett unbenutzbar wird es auf CGA 12" mit nur 640x200 1bpp aus 16k RAM. Nur noch 200 Zeilen machen die Höhe komplett untauglich. Selbst mit 6x8 Font sind 80x25 nun 480x200, erst mit fast unlesbarem 6x6 Font wären es 480x150. Noch schlimmer wird es auf 8bit 8088er PC oder XT, mit zusätzlich noch weit zu langsam und zuwenig Speicher, weshalb GEM und Windows mit 8088 Real Mode belasten statt mindestens 286 Protected Mode verlangen kompletter Unsinn war.)

Erst die 32bit Generation lieferte genug für brauchbare Desktop GUIs. Prozessor (über 10MHz) und Speicher (ab 1MByte) und Bandbreite (ab 10MByte/s) und Video (ab 800x600) und Monitor (ab 17"). Insbesondere hatten diese erst ausreichend Auflösung für Fenster, mehr als 640x480 für mehr als 80x30 Zeichen selbst wenn 8x16 Pixel 100dpi Font, plus GUI Elemente, plus Fensterrahmen, mit noch genug von anderen Fenstern sehen, dass diese sich überhaupt lohnen. Dies mit trotzdem genug Farben für Graphik, also ab 8bpp in 512kByte, oder zumindest in schwarzweiss, ab 2bpp in 128kByte Bildspeicher.

Desktops wurden somit real brauchbar ab SVGA 800x600, und erst echt gut ab XGA 1024x768 8bpp aus 3/4MByte oder gar SXGA 1152x864 8bpp aus 1MByte. Also 486er PC mit 17" bis 21". Sowie 68030 Mac IIcx mit Portrait Video Card 640x870 2oder4bpp aus 256oder512k RAM auf 15" Portrait Display oder gar Two-Page Monochrome Video Card mit 1152x870 2oder4bpp aus 512oder1024k RAM auf 21" Two-Page Monochrome Display. Alle ab um 1990, und somit erst 2 Chipgenerationen nach der Mac Einführung! Auch hatten 32bit dank diesen mit 2bpp (oder gar mehr) ansprechender aussehende GUI Elemente, sowie selektierter Text Grau hinterlegt statt invers, angefangen mit dem ebenfalls 68030 basierten 1120x832 2bpp aus 256k auf 17" NeXT Rechner (1988).

Man kann nun kritisieren, dass die Leute dies damals nicht wissen konnten, mangels unsere (Er-)Kenntnisse. Nur wäre es erst noch für sie komplett vorhersehbar gewesen! Zumal der Xerox Alto in 1972 das Ziel hatte, als maximalen Forschungsrechner einem durchschnittlichen Bürorechner von +10 Jahre in die Zukunft (= 1982) zu entsprechen, um Erkenntnisse für diese erstellen und nutzen zu gewinnen. Er war dazu massiv dimensioniert, mit 606x808 1bpp Bitmap aus 61kByte(!) Bildspeicher aus dem 64kWort/128kByte Hauptspeicher, auf einem beinahe-A4 14" Monitor in Portrait Anordnung. Dies passend zum US Letter Format (8.5x11"), welches mit 6x12 Font und 72dpi Matrix 612x792 Bitmap entspricht. All das in 1972, Kosten etwa $25'000 (Inflationskorrektur etwa *7, zu heutige $175'000!).

Der Alto musste dazu während Zeilen ausgeben 100% der Speicherbandbreite nutzen, mit Prozessor ganze Zeit anhalten. Das trotz mit Pagemode Doppelzugriffe arbeiten. Dabei wird die erste Adresshälfte einmal mit /RAS angeliefert gefolgt von zwischen Adresshälften schalten, dann zweimal hinter einander die zweite Adresshälfte anliefern mit /CAS gefolgt von Daten auslesen. Damit kann man dopplte Datenmenge in nur 1.5 mal Zeit holen, oder gar in gleicher Zeit mit nur Faktor 1.5 statt 2 schnelleren RAMs. Bedingung ist nur, dass die erste Adresshälfte konstant bleibt, was aber bei 2 Worte einer Videozeile direkt hinter einander im Speicher liegen trivial gegeben ist, mit nur unterstes Adressbit als Teil von der zweiten Adresshälfte nehmen.

Der Alto hatte trotz alledem keinerlei Desktop, Programme liefen auf dem ganzen Bildschirm, wie bei heutigen Phone/Tablett GUIs, etwa einem 12" Tablett entsprechend. Dies stand erst noch hochkannt, wie Phones zumeist und Tabletts oft gehalten werden. Die Alto "GUI" bestand somit lediglich aus Daten in Bitmapgraphik rendern und dem Prinzip von Sichtbarkeit, wieder mehr wie Phone/Tablett GUI. Dessen Nachfolger Dorado (1978/79) brachte vervielfachte Prozessorleistung (mit Cache) und MBytes Hauptspeicher (mit PMMU) und massive Bandbreite (mit 256bit(!) breitem RAM), sowie einen grösseren Landscape Monitor mit 4bpp. Selbst dessen Billigversion Dandelion bzw Xerox 8010 (1981) konnte 1024x808 mit nur 1bpp aus 103k RAM auf beinahe-A3 17" Monitor. Auf letzterem lief die Star GUI mit Fenster und Desktop. Kosten in 1981 $17'000 (Inflationskorrektur etwa *4).

Xerox 8010 ist was Steve Jobs und eine Gruppe Apple Designer bei einer Demo in 1979 sahen. Gefolgt von die Lisa entwickeln, mit weit geringerer Technologie, nur noch 720x364 aus 32k auf 12" Monitor, halbe Alto, viertel 8010, absolut grenzwertig. Kosten in 1983 $10'000 (Inflationskorrektur etwa *3). Gefolgt von Steve Jobs wegen dies zu teuer den Mac zur Mini-Lisa machen, trotz nur 512x342 aus 22k auf 9" Monitor, drittel Alto, fünftel 8010, und damit komplett unpassend. Bonuspunkte beim Mac für dazu noch anfangs 128k statt 512k RAM haben, trotz genau die 64kWort/128kByte sich bereits früh als die schlimmste Schwäche des Alto erwiesen zu haben. Das erkennen war der Haupgrund um ab 1975 den Dorado zu entwickeln. Das alles war noch bevor Apple überhaupt als Firma entstand in 1976!

(Die in 1984 mit Prozessor/Video Speicherinterleave machbaren 32k würden strikte auf einem Alto-artigen Portrait Monitor bei 70Hz 480x540 erlauben so 80x45 Zeichen in 6x12 Font. Mit Mac-artigen 60Hz wären sogar 480x660 und 80x55 Zeichen in 38.6k gerade noch machbar, eine Seite an Daten. Ausser man geht mit Pagemode Doppelzugriffe auf in 1984 schnellste RAMs los, dann wäre selbst mit 70Hz 620x820 in 64k machbar und etwa ein Alto zu erwarten. (Ex Mac Designer, inklusive Hardware Designer Burrell Smith, haben in der Firma Radius den Mac Plus und 512Ke mit einem derartigen Alto-artigen Monitor aufgerüstet, mit 15" und sogar 640x864 Pixel, mit beide Monitore gleichzeitig laufend.))

Womit Xerox mit dem Alto (1972) die angezielten +10 Jahre ziemlich genau getroffen hat! Genauer haben sie Prozessorleistung und Adressbereich etwas zu tief und Bandbreite und Bitmap etwas zu hoch getroffen. Der Mac Desktop wurde erst mit dem 68020 Mac II (1987) wirklich brauchbar, und mit dem 68030 plus kompakten IIcx (1989) ausgereift. Womit Xerox mit dem Dorado (1978) ebenfalls ziemlich genau getroffen hat. Generell hat Xerox PARC gute Arbeit geleistet. Wenn auch die Firma Xerox bei diese zu kommerzialisieren und vermarkten komplett verfehlt hat. (Die davon frustriert ausgewanderten Leute landeten übrigens oft bei Apple oder Microsoft. Oder sie gründeren Startups wie 3Com und Adobe. PARC hat neben GUI Rechner auch Ethernet und Laserdrucker erfunden.)

Alle Desktops auf 1980er Rechner, mit zumeist sogar nur etwa A5 Monitore, waren damit weit verfrüht, weil solche für damalige Bildschirme zu viel waren. Woraus folgt, dass 16bit und Desktop einfach nicht zusammenpassen! Der Mac derart grob vorzeitig danebenliegen ist weshalb der AT (und selbst XT) so dominant bleiben konnte, trotz PCs damals teurer sein (AT sogar weit so) und mit dem sehr simplen MSDOS daherkommen. Dieses zwar ohne GUI und Desktop, aber auch ohne dessen Last. Dazu kommt eine Auswahl von nur Kommandozeile mehrere (wie COMMAND.COM oder 4DOS, ersterer primitiv, letzterer mit Completion und History), oder zeichenbasierten Dateimanagern mehrere (wie Norton Commander oder PC Shell oder Xtree, ersterer kombiniert sogar Dateimanager und Kommandozeile in einem), oder falls man trotzdem graphischen Desktop wollte ebenfalls mehrere (GEM oder Windows, und für letzteren auch Ersatz Dateimanager (wie Norton Desktop for Windows oder Windows/Total Commander)).

Icons

Die heutige Erfahrung zeigt, dass Icons nur für App Auswahl und Toolboxen sinnvoll sind, da diese mit einer kleinen sortierten Menge an verschiedenen Formen gut erkennbar sind, um auf sie zu zielen. Aber dies gilt nicht mehr bei Dateien, weil solche ohnehin alle gleiches oder nur ein typspezifisches Icon bekommen, und deshalb ohnehin Dateinamen brauchen. Icons wären dort erst sinnvoll, wenn mit auto-Thumbnails generieren benutzt, aber sowas fehlte in Lisa und Mac.

Daher hat der Mac im Finder sehr bald den Listenmodus addiert, wie PC Filemanager ihn ohnehin stets hatten. Darin hat es nur noch Mini-Icons am Anfang der Zeile, statt den in MFS und HFS fehlenden Dateiendungen. (Leider wurde letzteres schlecht auf Windows kopiert, nicht nur mit helfend Mini-Icons addieren, sondern auch mit hindernd die Dateiendungen verstecken.)

Dazu kommt der begrenzt nutzbare Abfalleimer, nur für Dateien löschen, aber nicht für normale Daten beim editieren! Dies trotz dass Benutzer viel lünger an Daten editieren, inklusive dabei öfter Teile davon löschen. Aber dafür ist das Edit Menu notwendig, während Dateien diese separate extra Methode bekommen. Das vermutlich wegen ganze Dateien vom Finder her nicht aus einem Ordner in die Zwischenablage kommen können! Dies weil die Mac Editier-GUI auf Cut/Ausschneiden oder Copy/Kopieren in Zwischenablage allenfalls gefolgt von Paste/Einfügen basiert, statt auf kombiniertes Move/Bewegen oder Copy/Kopieren oder Löschen, was die Dateioperationen kennzeichnet.

(Kombiniert würde bei Text und Dateien in Operationen parallel laufen resultieren und damit konsistenter und besser sein. Es würde auch zusammen mit kopierbare Auswahl ungleich aktueller Arbeitsposition die Verlustprobleme reduzieren, welche entstehen bei etwas markieren und dann nach wegscrollen, gefolgt von wegen nicht mehr sichtbar sein die Markierung vergessen und anfangen zu tippen, womit das markiert verbleibende gelöscht wird! Weiter würde es auch Verlustprobleme reduzieren, welche entstehen zwischen Cut/Ausschneiden und Paste/Einfügen nur noch unsichtbare und vergessbare Daten in der Zwischenablage. Mit beidem wird das GUI Prinzip von Daten sehen und wissen unterlaufen, nur noch mentales Bild wirkt, wie bei einer Kommandozeile! (Der originale Mac Designer Jeff Raskin erachtet übrigens den von Xerox kommenden Mac Ansatz als Fehldesign, er zieht die kombinierte Variante vor. Leider hat die Restwelt kritiklos den Mac kopiert, sich auf 1970er User Interface Design fixiert und seither keinen Fortschritt mehr gemacht!))

(Der Abfalleimer ist ironischerweise das einziges GUI Patent von Apple, welches den Anti-Windows Prozess gegen Microsoft überlebte, gefolgt von Windows dieses eine (Miss-)Feature fallenlassen. Und selbst das scheint nur das Bild selber zu betreffen, nicht die Methodik, NeXT sein anfängliches Schwarzes Loch und späteres Recyclingsymbol sind scheints OK.)

Weiter war der graphische Dateimanager vom Finder ohne Harddisk sehr langsam. Immer wieder den Floppy Zustand anzeigen braucht viel warten. Was alles mit seinen Icons zum Spitznamen "Mickey Mouse Rechner" führte, sowie zusammen mit seiner Flut von Dialogboxen zum Spitznamen "Meckertopf". Anzeigen sollte folglich wegen Wartezeiten verhindern eher bei Bedarf auf Knopfdruck explizit geschehen, siehe obiges Filename Completion.

(Selbst Dateimanager setzten sich auf PCs erst mit Harddisk durch, davor nur temporär geladen bei komplexen Dateioperationen wo eh oft aktuellen Directoryzustand auslisten geschehen wird. GUIs kamen auf PCs sowieso erst mit 32bit auf, mit stets Harddisk und dessen kurzen Zugriffszeiten. Selbst dann war Windows 3.x ordentlich brauchbar aber OS/2 bereits zuviel, dann kam Windows 95 auf inzwischen schneller Hardware. (Auch hatte der Alto bereits eine 2.45MByte Wechselplatten Harddisk.))

Menüs

Aber dem Mac seine Menüleiste ist ineffizient dauernd sichtbar, verschwenden den ohnehin kleinen Bildschirmplatz. Dazu kommt, dass sie mit oben am Bild entlang stehen die weiteste Mausbewegungsdistanz erzeugt. Es wäre besser mit Popup Menues, welche nach Maustaste drücken direkt dort erscheinen wo ohnehin der Mauscursor ist. Nur fehlt dem Mac dafür die zweite Maustaste.

Selbiges trifft auch die Scrollbars. Sie zeigten auf dem Mac anfangs nicht mal die Länge von dargestellten Ausschnitt vom ganzen Text, nur dessen Position. Auch hier wäre besser als Popup Band, oder gar ein breiteres mit auto-Thumbnails vom Text seinen Seiten.

Pointer (Zeiger)

Aber leider hat die Mac Maus nur 1 Knopf, trotz Benutzer mehrere Finger haben und auch Xerox bereits beim Alto drei verwendet haben. Damit kann der Mac keine zweite Maustaste für Popup Kontextmenues oder Scrollbars nutzen. Erst recht hat er keine dritte für direktes Copy/Kopieren und Paste/Einfügen, ohne mehrmals ins Menu zu gehen. Wieder einmal bewusst so gemacht, wegen sonst "unerfahrene Benutzer abschrecken". Auch hier leidet der Mac unter schnell anfangen mit wenig zu lernen, aber danach auf Zeit hinaus immer ineffizient bleiben.

Schlussbetrachtung

Der AT baut direkt auf den PC und XT auf, und ist damit kompetent gebaut, aber sehr konservativ. Er ersetzt die 8088 mit 80286, gefolgt von breiterem Bus. Speicher ist gleich gross wie XT. Floppy ist erweitert auf 1200k. Harddisk ist flexibler. Video anfangs selbige MDA und CGA, welche beide grenzwertig mangelhaft sind. Kurz danach kam EGA, aber die lief auch in XT, wenn auch sie von der 80286 profitierte. VGA lieferte dies kompakter und 16bit, aber das war erst in PS/2. Hoch gelobt wurden die Tastaturen, ganz zurecht. Der Rest ist Durchschnitt. Software ist MSDOS, absolut minimal, aber offen für Verbesserungen und Erweiterungen. Das was wir seither alle kennen und lieben oder hassen.

Der Mac war anfangs als elektronischen Schreibmaschinenersatz gedacht, wurde aber zur Mini-Lisa ausgebaut, und kam als ersten GUI Rechner in den Massenmarkt. Er ist wegen ersterem minimalistisch aber deswegen für zweiteres schlicht unterdimensioniert. Anfangs war er schlicht unbenutzbar wegen unzureichenden 128k Speicher, zumindest bis der Mac 512K kam. Aber vor allem hat Video zuwenige Pixel um das MacOS Desktop GUI Prinzip durchzuziehen, selbst noch mit dem RAM und der HD von Mac Plus und SE. Er wäre mit Vollbild GUI besser gelaufen, selbst mit Radius Video und Monitor in einem Mac Plus. Aber auch das bringt keine fehlenden Farben. Diese lieferte der Apple IIGS, mit sogar 32k Video RAM, aber auch mit unpassende Fenster. Der Mac bringt ebenfalls als erster die Maus in den Massenmarkt, aber nur mit einer Taste. (Was Apple IIe schon fakultativ erlaubte.) Kann keine Harddisk, zumindest vor Mac Plus. (Was Apple III schon hatte.)

Aber diese Limitationen dauerten nicht lange. Beide evolvierten noch in den 1980ern und bleiben dabei bis heute. Der AT bekam bald wie PC und XT seine Clones, welche den horrenden Preis reduzierten, und bald auch besseres Video lieferten, nach HGC und C+ vor allem Super-EGA und SVGA. Der Mac bekam den Mac II, der endlich besseres Video lieferte, aber zu ebenso horrenden Preis wie ein originaler AT. Erst Mac IIcx lieferte wirklich genug Bildschirm, ebenso PC Clones mit SVGA. Beide schafften es bis heute weiter durchzuziehen.

An Herausforderern hatten sie nur zwei: Atari ST und Commodore Amiga. Beides davon anfangs hervorragende Rechner und billiger (ST sogar erheblich so) und leistungsfähiger (Amiga sogar erheblich so). Aber beide diese blieben dann jahrelang stehen, wurden von AT und Mac eingeholt und überholt, ST brauchte bis TT in 1990 und Amiga sogar bis AGA in 1992 um nur mit PS/2 VGA und Mac II von 1987 voll gleichzuziehen! Weshalb diese Rechner und die Firmen dahinter untergingen. Deshalb haben wir heute alle, wenn wir Desktop oder Laptop benutzen, entweder einen AT kompatiblen PC oder einen Mac vor uns. (Für was diese beiden einst konnten und was mit ihnen genau geschau, siehe den Teil 2 vom Vortrag im nächsten Jahr.)

Diese Seite ist von Neil Franklin, letzte Änderung 2024.09.17