Colecovision Black Screen Repair Help

[dafa_123]

Hello, I have a Colecovision that was given to me that only display a black screen with or without a cartridge inserted. I have a limited knowledge of electronics but I did some testing and here is what I have so far:

 

- I checked the PSU and I get the proper 5v, -5v and 12v. I also tried the PSU on another Coleco and it works. I even tried another working PSU just in case.

- I connected the Atari Module and I get the image. I can probably rule out the RF module.

- I checked the CPU at U1 and I get a clock signal on pin6 and I get 5v on pin 11. Not sure what else I can check here.

- I checked the Bios U2, U3 to U9 and all chips get 5v.

- I checked the VRAM U10 to U17 and they all get the 5v, 12v and -5v.

- The cartridge slot also gets 5v.

 

Not sure what else I can check or try. Any help would be appreciated.

 

Thank you.

 

[Ikrananka]

The problem is most likely U9 (the VDP) or the VRAM (U10 to U17).  It's likely the former as VRAM problems usually only occur with one or two chips at a time and cause screen corruption and not a blank screen.  So, I'd focus on U9 to start.

 

Attached are the relevant sections of the official ColecoVision technical repair manuals.  The flowcharts suggest first testing the output from U9 pins 35, 36 and 38 (these are the three video output pins).  Look for activity on those pins using a logic probe or ideally an oscilloscope.  If you don't have these tools then I'd suggest getting hold of another working CV and swapping U9 to see if that solves the problem.

Section 08-Technical Tips.pdf Section 06-Testing and Troubleshooting.pdf Section 07-Pictures of Signals.pdf

[dafa_123]

8 hours ago, Ikrananka said:

The problem is most likely U9 (the VDP) or the VRAM (U10 to U17).  It's likely the former as VRAM problems usually only occur with one or two chips at a time and cause screen corruption and not a blank screen.  So, I'd focus on U9 to start.

 

Attached are the relevant sections of the official ColecoVision technical repair manuals.  The flowcharts suggest first testing the output from U9 pins 35, 36 and 38 (these are the three video output pins).  Look for activity on those pins using a logic probe or ideally an oscilloscope.  If you don't have these tools then I'd suggest getting hold of another working CV and swapping U9 to see if that solves the problem.

Section 08-Technical Tips.pdf 2.01 MB · 2 downloads Section 06-Testing and Troubleshooting.pdf 9.62 MB · 3 downloads Section 07-Pictures of Signals.pdf 10.05 MB · 2 downloads

Thank you for those documents. They will help me a lot. I do have a old oscilloscope. I will follow them and hopefully I will find the issue. I will work on it tomorrow and I will let you know if I find the issue.

[Ikrananka]

35 minutes ago, dafa_123 said:

Thank you for those documents. They will help me a lot. I do have a old oscilloscope. I will follow them and hopefully I will find the issue. I will work on it tomorrow and I will let you know if I find the issue.

Good luck, I'm sure it'll be something that's fairly easy to fix by replacing a chip or two.  It's just figuring out which chips is the hard part.

[dafa_123]

Ok, so I did some testing with my old oscilloscope. I can't test everything because the oscilloscope that I have, B&K Precision 1470, does not have the ns or sub 1uS/Div range.

 

I started testing U1:6

I am able to see the main clock on U6 by using a 2v/Div and 1uS/Div. The wave is similar but smaller on my screen. I think that the main clock is Ok.

 

I am unable to test U1:16 since I don't have the 0.2uS/Div on my oscilloscope.

 

When I test U1:17, I get a flat line at ±3.5v

 

U1:18 gets a flat line at ±4.5v

 

U1:19 gets ±1v when the switch is off which is weird. Unable to test since it requires a 0.1uS/Div

 

U1:20 gets a flat line at ±3.65v

 

U1:22 gets a flat line at ±3.65v

 

U1:24 gets a flat line at ±4.5v

 

I stopped testing since, either the oscilloscope is malfunctioning, or the CPU is dead.

 

Does anyone know if I can get a replacement CPU other than from another Colecovision? Is there a compatible CPU that I could use?

[+DamonicFury]

17 hours ago, dafa_123 said:

Does anyone know if I can get a replacement CPU other than from another Colecovision? Is there a compatible CPU that I could use?

That's just a Z80, I believe... shouldn't be hard to find one on Ebay or wherever else you prefer to buy microchips.

[dafa_123]

1 hour ago, DamonicFury said:

That's just a Z80, I believe... shouldn't be hard to find one on Ebay or wherever else you prefer to buy microchips.

I ordered a TMPZ84C00AP-6 from China for 2.29$. Hopefully it will be compatible. If not, not a big lost. I am not sure if the fact that this one is rated to run at 6Mhz will cause any issues when run at 3.58Mhz.

 

Thank you for all the help. I will update my post once I receive and replace the CPU.

[ChildOfCv]

22 hours ago, dafa_123 said:

Ok, so I did some testing with my old oscilloscope. I can't test everything because the oscilloscope that I have, B&K Precision 1470, does not have the ns or sub 1uS/Div range.

 

I started testing U1:6

I am able to see the main clock on U6 by using a 2v/Div and 1uS/Div. The wave is similar but smaller on my screen. I think that the main clock is Ok.

 

I am unable to test U1:16 since I don't have the 0.2uS/Div on my oscilloscope.

 

When I test U1:17, I get a flat line at ±3.5v

 

U1:18 gets a flat line at ±4.5v

 

U1:19 gets ±1v when the switch is off which is weird. Unable to test since it requires a 0.1uS/Div

 

U1:20 gets a flat line at ±3.65v

 

U1:22 gets a flat line at ±3.65v

 

U1:24 gets a flat line at ±4.5v

 

I stopped testing since, either the oscilloscope is malfunctioning, or the CPU is dead.

 

Does anyone know if I can get a replacement CPU other than from another Colecovision? Is there a compatible CPU that I could use?

You can set the scope to 1uS and pull the 5x mag button to cheat on the sub-uS readings.  You may not get your signals as wide as the manual wants, but you can still get close enough to see if the waveforms match.  100ns = .1us

 

U1:17 indicates that there is no retrace trigger from the video chip.  But then the chip must be properly programmed to output the signal anyway, so this does not necessarily indicate a problem.

 

U1:18 should be flat.  It's the halt signal, and normally not used.  Going from memory, this output falls low whenever the chip enters the halt state.

 

U1:20 is for IO requests.  That line only shows activity when an I/O request is made (reading the joysticks, making noise, actively programming the display, etc)

 

U1:22 goes low for writes to either memory or peripherals

 

U1:24 is an input from peripherals.  Only the sound chip is connected, and it tells the processor to wait until it's ready to receive data, whenever the processor wants to send data.

 

 

All of that could still be happening with a good CPU, if it's not getting a good program.  It's still premature to replace the chip, though it sounds like you've already ordered one.  For instance, if you were checking with the switch on but no cartridge, the CV is supposed to print a message to insert a cartridge before turning it on, then it goes into an infinite loop.  You won't see any writes, I/O strobes, etc.  Only memory (MREQ), instruction fetch (M1), and read (RD).

 

Check lines 21 (read) and 27 (M1).  Every time the CPU wants to fetch an instruction, it will activate read and M1.  Check 25 (BUSRQ).  If that's low, the CPU will just be twiddling its thumbs because someone else is using the bus.

Edited October 4, 2019 by ChildOfCv

[dafa_123]

2 hours ago, ChildOfCv said:

You can set the scope to 1uS and pull the 5x mag button to cheat on the sub-uS readings.  You may not get your signals as wide as the manual wants, but you can still get close enough to see if the waveforms match.  100ns = .1us

 

U1:17 indicates that there is no retrace trigger from the video chip.  But then the chip must be properly programmed to output the signal anyway, so this does not necessarily indicate a problem.

 

U1:18 should be flat.  It's the halt signal, and normally not used.  Going from memory, this output falls low whenever the chip enters the halt state.

 

U1:20 is for IO requests.  That line only shows activity when an I/O request is made (reading the joysticks, making noise, actively programming the display, etc)

 

U1:22 goes low for writes to either memory or peripherals

 

U1:24 is an input from peripherals.  Only the sound chip is connected, and it tells the processor to wait until it's ready to receive data, whenever the processor wants to send data.

 

 

All of that could still be happening with a good CPU, if it's not getting a good program.  It's still premature to replace the chip, though it sounds like you've already ordered one.  For instance, if you were checking with the switch on but no cartridge, the CV is supposed to print a message to insert a cartridge before turning it on, then it goes into an infinite loop.  You won't see any writes, I/O strobes, etc.  Only memory (MREQ), instruction fetch (M1), and read (RD).

 

Check lines 21 (read) and 27 (M1).  Every time the CPU wants to fetch an instruction, it will activate read and M1.  Check 25 (BUSRQ).  If that's low, the CPU will just be twiddling its thumbs because someone else is using the bus.

I think my oscilloscope might be problematic. I can't seem to get a good reading. I have attached a few pictures. I was thinking of getting the Hantek PC Based USB Digital Storage Oscilloscope 6082BE 80Mhz 2CH,EXT 250MS/s. I don't want to pay too much since this is a hobby.

 

Picture 1: pin 20 1v/Div@5uSec

Picture 2: pin 21 1v/Div@5uSec

Picture 3: pin 25 1v/Div@1uSec

Picture 4: pin 27 1v/Div@1uSec

 

Edited October 4, 2019 by dafa_123

[ChildOfCv]

The signal for pin 20 looks weird, but only because it's a regular clock signal and that pin should be on an "as needed" basis.  The read and M1 look as expected though.  The processor only spends a few cycles reading memory, then it spends some time executing the instruction.  So there will be more "up" time than down.  BUSRQ looks like what it should be.

 

You should make sure you're reading pin 20 correctly.  Use the 1uS with 5x mag and keep the variable part of the time knob in CAL.  This gives you an effective .2uS/div sweep.  BTW, do you have the manual for that scope?  If not, I found a PDF at archive.org.  https://archive.org/details/1470Manual

 

I used a Hantek for a while.  It had some usefulness, but now that it's a few years old it's noisy.  For playing with old consoles though, it can do pretty much anything you care about.

[dafa_123]

21 hours ago, ChildOfCv said:

The signal for pin 20 looks weird, but only because it's a regular clock signal and that pin should be on an "as needed" basis.  The read and M1 look as expected though.  The processor only spends a few cycles reading memory, then it spends some time executing the instruction.  So there will be more "up" time than down.  BUSRQ looks like what it should be.

 

You should make sure you're reading pin 20 correctly.  Use the 1uS with 5x mag and keep the variable part of the time knob in CAL.  This gives you an effective .2uS/div sweep.  BTW, do you have the manual for that scope?  If not, I found a PDF at archive.org.  https://archive.org/details/1470Manual

 

I used a Hantek for a while.  It had some usefulness, but now that it's a few years old it's noisy.  For playing with old consoles though, it can do pretty much anything you care about.

Thanks, I have the original manual with the oscilloscope. Here are some more tests. Nothing happens to U9:14 when I press reset.

 

 

 

 

 

[dafa_123]

On 10/2/2019 at 10:03 AM, Ikrananka said:

The problem is most likely U9 (the VDP) or the VRAM (U10 to U17).  It's likely the former as VRAM problems usually only occur with one or two chips at a time and cause screen corruption and not a blank screen.  So, I'd focus on U9 to start.

 

Attached are the relevant sections of the official ColecoVision technical repair manuals.  The flowcharts suggest first testing the output from U9 pins 35, 36 and 38 (these are the three video output pins).  Look for activity on those pins using a logic probe or ideally an oscilloscope.  If you don't have these tools then I'd suggest getting hold of another working CV and swapping U9 to see if that solves the problem.

Section 08-Technical Tips.pdf 2.01 MB · 6 downloads Section 06-Testing and Troubleshooting.pdf 9.62 MB · 7 downloads Section 07-Pictures of Signals.pdf 10.05 MB · 7 downloads

Can you upload all the pages from the manual? I would love to see the entire manual.

 

Thanks.

[ChildOfCv]

8 minutes ago, dafa_123 said:

Thanks, I have the original manual with the oscilloscope. Here are some more tests. Nothing happens to U9:14 when I press reset.

Unless you have a cartridge like Frogger plugged in, that would be a "blink and you miss it" thing.  The CPU would spend a fraction of a second programming the screen and then go to a delay period.  Frogger will be doing constant animation as soon as you turn it on.  You should also hear sound in that case.

 

My concern by the above traces are pins 35, 36, and 38.  Those are the video output pins and they're flat lines.  The rest of the chip seems to be doing its job though.  It's accessing memory, at least.

 

Does U9 still have the heat sink firmly attached?

 

 

[dafa_123]

26 minutes ago, ChildOfCv said:

Unless you have a cartridge like Frogger plugged in, that would be a "blink and you miss it" thing.  The CPU would spend a fraction of a second programming the screen and then go to a delay period.  Frogger will be doing constant animation as soon as you turn it on.  You should also hear sound in that case.

 

My concern by the above traces are pins 35, 36, and 38.  Those are the video output pins and they're flat lines.  The rest of the chip seems to be doing its job though.  It's accessing memory, at least.

 

Does U9 still have the heat sink firmly attached?

 

 

I do get a signal on 35 and 36 with the Frogger cartridge but 38 is still flat. The heat sink appears to be properly glued to U9.

 

 

Edited October 5, 2019 by dafa_123

[ChildOfCv]

If you adjust the trigger, can you get a stable signal that looks like a composite signal on pin 36?  Your scope also has 2 composite TV trigger modes, so you should be able to see the sync signals.

 

And do you get sound with Frogger playing?

[dafa_123]

12 hours ago, ChildOfCv said:

If you adjust the trigger, can you get a stable signal that looks like a composite signal on pin 36?  Your scope also has 2 composite TV trigger modes, so you should be able to see the sync signals.

 

And do you get sound with Frogger playing?

I hope that I am using the trigger function correctly. I managed to get a wave form on U9:36 using the TVH function but I get a flat line on TVV. I am not sure if it's normal. I am unable to reproduce constantly the wave form using TVH. Sometimes, it's just a flat line. It could be an issue with my old oscilloscope since I often have to fiddle with the v/Div in order to see the wave form. I have ordered a new one online, but I probably won't get it for a couple of weeks.

 

As for the sound, I only hear a constant "Boooooooooo" sound. No music and no sound effects.

 

Thanks

[ChildOfCv]

3 hours ago, dafa_123 said:

As for the sound, I only hear a constant "Boooooooooo" sound. No music and no sound effects.

But you get no sound with standard cartridges, right?

 

If so, that means you probably have a working processor since it can do some things, a working ROM because it was able to start the cartridge, but potentially bad RAM since the game crashes immediately.  It could also be bad contacts at the cartridge port, so that some of the pins do not connect.  Finally, it could be that U5 is not properly directing memory reads.

 

One possible way to rule out the contacts is to disassemble a cartridge and plug just its PCB in.  Then you can check each pin on the PCB to make sure it reaches its proper destination.  An easy test point for most pins would be the expansion port because it shares all the address and data lines.  The other select lines go to U5.

[Tursi]

The sound should be muted by the ROM, before the cart is started... Since the ROM runs before any cartridge, and comes up to a stable static screen if no cartridge is inserted, you can test without any cart. 

 

When the system powers up, the sound chip is in a random state, so it's usually generating a sound. Software has to mute it, which means a continuous tone is a good indication of a really early crash. We see this a lot on the TI since the TI needs to start a second interpreter before it mutes the sound.

 

According to the ROM listings, the cartridge header is tested first - if there's a cartridge installed that skips the boot screen, it is started even before the reset happens. Otherwise, the very next thing the ROM does is mute the sound chip. So it should be fine to test with no cartridge installed. If you get a continuous tone out of the machine, it has most likely crashed in the first dozen or so instructions.

 

No RAM has been touched by this point, and the VDP isn't necessary to get this far. I think you should be focusing on the CPU, ROM, and sound chip. This is dependent on that tone starting at powerup and never changing, of course.

 

I don't know the designators for the ColecoVision board, but it looks like you checked that the CPU is not in halt, so that probably means the sound chip isn't holding it (but, pin 4 (Ready) should not be low on the sound chip). I think you're suggesting above that the CPU is functioning... If that's true I'd focus next on the ROM. If it's bad, the system won't be able to jump to the cartridge.

 

[dafa_123]

On 10/6/2019 at 2:42 PM, ChildOfCv said:

But you get no sound with standard cartridges, right?

 

If so, that means you probably have a working processor since it can do some things, a working ROM because it was able to start the cartridge, but potentially bad RAM since the game crashes immediately.  It could also be bad contacts at the cartridge port, so that some of the pins do not connect.  Finally, it could be that U5 is not properly directing memory reads.

 

One possible way to rule out the contacts is to disassemble a cartridge and plug just its PCB in.  Then you can check each pin on the PCB to make sure it reaches its proper destination.  An easy test point for most pins would be the expansion port because it shares all the address and data lines.  The other select lines go to U5.

 

I get the same results with or without a cartridge. Only a black screen with a constant "Booooouuuuu" sound. I don't see any reference on how to test U5 in the documentation that I have on hand. So I checked the voltage on U5 but I get different results every time I check. I checked with the oscilloscope and I get wave patterns on some pins, see pictures. I get the same results with or without a cartridge inserted. I am not sure how to properly test U5?

 

 

[dafa_123]

On 10/6/2019 at 6:54 PM, Tursi said:

The sound should be muted by the ROM, before the cart is started... Since the ROM runs before any cartridge, and comes up to a stable static screen if no cartridge is inserted, you can test without any cart. 

 

When the system powers up, the sound chip is in a random state, so it's usually generating a sound. Software has to mute it, which means a continuous tone is a good indication of a really early crash. We see this a lot on the TI since the TI needs to start a second interpreter before it mutes the sound.

 

According to the ROM listings, the cartridge header is tested first - if there's a cartridge installed that skips the boot screen, it is started even before the reset happens. Otherwise, the very next thing the ROM does is mute the sound chip. So it should be fine to test with no cartridge installed. If you get a continuous tone out of the machine, it has most likely crashed in the first dozen or so instructions.

 

No RAM has been touched by this point, and the VDP isn't necessary to get this far. I think you should be focusing on the CPU, ROM, and sound chip. This is dependent on that tone starting at powerup and never changing, of course.

 

I don't know the designators for the ColecoVision board, but it looks like you checked that the CPU is not in halt, so that probably means the sound chip isn't holding it (but, pin 4 (Ready) should not be low on the sound chip). I think you're suggesting above that the CPU is functioning... If that's true I'd focus next on the ROM. If it's bad, the system won't be able to jump to the cartridge.

 

I get the same "Booooouuuu" sound with or without a cartridge. The weird thing is I get different wave forms with and without a cartridge but the same "Booooouuu" noise... I have put the results of U20 without a cartridge, see pictures. If the ROM is the problem, how could I test it?

 

 

[ChildOfCv]

Well, the "easy" answer for me is that I created an Arduino 2560 shield that can run some fairly sophisticated diagnostics on the CV console from the expansion port.  The problem there is that it's not so easy for someone who doesn't have the parts, the board, or the Arduino

 

But there is a good chance it's the ROM.  You can get a replacement from console5.com for about $6.  https://console5.com/store/colecovision-no-delay-bios-kit.html

 

Even if it's not the issue, at least it eliminates the long title screen pause.  If it's not the issue, I'd take a hard look at the SRAM.

[dafa_123]

Ok, so I replaced the ROM and RAM with the ones from Console5, not luck, exact same symptoms. I am waiting for my replacement CPU and GPU. Hopefully, it will be one or the other...

 

I'll update the thread once I have replaced them.

 

Thanks everyone.

[dafa_123]

Here is my latest update. I have replaced the CPU and GPU with what should be compatible units (I could be wrong on this one) and I am getting the same result. I have replaced the CPU with a Toshiba TMPZ84C00AP-6 which appears to be the 6Mhz version of the Coleco CPU. I have replaced the GPU with a TMS9929ANL which appeared to have compatible specs to the the original.

 

I am still waiting for my new Oscilloscope. Once I have it, I redo all the checks and test all the traces to try and figure out what is not working.

 

Could it be another component that is causing the issue?

[ChildOfCv]

I'm trying to remember what we've tried, but:

 

ROM (U2) -- without that, the CPU just runs a bunch of junk data and nothing useful happens.

SRAM (U3,U4) -- almost immediately, it needs RAM to store its program stack, so without working SRAM chips, the code can get lost in time.

Memory map selector (U5) -- tells which chip to activate for an address region.  Its inputs (1,2,3) are the high address bits, and its outputs (7, 9-15) select chips based on the address region.

Generic NOT gate (U22) -- pin 12 must be low during memory access.

 

Without all 4 of these working, you won't even have basic functionality.

 

One thing that might help is a logic probe.  While a scope gives you a look at waveforms, something that happens in a few nanoseconds is easy to miss.  A logic probe will light up an LED for a visible amount of time whenever it sees a signal.  So, for instance, if you held the probe on U2 pin 22 and hit reset, you ought to see it light up red for a split second, indicating that the CPU is at least trying to read the ROM.

 

Well, you can also place the scope in single-trigger mode, and then when you hold the probe on that pin and hit reset, it ought to at least flash a trace across the screen if it sees a signal.  So maybe you could use that too.

Edited November 15, 2019 by ChildOfCv

[dafa_123]

58 minutes ago, ChildOfCv said:

I'm trying to remember what we've tried, but:

 

ROM (U2) -- without that, the CPU just runs a bunch of junk data and nothing useful happens.

SRAM (U3,U4) -- almost immediately, it needs RAM to store its program stack, so without working SRAM chips, the code can get lost in time.

Memory map selector (U5) -- tells which chip to activate for an address region.  Its inputs (1,2,3) are the high address bits, and its outputs (7, 9-15) select chips based on the address region.

Generic NOT gate (U22) -- pin 12 must be low during memory access.

 

Without all 4 of these working, you won't even have basic functionality.

 

One thing that might help is a logic probe.  While a scope gives you a look at waveforms, something that happens in a few nanoseconds is easy to miss.  A logic probe will light up an LED for a visible amount of time whenever it sees a signal.  So, for instance, if you held the probe on U2 pin 22 and hit reset, you ought to see it light up red for a split second, indicating that the CPU is at least trying to read the ROM.

 

Well, you can also place the scope in single-trigger mode, and then when you hold the probe on that pin and hit reset, it ought to at least flash a trace across the screen if it sees a signal.  So maybe you could use that too.

I will take a closer look at those chips.

 

I do not own a logic probe. Is there a model that you would recommend for a hobbyist? I saw a few cheap ones on Ebay, I don't know if they are any good.

 

Thank you.