Wäre nett. Danke.
Im Zweifel werde ich wohl die IDE Variante verfolgen.
Hallo Besucher, der Thread wurde 108k mal aufgerufen und enthält 679 Antworten
letzter Beitrag von Emwee am
Keyman64: Tastatur- und Hardwarecontroller
- Henning
- Erledigt
-
-
Lässt sich mit dem Keyman auch der Sleep Mode eines SD2IEC aktivieren?
Sleep Mode:
If you hold the disk change button down for two seconds, sd2iec will enter "sleep mode". In this mode it doesn't listen to the bus at all until you hold down the disk change button for two seconds again which resumes normal operation. -
Ja. Angenommen die Leitung des disk change buttons ist active low und an port a bit 0 angeschlossen:
DISK_CHANGE = port a bit 0
tristate DISK_CHANGES: clear DISK_CHANGE
S: sleep 2s
S: tristate DISK_CHANGE -
-
Gibt es zur Zeit eine Möglichkeit an ein KeyMan64 zu kommen?
Siehe http://henning-bekel.de/keyman64/#ordering-assembly-kits
Im Moment habe ich noch welche auf Lager.
-
OK, hab ich so gemacht.
-
Ich bin jetzt gerade dabei den Keyman64 über mein Joy-Control 64 anzusteuern. Dabei hab ich folgendes Problem.
Ich sende ausgesuchte PETSCII Codes an den Keyman der C64 gibt aber auf dem Monitor die falschen Zeichen aus. Z.B.:Aus $41 (A) wird $33 (3)
Aus $42 (B) wird $35 (5)
Aus $43 (C) wird $37 (7)Wenn ich mir die Ausgabe auf dem Logic Analizer ansehe dann komm ich aber auf die richtigen Werte. Also ist die Frage ob ich etwas an deinem Protokoll falsch verstanden habe oder verwendest du deine eine eigene Zeichentabelle?
Hier ein Screenshot vom Logic Analizer. Die Werte über der Datenleitung sind 0x04 danach 0xAA. Das müsste eigentlich ein Grafikzeichen sein. Der C64 gibt aber ein F aus.
Das Kommando Byte scheint noch zu stimmen. Immerhin gibt der C64 etwas aus. Mit dem Datenbyte geht aber irgend etwas schief. Sollte zischen den beiden Bytes noch ein Signal kommen?
-
Ich sende ausgesuchte PETSCII Codes an den Keyman
An dieser Stelle werden keine PETSCII-Codes interpretiert, es wird die laufende Nummer der Taste gemäß der internen, sich durch die Scanrichtung ergebenden Reihenfolge (keyman64 --keys) erwartet. Sonst wäre da auch von PETSCII-Codes die Rede und nicht von "key" bzw "key or slot number". Schließlich geht es um das Drücken von einzelnen Tasten und nicht um das Eingeben von PETSCII-Codes, wozu u.U. mehrere Tastendrücke erforderlich wären. Und manche PETSCII-Codes lassen sich auch garnicht über die Tastatur eingeben. Macht also hier keinen Sinn.
Da es nur 64 Tasten gibt, werden auch nur die unteren 6 bit des Arguments interpretiert. Also:
0xaa & 0x3f = 0x2a =~ Taste "F"
0x41 & 0x3f = 0x01 =~ Taste "3" etc... -
Danke das ergibt Sinn, wenn man darüber nachdenkt. Hab ich aber nicht. Irgendwie bin ich einfach davon ausgegangen dass das PETSCII oder ASCII Codes sein werden. Da hätte ich mir viel Arbeit sparen können und kein Eingabeschema für Hex-Codes bauen müssen. Da hätte das vorhanden Dezimale gereicht. Aber naja, was drin ist ist drin.
Ich hab mir noch eine entsprechende Tabelle gemacht (konnte nichts vernünftiges finden) und jetzt funktioniert die Datenübergabe wie erwartet.
Danke für deine Hilfe.Falls jemand auch mal den KeyMan über den seriellen Eingang ansteuern möchte, hänge ich mal die Tabelle an.
-
Danke das ergibt Sinn, wenn man darüber nachdenkt. Hab ich aber nicht. Irgendwie bin ich einfach davon ausgegangen dass das PETSCII oder ASCII Codes sein werden.
Falls es für dich besser wäre, wenn du über die serielle Schnittstelle auch PETSCII-Codes schicken kannst, könnte man das durchaus noch einbauen. Der Keyman weiß ja schon für seinen Type-Befehl, welche Tastensequenzen er für welchen PETSCII-Code drücken muss. Mir ist das bisher für die serielle Schnittstelle nicht in den Sinn gekommen. Wenn du zum Beispiel den Bildschirm löschen wolltest, müsstest du "zu Fuß" erst shift runter, dann CLR/HOME und dann shift rauf schicken, das ließe sich mit einem hypothetischen "type" Befehl zusätzlich zu "press" auf der seriellen Schnittstelle dann mit PETSCII 147 machen.
Das wäre für mich kein großer Aufwand, sag, ob du das brauchst. Ich nehme aber an, für deine Benutzer wäre es einfacher, in die PETSCII-Tabelle zu gucken, statt zu Fuß Sequenzen mit down/up/press einzupflegen, oder?
-
Ehrlich gesagt bin ich mir nicht so sicher wie es besser wäre. Das Ziel bei mir ist es ja einzelne Tastenanschläge vom Joystick aus auslösen zu können. Was man halt zum spielen so brauchen kann. Das wird meistens SPACE sein. Eventuell noch eine andere Taste. Mehr kann man sinnvoll mit einem 3-Tasten Joystick sowieso nicht machen.
Dazu sollte es immer genügen die entsprechende Taste auf dem Keyboard zu simulieren. Allerdings wäre der Komfort (auch für andere) natürlich schon größer wenn Du die PETSCII Codes direkt über die Schnittstelle abholen würdest.
-
Ich würde sagen ein zusätzlicher Schnitstellenbefehl der PETSCII versteht kann nicht schaden und tut nicht weh, von daher würde ich den noch einbauen. Welchen du dann benutzt, kannst du ja noch entscheiden. Ich denke aber auch, dass es für deine Anwendung einfache Tastenbetätigung ausreicht.
Wenn du allerdings den "press"-Befehl verwendest, gibt das einen einzigen Tastendruck mit fester Dauer (20ms glaube ich). Ebenso wenn es die PETSCII-Variante wäre.
Wäre es nicht schlauer, dem Benutzer die Taste in Form des Joystickbuttons richtig in die Hand zu geben, sprich wenn der Button gedrückt wird, sendest du "down", wenn der Button losgelassen wird, sendest du "up". Dann funktioniert der Button genau wie die Taste und kann länger oder kürzer gedrückt werden.
-
Prinzipiell ja, allerdings kommt mir das mit meiner regelbaren Dauerfeuerfunktion ins Gehege. Die möchte ich auch für die Tastenanschläge benutzbar halten. Aktuell ist mein Ansatz das maximal alle 60ms der Tastencode gesendet wird wenn der Knopf gedrückt gehalten wird oder eben 1 mal pro eingestellter Feuerperiode. Da kann sich aber beim Handling noch einige ändern. Ich bin noch am herumprobieren was ich am praktikabelsten finde.
-
Super Sache - Danke an Euch beiden... Ich kann's kaum erwarten beides in Aktion zu erleben.
-
Ich habe nun die Version 1.6 veröffentlicht.
Update-Anleitung:
Um die Firmware auf diese Version zu bringen, muss zunächst die Client-Anwendung aktualisiert werden. Dann kann mit der neuen Form des update-Befehls die Firmware installiert werden:
keyman64 update keyman64-application-1.6.hex keyman64.conf
Wobei "keyman64.conf" auf eine gültige Konfigurations-Datei zeigen muss.
Dies ist notwendig, da die neue Firmware mit dem alten und u.U. noch auf dem Atmel vorhandenen Konfigurationsformat nicht mehr kompatibel ist. Der update-Befehl deaktiviert vor dem Update die vorhandene Konfiguration und spielt danach die angegebene Konfiguration neu ein.
Neue Features:
Hauptsächlich ist hier die Unterstützung für eine Erweiterung der Kontrollports mit Hilfe von einem oder mehreren 74595 zu nennen. Wem also die 16 vorhandenen Steuerleitungen nicht mehr reichen kann diese nun auf einfache Weise erweitern. Der 74595 ist ein serielles Schieberegister. Diese Register können beliebig hintereinander geschaltet werden. Pro IC steht dann ein weiterer 8-bit breiter Port zur Verfügung. Egal, wie viele zusätzliche Ports man verwendet, zur Ansteuerung durch den Keyman werden nur 4 "native" Steuerleitungen benötigt.
Hier ein Beispiel zum Anschluss von zwei 74595 breakout-boards:
Ist die Erweiterung auf diese Weise angeschlossen, muss dem Keyman dies nur noch mitgeteilt werden:
expand PORTS=2 DATA=b0 CLOCK=b1 LATCH=b2 ENABLE=b3
Danach können die neuen Ports als "port c" und "port d" wie gewohnt in der Konfiguration verwendet werden.
Benutzt man also zwei Register, stehen insgesamt nun 28 Steuerleitungen am Keyman zur Verfügung.
Die einzige Einschränkung besteht darin, dass es sich bei den zusätzlichen Ports um reine Ausgänge handelt. Diese können also nicht auf tristate gesetzt werden und auch nicht als Eingänge für den "map"-Befehl verwendet werden.
Die hier gezeigten breakout-boards gibt es zum Beispuel von Artekit: https://www.artekit.eu/product…595-8-bit-shift-register/.
Alles weitere dazu ist auf der Website beschrieben.
Geschwindigkeit des Tastaturscans:Mit der neuen Direktive "speed" kann die Geschwindigkeit, mit der die Tastatur ausgelesen wird, zwischen "slow" und "fast" gewählt werden. Standard ist "fast" (wie bisher). "Slow" wird zum Beispiel im SX64 benötigt, da dort das Tastaturkabel um einiges länger ist und etwas mehr Zeit benötigt wird, bevor die Signale stabil werden.
Allerdings ist "slow" nicht viel langsamer als "fast" und bewirkt keine merkliche Verzögerung.
Kurznotation für Steuerleitungen und -bereiche:
Ab Version 1.6 kann man statt "port a bit 7" nun auch einfach "a7" schreiben. Ebenso können Bereiche wie "port b bits 0-1" nun kurz "b0-1" geschrieben werden.
Bessere Kompatibilität mit Modulen beim Einschalten:
GI-Joe ist aufgefallen, dass Module, die beim Start eine Taste abfragen den Tastendruck nicht mitkriegen, wenn der C64 eingeschaltet wird. Dies lag daran, dass der Keyman erst nach Initialisierung des USB-Gerätes mit dem Scannen der Tastatur beginnt. Daher erfolgt nun frühzeitig ein erster "scan und relay"-Schritt, der dieses Problem behebt.
-
Klasse Henning. Mehr Ports hatte ich mir immer gewünscht. Super Arbeit.
-
Klasse Sache. Mal gucken, ob ich das vor der DoReCo noch geupdatet kriege.
Danke
-
-
Wird die Meta-Taste beim earlyScan als normale Taste durchgeschaltet?
Ja wird sie. Sobald aber die USB-Initialisierung nach 500-1000ms abgeschlossen ist, geht es in die normale Scan-Routine, d.h. wenn du dann noch die Metataste gedrückt hast und du sie wieder loslässt, wird wie gehabt nochmal ein Meta-Tastendruck gesendet.
-
Klasse Henning, Danke.