2600 Building my own keyboard controller (need help)

[dustfilledhobo]

I am attempting to build my own keyboard controllers for the 2600, but I want to add potentiometer-adjustable turbo buttons to the basic design using 555 timers (12 separate chips per controller so I can adjust the speed of each button differently). My question is, will I need to have a separate power supply to draw enough current to power two controllers (totaling 24 555-timers)? Or will I be just fine using the power from the controller ports?

 

Thanks in advance for any help you can give me, even if you only have information about the 555 current consumption or the 2600's current output.

 

Dusty

Edited March 24, 2009 by dustfilledhobo

[GroovyBee]

For something like this I'd use a microcontroller and a rotary encoder.

 

To set it up you'd do :-

 

User - Hold the key down to adjust.

Micro - Debounce and detect the key down.

Micro - Look up the start rate value for the key from EEPROM.

User - Rotate encoder shaft left/right.

Micro - Sense the number of pulses from the encoder (and direction) and adjust the rate.

Micro - Use the rate to control the frequency of a PWM output.

User - Release key.

Micro - Debounce and detect the key up.

Micro - Store new rate in EEPROM.

 

Keeps it all digital (which is always a good thing ). The current consumption would be pretty low if interrupts are used to detect the encoder's pulses and the micro spends most of its time asleep (in a low current mode).

[BigO]

Just some thoughts:

 

The game software has to scan the keypad matrix. This scanning rate is limited by whatever else the software needs to be doing at the time (and hardware speed).

 

If you're attempting to read and trigger a single firing event per pulse or interpret the pulse rate as a firing frequency, you're going to have to have a fairly high matrix scanning rate to catch what amount to a bunch of button presses in a short amount of time in order not to miss pulses. The problem gets worse as the "turbo" rate increases. Admittedly, I have no idea what sort of pulse rates you're considering. If you're talking about simulating the speed at which a human might repeatedly press the buttons, it might not be an issue.

 

If you see the way the matrix scanning process works, you might find a way to do this with a lot fewer 555's than you're expecting. Or, the job might be more complex than you're expecting. I kinda think you'll find both to be true.

 

In addition to getting a firm grasp on the matrix keyboard scanning process, you might find it informative to read about coding for the driving controller. It has similar challenges with regards to needing to capture every change in state on an input line.

 

A complicating factor: the 2600 keypad uses the paddle input lines as part of the key reading routine. These lines have to charge capacitors which may slow down the polling rate you can achieve on those lines.

 

I have thought about doing a similar thing on a much smaller scale as a throttle for driving games. You can somewhat regulate speed in those games by repeatedly pressing and releasing the "fire" button rather than holding it on constantly. If you want a smaller scale application to work out the pulse generation electronics, you might do a single channel implementation as a speed control, modulating the "fire" button on the driving control or paddle controller.

Edited March 24, 2009 by BigO

[roland p]

Which game needs 12 turbo buttons?

[dustfilledhobo]

Which game needs 12 turbo buttons?

 

I read somewhere that sega genesis turbo controllers have been used with the 2600's synthcart, but you are limited i which sounds you can access using the turbo buttons. So, I though I would build my own controller to access all 24 sounds while also being able to control the speed of the turbo.

 

Also, thanks for the other replies. If anyone else has something they would like to add please do.

 

Also, GroovyBee, I have never used a microcontroller or rotary encoder. Could you draw me a schematic or block diagram to illustrate how to hook all of this up? Thanks in advance.

 

Dusty

[supercat]

I read somewhere that sega genesis turbo controllers have been used with the 2600's synthcart, but you are limited i which sounds you can access using the turbo buttons. So, I though I would build my own controller to access all 24 sounds while also being able to control the speed of the turbo.

 

I don't see much point in trying to build a crazy complicated piece of electronics for that purpose. If you're seeking to use the 2600 as a performance musical instrument it would be better to figure out what exactly you want to do and have someone write some suitable software, probably in bBasic. The keypads are not designed for rapid operation, and trying to pulse them quickly would probably not yield the results you're after.

[GroovyBee]

Also, GroovyBee, I have never used a microcontroller or rotary encoder. Could you draw me a schematic or block diagram to illustrate how to hook all of this up? Thanks in advance.

 

Erm.. You need to choose a micro first. How good are your soldering skills? If they are top notch then you can go for SOICs or QFPs. Otherwise you are limited to .1" pitch devices (or have a look at Olimex, Sparkfun etc. for some ready built .1" pitch microcontroller modules). Do you have any software experience? Something like this is probably best done in assembler.

[dustfilledhobo]

Also, GroovyBee, I have never used a microcontroller or rotary encoder. Could you draw me a schematic or block diagram to illustrate how to hook all of this up? Thanks in advance.

 

Erm.. You need to choose a micro first. How good are your soldering skills? If they are top notch then you can go for SOICs or QFPs. Otherwise you are limited to .1" pitch devices (or have a look at Olimex, Sparkfun etc. for some ready built .1" pitch microcontroller modules). Do you have any software experience? Something like this is probably best done in assembler.

 

My soldering skills are good, and my software experience is minimal. I feel much more comfortable with hardware.

 

 

And supercat, I don't know anything about the 2600, but haven't people been successful in modding 2600 controllers to have auto-fire buttons (I could be wrong, so correct me if I am)? Shouldn't this same idea work for the keypad controller? Once again, I don't know, these are genuine questions.

[GroovyBee]

My soldering skills are good, and my software experience is minimal. I feel much more comfortable with hardware.

I'll have a look at how the 2600 scans keypads and then get back to you. One of the Freescale MC9S08 range is probably ideal because some of them are available in 0.1" pitch DIP and its assembly language is similar to 6502 (in my opinion). That'll make it easier for you to get some help on the software side from the 6502 assembly language folks on here.

[dustfilledhobo]

Thanks for your help. I look forward to your next reply.

[BigO]

My soldering skills are good, and my software experience is minimal. I feel much more comfortable with hardware.

I'll have a look at how the 2600 scans keypads and then get back to you. One of the Freescale MC9S08 range is probably ideal because some of them are available in 0.1" pitch DIP and its assembly language is similar to 6502 (in my opinion). That'll make it easier for you to get some help on the software side from the 6502 assembly language folks on here.

It's basically a standard 3x4 keypad matrix. The only thing unusual I've seen about it is the resistors that connect to the paddle input lines. They would keep those column (inputs) high until a low was applied to that column via a button on a row that was being polled.

 

Since the joystick applies a ground (low) to the various inputs when switches are closed, it can be assumed that the standard digital port lines are pulled high internally. Given that, to read the keypad in the 2600 software you'd have to set a keypad row low, then check the column inputs for a low to detect a button press on the currently polled row. Then you set the next row low (return the previous row to a high) then check the column inputs for a low, etc.

 

Aside from the processing speed of the 2600, your overall scanning rate (for 2/3 of the buttons anyway) is going to be limited by how quickly the 2 paddle input lines (pins 5,9) charge to a logic 1 state after they've been pulled low by a button press in those columns.

 

Considering that you can only momentarily read each button for, say 1/12 of the scanning cycle, and you want to break each of those time slices down to read a series of pulses within that time and the software will need processor time to do anything useful, you may not get exactly the effect you're looking for.

 

To accomplish an individual pulse rate per button, not only will you have to have some source for creating the pulses at the desired rate, you will have to apply that signal at an appropriate time (interrupting the polling signal being fed through the keypad back to the port/column) according to which row is being polled and which button is being pressed in that column.

 

Hardware-wise, I think the concept could be implemented, but to what end? I tend to expect the software to be checking each button for a given amount of time and stop checking that button after it has found an active signal (or some debouncing criteria have been satisfied) on the button that it's checking. The author of the software would have to speak to this point. I'd certainly test it with some simpler circuit simulating one of the keypad buttons before embarking on the bigger project.

 

If you're writing custom software and want each of 12 buttons to be able to convey a variable value to the console, you might be better off building something that scans the matrix with a microcontroller then buffers the rate data that you want associated with that keypress. The console could then do some digital communication on 4 or 5 digital I/O lines to read the buffered data. Just idle speculation.

 

There's a schematic of the 2600 keypad here: http://www.atariage.com/2600/archives/sche...sories_Low.html

Edited March 25, 2009 by BigO