Help with rotary encoder translator

[RARusk]

For the past couple of years I have been working on an optical rotary encoder project for the game "Tempest 2000" for the Atari Jaguar. The game uses the joypad but there was a hidden code that, when activated, will allow you to use a mechanical encoder, such as the Atari 2600 "Indy 500" driving controller.

The original "Tempest" arcade game used a optical rotary paddle for control. This is obviously the best way to play the game. And I am attempting to make one work with "Tempest 2000".

While a mechanical encoder works good with the game it doesn't have the necessary speed and feel of an optical encoder. However, because of specific electrical characteristics, you have to hook up the optical encoder differently to the Jaguar joypad that what you do with the mechanical one.

The optical encoder works fantastic but, again because of how you need to hook it up, it causes interference that affects the camera (which is always zoomed in and causes problems on large playfields) and on a certain bonus stage. The Jaguar is expecting a standard three-pole mechanical encoder not an optical one.

So, to solve this problem, I decided to try to make a circuit that will "translate" the signal from the optical encoder into something that the Jaguar will better understand and remove the bugs from my controller. I believe I figured out most of the circuit but I need help with one part.

With a mechanical encoder inner contacts are brushing up against outer contacts as you spin the paddle (which create pulses which help determine direction and speed). When you stop the paddle the inner contacts fall into indents which separate the outer contacts. This allows the lines for left and right to go off when you stop the paddle.

However, on an optical encoder, when you stop the paddle, the left and right lines can be either on or off because there are no indents. What I want is a circuit that will kill the lines when the paddle is stopped regardless of what state the line is when it enters the circuit.

I got a hint when I asked Intersil for assistance:

"For the first issue, it looks like you need an ON-OFF-ON type switch, Left is on, center is off/open and right is on. I think you can do this with two CMOS SPDTs."

But I haven't figured out how to do this. It sounds simple but I can't figure it out. I have looked on the web but, so far, I haven't found anything. I even asked for help from another website but all I got was silence.

Maybe somebody her can lend me a hand or even suggest a better way.

[NFG]

I'm surprised that you need to find a different mechanism, it does sound as if there's something else wrong.  Both an optical and mechanical encoder return the identical results to the computer, and in fact I seem to recall there were two different encoders for the Atari 2600 (which I used for my Jag Tempest hack), one optical and one mechanical.

Whether you're using an optical sensor or a mechanical switch, the output is either Vcc or GND, right?  You could use mice and pigeons if you could somehow wire them to return the appropriate voltage - the system doesn't care how you got there.

Both encoders have a two-bit output with four potential states:  00 01 10 11

The order these are received by the console indicates direction. 

I think these indents are confusing you.  Pics might help illuminate your point, but it seems to me you don't HAVE to stop on an indent.

[viletim]

Both optical and mechanical rotary encoders are available with and without detents. The amount of states transitions (pulses) per detent also varies between encoders. For example the PHIER CI-11 mechanical encoder is available without detents, with a detent on every two pulses, or detent on every four. I don't know which type is best to play tempest...

Mechanical encoders are just switches so they'll have a lot of noise on each transition which needs to be debounced by the receiver. Optical encoders need (and usually come with) some schmitt trigger type of circuit to turn the ramping output of the optical receiver into digital pulses. But ignoring these details, they both work the same way except that an encoder with detents may have a predictable state in the rest position.

[RARusk]

I'm surprised that you need to find a different mechanism, it does sound as if there's something else wrong.  Both an optical and mechanical encoder return the identical results to the computer, and in fact I seem to recall there were two different encoders for the Atari 2600 (which I used for my Jag Tempest hack), one optical and one mechanical.

Whether you're using an optical sensor or a mechanical switch, the output is either Vcc or GND, right?  You could use mice and pigeons if you could somehow wire them to return the appropriate voltage - the system doesn't care how you got there.

Both encoders have a two-bit output with four potential states:  00 01 10 11

The order these are received by the console indicates direction. 

I think these indents are confusing you.  Pics might help illuminate your point, but it seems to me you don't HAVE to stop on an indent.

If you used an optical encoder for your Jag Tempest hack and it worked perfectly without any of the problems I have described how did you hook it up? I would love to know this.

Right now I am using an encoder I hacked out of a Sony BVE-910 editing keyboard as shown at this topic over at AtariAge.

[NFG]

I don't remember the encoder type, I only remember that I used two Atari Indy500 controllers.  I put a 9pin connector in the Jag pad, and plug the spinner into that.  Weight the spinner with a mess of pennies, and presto - instant funs.

[RARusk]

Hmmmm....not quite the answer I was hoping for.

The "Indy 500"paddle is a mechanical encoder and the resolution is too low unless you make certain modifications like the one you did.



The "Indy 500" encoder has three poles - one for left, one for right, and one for ground/voltage. To make this, and similar mechanical encoders, work on the Jaguar you have to hook up the right pole to the right button (leading into Padport 11), the left pole to the left button (leading to Padport 12), and the ground/voltage pole to Padport 4.

But, for an optical encoder, you have to hook it up a bit differently. You still hook up the left and right poles accordingly BUT you don't hook up Padport 4 to anything on the logic board for the encoder or it will not work. So, even though an optical encoder works great on the game, the way you hook it up and the electrical characteristics of the optical encoder signals is what is causing the interference I am trying to get rid of.

The circuit I am trying to create will "convert" an optical encoder to a mechanical one for the game.

The first half of the circuit, and the one I am having the most problems with, is to mimic the detents of a mechanical encoder. When the paddle is at rest I want the line states of both left and right going into the second half of the circuit to be at 00 even if the line states going into the first half of the circuit are at 11.

As for the second half of the circuit:



This is a dual CMOS SPST switch. Padport 4 is hooked up to NO1 and NO2. Optical Right (from the first half of the circuit) is hooked up to IN1. Optical Left (from the first half of the circuit) is hooked up to IN2. Right Button (Padport 11) is hooked up to COM1. Left Button (Padport 12) is hooked up to COM2. And, of course, ground and voltage.

This will convert the pulses into what the game best understands and works with. This should remove the problems I currently have my construct and allow it to shine.

[ninn]

any updates on this? I'd like to try something similar.