DB9 Keyboard?

[+Karl G]

So, I'm not much of a "hardware guy", but I was wondering if it would be feasible to make a full keyboard that could work as a DB9 controller? An Atari joystick has 4 directions and one fire button. Combining those 5 possibilities would give 31 possible combinations, which would cover all the letters, space, a couple of punctuation marks, and perhaps one key for a "shift lock" to access numbers and other characters. Does such a beast exist for any system that used these connectors, or has anyone made a homebrew keyboard controller like this, or is there a technical reason why this method wouldn't be feasible?

[+Gemintronic]

Probably going to have to jury rig a PS/2 keyboard, Arduino (or Teensy) and the DB9 end of a sacrificial genesis joystick.  Plus write your own code to translate what keyboard codes the micro-controller sees and the 2600 joystick port can handle.

 

Vaguely related links:

https://github.com/GeoffLedak/Blue-Pill-Sega-Keyboard-Adapter

https://little-scale.blogspot.com/2013/03/how-to-make-atari-2600-midi-music.html

[flickertail]

I'm curious as to your goal. Using a $4 Raspberry PI Pico and some additional chips, it's possible to program anything you want as long as your cart program supports it.

 

For instance, I created an interface for SNES controllers for the 2600/7800.

If you add the 5/9 pins into the mix, can use a Pico board, two AD5242 digital potentiometer chips, and two ADG715 switch chips to the mix (see my monstrosity of a prototype in the attached image), you can pretty much have a much larger selection of keys. You could even mimic the use of 2 x 12 button keypads for a total of 144 keys (or 81 keys plus 2 I/O pins for communicating with the Pico) not just the 31 possible combinations you discussed above.

 

Using the Pico C++ SDK, you can power the Pico off controller port power (as in the example I posted above) and use the Pico as a USB host for a low-power USB keyboard.

 

You just have to write a cart to support whatever input you are sending the Atari.

 

 

[+Karl G]

Well, as I've said, I'm not much of a hardware guy, so I don't have a lot of confidence in my ability to pull something like that off myself. Writing the software to support it would be the easy part for me.

 

Being able to have a full(ish) keyboard would allow e.g. the ability to create an interactive BASIC on the Atari 7800, or create editors for the 2600/7800 that could access the SaveKey. So, mostly silly stuff. 

 

As I count 31 combinations of inputs, I don't see why something like this wouldn't be possible, but I'm surprised that in the Atari's long life that no one has produced one for some specialized application, which made me wonder if my reasoning was correct on the feasibility of such a keyboard.

[flickertail]

35 minutes ago, Karl G said:

As I count 31 combinations of inputs, I don't see why something like this wouldn't be possible, but I'm surprised that in the Atari's long life that no one has produced one for some specialized application, which made me wonder if my reasoning was correct on the feasibility of such a keyboard.

Well, my friend David and I are eventually going to turn the monstrosity into a dev board for people to try. But I've been saying that for a while, and I'm guessing people here are tired of hearing me say that without showing some results... but maybe one day...

 

...that said, the Pico uses the C++ Tiny USB library to support keyboard and mouse host control. As long as the 7 pins can push enough power to power the keyboard, it's totally doable, unless their is more latency Pico and the keyboard than I would expect.

 

And depending on power, you might even be able to connect an I2C SD card reader to the Pico as well. But power requirements is a level above my capabilities. I rely on David to tell me when I'm trying to push features too far.

 

Anyway, I'm rambling... but I would expect that if you had a fancy enough cart, then you could use 3 of the 4 rows on each 2600 keypad to give you 81 keyboard key options plus 2 I/O pins for 2600<->Pico comm, and possibly a storage option as well. Using the Pico C++ SDK, programmatically there shouldn't be any reason why you couldn't do it.

 

I should post my monstrosity designs to my blog. However, as I am not an electronics expert, they aren't in a format that anyone other than myself and David can understand. However, I will post my Pico C++ code for my SNES controller. (I tried using Python for Pico, but it was too slow).

 

Oh, but to answer your original question. Yes, someone has tried it before... I don't remember where I read it (probably on Atari Age - 15yrs ago before my divorce and the original forum posts were lost), and I don't remember the details, but there was a company in the 80s that tried to build a keyboard add-on for the 2600.

 

As an aside, I do all my monstrosity dev using my 7800 so I run custom test code using my Harmony Cart.

[flickertail]

25 minutes ago, flickertail said:

I should post my monstrosity designs to my blog. However, as I am not an electronics expert, they aren't in a format that anyone other than myself and David can understand. However, I will post my Pico C++ code for my SNES controller. (I tried using Python for Pico, but it was too slow).

If interested, I posted my Pico code.

[brain]

Back in the day, I did this for the C64, but the idea is universal  I defined enough to do a 10 key keypad but tying each pad to groun and to a bank of diodes that forced certain lines low.  Thus, each keypress would register a number from 0 to 31, as you note.

 

The issue was "rollover" and "phantom keys".  If, for instance, A was 8 and S was 4 and T was 12, if you rolled your finger from A to S and thus there would be a time when both were depressed, you would get ATS, not AS.  So, I think the best way to do this now would be to implement a keyscanner on an arduino/pico/choose your poison and then output the 5 bit code at a certain rate, with spacing.  So, if you knew the joystick read routine was done 60 times a sec, you would do A <none> S <none> and hold each state for 1/60th of a second, thus ensuring each key got registered correctly.  The downside is that the most keys you can "see" at the joyport would be scanning frequency/2

 

Jim

[+ZeroPage Homebrew]

If you're involving a Raspberry Pi or equivalent you could have the keyboard send an output sequence for each key press. This way you can have as many keys on the keyboard as you like (plus shift, control, alt, function keys etc.) and the program on the console would know what key/key combo corresponds to that sequence.

 

For example:

The letter A could be L L L L L B

The letter B could be L L L L U B

The letter C could be L L L L R B

The letter D could be L L L L D B

etc.

 

The B = button at the end of the sequence tells the receiving program that they've encountered the end of the sequence and that a new letter is coming next.

 

The string could be extended to accommodate as many keys or key combos as needed. This way you could plug ANY USB keyboard into the mini computer and then have the sequence output on a female DB9. Externalizing the keyboard from the equation saves massively on cost so really the only parts you need are.

• Raspberry Pi
• Female DB9 + wiring
• Enclosure

This could be INCREDIBLE for the 2600 PlusCart for chatting online, for text adventures or... RPGs or just about any game that requires a lot of different keyboard inputs and work for both the 2600 and 7800!

 

- James

 

[Thomas Jentzsch]

7 hours ago, ZeroPage Homebrew said:

This could be INCREDIBLE for the 2600 PlusCart for chatting online, for text adventures or... RPGs or just about any game that requires a lot of different keyboard inputs and work for both the 2600 and 7800!

Instead of a keyboard, you could also use a joystick and display the resulting keys/groups for each direction. Should be quite simple to use. With just three directions you can input 4^3 = 64 different chars.

Start:
     A..P
      |
q..! -+- Q..9
      |
     a..p

Then, after e.g. pressing UP:
     A..D
      |
M..P -+- E..H
      |
     I..L

Then, after e.g. pressing LEFT:
      M
      |
   P -+- N
      |
      O

So e.g. UP, LEFT, DOWN results into O

 

Alternatively one could define shorter paths for more frequent chars (e.g. E or T) and longer paths for less frequent ones (e.g. Q or Z). But that might become a bit irritating to use.

[+Karl G]

11 hours ago, ZeroPage Homebrew said:

If you're involving a Raspberry Pi or equivalent you could have the keyboard send an output sequence for each key press. This way you can have as many keys on the keyboard as you like (plus shift, control, alt, function keys etc.) and the program on the console would know what key/key combo corresponds to that sequence.

In this case, how do you imagine synchronizing the sending of the sequence by the Pi with receiving it on the Atari? It seems like you would need to have it be bi-directional so you could send an acknowledgement bit after each bit in the sequence. I certainly follow your reasoning about the value of a solution using widely-available and cheap hardware, though.

[+Karl G]

4 hours ago, Thomas Jentzsch said:

Instead of a keyboard, you could also use a joystick and display the resulting keys/groups for each direction. Should be quite simple to use. With just three directions you can input 4^3 = 64 different chars.

There's certainly something to be said for a solution that can use the hardware everyone has, especially to develop the software side in the meantime. It's kind of reminiscent of texting on an old flip phone.  

[+ZeroPage Homebrew]

1 hour ago, Karl G said:

In this case, how do you imagine synchronizing the sending of the sequence by the Pi with receiving it on the Atari?

I imagine the console would be in a state where it would always be listening for input on say, the second joystick port. The synchronization would come into place when a specific key sequence would be over with the 'red button' line being activated, kind of like how Morse code letters are separated by a brief pause. I'm not sure how robust the input of the DB9 is, but I've never seen a game interpret my joystick movements incorrectly on the 2600 so I imagine if the console is working correctly there shouldn't be an error in transmission since a human typing on a keyboard is a very slow input.

 

You could also slow down the transmission of the signals from the RPi to the joystick input as much as needed AND also introduce error correction into the sequence just in case there's a doubt about the input. Also, I really don't think it's necessary, but if need be, you could have two way communication like the Savekey/Atarivox does for confirmation of key presses.

 

All of this is just theory on my part as I'm far from knowledgeable in signal timings but it seems like it's EXTREMELY doable and somebody knowledgeable in coding for an RPi and the 2600 could bang this out on a weekend.

 

- James

[+Gemintronic]

This guy has been flogging his show and tell videos for 2600 console conversions

https://www.youtube.com/watch?v=EgE_EKp0-gA

 

The meaty part here (I think) is finding out if he'll share any insight into his Arduino code to talk to 2600 joysticks.  He has another video making a wireless connection.

[emerson]

I used a PIC microcontroller to interface both PS/2 keyboard and mouse with the NES. I was attempting a Family Basic keyboard replacement and while I had some timing issues with Basic itself reading my circuit my own homebrew code worked perfectly fine. One day I will rewrite my code in assembly and get it working correctly with Basic.

 

PS/2 devices will buffer data if you hold the clock line low which allows you to both control when the device is read and/or halt reading the device for whatever reason. PS/2 devices provide their own clock signals to the master device so you have to monitor the clock line and read the data line when appropriate. PS/2 devices can also be programmed to operate in a specific mode which is beneficial as they do not all default to the same mode on power up.

 

My approach to a 2600 keyboard would utilize a PIC and an SPI style protocol to transfer data to the console. The PIC reads and buffers keyboard data until the 2600 is ready to receive it. When the 2600 is ready for data it sets a ready flag on the joystick port. When the PIC sees this ready flag it waits until the keyboard is finished sending data, halts keyboard transmission, and clocks the buffered keyboard data into the 2600. Once all the data is sent the PIC would release the keyboard and read in any buffered data from it. A total of 3 I/O lines would be required from the joystick port. I am unsure of the max current of the 2600 joystick port and there is conflicting data on the max current of a PS/2 device. According to my research it's either 100mA or 275mA. This may be respective to 6-pin mini DIN and 5-pin standard DIN keyboards but that is just a guess.

 

Edit: Another option might be to simply use a serial to parallel shift register and utilize both joystick ports as a parallel bus to read the data into the console. The cable would look like a stethoscope.

Edited November 12, 2021 by emerson

[Stephen Moss]

On 11/11/2021 at 8:13 PM, Karl G said:

As I count 31 combinations of inputs, I don't see why something like this wouldn't be possible, but I'm surprised that in the Atari's long life that no one has produced one for some specialized application, which made me wonder if my reasoning was correct on the feasibility of such a keyboard.

Keyboard usually use a Row, Column addressing system to read all the keys, although difficult to do it is not impossible, you might first want to consider how the Keyboard controllers for the BASIC programming Cart operate.

 

However, if you are using an existing PC keyboard I believe they usually have a device in them that does that, which uses a look up table to output the appropriate ASCII character code (8bit), so your console software would have be able to read and interpret that, the question then become do you send the 8bits as two nibbles to one controller port or do you send all 8 bits (4 to each controller port), co and combine them in you software then lookup the applicable character for the ASCII code.  

As others have stated/alluded to the issue is going to be one of synchronisation between the transmitter (keyboard) and the receiver (console) so that either the transmitter is not sending data to fast for the console software to read or to slow that the console reads that same data twice in which case some kind of intermediate buffer would be require to store the keyboard data until it can be read. The issue there is if someone is typing reasonable quickly and you cannot read the key data fast enough, two issues arise..

1) The user will start noticing a massive lag between what they type and what appears on screen and.

2) Eventually you will fill the buffer and as a result miss keypresses made.

 

The above is the likely reason as to why someone has not produced such a thing (more trouble than its worth), along with the fact likely demand for such a thing would be too low to spend time on it unless you personally have a really desperate, can't like without it need to have one. And why the existing keyboard for the VCS operate as they do.