For example, if I hold down an arrow key in VICE, the cursor moves at a rate of something like 15 positions per second. It doesn't matter exactly how much and I think it might vary between Commodore systems. Whereas in the X16 emulator, it moves at whatever your operating system is configured to.
The Windows Control Panel has about the same range as the PS/2 standard, peaking at 30Hz or so, so that's fine. It can be altered beyond this by tampering with the registry. macOS is in a similar boat, where you need to crack open the terminal to achieve repeats of 15ms and potentially faster. Linux is vast, but the GUI I have in GNOME 2 ranges from 10Hz to 111Hz (and allows repeating to be disabled completely).
The conclusion here is nerds can use faster repeat rates with the X16 emulator than is possible on the hardware itself, with PS/2 keyboards maxing at 30 characters per second when holding down a key, maybe 40 at a stretch.
This presents a problem for games, which often involve holding down a key for player movement etc. My understanding is the KERNAL polls the SMC for keyboard input once per VSYNC (more if it's multi-byte, i.e. extended keycode). So if you're sending keys more than just shy of 60 times a second, they all sort of get jammed in there and it takes a while for the buffer to get emptied again, resulting in a very poor gaming experience.
Developers can work around this by disabling the KERNAL's stuff and polling the SMC themselves, either a fixed number of times per second or until there are no further keys to be processed. But they shouldn't have to.
Given the limitations of PS/2 keyboards, I don't think it would be appropriate to patch the KERNAL for this, but it is an option. Instead, it would be better for the emulator to emulate a PS/2 keyboard (and mouse).
This would require the emulator handle the delay and repeating of keys itself, rather than relying on the host operating system to do so. Ideally it would detect commands sent to register $19 proceeding command byte $F3 to set that to different values, if that's how it works on the hardware, but this doesn't sound particularly easy to get right.
Potential use cases:
- Not having to worry about weirdos downloading the emulator to play your game, only for it to be unplayable.
- Send commands to the emulated PS/2 keyboard to reduce the amount of repeated keys it sends, giving games a few more CPU cycles to focus on more important things.
- Test setting Num/Caps/Scroll Lock LEDs for programs that handle their states itself or use them for novelty purposes (e.g. lives indicator).