Megadrive controller going crazy...

[Steve T]

So I converted an old pad which had seen better days - from ebay it was full of broken silicone parts and bits of old stick backed paper - to an adapter board for an arcade stick, mainly to use on a MD... Which is where i'm having issues.

After a couple of months of light use i started having problems with it a few weeks ago, crossed inputs on the buttons which would occur after a few minutes use - it would always work perfectly for a few minutes before this happened, pressing A would also trigger B for example, infact this was the only issue at first, although possibly some dropped inputs too.

Since it seemed to only happen once things were warmed up I thought it might be a component issue (rather than say, a broken / crossed conductor in the cable, a short on the board(s) or wiring problems on the stick) and being too lazy to properly troubleshoot, and lacking tools like a scope decided to replace everything on the cut-down board, just a few passives and a cheap IC.

worked fine, for a few minutes ... then i started having issues with the directions, after messing with it some more I've managed to get it into a state where it somehow directed the player sprite in Hellfire (a pretty awesome arcade / MD shooter by toaplan) to uncontrollably drift down off the bottom of the screen and actually re-appear at the top, as if looping / wrapping around like in asteroids or something, in 25 years of playing this game and never getting past level 3 I've never seen the player sprite glitch like this, the behavior should be impossible.

fortunately the previous issue with the buttons seems to have disappeared, or maybe its just that i can play for long enough (not being able to steer) to make it happen.

And yes it works absolutely fine and reliably with other controllers, unmodified pads.

So its not directly an Amiga issue, but the multiplexer chip is the same as one of the CD32 pads and many of use the MD pad on an Amiga, so this may be help to someone, even if its just throw it in the bin and move on I've had great advice here in the past and I don't really know anywhere else to ask either lol.

One other thing, I was unsure of the capacitor value for the ceramic disk, rather than the usual code it just seems to show ".1M" i figured that was the same as a 104 but maybe its the wrong part - I opened up another old 3 button to check but it was a newer SMT type board with an unmarked tiny SMT cap, so...

Any help appreciated, sorry for the wall o text.

[Daedalus]

The capacitor in the MD pad isn't critical, it's only there to decouple any noise on the power rails, so any small-ish value capacitor will do the job there.

It seems like a very strange issue alright, something funky happening because up and down don't do anything special - they're not routed through the multiplexer or anything so it's difficult for anything to interfere with them.

As for the multiplexer chip - the CD32 pad doesn't work in the same way at all and doesn't use a multiplexer so I'm not sure what you mean there.

[Steve T]

I don't have an original CD32 pad but a couple of boards from a 3rd party, i think he basically copied the design 1:1 hmm, maybe it is another chip, its very similar TI chip, the first few characters are the same on it, a bit hard to read the text.

yeah i didn't think it would be critical about the cap, i'm pretty sure it has the right value, assuming the chip in the CD32 board is the same, it has the same decoupling cap on the same pin for example. but it has me stumped so far like i said the directions are causing some *very* odd effects.. like now testing with hellfire, it will move the screen and not the ship, this is not how the game is meant to run, that shouldn't happen at all!

*** comparing the 2, they aren't the exact same chip but appear very similar (good thing i didn't try swapping them out i guess!), the MD has a TI SN74HC157N, CD32 uses a TI SN74LS165AN and another chip i just can't identify, silk screen is too worn on it.

[Daedalus]

Yeah, there are a lot of logic chips that look very similar. Possibly the most common are the 74 series, most of them begin with 74LS or 74HC, along with numbers that describe the function, and the majority are in 14 or 16-pin packages. The first 2 letters are the manufacturer (SN for Texas Instruments, CD for Motorola for example), and the N means they're DIL packaged (the standard type you see there). The 157 is a multiplexer, the 165 is a shift register and the mystery chip is most likely a 125 - a buffer with tri-state outputs that's used for switching between compatibility and CD32 modes.

Indeed, it is very strange the effects it can have. I wonder if there's some sort of oscillation going on that is confusing the software. I really can't think of how that could really affect a game so badly, but without a scope or at least a simple LED probe to check the board it's difficult to figure out what's happening.

[Steve T]

hmm, well i must really be in trouble then. Yeah i really am starting to require a scope now, i think it would help with some TV issues i need to fix too, i just know i'm going to end up blowing something up

maybe i'll replace the wiring thats tying it all together, make it a bit cleaner.

I'm getting some totally different resistance values in some areas since the rebuild, i was getting 8k to 10k now 10k to 12k - just measuring across the resistors themselves before and after, (yeah i know thats not a good way to get a reading on that actual resistor, i'm probably measuring something else).

so that's a bit weird.

needless to say, all the extracted resistors were pretty much in spec, when measured out of circuit.

I had a fair bit of flux on there, residue that i tried cleaning off but there's still some built up in places, i wonder if there isn't perhaps some kind of leakage going on through that? Maybe i just need to do it better, but its odd the thing worked at first, i certainly didn't add more flux later anyways.

The other thing i thought but discounted was the difference between microswitched switches and carbon contact switches - well, carbon on copper in this older style of MD pad... but there has to be a difference in resistance on the switch... not really sure how it would make much difference to the chip (like breaking it or something) i don't think it would, it would also mean that the new chip broke instantly.

I think probably the old chip i removed was OK too.

Appreciate the advice and info as always, thanks!

[Daedalus]

I don't think any of those things would be enough to upset it, though it's no harm to eliminate them anyway. The resistors are pull-up and so like the capacitor, the value isn't really critical. They're nominally 10k I think, but anything from 1K to 20K should do the job. Electrically there's a huge difference between the high and low logic voltages, and either type of switch would normally be well within the requirements. Yes, the rubber dome switches will have a higher resistance, but a resistance of 10% of the pull-up resistor (if any) is enough, and they'll be well below that value. Typically, microswitches would suffer from contact bounce and the rubber dome ones wouldn't, but that's rarely an issue for software as it's normally level triggered, not edge triggered. Besides, all Zipsticks use microswitches and all CD32 pads are rubber dome.

[Steve T]

True though i assume all the microswitches in Zipsticks are wired directly to the Amiga? most of the buttons on my arcade stick are going through the CD32 or MD pad hardware first... whether that makes a difference or not the microswitches were working great with hellfire and other games before, and with the CD32/amipad hardware installed it also works great on the Amiga, i hadn't noticed any dropped inputs or odd behaviour with it.

I figured it would be a fairly broad range of acceptable values, but no idea it would be that broad... the resistors seemed to be a dead end anyway, like i said they're all replaced with new ones due to a lack of ideas

I also looked online for similar issues before posting here and couldn't find much, but this poster seems to have similar issues and someone else replies they've seen it a lot but just replaced the pad. http://www.gamefaqs.com/genesis/9163...th-controllers but if its a common fault WTH causes the issue?

Since i was going to make a 6 button adapter to go along with the 3 button anyway i ordered this splendid "Six Buttoms Game Handle Commander" from the usual source.

http://www.ebay.co.uk/itm/Six-Buttom.../222054414914?

A whopping £1.55 (about 2USD) for this to be delivered to my door from halfway around the planet... OK it might take a few weeks...

http://www.ebay.co.uk/itm/Six-Buttom.../222054414914?

Dreadful to play anything with i'm sure (who actually needs stuff this cheap & shitty?) but hopefully i can hack it up....

[Daedalus]

It's a strange one alright! Zipsticks etc. are wired directly to the Amiga, true, but those logic chips have similar input ranges to the Amiga's own logic so they should respond and the same way.

Yeah, something like that would be handy for hacking up for testing if nothing else. Good luck with it

[Steve T]

Yeah well i'd still like to get this working, It'll take weeks to get here and i'm going to continue to try and work out whats going on here...

So after a bit of rewiring, it'll play for much longer before glitching and the glitch is always now with the right direction, so the player will always move right...

Infact right from the start there seems to be a problem where trying to move right will halt the input from A, just for a frame or two. I notice this when using the soft autofire in hellfire on A, maybe it also applies to other buttons but i'm not sure... maybe this is normal behaviour but i don't think so.

it seems like the old chip had maybe malfunctioned on A and B and this one on Right, might simply be 2 defective chips but the replacement was brand new sealed perhaps i damaged it somehow... is it odd that they would both fail in a way that only shows itself after being on for a time? Or is it just a fault which is elsewhere and affecting both of the chips (which otherwise work perfectly) in slightly different ways, perhaps due to the changes I've made in the wiring and cleaning stuff up.

(BTW, there was never anything wrong with up and down, i'd left an up for jump modification (for use with amiga) on by mistake! So we can rule those controls out I guess, the fault it seems only ever been with what goes through the 157 chip itself.)

[Steve T]

Finally got round to looking at this again, rewired a lot of it (new wiring, avoiding soldering onto the chip itself), removed any old/new solder mix and resoldered or reflowed all the pins on the chip.... Seems to be working reliably now (hesitant to say its totally fixed!) but still not sure what the problem was, perhaps it was just something to do with how it had been put together.