BigO

With the availability these days of cheap microcontrollers, the hardware cost of circuitry to decode and translate the quadrature signals wouldn't be my biggest concern. A sub-five-dollar Arduino Nano can handle decoding and translating two quadrature signal streams with plenty of resources to spare. Though, there would be the additional one-time cost of developing the software and per-unit cost of programming the devices might be a meaningful cost factor for production. I think the mechanical portion of encoding of ball motion would be the hurdle that I couldn't affordably get over.

About the same. I wasn't a rabid gamer then and now I tend to spend more time building controllers to play games with than actually playing games with them. I keep telling myself when I finish my current multi-function controller project that I'll actually use it...

I only have a passing knowledge of this,but it almost seems like you'd have to use at least a subset of an emulator to calculate an x/y representation of game elements. Does Stella expose anything that would make this exercise more feasible?

I'm not sure it's directly applicable, but I recall the homebrew Chunkout displaying at least 8 different colored blocks one one line.

Some of those pictures look typical of dirty cartridge and/or port contacts. I'd try cleaning them because it could be that simple. You should be able to search out a number of threads covering that subject. On the other hand, at least one doesn't quite look like I'd expect. The last one looks like it's rendering some elements correctly but not others. That could be a deeper problem.

On the video issue, that might just be dirty cartridge and/or socket contacts. Activision games are particularly susceptible to this issue as their circuit boards are slightly thinner than others.

I have no idea what you could be referring to.

The PAL/NTSC compatibility of a cartridge is a property of the software game program, not the cartridge hardware. If you have an NTSC console, you'd need an NTSC flavored ROM to be installed on that custom cartridge. Some PAL only titles have been converted to NTSC versions so you might be lucky there. I'd recommend contacting Al via e-mail if you have concerns about what you've already ordered.

Read the above mentioned service manual and be prepared to hear yourself ask, "Really?! That's the official method?!"

That was it. Thanks! Clearly there's something I need to read in this thread.

Is it broken? The paddles don't move now. For play testing a homebrew paddle controller, I was looking for paddle games. I downloaded the latest version a apong.bin to my Harmony Cart, overwriting the version I had before. To be sure it wasn't a problem on my end, I have: Tested with OEM paddles and no luck there either. Downloaded the original version from the first post and the paddles work fine. Downloaded the latest version several times from the recent post to assure no corruption Downloaded the latest version from the first post so I don't think it's a corrupt download. Is it just me?

For the record, I don't dispute what Stephen Moss is saying. I wasn't engineering a final solution, just addressing the need to switch only one pin of each controller and throwing out brainstorming style tidbits. It seemed like the OP solution was possibly overly complicated which was likely to affect power requirements, but I am not a professional in the field. Good luck with the project.

For reference, I'm driving an arduino, quadrature encoder, and a digital potentiometer off of an RF connected light 6'er and don't see any impact on the video even if I plug it in while the console is already powered up. I've powered a few odd things from the 2600. The only time I've seen anything weird was when I accidentally backed USB power into the console while it was powered off. That just made the static on the screen more black.

Stephen Moss, you are correct. Undoubtedly, there are pull up resistors at play inside the console/IC's. In hindsight, my phrasing was ambiguous at best. By "All of the inputs to the 2600 are just floating", I meant the controller output pins with respect to their influence on the inputs. Better phrasing might have been "the outputs from the controller where they connect to the console inputs are just floating. They exert no influence on the inputs". The significance is that two joysticks can be connected in parallel and until actuated, both would remain completely transparent to the console inputs. In order to switch between the joysticks, one would need only to break the pin 8 ground connection to one joystick to make sure it was the other joystick being read.

Same with all games? No game? 2600's do funny things when the cartridge port or cartridge pins are dirty. But the "static" part of your description makes it seem only vaguely like that.

All that I've looked at are 500K. And the working range is not the full range of the pot. If you look at how the pots are actuated, you'll see why. They rotate only about 180 degrees. It's been a long time since I measured and mechanically estimated the range so I don't recall the full range.

Not fully thought out (and I'm not claiming to be a hardware guru), but here's my knee-jerk, brainstorming reaction: At a first approximation, with a standard 2600 joystick setup, there's really no signal being sent to the 2600 until you actuate the joystick or fire button. All of the inputs to the 2600 are just floating. You should be able to fully connect two idle joysticks in parallel with no ill effect. It would only be necessary to connect/disconnect the ground signal to each joystick to determine which one is being read at that instant. The unconnected ground signal to the inactive joystick would have to be something that goes to Hi-Z rather than a digital 1 for the non-selected joystick. A tri-state buffer like a '244 might take care of floating that signal. Maybe an analog mux like a '4066. Presumably, the 2600 has some means of internally pulling up the input lines, so you probably wouldn't need external pull ups. Lower parts count, probably lower power draw.

Define "good money". It wouldn't require much technical wizardry to produce a controller that would work with these games. The quickest run to daylight would be to use off-the-shelf arcade parts but, as mentioned above, they're not what most of us hobbyists would call cheap.

I was too poor to have games like that back then. Add to that the fact that I have little interest in sports. I didn't play or own one of those red LED games until the last couple of years. I played the game (soccer) for a few days then put it away. Eventually, I sold it to an AtariAge member who happened to be in town on business. This whole genre of games was just a Blip on my radar.

Those were early prototypes of self-driving cars. They were superior to the current real world counterparts in that the video game version didn't require a human driver as backup. Sleep well.

Circus and Kaboom, of course. TacScan is a close 3rd. A rarely mentioned one is Steeplechase. I think I like it for the creative use of the controller as much or more than the game play.

Before the hack and before I had a Harmony cart, I built an adapter to externally remap the Up direction to work as the booster grip button did. It took a little bit of active electronics but was a fun first controller hack.

Happy to help. Since you've proven the concept, others might be encouraged to save classic hardware from the trash heap even without a drop-in sensor replacement.

Nice.