Keyman64: Tastatur- und Hardwarecontroller

Es gibt 713 Antworten in diesem Thema, welches 142.147 mal aufgerufen wurde. Der letzte Beitrag (7. September 2025 um 13:54) ist von mac of tugcs.

  • Hast du ein Modul (Action/Retro/Sonstwas-Freezer-Fastload) eingesteckt, das die IO-Bereiche nutzt? Wenn ja kommt es da natürlich zu Konflikten, da diese sich ebenfalls in $de00 und/oder $df00 einblenden. Genau dafür ist die Kontrolle über I1EN und I2EN ja gedacht. Hast du einen spezifischen Grund, diese Bereiche immer pauschal mit für den zweiten SID zu verwenden? Wenn nicht, lass es. Es gibt eine handvoll schlechter Stereo-SIDs bei $de00 und kein einziges bei $df00 (in der aktuellen HVSC). $de00 brauchst du höchstens für MSSIAH, und dann schaltest du I1EN auch nur zu, wenn du es tatsächlich gerade benutzt.

    Die Idee, einfach einen SID an I/O1 oder I/O2 zu hängen, ist bescheuert. Mein Board unterstützt das nur, weil es eben historische "Lösungen" gibt, die das so gemacht haben. z.B. das SID2SID board vom MSSIAH. Würden die Jungs von MSSIAH mal eine firmware rausbringen, bei der sich eine vernünftige Adresse ($d420 oder $d500) für den zweiten SID einstellen ließe, könnte man sich den ganzen Tanz sparen.

    Übrigens kanns du auch Bereiche von Leitungen gemeinsam schalten, statt alle bits einzeln zu setzen:

    set port a bits 0-1 to 0
    set port a bits 0-1 to 1
    set port a bits 0-1 to 2
    set port a bits 0-1 to 3

  • Alles klar, jetzt bin ich um einiges an Wissen reicher!!! :thnks: für deine ausführliche Antwort.
    Nein, es war kein Modul o.Ä. gesteckt, nur Power und Video Out. Ich habe mich mit der Adressierung des zweiten SID so genau auch noch nicht beschäftigt, aber jetzt weiß ich, das ich die Funktion über die IO Umschaltung bestimmt nie brauchen werde. Ich dachte es wäre wichtig/besser alle Funktionen deines MixSID dann auch nutzen zu können. Ich lass das erstmal so in der Konfig und auch mit den zusätzlichen Adressleitungen am Expansionsport. Vielleicht kommt ja doch noch mal eines Tages ein MSSIAH in Haus...oder falls ich doch noch mein TC64 über den Keyman64 bedienen möchte.

    Das mit dem gemeinsamen schalten der Port Bits ist mir bewußt, werde ich in meiner neuen Konfig auch so machen. Ich hatte bis spät in die Nacht am Keyman64 mit verschiedenen Konfigs probiert, da war für mich das einzelne schalten etwas übersichtlicher zum lesen :drunk:

    <C64 I +MixSID +Keyman64 +Reprom+ WiC64...Ultimate64 +SX64 Style Case +Rear Admiral Thunderdrive +Nunchuk64 ...MorphOS PowerBook G4...Acorn A3000 +4MB +IDE RiscPC700 +StrongARM +5x86 AlephOne PC Card>
    <Icebird: Acorn Demogroup - Mini Mag Diskmag - TRT The Retro Team aus Oldenburg>

    <Retrospieleabend@Attraktor e.V. Hamburg>

    <Highscore Friends Bitte melde dich an, um diesen Link zu sehen.>

  • Ok, mal zurück zum Thema.

    Gute Neuigkeiten: TheRealWanderer hat sich bereiterklärt, eine Serie von 25 Stück vorzufinanzieren. Davon sind 9 Stück bereits bestellt, danach habe ich dann also noch 16 Stück direkt auf Lager.

    Da TheRealWanderer und ich uns auf der DoReCo nicht darüber einigen konnten, wem denn nun der (geringe, aber dennoch vorhandene) Gewinn zusteht (jeder von uns beharrte darauf, dass er dem anderen zustünde), haben wir kurzerhand beschlossen, diesen gemeinsam der DoReCo zu spenden.

    An dieser Stelle also vielen, vielen Dank an TheRealWanderer für diese Aktion!

    Im Entwicklungszweig der Firmware hat sich auch ein bischen was getan: Zum einen wurden ein paar kleinere Bugs beseitigt, zum anderen wurde ein neues Feature implementiert, dass es erlaubt, eine Aktion erst nach zweimaligem Drücken der belegten Taste auszuführen, sinnvoll z.B. für die Reset-Taste, um nicht aus Versehen einen Reset auszulösen, bevor man seine Sachen gespeichert hat.

    Ein weiteres neues Feature ist die Möglichkeit, eine Steuerleitung auch als Eingang verwenden zu können und bei ein Low-Signal in einen Tastendruck zu übersetzen. Parallel habe ich eine kleine Zusatz-Platine in Arbeit, die es erlauben wird, die Paddle-Leitungen wahlweise wie gewohnt zum SID oder aber "woanders hin", also zum Keyman durchzuschleifen. Beides wird in Kombination die Möglichkeit eröffnen, sich Tasten auf zwei zusätzliche Buttons an entsprechend modifizierten Joysticks zu legen. In Verbindung mit der seriellen Schnittstelle des Keyman wird es dann auch möglich sein, die Zuordnung von Buttons zu Tasten vom C64 aus zu ändern, sodass man sich einen kleinen Loader für das jeweilige Spiel schreiben kann, der den Keyman gleich passend konfiguriert. Wenn es interessiert kann sich mal diesen Bitte melde dich an, um diesen Link zu sehen. auf github ansehen.

    Diese Features werden in kürze in einem neuen, offiziellen Release erscheinen.

  • Hi Henning,

    zum anderen wurde ein neues Feature implementiert, dass es erlaubt, eine Aktion erst nach zweimaligem Drücken der belegten Taste auszuführen


    ich habe gestern meinen MixSID eingebaut (echt geniales Teil!), mit dem Keyman64 verkabelt und in dem Zug diesen auch gleich auf Firmware 1.3 aktualisiert. Soweit alles bestens, aber dieses Policy-Feature funktioniert igendwie etwas komisch.
    Und zwar hab ich bei einer Tastenzuordnung (auf Taste "i") die Policy auf 0 gesetzt, so dass die entsprechende Funktion erst beim zweiten Tastendruck ausgeführt werden soll.
    Wenn ich Meta + i + i drücke, wird die Funktion erst beim zweiten Druck auf 'i' ausgeführt, soweit so gut.
    Wenn man Meta + i drückt, passiert nix, auch gut. Wenn man dann aber nochmal Meta + i drückt, wird die Aktion auch ausgeführt.
    Ich hätte erwartet, dass nach Loslassen der Meta-Taste das Zählen wieder von vorn beginnt.


    Mein Keyman schaltet nun schon einige Signale, da ist es nicht immer leicht den aktuellen Zustand zu erkennen. Ja, man könnte zig LEDs anschließen und ich weiß auch dass an einer Bildschirm-Overlay-Lösung gearbeitet wird, aber wie wäre es mit einer "kleinen" Lösung, nur mit dem Keyman? Ein spezielles Kommando könnte den Zustand aller (oder aller benutzten) Pins als Text ausgeben. OK, funktioniert natürlich nur, wo man den Text auch sieht, z.B. im BASIC Modus, aber immerhin.
    Oder man bohrt den type Befehl auf, z.B. auf eine printf-ähnliche Syntax, so dass man eigene Meldungen definieren kann, z.B.:
    type REM MixSID MIXER_CONTROL is %d~ \ port a bits 4-5
    oder so ähnlich.

    AC/64 - C64 Umbau auf 9V Wechselspannung: Bitte melde dich an, um diesen Link zu sehen.
    Jocopod - Joystick to Controlport Dongle: Bitte melde dich an, um diesen Link zu sehen.

  • Und zwar hab ich bei einer Tastenzuordnung (auf Taste "i") die Policy auf 0 gesetzt, so dass die entsprechende Funktion erst beim zweiten Tastendruck ausgeführt werden soll.
    Wenn ich Meta + i + i drücke, wird die Funktion erst beim zweiten Druck auf 'i' ausgeführt, soweit so gut.
    Wenn man Meta + i drückt, passiert nix, auch gut. Wenn man dann aber nochmal Meta + i drückt, wird die Aktion auch ausgeführt.
    Ich hätte erwartet, dass nach Loslassen der Meta-Taste das Zählen wieder von vorn beginnt.

    Entschuldige, dass ist ein Missverständnis, mein Fehler: Das "policy" feature ist schon in 1.3 enthalten und dient dazu, bei jedem geraden Tastendruck eine andere Aktion auszuführen, als beim jeweils ungeraden. So kann eine Taste auch als Ein/Aus-"Taster" (flipflop) für komplexere Schaltsequenzen benutzen werden. Daher wird die Zählung da auch nicht zurückgesetzt.

    Das von mir erwähnte Feature "Ausführen einer Sequenz erst nach mehrmaligem Tastendruck" ist vorerst nur im git, wird aber erst in der in Kürze kommenden Version 1.4 offiziell. Das dient dazu, eine einzige Schaltsequenz erst nach mehrmaliger Betätigung der Taste auszuführen, und funktioniert so, wie du es hier von "Policy" erwartet hast. Details siehe Bitte melde dich an, um diesen Link zu sehen..

    Du kannst dir gerne eine firmware aus dem aktuellen git bauen und testen ;) Ansonsten noch etwas Geduld...

    Ein spezielles Kommando könnte den Zustand aller (oder aller benutzten) Pins als Text ausgeben. OK, funktioniert natürlich nur, wo man den Text auch sieht, z.B. im BASIC Modus, aber immerhin.
    Oder man bohrt den type Befehl auf, z.B. auf eine printf-ähnliche Syntax, so dass man eigene Meldungen definieren kann, z.B.:
    type REM MixSID MIXER_CONTROL is %d~ \ port a bits 4-5
    oder so ähnlich.

    Eine formatbasierte Ausgabe wäre etwas aufwändiger, ein generelles "status"-Kommando wäre erstmal einfacher, wenn auch schwerer zu lesen, da der Keyman ja nicht weiß, was die einzelnen Steuerleitungen bedeuten. Im einfachsten Fall wäre das ja etwas wie

    00110011
    XXX00100

    Overlay: ist in Arbeit, die Hardware ist soweit fertig (bis auf ein paar Kleinigkeiten), ich muss allerdings noch etwas die Client-Software polieren und dokumentieren...

  • Entschuldige, dass ist ein Missverständnis

    Aaah! OK, ja, das hab ich falsch verstanden, danke für's Erklären. So ergibt das nun auf einmal alles einen Sinn. :)

    OK, dann bau ich mir heute Abend mal die git-Version.


    Im einfachsten Fall wäre das ja etwas wie

    00110011
    XXX00100

    Wär ja schonmal besser als nix. Sprich, ich wär :dafuer:

    AC/64 - C64 Umbau auf 9V Wechselspannung: Bitte melde dich an, um diesen Link zu sehen.
    Jocopod - Joystick to Controlport Dongle: Bitte melde dich an, um diesen Link zu sehen.

  • Du kannst dir gerne eine firmware aus dem aktuellen git bauen und testen


    Gebaut und geflasht.
    Das Ausführen nach mehrmaligem Tastendruck funktioniert astrein. Sehr cool!

    AC/64 - C64 Umbau auf 9V Wechselspannung: Bitte melde dich an, um diesen Link zu sehen.
    Jocopod - Joystick to Controlport Dongle: Bitte melde dich an, um diesen Link zu sehen.

  • Ich habe nun die Bitte melde dich an, um diesen Link zu sehen. veröffentlicht.
    Hier in Kürze die neuen Features und Hinweise zum Update:

    Das Komandozeilentool ist um zwei weitere Befehle erweitert worden, die das Übertragen der Konfiguration und das Aufspielen neuer Firmwareversionen vereinfachen, so dass dazu nicht mehr zwingend avrdude benutzt werden muss.

    Der Befehl "configure" übernimmt das Konvertieren und das Übertragen der Konfiguration. Es reicht nun ein

    $ keyman64 configure keyman64.conf

    Es muss also nicht mehr erst konvertiert, dann der Bootloader aktiviert und dann avrdude benutzt werden.

    Der Befehl "update" kann in Zukunft verwendet werden, um die Firmware zu aktualisieren, z.B.

    $ keyman64 update keyman64-firmware-1.x.bin

    Um ein Update auf die Version 1.4 durchzuführen, sind allerdings diesmal ein paar mehr Schritte nötig, da sich sowohl die Firmware als auch der Bootloader und das Binärformat der Konfiguration geändert haben.

    Wer ein externes Programmiergerät besitzt (z.B. TL886) kann das kombinierte Image aufspielen (keyman64-application-and-bootloader-1.4.hex) und muss danach die nur noch seine Konfiguration einmal mit dem neuen Komandozeilentool konvertieren und in's Eprom flashen. Dazu muss allerdings noch einmal die "alte" Methode verwendet werden (manuell in den Bootloader gehen, binäre Konfiguration wie gehabt mit avrdude übertragen).

    Wer keine Möglichkeit hat, den Atmel außerhalb des Keymans zu programmieren, muss wie folgt vorgehen, und zunächst den Bootloader selbst updaten:

    1. Das neue Komandozeilentool auf dem PC installieren
    2. Den Keyman in den Bootloader-Modus setzen (z.B. über "keyman64 boot")
    3. avrdude -p m1284p -c usbasp -U flash:w:keyman64-bootloader-updater.hex
    4. Ein paar Sekunden warten, bis der Bootloader upgedatet ist
    5. Den keyman erneut in den Bootloader-Modus versetzten, diesmal muss aber die manuelle Methode benutzt werden: Boot-Taste gedrückt halten, Reset-Taste drücken, Boot-Taste loslassen.
    6. Nun die Konfiguation einmal neu mit "convert" konvertieren und mit avrdude wie gehabt übertragen
    7. Wieder wie in Punkt 5 beschrieben in den Bootloader wechseln und die neue Firmware aufspielen:
    8. avrdude -p m1284p -c usbasp -U flash:w:keyman64-application-1.4.hex

    Nachdem das erledigt ist, stehen die neuen Komandozeilen-Befehle "update" und "configure" zur Verfügung.

    Weitere Features:

    - Der neue Keyman-Befehl "status" gibt den aktuellen Zustand der Steuerleitungen aus. (Vorschlag von lvr, danke).
    - Der neue Keyman-Befehl "version" gibt die Version der firmware nebst Build-Datum aus.

    (beide Befehle tippen die Ausgabe in der Tastatur, diese ist also nur zu sehen, wenn man sich auch im
    C64-Direktmodus befindet).

    - Der neue Keyman-Befehl "map" erlaubt das Verknüpfen einer Steuerleitung mit einer Taste. Die Leitung wird dadurch zu einem low-aktiven Eingang; Ist die Leitung low, wird die entsprechende Taste gedrückt.

    - Die Syntax für den Befehl "type" wurde geändert, es können nun alle PETSCII-Zeichen und Steuercodes verwendet werden, die auch auf der realen Tastatur eingegeben werden können. Dazu werden Escape-Sequenzen verwendet:

    \r für RETURN
    \n für SHIFT-RETURN
    \f für SHIFT-CLRHOME
    \\ für ASCII-Backslash (entspricht PETSCII-Pfund)

    Um beliebige PETSCII-Codes einzubetten können diese auch hexadezimal oder dezimal Kodiert werden:

    \xnn für hexadezimal, z.B. \x93 = SHIFT-CLRHOME
    \{ddd} für dezimal, also z.B. \{5} für weiße Schrift, \{147} Bildschirm löschen (Basic-Coder denken "chr$-Codes"))

    Falls ihr in eurer Konfiguration Makros definiert habt, in denen RETURN durch eine Tilde (~) kodiert ist, wird diese nun als PI-Symbol ausgegeben. Verwendet hier statt der Tilde die Escape-Sequenz \r.

    Die Tilde hier zu missbrauchen war eine blöde Idee von mir, die jetzige Lösung ist technisch sauberer. Sorry.

    Ein weiteres neues Feature ist die "requires"-Direktive, die den Keyman anweist, eine an eine Taste gebundene Befehlssequenz erst auszuführen, wenn die Taste mehrere male gedrückt wurde, ohne das die Metataste zwischendurch losgelassen wurde. Damit kann man sich selbst vor versehentlichem aktivieren potentiell destruktiver Befehel (z.B. eines Resets) schützen:

    R: requires 3
    R: clear port a bit 0
    R: sleep 20
    R: tristate port a bit 0

    Angenommen, port a bit 0 ist an die Reset-Leitung angeschlossen. Ein Reset wird dann nur durchgeführt, wenn r dreimal hintereinander gedrückt wird, während die Meta-Taste dabei durchgängig gedrückt gehalten wird. Dank an c0zmo für diesen Vorschlag.

    Eine letzte Änderung betrifft die serielle Schnittstelle (benutzt die überhaupt jemand?). Jedenfalls muss hier nun auch der Befehl als Byte (und nicht wie zuvor als nibble) übertragen werden, um zukünftige Erweiterungen möglich zu machen. Wer diese Schnittstelle verwendet, muss also seinen Code entsprechend anpassen. Die von mir bereitgestellten Assembler-Beispiele dazu sind in der aktuellen Distribution angepasst.


    Jetzt noch kurz zum aktuellen Batch:

    Ist in Arbeit, ich werde jetzt die neue Version 1.4 auf die Atmels brennen und mit dem Zusammenstellen der Bausätze beginnen. Sorry, das es diesmal so lange dauert, aber Real Life verlangt gerade viel Zeit... Ich hoffe allerdings, in der nächsten Woche verschicken zu können.

    Henning

  • Hallo Henning,

    ich habe soeben die neue Firmware kompiliert und meine beiden in Produktion befindlichen Keymans erfolgreich auf die Version 1.4 gebracht. Über die Kommandozeile mit avrdude hat das nach deiner Anleitung super geklappt! :thumbsup:

    Die Befehle "status" und "version" sind eine tolle Sache, um zu prüfen, ob wirklich alles geklappt hat. Aber das Beste ist tatsächlich die vereinfachte Konfiguration - mit einem Kommando konvertieren und flashen, super! Danke, dass du das Schmuckstück so toll pflegst. :)

    c0z

  • @cozmo: Danke für die Rückmeldung :)

    Was das direkte Übertragen der Konfiguration angeht, das schwebte mir schon länger vor, musste halt nur mal gemacht werden. Schöner ist eigentlich noch die direkte Kommunikation mit dem Bootloader über USB beim flashen der zukünftigen firmware-updates, das hat sich letztendlich als sehr einfach zu realisieren herausgestellt. Es muss in Zukunft also nicht mehr zwingend avrdude mit seiner zugegebenermaßen eher kryptischen Syntax verwendet werden.

  • Hallo Henning,

    ich habe soeben die neue Firmware kompiliert und meine beiden in Produktion befindlichen Keymans erfolgreich auf die Version 1.4 gebracht. Über die Kommandozeile mit avrdude hat das nach deiner Anleitung super geklappt! :thumbsup:

    Die Befehle "status" und "version" sind eine tolle Sache, um zu prüfen, ob wirklich alles geklappt hat. Aber das Beste ist tatsächlich die vereinfachte Konfiguration - mit einem Kommando konvertieren und flashen, super! Danke, dass du das Schmuckstück so toll pflegst. :)

    c0z

    Irgendwie stehe ich auf dem Schlauch

    Habe die Kombi-Firmware nach Anleitung von Henning mittels TL866 auf den Atmega1284P gebracht, bekomme aber keine Rückmeldung vom Keyman64

    reading commands from stdin...

    ist das letzte was ich sehe
    wenn ich z.B.
    keyman64 status
    eingebe, schliesst sich das Keyman64 Fenster.

    Wie lautet die richtige Syntax um einen Befehl abzusetzen?
    Ich habe noch keine Conf drauf.

    8-Bit enthalten circa 150g reinen Alkohol und sind bei regelmäßigem Konsum nicht unbedenklich :drunk:

  • Habe die Kombi-Firmware nach Anleitung von Henning mittels TL866 auf den Atmega1284P gebracht, bekomme aber keine Rückmeldung vom Keyman64

    Was heißt denn genau "Keine Rückmeldung"?

    Wenn du nur "keyman64" ohne weitere Argumente aufrufst, erwartet es deine Befehle auf der Standardeingabe, um sie nach dem Schließen derselben über USB an den Keyman zu senden. (Vielleicht ist "stdin" hier zu Programmierer-spezifisch ausgedrückt).

    Probier mal direkt auf der Kommandozeile (DOS-Prompt (Windows) oder "Terminal" unter Linux)

    keyman64 version

    Dabei darauf achten, dass der C64 im Direktmodus ist.

    Auf dem C64 sollte dann die Firmware-Version getippt werden.

    Auch mal ausprobieren:

    keyman64 type "hallo welt"

    Ich habe noch keine Conf drauf.

    Dann ist eine einfache Default-Configuration installiert. Drück mal "Pfeil-nach-Links" und T, dann sollte eine kleine Meldung erscheinen.

    PS: Nur um sicherzugehen: Windows oder Linux? Hast du vorher schon die 1.3 firmware erfolgreich im Einsatz gehabt? Sind (falls Windows) die USB-"Treiber" korrekt installiert (Stichwort Zadig)?

  • keine Rückmeldung vom Keyman64

    reading commands from stdin...

    wenn ich z.B.
    keyman64 status
    eingebe, schliesst sich das Keyman64 Fenster.

    Kann es sein, dass du einfach auf die keyman64.exe doppelklickst? Dann wird das tool ohne Argumente aufgerufen, windows merkt oha, ein Kommandozeilenprogramm, öffnet es in einem Dos-Konsolen-Fenster, das sich schließt, wenn das Programm beendet wird. In deinem Fall (bei Eingabe von "keyman64 status") bricht das Keyman64Programm (das auf Standardeingabe wartet, weil es keine Argumente bekomment hat) ab, weil "keyman64 status" keine gültige Syntax ist, und das Fenster schließt sich...

    Öffne mal eine "Eingabeaufforderung" (cmd.exe) und gib dort z.B. "keyman64 version" ein.

  • Hallo Henning

    ja, in der Tat dachte ich das Keyman64 eine Art Terminalfunktion inne hat :schande:

    Mein Fehler.

    Aber auch Cmd
    Keyman64 version
    bringt nur eine Leerzeile und erneuten Dos-prompt zur Anzeige

    Nutze WIN10

    Unterschiedliche Treiber über das Zadig-Tool, einer für Boot, einer für Standardmode installiert.

    Systemsteuerung\Geräte\USB zeigt den Keyman64 folgendermaßen:
    Bitte melde dich an, um diesen Anhang zu sehen.

    Achja, der Jumper steckt auf USB
    In den Cevi habe ich ihn noch nicht eingebaut, da ich erst sichergehen wollte das er funktioniert.

    Die 1.3er Firmware muss ich gestehen hatte ich nie getestet.

    +++ Jetzt bekomme ich Antwort +++

    Bitte melde dich an, um diesen Anhang zu sehen.

    Das "Minus" vor version fehlte.

    freu

    und Danke für die Hilfestellung.

    Gruß
    Mike

    8-Bit enthalten circa 150g reinen Alkohol und sind bei regelmäßigem Konsum nicht unbedenklich :drunk:

  • Ja, das ist nur die Versionsmeldung der keyman64.exe, die bei "keyman64 --version" ausgegeben wird.

    Der Keyman-Befehl "version" (der innerhalb des Keyman läuft und der z.B. auch auf eine Tastenkombination gelegt werden kann) gibt die Firmware-Version auch direkt auf dem C64-Bildschirm aus, indem er die Meldung einfach "eintippt". Also wird dieser Befehl am PC nichts zeigen können. Du kannst den Befehl aber trotzdem (Wie jeden anderen Keyman-Befehl) mit Hilfe der keyman64.exe remote über USB auf dem Keyman zur Ausführung bringen, in dem du am PC

    keyman64 version

    verwendest.

    Probier mal stattdessen

    keyman64 --identify

    Das fordert den Keyman auf, über USB die Firmware-Version zurückzugeben. Diese wird dann im Konsolenfenster am PC ausgegeben und sollte etwas wie

    "firmare 1.4 (Datum und Uhrzeit)"

    zeigen.

    Dann weißt du, dass zumindest das Aufrufen von Keyman-Internen Befehlen vom PC aus klappt. Alles weitere machst erst Sinn, wenn der Keyman im C64 eingebaut ist...

    Aber auch Cmd
    Keyman64 version
    bringt nur eine Leerzeile und erneuten Dos-prompt zur Anzeige

    Jedenfalls spricht das Fehlen einer Ausgabe dafür, das der Befehl erfolgreich beim Keyman angekommen ist (sonst gäbe es eine Fehlermeldung). Die Versionsinformation hat er jetzt aber "in die Luft" getippt, da an seiner "Tastatur" noch kein C64 angeschlossen ist.

  • Danke Henning

    Nachdem ich mich jetzt als Super DAU ge-autet habe, hier die Erfolgsmeldung:

    In den Cevi gesteckt
    [Pfeil-links] +T
    [Pfeil-links] +V

    Alles funktioniert.

    8-Bit enthalten circa 150g reinen Alkohol und sind bei regelmäßigem Konsum nicht unbedenklich :drunk:

  • ja, in der Tat dachte ich das Keyman64 eine Art Terminalfunktion inne hat

    Das ist aber auch mein Fehler, irgendwie.

    Ich habe schlicht nicht daran gedacht, was passiert, wenn man auf Windows auf die keyman64.exe doppelklickt...

    Die Tatsache, dass dort dann ein Konsolenfenster aufgeht, in der das Programm läuft, gepaart mit der (aus Unix-Sicht sinnvollen) Eigenschaft, bei Aufruf ohne Argumente Befehle von der Standardeingabe zu lesen, ist auf Windows nicht sehr glücklich.

    Ich sollte unter Windows wohl noch einen hilfreichen Hinweis für diesen Fall ausgeben. Es sollte sich ja festellen lassen, ob mein Parent-Process das nackte Konsolenfenster ist oder die cmd.exe oder eine andere interaktive shell. Vielleicht kann da ein Windows-Programmierer weiterhelfen?

  • Die Tatsache, dass dort dann ein Konsolenfenster aufgeht, in der das Programm läuft, gepaart mit der (aus Unix-Sicht sinnvollen) Eigenschaft, bei Aufruf ohne Argumente Befehle von der Standardeingabe zu lesen, ist auf Windows nicht sehr glücklich.

    Ich habe mir angewöhnt, bei Aufruf ohne Argumente die interne Hilfe auszugeben. Wenn man wirklich einen Lauf ohne Argumente braucht (z.B. Filterfunktion von stdin nach stdout), kann man das per "programmname --" erreichen.
    Aber im vorliegenden Fall würde das auch nicht viel bringen, da das Terminalfenster unter Windows ja sofort wieder verschwindet. Man könnte allerdings vor dem Programmende noch system("pause") aufrufen. ;)

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..