Restoring a 5200 - advice and assistance needed

[+DrVenkman]

It's very, very odd that both VR's would be bad and would fail with completely 0 volts output. Usually 7805's will fail to a lower-than-normal voltage, or a higher-than-normal voltage. I've never had one go stone-dead, let alone 2 in the same system. Their failures also shouldn't have any effect on the input side of the pins.

 

I think something has fried the transistors and/or that 4013. 

 

 

[+-^CrossBow^-]

4 minutes ago, DrVenkman said:

It's very, very odd that both VR's would be bad and would fail with completely 0 volts output. Usually 7805's will fail to a lower-than-normal voltage, or a higher-than-normal voltage. I've never had one go stone-dead, let alone 2 in the same system. Their failures also shouldn't have any effect on the input side of the pins.

 

I think something has fried the transistors and/or that 4013. 

 

 

Exactly. I did have to replace a VR on a 5200 recently. VR1 to be exact as VR2 was reading properly but still a dead 5200. On that one I was still getting input voltage of about 10v but 0v on the output side. So they can go totally dead but like you I don't see them both doing it and not getting any input voltage indicates an issue before the VRs and not the VRs themselves.

 

[+x=usr(1536)]

7 hours ago, -^CrossBow^- said:

There was no need for a cap kit because there are only 3 electrolytics you can really replace in the 5200. The main one is the large filter cap and the other 2 are the poly audio caps that are the same used on the 2600 and 7800. So a Cap kit wasn't needed honestly.

 

Understood.  It was one of those things where it was cheap and I didn't want to have to order it separately if it was needed; couldn't see a good reason to run up another shipping charge.  Worst case, it sits around doing nothing until needed and / or gets cannibalised for other stuff.

 

Quote

 

I still think that either the MJEs are at fault or another component in front of the VRs. The MJEs basically get the full force of the input DC and will read about 12-13v thereabout. If it doesn't switch on at now or is flaky it could be the 4013 so I hope you got one of those on order? I think it comes with a socket but I can't be sure about that. BTW...won't help with the 4013 as that is a 14 pin IC, but there are two IC sockets on their way to you for use with the 4052 MUX chips if needed.

 

 

Yep, both the 4013 and DIP-14 socket are on order.  I've also gone back over the schematics a bit more, and am getting my head a little more around how things work in the power section as opposed to how I thought they worked.

 

7 hours ago, DrVenkman said:

It's very, very odd that both VR's would be bad and would fail with completely 0 volts output. Usually 7805's will fail to a lower-than-normal voltage, or a higher-than-normal voltage. I've never had one go stone-dead, let alone 2 in the same system. Their failures also shouldn't have any effect on the input side of the pins.

 

I think something has fried the transistors and/or that 4013. 

 

 

 

I'm in agreement with all of the above.  FWIW, I'm wondering if someone didn't try to run this off of an AC supply at one point.

[+x=usr(1536)]

  

Banged on this a bit more this evening.  Here's what was done:

Replaced both VRs.

Replaced 4013 and added a socket to it.

The RF modulator was not installed; I'm keeping that aside until the power issues are figured out.

 

The good news: no new problems cropped up.

 

The bad news: nothing was (ostensibly) fixed by doing this - results are basically the same as before.

 

Voltage at the 4013 is consistent with what was read out pre-socketing, and continuity testing after soldering in its socket suggested that all pins were successfully mated to the PCB.  Results were the same with both the two new and one original IC.

 

One interesting thing did crop up: bridging either emitter or collector to base on Q7 caused the power LED to go on steadily.  The power switch had no effect during this time, but the LED was lighting up far better than it had previously.

 

On 12/3/2020 at 3:19 PM, DrVenkman said:

I think something has fried the transistors and/or that 4013.

 

Q6 and Q7 are next up for replacement.  Thought I'd ordered them with the other components, but...  Nope.  *headdesk*

[+x=usr(1536)]

The transistors at Q6 and Q7 have been replaced.  No change.  It's like power just isn't getting over to the logic side of the board.  Readings are pretty much the same on everything that's been replaced so far as they were initially.

 

Just because I haven't mentioned it so far: pins 18 and 36 on the cartridge slot seem to have no effect on whether or not power goes where expected when the switch is pressed.

 

Is it possible that the issue is in the switch?  I'm reading continuity on a surprising number of its pins (in-circuit), but as I don't have much of an idea how the switch should operate beyond 'power goes here when pressed', I don't know if what I'm seeing at the pins matches how it should be working or not.

 

Any advice appreciated - right now, I'm running up against the wall with it.

[+x=usr(1536)]

Had some time this afternoon to take another look.  Unfortunately, I didn't make any significant progress: it's still not powering up fully.

 

Changes since the last update: replaced the power switch with a new one, installed the RF modulator that -^CrossBow^- sent me a while back, and replaced C45 with a fresh capacitor just in case.  Just for grins, tried three power supplies other than the one I had purchased; no dice.

 

Bridging emitter to collector or collector to base on Q7 still gets the power LED on solid, but that seems to be the only way to make that happen.

 

Other than shotgunning all of the transistors, I'm out of ideas.  If anyone has any, I'm all ears.

[+x=usr(1536)]

Watched @-^CrossBow^-'s 2-port repair livestream (and the follow-up video) last night, and noticed that he was having the same problem as I was, just in reverse - his system wouldn't power off, whereas mine won't power on.

 

The only significant difference I can see between the troubleshooting he's done and what I've done is that he removed the cartridge port, whereas I haven't.  It was checked for continuity and came out OK, so I decided to not pull it.

 

Time permitting, I'll pull the system out this weekend and follow the bouncing ball on his video.  There hasn't been any change since it was shelved in January, so I'll start at the beginning and follow along.

[+-^CrossBow^-]

Well, it ended up being two things although I'm not sure which caused which first.

 

Q7 ended up being the main culprit although the troubleshooting flowchart sure as heck kept telling me the issue was Q6 instead. But as you saw, I replaced out Q6 with no change. It wasn't until I actually removed q7 and then plugged in power that it didn't power on anymore automatically and was turning on/off normally at that point. So I then went ahead and installed the original 210 from Q6 that I removed and installed it into Q7. Sure enough it fired right up and was working again. However, after letting the Antic test running on the 2.3 diagnostics it suddenly began to corrupt on the graphics again and do other odd stuff. So I replaced out the ANTIC as well and from then on it was running Fractalus in demo mode for at least 2 hours followed by one of my better scoring and longer play sessions of The Last Starfighter without issue.

 

My guess is that Q7 actually went back and in the process goofed up something with the ANTIC but not enough to show up until it had been on for a while to get nice and warm.

 

But I eventually got there by starting with the ASAP principle. Always Start At Power.

 

[+x=usr(1536)]

Had a bit of free time this afternoon, so looked into this a bit further.  As it turns out, this is a fully-working 5200.  That said, the power issue remains. More:

 

18 hours ago, -^CrossBow^- said:

Well, it ended up being two things although I'm not sure which caused which first.

 

Q7 ended up being the main culprit although the troubleshooting flowchart sure as heck kept telling me the issue was Q6 instead. But as you saw, I replaced out Q6 with no change. It wasn't until I actually removed q7 and then plugged in power that it didn't power on anymore automatically and was turning on/off normally at that point. So I then went ahead and installed the original 210 from Q6 that I removed and installed it into Q7. Sure enough it fired right up and was working again. However, after letting the Antic test running on the 2.3 diagnostics it suddenly began to corrupt on the graphics again and do other odd stuff. So I replaced out the ANTIC as well and from then on it was running Fractalus in demo mode for at least 2 hours followed by one of my better scoring and longer play sessions of The Last Starfighter without issue.

 

Interesting re: Q6 because the problem I'm seeing is - as suspected - clearly centred around Q6 and Q7.

 

Basically, I got fed up with not knowing if either Q6 or Q7 were doing anything.  First test: bridge emitter to base followed by collector to base on Q6.  Nada, though there was a slight change in the snow pattern on the CRT the machine was connected to.  Performing the same test on Q7 caused a solid green screen to appear when either one was bridged to base.  Repeating the test on Q6 while also bridging Q7 caused the machine to spring to life; it didn't matter which way either transistor was bridged as long as both were bridged at the same time.  According to the brief game of Ms. Pac-Man that I was able to start and play, video, sound, and controls are working.

 

18 hours ago, -^CrossBow^- said:

My guess is that Q7 actually went back and in the process goofed up something with the ANTIC but not enough to show up until it had been on for a while to get nice and warm.

 

But I eventually got there by starting with the ASAP principle. Always Start At Power.

Understood.  I'll do some extended testing once I can get it to switch on and stay on.

 

However, this is the point where I need an adult because I'm not 100% certain where to go next with this.  Q6 and Q7 were both replaced in earlier troubleshooting.  I could replace Q6 and Q7 one at a time and see what happens, I suppose.

 

Any thoughts?  Given that this is now a known-working machine, I'd really like to get it back up and running properly.

[+-^CrossBow^-]

Well I spoke too soon. I was finalizing the wiring for the UAV this evening and fired it up to test it and sure enough within a few min, the graphics went totally south and it locked up. Loaded it up again and just had it running on the ANTIC test and within 30sec it started to show odd blocks of data on the screen and eventually got worse and worse.

 

I already replaced the ANTIC so it has to be something else at this point. Only Q7 has been replaced out as both of the VRs are still original and generating exactly +5 from them. 

 

 

[+x=usr(1536)]

@-^CrossBow^-: would you mind sanity-checking me on something?

 

From what I'm seeing in the 2-port schematics, bridging legs on Q6 and Q7 as I've been doing effectively bypasses the power switch - I think.  FWIW, the 4013 is showing 10.35V across pins 7 & 14 with the PSU plugged in.

 

Does this sound reasonable?  I'd appreciate it if you could let me know.

[+x=usr(1536)]

Success!  Of a major-but-minor sort, anyway

 

Replaced Q8 and Q9 with a couple of NTE 2N3904 transistors.  The power switch now works properly, and I can't say how thrilled I am for that to be the case.  As much as I enjoyed the Mad Max approach of bridging legs on Q6 and Q7 to achieve the same result, this is certainly far more civilised and infinitely more reliable.

 

Still have a bit of troubleshooting to do:

 

 

My other 5200 (also a 2-port) doesn't have the snow issue that this one does.  Courtesy of @Dopy25, who sent a channel switch and 4-port RF cable my way, I'll be able to permanently attach a more-correct internal RF cable to this one when the male RF jack to go with it arrives.  If it clears things up, great, but I'm not holding my breath because:

 

 

That's a lockup.  Takes about 20 minutes to get there from cold, and the CPU is hot enough when the lockup occurs that you really don't want to touch it for too terribly long.  I'll gather some heat measurements tomorrow after the machine's cooled down overnight, but as this machine is running as a bare board on a desk in my office that's right under a ceiling fan and the thermostat shows 72°F in the room, I'm thinking it's probably a bad CPU.  It is a Rockwell model, so... ?‍♂️

 

Either way, this machine is the one slated for modification (meaning a UAV), so I might also see if I can't get a Sally adapter to fit and go with a modern 6502.  Still, need to swap CPUs before I do that in order to make sure that this is where the problem actually is.  The video is probably a separate issue, but that one can be looked at after the CPU.

[+x=usr(1536)]

Memo to self: lockup was 6m35s from cold, and the CPU was ±30°F warmer than the other ICs.  The screen output was consistent with the photo above, so this is a reproducible event.

 

Evidently, the 20-minute number was how long it took me to observe that it had crashed, not how long it took for it to do it.  Will test again later today with a different cartridge and see what happens, but this one has run fine for a couple of hours in the other 5200 without issue.

[+-^CrossBow^-]

It is only the CPU that is getting warmer than the rest? All of the DRAM along the left hand side seems to be cool?

 

[+x=usr(1536)]

3 hours ago, -^CrossBow^- said:

It is only the CPU that is getting warmer than the rest? All of the DRAM along the left hand side seems to be cool?

Yep, that's exactly what's happening.

 

It is using a Rockwell CPU (C014806-12) that's in a date range (8250-up) known to be flaky, so I may as well replace it with a different manufacturer's Sally and see what happens.  If nothing else, it avoids having to potentially do the back-of-board mods to make the Rockwell work reliably - and if the Rockwell's getting hot anyway, it makes sense to R&R it.

[+-^CrossBow^-]

I was only asking because it isn't unusual for the ANTIC to get pretty warm as well as the CPU depending on what is going on. I usually use Fractalus as a burn in testing game since you can press the '0' key on the keypad and the game will play in 'Droid' mode to simulate someone playing the game.

 

 

[+x=usr(1536)]

1 hour ago, -^CrossBow^- said:

I was only asking because it isn't unusual for the ANTIC to get pretty warm as well as the CPU depending on what is going on. I usually use Fractalus as a burn in testing game since you can press the '0' key on the keypad and the game will play in 'Droid' mode to simulate someone playing the game.

Ah, gotcha, and thanks.

 

Apologies if I sounded a bit brusque; it certainly wasn't my intention.  Having to write replies here in-between everyone and their dog apparently wanting to call my phone today

[+-^CrossBow^-]

38 minutes ago, x=usr(1536) said:

Apologies if I sounded a bit brusque; it certainly wasn't my intention.  Having to write replies here in-between everyone and their dog apparently wanting to call my phone today

Didn't come across that way to me at all. Just trying to help isolate where the issue might be on this. Usually the glitching and lockups are caused by faulty RAM (As I was finally able to fix with the last one I worked on), or a bad IC that once it gets to temp, is when it starts to exhibit issues.

[+x=usr(1536)]

1 hour ago, -^CrossBow^- said:

Didn't come across that way to me at all. Just trying to help isolate where the issue might be on this.

Understood, and thanks ?

1 hour ago, -^CrossBow^- said:

Usually the glitching and lockups are caused by faulty RAM (As I was finally able to fix with the last one I worked on), or a bad IC that once it gets to temp, is when it starts to exhibit issues.

I certainly wouldn't rule out the RAM.  Unfortunately, I'm testing with limited tools, so don't have a good way at present to run diagnostics, etc.  An Atarimax cartridge is definitely in my future, at which point I'll hopefully be able to run some decent test suites.

 

FWIW, I checked and don't appear to have a copy of Rescue on Fractalus.  Choplifter stood in for it, and locked up at the 6m38s mark after the console was started from cold; the CPU was hot but everything else felt fine.  Ms. Pac-Man crashed at 6m35s, so this is in line with that result.  Blue Print is on standby for a third test once it cools down again, but I wouldn't be surprised to see something similar happen.

[+x=usr(1536)]

For reference (and the sake of my own memory), this is the work that has been performed up to this point:

• Bought a 12V, 5A regulated & switching PSU as the 5200 didn't come with one
• Replaced VR1 & VR2
• Replaced C45
• Replaced 4013
• Installed RF modulator
• Replaced power switch
• Replaced Q6 & Q7
• Installed channel switch
• Replaced Q8 & Q9
• Installed RF cable

As it sits now, the CPU is getting hot and the system can be made to lock up after about 6.5 minutes.

 

There is snow on the display as well.  May be digital, not RF-related.  Will check after CPU replacement.

 

Attached file describes the timing issues with Rockwell CPUs and the workaround that Atari recommended.  I'm just going for replacing it with a Synertek and seeing where things land.

Tech.Tip.07.pdf

[+x=usr(1536)]

Fibbed a little when I said that the RF cable was installed.  It was, but soldered directly to the motherboard.  I then decided that I didn't like that arrangement, so removed it and ordered a right-angle RCA plug to graft onto it in order to plug it into the RF output on the motherboard.  It did work, but given that I'm chasing multiple issues I wanted to stay as close to stock as possible during that process.

 

Overall, things went well.  Had to grind some of the centre pin on the RF plug down in order for it to fit the RF output's jack without standing tall, but that was no big deal.  Here it is with the material removed:

 

 

And a closeup of it installed.  I'm not concerned about it coming adrift; it's in there.

 

 

The connector's body is anodised metallic something-or-other, but I'm not concerned about it contacting other components as there is a lot of clearance between it and the PCB:

 

 

New CPUs should be arriving Monday.  Depending on how that goes, next steps after that may be chasing down the snowy picture per the FSM.

[+-^CrossBow^-]

I've just received in another 4-port unit to start working on this weekend as well. BTW there is enough on that RCA jack on the board that you can also desolder it and lift it up a bit more on the board. I've done that on a few so that my makeshift RF cable I use will fit better when testing things.

 

 

[+x=usr(1536)]

12 hours ago, -^CrossBow^- said:

I've just received in another 4-port unit to start working on this weekend as well. BTW there is enough on that RCA jack on the board that you can also desolder it and lift it up a bit more on the board. I've done that on a few so that my makeshift RF cable I use will fit better when testing things.

Thanks for the tip.  USPS says that CPUs are arriving today, so I may give that a shot while I'm in there

[+x=usr(1536)]

The Synertek CPU is in and Ms. Pac-Man has been running in attract mode for approximately 30 minutes without a lockup.  The CPU is also around the same temperature as the other ICs on the board, which is a huge improvement from being too hot to comfortably touch.

 

Gonna let this run for a few hours and see where it goes, but I think this may now be a fully-operational unit.  FWIW, there is still snow on the screen but some mild experimentation has shown that it may be RFI as opposed to a component issue.  Still need to find a definitive cause, but it's looking likely.

[john_q_atari]

I just got a 4 port today. Hooked it up with a switch box and I was getting a snowy picture, like a bad RF cable or something, but every once in awhile it would clear up and look pretty good for RF. Turned it on just now to test the sound, and the picture has been clean the whole time. Interesting. Not sure it's the same interference behavior as your snowy screen. Doesn't really matter I guess as I got this unit to convert to HDMI. Glad to hear your lockup problems appear to be fixed with a replacement CPU.