Black Screen issue with Colecovision

[ChildOfCv]

Cool. And one thing I realized: Perhaps someone attempted to replace one of those chips, but lifted pads or something. Do you see any evidence of post-manufacture solder there?

[vgcollector]

I have not seen any evidence of prior work on this board. All of the solder joints seem to be original. I think I could spot that especially as close as I have looked at this particular board. I will check those spots tonight and update my post when I get that done. I will also look for broken traces. I would think that a broken trace wouldn't happen with the board seated like it is. Is there any chip you are leaning towards as being the culprit yet? Thanks

[vgcollector]

One other question. If there is a broken trace, am I looking for the break on the top of the board or on the bottom. I figure I might as well check the traces while I am testing the pins.

[ChildOfCv]

Yes, definitely make sure the pins are connected with an ohm meter (power off).

 

At the moment, I don't have a strong suspicion about any of the chips until we see the re-check of the pins. But if you really have activity on all the data pins at the memory chips, but nothing at the VDC on that one pin, then that does mean there is a trace breakage somewhere.

 

Just fair warning: The PCB traces I showed were my own routing and do not necessarily match the board. I routed the traces in order to compare every connection manually. But without removing large chips, I couldn't see those parts of the board well enough to run the traces exactly as they were. But the pin connections themselves will be correct.

[vgcollector]

Yes, definitely make sure the pins are connected with an ohm meter (power off).

 

At the moment, I don't have a strong suspicion about any of the chips until we see the re-check of the pins. But if you really have activity on all the data pins at the memory chips, but nothing at the VDC on that one pin, then that does mean there is a trace breakage somewhere.

 

Just fair warning: The PCB traces I showed were my own routing and do not necessarily match the board. I routed the traces in order to compare every connection manually. But without removing large chips, I couldn't see those parts of the board well enough to run the traces exactly as they were. But the pin connections themselves will be correct.

Sorry for the late post on this, but here are my latest readings on U3 & U4. I put these into Excel so I could concentrate on the readings.

 

Second Test Chip U3 Chip U4 Pin# Low/High Blinking Tone Pin# Low/High Blinking Tone 1 Both Yes Low 1 Both Yes Low 2 Both Yes Low 2 Both Yes Low 3 Low Yes Low 3 Low Yes Low 4 Both Yes High 4 Both Yes High 5 Both Yes Low 5 Both Yes Low 6 Both Yes High 6 Both Yes High 7 Both Yes High 7 Both Yes High 8 High No Low 8 High No Low 9 Low No High 9 Low No High 10 High No High 10 High No High 11 Both Yes High 11* Low Yes Low 12 Low Yes Low 12 Low Yes Low 13 Low Yes Low 13 Low Yes Low 14 Low Yes Low 14* Low No High 15 Both Yes Low 15 Both Yes High 16 Both Yes Low 16 Both Yes High 17 Low No High 17 Low No High 18 High No Low 18 High No Low

I put an asterisk next to the readings on U4 that were way different than U3. Thanks. I was a little more precise this time.

[vgcollector]

Hi, I tried to copy the U3 & U4 second readings list from my spreadsheet but it wouldn't let me attach it or copy it in. I have attached a snip it of what my findings were. Let me know what you think.

Edited February 27, 2019 by vgcollector

[ChildOfCv]

Okay, these readings are consistent: D4 is still stuck low (which is also pin 21 of the VDC), and neither memory chip is going active. A7 never blinks, which led me to research what the z80 does for memory refreshes. Turns out, it never changes bit 7 on refresh! Interesting. So unless it's addressing memory in the xx8x range, we can expect this to never change. But if it is running code, I'd expect it to trip over that. Makes me wonder if it happened to encounter a HALT instruction and is now just asleep. What does CPU pin 18 read? Edit: You indicated that U8 pins 5 and 6 are blinking, so that indicates that instruction fetches are happening, which means not asleep. But confirmation for sanity is still a good thing

 

 

I'd like to see if there's any attempt to access the ROM chip, but this one is a bit tricky: Some board versions only use a 24-pin ROM chip. Some use a 28-pin ROM socket but still use a 24-pin chip. And some use a 28-pin ROM chip in a 28-pin socket. I'll attempt to diagram it.

 14 13 12 11 10  9  8  7  6  5  4  3  2  1
+-----------------------------------+-----+
|                                   |     |
|                                  _|    _|
|                                 (_|   (_|
|                                   |     |
|                                   |     |
+-----------------------------------+-----+
 15 16 17 18 19 20 21 22 23 24 25 26 27 28

So if you have the short chip, your pins will be numbered 3-26. 1, 2, 27, and 28, if your board has them, will be bare holes. I'll go ahead and use that numbering regardless of how long the socket is.

 

Anyway I'm curious if pin 22 is blinking.

 

U5 is the next stop. Use the same pin diagram as for U6. And actually you ought to see about the same conditions on each pin, except for its outputs:

 

16 - +5V. High.

15 - ROM select, connected to pin 22 of the ROM chip. Should be blinking.

14 - Expansion select. Probably won't be blinking, though with the CPU running random code nothing would be too surprising.

13 - Other expansion select. Ditto.

12 - Memory select. We've already noted that this one is not active.

11 - Cartridge select, bank 1. It might be blinking.

10 - Cartridge select, bank 2. Again, might be blinking, but probably not.

9 - Cartridge select, bank 3.

8 - Ground. Low

7 - Cartridge select, bank 4.

6 - Memory map override. High.

5 - Memory refresh. Blinking, mostly low.

4 - Memory request. Blinking.

3 - A15. Probably blinking.

2 - A14. Probably blinking.

1 - A13. Probably blinking.

Edited February 27, 2019 by ChildOfCv

[vgcollector]

Sorry I didn't see your reply to my post I will check these tonight. I usually get an email on new posts, and I didn't check.

 

Thanks

[vgcollector]

Sorry I didn't see your reply to my post I will check these tonight. I usually get an email on new posts, and I didn't check.

 

Thanks

I tested CPU pin 22 and it was High, no blinking, and High tone. I tested the U5 chip and mine had 24 pins(short chip) so 1 and 2 were empty as well as pins 27 & 28. So just to clarify the first chip I did the reading on was #3. Let me know what you think of these readings. Thanks

[ChildOfCv]

Sorry I didn't see your reply to my post I will check these tonight. I usually get an email on new posts, and I didn't check.

 

Thanks

 

One more thing: could you try hitting reset a few times while holding the probe on 22 to see if there's at least a blink of access?

[vgcollector]

I tested CPU pin 22 and it was High, no blinking, and High tone. I tested the U5 chip and mine had 24 pins(short chip) so 1 and 2 were empty as well as pins 27 & 28. So just to clarify the first chip I did the reading on was #3. Let me know what you think of these readings. Thanks

The test above was for U2. Testing U5 now.

[vgcollector]

The test above was for U2. Testing U5 now.

Ok, tested the real U5 16 pins.Just to clarify the first set of readings is for U2, and the 2nd set is U5.

[ChildOfCv]

Well this is weird again then.

 

U5 seems to be working as it ought to: The address consistently lies in the ROM region, and it is indeed attempting to activate the ROM chip. Pin 15 is electrically connected to U2 pin 22, so it also ought to be showing the same readings. With power off, check continuity there. Hopefully this is another miscounted pin thing.

 

 

 

Anyway, it appears that the biggest issue is that something seems to be holding D4 down. Unfortunately, there are 7 chips that connect to this pin: U1, U2, U4, U9, U18, U19, U20. Then there are the expansion ports and the cartridge port. I assume you've already given the cartridge port a close inspection? Also, take a very close look at the top right side of the expansion port, as D4 is in that area too. You should get a resistance reading of any D4 connection to ground, such as U2 pin 20 or U4 pin 14.

 

As far as which of the 6 is the source of the problem, well here's where desoldering skills come in. I would hope for one of the common chips. U18 and U19 could be destroyed by static while plugging and unplugging controllers, for instance. U4 is a RAM chip, and "stuck bits" are synonymous with RAM, but this is a slightly unusual case that hopefully doesn't involve the RAM. But it's still a logical choice. Anyway, you may need to remove them one by one in order from most likely to least likely, until the short (that I suspect is the problem) goes away.

[vgcollector]

 

One more thing: could you try hitting reset a few times while holding the probe on 22 to see if there's at least a blink of access?

I did this and it blinked each time I hit the reset button.

[vgcollector]

Well this is weird again then.

 

U5 seems to be working as it ought to: The address consistently lies in the ROM region, and it is indeed attempting to activate the ROM chip. Pin 15 is electrically connected to U2 pin 22, so it also ought to be showing the same readings. With power off, check continuity there. Hopefully this is another miscounted pin thing.

 

 

 

Anyway, it appears that the biggest issue is that something seems to be holding D4 down. Unfortunately, there are 7 chips that connect to this pin: U1, U2, U4, U9, U18, U19, U20. Then there are the expansion ports and the cartridge port. I assume you've already given the cartridge port a close inspection? Also, take a very close look at the top right side of the expansion port, as D4 is in that area too. You should get a resistance reading of any D4 connection to ground, such as U2 pin 20 or U4 pin 14.

 

As far as which of the 6 is the source of the problem, well here's where desoldering skills come in. I would hope for one of the common chips. U18 and U19 could be destroyed by static while plugging and unplugging controllers, for instance. U4 is a RAM chip, and "stuck bits" are synonymous with RAM, but this is a slightly unusual case that hopefully doesn't involve the RAM. But it's still a logical choice. Anyway, you may need to remove them one by one in order from most likely to least likely, until the short (that I suspect is the problem) goes awa

First, where is a good source of replacement chips? I have a ROM chip, controller chips, and the newer DRAM chips, but I haven't found a place that sells the others except for China on ebay. Also when you refer to D4 what are you referring to there.

 

If you were doing this what would you replace 1st? I can solder, but I was hoping to narrow it down some. Does the fact that the Expansion module work eliminate any of the chips you listed above. I appreciate all the help you have been. I have learned a lot.

 

Thanks,

Vgcollector

[nick3092]

Does the fact that the Expansion module work eliminate any of the chips you listed above. I appreciate all the help you have been. I have learned a lot.

 

Thanks,

Vgcollector

The way I understand the expansion module to work, is that it's basically a full fledged Atari minus power supply and RF. It just takes the power from the Coleco and sends the signal to the RF module in the Coleco. So it bypasses everything that makes the Coleco, Coleco.

 

Meaning it doesn't help narrow down what part of the Coleco circuit is actually malfunctioning.

[ChildOfCv]

First, where is a good source of replacement chips? I have a ROM chip, controller chips, and the newer DRAM chips, but I haven't found a place that sells the others except for China on ebay. Also when you refer to D4 what are you referring to there.

 

If you were doing this what would you replace 1st? I can solder, but I was hoping to narrow it down some. Does the fact that the Expansion module work eliminate any of the chips you listed above. I appreciate all the help you have been. I have learned a lot.

 

Thanks,

Vgcollector

 

Did you re-verify the ROM pin 22?

 

Check Digikey or Mouser for standard logic chips. Anything that begins with 74ls is standard logic.

 

sn76489, and tms9928 will be your biggest headaches to replace, so you should save them for last. Some can be salvaged from other systems, or you could ask around here, maybe place a WTB ad for the bad chip. If it turns out to be the z80, there are several manufacturers of that one (notice mine is a NEC and not a Zilog). I think Hitachi also made them at one time.

 

As to what D4 is, it's the 4th bit on the data bus. The z80 has an 8-bit bus, and each bit has its own signal wire. The lines are numbered D0 to D7.

 

 

The data bus is shared between every component that needs to send data to or from the z80. The above diagram highlights all of the D4 connections. Since it's a simple wire connecting all of these points, that does make it harder to track down a short. Even worse, the short probably goes through a silicon semiconductor or CMOS gate that has failed. These can act like a small value resistor rather than a direct short. But since it's holding the voltage at 0, you know that there is enough current to register on an ohm meter. So the first thing to do is to check whether any of the above diagrammed points has a low resistance to ground. Being as they are all connected by wire, any location can be checked. If so, then we need to replace a chip, but first we'll have to track it down.

 

If you do not see a short to ground, then there is a possibility that it's just the ROM chip that has lost the ability to drive D4. The CPU could still find a way to occasionally output a D4 high if it found just the right combination of instructions, but having a handicapped instruction set due to D4 could prevent that from happening. If so, then a new ROM chip will be all you need.

 

Tracking down the short might be possible without removing chips, if you're willing to spend some $$$$. There are precision meters called milliohm meters, which have a bit more accuracy than your typical Home Depot special. With that, you have a chance of probing every point to the same ground point and finding the one with the least resistance. But it will be such a tiny difference that even making less than ideal contact with the chip pin could easily influence you in the wrong way. One thing that could minimize that chance is to first reflow the joints that you're going to test in order to clean up oxidation on them. Otherwise make sure you make firm contact.

 

Another tactic is to hook a power supply to the suspect connection net, and look for a chip that warms up. But you'll want a good bench power supply with adjustable voltage and current stops so that you can gradually turn up the power. Of course if you end up completely burning through the shorted transistor, then theoretically you can figure out the problem chip based on what still doesn't work. But I don't recommend this tactic, because it's like trying to fix a dent in your car with a sledge hammer: If you are really good, you can get good results, but if you ham-fist it, you make it worse.

[ChildOfCv]

And this is the signal line that is supposed to activate the ROM chip. You said that it is blinking on U5, but not on U2?

 

[vgcollector]

And this is the signal line that is supposed to activate the ROM chip. You said that it is blinking on U5, but not on U2?

 

Screen Shot 2019-02-28 at 9.33.13 PM.png

ChildOfCv, I appreciate all the help you have been!! I have learned a lot and I will keep posting with progress. I think I may just change the ROM chip to start since I have 2 brand new ones I got from Console 5. I will check the readings on U2 and U5 again to make sure I got them correctly. After the first couple of chips I tested I pretty much tested every chip 2-3 times to make sure I got a good reading. Do you have any kind of document that says what the reading should be on most of the chip pins on a working Colecovision. I do have a working one, and I may just crack it open and take the readings off each chip for comparison.

 

If you have any part#'s for Colecovision chips you have ordered from Digikey or Mouser please let me know. I can identify chips that are the same, but then they have all the extra letters and I get lost.

 

Thanks, I will post as I have updates.

[ChildOfCv]

I haven't put any documentation together, but your spreadsheet ought to work out well. The one thing it should probably distinguish, though, is which readings are generated by the chip vs which ones are generated elsewhere and input to the chip. As the old saying goes, "garbage in, garbage out." If your inputs read wrong, you can't blame the chip for giving you faulty outputs.

 

Some things depend entirely on what is running at the time, though. For instance, during the Colecovision logo pause, and typically on the "get ready player 1" screens, you will see a whole lot of nothing. If you start the system without a cartridge in, there will be a flurry of activity for maybe a tenth of a second, then most of it will be quiet.

 

Frogger is useful because it's constantly running the sound, video, and input. So if the system is at least successful at executing code, you will see pretty much everything happening.

 

As for chip suffixes, those tend to be company-specific. For instance, TI uses the "N" suffix to specify standard plastic PDIP case. When searching for a replacement, always pay attention to the "package" of the chip. ("packagING" is just the container type that they ship multiple chips in, so not the same thing) This is the general shape and pin layout of the chip. The chips on the CV board are all DIP or PDIP package. So, for instance, you look up 74ls74 and see about 10 different choices. Narrow it to PDIP-14 or DIP-14 and you now have 2, and they both end with AN. The E4 after the AN means that it's RoHS compliant. RoHS is some European environmental regulation or other. I don't live there, so it doesn't matter to me either way.

[vgcollector]

I was going to ask you what pin can I put a set of ear phones on to hear music if I have Frogger is inserted. I have seen on the forum you can do it, but they don't mention which pin.

[ChildOfCv]

That would be the left side of C88 at the top of the board.

[vgcollector]

That would be the left side of C88 at the top of the board.

ChildOfCv, I finally got back to my little project of fixing the black screen issue. I have ordered some new VRAM chips, but while I waited I went ahead and desoldered 2 good working ones from a Colecovision board I got that someone had butchered and it powered up correctly, but the controller ports an traces were shot. So I removed the 2 VRAM chips from the board. Now based on your comments about D4 being held down above. Do you think I should just replace the U4 vram chip and then see what happens. Then if I need to I can replace U3 as well? I have read a lot of the fixes for the Black screen issues and even though a lot of the topics never post what the solution is, a lot of them seem to point to the Vram. I think it has to be something that is fairly common with all the Colecovision boards. Thanks, my soldering skills are slowly improving.

[ChildOfCv]

Well, first we need to clarify some terms. VRAM is the 8 video RAM chips above the video chip. It's actually DRAM (dynamic RAM), but since it's used for video they call it VRAM.

 

SRAM (static RAM) are the 2 chips below the video controller. They are also the 1K system RAM, so I guess you could still call them SRAM.

 

In some circumstances, the video RAM can be the fault, but in your case the problem is long before data can even reach the video controller, let alone the VRAM.

 

That said, the SRAM certainly can be the problem. U4 is the one that connects to the faulty data line (each byte of system RAM is divided so that U3 gets the low half and U4 gets the high half), so it would be the first one I tried. U3 is not connected to the faulty data line, so cannot be its cause (but of course it can still be dead...). But for now, resurrecting the D4 data line between those named 7 chips is the priority. If the RAM chip doesn't fix it, I'd move on to the input chips since they can be abused by static shock and are standard 74LS series chips, therefore easily replaced.

Edited March 12, 2019 by ChildOfCv

[vgcollector]

Well, first we need to clarify some terms. VRAM is the 8 video RAM chips above the video chip. It's actually DRAM (dynamic RAM), but since it's used for video they call it VRAM.

 

SRAM (static RAM) are the 2 chips below the video controller. They are also the 1K system RAM, so I guess you could still call them SRAM.

 

In some circumstances, the video RAM can be the fault, but in your case the problem is long before data can even reach the video controller, let alone the VRAM.

 

That said, the SRAM certainly can be the problem. U4 is the one that connects to the faulty data line (each byte of system RAM is divided so that U3 gets the low half and U4 gets the high half), so it would be the first one I tried. U3 is not connected to the faulty data line, so cannot be its cause (but of course it can still be dead...). But for now, resurrecting the D4 data line between those named 7 chips is the priority. If the RAM chip doesn't fix it, I'd move on to the input chips since they can be abused by static shock and are standard 74LS series chips, therefore easily replaced.

I meant the SRAM, sorry for the confusion. I will try the U4 chip first, and then see what happens. Hopefully I can get this done in the next few days.I will update you when that's done hopefully with some good news. Thanks!!

Thanks