Beiträge von Wiesel im Thema „PS2-Tastatur am C64“

    Ich hatte 2017 mal die Idee verfolgt - aber noch ein paar Verfeinerungen gemacht, nämlich gemessen was die Originaltastatur an Widerstand hat, mit dem Datenblatt des HC4066 abgeglichen und einen Vorwiderstand für jede einzelne Taste entsprechend errechnet. Den Prototypen habe ich dann geroutet und produzieren lassen, aber nie in Betrieb genommen:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Da mich mein 8051-Entwicklungssystem in den letzten Wochen echt geärgert hat, habe ich ein Neues aufgesetzt - ohne USB->seriell Wandler, sondern mit nem schönen alten Mainboard, das zwei echte COM-Ports hat. Das nur als Nebenschauplatz; da ich vergangenes Wochenende mit einem guten Freund darüber diskutiert habe, wie unmöglich es ist, jeden noch-so-kaputten software-scanner in einer rein digitalen/softwaremäßigen Lösung zu bedienen (prinzipiell also die hier vorangehende Diskussion "reloaded"), habe ich den Prototypen von 2017 wieder herausgekramt und ihn in Betrieb genommen. Erstmal ohne PS2-Code, sondern nur um zu prüfen, ob meine Schaltungsidee zur Weitergabe von left-shift und shift-lock auch funktioniert. Und das tut sie: Ich kann "linke shift" und "shift lock" mit dem Microcontroller getrennt übertragen, und die einschlägigen Testroutinen für diesen Spezialfall zeigen absolut zuverlässig entweder nur linke Shift, oder sowohl linke Shift, als auch Shift lock.

    Ich hatte noch einen C64, bei dem die shift-lock Erkennung nicht sauber funktionierte - da flimmert das shift-lock Bit nur, wenn man an der shiftlock-Taste wackelt. Den Rechner fand ich besonders interessant, denn ich hatte befürchtet, dass da eine besonders obskure CIA drin ist, die evtl. andere Schaltschwellen hat. Entwarnung: Es liegt bei diesem Computer nicht an der CIA, sondern an der Shift-lock Taste selbst. Diese Taste ist alt, kratzt vermutlich ein wenig und hat einen recht hohen ohmschen Widerstand, deswegen funktioniert die Shift-lock-Erkennung da nicht zuverlässig. Mit meinem Prototypen kann ich auch mit dem Computer zuverlässig die linke Shift und shift-lock übertragen.

    Wenn also "irgendwo im Internet" steht, dass die Erkennung von Shift-lock nicht zuverlässig ist, dann ist das möglicherweise die gleiche Ursache wie bei meinem Computer: Eine alte/verschlissene Shift-lock Taste.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Auf dem Bild seht Ihr, dass ich noch einen Anschluss für die C64-Tastatur unter die Platine gelötet habe - sonst kann ich das Testprogramm nicht laden. Der Anschluss über Kabel ist auch nicht gerade der Weisheit letzter Schluss. Ich kann aber sagen, dass ich ein proof-of-concept habe, eine PC-Tastatur an einen C64 anzuschließen und dabei nicht fürchten muss, dass irgendwelche kaputte Software nicht funktioniert. Ab hier ist es noch "Fleißarbeit", den PS2-Code aus Lyra in diesen Microcontroller zu portieren und sich ein vernünftiges Mapping auszudenken. Für ein Produkt reicht es aber meiner Meinung nach noch nicht, weil der C128D nicht abgedeckt ist. Ich vermute mal, dass es sehr viel mehr C128D ohne Tastatur gibt, als C64 ohne Tastatur.

    (Thread-Ruhe nach über 12 Jahren gestört - ist das Rekord?)

    Jens

    Kann die Routine denn aus Port A lesen, ohne dort auf Eingang umgeschaltet zu haben?

    Ja. Das ist ja das, was Sauhund ständig als "Ausgänge gegeneinander treiben" bezeichnet (so fragt man linke shift und shift-lock getrennt voneinander ab). Beim Auslesen des Datenregisters wird nicht das zurückgegeben, was man reingeschrieben hat, sondern das, was wirklich am Port anliegt. Wenn eine 1 reingeschrieben wurde, aber ein Kurzschluß gegen GND anliegt, liest man wirklich eine 0 zurück, trotz "Ausgang"-Programmierung im DDR.

    Jens

    In dem Moment, wo die CIA den zuvor von ihr benutzten Ausgang auf Eingang umschaltet, bekommen wir das mit und ändern auch die Richtung. Dazu muss die Schleife wie o.g. schnell genug durchlaufen (vor dem nächsten Lesen (4 µs?) muss alles erledigt sein), sonst klappt's nicht.

    Es klappt auch so nicht. Folgendes Szenario:

    - Scanner setzt Port A auf %11111110
    - Microcontroller bekommt's mit und errechnet %11110111 für Port B - wird ausgegeben

    Bis hierhin kein Problem - die Taste wird gedrückt. ABER: Wenn jetzt eine Ghostkey-Routine ihrerseits Port B auf Ausgang schaltet und auf %11110111 legt, aber dann erst Port A auf Eingang schaltet, steht auf beiden Seiten die 0, ohne dass Du herausfinden kannst, wer welchen Pin auf 0 gezogen hat. Irgendwann geht Port A dann auf $ff, weil dort nach Input gesucht wird, woraufhin Du erst reagieren kannst - möglicherweise zu spät, denn die Ghostkey-Routine hat schon gesagt "oh, da ist ff, also wurde doch nichts in dieser Spalte gedrückt".

    Schlimmer ist, wenn mit Port A gescannt wird und an Port B am Joystick gewackelt wird, denn dann fehlt Dir jede Info darüber, welches Bit in welche Richtung geht. Du mußt also auch die Situation abdecken, die annimmt, dass sowohl in Port A, als auch in Port B einzelne Bits auf Ausgang gestellt sind. Ohne Kenntnis der beiden DDRs ist das schlicht und einfach nicht möglich. Du wirst immer nur eine Teilmenge an Scannern und Fällen abdecken, aber mir erschließt sich kein Weg, wie Du *alle* Fälle in Betracht ziehen kannst.

    Du wirst also immer Annahmen über den Scanner machen müssen - schlechte Idee für universal-Hardware.

    Jens

    Mhhh, nein. Sobald man auf lesen schaltet und im gleichen Moment die CIA auch liest, ist ja Mist.

    Ähemm.. nee, das ist nicht die Ursache. Vielmehr hast Du das Problem, dass auf ein- und derselben Leitung eine 0 stehen kann und Du nicht weisst, wer diese 0 erzeugt hat: Du selbst, oder der Computer per Abfrage. Wenn eine Ghostkey-Erkennungsroutine halbwegs intelligent programmiert ist, testet sie nur die Bits ab, die sie auf dem "Hinweg" auch gesehen hat. Wenn sie dann noch gemein programmiert ist, wird *nicht* zwischendrin auf $ff umgeschaltet, so dass Du keinerlei Möglichkeit hast, den Scan-Zeitpunkt zu erkennen.

    Selbst wenn Du Dir "merkst", dass Du gerade Bit X von Port B auf low gezogen hast hilft das nicht viel, weil gerade dieses Bit bei der Ghostkey-Erkennung interessant ist. Ein- und denselben Pin kannst Du an einem Microcontroller nicht zum Eingang und zum Ausgang machen; null ist null, aber die Quelle dieser Null zu ermitteln ist "beliebig schwer", denn Du hast drei mögliche Quellen: Joystick, CIA-Scan und Dich selbst.

    Ich denk' mir was aus, was ich vielleicht unter ner open-Hardware-Lizenz veröffentliche (Premiere, habbich noch nie gemacht). Ein Riesengeschäft wird das wohl kaum werden.

    Jens

    Für die Tastenmatrix-Abfrage sollte das allerdings kein Problem darstellen, auch wenn die Worst-Case-Interruptlatenzzeit beim AVR IIRC 6 Takte beträgt.

    Gerade gemessen: Der Abfrage-Impuls ist fast 40µs lang, das ist für nen Microcontroller von heute Spazierschritt. Und ne Idee, wie man ohne den teuren Matrix-Chip hinkommt, habe ich auch. Ne Lösung für das ShiftLock-Problem habe ich aber noch nicht, und für den 128er sollte man sich auch gleich was ausdenken, aber dafür fehlt mir die Zeit. Die Idee für einen Tastaturadapter gefällt mir aber, vielleicht mache ich ein Produkt draus.

    Jens

    Oder Binärkomparatoren auf beiden Ports nutzen um einen Interrupt zu erzeugen? Allerdings klappt das auch nur wenn kein perfider Coder einzelne Bits der Ports wechselseitig benutzt.

    ...und wenn man genau darüber nachdenkt, könnte man so sogar bestimmte Ghostkeys innerhalb der Matrix erkennen, ich muß also mein Posting von gerade korrigieren und das Gegenteil behaupten: Wenn man immer nur ein Bit als Ausgang schaltet und 15 Bits als Input auswertet, können auch bestimmte Ghostkey-Effekte als Solche erkannt werden.

    Als IRQ-Quelle müsste man eigentlich die Ports eines Microcontrollers so programmieren können, dass sie einen falling-edge-IRQ auslösen, also ganz ohne Zusatzhardware. Oder können das die 8-bit AVRs nicht?

    Jens

    schwierig, es gibt auch scanner die mit verschiedenen mustern abwechselnd in beide richtungen scannen, damit kann man wohl diverse "ghostkey" probleme in den griff kriegen

    Damit bekommt man wirklich Ghostkey-Probleme in den Griff, aber auch nur die, die durch Joysticks verursacht werden. Ghostkeys innerhalb der Matrix erkennt man so nicht.

    Die Frage wäre, ob nicht eine automatische Erkennung der Richtung machbar ist: Die Matrix-Output-Routine lauscht so lange, bis einer der beiden Ports nicht mehr $ff ist. Je nachdem, welcher Port als Erster ungleich $ff ist, springt man in Richtungs-Routine A oder B. Problem: Richtungswechsel ist nur dann möglich, wenn die Abfrage-Routine auf C64-Seite auch brav auf $ff zurückschaltet und der Benutzer nicht gerade am Joystick rappelt.

    Jens

    (danke fürs back2topic)

    leider bin ich zu faul jetzt den link auf die threads zu suchen in denen du mit technischem fachwissen geglänzt hast, aber wenn du dich unbedingt ein wenig blamieren willst sag bescheid =)

    Lass' doch gut sein, das ist nicht gerade konstruktiv. Jim Brain hat offenbar in seiner V3 das gemacht, was schon 1995 durchs Usenet schwirrte.

    Zu der Lösung in Chameleon: Da haben wir den ganzen Prozessorbus und können die CIA-Register (insbesondere die DataDirectionRegisters) überwachen und entsprechend reagieren.

    Die billig-Variante wäre, wenn man an der Tastatur einstellen könnte, welche Richtung im Microcontroller-Code benutzt werden soll. Ne PS2 Tastatur hat ohnehin viel zu viele Tasten für den C64, da kann man auch eine für Config benutzen. Und die Scroll-Lock/Numlock LEDs haben auch keinen richtigen Sinn, die können als Richtungsanzeige benutzt werden - schwupp, schon ist man wieder bei einem einzigen Microcontroller, aber man kann Bruce Lee spielen (oder war das gar nicht das böse game? *kopfkratz*)

    Jens

    Mal ein anderer Ansatz: Warum nicht einfach die CIA Register überwachen? SwinSID schafft das beim SID doch auch sehr gut.

    Das Tolle am C64-Tastaturanschluß ist doch, dass es dort nicht nur die Matrix, sondern auch GND und +5V gibt. Man kann also etwas bauen, was garantiert in jedem C64 mit jeder Board-Version "nur steckbar" funktionieren wird. Wenn Du an die CIA gehst, schließt Du sehr viele 64er aus, bei denen der Chip nicht gesockelt ist. Das Hindernis für den Einbau ist ungleich größer.

    Jens

    Allerdings kann ich ja dann das hier: Bitte melde dich an, um diesen Link zu sehen.


    Als Tastaturtreiber bei langen Anschlußkabel ja auch
    vergessen.

    Korrekt. Es bedarf einer wirklich ausgefeilten Hard/Softwarekombination, wenn man beide Abfrage-Richtungen mit einem PS2-Adapter erschlagen möchte. Ich hatte mal ein solches Konzept durchgeplant, aber leider gibt's ne Menge Möglichkeiten auf C64-Seite, mit denen man einen solchen Adapter doch wieder überlisten kann.

    Zusätzlich gibt es Software, die die Tasten "linke Shift" und "shift lock" getrennt abfragen kann, auch wenn diese physikalisch an den gleichen zwei Leitungen angeschlossen sind. Wenn Du schon das Rad neu erfinden willst (ja, es gibt bereits PS2-Adapter für den C64), dann solltest Du auch solche Sachen mit einbeziehen, sonst wird's mit "Anerkennung aus der Szene" nicht viel.

    Jens