NES loading to solid gray screen after being zapped by static

[Ben Boldt]

We have now concluded the experiments with Mega Mace's NES. It is completely repaired and being sent back today. It was fun.

package.jpg

Moving on from this, I want to continue with my own hardware for the following experiments:

• Replacement of the CPU in a PAL NES. We know it won't sound exactly correct, but can it still be done with acceptable results? (I have a PAL NES for experimentation but no PAL carts, so will need get one or reflash a cart with a PAL image or something, etc.)
• Replacement of PPU in an NTSC NES/Famicom. Will this need a PLL like the CPU did, etc.
• Replacement of PPU in a PAL NES
• Clear documentation of all PLL circuits, updating the wiki, etc.

[Ben Boldt]

I got 5 more UA6527P CPUs since they are just ~$2 dollars each. Why not have more fun for such a low cost.

Fronts:

ua6527p_6-10_front.jpg

Backs:

ua6527p_6-10_back.jpg

All are blank on the bottom except for #9, which says "TC23". Not sure I remember ever seeing that one before.

#7 has a clock divider of 16. All others have a clock divider of 15. I have not built any of the PLL circuits yet in order to hear the duty cycles.


Back to my comment in the previous post, considering replacing the CPU in an actual PAL NES. There are 2 different approaches to setting the correct CPU speed in this situation.

1. The resulting CPU speed should be equal to the normal PAL CPU speed.
   • This will make any cycle-timed code behave correctly.
   • Any mappers that count CPU cycles to make timers/interrupts will behave correctly. This also probably includes some scanline interrupt designs.
   • Incorrect audio frequencies being produced due to NTSC lookup tables in the CPU.
2. The resulting CPU speed should be equal to the normal NTSC CPU speed.
   • Assuming that the audio lookup tables closely offset the difference between PAL and NTSC CPU speeds, this will have correct pitch audio.
   • Messes up all the other time-senitive stuff mentioned above.

It is probably much more important to have the original PAL CPU speed for timing purposes than it is having all of the audio shifted in pitch. I am thinking it all shifts together so it may not actually sound horrible. So basically, throwing a UA6527P with /16 divider directly into a PAL NES is the best bet? Is this a correct assessment?

[lidnariq]

That's my understanding - the /16 ones were originally intended for clones of the licensed PAL chipset before Not-Nintendo discovered that broke compatibility with too much of the NTSC library.

(Nintendo knew that it would and I believe they considered it a virtue not a flaw).

If you want another thing to check beyond pulse waves, check if pin 30 high keeps the CPU from running at all (it's probably /RDY), or if it keeps joypads from working (it's +TST)

[Ben Boldt]

If you want another thing to check beyond pulse waves, check if pin 30 high keeps the CPU from running at all (it's probably /RDY), or if it keeps joypads from working (it's +TST)

That’s a cool idea, yes I can do that.

[Ben Boldt]

I have tested and all 5 of the CPUs have reverse duty cycles.

ua6527p_6-10_pll.jpg

The /16 one, I ran it without any PLL which was surprisingly playable. Yes, big glitches and laggy in spots but it worked, including the status bar stayed generally where it should be. I thought that was interesting. It is hard to tell at such a lower frequency, but it does sound like it has reverse duties. Funny, I think they were actually all supposed to be /16 and there was only 1 of those. I will keep this one without a PLL since it could be used directly in a PAL NES.

These chips DO have paint on top. It comes off easily with acetone. I tried that on the left half of #8 where you can't see it under the PLL board. No additional markings appeared under the paint though. With the paint removed, it revealed a rough sanded surface, on which the new lasered label was still there but not very visible anymore.

I noticed, #10 makes an extra little sound at the end of the pause sound in SMB3. Not sure what is going on there. It does it every time.

In order to play with the test mode pin, I don't want to bend that pin on all of the CPUs so I will have to remove the socket from my Famicom in order to separate it. I can bend up the pin of the socket and put a piece of tape on the hole of the motherboard there. Actually, maybe I can stack an extra socket between, and bend up the pin on the extra socket; that's a better idea.

[MegaMace]

As for me, I received the returned NES from Ben today. Thank you for all the help Ben!

I haven't extensively used it, but tested it out a little bit. The first time I booted up a game from my Everdrive there were some graphical glitches on the title screen, but I didn't see that again. I'll keep an eye out for anything weird as I use it and see if I can reproduce it when I do see something.

[Ben Boldt]

You still have the original genuine PPU so hopefully that’s just normal.

Expansion audio should work now. Try a game like Akumajou Densetsu [J].

https://www.nesdev.org/wiki/List_of_gam ... sion_audio

[MegaMace]

Yup, I gave that a shot and have the expansion audio!

[Ben Boldt]

Yup, I gave that a shot and have the expansion audio!

Nice.

If you want another thing to check beyond pulse waves, check if pin 30 high keeps the CPU from running at all (it's probably /RDY), or if it keeps joypads from working (it's +TST)

That’s a cool idea, yes I can do that.

OK I tried this today. Here was the setup:

pin_30_setup.jpg

I flipped the switch while running SMB3 [J]. For all of the TA-03NP1 chips (# 2, 4, 5), The pin was +TST. The game kept running, but started ignoring the controller. For all CPUs 6-10, the pin was /RDY. The game froze up when I flipped the switch, and usually could continue when I flipped it back. The original CPU, which is a RP2A03E, also treated it like /RDY. CPUs #1 and 3 are owned by MegaMace.

I also received the 3pcs WDL 6528 NTSC PPU chips that I ordered. I wasn't sure about the correct clock frequency for these chips, so I did 2 things with the original PPU first:
- Measured ALE compared to the crystal. I found a factor of 8 periods of the crystal to 1 period of ALE.
- Also visible with the ALE signal was the V-blank when zooming out. I measured close to 60Hz on this.

So then I put the WDL 6528 in there and made the same measurements. I was surprised to see, the exact same measurements. I thought for sure it would be wanting the higher crystal frequency that goes with a /15 CPU, but that was not the case. I plugged it into the monitor and sure enough, these chips are a drop-in replacement for the NTSC PPU and all 3 of them work great. They were also packed very nicely in a plastic box with foam:

wdl_6528.jpg

It was this item, and it was on sale for $8.20 each + $5 combined shipping:
https://www.aliexpress.us/item/3256806212320877.html

[MegaMace]

I've been prototyping a stereo audio circuit and something occurred to me... I used to have a basic stereo mod which, Ben will recall, I disconnected the wires from when I sent it out for repair. At some point, part of the circuit disconnected on its own, but I don't know for sure if this was before or after I damaged the CPU.

Point being, if there were some extra wires going to the CPU, could that have made it more susceptible to ESD damage? I don't really know much about how ESD charges dissipate, let alone on the NES and what kind of mitigation factors it has... or is that something nobody really knows? Feels like it would make more sense if the shock went into one of the added audio jacks rather than the controller port. It's not a big deal but I'm just curious how the static factored in. I'm guessing the answer is probably something it might survive a shock but might not. I bought a wireless controller anyway and now I make sure to touch metal before touching the power or reset button.

[Ben Boldt]

I don’t think any of us have seen a CPU break from static to a controller or power button before, so your experience is at least very unique.

I do not doubt that you had an ESD when you touched the controller. But I do sort of wonder if it could have been coincidental with the CPU breaking. If there were wires connected to the CPU, I suppose they may have been close to touching something? Potentially shorting out to something? As you move the Nintendo around and bump it, insert carts, jiggle them, etc, maybe a loose wire had the opportunity to shift around and come into contact with different things. These are just ideas. I really don’t know how it broke and it is unusual.

[MegaMace]

Dunno if there's still an appetite for possible CPU differences, but I'm gonna share this here since I didn't see another thread continuing it. So far, I played through one game that was new to me and didn't notice any issues. But when I was using LoZ, a familiar game, to experiment with some audio circuits, that's where I started to notice some sound differences. Here's a clip:

https://youtu.be/V6LjH_SBZFc

Of course, I'll note I made sure these were coming from the stock audio configuration as well, not just what I was doing. I'm not sure if it can all be attributed to the CPU, like the lower overall volume I experienced, but I would think the CPU might be the culprit for the stuff like the missing SFX and the square wave tremolo.

This was all recorded with the same power and audio cables and same capture card configuration. No editing was done to the audio levels aside from the fade in/out obviously. Only the last clip in the video comes from a hardware modded audio configuration.

Err... actually, after I typed this all out, I considered if the expansion audio mod that Ben did could affect it too?

Edit: I've tested some more games and yeah, it's definitely noticeable. Might try taking out the expansion audio or switching to the swapped duty cycle CPU at some point just to see if it has the same issues.

[MegaMace]

Swapped duty cycle CPU sounds more "correct" in terms of volume balance and SFX being audible, best I can tell with the obviously different sound. Maybe there's just a range of variance in audio with these chips. Would make sense with what Ben said here earlier too:

I noticed, #10 makes an extra little sound at the end of the pause sound in SMB3. Not sure what is going on there. It does it every time.

[Fiskbit]

For what it's worth, I don't see how an expansion audio mod would have any effect on this. In the case where you're using a cartridge without expansion audio, instead of the audio in being connected to nothing, it's connected through a resistor to nothing. This shouldn't make any difference at all.