Jump to content

Photo

POKEY keyboard scanning, CTRL-SHIFT keyboard combos.


8 replies to this topic

#1 tschak909 ONLINE  

tschak909

    River Patroller

  • 2,408 posts
  • Location:USA

Posted Sun Jul 8, 2018 12:01 AM

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



#2 phaeron ONLINE  

phaeron

    River Patroller

  • 2,512 posts
  • Location:USA

Posted Sun Jul 8, 2018 12:45 PM

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.



#3 tschak909 ONLINE  

tschak909

    River Patroller

  • Topic Starter
  • 2,408 posts
  • Location:USA

Posted Sun Jul 8, 2018 1:09 PM

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



#4 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,673 posts
  • Location:Australia

Posted Sun Jul 8, 2018 4:38 PM

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 by Rybags, Sun Jul 8, 2018 4:39 PM.


#5 Kr0tki OFFLINE  

Kr0tki

    Stargunner

  • 1,113 posts
  • Location:Warszawa, Poland

Posted Sun Jul 8, 2018 7:48 PM

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 by Kr0tki, Sun Jul 8, 2018 7:52 PM.


#6 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,673 posts
  • Location:Australia

Posted Mon Jul 9, 2018 12:36 AM

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.



#7 phaeron ONLINE  

phaeron

    River Patroller

  • 2,512 posts
  • Location:USA

Posted Mon Jul 9, 2018 1:03 AM

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.



#8 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,673 posts
  • Location:Australia

Posted Mon Jul 9, 2018 1:07 AM

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?



#9 Kr0tki OFFLINE  

Kr0tki

    Stargunner

  • 1,113 posts
  • Location:Warszawa, Poland

Posted Mon Jul 9, 2018 8:42 AM

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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users