Beiträge von Henning

    Die von mir gefixte Version ist jedenfalls ein guter Kandidat für den zweiten Slot

    Mike


    Tatsächlich, dann gibt es mittlerweile ja doch eine sinnvolle Alternative.


    Das habe ich wohl in #2 überlesen, und auch der von dir verlinkte Thread zu deinem Patch ist wohl an mir vorbeigegangen.


    Hättest du was dagegen, wenn ich den Patch zum Reprom64 git repository hinzufüge und entsprechend auf der Projektseite beschreibe? Ich könnte dann auch ein kleines C-Program zum patchen schreiben, für diejenigen die nicht auf dem C64 brennen/patchen können oder wollen.

    dragonfly45 Ich vermute mal stark, dass du dich auf mein Reprom64 beziehst, oder? :)


    Die einfache Antwort: Nicht das ich wüßte. Lass erstmal einfach das Original-Basic drin, ignoriere die Basic-Adressleitung. Dann hat dein C64 ein funktionierendes Basic und bleibt kompatibel zu vorhandener Software. Klassische Basic-Erweiterungen sind eh meist auf Expansionsport realisiert.


    Ich habe im Reprom64 zwar die Möglichkeit hinzugefügt, zwischen zwei Basic-ROMs zu wechseln, allerdings nicht, weil es zu dem Zeitpunkt so viele alternative Basic-ROMs gegeben hätte. Tatsächlich wußte ich damals gar nicht, ob es überhaupt ein sinnvolles alternatives Basic in Form eines ROMs gibt.


    Dass überhaupt Basic mit dabei ist, liegt halt daran, dass das Reprom nicht in erster Line ein Kernel- und Charset-Umschalter sein sollte, sondern erstmal eine All-In-One-Lösung, um defekte Original-Roms nicht ständig durch wackelige Doppelsockel-Bastel-Lösungen oder einzelne Eprom-Adapter-Platinen, die dann nicht alle nebeneinander passen, ersetzen zu müssen. Dann lieber ein einziges Teil rein und das Thema ROMs ist gegessen. Das war die ursprüngliche Intention. Dabei dann nicht gleich Umschaltung und schön viel Platz mit hinzuzufügen, wäre dann aber auch doof gewesen.


    Das Design ist so wie es ist, weil alle anderen Möglichkeiten, den Platz im Eprom auszunutzen (z.B. nur ein Basic-Platz, statt dessen dann ein Kernel oder zwei Charsets mehr) die Dinge nur unnötig verkompliziert hätte. Und das nicht nur vom Hardware-Design her, sondern auch für den Benutzer.


    Denn dann hätte es für Kernal oder Charsets nicht zwei sondern drei Addressleitungen geben müssen, dann hätte verhindert werden müssen, dass bei Addressen größer fünf oder sechs die falschen Bereiche addressiert werden, und dann hätte dem Benutzer noch erklärt werden müssen, warum welches ROM bei den überzähligen Adressen erscheint, denn ich hätte ja nicht verhindern können, dass jemand drei Schalter anschließt und die dann lustig schaltet.


    Also habe ich das Design so einfach wie möglich gehalten (KISS) aber auch alle im Design steckenden Möglichkeiten an den Benutzer weitergegeben (alles andere wäre für mich Bevormundung).


    Hätte ich nur ein Basic "erlaubt", dann hätte wieder jemand anderes zurecht gefragt, warum ich denn die Basic-Addressleitung nicht für den Benutzer rausgeführt habe, wo die Hardware das doch eigentlich schon kann... ihr wisst ja, wie das ist :D

    Ok, hab ich erstmal wie beschrieben umgesetzt:


    https://github.com/hbekel/keym…377b86ebb22e85ac20cc006b1


    https://github.com/hbekel/keym…f74fd6965a8168cc62c568e06


    Die aktuell mitgelieferte udev-Regel habe ich heute morgen noch verbessert, die ist aber noch nicht auf github, das kann ich auch heute abend machen. Die verbesserte Regel erzeugt entweder /dev/keyman64, wenn keine Seriennummer konfiguriert ist, oder /dev/keyman64-<Seriennummer>, wenn eine da ist. Die aktuelle hängt einfach nur die Seriennummer an /dev/keyman64 an, also ohne dynamisch hinzugefügten Bindestrich... das ist aber eher Kosmetik. Mann kann ja auch immer spezifische Regeln selbst schreiben, wichtig ist ja, das jetzt überhaupt ein Unterscheidungsmerkmal für udev da ist.


    ABER, ich habe heute morgen nochmal nachgedacht, am besten wäre es, wenn ich einfach beide Methoden zum Auffinden des richtigen Keymans ermögliche (über device nodes oder über generisches Iterieren und zusätzliches Prüfen der Seriennummer).


    Denn dann könnte man, unabhängig vom Betriebssystem immer auch einfach nur die Seriennummer über --device bzw. KEYMAN64_DEVICE angeben:


    $ keyman64 --device brotkasten type "Hello World!" // funktioniert überall

    $ keyman64 --device u64 reset


    oder halt unter unixoiden Systemen ebenso


    $ keyman64 --device /dev/keyman64-brotkasten type "Hello World!" // funktioniert überall

    $ keyman64 --device /dev/keyman64-u64 reset


    Ich gucke mir das heute abend noch weiter an...

    Ich habe mir meinen Code nochmal angeschaut und habe festgestellt, dass ich den über --device angegebenen Pfad garnicht verwende, sondern nur über alle USB-Geräte iteriere und einfach das erste Gerät nehme, das ich mit der passenden Vendor- und Product-ID finde. Das erklärt zumindest das beobachtete Verhalten.


    Ich habe diese Methode wohl verwendet, weil sie generisch ist und unter allen Betriebssystemen funktioniert.


    Jetzt habe ich es hier soweit, dass unter Linux wirklich device nodes verwendet werden, also könnte man so die generischen nodes unter /dev/bus/ benutzen, um den gewünschten Keyman anzusprechen. Wirklich schön ist das aber auch noch nicht.


    Ich denke, ich werde noch die Möglichkeit einbauen, jedem Keyman über die config einen eigenen Namen geben zu können (technisch die Seriennummer des USB-Geräts).


    Dann könnte man mit einer passenden udev-Regel die Einträge unter /dev anhand der Seriennummer eindeutig und sprechend machen. Gibt man dem einen Keyman z.B. "brotkasten" und dem anderen "u64" als Seriennummern, würden sie dann so erscheinen:


    Code
    1. $ ls /dev/keyman64-*
    2. /dev/keyman64-brotkasten
    3. /dev/keyman64-u64


    Die udev-Regel dafür sähe dann so aus:


    Code
    1. SUBSYSTEMS=="usb", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="60e9", MODE:="0666", SYMLINK+="keyman64-$attr{serial}"

    Folgende Situation: System Linux, Intel Rechner an dem 3x C64 mit jeweils Keyman64 angeschlossen sind.


    Die Geräte werde unter "/dev/bus/001" und dann halt 047, 048, 049 aufgelistet.

    Also war meine Idee zb:


    keyman64 --device /dev/bus/001/047 -i


    um die Info für das erste angeschlossene Keyman zu bekommen.

    Das geht soweit auch, aber halt nicht für 048 und 049. Da wird mir immer das erste Keyman angezeigt

    Ich hätte jetzt auch gedacht, dass das gehen sollte... Gucke ich mir mal an.

    Der Keyman steuert die 8x8 Tastaturmatrix vom C64 darin ist die RESTORE Taste nicht enthalten. Also nein, er kann RESTORE nicht ansprechen.

    und pcollins


    Das stimmt, da Restore nicht teil der Matrix ist, ist sie für den Keyman auch nicht teil der Tastatur.


    Es spricht aber nichts dagegen, die Restore-Leitung zu einem der Keyman-Ports zu führen und dann wie jede andere Leitung auch über einen Befehl kurz auf Masse zu ziehen.


    Falls ich irgendwann nochmal eine neue Revision mache, würde ich die Restore-Leitung mit ansprechbar machen, ohne dass eine Portleitung dafür belegt werden muss. Habe ich leider beim Design damals nicht drüber nachgedacht, sorry.

    GMP Versuch's mal so:

    Code
    1. tristate a7 # Port A PIN 8 (FPGASID-TYPE) tristate
    2. m:0 clear a7 # jedes erste, dritte, fünfte... mal
    3. M:1 tristate a7 # jedes zweite, vierte, sechste... mal

    Die Syntax hat mich jetzt ehrlich gesagt selbst verwirrt, als ich mal wieder in die Doku geguckt habe, und die ist zudem noch falsch :whistling: Korrigiere ich morgen mal...


    Ich glaube sowas hier wäre einfacher zu verstehen:


    Code
    1. m:odd clear a7
    2. m:even tristate a7

    Oder zumindest sollte man 0 und 1 umdrehen, dann ist es nämlich einfach das niederwertigste bit der Anzahl der Betätigungen.


    Eine kleine HID-Tastatur mit bis zu 16 Tasten,, umgesetzt auf Atmega328 mit V-USB, dazu zwei 4051 und ein 7414.


    Über eine USB-Control-Message kann das Tastatur-Layout zur Laufzeit verändert werden, dazu habe ich ein kleines Kommandozeilen-Tool geschrieben.


    Das Ganze ist unter dem Schreibtisch montiert, so dass ich bequem an die Buttons komme, wenn ich mich im Bürostuhl zurücklehne und ich zu faul bin, mich vorzulehnen, um an die eigentliche Tastatur zu kommen.


    Unter Linux schalte ich dann das Layout mit Hilfe von devilspie2 dynamisch um, je nachdem, was für ein Fenster gerade den Fokus hat, z.B.:


    Ich habe das Problem mittlerweile lösen können. Es lag schlicht daran, dass die von mir gebaute Firmware aus den veröffentlichten Quellen veraltet war und nicht mehr kompatibel zum aktuellen Portal ist. Nach Update auf die aktuelle Firmware läuft alles wieder so, wie es soll :)

    geht das mit dem keyman? p4 als cevi, also auch 4 cursor tasten? wenn ja dann beschäftige ich mich damit nochmal genauer. sorry fürs off topic

    Mit dem keyman64 in seiner jetzigen Form könnte man zumindest vier zusätzliche Tasten irgendwie ins gehäuse flanschen, diese mit den freien GPIO-Ports verbinden und diese dann auf andere Tasten der vom C64 "gesehenen" Tastatur mappen. Die Konfigurations-Direktive "map" erlaubt es, eine Eingangsleitung mit einem Tastendruck zu verknüpfen. Um allerdings z.B. Shift und die Cursor-Hoch-Runter-Taste des C64 zu drücken um den Cursor nach oben zu bewegen müsste ich die Firmware noch ein bischen anpassen, das wäre aber nicht allzu schwierig.


    Im Moment geht nur "Eine Eingangsleitung auf eine Taste mappen", es bräuchte "Eine Eingangsleitung auf eine beliebige Befehlssequenz mappen" - Das wäre durchaus ein sinnvolles Feature.