Jump to content
IGNORED

Joystick multiplexer help


gauauu

Recommended Posts

Hey all, as some of you know, I've been slowly working on a design to do 4 joysticks on the Atari 2600, using a simple multiplexer scheme -- using one or two of the controller lines as output to drive a multiplexer, allowing multiple joysticks in a joystick port. It's mostly worked really well, BUT on consoles that are still using RF (ie haven't been modded for A/V out), there's a bit of flicker on the screen whenever you wiggle one of the joysticks. Apparently, there's something that happens while switching the joystick that causes a spike or surge or something that shows up in the video.

 

After asking around, and trying a number of designs to fix this, I'm running out of ideas. I've been working with John Champeau to hopefully use this in his upcoming Wizard of Wor game, but we're wanting to get these issues worked out to make it possible.

 

If any of you hardware gurus are interested in helping, and have any suggestions, we'd be really interested to hear it. I'm posting a link to the Eagle schematic and board files of one variation of it. I've tried quite a few slight variations, and they all exhibit the same behavior. At the advice of a knowledgeable friend, I also tried piggybacking 10 microFarad caps over the pull-up resistors, but that didn't resolve the issue.

 

https://www.dropbox.com/s/2ufezgdjs733lot/2mux.zip?dl=0

 

Please let me know if you have any suggestions, or ideas for us. Thanks!

 

post-39949-0-05942200-1551146431_thumb.png

  • Like 3
Link to comment
Share on other sites

Have you watched the VCC/GND connection with a scope to look for power degradation? The RF board is quite sensitive to power fluctuations.

 

Also, at least temporarily, try powering the multiplexer with a separate 5V supply. Just keep the grounds common.

 

Another test: Try not connecting the L and R pins for a moment, to see if they are the primary cause.

 

I see you also modified the direction inputs so that L and R go into the TIA instead of the RIOT, no doubt so you can take advantage of the bidirectional ports. I wonder if the fact that the TIA pins have a capacitor connected to them might be causing trouble? That is, in order for the pin to change state, the capacitor forces an inrush or outflow of current from the multiplexer in order to complete the state change. That could cause a bit of extra power draw in the process. One possible way to mitigate that might be to place a small resistor on those pins.

 

Also, the CV plays a trick of using a voltage divider to keep the "high" voltage at 2.5V. This is enough for a TTL high, but allows for faster turnaround. That trick could also work for you.

Link to comment
Share on other sites

There are a lot of possiblities, have you placed a 0.1uF ceramic disc across the supply of the IC's right at the the IC (standard decoupling technique)?

I do not think the 10uF caps across the resistors would do much, spikes are usually high frequency a 0.1uF ceramic disc between the inputs to IC1 & 2 and ground in addition to the supply decoupling would help decouple any spikes/noise were that the cause of the interferance .

 

You could replace IC's 1 & 2 with a single PIC (or other) microcontroller, it may take up less space and having the input and output pins on different ports should stop any transients propagating through as unlike a pure logic device the output high/low status is being set by the software.

 

Another option is to change you approach to the entire design and use a wired OR system like the Jaguar team tap.

The set up is similar to that of IC1 in regards to the input pull up resistors but each input goes through a diode to each controller port. For example if pin 2 of IC1 is the "Up" input it goes through one diode (1N1414 should suffice) to the Up pin of controller port 1 (cathode to controller port), through a second diode to the Up input of controller port 2 and so on for how many controller ports you require.

Then you can repeat that with say pin 3 for the "Down", pin 5 for "Left", pin 6 for "Right" and pin 11 for "Fire", but use a non-inverting buffer/Line driver IC like a 74HC244 instead of the 74157.

 

This way you only need 1 input and output pin per function (L, R, U, D , Fire), how do you select which controller is being read? Simple, connect the ground connection of each controller port to your port select lines, the controllers who's ground lines are high (5v) will produce no output but the one who's ground line is low (0V) will be the one that is being read. Alternatively, you could use the controller select lines to switch the controller port grounds to ground via an ZVN4306A FET so as not to load the controller selection lines.

 

Whichever of the above you use you have to account for propagation delay. Normally the 2600 the pins are read directly, when switching port it takes a new nanoseconds for the change in the controller select pins to propagate through, select the port and the output of the input IC reflect that change so hopefully there are a few instructions to execute between the controller port selection and read otherwise you may be reading a different port to the one you think you are or possibly at the point of the change in state as the outputs update to reflect the new controller data which could potentially be causing the interference.

It is unclear to me from the posted image where the controller data and select line are going to and I could not download from Dropbox at my present location to see if that held any more information but if ChildOfCv is correct in that you are connecting to the TIA depending on how you are doing that it may be loading the TIA resulting in the interference in the video.

Link to comment
Share on other sites

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.

Edited by BigO
Link to comment
Share on other sites

Thanks for all the replies.

 

 

Have you watched the VCC/GND connection with a scope to look for power degradation? The RF board is quite sensitive to power fluctuations.

 

Yeah, I tried, but I'm not very experienced with this sort of thing, and wasn't able to see it. I imagine that's because I don't really know what I'm doing with a scope though :-)

 

Also, I don't think it's the L/R pins into the TIA causing trouble -- my first design had everything going into the normal pins on the 2nd controller port, and it had the same issue.

 

There are a lot of possiblities, have you placed a 0.1uF ceramic disc across the supply of the IC's right at the the IC (standard decoupling technique)?

I do not think the 10uF caps across the resistors would do much, spikes are usually high frequency a 0.1uF ceramic disc between the inputs to IC1 & 2 and ground in addition to the supply decoupling would help decouple any spikes/noise were that the cause of the interferance .

 

 

I tried caps across the ICs, but they may have been too high. I can try again with 0.1uF.

 

 

Another option is to change you approach to the entire design and use a wired OR system like the Jaguar team tap.

The set up is similar to that of IC1 in regards to the input pull up resistors but each input goes through a diode to each controller port. For example if pin 2 of IC1 is the "Up" input it goes through one diode (1N1414 should suffice) to the Up pin of controller port 1 (cathode to controller port), through a second diode to the Up input of controller port 2 and so on for how many controller ports you require.

Then you can repeat that with say pin 3 for the "Down", pin 5 for "Left", pin 6 for "Right" and pin 11 for "Fire", but use a non-inverting buffer/Line driver IC like a 74HC244 instead of the 74157.

 

 

 

 

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.

 

 

I like these ideas, I may give them a try.

 

 

Thanks for the suggestions, all.

 

 

 

Whichever of the above you use you have to account for propagation delay. Normally the 2600 the pins are read directly, when switching port it takes a new nanoseconds for the change in the controller select pins to propagate through, select the port and the output of the input IC reflect that change so hopefully there are a few instructions to execute between the controller port selection and read

 

Yeah, the different designs we tested all have a bit of delay. We've been switching the pins, waiting a bit, then reading.

Link to comment
Share on other sites

Yeah, the different designs we tested all have a bit of delay. We've been switching the pins, waiting a bit, then reading.

 

One way to avoid the switch/wait thing is to read first, then switch and return to drawing. By the time you come back to read the other port(s), it ought to be stabilized.

 

BTW, a third option is to use 2 pins for controller selection and use 4:1 multiplexers. This does mean you have to cycle through 4 states instead of 2 though, but it gives you all 4 directions and the button back into the RIOT.

  • Like 1
Link to comment
Share on other sites

Also, for scoping the VCC, set it for AC, normal trigger, and probably around .1V/div. If you have a storage scope or a USB PC type, it ought to show you the entire image if it triggers. Otherwise you just have to watch the after-image.

 

It's also possible that a good multimeter with a min/max function could give you some idea of wandering power readings.

  • Like 1
Link to comment
Share on other sites

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 may be correct but I would be surprised if they were floating as any noise could result an accidental fire/movement, disrupting game play.

 

I can see why someone might think they are floating as there are no pull up resistors shown on the schematic, but I would be surprised if the relevant input pins did not have transistors pulling them high inside the RIOT & TIA to ensure an consistent and noise immune input state when the joystick direction/fire are not actuated. This can be easily tested by just measuring the voltages on the direction of the RIOT/controller port, if they read in the 4-5V range they are pulled up internally, if not they are floating.

  • Like 1
Link to comment
Share on other sites

You may be correct but I would be surprised if they were floating as any noise could result an accidental fire/movement, disrupting game play.

 

I can see why someone might think they are floating as there are no pull up resistors shown on the schematic, but I would be surprised if the relevant input pins did not have transistors pulling them high inside the RIOT & TIA to ensure an consistent and noise immune input state when the joystick direction/fire are not actuated. This can be easily tested by just measuring the voltages on the direction of the RIOT/controller port, if they read in the 4-5V range they are pulled up internally, if not they are floating.

 

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.

Edited by BigO
Link to comment
Share on other sites

One way to avoid the switch/wait thing is to read first, then switch and return to drawing. By the time you come back to read the other port(s), it ought to be stabilized.

Thanks for the advice! This is exactly what I'm doing in WoW Arcade: at the beginning of VBLANK I read joystick 1 and then switch the inputs to joystick 2. During overscan, I read joystick 2 and then switch back to joystick 1. This gives a minimum of 30+ scan lines between switching and reading (I lot more for joystick 2 as it waits 200+ scan lines between set/read with the kernel). It also reads both joysticks each frame. I have played WoW Arcade with this setup (2 player with my brother) for hours and the control is spot on; not once did it feel any less responsive than using 2 joysticks connected to the regular ports. :)

 

One thing Nathan and I spoke about in the design is supporting 4 one-button joysticks on one port but also supporting 2 2 button joysticks. My thought was to multipurpose one of the joystick pins to be input or output; it would be controlled by a switch on the adapter. In 4 one-button joystick mode, the two control output pins would be used to select which joystick to read (1-4). In 2 joystick mode, only one of the pins would be used as a selector and the other would be an output pin for the 2nd button. Does that sound feasible? Of course the software would have to be written to know what to expect on that 2nd pin, but the game itself would decide that either by the nature of the game (for example, Wizard of Wor Arcade only supports 2 joysticks and needs only 1 button for each, so it would never need to write or read from the 2nd pin; it would only use the 1st pin as a selector and ignore the 2nd pin (not needed to select or to read since the 2nd button isn't needed). A menu configuration could also be used in the game to take advantage of 2 button mode if needed.

 

I think it would make the multiplexer a bit more marketable and attractive to programmers since it would allow them to write games that support 2 button controllers for 2 players (I'm thinking sports games) but also have the flexibility to support 4 joysticks with 1 button for each player (like Nathan's demos of 4 player Combat, Joust, etc.).

Edited by johnnywc
Link to comment
Share on other sites

Hmmm... actually you could even support 4 2-button joysticks if you used the 4:1 multiplexer approach. If 2 of the 8 pins are for address, that leaves 6 for signals, which could easily do 4 directions and 2 buttons. That also saves you from designing different modes in the multiplexer box. But it does mean you have to poll 4 times in a reasonable time (per frame, I guess?) A little more complicated from a programming perspective, but a win from the hardware side.

 

One thing about the 2600's design seems weird to me, though. PA0 (player 2 up) has a capacitor connected to it, but none of the other direction inputs show one. Is there a traditional explanation for this?

Link to comment
Share on other sites

Hmmm... actually you could even support 4 2-button joysticks if you used the 4:1 multiplexer approach. If 2 of the 8 pins are for address, that leaves 6 for signals, which could easily do 4 directions and 2 buttons. That also saves you from designing different modes in the multiplexer box. But it does mean you have to poll 4 times in a reasonable time (per frame, I guess?) A little more complicated from a programming perspective, but a win from the hardware side.

Disclaimer: I'm not a hardware guy :) With that said, I think we only have 7 pins we can read in the first joystick port, right? 4 for the joystick directions, 1 for the button, and the other 2 from the paddle lines (the other 2 are vcc and ground). If we use 2 of the joystick directions as input to the multiplexer, that leaves 5 pins we can read I think (or at least that's how we're doing it now). I guess I don't understand enough about multiplexers about how it would work from a hardware or software standpoint. :| Certainly a more simple hardware design that supports 4 joysticks each with 2 buttons would be best!
Link to comment
Share on other sites

 

One way to avoid the switch/wait thing is to read first, then switch and return to drawing. By the time you come back to read the other port(s), it ought to be stabilized.

 

BTW, a third option is to use 2 pins for controller selection and use 4:1 multiplexers. This does mean you have to cycle through 4 states instead of 2 though, but it gives you all 4 directions and the button back into the RIOT.

 

This is how my original design worked. I used the player 2 port, 2 pins as output to drive 4:1 multiplexers. Then read everything as normal on the RIOT on the player 1 port. It still had the same flicker/interference issues :-(

Link to comment
Share on other sites

Oh, I assumed the multiplexer box plugged into both ports... at least I thought I saw 4 plugs in the (imported) Eagle schematic.

 

If you were to use both ports, you'd have easy access to all pins on the RIOT, and you could still keep the TIA pins in reserve. So, that was the basis of my suggestion.

Okay, that makes sense now. :) Nathan's original design used both ports; I approached him about modifying the design to use one port so the other port would be free for the Atarivox (for speech/savegame in Wizard of Wor).

 

Anyway, so if we use one port, is it feasible to multi-purpose a pin to be input/output based on a switch on the adapter to toggle between the two modes (4 one-button joysticks and 2 two-button joysticks)?

Link to comment
Share on other sites

 

This is how my original design worked. I used the player 2 port, 2 pins as output to drive 4:1 multiplexers. Then read everything as normal on the RIOT on the player 1 port. It still had the same flicker/interference issues :-(

Wow, so that exonerates the TIA then.

 

If you have an external +5V source, say from a USB device that you can tap, see if separately powering the box prevents the flicker.

 

Also, are you using 74LS chips or straight 74? The biggest beef against the straight 74 is power use. The LS variants use about 1/5 of the power of the standard ones.

 

I'm also curious if feeding a 555 timer into a port or two causes the same flicker. If so, that gives you a more consistent way to try to track down the issue.

 

Anyway, so if we use one port, is it feasible to multi-purpose a pin to be input/output based on a switch on the adapter to toggle between the two modes (4 one-button joysticks and 2 two-button joysticks)?

That sounds feasible. The biggest thing you'd want to make sure of is that the Atari and the multiplexer don't damage each other when they're not in agreement over who runs the port.

 

One trick would be to switch to input mode on the RIOT to send a high (with the internal pull-up resistor) and switch to output to send a low. Use a diode that allows the multiplexer to sink only. Then if both are trying to drive, we have:

 

MX high, RIOT "high": Line is high.

MX low, RIOT "high": Line is low, but RIOT okay with that.

MX high, RIOT low: Line is low, but MX can't tell.

MX low, RIOT low: Line is low.

Edited by ChildOfCv
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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.

That is also a wired OR solution, just using fewer componets than the one I suggested, it should work but in my solution the diodes provides better isolation and the 74HC244 (which could be omitted) just ensures a clean signal.

 

The difference between the two is that because my solution uses diode isolation you can disable and enable a joystick with either the logic output (Low = enable, High = disable) connected directly to the Joystick ground pins or use the logic outputs to drive a ZVN4306A (High to the gate = enabled, Low = disabled) to connect/isolate the controller ground pins.

If you do not use diode isolation then you have to switch the ground connections via a ZVN4306A because if you do it with just the digital signals directly driving the ground pin of Joystick 1 high (disabled) and Joystick 2 low (enabled) a short circuit will occur between the high and low controller select outputs when the same direction/fire button on both Joysticks are closed at the same time. Short term such short circuits would result in intermediate voltages that could randomly be interpreted and high or low and direction/fire inputs not being recognised, long term effects would be to damage the logic outputs. Consequently while you can just strap them in parallel without diode isolation you need to be careful about how you go about it.

 

Also, are you using 74LS chips or straight 74? The biggest beef against the straight 74 is power use. The LS variants use about 1/5 of the power of the standard ones.

Good point, the LS chips do not provide enough output current to correctly drive a standard 7800 series TTL input, you need to use either standard 7800, 78HC or CMOS 4000 series logic devices when integrating to standard 7800 series devices.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

You guys rock. I'm going to try some experiments with putting the sticks in parallel, switching the grounds (with diodes as suggested)

 

...it goes through one diode (1N1414 should suffice) to the Up pin of controller port 1 (cathode to controller port), through a second diode to

 

I'm having trouble finding info about the 1N1414, is there a different part that would be similar? (I'm not very knowledgeable about the difference between diode types)

 

 

Also, are you using 74LS chips or straight 74? The biggest beef against the straight 74 is power use. The LS variants use about 1/5 of the power of the standard ones.

 

 

I'll have to double check this later tonight.

Link to comment
Share on other sites

Good point, the LS chips do not provide enough output current to correctly drive a standard 7800 series TTL input, you need to use either standard 7800, 78HC or CMOS 4000 series logic devices when integrating to standard 7800 series devices.

Hmmm... I guess I should ask which platforms are being targeted. Are there other envisioned platforms for this multiplexer besides the 2600/7800/800? Because they all use NMOS/CMOS and LS.

Link to comment
Share on other sites

I'm having trouble finding info about the 1N1414, is there a different part that would be similar? (I'm not very knowledgeable about the difference between diode types)

Sorry that was a typo I meant 1N4148, it is a fairy run of the mill silicon diode with a forward voltage of 0.7v, alternative you could use a schottky diode such as the BAT85 which has a lower forward voltage of 0.3v and is probably the better option if you are omitting the 74HC244 and going controller port inputs - diodes - joystick instead of controller port inputs - 74HC244 - diodes & pull up resistors - joystick.

Link to comment
Share on other sites

Just did a proof-of-concept today, wiring it up with the general idea you guys suggested (2 sticks wired in parallel, other than the ground switched from the RIOT output pins). It's just in parallel right now (so other hardware, so I depend on software turning the alternate pins back to input to prevent short-circuits!), but the general concept works so far. I'll do some more tests with adding the diodes, and whatnot, but it appears promising so far.

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

Thanks for the help, all. The design of running them parallel with an inverter on the ground, and using diodes for isolation, is working perfectly. No signs of interference. I've got it all on a messy breadboard right now (I don't know how you hardware people stay sign, the mess of wires drives me crazy!), but it's time to make some prototype PCBs!

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...