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

[ Thread Index | Date Index | More Archives ]


Could you describe a scenario where you get this error or stuck keys results on real HW ?

The problem is rather erratic so I didn't determine the exact key combination which causes it - but I will try to find a repeatable pattern and report.

I was able to determine that the problem only happens when more than one 'class' of key is held. e.g. it does not happen when holding down many alphanumeric keys - it must be a sequence of CTRL+SHIFT+ARROW keys which causes it, perhaps also requiring alphanumeric held.

(I saw one other, related problem with spurious keycodes which I can't account for, but I need to gather a bit more info before I can say much about that...)
What do you mean by "error signal" ? An error packet sent by the hd6301 ?

I meant my own code issues an error signal if the map detects a conflict - e.g. if a key 'up' event is received for a key that is already known to be 'up' (or a down event, for a key already down). This is how I detect the lost events.

This problem does not happen with Hatari - even when exhausting the simultaneous key limit - there is never a conflict in the map.... no key events get 'lost'. The up/down events are always 1:1.
Note that the HD6301 only has 16 bytes in its circular buffer to report keys to the host cpu through the acia. I would need to have a look at the HD6301 ROM to see how it handles simultaneous keys, but the very small amount of available ram (less than 128 bytes) is certainly the cause of this limiting behaviour.

That is almost certainly the reason. However it's not very good news for me in this task :)

I was actually hoping the Falcon is faulty and that it's not a 6301 problem  - because I can still work with a key limit of 2 or 4 - but working with lost key up/down events (or spurious keycodes) would be a nightmare.


Mail converted by MHonArc 2.6.19+