POKEY keyboard scanning, CTRL-SHIFT keyboard combos.

[tschak909]

If POKEY is used to directly scan the keyboard, can the CTRL-SHIFT keycodes (the 14 or so of them) that fall through the cracks be detected and read?

 

Or is this a case of an oops with the keyboard mux?

 

-Thom

[phaeron]

If you mean scan codes $C0-C7 and $D0-D7, no, bypassing the OS and going straight to POKEY isn't enough. The problem is that Ctrl and Shift are part of the keyboard matrix and on the same column on the Atari, so Ctrl+Shift+<key> is guaranteed to produce a fourth phantom key when the third key is on the same row as Ctrl or Shift. That phantom key then prevents POKEY from reporting a key down. There's no way that I know of to sense multiple keys down, and even if there were you couldn't distinguish Ctrl+Shift+L and Ctrl+Shift+V, for instance.

 

It's possible for a keyboard to have diodes to prevent this, but I haven't heard of an Atari keyboard immune to this problem.

[tschak909]

oh shit.. After looking at the schematic, that makes sense. *facepalm*

 

Ok, I guess it's using the START key as a modifier, then...

 

-Thom

[Rybags]

Shift + Ctrl + A generates $FF and falls through the cracks since that code is also the "no key" condition but can be detected in software.

 

Also not forgetting some OS ignored Ctrl combinations such as 0, 4-9 which some key processing programs use as function keys

Edited July 8, 2018 by Rybags

[Kr0tki]

There's no way that I know of to sense multiple keys down

Well, there kinda is a way, and I believe you are aware of it already - by disabling keyboard debounce (SKCTL's bit 0). In fact, in that mode POKEY detects only pressing multiple keys at once, with the restriction that only two "consecutive" keys are detected ("consecutive" in the sense of the order of POKEY keyboard scanning).

 

For example, try POKE 53775,2 and then press Q, W, I and Return simultaneously. Q and W are consecutive, which is detected by POKEY as pressing Q only, and I and Return are also consecutive, which is detected as pressing I only. The result is, POKEY behaves as if Q and I were being pressed alternatively at a rapid pace.

 

(The 5200's keypads work this way - POKEY is permanently set to non-debounce mode, and every key is wired to short two consecutive positions of the POKEY's keyboard matrix. This allows limited detection of multiple keypresses.)

 

Although the method is limited by the requirement of "consecutiveness", I wonder if there exists some way of avoiding it, by means of switching the debounce bit, or the keyboard scanning bit (SKCTL bit 1), rapidly, in a frequency related to the frequency of keyboard scanning (ie. once a scanline).

Edited July 9, 2018 by Kr0tki

[Rybags]

Possibly putting Pokey into INIT mode, or just changing SKCTL might be sufficient to restart the scan sequence, or maybe more desirbably alter the state machine in some way.

But whether that could be sufficient to detect mutliple keys?

 

A good starting point might be a custom kb IRQ that changes SKCTL setting for a scanline then back before returning.

[phaeron]

Toggling the keyboard scan enable will restart the scan sequence, but also resets the state machine. The most useful trick I can think of for this would be to truncate the keyboard scan to partially scan the keyboard more quickly (such as the arrow keys).

 

Toggling debounce on the fly allows detecting a specific pair of keys. The problem is that there isn't a way to know which key POKEY has latched for comparison, since it doesn't report a scan code until after the second check passes (if it did, we could just use that to do a raw scan). Precise timing would theoretically allow sweeping for the 8 pairs of hidden Ctrl+Shift+X key combinations. It's still impossible to tell the keys in the aliased pair apart due to the phantom key effect, and this would reduce the key scan to an unusably low rate. As such, I haven't found an actual useful hack for the debounce bit on the computer.

[Rybags]

How about coming out of Init state? Do we have a deterministic situation where we could know what key is scanned by some simple calcs based on # of scanlines elapsed?

[Kr0tki]

That won't help in case of key ghosting. Pressing three keys that spawn the fourth ghost key is electrically indistinguishable from pressing all four keys at once (regardless of which three keys of the four were pressed). You simply cannot differentiate the two cases on the hardware level.