I'd suspect you'd want a faster refresh rate than that; you'd want to see each LED refreshed fifty or sixty times a second minimum, so around four hundred ticks a second from an IRQ. ...
Gotcha. OK, then keeping it powers of two, ~512 ticks per second is roughly 2ms/tick, on a 16:1 press/unpress ratio and 5ms steady state to the cap in complete key press state, then the read key coming first in the IRQ sequence before bumping the LED column would get it read on the second full tick after it is pressed, delayed by one or two if a bounce hits right in the middle of the read key strobe.
And of course skip the key read part if current LED is 5-8.
The second full key read in would be 9-16 ticks after first substantial attack, so ~18ms-32ms. A long enough bounce in the third full key read to cross the hysteresis starts to be multiple standard deviations out in the stochastic process, but one might say key / unpressed / same key should not count as a release, since the two key reads would be 32ms apart, and these are tac switches, so UIAM, an actual double press isn't going to complete so fast.
Once released, if it's 80ms for the cap to be in full release state, and hysteresis delays the rise of the NoPress signal on data7 until around 45ms-50ms into the release, two consecutive release reads on the previously detected column or a release read, the previous key, and another release seems like it ought to get pretty good bounce rejection, which is
also key / unpressed / same key doesn't count as a release.
So there'd be four states ... multiple releases have been read, the last read was an initial key read, the last read was a release following a key read, and the last read was a repeated key that follows a single release.
Four states is nice because the state can be stored in bits 7 and 6 and read with BIT. It can be stored in a single byte with the "previous key" by having the "no key pressed" value as bit5:
bit0-bit5: bottom six bits of last key registered if key pressed
bit0-bi5: %xx100000 if last key registered is unpressed
bit6-bit7: debounce state 0-3.
With cap + hysteresis debounce on all rows, it might be OK to treat it as a low noise environment and a key with d7 in Press state that different from the most recent key read is treated as a new key, so goes straight into first read of a key following release state.
~~~~~~~~~~
{Side points:
1. Do you have a preference for the break point monitor to use as a reference for the proper kernel? The IRQ routine will disentangle BRK's from IRQ's so it will want some code to jump to if it is actually a BRK. It can still be a minimalist one, as it can be written to use a vector in the system space in the zp instead if the vector is non-zero.
2. Also, caps and suspenders, a routine to write the DROM code into the EEPROM as the first test is not strictly limited to 128 bytes anymore, so it could be written to write a proper decrement address routine just below $FF80 and patch the DROM routine for the backspace function to the proper decrement address routine ... with the symbol table moved to the top of the DROM, between the to_leds subroutine and the symbol table taking over 32 bytes, small patches in the $FF60-$FF7F range are guaranteed to be able to reach the loop_90 code with a branch.}
