Keyboard repeat delay

[SlithyMatt]

I'm trying to figure out how keyboard repeat delay is going to work on the hardware, and to try to tune my emulation to match that. My main computer enforces a repeat delay of 500 ms, but leaves it configurable, so I can bring it way down (hooray, Linux!), if I plan on being very sprightly in my typing. Looking at the Kernal code, there is a delay counter that gets initialized with 10, so is that in 60Hz ticks? In other words, if I bring my host keyboard repeat delay down to 166, will that let me properly emulate the PS/2 keyboard behavior? What I did not see was separate handling for the first repeat delay and subsequent times, like Linux lets you configure. If I were to hold down a letter key within my desktop environment, I'll get the first character going through more or less immediately, it will be repeated the first time 500 ms later, then 20 ms later for each subsequent repeat, if I stay with the default settings. What would I expect with either of the PS/2 keyboards? Will the pack-in keyboard and the WASD keyboard be different in this respect? I confess I know very little about how PS/2 keyboard protocols work, or even USB keyboards, for that matter.

[StephenHorn]

Heh, conveniently Ben Eater has just covered PS/2 keyboards. Turns out the key repeat comes from the keyboard itself.

 

[Stefan]

Hi @SlithyMatt

The keyboard interface was discussed recently in these threads:

https://www.commanderx16.com/forum/index.php?/topic/909-how-does-ps2-keyboard-interface-work/

https://www.commanderx16.com/forum/index.php?/topic/1156-are-ps2-host-to-device-commands-supported-in-the-emulator/

After reading the Kernal source for some time, I have come to the following conclusions:

• 
  The Kernal doesn't control key repeat in any way
  


• 
  PS/2 keyboards have key repeat built in
  


• 
  In order to control the repeat rate, you need to send a command from the host (=X16) to the keyboard
  


• 
  There is no support in the Kernal for sending commands to the keyboard, but you could implement it yourself. To test this you would need the real hardware, as the emulator doesn't seem to react to such commands.
  

The counter initialized to 10 you refer to might by the one at kernal/drivers/x16/ps2.s line 56.

If this is the point in the code you mean, it is actually initialized to 10 * 8 = 80. As far as I understand, the Kernal in this loop repeatedly polls the PS/2 lines looking for a start condition set by the keyboard. If no start condition is found before the end of the loop, the Kernal disables the PS/2 communication until next VBLANK interrupt. And the Kernal reads only one scan code during each VBLANK. One scan code may consist of several bytes though. 

I tried to manually calculate the time the Kernal spends in that loop waiting for a start condition, and came to 110 us. I've read that a PS/2 device should not start communication until 50 us after the clock line is released by the host, so 110 us seems to be a reasonable number.

[Stefan]

This page has great info on the low level workings of the PS/2 interface:

https://www.avrfreaks.net/sites/default/files/PS2 Keyboard.pdf

There are only a few generally supported host to device commands. Most of them are not very useful. The two most interesting commands might be:

• 
  0xF3 <byte value>: Set key repeat rate and delay
  


• 
  0xED <byte value>: Turn on/off Num Lock, Caps Lock and Scroll Lock LEDs
  

[SlithyMatt]

5 hours ago, Stefan said:

0xF3 <byte value>: Set key repeat rate and delay

If the means of sending this is consistent, then it would be very useful for apps that depend on holding keys down for a period.