Eine PS/2-Tastatur für den Neunundneunziger

	Eigentlich sollte es ein USB-Keyboard werden... aber dann kam wieder alles anders. Der Analysator für USB-Keycodes compilierte und lief noch einwandfrei aus der Arduino IDE, aber nach einem Update der Libs war es Essig damit - keine brauchbare Fehlermeldung, nur einfach sinnfreie Rückmeldungen der Transportschicht. Der ESP32-WROOM emulierte das USB-Hostprotokoll für eine Tastatur ohne Probleme, aber bis zur Simulation des TI-Keyboards war noch ein langer Weg... na dann wird es eben die PS/2-Variante - da ist das Protokoll relativ einfach "händisch" umzusetzen. Es gibt ja kritische Stimmen, die das USB-Protokoll als "overengineered" ansehen... muss man nicht auch so sehen (kann man aber).
	Nostalgie
	Im Prinzip muss es dieses Teil dann auch in einer PS/2-Variante geben, daher erst mal das Bild der USB-Fassung mit angeschlossenem Keyboard. Ein wenig schmerzt das schon, aber wer mal auf der PS/2-Tastatur geklimpert hat, wird wohl so schnell mit keiner USB-Tastatur mehr fremdeln... Und meine ist NOS, New Old Stock - eine absolut unbenutzte AT-Version in Originalverpackung - ein Träumchen in Sachen Haptik für nur EUR 65,-!
	Adapter
	Adapter gibt es diverse, aber welchen nehmen? Der Linke ist die Komfort-Variante mit Parallel-I/O, UART und SPI (ob er auch senden kann? Die Doku schweigt dazu.) sowie angeblich auch IIC - Mal sehen, vielleicht ist das die beste Variante zur Keycode-Analyse, aber das Protokoll ist hier komplett hinter dem Käfer versteckt. Der in der Mitte ist an sich nicht mehr als eine Buchse mit Stiftleiste - mehr die Sorte aus der "Makerbox", wo man sich seinen Prototyp per Breadboard zusammensteckt. Hey - warum auch nicht?! Und rechts, naja - seht selbst. Alles sogenannte "Pfennig-Artikel" aus dem Reich der - nee, nicht Mitte, das wäre Israel - naja, egal, eben da, wo die heutigen 40 Räuber zu finden sind. Naja, am Ende hängt die Wahl des Adapters davon ab, welche Software zum Einsatz kommt.
	Was sagen denn die anderen?
	Solch ein Projekt ist nicht neu - so schön das TI-Keyboard auch ist - für Vielschreiber ist es eher ungeeignet. Daher findet man, so man denn sucht, beim netten Inder viele Umsetzungen, die überwiegend auch im Quellcode und mit Beschreibung der entsprechenden Hardware vorliegen. Aber wehe man geht in die Details... Dieses kann nur das Typ I Protokoll, jenes kann nur empfangen, aber nicht die LEDs steuern, das hier läuft nur auf einem (überteuerten) Teensy V3, den es nicht mehr gibt, die Software läuft aber nicht auf V4 und Nachfolger, und noch eins macht nur Umsetzung von PS/2 auf USB (echt jetzt? Dafür gibt es doch die netten Adapter...), und auf die TI-Matrix adaptieren auch nicht viele. Und wer es ganz historisch haben will, schaut sich das Rave Keyboard an, das es schon 1988 erlaubte, ein PS/2 Keyboard anstelle der normalen Tastatur zu benutzen. Der Aufwand rund um den kleinen 24-beinigen Mikroprozessor ist schon respektabel.
	Die Klassifikation
	Ist das eigentlich ein Hardware- oder ein Software-Projekt? Die Hardware besteht ja lediglich aus dem Keyboard (fertig gekauft) und einem Anschluss für den PS/2-Stecker (fertig gekauft), dem Micro der die Umsetzung macht, und der Adaption an den Tastaturanschluss der Konsole. Daher mache ich das so: hier in der Hardware-Ecke betrachte ich die reine Umsetzung in den 3 funktionalen Blöcken E-V-A (Eingabe-Verarbeitung-Ausgabe), Details zum Code kommen dann in der Rubrik "Software Projekte" - OK?
	Kommen wir nun zu etwas völlig anderem: Software-Engineering
	1. Requirements
	Zunächst die essentiellen Requirements: Das Keyboard ist eines, das den PS/2 Befehlssatz 2 verwendet, also muss die zu verwendende Lib das beherrschen. Keyboards mit Befehlssatz 1 werden nicht unterstützt. Die LEDs des Keyboards müssen den realen Stand von 'CapsLock', 'NumLock', 'ScrollLock' wiedergeben. Die Softwarelösung muss bzgl. der Spezialtasten (Umlaute, Klammern, ...) einfach konfigurierbar sein Es müssen alle TI-spezifischen Tastencodes erzeugt und übertragen werden können. Bestehende Umsetzungen sollen analysiert und ggf, übernommen werden. Eine Lösung für die 'Alpha Lock' Taste muss erarbeitet werden, zunächst ist keine Umsetzung geplant. Die elektrische Adaption an den TI muss ohne Hardwaremodifikation erfolgen (abgesehen von der u.g. Hardwareoption). Ein Parallelbetrieb der PS/2 Tastatur zusammen mit dem TI-Keyboard ist nicht vorgesehen. Es muss der kleinstmögliche Micro eingesetzt werden Nun die optionalen Requirements, die beim Design aber beachtet werden sollten: Die LEDs sollten optional bei jedem Einschalten in den beim Ausschalten aktiven Zustand versetzt werden. Eine Live-Autoadaption mittels spezieller Tasten(-kombinationen) mit persistenter Speicherung muss optional vorgesehen werden. Diese Autoadaption (und ggf. anderes Feedback) muss dem Benutzer akustisch rückgemeldet werden. Als Option sollten Hardwaresignale an den TI möglich sein, z.B. RESET, LOAD o.ä. Es ist die Option vorzuhalten, daß der Micro die Spannungsversorgung des Keyboards steuert.
	2. Aktueller Stand der Dinge, oder: DER GLITCH!
	Das PS/2-Protokoll ist definiert und dokumentiert, da gibt es nichts zu untersuchen, lediglich die aus der Tatsache, daß die Tastatur Clock-Master ist, resultierende Anforderung an die Antwortzeit des Micros ist relevant, aber in der Regel reicht ein mit 16 MHz laufender ATMega328 aus, um schnell genug zu reagieren. Das ist aber nicht der Punkt: die Clock-Frequenz liegt irgendwo zwischen 10 und 17 kHz, entsprechend einer Periodendauer von ca. 60 bis 100 Mikrosekunden. In dieser Zeit wird 1 Bit übertragen, insgesamt sind es pro Byte jeweils 12 Bit, also zwischen 720 und 1200 Mikrosekunden. Wie wir unten sehen werden, sind das fast exakt die 1,17 Millisekunden, die der TI zwischen 2 Abfragen braucht, wenn der Monitor läuft (Titelbild) und keine Taste gedrückt ist. Kniffliger ist in jedem Fall der TI, wie sich nach einigen Messungen herausstellte, nachdem ich im ersten Ansatz plante, die Ausgänge des 74LS156 als Interruptquellen eines Arduino Every zu verwenden, und dazu das Oszilloskop an die Tastatur-Stiftleiste anschloss... AU WEIA! Aber der Reihe nach - erst mal herausfinden, welches Timing wir da haben, denn die an sich sehr guten Sams Computerfacts existieren im Netz nur in absolut unbrauchbaren Auflösungen, wodurch man die Oszillogramme nicht lesen kann... Bild 1: Man schließe ein paar Kanäle an die Strobe-Signale vom Decoder 74LS156 und schaue nach. Und da ist er auch schon - der Glitch. Mist, wenn ich hier Interrupts zulasse, dann ist der Micro immer auf dem Holzweg... also mal genauer reingezoomt... schließlich soll ja erstmal das generelle Timing analysiert werden. Bild 2: Der Glitch ist systembedingt, da die CRU schließlich eine serielle Schnittstelle ist, und die Bits nacheinander einlaufen - Abhilfe ist ohne größeren Aufwand nicht möglich. Leben wir halt damit... wobei uns genau diese Eigenart der CRU ein klein wenig hilft: das Programm macht erst dann weiter, wenn der Befehl abgearbeitet ist, die Bits also stabil sind. Interessant mag sein, daß zwischen den Bits mehr oder weniger exakt 660ns vergehen - 2 Clocks pro Bit, denn erst muss die Adresse auf den Bus, zusammen mit CRUOUT, und dann noch ein Clock-Impuls. Bild 3: Man sieht (Die Traces bilden A, B und C von oben nach unten ab), daß von 5 bis 0 gezählt wird (6 und 7 fragen die Joysticks ab), daß aber zwischen den Abfrageblöcken selbstredend eine 0 verbleibt, d.h. eine Scan-Spalte ist immer aktiv! Und wenn man sich anstrengt, kann man 6 Kästchen zählen, entsprechend 1,2ms Periodendauer der Abfragen, wenn nur das Titelbild angezeigt wird. Interessanterweise ist das 2Y0, von dem man normalerweise annehmen würde, daß es NACH System 1 kommt - tut es aber nicht! Bild 4: Wahrheitstabelle aus dem Datenblatt, mit exakt demselben use-case, mit dem wir es hier zu tun haben. Bild 5: Man sieht die Dauer der Abfrage, wobei ich im TI-99/4A Intern mal nachsehen muss, wo und wie da gesampelt wird - eine Low-Phase von etwa 66 Mikrosekunden ist zwar lang (und wird länger, wenn Tasten erkannt werden, aber das spielt weniger eine Rolle - das zu entwickelnde System muss mit den Minimal-Timings klarkommen), aber wo wird gesampelt? Bild 6: Ein Blick in den Quellcode ergibt, daß etwa 32 Ticks (ca. 10 Mikrosekunden) nach Setzen der Strobes der Pegel eingelesen wird. (Sorry wegen der schlechten Masse auf Kanal 2...)
	3. Das 2Y0-Problem, oder: Danke Herr M.
	Eine etwas genauere Analyse der Oszillogramme, des Schaltplans sowie der KEYSCAN-Routine des Monitors zeigt zweierlei: Es wird von 5 bis 0 gezählt, also wird Strobe 0 zuletzt gelesen. Da es kein Enable für den Decoder gibt, bleibt 2Y0 eben low, bis wieder was gelesen werden soll. Damit "qualifiziert" sich 2Y0 (theoretisch) zum Interrupt-Trigger, bei dessen steigender Flanke die Software in den "Obacht"-Modus gehen muss, also schnell abfragen und antworten, und bei dessen fallender Flanke der Wert der Spalte mit den Tasten 'Fctn', 'Ctrl', 'Shift', 'Enter', 'Space' und '=' ausgegeben werden muss - und zwar nur 1 Mal, dann aber mit Busy-Waiting für mindestens 10-20 Mikrosekunden. Aber warum die Referenz auf Herrn Martin? Wer mich kennt weiß, daß mein Verhältnis zu ihm immer etwas ambivalent war. Und so auch hier: Man ist dankbar für TI 99/4A Intern (wenn auch mit Schreibfehler), aber wenn man dort genauer hineinsieht, stellt man schnell fest: der überwiegende Teil der ROM-Listings besteht aus der 1:1 Vertonung der Assembler-Syntax - Semantik? Viel zu oft Fehlanzeige, so auch bei der Keyscan-Routine. Naja, egal - da gibt's von mir irgendwann was besseres...
	HALT - und was ist mit dem Joystick?
	Dazu muss das System in den Zustand gebracht werden, den Joystick abzufragen, vielleicht durch ein kleines BASIC Programm... Das wird wohl in einem separaten oder verlängerten 2Y0-Zyklus resultieren. Da aber jetzt schon klar ist, daß die Strobe-Leitungen die Zieladressen vorgeben, ist das wohl nicht mehr als eine Fingerübung. Der Messaufbau kann bleiben - die Messung kommt später...
	4. Die Konsequenz: proof of concept - Rel. 0.2
	Fassen wir zusammen: Es gibt 6 abgetastete Eingangsleitungen, nämlich die 6 Strobes, die am Keyboard-Connector anliegen. Die Alpha Lock Taste (P5 zu I7) wird nicht galvanisch konnektiert. Um Eingangsports zu sparen, wird ein 8-zu-3 Prioritäts-Encoder 74LS148 genutzt, um nur 3 Bit abfragen zu müssen - im Grunde genommen macht der die Arbeit des Encoders zunichte, an den man aber ohne Umbau des Mainboards nicht herankommt. Es gibt 8 Ausgangsleitungen zu den entsprechenden Ports des TMS9901, welche die Tastendrücke durch LOW-Pegel simulieren. Open-Collector Ausgänge sind nicht nötig, da bei diesem Konzept keine 2 Tasten auf verschiedenen Strobes zum gleichen Zeitpunkt konnektieren. 2Y0 wird nicht mehr betrachtet, denn durch den Encoder muss einfach nur die Spaltennummer gelesen und flugs das richtige Byte ausgegeben werden - der Glitch spielt dann keine Rolle mehr, zumindest solange die Ausgabe der Zeilenbits schnell genug erfolgt. Zwischen dem Wechsel der Spaltennummer und dem Setzen der passenden Ausgangsleitungen dürfen maximal 10 Mikrosekunden vergehen. Aus dem vorigen Satz ergibt sich, daß die Verarbeitungszeit der Ausgabe plus der maximalen Interrupt-Laufzeit nicht über 10 Mikrosekunden liegen darf. Es muss also ein Prototyp gebaut werden, der PS/2 Daten mittels der gewählten Bibliothek liest, die Eingänge scannt und das zugeordnete Bitmuster ausgibt. Das wird vielleicht zu eng für einen ATMega328... mal sehen (der Nano V3 hat sich ja beim RAM-Test durchaus als flottes Teil erwiesen) - aber es gibt ja Alternativen. Stay tuned, denn sobald das geklärt ist, geht es in der Rubrik "Software" weiter!