Investigate damaged NES board

A friend of mine has a NES that he managed to damage through some experiments. Now I would like to find out what part of it is damaged and fix it if it's easy to replace or otherwise at least save the working parts.

So I wonder if anyone knows of any good ways to approach this problem, or maybe some general hints or guidelines when dealing with this kind of stuff.

He says it shows a white screen when turned on, if that info is any useful.

What test tools do you have on hand?
Logic analyzer? Oscilloscope? Multimeter? Logic level tester? Frequency counter?

If you had infinite money, I'd use a logic analyzer hooked up to all the pins on the cartridge connector, or at least most of the pins on the CPU.

I have access to multimeter and oscilloscope but unfortunately no logic analyzer. Though I'm considering making my own cheap one with a PIC if that's not too hard.

Oscilloscope is more than adequate:

A few pinouts from the wiki that will be useful:
nesdevwiki:CPU_pin_out_and_signal_description
nesdevwiki:PPU_pin_out_and_signal_description
nesdevwiki:Mask_ROM_pinout

Given that the PPU is drawing a solid white picture:
With a cartridge in, test the following-
* Vcc should be between 3.7V and 5.2V
(CPU)
* CLK should be 21.5MHz (26.6MHz PAL) → broken trace (because the PPU is still drawing a picture and so is still receiving the clock)
* /RST should be high → broken trace (because the PPU is still drawing a picture)
- - if it's pulsing low, the CIC is broken or the connection to the cartridge isn't good enough
* M2 should be 1.8MHz (1.7MHz PAL) → dead CPU or power supply issues
All subsequent tests could fail if the connection to the cartridge isn't good enough:
* A0 should change approximately every 2-3 M2 cycles
* some of A1..A15 and R/W should change ever
(74'139 adjacent to CPU)
* pins 11 (/INTSEL) and 9 (/ROMSEL) should pulse low quite often → if they don't, and the inputs are changing, the 74'139 could be damaged.
* pins 4 (/INTRAMSEL) and 5 (/PPUSEL) should pulse low often and occasionally, respectively
(PPU)
* /INT should pulse low ever → maybe a damaged PPU
- - if It doesn't, trigger on /PPUSEL, look at contents of A0..A2 (b'010'), D7 (should usually be high but occasionally low), R/W (high)
- - - → more likely a damaged PPU

If all of those check out ok, then maybe the problem is the RAM. Trigger on /INTRAMSEL, and, when R/W is high, see if any of D0..D7 change mid-cycle. If it doesn't, then that RAM might be damaged.

If it plays music and makes sound effects in response to user input, the PPU RAM might be damaged.

/ROMSEL is also on the cartridge, and /INTRAMSEL and /PPUSEL are also on the RAM adjacent to the CPU and on the PPU respectively.

Thank you! I'll check it out as soon as I can and let you know what I find out.
Too bad I don't have the cartridge connector. Guess I have to attach some cables with tape or something...

Isn't that what these and these are made for? :)

Unfortunately the 6502 has a bunch of instructions that are interpreted as "crash and do nothing more until reset", so a ROM for the CPU to execute is really necessary. But that doesn't involve the entire cartridge connector, and you might be even able to piggy-back it on the internal RAM.

You can wire the data bus the "NOP" instruction code and then count the frequency at the address lines using the oscilloscope. That will at least allow you to know if the CPU is running or not.

Well, until it NOP slides itself into RAM or the PPU. 0x4C (JMP $4C4C) would be safer, but doesn't let you watch the upper address lines changing. The 0xEA NOP would only guaranteeably execute 5398 NOPs (because it started executing at $EAEA) before it could slide into a KIL instruction somewhere. 0x44 (NOP zpg) would at least give you a few more cycles before it slides into RAM.

I would disconnect the 74LS139 enable pin from the bus (killing the wram and the PPU) to perform that test... Forgot to mention that.

I can't imagine trying to make any good conclusions about the status of the main board without a 72pin connector and cart to test with... How do you really KNOW it's broken? Maybe his 72 pin was just bad/dirty. How awesome would it be to spend hours tinkering with it, only to find out it was never actually broken.

Ok, a little update. I realized I could just borrow a connector from one of my other NESs (I know, pretty obvious, should have thought of that from the start). So I did just that and started it up to see if what he told me was correct. And it was, kind of. But it wasn't white but rather gray. I compared with the white screen of a working NES and it's not the same. And it is not blinking. Don't know what conclusions can be made from that but maybe you know.
I'll try the oscilloscope later but I don't have it around anymore since I only borrowed it and the owner needed it now. I will be able to borrow it again soon though.

There's some amount of random variation on what color you get when the PPU is first powered, but that could indicate brownout.
Connection to the cartridge's CIC is ok, OR the CIC on the mainboard is broken.

With only a voltmeter you can at least see if /RESET, /NMI, or /IRQ is stuck. Hard to go further without a logic probe. I bought one of these, it's been good enough for my uses:
http://www.amazon.com/gp/product/B000Z9HAP4/

I fired it up once more and this time it was blinking. Which must mean that the CIC is ok i guess.
I made it stop blinking and then did some tests with a voltmeter.
Vcc showed a solid 5.00V so that's fine.
/RST was 4.99-5.00
/NMI and /IRQ showed 4.94V. (could this be interpreted as they are triggered sometimes and the measured voltage is some kind of mean value?)

I also checked the CLK pin which I'm not sure is ok.
What happened was that the measured voltage was 2.xx(don't remember exactly)
and the screen turned green. I don't know why, but I got afraid I had done something bad.
Eventually the screen went back to gray after I had done some more measuring.

And I don't have access to the oscilloscope yet but hopefully soon.

@Memblers: thanks for the tip, I'll definitely consider buying one.

That's consistent. The CLK pin is rapidly oscillating between 0 and 5 V all the time, so it should show up somewhere in-between when averaged by your voltmeter.
Additionally adding the meter puts enough load on the pin that the CPU and/or PPU may no longer understand the incoming voltages. But that's harmless and should go away shortly after you remove the meter.

So finally we have made some tests with oscilloscope!
I'll report our findings so far:
CLK is indeed 26.6 MHz
M2 is 1.667 MHz (close enough i guess)
The rest was a bit more difficult to get consistent behaviour on, probably due to bad connection sometimes.
But most of the time all of the address pins and 74'139 pins behave according to what you said, for a short time, and then address pins locks at high and most things seems to freeze (JAM instruction maybe?).
However A1 is a bit odd because after some even shorter time it gets 'tired' and 'high' becomes ~2V.
This image should clarify:

Yellow is A1 and cyan is M2 both starting at reset.
I guess this could be the problem...

Bus conflict, mayyybe?

If you can somehow test whether the ROM outputs something different for A1 high/low while the rest of address bus unchanged, that would be conclusive. Not certain how to do that without some kind of logic analyzer or a >2 channel scope (A0, A1, Dx)

What game are you testing with? Do you get similar results regardless of the game? Finally, do you have the ability to program a cartridge?

We have only tested with Boulder Dash and no cartridge. Both give the same result on A1.
And no, I do unfortunately not have any programmable cartridges.

Regarding bus conflict, are there any other parts than the cpu that can put addresses on the bus?

Perhaps try a pull-up resistor on A1.

Nothing else should be capable of driving A1, but something could have shorted out somewhere, maybe.

When you ran without a cartridge connected, did you add some resistors to drive the data bus?

Faulty ram chip could do that. The chip could have a short circuit on the ESD protection diode.

That's true to the PPU or the CPU itself, as well.

Tried pull-up, still same result.

no.
Then my friend decided to just cut A1 off (in a way that is easy to reconnect ) to see if it still behaved the same way,
and it did, which means the cpu is damaged (and l_oliveira is correct), right?

Assuming that the logic sense on the pin is correct (just too low for external peripherals to correctly receive as logic level high), you should be able to add an external buffer (e.g. two gates of a 7404 or 7414).

You could try, with the system power off measure the continuity of the CPU A1 pin to GND and VCC using the multimeter diode test scale.

Put the positive probe at the GND pin of the CPU (with A1 disconnected from the rest of the system) and negative at A1. Repeat with negative probe at +5v pin of the CPU and positive at A1.

If you can try it at another address line, maybe A12 and see if they both measure identical (they should if the pins are not damaged and they're completely disconnected from the rest of the system) the fault might be elsewhere.

@lidnariq: we have thought about that but unfortunately the logic screws up at the time when it drops, but after that the logic behaves correctly. I guess that makes it a lot more difficult.

@l_oliveira: by 'completely disconnected', do you mean like I did with A1 (i.e. cut off)? In that case I haven't done it with any other pin.
But I measured with a multimeter anyway and the value was higher on A1 than the rest of the Ax pins, but maybe that's just because it's cut off?

Ok, now I have cut off A0 as well and made some measurements.
The results were only slightly different than before, A1 still showed very different values compared to A0.