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

    Ah, verstehe, dass wusste ich nicht.

    Mhh, es scheint aber nichts an meinem letzten Beitrag zu ändern: Statt von Output auf Input umzuschalten und uns damit Reaktionszeit zu gönnen, müsste der "Leser" von 0 auf 1 umschalten und dann lesen, was uns auch Reaktionszeit gibt.

    Zugegebenermaßen ist das Thema für mich nur akademisch, weil ich nicht vorhab, sowas zu machen. Und der Thread-Starter hat sich anscheinend schon ausgeklinkt. Könnte auch ziemlich sportlich werden, wenn man das mit einem Atmega lösen wollen würde, wenn man wirklich nur 3 µs zum Durchkauen der Logik hat. Ich würde ja einen LPC2101 nehmen :wink: Aber den kann wieder keiner löten. Oder gleich programmierbare Logik.

    Es gibt aber definitiv eine theoretische Lücke im o.g. Code: Mehrere gedrückte Tasten. Was aus der einen rauskommt, würde sich rückwärts wieder auf den "Quellport" auswirken. Bei Shift z.B. ginge es noch, aufgrund der Anordnung in der Matrix. Da wird kein Rückwärts gebraucht. Aber mehrere Buchstaben z.B....

    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".


    Danke für das konkrete Beispiel. Kann die Routine denn aus Port A lesen, ohne dort auf Eingang umgeschaltet zu haben?

    IMHO kann sie erst den anderen Port aus Schreiben schalten. Irgendwann muss sie aber den Port A (evtl. nur diese Leitung) auf Input schalten. Diese wird dann aus Sicht des Controllers high (1). Jetzt sorgt die Schleife dafür, dass die Richtung umgeschaltet wird. Mit der nächsten Instruktion liest die CIA das Register aus. Schließlich kann auch die CIA auf einer Leitung nicht gleichzeitig schreiben und (was anderes) lesen. Da sollte das seitens des Controllers dann schon erledigt sein. Deshalb kam ich ja auch auf 4 µs (STA DDRA, LDA DRA oder sowas). Wobei es evtl. auch nur 3 sind, wg. der CIA.

    Über Deinen zweiten Absatz denke ich nach, wenn wir den Irrtum im ersten geklärt haben. Egal, auf welcher Seite er liegt :wink:

    (1) Denn diese Seite/Leitung habe ich ja genau aus diesem Grund im Controller als Input gelassen.

    Edit:

    Zitat

    steht auf beiden Seiten die 0, ohne dass Du herausfinden kannst, wer welchen Pin auf 0 gezogen hat


    Das ist meiner Meinung nach der Irrtum: Die 0 steht nicht (dauerhaft) auf beiden Seiten. Sie verschwindet auf der Seite, von der kurze Zeit später gelesen werden soll. Aber vielleicht liege ich ja hier auch falsch. Dann lerne ich gern was dazu.

    Danke für die Infos.

    - schlichtes scannen in die andere richtung. (zur unterscheidung joystick/tasten reicht das glaub ich)


    Das sollte mit o.g. Methode gehen. 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.

    Einen Joystick sollte man sogar noch einfacher erkennen können: Wenn die CIA alle Ports auf Input hat und totzdem noch irgendwo ein Low reinkommt.

    Zitat

    - scannen mit verschiedenen bitmustern, und eventuell auch sogar mit in verschiedene richtungen eingestellten leitungen auf dem selben cia port


    Sollte auch berücksichtigt sein, weil wir pro Leitung und nicht pro Port arbeiten.

    Zitat

    - ausnutzen von dreckeffekten, zb paar takte lang ausgang gegen ausgung treiben, dann im scanner die latches lesen. hier kann man durch messen der zeit bis ein bit kippt rückschlüsse darauf ziehen was in der matrix passiert (ähnlich wie bei der abfrage von shift-lock)


    Obwohl ich das Prinzip noch nicht ganz verstehe (Ausgang gegen Ausgang bei OC?): Das hat wohl was mit den unterschiedlichen Widerständen von Shift Lock und Shift zu tun. Und funktioniert wohl nicht mal auf allen C64igen zuverlässig.

    Zitat

    letzteres würde ich vermuten ist schwierig bis garnicht zu simulieren mit so einer schaltung (egal welcher art).


    Wenn man wirklich eine Primitivlösung mit einem Controller und sonst nix umsetzen möchte, könnte man auch darauf verzichten. Selbst ein Matrixschalterdingens wird das vermutlich nicht ohne weiteres können.

    Eigentlich habe ich auch keine Zeit, mich mit diesem Thema zu beschäftigen. Aber interessant ist's und ich schaue auch wiedermal vorbei :smile:

    Gut, so ähnlich habe ich es geahnt. Der zweite Teil der Antwort fehlt aber noch :smile:

    Okay, ich habe noch nicht genau darüber nachgedacht, was mit der o.g. Implementierung passiert, wenn ein Joysticks-Kontakt geschlossen ist. Bis jetzt würde das so gewertet werden, als sei die entsprechende Leitung der CIA auf Low. Wir würden also, falls eine Taste gedrückt ist, das andere Ende der Matrix auch auf Low ziehen (wenn es nicht schon von der CIA auf Low ist). Sobald der Joystick-Kontakt geöffnet würde und die entsprechende Leitung nicht auch von der CIA auf Low liegt, würden wir auch das andere Ende wieder loslassen (also auf Input schalten). Ist doch eigentlich wie bei einer physikalischen Tastatur, die "weiß" auch nicht, ob die CIA oder der Joystick an der Leitung zieht.

    Und wenn Du jetzt noch sagst, warum sich ein ghostkey-aware Scanner an o.g. Implementierung stören würde. Ich seh's wirklich nicht.

    Bevor ich Jens' Beitrag gelesen hab, hab ich selbst den Gedanken weitergesponnen.

    Das Ganze wird nicht portweise, sondern leitungsweise gemacht, dadurch kann jede Leitung einzeln in eine andere Richtung geschaltet sein. Ich gehe davon aus, dass, wenn ich an beiden "Enden" (Also Zeile oder Spalte) der Matrix eine 0 lese, sich eine gedrückte Taste nicht auswirkt. Wenn ich an einem Ende keine 0 mehr lese, wurde wohl gerade die Richtung auf dieser Leitung umgedreht und ich schalte das andere Ende auch wieder auf Input. Und ich gehe davon aus, dass Bits, die von der CIA gelesen werden und die ich nicht auf Low ziehe, auf High liegen.

    Die Hauptaufgabe dabei ist, die Daten so geschickt abzulegen, dass die ganze Schleife in wenigen µs durchlaufen kann. Da man manche Operationen meistens abkürzen kann und oft mehrere Leitungen bzw. Bits mit logischen Operationen auf einmal behandeln kann, sollte das klappen. Die Codegröße ist ja auch nicht sooo ausschlaggebend, weil der Controller sonst nichts zu tun hat.

    Nun muss ich zugeben, dass ich nur ahne, was eine Ghostkey ist und keinen Schimmer habe, wie sie normalerweise detektiert werden. Deshalb weiß ich auch nicht, ob und warum dieser Algorithmus nicht immer funktionieren würde.

    Aber immerhin könnte man eine Menge verquerer Tastaturabfragen mit einem primitiven Controller unterstützen. Auf IRQs würde ich ggfs. sogar verzichten. Den Overhead könnte man sich wahrscheinlich sparen, wenn das PS2-Protokoll wirklich so langsam ist, dass man es in der Hauptschleife mit abfrühstücken könnte.

    Hinweis: Leitungen, die auf Eingang stehen und immernoch auf Low sind, rufen bei unveränderter Tastensituation keine Änderung am anderen Ende hervor.
    Hin- und Hergeschaltet wird vom Controller aus natürlich immer nur Input<=>Low.

    Wenn ihr erkennt, dass mit dieser Lösung etwas definitiv nicht funktioniert, bitte schreibt ein ganz konkretes Beispiel. Das vermeidet Missverständnisse.

    Gruß,

    Thomas

    Ähm, bin vielleicht schon zu müde, um das zu raffen, aber: Wenn an den CIAs OC-Ausgänge sind oder sowas. Und man das am Atmel auch so machen würde. Kann man dann nicht stupide in beide Richtungen hin- und herschalten? Also A lesen, B schreiben, B lesen, A schreiben... Mhhh, nein. Sobald man auf lesen schaltet und im gleichen Moment die CIA auch liest, ist ja Mist.

    Aber vielleicht spinnt jemand die Idee weiter :wink: