Jump to content
  • entries
    44
  • comments
    88
  • views
    15,200

Weird Paddle 3 issue on a 2600 4-switch?!


CrossBow

496 views

I've seen something similar to this before although not in the way I was seeing with a recent 4 switch console I was servicing. As part of diagnostics I will use Paul Slocum's excellent Test Cart program as it should some primary colors, shows the current state of all switches minus power of course, but also has a basic graphical view of each controller and small block on the bottom that will move left/right when you plug in paddles to test those too. So all in all a nice utility to know that all controller functions are working properly on the console.

Well, on this one, player 1, player 2, and player 4 paddle controls would move from left to right and back turning the paddle as you would expect. But player 3 paddle control would just site on the left side, and then after a point when turning the paddle, it would suddenly just be on the right. No movement of any kind. Just one sec on the left, and then next thing you know it is on the right. So it was acting more like a digital control vs analog. It wasn't the paddles since I used the same set to test player 1 and 2 and that was working fine.

Going through the service manual will yield some interesting stuff to help isolate this, but unless you have the diagnostic controller plugs and the 2.6 diagnostic rom, you aren't going to be able to see exactly what you need to see. But lets review that..

If you have the diagnostic plugs, plugged into the controller ports and the diagnostic rom up and running with the controller matrix screen up. Then you use an Oscilliscope to probe the paddle lines off the TIA pins 37,38,39, and 40. They represent player 4, 3, 2, and then player 1 on pin 40. Well, what you should see on your scope if you have it set to the right settings, is something like the picture below from the service manual:

image.png.87bbeb732e7d27a315b22391a1c19195.png

 

However, when I probed pin 38 that is for the player 3 paddle line. I was getting a flat line. Well, actually I was showing a flat line of about 1v but the point is...not pulse like you see in those pictures. (And btw...I was seeing that same pulse line on my o'scope for the other paddles). 

Well honestly there isn't much in the way of electronics from the controller port to the TIA where the paddles are read and handled. In fact, there is really only 1...just 1 component in the middle of the mix from the controller port to TIA. At least on the 4 switch and above units this is the case. That one component is usually a small ceramic disc, or poly capacitor that doesn't usually go bad. So I first checked that the traces from pin 5 of the player 2 controller port to that cap (C220) was good. It was, and then checked from the cap to pin 38 of the TIA. That too pinged out good. So I went ahead and replaced the capacitor just to see if anything changed. Sadly.... no.

What did fix it?

Well, if you've gotten this far and read my description of the very simple circuit from port to TIA... it should come as no surprise that is was the TIA itself. This is even more sad considering how rare these IC chips are now becoming and there isn't any projects I'm aware of to make new ones or something to replace the TIA. 

But yeah... if you find the paddle lines aren't working, chances are that it is the TIA chip itself that has failed if the actual traces are good. Apparently this was less of an issue with earlier 2600s as they used buffer ICs to help control this and therefore the TIA was more protected. Just more cost cutting at work as the console lived on...

 

 

4 Comments


Recommended Comments

I think the issue is that the "dumping" transistor (in red in the attached excerpt from the TIA schematics) for that paddle line is bad (shorted).

TIA_inputs.png.d409dc20d678b261c833247a71f6f60f.png

Each paddle line has one of those and they are activated (all 4 at the same time) by the "DUMP" signal shown in the diagram, which is under software control (the program writes to a TIA register to enable or disable it).
The purpose is to discharge the capacitors attached to the paddle lines. After doing so the program disables the transistors again and then keeps checking the paddle lines and measures the time it takes for them to switch to a digital "1". That time is determined by the RC circuit formed by the (fixed) capacitor in the console and the (variable) resistor in the paddle controller itself, and it's therefore proportional to the position of the pot. That's how 2600 games read the paddles.

The bad transistor is the reason why you don't see the pulses on the scope.

Note that the TIA paddle inputs are strictly DIGITAL (they only read "1" or "0"), and apart for those additional transistors, they're identical to the joystick triggers ones.

The "shorted" transistor  results in a low resistance between the paddle input and GND. When you have a paddle controller plugged in, you add another variable resistor between the line and +5V, obtaining a simple voltage divider.

And so depending on the position of the pot you either get a logical "1" (voltage above a threshold value)  or "0" (below that value). The cap is never discharged and just keeps that same voltage determined by the divider. So there's no charging time to be measured.

That's why the paddle just sits either on one or the other side of the screen in the Testcart.

 

Link to comment

Thank you for the detailed explanation on it all Alex! But again, in this case the failed transistor is located where....? 

Inside the TIA. So I guess it is awesome to know what is failed in this case, but still stinks because it isn't something that can be fixed. Unless it were possible to just wire in an actual transistor to handle this externally on a small perf board or just wired into the system directly and then shrink wrapped up? Hmm... a bodge to allow a 95% working TIA to still be used for 100% functionality in a console. 

I'm kinda like the idea of this...

 

Link to comment
8 minutes ago, CrossBow said:

Thank you for the detailed explanation on it all Alex! But again, in this case the failed transistor is located where....? 

Inside the TIA.

Yes, absolutely. 

My post was just meant as an explanation of why you got that specific behavior with the Test Cart, but the diagnosis still stands: the TIA is toasted.😄

5 minutes ago, CrossBow said:

Unless it were possible to just wire in an actual transistor to handle this externally on a small perf board or just wired into the system directly and then shrink wrapped up?

 

I don't think it is possible. It's not only that you need to watch the CPU address and data bus to see when the program writes to the TIA register used to turn those transistors ON and OFF (not impossible, but surely complicates things a bit), as that "DUMP" signal is not available outside the TIA, but the fact that you'd need to remove the bad transistor from the circuit for this to work!

Link to comment
1 hour ago, alex_79 said:

I don't think it is possible. It's not only that you need to watch the CPU address and data bus to see when the program writes to the TIA register used to turn those transistors ON and OFF (not impossible, but surely complicates things a bit), as that "DUMP" signal is not available outside the TIA, but the fact that you'd need to remove the bad transistor from the circuit for this to work!

Ah.. I see. I wasn't sure if that signal was available outside of the TIA to be found elsewhere or from another pin etc. 

I wonder if the cost to need ratio just isn't there for a new TIA replacement to be produced or hardware emulated/simulated off a PCB?

 

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Restore formatting

  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...
×
×
  • Create New...