pseudo_intellectual

I had an identical problem which turned out to be the CPU SRAM instead of the VDP DRAM. If it helps, I documented my travails in another topic a few years ago (scroll down): http://atariage.com/forums/topic/183844-colecovision-crisis/ If you can get one, a logic probe is useful to see if the CPU is doing anything useful on startup.

I sold a few game things off of eBay last year. I think I ended up paying 10% to eBay and another 2% to PayPal. Those percentages were paid out based on the cost of the item plus shipping, and their shipping calculator shorted me (though this I acknowledge was my fault). Considering those costs (in money) plus the cost of my time packing the item properly and getting it to the post office, I'd have been better just sending the stuff over to the used video game store even if they were offering me significantly less. Maybe selling the item wasn't worth it to the seller unless the margin was large enough? If they were only going to net a few bucks at best on the item, I can see why they'd rather not bother selling it at a more reasonable price. I know how you feel about things being common priced high, and I've been frustrated at times by this also, but I can also see where some of these sellers may be coming from.

I recently had a ColecoVision which only produced a black screen. It wasn't due to the VDP DRAM, as many mention on here, but rather the SRAM used by the CPU. I wonder how common a failure that is.

Update: I received replacement SRAM today and after installing it... SUCCESS! The COLECOVISION logo appears and I am now able to play games. With that in mind if anyone is having similar issues: * The VDP and its RAM are not always to blame for no video. In my case the original 4116 VRAM was just fine, as well as the VDP. * Pay attention to the outputs on U5 and U6 (74LS138). Observe chip select activity on the VDP. If there is activity here on each reset, the BIOS is probably working. * If you see write access to the VDP RAM and the output (pin 14) goes low on all 8 of the RAM ICs, the BIOS successfully executed its VRAM clear routine. That is assuming you also see activity on the VDP RAM refresh and address signals. * If everything else appears to be working, the SRAM may very well be the culprit. I'm using MBM2148 SRAM, which at 55ns is quite overkill. However, I happened to find a pretty good deal for a pack of 10 on eBay, so I went with that. NTE sells a direct replacement for the 2114 SRAM, but you do not want it: I've seen it priced between $10-$12 APIECE (because you'll be needing 2). So now all I need to do is get the composite mod done and I can sew this bad boy up.

I thought I'd document some of my troubleshooting experiences for the same issue. I have a ColecoVision which is doing approximately the same thing as the OP. The screen is black and I hear no audio. Trying to "fly blind" with the controller in attempt to start a game without video yields nothing. After poking around I believe I have bad SRAM. I will find out in a few days if this is true once I get replacements. Here's how I am making that conclusion: Using a logic probe, I can see that there is bus activity. Various chip selects are being pulsed. Most importantly, there is write access to the VDP consistently on startup. At this point I'm fairly confident that the CPU and at least some of the BIOS is functioning normally. Could it be the VDP or its RAM? Well, I can see that the /RAS and /CAS signals are going to the VRAM. Based on the outputs on each of the RAM ICs, I can see that it is successfully clearing the video memory. I found the listing for the BIOS and I can see that this is one of the first things it does. There could be problems with the VDP (the /INT signal is always low; is that normal?). I happened to have a TMS9918 floating around which is pin-compatible except for the video output. I isolate these signals from the socket I installed and gave it a go. The bus activity is unchanged from the original VDP. This, I acknowledge, is probably not a good way to isolate the VDP, but it was all I have to work with at the moment. Could it be that part of the BIOS is corrupted? I suddenly realize I have an eBay EPROM programmer and after wiring a socket adapter I dump its contents. Its checksum matches a version of the BIOS I downloaded. At this point I am convinced that the BIOS is good. I look at the BIOS source code some more and I realize that the call to clear the VRAM pushes the stack. I wonder if the SRAM contents are corrupted (or the address lines are messed up somehow) and the CPU is returning to a bad location in the BIOS address space. Indeed I see that the CPU is perpetually accessing addresses in that area. At this point I am convinced that there is a problem here. I thought about doing a pattern test of the RAM on perfboard with a PIC or by wiring it to the EPROM programmer somehow, but I suspect by the time I get it going I will have received the replacement SRAM. Soooo.... I will find out if my prognosis is correct. Perhaps there something others may want me to try?

In case anyone cares, I did eventually manage to find a solution using a switching 5V regulator and a charge pump inverter for -5V. I particularly like the switching regulator since it is rated for 1.5A and it emits no detectable heat. It also only cost about $4.20. Since my 12V power supply is already regulated, it goes right into the board. Once I figure out why the I am getting no video (a problem this particular ColecoVision had to start with), I'll make a small hole for the power supply connector. Anyway, if someone happens to have an external 12V supply floating around, making use of it appears to be quite workable.

Just curious: has anyone gone about using the relulators-inside-ColecoVision approach that the original poster is proposing? I'd like to do something similar. I am missing the original brick but I have a fairly powerful 12V external SMPS I think I can use if I can get the additional 5V and -5V sources the ColecoVision requires. Is the 7805 and its equivalent -5V (7905?) regulator up to the task? What kind of load should I expect the ColecoVision to put it under, and how warm should I expect the regulators to get? I see that this site has power ratings: http://www.colecovision.dk/technical.htm But there is a decimal discrepancy between the adapter photos and the schematic, so I'm not entirely sure.

When I did a search for "U38", I discovered that there were tons of topics concerning the voltage regulators already. Wanting to ask a related question without creating a brand new post, I picked a topic and tacked my question on the end of it. It wasn't my intention to dredge unpleasant memories

As it happens I received a Jaguar with this apparently very common problem. I have obvious damage to U38, and the magic smoke in C134 appears not to have escaped. I'm also preemptively replacing REG1; I see voltage on VIN but nothing on VOUT. I'm scratching my head as to how the original owner managed to reverse-bias the power input. The thing shipped with the original power supply. Maybe he/she was working in the dark and grabbed the wrong adapter. Anyway, the regulators have been desoldered and the parts are in my shopping cart. Before I pull the trigger, I was curious if anyone has found other manifestations of using the wrong power supply so I have all my bases covered. Also, has anyone bothered to put in any kind of protection diode as a modification? If so, how did you go about it?

With regard to theone of the original poster's questions: is there a source for that SIO connector? Come to think of it, what is it with console manufacturers and proprietary connectors? Was there really such a dearth of off the shelf connectors that they had to engineer a new one? Or is it because of something more sinister (some futile attempt to lock out third party peripherals)?

Just thought I'd follow up with what happened after the last post, if for no other reason than to help others in a similar situation. It turns out that the delay line (U29) was, in fact, the culprit. I got a replacement from Best Electronics and after putting it in the machine fired up immediately. Better yet, there doesn't appear to be any other damage. The self test finds all the RAM successfully and I didn't encounter any other problems while playing the few game cartridges I have. Is the delay line a frequently failing component? I got this thing off of eBay for $7 +shipping which may have been too much considering the work and parts I had to put into it. In hindsight, something should have tipped me off when he was parting the disk drive and the software separately and his description said something to the effect of "the power light comes on but I didn't have a video cable to test further." On the other hand, I probably got more entertainment value troubleshooting it than if it worked immediately. Now all I have to do is go find something to do with it. I've never written 6502 assembly before; maybe it's time to learn Thanks all to who gave suggestions.

Bob: Thanks for your response. I had a few days to sleep on the problem and in light of your suggestions I decided to lug it out for some more troubleshooting. I initially looked at the RAM, but not nearly as much as I should have (and my observations probably reflect that). I'm not familiar with DRAM refresh circuity, so a lot of what was going on in the schematic was confusing me. I suppose it is as good of a time as any to learn. I see that the /RAS and /CAS signals are pulsing, as are the data in and data out ports on all 8 of the DRAM ICs. Suddenly I realized that the /WE was stuck high the entire time (can't believe I missed that). I see the CPU is properly pulsing this signal, but it is not passing through the output of U28. It turns out that the latch signal on U28 is driven by pin 6 of the delay line, which is stuck on high the entire time. Based on this, I'm wondering if this is the culprit; I can't see the CPU having a lot of success writing to RAM if the write enable on the DRAM is stuck. What do you think of this? I don't have any detailed documents on the delay line so I may be grasping at straws. Even if I am correct in that I need a delay line, I suspect I'm going to have a lot of trouble finding one unless it comes out of another dead system, so I may have to concede that I'll have to wait for a spare unless someone has some spare delay line ICs floating around... PS: Forgot to mention that the "delay line" I'm referring to is U29.

I have an 800XL with essentially the same problem. Whether using the RF or composite connections, I see a brief flash on the screen followed by solid black video. No noise is present when I press the keys. This occurs regardless of whether I am using a cartridge (I've tried several) or without. The first thing I do, seeing that all the ICs are socketed, is remove them with a chip puller and reseat them. I didn't observe any rust or oxidation on any of the ICs I reseated. Armed with a meter, logic probe, and some schematics I started digging. With these in hand I made the following observations: * The power is good. I see +5V on all the ICs which require it. * The CPU appears to be functioning. I see pulsing of the address and data lines. The reset circuit also appears to be functioning. I see the /RESET signal pulse on it remains HIGH shortly after releasing the reset button. * The peripheral chip selects for the PIA, POKEY, and GTIA are being pulsed, which appears to indicate that the CPU, for its part, is attempting to access the address space of these ICs. This seems to preclude that the address decoding circuitry and the MMU is at fault. The /HALT signal is being pulsed continuously. This signal is responsible for determining address bus access between the ANTIC and the CPU, right? * The chip select for the OS ROM pulses continuously for 2-3 seconds before remaining high until the next reset. * I never see the chip select for the BASIC ROM be driven low with repeated resets. * I see that the PIA is using some of the PORTB pins to drive the MMU. However, I never see PB0, PB1, or PB7 pulse whatsoever. I do see that PB2 and PB3 pulse momentarily on startup so I am assuming (perhaps mistakenly) that the CPU is somehow able to initialize PORTB on the PIA. Perhaps the PIA is okay? Would the machine give me anything other than a black screen if the PIA was malfunctioning? * I am not at all certain about the GTIA and the ANTIC. I can only assume that the GTIA is providing a valid signal. The voltage levels coming off of the video amplifier appear to be okay and my television's OSD clears when the machine is on and reappears when it's off. To know any more would require a scope, it seems. * I have no way to determine if the RAM is good. Changing the RAM positions didn't affect the outcome. * I really wanted to get to the self test, but I've been unable to activate it (pressing OPTION along with reset, right?). Unfortunately, I haven't a spare machine to swap ICs. Save for the RAM and (maybe?) the 6520, it appears that everything else will require finding another machine to swap parts. Does anyone have any recommendations about isolating the particular part (or parts). I'd like to troubleshoot this thing as intelligently as I can, and I had hoped that perhaps someone has run into similar issues or would otherwise know what this machine should be (or not be) doing within the first few seconds of flipping the switch. Thanks in advance!