SNES rev 1 black screen at startup

[Poot36]

Well I have tried another of my cartridges (Super Mario All-Stars) and here is the result of the video output and reset glitching: https://youtu.be/dT9o6S2DnrU I was also able to get blue scrolling flashing bars and other random garbage as well that I did not film.

[lidnariq]

Looks like the PPUs and CPU at least partly work... weird that it's full of garbage, though. If you can get your hands on the SuperNES Test Program, maybe that'd be helpful...

[Poot36]

I will try to find a crappy SNES cart to turn into a flash cart and put that program on it. I have attached a LA trace from when the SNES was doing the garbage video output. I suspect that the sound module (that the CPU seems to fail to get a response from) is causing it to crash in such a way as to leave weird stuff in the video ram. I know the sound module works fine because I have tested it in another working SNES.

[lidnariq]

... Why does /CPURD never go low in that most recent trace? /ROMSEL is flapping, but the actual control lines aren't...

[Poot36]

I am starting to think that it is very broken. Is it possible that the CPURD and CPURW lines transition faster then the SYSCK line preventing my LA from picking them up? I have attached the LA trace from when it does the garbage colored blocks that you see in the video. I am starting to suspect that one of the chips is in latchup on the outputs or inputs.

[lidnariq]

That's definitely nonsense. Not only is /CPURD never moving, but the values on the address and data busses are changing wildly ... like it's just picking up (and maybe amplifying?) noise.

[Poot36]

You have a point there. I will try to isolate the CPU and RAM and try to figure out what chip is causing this. I don't know if this idea would work but could I use a Arduino and some shift registers to simulate the CPU and try to get the PPU chips to do something? Or would this not work due to the clock signals as well as other signals that I would not be able to easily replicate with this setup? I was thinking of just controlling the address and data lines with the setup and holding the SNES CPU in reset.

[lidnariq]

If you have the skills/tools to desolder the CPU, or at least can keep its outputs tristated, that should work fine.

The PPU's interface to the CPU should be something you can improvise some simple test with an Arduino program fairly easily.

[Poot36]

I have found an interesting discovery in that if I disconnect resistor R74 that allows the PPU to reset the CPU, cart and sound module and trigger my LA off the XIN clock instead of the SYSCK I get the CPURD and CPUWR lines to show up again. The heading SYSCK1 in the attached LA traces is actually SYSCK on the SNES. In the first trace the PPUs are not in reset and in the second one they are. The tests were done with the Super Mario All-Stars cart and the sound module installed. Also I have just realized that the PPUs have just a 8bit address bus and a 8bit data bus as well as a read and write control lines as well as HBLANK, VBLANK, and EXTLATCH. I am wondering how I would convert the 0x2100 to 0x213f registers into a 8bit value that the PPUs would understand? I think these are the values that the CPU is expecting on the address "A" bus but what comes out on the "PA" bus? Would I be correct in thinking that the "B" address bus is what is labeled in the color SNES schematic as CA16 to CA23? Also can I ignore the HBLANK, VBLANK, and EXTLATCH on PPU2 for now? I know some Arduino programming and would be able to probably get this to work if I could figure out what hex or binary values I would need to send to the PPUs for them to work. I am more of a hardware kind of guy not a software one but will learn the software bit if I have to. Also I am a beginner at SNES programing so I am sorry if some of my questions come across as stupid. I am also still learning how to best use my LA as well as I have only been using it for a few weeks and have had no formal training on how to properly use one (except from what I read from the users manual that was somewhat hard to understand).

[brento1138]

I am sorry that I do not have much to add to this conversation, other than I've really run into a wall trying to fix broken Super Nintendo consoles. I have had a ton of luck with old NES consoles, but SNES... no luck.

I get the same problem as you: black screen of death. The system powers up just fine. I have replaced all caps, same thing. Switched around sound cards and other pieces from working systems, and nothing has helped.

I will follow this conversation. I really hope to solve this problem... I have thrown away quite a few boards in frustration due to not being able to fix them. I still have a couple that I have hope for though...

Good luck.

[lidnariq]

I am wondering how I would convert the 0x2100 to 0x213f registers into a 8bit value that the PPUs would understand? I think these are the values that the CPU is expecting on the address "A" bus

I think the PPUs are on the B/PA bus, so AFAIK you should just be able to use /PARD and /PAWR with PA0..PA7 and D0..D7.

Hopefully someone will speak up if I've confused things.

but what comes out on the "PA" bus?

The SNES is a little weird in that it has two address-and-control busses and only one data bus, but arguably that makes sense because the DMA controller only allows transfers between the two different address busses, allowing one cycle per byte (in contrast to the NES's DMA taking two cycles per byte).

Would I be correct in thinking that the "B" address bus is what is labeled in the color SNES schematic as A16 to A17?

I don't even see A16 and A17 on the SNES schematic, except for as part of "CA16" and "CA17" or where those signals connect to the SNES's DRAM and cartridge connector.

Also can I ignore the HBLANK, VBLANK, and EXTLATCH on PPU2 for now?

Should be safe.

if I could figure out what hex or binary values I would need to send to the PPUs for them to work.

I regret to say that I have never written any SNES programs at all, but maybe tepples's controller test program is a good enough starting point?

I am more of a hardware kind of guy not a software one but will learn the software bit if I have to. Also I am a beginner at SNES programing so I am sorry if some of my questions come across as stupid. I am also still learning how to best use my LA as well as I have only been using it for a few weeks and have had no formal training on how to properly use one (except from what I read from the users manual that was somewhat hard to understand).

Stop selling yourself short, you're doing fine.

Now, as far as the LA traces go ... I dunno, I don't see anything obviously useful or anti-useful there.

[Poot36]

I just realized that I goofed on my previous post in that it mentions address lines A16 and A17 when in reality it should be CA16 to CA23. Whoops! I think some older cartridge pinouts refer to those address lines as address B and that is what confused me. Will take a look at the controller test program and also capture what is being sent to the PPUs when I get that blocky flashy screen so that I can try to replicate that. I am just not sure if the Arduino is going to be fast enough or if the speed of the data going in doesn't mater as long as it is correct and is in the VRAM.

[lidnariq]

I just realized that I goofed on my previous post in that it mentions address lines A16 and A17 when in reality it should be CA16 to CA23.

Oh, yeah. Sometimes the 65816 documentation refers to the upper 8 bits of the address as the "bank", or B. Just to be even more confusing.

I am just not sure if the Arduino is going to be fast enough or if the speed of the data going in doesn't mater as long as it is correct and is in the VRAM.

The speed shouldn't matter, because I believe the PPU has a classic asynchronous interface, like ISA cards or static RAMs.

[Poot36]

Ok, I have finished wiring up my LA to the B address bus as well as some other pins. I have attached the trace and also two pictures of what each line is doing just after startup. I have noticed that address line 8 always starts a little earlier then the rest and that there seems to be some funniness with the sysck line (very short high burst) that also affects other lines as well. Also let me know if the .tif based pictures work or not.

[lidnariq]

I can view TIFs, but my browser won't display them in-line. They're also uncompressed, so it's better to convert them to something lossless and small like gif or png.
I already converted these two, and for no good reason I though it would be funny/useful to combine the images, so:

ADDRESS8+9.PNG (3.94 KiB) Viewed 5857 times

... Man, that looks familiar. I think I used this LA in college?

Anyway, regarding what I see in the LA trace ... it looks like the DMA controller is good?
[420C] ← 00, disabling all HDMA
[420B] ← 00, disabling all GP DMA
[2181] ← 00 \ (edit: typoed here)
[2182] ← 00 \
[2183] ← 7F ----- indirect WRAM pointer at $7F0000
[4300] ← 00, (A to PA, d/c, d/c, 2:A-inc, 3:always write to one address on PA bus)
[4301] ← 80, PA address
[4302] ← 02, \
[4303] ← 02, \
[4304] ← 04, --- start from address $040202
[4305] ← 00, \
[4306] ← 00, --- transfer 64KiB
[420B] ← 01, initiate DMA transfer set up in channel 1.

I'm really not clear what the code here is trying to do. There's ... nothing obviously useful about those memory locations. And you can't DMA transfer from RAM (as at $040202) to RAM (via PA $80). And the only value appearing on the data bus during the entire transfer is $B7, so ... uh...?

Is this still All-Stars?

Anyway, can you configure the LA to capture on a rising edge of SYSCK? It should help stretch out the 8192-sample recording limit. ... although not enough, if something does another 64K-long DMA transfer like this.