Support for Recreated Spectrum Keyboard in game mode

[adrianlongland]

This keyboard is closest to feeling like on real hardware. In Qwerty Mode the Caps and Symbol Shift keys don't send any codes unless pressed with something else. This means you can't use those keys to play games in Qwerty Mode. Also in Qwerty mode keys can be dropped - not sure why. In game mode it sends a key code up/down for each button press, and a different code up/down for each button release. Response is good, and keys don't get dropped.

Added an option to enable in the menu. Once enabled, be careful not to press keys on standard keyboard as the key codes can leave spectrum keys reading pressed down. It's ok to press FN keys and cursors.

There are at least a couple of alternatives to implementing in keyboard.sv:

1. Implement on the linux side based on usb id - translating the keycodes to standard keyboard codes up/down. Would need an option (in mister.ini ? ) to enable the conversion because there is no way I know of knowing the keyboard is in game mode.
2. Provide code for a Arduino usb interface like the 2600 spinners - that would take the usb stream and do the mapping to standard keyboard codes. This would mean no changes to Mister code, but users need to make the hardware. Also more lag.
3. Provide code for a Arduino usb interface to connect to the internal ribbon cables. Should be possible to support both the original hardware spectrum ribbon cable, and the one inside the recreated keyboard. Minimal lag, same as 2600 interface.

[sorgelig]

Your original PR for keyboard tweaks looked reasonable (just needed swap for '/"). But your addition of "recreated keyboard" doesn't fit MiSTer project. It's ok you fork the core and do some incompatible modifications to fit into spectrum like case as a single core system. Just like Spectrum Next. But MiSTer is multi-core platform where input devices are shared for all cores. This is why MiSTer doesn't support cartridges or original floppy disk controllers. Such HW addons simply can't fit multi-core project.

[adrianlongland]

I will swap '/" in the first PR and resubmit.

The Recreated Keyboard can be used for other cores. In qwerty mode it can be used for any core as a standard keyboard eg. 486. It just has the issue of caps and symbol shift not generating key codes when pressed on their own, which makes those keys unavailable to games. Options 1-3 above would allow any core full access to the keys. All cores would see it as a standard keyboard with a limited number of keys. Is option 1 (linux side remap) something you would consider?

[sorgelig]

I didn't understand what option 1 is. It's basic keyboard protocol. That's how it works already.

[adrianlongland]

Option 1 would take the non-standard game mode key codes, and convert them to standard keyboard codes.

The keyboard has 2 modes:

Qwerty mode sends all the standard key codes, but the Caps Shift and Symbol Shift don't send a code unless they are pressed with something else. Also all the spectrum characters are sent as the equivalent standard key codes. eg. if you press Symbol Shift and P it will send Left Shift and '/". Not Ctrl and P. If you are trying to program in BASIC that makes some of the symbols inaccessible. Or playing my favorite game Lunar Jetman, you can't press Symbol Shift to pick up.

Game mode sends totally different key codes for each button down and button up. Why - I don't know. At least each key is independent. eg. You press 1 it sends "a down, a up", and when you release 1 it sends "b down, b up." Option 1 would allow the keyboard to work in game mode, so if it sees "a down" it sends "1 down", if it sees "b down" it sends "1 up".

Option 1 would make the Recreated Keyboard in game mode look like a standard qwerty keyboard to all cores, and with access to the Caps Shift and Symbol Shift. If you pressed Symbol Shift and P it would show up as Ctrl and P. The result would be a keyboard usable in any core, than behaves just like the original spectrum keyboard in the spectrum core.

[sorgelig]

This is already explained above - it's very specific to implementation of one keyboard. It doesn't fit MiSTer work. What you described fits to single core implementation with custom input devices.