Colecovision Black Screen Repair Help

[ChildOfCv]

Well, Amazon's Choice seems to be okay.

 

https://www.amazon.com/Elenco-Electronics-LP-560-Logic-Probe/dp/B000Z9HAP4

[dafa_123]

On 11/14/2019 at 7:19 PM, 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.

Received my logic probe and oscilloscope. Since I replaced the BIOS with the one from Console5 which has more pins, I assume the U2 pin22 is now U2 pin24, would I be correct?

 

I set the logic probe to pulse and CMOS. When I use the logic probe on that pin I get a low signal and when I turn on the unit or press reset, the Hi and Low lights turns on with a pulsing noise for a few seconds and then it goes back to low but sometimes it remains stuck in HI/LOW. I have attached a small video.

 

As for the oscilloscope, I seem to have an issue with it. It worked for a few minutes when I connected it for the time, but now, I can't get a signal from either channels. Either I clicked on something that is causing this or it is defective. I just don't see any lines...

[ChildOfCv]

With the logic probe, use TTL mode.  The 74LS chips are TTL and the Z80, RAM, and ROM are TTL-compatible.

 

As for pin counts on the ROM, I used the 28-pin socket when I made the pin assignments, so before the ROM replacement you'd have been counting the blank solder holes as pins 1,2 and 27,28.  So it's still pin 22 that you care about. Pin 24 is the 9th address line bit.

 

Your scope settings look sane.  Occasionally the USB can forget what it's doing, and it may be necessary to end the program and re-plug the scope.  But that's usually only the case after sleep mode.

[ChildOfCv]

Also, the video chip ought to have a heat sink.  Did you have one rattling around in there before you removed the aluminum shielding?

[dafa_123]

2 hours ago, ChildOfCv said:

Also, the video chip ought to have a heat sink.  Did you have one rattling around in there before you removed the aluminum shielding?

I removed the Heatsink when I removed the original GPU. I want to wait and see if I get an image before installing it on the new GPU. Since I don't leave the unit on for very long when I test, I don't think it will damage the GPU.

 

I sent an Email to Tech Support about my issue. It's really annoying since it worked for a few minutes when I first plugged it in...

 

I will do some further testing tomorrow.

 

Thank you.

 

[dafa_123]

On 11/14/2019 at 7:19 PM, 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 am going nuts with this console. I keep getting inconsistent readings. I took new readings with the Hantek Oscilloscope and I get some weird output. I don't know if this can give us a clue but I often need to flip the switch on/off several time before I actually get a signal other than a flat line.

 

Ok so here it is:

 

U1:6 --> The clock signal I see does not appear to be valid.

U1:16 --> Can't seem to see any interrupt.

U1:17 --> This one is a flat line.

U1:18 --> Also a flat line.

U1:19 --> I get a signal, but it's not like the one in the repair manual.

U1:22 --> Flat line.

U1:24 --> Again I get a signal, but it's not like the one in the repair manual.

U1:27 --> Appears almost normal.

U1:28 --> Also appears almost normal.

U1:35 --> I seem to getting a pulse.

U6:5 and U6:5B --> I get a bunch of out of spec signals and after a few seconds nothing else.

U7:3 --> I seem to getting a proper signal.

U8:1 --> Seems normal.

U8:3 --> Clock does not appear normal.

U8:8 --> Clock does not appear normal.

U8:9 --> Clock does not appear normal.

U9:1 --> Signal does not appear normal.

U9:2 --> Signal does not appear normal.

U9:3 --> Flat line. The address line could be dead. How can I fix this?

U9:17 --> Signal appears similar to the image in the manual.

U9:25 --> Signal does not appear normal.

U9:35 --> Signal does not appear normal.

U9:36 --> Signal does not appear normal.

U9:38 --> Signal does not appear normal.

U9:40 --> Clock does not appear normal.

U20:14 --> Clock does not appear normal.

 

Could there be an issue with the address line and/or the clock? Should I replace U22? Should I replace all the logic gates U5, U6, U7, U8, U22 and U24?

 

Thanks

[ChildOfCv]

Unfortunately, oscilloscopes aren't quite "point and shoot".  You should look at the instruction manual about probe compensation.  For the probes that came with my Hantek at least, there's an adjustment screw on the probe where it plugs into the scope.  The other important thing to understand is that when the probe is switched to "1X", it has a much lower bandwidth than when it's on 10x.  So if you wanted to see a 3.58MHz square wave accurately, you'd have to hook it to a function generator at that frequency and square wave output and adjust the compensation until it appears that way, possibly on 10X depending on the probe.

 

But if all you care about is that the signal exists, that's not necessary.  So I'll comment on each one for now:

 

U1 pin 6 is a 3.58MHz signal.  I'm not worried about the shape at the moment.

Pin 16 is the interrupt pin.  You'll only ever see any movement there when the Super Action Controller moves its roller, or if you use the trackball in trackball mode.

Pin 17 is spiked by the video chip, when programmed to do so.  You'll see it under normal circumstances.

Pin 18 is a halt output.  It only changes when the chip has entered HALT state by running the HALT instruction.  An interrupt will bring it out of that state.

Pin 19 is the memory request output.  If you want to adjust the compensation on your probe, this might be a good alternative to a calibrated source.  Anyway, it shows that the processor is attempting access to memory.

Pin 22 is the write access output.  Apparently it's not trying to write to memory.  Unless you find times where this line does go low, it's apparent that the processor is not running useful code.

Pin 24 is the WAIT input.  It tracks nicely with the MREQ output, so it must be accompanied by the M1 output too.  Anyway, this happens when it's reading instructions to execute.  The sound chip will also request a wait period when it's addressed.

Pin 27 is M1, which is activating on a regular interval.

Pin 28 is the memory refresh output.  On every other cycle when the processor isn't reading memory, it does a refresh output so that DRAM chips can retain their information without interfering with normal operation.

Pin 35 is an address line.  Its contents are not typically so regular, but it's obvious that the processor is not in a recognizable program.

U2 pin 8 is an address line.  It should be read at a higher frequency since it's changing a lot faster than that microsecond display can show.

U6 pin 5 is being measured at 50mV per division.  So I can't tell if that's an aberration or just slight crosstalk.  But U6 pin 5 ought to be held low.

U7 pin 3 tracks the WAIT output.  Seems to be working.

U8 pin 1 sees the inverse of M1.  Looks correct.

U8 pin 3 is the main clock input.

U8 pins 8 and 9 are the main clock output.  They are inverses of each other, so they both look right.

U9 pins 1 and 2 are memory access outputs.

U9 pin 3 is address and data.  I would not expect it to be a flatline since the VDC is constantly refreshing memory.

U9 pin 17 is a data line.  It's connected to many other chips, such as the RAM, ROM, CPU, and sound.  It's supposed to be controlled by whichever one is told to write to the bus.

U9 pin 25 is an internal data line from the VRAM.  I guess it's nice that it shows movement.

U9 pin 35,36,38 are the video outputs.  We can't really say much about them until we've seen the system attempting to do something.

U9 pin 40 shows a clock signal somewhere near 10MHz.  It won't look awesome because the CV just uses a resonant circuit that is kicked by the main clock.  But it's good enough.

U20 should be getting the main clock, but again the sweep frequency is too low so it just looks like fuzz.

 

I'm most interested at the moment in U2 pin 22 though.  Right after you hit reset, that should be showing a lot of activity.  U3/U4 pin 8 also should be alive.

[ChildOfCv]

Correction:  U20 pin 14 reading was not correctly triggered.  Trigger level is at ground, but the signal is up at 1V+.  Actually, that's also the case for U2 pin 8.

Edited November 24, 2019 by ChildOfCv

[dafa_123]

19 hours ago, ChildOfCv said:

Unfortunately, oscilloscopes aren't quite "point and shoot".  You should look at the instruction manual about probe compensation.  For the probes that came with my Hantek at least, there's an adjustment screw on the probe where it plugs into the scope.  The other important thing to understand is that when the probe is switched to "1X", it has a much lower bandwidth than when it's on 10x.  So if you wanted to see a 3.58MHz square wave accurately, you'd have to hook it to a function generator at that frequency and square wave output and adjust the compensation until it appears that way, possibly on 10X depending on the probe.

 

But if all you care about is that the signal exists, that's not necessary.  So I'll comment on each one for now:

 

U1 pin 6 is a 3.58MHz signal.  I'm not worried about the shape at the moment.

Pin 16 is the interrupt pin.  You'll only ever see any movement there when the Super Action Controller moves its roller, or if you use the trackball in trackball mode.

Pin 17 is spiked by the video chip, when programmed to do so.  You'll see it under normal circumstances.

Pin 18 is a halt output.  It only changes when the chip has entered HALT state by running the HALT instruction.  An interrupt will bring it out of that state.

Pin 19 is the memory request output.  If you want to adjust the compensation on your probe, this might be a good alternative to a calibrated source.  Anyway, it shows that the processor is attempting access to memory.

Pin 22 is the write access output.  Apparently it's not trying to write to memory.  Unless you find times where this line does go low, it's apparent that the processor is not running useful code.

Pin 24 is the WAIT input.  It tracks nicely with the MREQ output, so it must be accompanied by the M1 output too.  Anyway, this happens when it's reading instructions to execute.  The sound chip will also request a wait period when it's addressed.

Pin 27 is M1, which is activating on a regular interval.

Pin 28 is the memory refresh output.  On every other cycle when the processor isn't reading memory, it does a refresh output so that DRAM chips can retain their information without interfering with normal operation.

Pin 35 is an address line.  Its contents are not typically so regular, but it's obvious that the processor is not in a recognizable program.

U2 pin 8 is an address line.  It should be read at a higher frequency since it's changing a lot faster than that microsecond display can show.

U6 pin 5 is being measured at 50mV per division.  So I can't tell if that's an aberration or just slight crosstalk.  But U6 pin 5 ought to be held low.

U7 pin 3 tracks the WAIT output.  Seems to be working.

U8 pin 1 sees the inverse of M1.  Looks correct.

U8 pin 3 is the main clock input.

U8 pins 8 and 9 are the main clock output.  They are inverses of each other, so they both look right.

U9 pins 1 and 2 are memory access outputs.

U9 pin 3 is address and data.  I would not expect it to be a flatline since the VDC is constantly refreshing memory.

U9 pin 17 is a data line.  It's connected to many other chips, such as the RAM, ROM, CPU, and sound.  It's supposed to be controlled by whichever one is told to write to the bus.

U9 pin 25 is an internal data line from the VRAM.  I guess it's nice that it shows movement.

U9 pin 35,36,38 are the video outputs.  We can't really say much about them until we've seen the system attempting to do something.

U9 pin 40 shows a clock signal somewhere near 10MHz.  It won't look awesome because the CV just uses a resonant circuit that is kicked by the main clock.  But it's good enough.

U20 should be getting the main clock, but again the sweep frequency is too low so it just looks like fuzz.

 

I'm most interested at the moment in U2 pin 22 though.  Right after you hit reset, that should be showing a lot of activity.  U3/U4 pin 8 also should be alive.

Since the CPU does not seem to be getting any useful DATA, I checked the traces using the diagram I attached to this post. Following the diagram and using my multi meter in Diode mode so that I can hear a buzz when the traces are connected, I found some that do not buzz pin to pin and should be connected according to the diagram. I do get a value on the multi meter but no buzz.

 

My question is, should I solder a jumper cable between those points?

 

The BIOS is the one I installed from Console5.

U2:Q1 pin 12 is not buzzing to U10:D1 pin 15

U2:Q3 pin 15 is not buzzing to U10:D3 pin 8

U2:Q6 pin 18 is not buzzing to U10:D6 pin 10

U2:Q7 pin 19 is not buzzing to U10:D7 pin 13

Pin 20 is not buzzing to WJ5:2

 

All the rest buzz when I test pin to pin. I checked from U2 I get a buzz on those pin with U3 and U4.

 

 

[ChildOfCv]

Didn't you alter the board as required to install the new ROM chip?  As it comes from the factory, it's wired for a 24-pin PROM.  The new chip is a 28-pin EEPROM.  The board has allowance for that, but you must make some changes.  WJ4 and WJ5 need jumpers connected.  Underneath the board in that general area there are two unlabeled traces that have a pad along the way, but are covered in solder mask.  Those two traces need to be broken.  See https://console5.com/wiki/Colecovision_BIOS_Replacement  Edit:  Actually, looking at your earlier picture, it appears that the solder may not have bonded with WJ5's jumper wire.  When you heat the solder, make sure to place the tip against both the pad and the wire so that both will heat up and bond with the solder.

 

As for the data lines, what is the resistance?  Also, make sure you have good contact with the pin itself.  Over time, chip pins will build up a nonconductive layer that your probes have to poke through to get an accurate reading.  If they don't have great conductivity, you should probably reflow the joints on each side.  You can also look over the traces for damage, but that's less likely.

Edited November 25, 2019 by ChildOfCv

[dafa_123]

6 hours ago, ChildOfCv said:

Didn't you alter the board as required to install the new ROM chip?  As it comes from the factory, it's wired for a 24-pin PROM.  The new chip is a 28-pin EEPROM.  The board has allowance for that, but you must make some changes.  WJ4 and WJ5 need jumpers connected.  Underneath the board in that general area there are two unlabeled traces that have a pad along the way, but are covered in solder mask.  Those two traces need to be broken.  See https://console5.com/wiki/Colecovision_BIOS_Replacement  Edit:  Actually, looking at your earlier picture, it appears that the solder may not have bonded with WJ5's jumper wire.  When you heat the solder, make sure to place the tip against both the pad and the wire so that both will heat up and bond with the solder.

 

As for the data lines, what is the resistance?  Also, make sure you have good contact with the pin itself.  Over time, chip pins will build up a nonconductive layer that your probes have to poke through to get an accurate reading.  If they don't have great conductivity, you should probably reflow the joints on each side.  You can also look over the traces for damage, but that's less likely.

Didn't you alter the board as required to install the new ROM chip? Yes, I followed the instructions step by step from the site.

 

As for the data lines, what is the resistance? I don't have any resistance. I only have a number when I put the meter in Diode mode.

 

Since I replaced the CPU and I am now using a socket, the contact with the pins should be good. I can try re solder the problematic pins. If that doesn't work, should I jump the pins with a wire in order to make sure that the connection works?

 

Thanks

[ChildOfCv]

2 hours ago, dafa_123 said:

Didn't you alter the board as required to install the new ROM chip? Yes, I followed the instructions step by step from the site.

 

As for the data lines, what is the resistance? I don't have any resistance. I only have a number when I put the meter in Diode mode.

 

Since I replaced the CPU and I am now using a socket, the contact with the pins should be good. I can try re solder the problematic pins. If that doesn't work, should I jump the pins with a wire in order to make sure that the connection works?

 

Thanks

Weird.  I've never seen a meter that doesn't have ohms mode.  "Diode mode" looks for a voltage across the two points because it's for testing diodes.  When reading a diode one way, it would show around 0.6V and the other way it should show no reading.  Beeping in that case means the diode is shorted.  But that can also be used for a continuity mode.  Voltage should be nearly zero in that case.

 

Anyway, yeah try melting the solder on each pin.  Place the tip of the iron firmly against both the pin and the pad for a couple of seconds each after the solder melts.  When taking a reading from a pin, scraping it with a fiberglass pen may eliminate oxidation and help get a good reading.  If you still don't get a good connection, then try running a wire instead.

[dafa_123]

On 11/24/2019 at 2:34 PM, ChildOfCv said:

Unfortunately, oscilloscopes aren't quite "point and shoot".  You should look at the instruction manual about probe compensation.  For the probes that came with my Hantek at least, there's an adjustment screw on the probe where it plugs into the scope.  The other important thing to understand is that when the probe is switched to "1X", it has a much lower bandwidth than when it's on 10x.  So if you wanted to see a 3.58MHz square wave accurately, you'd have to hook it to a function generator at that frequency and square wave output and adjust the compensation until it appears that way, possibly on 10X depending on the probe.

 

But if all you care about is that the signal exists, that's not necessary.  So I'll comment on each one for now:

 

U1 pin 6 is a 3.58MHz signal.  I'm not worried about the shape at the moment.

Pin 16 is the interrupt pin.  You'll only ever see any movement there when the Super Action Controller moves its roller, or if you use the trackball in trackball mode.

Pin 17 is spiked by the video chip, when programmed to do so.  You'll see it under normal circumstances.

Pin 18 is a halt output.  It only changes when the chip has entered HALT state by running the HALT instruction.  An interrupt will bring it out of that state.

Pin 19 is the memory request output.  If you want to adjust the compensation on your probe, this might be a good alternative to a calibrated source.  Anyway, it shows that the processor is attempting access to memory.

Pin 22 is the write access output.  Apparently it's not trying to write to memory.  Unless you find times where this line does go low, it's apparent that the processor is not running useful code.

Pin 24 is the WAIT input.  It tracks nicely with the MREQ output, so it must be accompanied by the M1 output too.  Anyway, this happens when it's reading instructions to execute.  The sound chip will also request a wait period when it's addressed.

Pin 27 is M1, which is activating on a regular interval.

Pin 28 is the memory refresh output.  On every other cycle when the processor isn't reading memory, it does a refresh output so that DRAM chips can retain their information without interfering with normal operation.

Pin 35 is an address line.  Its contents are not typically so regular, but it's obvious that the processor is not in a recognizable program.

U2 pin 8 is an address line.  It should be read at a higher frequency since it's changing a lot faster than that microsecond display can show.

U6 pin 5 is being measured at 50mV per division.  So I can't tell if that's an aberration or just slight crosstalk.  But U6 pin 5 ought to be held low.

U7 pin 3 tracks the WAIT output.  Seems to be working.

U8 pin 1 sees the inverse of M1.  Looks correct.

U8 pin 3 is the main clock input.

U8 pins 8 and 9 are the main clock output.  They are inverses of each other, so they both look right.

U9 pins 1 and 2 are memory access outputs.

U9 pin 3 is address and data.  I would not expect it to be a flatline since the VDC is constantly refreshing memory.

U9 pin 17 is a data line.  It's connected to many other chips, such as the RAM, ROM, CPU, and sound.  It's supposed to be controlled by whichever one is told to write to the bus.

U9 pin 25 is an internal data line from the VRAM.  I guess it's nice that it shows movement.

U9 pin 35,36,38 are the video outputs.  We can't really say much about them until we've seen the system attempting to do something.

U9 pin 40 shows a clock signal somewhere near 10MHz.  It won't look awesome because the CV just uses a resonant circuit that is kicked by the main clock.  But it's good enough.

U20 should be getting the main clock, but again the sweep frequency is too low so it just looks like fuzz.

 

I'm most interested at the moment in U2 pin 22 though.  Right after you hit reset, that should be showing a lot of activity.  U3/U4 pin 8 also should be alive.

I may have a bigger issue with this board. I solder the missing connection and now all the meter test I do works. I checked pretty much all the paths on between U1, U2, U3, U4, U5 and U6 and they all appear Ok. I now get a signal on U2:22 and I get a dip on the 5v of U3 and U4.

 

I started checking the lines between U1 the memory and none of the lines appear to be connected, see attached diagram. Even between memory chips some lines don't work. If that is the case, I will have to solder jumper cables between all the chips and CPU.

 

I am starting to wonder if it is worth the effort? Any thoughts?

 

Thanks.

[ChildOfCv]

Uh... that's not U1.  That's the video chip, U9.  Unless your board revision numbered them differently.

 

I created this schematic after noticing a number of issues with the schematic that you've been referencing above.  There's also a PCB layout to help locate parts.  But note also that this is my rev J board so things may not be exactly in the same place on yours.

 

The other thing to note is that TI for some boneheaded reason labeled their data and address pins in reverse order from everybody else (and from common sense).  D0 is the highest bit and D7 is the lowest.  Same for the address bits.  So when matching the connections, match AD7 on the TI (pin 3) with A0 on the memory chips (pin 5) and so on.  My schematic makes that more explicit.

 

Console-Schematic.pdf Console-PCB.pdf

[dafa_123]

11 hours ago, ChildOfCv said:

Uh... that's not U1.  That's the video chip, U9.  Unless your board revision numbered them differently.

 

I created this schematic after noticing a number of issues with the schematic that you've been referencing above.  There's also a PCB layout to help locate parts.  But note also that this is my rev J board so things may not be exactly in the same place on yours.

 

The other thing to note is that TI for some boneheaded reason labeled their data and address pins in reverse order from everybody else (and from common sense).  D0 is the highest bit and D7 is the lowest.  Same for the address bits.  So when matching the connections, match AD7 on the TI (pin 3) with A0 on the memory chips (pin 5) and so on.  My schematic makes that more explicit.

 

Console-Schematic.pdf 364.82 kB · 5 downloads Console-PCB.pdf 89.93 kB · 5 downloads

I've been going through the all the traces with my meter. I have pretty much repaired, tested and verified all the traces from the Video Controller and Video DRAM diagram.

 

I have a few questions regarding the Processor, Program Memory and BIOS diagram:

 

1. WJ4 and WJ5 do not appear to be jumped on your diagram. Is it because it's the diagram with the original BIOS? If that is the case, do you have by any chance a diagram with the Console5 BIOS upgrade?
2. Should U1:6 be connected to U8:3?
3. U8:3 does not buzz either with Expansion slot 45(44)?
4. U1:6 and Expansion slot 45(44) buzz. Should I put a jumper between U1:6 and U8:3?

 

All other traces from the Processor, Program Memory and BIOS diagram seems to be connected properly. Could it be just a bad clock connection issue?

 

BTW, thank you for the files

[ChildOfCv]

The jumpers are shown in their original configuration.  You "disconnect" the two traces that are shown connected and "connect" WJ4 and WJ5 for the EEPROM conversion.

 

Yeah, U8:3 should be connected to U1:6.  That adds an extra wait state when the CPU wants to access memory.  I guess that's important

 

 

 

 

[dafa_123]

1 hour ago, ChildOfCv said:

The jumpers are shown in their original configuration.  You "disconnect" the two traces that are shown connected and "connect" WJ4 and WJ5 for the EEPROM conversion.

 

Yeah, U8:3 should be connected to U1:6.  That adds an extra wait state when the CPU wants to access memory.  I guess that's important

 

 

 

 

I connected U6:1 to U8:3 tested the traces. Same issue, all the traces buzz as they should. Just not sure with the new BIOS.

 

If I compare the old BIOS connections with the new one, U2:22 and U2:20 are now connected. W4 and W5 are connected together. Not sure if I should be buzzing between W4 and W5.

 

There might be some wrong here. Now I get U1:1 connected to U2:20, U2:22 and U2:23. Is that normal ?

[ChildOfCv]

1 hour ago, dafa_123 said:

I connected U6:1 to U8:3 tested the traces. Same issue, all the traces buzz as they should. Just not sure with the new BIOS.

 

If I compare the old BIOS connections with the new one, U2:22 and U2:20 are now connected. W4 and W5 are connected together. Not sure if I should be buzzing between W4 and W5.

 

There might be some wrong here. Now I get U1:1 connected to U2:20, U2:22 and U2:23. Is that normal ?

No.  The underside trace between WJ4 and WJ5 is still connected.  You need to make sure it's completely severed.

[ChildOfCv]

[dafa_123]

23 hours ago, ChildOfCv said:

I fixed the traces issues with U2. I am now buzzing everywhere that I should but still get the same symptoms. Most of my Hantek oscilloscope reading don't show what they should according to the repair manual. I am getting a weird signal from U1:6. Could the clock crystal be bad?

 

Not sure what to look for next. I've replaced the ram and BIOS with the Console5 Upgrade kit, replaced the CPU and GPU and I get the exact same issue. Double checked and repaired all traces according to the diagrams you provided. I get proper voltage on all chips that I check. Unless the issue is with one of the SN74xxx chip, not sure what to look for next.

 

 

[ChildOfCv]

Well, remember that the signals shown will only be seen on the blue screen where it's asking for difficulty level/number of players.  So when it's not doing that, you can't expect to find what they are showing.  So when so many problems even prevent that from happening, the scope pictures are of dubious usefulness.

 

Now, when looking at the signal, you always need the trigger level to be in the range of the signal.  Yours is at 0V, so it's not synchronized so you're seeing the effect of sine waves at infinite numbers of phases overlapping.

 

When you replaced the CPU, did you use a socket?  If so, that opens some possibilities for logic testing.  The strategy would be to remove the CPU, then use jumper wires to set certain lines high or low to check outputs.  Then you don't need a logic analyzer to do the hefty signal analysis.

[dafa_123]

On 12/2/2019 at 5:57 PM, ChildOfCv said:

Well, remember that the signals shown will only be seen on the blue screen where it's asking for difficulty level/number of players.  So when it's not doing that, you can't expect to find what they are showing.  So when so many problems even prevent that from happening, the scope pictures are of dubious usefulness.

 

Now, when looking at the signal, you always need the trigger level to be in the range of the signal.  Yours is at 0V, so it's not synchronized so you're seeing the effect of sine waves at infinite numbers of phases overlapping.

 

When you replaced the CPU, did you use a socket?  If so, that opens some possibilities for logic testing.  The strategy would be to remove the CPU, then use jumper wires to set certain lines high or low to check outputs.  Then you don't need a logic analyzer to do the hefty signal analysis.

I was so tired, I did not noticed the trigger level. I adjusted it and took a new reading. Still does not look Ok. I might not be using the oscilloscope correctly, I am not an expert.

 

Yes I have the CPU on a socket. Do you have a procedure that could tell me which lines to test and what to expect?

 

Thank you

[ChildOfCv]

34 minutes ago, dafa_123 said:

Do you have a procedure that could tell me which lines to test and what to expect?

 

This would also be easier if you have a breadboard and long jumper wires for it, so that you can make multiple connections to the same +5 or ground location.

 

The first test, I would say, is to make sure that the chip select ICs are working correctly.  Connect U1 pins 19 and 20 to +5V.  Now you can check the pins on U5 and U6.  Pins 7 and 9-15 on both of those chips should be near +5.

 

For the memory selector test, you need U1 pin 13 at +5 and pin 19 grounded.  Then you would set pins 5, 4, and 3 as follows and expect ONLY one of pins 7, 9-15 on U5 to go low, as follows:

5  4  3   U5
--------+---
G  G  G | 15
G  G  5 | 14
G  5  G | 13
G  5  5 | 12
5  G  G | 11
5  G  5 | 10
5  5  G |  9
5  5  5 |  7

For the IO selector test, you need U1 pin 20 grounded and will be playing with pins 22, 35, and 36.  Then use the following table for U6:

22 35 36   U6
---------+---
 G  G  G | 15
 G  G  5 | 14
 G  5  G | 13
 G  5  5 | 12
 5  G  G | 11
 5  G  5 | 10
 5  5  G |  9
 5  5  5 |  7

 

Edited December 4, 2019 by ChildOfCv

[dafa_123]

58 minutes ago, ChildOfCv said:

 

This would also be easier if you have a breadboard and long jumper wires for it, so that you can make multiple connections to the same +5 or ground location.

 

The first test, I would say, is to make sure that the chip select ICs are working correctly.  Connect U1 pins 19 and 20 to +5V.  Now you can check the pins on U5 and U6.  Pins 7 and 9-15 on both of those chips should be near +5.

 

For the memory selector test, you need U1 pin 13 at +5 and pin 19 grounded.  Then you would set pins 5, 4, and 3 as follows and expect ONLY one of pins 7, 9-15 on U5 to go low, as follows:

5  4  3   U5
--------+---
G  G  G | 15
G  G  5 | 14
G  5  G | 13
G  5  5 | 12
5  G  G | 11
5  G  5 | 10
5  5  G |  9
5  5  5 |  7

For the IO selector test, you need U1 pin 20 grounded and will be playing with pins 22, 35, and 36.  Then use the following table for U6:

22 35 36   U6
---------+---
 G  G  G | 15
 G  G  5 | 14
 G  5  G | 13
 G  5  5 | 12
 5  G  G | 11
 5  G  5 | 10
 5  5  G |  9
 5  5  5 |  7

 

Did the test, here are the results:

 

U5:7@4v

U5:9-15@3.82v

 

U6:7@5.8v

U6:9-14@5.4v

U6:15@3.82v

 

U5 tested low @0.1v when tested following the diagram.

 

U6 appears in the wrong order. I got:

 

G G 5 low on pin 11 instead of 14 @0.1v

G 5 5 low on pin 9 instead of 12 @0.1v

5 G G low on pin 14 instead of 11 @0.1v

5 5 G low on pin 12 instead of 9 @0.1v

 

The rest are according to the diagram and I get a low @0.1v

[ChildOfCv]

TTL logic says that anything >2V is high, so those all work.

6 hours ago, dafa_123 said:

U6 appears in the wrong order. I got:

 

G G 5 low on pin 11 instead of 14 @0.1v

G 5 5 low on pin 9 instead of 12 @0.1v

5 G G low on pin 14 instead of 11 @0.1v

5 5 G low on pin 12 instead of 9 @0.1v

Oh you're right, I got the bit order backwards.  The bit order should be:

36 35 22   U6
---------+---
 G  G  G | 15
 G  G  5 | 14
 G  5  G | 13
 G  5  5 | 12
 5  G  G | 11
 5  G  5 | 10
 5  5  G |  9
 5  5  5 |  7

So U5 and U6 are both working.  U22 serves clock signals with 4 of its 6 gates, so you'd see a dead clock line if one of them weren't working.  You could check the two gates that help out U1 though:  Check that U22, pin 6 is the opposite of U1 pin 27 for both states.  Check that U22 pin 12 is the opposite of U1 pin 28.

 

Now for U7:  U7 pin 2 should be the opposite of U1 pin 31.  U7 pin 4 should oscillate at half of the main clock speed when U1 pin 27 is grounded, but should be high when it's +5V.  U7 pin 6 should read low.  U7 pin 8 should read high.  U7 pin 10 should read high when you're not pressing reset, or low when you are.  U7 pin 12 should read the opposite of 10 in both cases.

 

U8 works.

We assume that U1 works since it's been replaced.  

We assume for now that U2 works since it's new.

U18 and U19 are untested so far, but unless they're shorting a bus line, they shouldn't be a factor in basic functionality.  Same for U20.

 

You can test the address and data lines with U1 removed though.  The pins of interest are 1-5, 7-10, 12-15, and 30-40.  Use a resistor between 2K and 10K to pull each of these pins up to +5V and make sure they actually measure 5V.  Alligator clips for the meter probe would be useful, or you can read it from the scope since it has a clip.  Then repeat with the resistor pulling them to ground.  If any read strongly different than what is being pulled, then it will be necessary to track down the cause.

 

Edited December 4, 2019 by ChildOfCv