My SNES that I've had since it was new has developed a problem suddenly. Sprite graphics have vertical lines through them. I'll attach an image to this post of Mega Man X to demo the exact fault. I'll try to get a clearer picture later. Sprites end up with vertical lines through them near the right side of each sprite cell. No background graphics are having issues. The cartridges are clean. Everything was working 100% less than a month ago. I went to play something today and noticed these lines. Does anyone have any ideas what could be causing this? Maybe just a bad connection inside my system?
My console is a regular US model, PCB marked SNS-CPU-GPM-01. I'm just looking to get some ideas and opinions on what might be wrong and how I might fix it. I haven't noticed any other issues and it passed one of the SNES test programs electronics tests OK. It just seems to be this graphical glitch with sprites.
Another observation, it seems like D6 of the graphics is messed up. However when flipping a sprite (turning X around) the lines do not flip, they stay in the same relative place in the sprite cell. So it's as if sprite cells are outputting garbage for that pixel.
Using a scaler and a LCD I was able to take much better pictures. Unfortunately I don't have a capture device but this should illustrate the problem.
DogP's repair page has good info:
http://projectvb.com/nss/logs.htm
Unfortunately I'd already looked at his logs before posting here. None of his cases seem to match mine. My console isn't failing any electronics test, it's just the graphical problem.
Looks like one of the D lines going into whatever PPU handles sprites is making a bad connection to the VRAM, but the other PPU (responsible for backgrounds) isn't affected.
The reason I'm not sure it's the VRAM connection is the errors do not flip when the sprites are flipped. They stay in the same place of where the sprite cells are, it doesn't matter about the pattern data it's fetching. Atleast that's what I think is happening. So might it be some connection between PPU1 and PPU2 could be bad?
To be clear it would be something like this, regardless of pattern data. Dots are OK, x are bad pixels in the sprite cells.
......x.
......x.
......x.
......x.
......x.
......x.
......x.
......x.
Maybe one of the PPU chips is just failing.
If you have a SD2SNES you could see if the master clock frequency has drifted too much, which might be a reason for the PPU failure.
Would that be something correctable? I don't have the SD2SNES currently though unfortunately. I do think that it might just be one of the PPU chips has had an internal failure. Unless somehow a connection on one of the chips became broken. Could that happen by pushing down too hard on a cartridge maybe? I forget from last night when I opened it up but one of the PPU chips is very close to the cartridge slot I think. It's just so strange for this failure out of nowhere to occur.
I guess it doesn't matter too much because I'm not going to be working on it myself. Does anyone know anyone that fixes these for people? I doubt DogP does. Otherwise I guess I should just get another unit. The only reason I want to save it is sentimental value.
If a PPU chip is failing internally, the only fix would be to swap it out for a working one pulled from another SNES. I'm sure if you look you could find one on eBay for parts, but swapping out a surface mount chip isn't for an amateur.
If it's just one of the traces becoming damaged somehow, that'd be fixable with a bodge wire. I guess you could just go in there with a multimeter and check for connectivity across the trace?
Open the machine and tap around the PCB and also run your fingers over the pins and see if the garbage lines change. If you see change then the problem is mechanical or that some pin is messed up. Sometimes a pin loses ability to drive signal to 0 or 5V and in that case a pull down or up will help, I've fixed a NES PPU and some ROM chips which had a pin which showed some "jigglyness".
Is it safe to be touching the pins while the machine is running? I tried pressing down a bit on the chips but not on any pins because I am not sure if that is safe to do. If that is safe to do with a bare finger I will try that and see. How would I know if a pin lost its ability to drive a signal high/low and determine if it needed a pull up/pull down?
I also haven't yet gotten a real good look at the board yet or used a multi-meter to check for any broken traces. I might be able to do that today. I guess if I'm lucky it's just a loose pin or trace I could fix with a wire.
Edit: Pushing down on the pins of the PPUs didn't appear to change anything. Nothing looks abnormal, no damage or anything I can see.
I wonder if your idea that maybe a pin is unable to drive its signal anymore might be the cause as I said earlier, it's like D6 of sprite data from one or both bytes of sprite data is stuck high or low. I didn't figure out an exact match by tweaking my emulator but it's definitely sprite cell related and not sprite pattern data related.
I attached a PCB picture where the PPUs are. I didn't notice anything wrong, but I may have just missed it.
Voltages inside a running NES or Super NES Control Deck aren't any more dangerous than touching both contacts of a 9 V PP3 battery with a fingertip.
Photo of Duracell 9-volt battery by Ashley PomeroyBeing a software guy, I lack hands-on experience with electronics repair. But I'd recommend the usual anti-static precautions, and don't short a power pin to a ground pin with a metal probe. I'll leave explaining the rest to others who are handier with a soldering iron.
A bad connection between the PPU and VRAM would affect BGs as well as sprites, and I don't see how a bad connection between PPU1 and PPU2 could affect just one out of every 8 pixels like that (the pixel bus between the two chips carries one pixel at a time) I would guess that one of the on-chip data lines to the line buffer on PPU1 has failed--not something that can be fixed short of replacing the chip with one from another SNES.
AWJ wrote:
A bad connection between the PPU and VRAM would affect BGs as well as sprites
As I understand it, one PPU handles sprite compositing, the other backgrounds and color math. Both are connected to VRAM; they just can't query VRAM at the same time. If only the PPU that handles sprites has a bad D6, it'd be normal for backgrounds not to be affected.
AWJ wrote:
I would guess that one of the on-chip data lines to the line buffer on PPU1 has failed--not something that can be fixed short of replacing the chip with one from another SNES.
Screenshots of X facing left, X facing right, and X facing right but having walked two pixels to the right would settle this.
EDIT: I overlooked something
tepples wrote:
AWJ wrote:
A bad connection between the PPU and VRAM would affect BGs as well as sprites
As I understand it, one PPU handles sprite compositing, the other backgrounds and color math. Both are connected to VRAM; they just can't query VRAM at the same time. If only the PPU that handles sprites has a bad D6, it'd be normal for backgrounds not to be affected.
AWJ wrote:
I would guess that one of the on-chip data lines to the line buffer on PPU1 has failed--not something that can be fixed short of replacing the chip with one from another SNES.
Screenshots of X facing left, X facing right, and X facing right but having walked two pixels to the right would settle this.
The first two posts by the OP show X facing left and right and each of them shows different bad columns, which isn't consistent with the problem being between the VRAM and the PPU.
AWJ wrote:
A bad connection between the PPU and VRAM would affect BGs as well as sprites, and I don't see how a bad connection between PPU1 and PPU2 could affect just one out of every 8 pixels like that (the pixel bus between the two chips carries one pixel at a time) I would guess that one of the on-chip data lines to the line buffer on PPU1 has failed--not something that can be fixed short of replacing the chip with one from another SNES.
So one of the PPU chips probably had an internal failure? I do agree that the connection to VRAM is probably fine. I thought maybe it could be something communication related between PPU1 <> PPU2 but if it's as you say then I guess some internal chip function has failed. Are you fairly sure it's PPU1 that would have the failure? Or could it be PPU2? I guess I'll have to find someone to swap it out but being sure which of the two is defective would help.
Probably the one that is closest to the output, which would be PPU2 (5C78).
Does anyone else have an opinion on which PPU is at fault? It'd be easier and cheaper to only have to replace 1 PPU chip and not both.
It's going to be hard to find these as loose parts. (By which I mean, someone else is going to have to have opened a SFC/SNES and pulled the IC using good equipment in order to send it to you)
And it's a big enough surface-mount device that you'll really need a hot air rework station to remove the one on your mainboard anyway...
I don't plan on doing any of that myself. I don't have those tools or skills to do that. But should I decide to get it done it would help to be pretty confident in which chip is bad. For the time being I did the more sensible thing and just acquired another unit.
Hopefully an otherwise broken one, because hacking apart a good console would be bad
That's the idea. It wouldn't make sense to part out a fully functional console.