Fwd: [hatari-devel] Re: IKBD, max keys?

[Douglas Little <doug694@xxxxxxxxxxxxxx>]

[sorry, forgot to CC hatari list with my reply...]

Hi!

do you mean 2 by using some TOS functions or by reading directly fffc02 ?

This is directly catching packets fffc02 using a custom interrupt handler (although, the details of handler is irrelevant in this scenario).

 

If this by reading fffc02, I had the feeling you could have as many simultaneous keys, as long as you keep a pressed/released state for each key yourself. But I never really tried to see if the IKBD sends a release event when too many keys are down.

I am already catching/tracking keypress/release information in a map, and it is this map which tells me that information is being lost with several keys held together.

The process I use:

- catch all IKBD interrupt events

- filter keyboard events from midi/mouse/joystick (and 6301 error states - although no 6301 error states are noticed)

- keycodes recorded in a circular, interrupt-safe queue (which I know for certain never overruns - I have tests for this sort of thing too)

- queue processed by background code

  - keycodes with bit #7 set treated as 'key up' / otherwise 'key down'

  - flag updated in map for any change in state for that key (down = true, up = false)

  - changes to map only allowed if the value *changes*, otherwise *error* signal and 'stuck keys' (I do see this error occurring on a real machine - but never on Hatari, which I think is telling)

  - for any change to up/down state for a key, 'simultaneous' counter incremented/decremented, and a max value tracked

In Hatari the max value seems to be 4 for alphanumeric-class keys, +2 for control/shift-class keys, +2 for arrow keys. So that's actually 8. (There may be other classes of key I didn't try combinations for).

On a real Falcon, the limit is 2 for alphanumeric-class keys, +1 for control/shift-class keys, +1 for arrow-class keys - making a limit of 4. (The limit for the control/arrow classes of key rises to 2 if they are used alone, and there may be more complicated patterns I didn't check).

It's also notable that the *error* case on a real Falcon occurs only when 2 or more classes of key are used together. To me this indicates a bug in the 6301 code.

These are my findings so far, and they appear to be reliable. They also turn out to be the cause of 'stray keypresses' bringing up the menu/console in my game project, which I originally thought was a bug in my code. Apparently not - it's spurious keycodes returned from the IKBD when too many key types are held together.

 

Keys are handled by SDL, so it will certainly varies depending on the OS. As long as the OS allows more keys to be pressed than a real Atari, then it's not too big a problem, the opposite would be limiting though.

Yes I understand. I am not really expecting this to be 'fixed' but more curious about existing knowledge/solutions w.r.t. this problem and whether Hatari imposed it's own limits or not. Since this does not seem to be the case, I'll probably need to find answers some other way.

Doug.