New Controller Standard for 2600

[Zonie]

Folks,

 

I have brought this up in years past (I think) about creating a new "homebrew Standard" controller that we as a group could decide on and then new homebrews and hacks can be written to take advantage of it. Some of the ideas out there recently (mine included) involve using both ports on the 2600 like Stargate and Raiders did, but this idea would use only one port to allow for two player action.

 

I propose we publish instructions and a bill of materials to build one, and users can also build them to sell to those not inclined to make their own.

 

I think something like this will fuel some really cool hacks. I can think of Missile command having three bases and analog control, for example.

 

Two ideas below, take advantage of the POT lines for the paddles. Remember an analog joystick is two pots, and I think that the original designers thought about this when they designed the 2600, Curt Vendel may have some insight to this?

 

Both ideas use the up and down inputs for additional fire buttons for a total of three, the left and right for an (optional?) driving controller/spinner, and the joystick now uses the paddle pot lines.

 

Style 1 uses true analog pots for the joystick.

Style 2 uses a digital arcade controller and takes advantage of the DPST micro switchhes and a few resistors to create voltage differences to simulate analog control with a digital joystick.

 

I purposely avoided using any multiplexing and IC circuits to simplify this as much as possible.

 

I don't know how easy it is to program a 2600 for analog control (can't be too bad since Pong and Breakout use it) but I think this would fuel a totally new gaming experience for us. I am not a programmer, I'm a hardware guy, so this is my contribution to the community. And not sure how well the 2600 will handle analog joysticks, and the calibration of them, for example, but worth a look.

 

 

 

What do you all think?

Edited June 28, 2008 by Zonie

[A.J. Franzman]

The main problem with the 2600 reading analog and rotary-encoded inputs is that it takes a lot of processor time, which is why most paddle controller games and the one original driving controller game are rather simplistic, graphically and in gameplay. One person was able to hack one arcade port to use the Trak-Ball controller in its native mode (Missile Command TB by Thomas Jentzsch), but even he could not foresee any possibility of hacking other, more complex games which used a trackball in their arcade original incarnations, to do so on the VCS. (Such as Centipede, Millipede, Crystal Castles, etc.)

 

So the problem with these improved controller designs is that any games designed to use them, will not be able to take full advantage of the 2600's other capabilities, which modern programmers now have in their repertoire to create really stunning examples of the kinds of games that Atari could only dream of in the years preceding the post-crash renaissance. Perhaps in the near future, if/when the Chimera project is fully realized, something like these new controller designs will be viable. But not yet, IMO.

Edited July 1, 2008 by A.J. Franzman

[Zonie]

A.J. Thanks for the information. I was not sure if the Analog inputs were a viable option. Seems they are not. Bummer. The rotary controller in my post basically emulates the driving controller, which is two digital inputs.

 

OK, if the Analog is a bust, then a dual jack solution is probably the best bet.

 

This would basically be the left port being used as a standard joystick port, and the right port supplying two additional fire buttons and the spinner/driving controller input.

 

What I am trying to create here is more functions without going to the extreme as some of the newer consoles. A joystick and a spinner seem to be the ideal input devices where a tron-like gameplay could be possible with such a setup.

 

The only downside is the one-player only aspect.

 

Has anyone in the Homebrew community looked at the possibility of adding a controller port to the cartridge itself, or possibly an adapter between the cart and the console, sort of like the sonic/knuckles thing on a Genny? Looking at the Chimera cartridge, It looks like this may be what is happening? I gotta look at more of the Chimera project. Have been away for a while...

 

What about multiplexing like on the keyboard controllers? Anyone thought about using such inputs to create directional inputs? I'm not sure of the keyboard controller schematic off hand, but is is a viable option?

Edited June 30, 2008 by Zonie

[+SpiceWare]

The CBS Booster Grip uses the analog inputs to add 2 extra fire buttons. The reading of the extra buttons is simpler than reading a paddle as you only have to check it once per frame instead of many times. This allows each player to have a digital joystick with 3 fire buttons, plus time for more complex kernels.

 

I've found this page on converting an NES game pad to be Booster Grip compatible, suspect the same could be done with a Genesis 3-button game pad.

[BigO]

Has anyone in the Homebrew community looked at the possibility of adding a controller port to the cartridge itself, or possibly an adapter between the cart and the console, sort of like the sonic/knuckles thing on a Genny? Looking at the Chimera cartridge, It looks like this may be what is happening? I gotta look at more of the Chimera project. Have been away for a while...

As I understand it, the Chimera does/will directly support controllers to free up the mainboard CPU for handling graphics. This may well make the advanced controller a reality for Chimera dependent games.

Edited July 1, 2008 by BigO

[BigO]

As I have a current interest in controllers for vintage gaming these days and man-machine-interfaces in general, I would find it very interesting to see what functionality or designs other people might suggest for a new "hombrew standard" controller that Zonie is talking about here.

Edited June 30, 2008 by BigO

[Zonie]

The CBS Booster Grip uses the analog inputs to add 2 extra fire buttons. The reading of the extra buttons is simpler than reading a paddle as you only have to check it once per frame instead of many times. This allows each player to have a digital joystick with 3 fire buttons, plus time for more complex kernels.

 

I've found this page on converting an NES game pad to be Booster Grip compatible, suspect the same could be done with a Genesis 3-button game pad.

 

OK, I thought the booster grip used port 2. Then using the paddle lines for a digital input is viable then. cool.

[Zonie]

OK, Using the BS booster grip method of using the pot lines for extra fire buttons, I have also added a select switch to select between having:

 

 

A. Joystick + three buttons

B. Joystick + one button + spinner

 

 

This still gives us a controller that can be used for existing games and allows for new Homebrews to take advantage of the extra inputs without needing the Chimera cart.

 

Thoughts?

[Wickeycolumbus]

OK, Using the BS booster grip method of using the pot lines for extra fire buttons, I have also added a select switch to select between having:

 

 

A. Joystick + three buttons

B. Joystick + one button + spinner

 

 

This still gives us a controller that can be used for existing games and allows for new Homebrews to take advantage of the extra inputs without needing the Chimera cart.

 

Thoughts?

 

I really like the idea! I am going to build one of these and try to write some software for it tomarrow.

[BigO]

Thoughts?

I like the way you set up the selection between buttons and quadrature encoder (spinner).

 

I know it's processor intensive to read the driving controller because if you miss state changes you can't properly detect rotation. I've always assumed that due to the capacitors, the state change time of the paddle input lines would be slower than the standard digital input lines. I don't know if this represents a problem in the real world, but it's something I'd test before nailing down this design, just to quantify the delay if any.

[BigO]

A comment for clarity's sake: you say it will work with existing games meaning existing joystick games, right? (And Omega Race)

The driving controller as implemented here wouldn't work with Indy 500 and other homebrews that support it...unless you come up with a nifty way of switching it over to the lines that were used to support the OEM driving controller.

 

(I don't mean in any way to detract from this project, just pointing out what I see as potential issues.)

[Zonie]

Big-O. No issues. Nooffense taken. Please point out every problem you see. this is a working session in my opinion. I also toyed with the idea of putting in a selection switch for the encoder to use either the pot lines or the joy_rt and joy_lf lines like it does as currently in the driving controller. This can all be easily done with DPDT switches (or rotary) that can easily be obtained by anyone at Radio Shack. (Remember, easy to get parts and easy for anyoen to build)

 

Also for clarification, yes, it will work with existing joystick and omega race.

 

I am looking forward to see if Wickeycolumbus has any luck reading the encoder with the pot lines. It may be a good exercise to just quickly wire the encoder to the pot lines and write some test code "just to see" what happens.

 

I have mocked this thing up on a shoebox (not wired yet) just to get the feel. I have moved the spinner to the left of the joystick so it can be operated with the left hand with the right hand on the joystick. The stick will need a top button or you can actuate the standard fire button with the right pinkey as the three buttons are to the right of the stick.

[BigO]

Big-O. No issues. Nooffense taken. Please point out every problem you see. this is a working session in my opinion. I also toyed with the idea of putting in a selection switch for the encoder to use either the pot lines or the joy_rt and joy_lf lines like it does as currently in the driving controller. This can all be easily done with DPDT switches (or rotary) that can easily be obtained by anyone at Radio Shack. (Remember, easy to get parts and easy for anyoen to build)

The selection of the joystick lines vs paddle inputs will also have to include switching the common to ground (pin instead of +5 (pin 7).

3PDT switches exist, but I doubt Radio Shack has them.

Edited July 1, 2008 by BigO

[Wickeycolumbus]

I am looking forward to see if Wickeycolumbus has any luck reading the encoder with the pot lines. It may be a good exercise to just quickly wire the encoder to the pot lines and write some test code "just to see" what happens.

 

unfortunately I did not have the time to test it today. What is the value for the pot?

[Zonie]

Big-O. No issues. Nooffense taken. Please point out every problem you see. this is a working session in my opinion. I also toyed with the idea of putting in a selection switch for the encoder to use either the pot lines or the joy_rt and joy_lf lines like it does as currently in the driving controller. This can all be easily done with DPDT switches (or rotary) that can easily be obtained by anyone at Radio Shack. (Remember, easy to get parts and easy for anyoen to build)

The selection of the joystick lines vs paddle inputs will also have to include switching the common to ground (pin instead of +5 (pin 7).

3PDT switches exist, but I doubt Radio Shack has them.

Well, th AA store could carry them...

[BigO]

Or you could use a 4066 or other commonly available chip.

 

Wickey, I may be misunderstanding your question, but there is no potentiometer to have a value. The quadrature encoder (like the driving controller) is hooked up to the input lines where the standard paddle pots would connect.

[Zonie]

Or you could use a 4066 or other commonly available chip.

 

Wickey, I may be misunderstanding your question, but there is no potentiometer to have a value. The quadrature encoder (like the driving controller) is hooked up to the input lines where the standard paddle pots would connect.

 

Yes, but then that would require a small PCB with support components, etc. WOuld be nice, but simple is key here to gain wide acceptance.

 

Maybe someone lurking will build and sell one in the AA store...That is what I am hoping for. the collaborative efforts of this ad-hoc "standards committee" will drive this. This is the chance to get what we wanted back in 1978.

[Wickeycolumbus]

Or you could use a 4066 or other commonly available chip.

 

Wickey, I may be misunderstanding your question, but there is no potentiometer to have a value. The quadrature encoder (like the driving controller) is hooked up to the input lines where the standard paddle pots would connect.

 

where could I get one of these quadrature encoders?

[BigO]

Or you could use a 4066 or other commonly available chip.

 

Wickey, I may be misunderstanding your question, but there is no potentiometer to have a value. The quadrature encoder (like the driving controller) is hooked up to the input lines where the standard paddle pots would connect.

 

where could I get one of these quadrature encoders?

Atari 2600 driving controller.

[Thomas Jentzsch]

I know it's processor intensive to read the driving controller...

No, it isn't. At least not with the low resolution Atari DC (just 16 positions/360°).

 

...because if you miss state changes you can't properly detect rotation.

Right. But due to the very low resolution this is very unlikely.

 

The trackball is a different story, because the resolution is much, much higher.

[Thomas Jentzsch]

where could I get one of these quadrature encoders?

Atari 2600 driving controller.

Other options: Atari Trackball, ST mouse and Amiga mouse.

[BigO]

You could pick the signals out of an older optomechanical mouse if you were creative and desperate.

 

I've got this VTech "Mouse Play Deluxe" toy (that I bought for the LCD) that has a cutesy little 2 button mouse that feeds the raw gray code directly onto the wire that goes into the main unit. I've been kicking around the idea of use it in place of a driving controller or plug the inputs into a trackball controller.

 

http://www.drtoy.com/2000_v/vtech_4_2000v.htm

[Zonie]

I think we need to settle on the encoder from the driving controller. It is compatible, many around, I find them in the wild all the time. This is what I intended.

[BigO]

I think we need to settle on the encoder from the driving controller. It is compatible, many around, I find them in the wild all the time. This is what I intended.

I agree. It's especially nice to have access to one of the "open" ones so that you can see what's going on mechanically.

 

I think I saw somewhere that a guy built his own so for the true hardcore, from-scratch, DIY-er, there's that possibility.

[Zonie]

Well, I think I'm gonna build this thing into a 2600 Vidlid.

 

VIDLID.bmp