PatrickMc

Finally solved it! 🤬🎉 To keep the thread complete for others who may have similar symptoms down the road: It turns out that it was actually two bad video memory chips (4164s from a +5V mod). Interestingly, both chips passed testing with two different external testers and it wasn't until I pulled the sockets to check for exposed/corroded/degraded traces that I noticed the behavior slightly change as I started to check and repopulate the sockets. As a final step, I plugged the two suspect chips into a different system -- identical behavior. Lesson learned about having too much faith in a chip tester... Thanks again @Tekman for your help. Happy New Year!

Thanks once again @Tekman. After several days of checking continuity, reflowing anything and everything, socketing and testing the ICs (everything but the controllers -- I feel like I'm pushing my luck on not lifting a trace -- especially so with Coleco's fun habit of bending pins over on the ICs), trying both hot and cold tests again without any luck, and I'm still stuck in finding any culprits. While I found several questionable pins on the ICs, there were no signs of a bad connection anywhere. I rechecked the address and data lines and they still look reasonable. For fun (grasping at straws?), I've added a couple of images showing the power-up symptoms just in case they might provide a clue (apologies for the funky oversaturated colors). I've fixed a few systems with bad VRAM but never seen this before. The green pattern starts somewhat sparse and noisy and grows in intensity over time. Eventually all the noise stops and the display is steady but still scrambled with the green solid and no longer noisy. The 2nd image shows the screen about 5 seconds before this final stage. If I then push the reset button everything runs normally from there. The logo screen (no cartridge in this case) shows what I would consider VRAM issues if the green were to be removed. As a reminder, the video output is essentially identical over RF and an RGB mod output. I ran out of time tonight but the last thing I noticed was the VDP clock seems to jump around by about 2-4 MHz, and occasionally when I probe the VDP pin (40) the screen will go blank and/or noisy. Occasionally I see what amounts to a shifted clock signal on the scope along with the original signal. I didn't get to double check the trigger settings but I don't recall the other clock signals behaving this way on the scope. It happens both during the startup issues as well as when the system appears to be working fine. I'm still trying to wrap my head around the clock circuit. In my last set of tests I found that if I powered off, placed the oscilloscope probe, and powered back up, the system would occasionally fail to display an image. A signal was present and the clock was active but only an empty (all black) output image was making it to the TV. This happened once with the system powered up too but the system could have gone into the screen save mode. I certainly have more homework to do...

Thanks again @Tekman, I too was hoping freeze spray was going to reveal the issue. I carefully worked my way section by section, initially focusing around the VDP and VRAM. Did not even flicker... Then I worked out to the BIOS, CPU, and address translation ICs. No joy... Even though I have no issues with the audio or controllers I gave them a squirt... Nada... I then dropped in a TMS-RGB to bypass the modulator... TMS-RGB works fine -- I now get a nice clean version of the same symptoms. 😊 I finally just went ahead and swapped out and socketed the CPU and the BIOS (updating to no-skip). In part I guess I was hoping to knock something loose in the process. Unfortunately, also no change. I can't imagine any of the bypass caps causing problems but (from what I have read) they can cause startup issues but I have never seen that happen. None of them look damaged and I've reflowed all the of them on the board. Would they actually ever be intermittent like this? That leaves the LS logic in the address translation and the clock sections... I checked the clock signal from power-on (at CPU and VDP) and it all look fine. This board is quickly becoming a good candidate for a fully-socketed "tester"...

Thanks @Tekman! Unfortunately, no luck with the tap test -- system was stable. I really worked the power switch over and it didn't blink. So I've ordered a can of freeze spray and I'll give it a go in a couple of days... However... I noticed a slightly different behavior today. I was walking through various checks again and the VDP I desoldered has very short pins and I keep wondering about the socket connections. So, I swapped out the VDP again but this time around the system had reached a working "warm" state. The earlier swap-out was when the system was cold. This VDP has full length pins and the system powered up with a noisy screen and followed the same symptoms I've seen from a cold start... I was expecting it to be OK as the system had warmed up -- with of course the exception of the VDP... The system continued to follow the overall pattern of eventually reaching a working state... Let the fun continue! 😊

Hi all, Working on a restoration+mod and have hit a problem that I can't figure out. I've cleaned up the power switch (disassembled cleaned and reinstalled), done the +5V VRAM mod, and fixed a bad RF jack. All voltages and related details (e.g., traces) look and check out OK across all RAM and ICs. The problem happens on an initial power up after the system has been off for a while. When cold the system starts up with a garbled screen that would suggest a bad VRAM or power switch problem. However, after about a minute the garbled image changes -- mostly identified by a lack of changing output (goes static -- as in no movement). At that point, either power cycling or pushing reset will result in a decent image, sound, and I can play games without any issues. I have tested for about 10 minutes and everything remains working without issue -- I've done this many, many times now... I can turn the system off and then back on and everything is fine unless I let it sit for a while and then the problem will return and behave exactly as before (with not identical but very similar garbled images). Wash, rinse, repeat... I overhauled the switch and did the +5V VRAM mod as the system behaved this way from the outset (although at the time I didn't leave it powered on long enough to know it would stabilize). I've run the VRAM chips all through repeated cycles in a tester -- all OK. This happens with or without a cartridge. I've desoldered the VDP and put in a socket, swapped to a known working VDP, and the problem remains identical. I've reworked the power connection to the PCB and tried multiple PSUs that all work fine w/ another system -- no change. I removed and reworked all the solder joints on the modulator -- no change. I finally replaced all the electrolytic caps -- same story. At this point I'm down to pondering if there is a flaky decoupling cap lurking or something similar in the internals of one of the ICs... Unfortunately, the way the system begins to stabilize once powered on has made it difficult to hunt anything down. Sure feels like a long haul ahead so I thought I'd check in here. Any additional ideas and suggestions? Thanks. --Patrick

Quick update: I focused on further Pitfall cartridge testing today by comparing the original cartridge to a flash-cart version. The original cartridge always locks up and I had zero issues with the flash-based version. So, it does indeed appear that the original cartridge was an issue perhaps due to a failing ROM or bad solder joint. It will be interesting to see if H.E.R.O. ends up in a similar situation. So, my first experience with a "sort of" working cartridge that was certainly fun when trying to test a repaired and mod'ed console up and running for the first time.

Hi all, I've just finished a fairly significant overhaul on a Colecovision that was in pretty rough shape (dirty power switch, bad video RAM, a bad sound chip, and a bad hex buffer). With that many problems I went ahead and did a +5V RAM upgrade, added the TMS-RGB mod, and added a no-wait BIOS (fire-to-skip version). Everything seems to be in good shape (no more video artifacts, sound is very clear, etc.) but this evening I had some very odd crashes when testing both Pitfall and H.E.R.O. Both games somewhat randomly die to a black screen and then eventually start running again from the start -- as if reset was pressed. However, this is short-lived as both games crash again and typically much sooner in comparison to the initial crash (within seconds of trying to start playing again). I have also played Frogger and Spy Hunter several times for a bit over 15 minutes each time and did not have any similar problems. The fact that two Activision cartridges are acting up seems a bit odd to me... I've carefully traced through all the address and data lines for the +5V RAM as well as tested each VRAM chip individually outside of the console and spotted no issues. It would appear that I can always get the two Activision cartridges to eventually crash. I have never had either of them last for more than a few minutes at most (I still need to test more to be 100% confident but something does seem to be funky). Has anyone seen something like this before? Any suggestions for next steps? Thanks, --Patrick

Hi @fiddlepaddle -- managed to find another one this evening! Thanks! ?

Hello all, I've been working on my first restoration and associated troubleshooting of a 7800 console. I'm flummoxed and wanted to reach out to the community to see anyone has had a similar experience. Sorry in advance for the rambling summary. ? NTSC w/ a revision B system board. Main symptom is a black screen w/ no audio -- sometimes... The Atari logo consistently shows up on power up. More below. Console all the way apart, cartridge cup removed, pins cleaned, replaced all caps after finding that the 2200uF was not in great shape. Also replaced the power regulator and power switch while I was at it. All voltages look good now at the ICs and along the main power rail. In response to the no audio issue, I've walked the troubleshooting flowcharts (many times) and typically end up on flowchart E where it mentions the encryption latch. I don't have the diagnostic or color cartridge so skipped those steps. As a result of the encryption latch tip, I've checked the logic ICs and outputs all look correct. In other words, they produce the correct results based on the input signals they receive. For the vast majority of the time the system swaps between initially working and then mostly failing -- I'd guess the failure rate is easily over 90 percent following this pattern. For the first week or so I was using a known working Galaga cartridge but then I started to get suspicious. While it always works in another console, most of the time it does not on this particular system. Furthermore, I can't reproduce the glitch with other cartridges -- e.g., Centipede and Donkey Kong both appear to always work as do a few others but I don't have a lot of cartridges to test with. In revisiting the logic chips related to the encryption latch I noticed the signal from the A12 address line from the 6502 looked stuck -- any time I see this particular signal coming from A12 it is a dead giveaway that the system will come up with the black screen and hang (it initially doesn't look like this but then will suddenly "snap" in). Here's a look at what I see on my scope for A12 -- it will stay like this as long as I leave power to the system the CPU is clearly wedged). In looking at the schematic, A12 comes off the 6502 at pin 22 and routes over to pin 8 of the cartridge slot via U4's (74LS08N) output pin #8. I re-cleaned the pins on Galaga (even removing the PCB to get a good look at them, and then re-cleaned the slot and reflowed all the pins. No luck. My next thought was that the vast majority of the time that Galaga actually runs is when the system sat powered down for a while. So, if I leave it idle for several minutes it seems to almost always work on the first power up and then fail for the vast majority of the following times when the system is power cycled with little rest in between. The 6502 does occasionally feel somewhat hot (but not too hot to touch) as I was running through other troubleshooting phases (perhaps not too surprising if it is locked up). After using some compressed air to "freeze spray" the 6502, Galaga successfully started up 10 times in a row. Once things had a chance to warm back up again the system returned to its lock-up behavior. No surprises here: My conclusion is the 6502 is potentially starting to fail but I can't wrap my head around why only Galaga triggers this behavior. The locked up signal on A12 could easily be the result of something else happening that I haven't observed. I haven't done an exhaustive walk of all address and data lines as I'm not familiar with all the low-level startup details for the system. I would find it very odd that Galaga just so happens to have a particular set of instructions that cause the system to hang. What are the odds? ? I have removed and socketed the 6502 and the same behavior continues. My plan is to start a search for a replacement Sally to see if that helps validate the diagnosis... Have I missed something obvious? Has anyone else seen similar behaviors? Thanks for any insight you can provide!

Thanks to all! The help is much appreciated! ?

Hi, First time poster with my first system that is in a bit of rough shape. Machine was pretty much DOA on arrival but when I opened it up it was clear why…. The crystal for the CPU clock circuit was loose and floating around inside the case. Unfortunately, it broke off right at the base and there is no way I can see to solder it back in place. This is the 48MHz version of the board but I can’t find an exact replacement for the original part. Given this is my first TI-99/4A, how precise do I need to match the original specs? Any pointers to suitable replacements would be much appreciated. Thanks!