USB Keyboard - slow response/dropped keypresses


Author Message
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10968
Posted: 07:45am 04 Jul 2025      

There are reports of slow response/dropped key-presses for the USB versions with a USB keyboard.
I would like to get to the bottom of this so if you are seeing this please post on this thread.

Please include details of exactly which version of the firmware you are using and complete option list. Also include precise information as to how the keyboard is wired and how the board is powered. Explain in exactly what circumstances you are seeing this issue. I can't see the problem which makes it difficult to track down.

My test protocol is to run my finger along the keys as fast as possible from Q to P
qwertyuiop and across the other rows as well.
I don't see an issue doing this either at the command prompt or in the editor.
If you can suggest a different test that doesn't involve a manual dexterity I may not possess then please suggest it.

General info:

At the moment there are three parameters related to the keyboard.
1: keyboard polling loop time - currently set to 20mSec - this would need to be changed in firmware
2: Repeat time for first keypress hold - defaults to 600mSec
3: Repeat time for subsequent hold - defaults to 150mSec

The latter two can be adjusted with OPTION KEYBOARD or OPTION KEYBOARD REPEAT

USB keyboards report a maximum of 6 simultaneous keypresses. MMBasic always takes the key at the top of the stack as the input which is the last key pressed. If two keys are pressed within 20mSec it is possible the first may be lost.

The current code on the PicoMite is a direct copy from the CMM2.

The issue of key-rollover also needs to be considered. USB keys are organised such that although up to 6 keys can be registered as pressed at the same time the scan built into the keyboard is not completely flexible so if two keys are in the same scan column or row then only one of them will be registered. The keyboard is typically organised so that physically adjacent keys are NOT in the same scan.

Is there an issue with some keyboards (German layout?) that means that letters that are often following each other are in the same scan group?

As previously stated, I'm happy to try and solve this issue but I need more than "it's slow, it's dropping keypresses" to help me do this. In particular, as I can't replicate, I will need someone who sees the issue to try out firmware versions with blind hacks until we get to an answer.