Multiple simultaneous keypresses on Keyboard Controllers

[+x=usr(1536)]

Quick question as mine are buried right now: are the keyboard controllers (or Video Touch Pad / Kids' Controller) able to register multiple simultaneous keypresses?  We're talking about four at a maximum.

 

My recollection is that they aren't, but I'm not sure if I should trust my memory on this one or not.

[+Stephen Moss]

It really depends on how the system/game software was written to read them, but generally Keyboard controllers and any other controller that uses a Row Column addressing system should register multiple simultaneous presses if the buttons are on the same column.

So for a Keypad controller arranged as follows...

  

Row 1 - 1 2 3 

Row 2 - 4 5 6

Row 3 - 7 8 9

Row 4 - * 0 # 

 

When Colum 1 (buttons 1 ,4 ,7 & *) is pulled low, when any of those button are pressed the corresponding Row output will be pulled low through the respective button. Therefore as generally all the Row outputs read simultaneously rather than individually if more than one of them is pressed simultaneous they will be read simultaneously. But only one Column is active at a time so you could not read 4, 5, & 6 simultaneously, because they are on different columns.

 

That said it also depends on your definition of simultaneously, if you read all three columns into a Word variable and then examine the data, rather than read a column and immediately process the data before reading and processing the next column, then from a certain point of view it could then be said that they could all be pressed simultaneously because the data for each column has been collated into a single entity before processing. 

[+x=usr(1536)]

2 hours ago, Stephen Moss said:

It really depends on how the system/game software was written to read them, but generally Keyboard controllers and any other controller that uses a Row Column addressing system should register multiple simultaneous presses if the buttons are on the same column.

Agreed - they should.  However, I just can't recall specifics for this particular controller, and for some reason have it in my mind that they don't.

2 hours ago, Stephen Moss said:

So for a Keypad controller arranged as follows...

  

Row 1 - 1 2 3 

Row 2 - 4 5 6

Row 3 - 7 8 9

Row 4 - * 0 # 

 

When Colum 1 (buttons 1 ,4 ,7 & *) is pulled low, when any of those button are pressed the corresponding Row output will be pulled low through the respective button. Therefore as generally all the Row outputs read simultaneously rather than individually if more than one of them is pressed simultaneous they will be read simultaneously. But only one Column is active at a time so you could not read 4, 5, & 6 simultaneously, because they are on different columns.

Understood.  It's not dissimilar to how touch-tone telephones implemented their keypads - or the 5200 controller, for that matter.

2 hours ago, Stephen Moss said:

That said it also depends on your definition of simultaneously, if you read all three columns into a Word variable and then examine the data, rather than read a column and immediately process the data before reading and processing the next column, then from a certain point of view it could then be said that they could all be pressed simultaneously because the data for each column has been collated into a single entity before processing. 

'Simultaneously' in this case meaning 'multiple keys held down at the same time and able to be individually-discerned while in that state'.

 

Where this is springing from is the realisation a few days ago that while the controller presents 12 keys in a 3x4 matrix to the user, the matrix is actually 4x4 in size.  This would allow for 16 keys (or switches) on a single port, which are enough inputs to theoretically allow for three joysticks - each with its own fire button - on a single physical port.  It would also allow for multi-button joysticks, though with a reduction in the overall number of joysticks that could be attached to a given port.

 

Granted, any software making use of this capability would require keyboard controller support, and the joystick(s) would have to each be implemented as a subset of the keyboard controller's matrix.  I'm not even sure that the joystick port could be polled fast enough to read the states of each stick in a way that would be useful for fast-action games.  In no way am I suggesting that this is necessarily a practical approach, but as an off-the-shelf way of handling multi-button or twin-stick games it might be workable, at least in theory.

[alex_79]

3 minutes ago, x=usr(1536) said:

Where this is springing from is the realisation a few days ago that while the controller presents 12 keys in a 3x4 matrix to the user, the matrix is actually 4x4 in size.

 

The matrix is 3x4. The columns are connected to pin 5,6 and 9 of the controller port (TIA inputs for paddles and joystick button), while the rows are connected to pins 1,2,3 and 4 (RIOT I/O). The only two pins left are 7 and 8, which are power and ground. There isn't an additional I/O line to increase the size of the matrix.

 

Also, multiple key pressed at the same time can cause "ghost" key press to be detected, or prevent some of the key to be detected, because of interactions between the rows and columns.

 

 

[+x=usr(1536)]

33 minutes ago, alex_79 said:

The matrix is 3x4. The columns are connected to pin 5,6 and 9 of the controller port (TIA inputs for paddles and joystick button), while the rows are connected to pins 1,2,3 and 4 (RIOT I/O). The only two pins left are 7 and 8, which are power and ground. There isn't an additional I/O line to increase the size of the matrix.

Ah, got it.  Appreciate the clarification.

33 minutes ago, alex_79 said:

Also, multiple key pressed at the same time can cause "ghost" key press to be detected, or prevent some of the key to be detected, because of interactions between the rows and columns.

Yep, this is what I was thinking of, but not remembering.

[BigO]

(Aside: The keypad matrix on the 5200 is 4x4, supporting the start, pause, reset or whatever those buttons were titled with one matrix position not implemented. That may be how the 4x4 structure got into your head.)

[+x=usr(1536)]

1 hour ago, BigO said:

(Aside: The keypad matrix on the 5200 is 4x4, supporting the start, pause, reset or whatever those buttons were titled with one matrix position not implemented. That may be how the 4x4 structure got into your head.)

That and running across PCB photos of the keypad controller.  I'm pretty positive that the two managed to munge themselves together after that point.

[+Stephen Moss]

3 hours ago, alex_79 said:

The matrix is 3x4. The columns are connected to pin 5,6 and 9 of the controller port (TIA inputs for paddles and joystick button), while the rows are connected to pins 1,2,3 and 4 (RIOT I/O). The only two pins left are 7 and 8, which are power and ground. There isn't an additional I/O line to increase the size of the matrix.

I was thinking that, but given that some kind of adaptor units with 4 sets of Joystick ports would need to be built there would probably be room inside for additional components.

Therefore Joystick port pins 5 & 9 could be used to select the output of a 1 (GND) to 8 multiplexer so you could select up to 4 columns with just the two output (00, 01, 10 & 11) thereby freeing up pin 6 for the Fire button input so you effectively have a 4 x 5 matrix button inputs.

The fire buttons would be a little tricky though but I would think wired ORing then using didoes to pin 6 should work, if your want to view them more as a large keyboard.

 

Personally, I would still use pins 5 & 9 with a multiplexer to select which Joystick output is being read, but the multiplexer output would instead be connected to the OE pins of Octal tri-state line driver (i.e. 74HC244).

Each joystick output would connect to the input pins of its own line driver, the output of the line drivers would be connected together on a 5 line bus (L, R, U, D & Fire).

Joystick port pins 5 & 9 select which drivers output is active (other will be in tri-state mode) and thus which joysticks output is placed on the bus, which can then be read as a normal joystick. It is effectively the same thing as above but a more robust way of doing it.