SNES rev 1 black screen at startup

[Poot36]

I have figured out that I had miswired the OE line (it was connected to A22 on the cart). I have fixed that and rewired the EEPROM socket so that I do not have to use the swapbin utility that apparently does not work with files smaller then 8mb even if you extend the file to that size. I have tried the 8Kb file and copy pasted it to 256Kb and all I get is a black screen but I do get video synchronization pulses. I think trying to find a HiROM game or demo that is 256Kb would be my best bet, do you know of any? Is there anything else I can try short of totally rewireing the cart for LoROM use?

[lidnariq]

The tiny 8KiB thing reaaaaally should work. Only the first 829 bytes and last 32 matter; the middle 7KiB are pictures and padding. So if it doesn't work, there's got to be a wiring or programming issue...

Anyway, any image that is 32KiB or smaller is a strict subset of both LoROM and HiROM, so that's definitely not the problem you're having.

So anyway, I guess there's a bunch of free-to-redistribute SNES images from zophar...

[Poot36]

I have attached the 8K copy pasted file that made it 256K just in case I did some thing wrong with it (I used notepad by the way). Wold it be worth it testing these files in a emulator or would that no correctly simulate the SNES?

[Poot36]

Yahhh! I fixed it! I used the copy binary function of Notepad++ instead of a Ctrl + A Ctrl + C Ctrl + V in just Windows notepad. I have attached the file that I used. I also tried the cart in the broken SNES and still got a blank screen . I also figured out that on one of my controllers the R trigger does not work.

[lidnariq]

Hm. Well, on the bright side, this test program is simple enough that we can pretty conclusively diagnose what's going on/wrong from a logic analyzer trace.

You should see mostly-sequential addresses in the range of $E000 through $E33D as it executes.

[Joe]

I have attached the 8K copy pasted file that made it 256K just in case I did some thing wrong with it (I used notepad by the way).

Text editors are generally very bad at keeping binary files intact. Notepad destroyed some of the data.

Have you ever heard of hex editors? They're much better for manipulating binary files. I like HxD, but there are many to choose from.

[tepples]

Under Windows, the idiomatic technique for "doubling up" a headerless ROM whose size is a power of 2 uses copy /b in the command prompt.

Code: Select all

rem  starting with a ROM 8192 bytes (64 kbit) in size:
copy /b rom_64kbit.sfc+rom_64kbit.sfc rom_128kbit.sfc
copy /b rom_128kbit.sfc+rom_128kbit.sfc rom_256kbit.sfc
copy /b rom_256kbit.sfc+rom_256kbit.sfc rom_512kbit.sfc
copy /b rom_512kbit.sfc+rom_512kbit.sfc rom_1Mbit.sfc
copy /b rom_1Mbit.sfc+rom_1Mbit.sfc rom_2Mbit.sfc
rem  now the ROM is 262144 bytes (2 Mbit) in size

It won't work with headered ROMs, such as NES ROMs with an iNES or NES 2.0 header or Super NES ROMs with a copier header. For those, you have to separate out the PRG ROM (and in the NES's case, the CHR ROM) before doubling.

[Poot36]

Well here is the LA trace. It appears to loose it around the 2.5K to 2.7K region. I am assuming that the video gets setup but does not receive any valid data after that so I just get a blank screen. I have reconnected the R74 resistor from the /resout line from PPU2 and have figured out how to trigger my LA on the first address that the SNES sends out (0x0100) so that I do not wind up with all zeros in the trace.

[lidnariq]

Hm. The last few instructions before it goes crazy are:

Code: Select all

 t     dt addr r w pa r w m f
 1975  22 E0C1 0 1 C0 1 1 1 0 - JSL $80E132
 1983  32 E0C2 0 1 C0 1 1 1 0
 1991  E1 E0C3 0 1 C0 1 1 1 0
 1999  80 01FF 1 0 CF 1 1 0 0
 2013  80 E0C4 0 1 C1 1 1 1 0
 2021  E0 01FE 1 0 CF 1 1 0 0
 2029  C4 01FD 1 0 CF 1 1 0 0
 2037  8B E132 0 1 0C 1 1 1 0 - PHB
 2052  00 01FC 1 0 CF 1 1 0 0
 2060  4B E133 0 1 0C 1 1 1 0 - PHK
 2074  80 01FB 1 0 CE 1 1 0 0 -- last time it correctly interacts with the stack in the normal place
 2082  AB E134 0 1 0D 1 1 1 0 - PLB
 2102  E0 FFFF 0 1 CF 1 1 1 0 -- that's not where the stack is... also the first time the cpu ever tries to read a value from the stack or RAM
 2110  E2 E135 0 1 0D 1 1 1 0 - SEP #$20
 2118  20 E136 0 1 0D 1 1 1 0
 2132  9C E137 0 1 0D 1 1 1 0 - STZ $2121
 2140  21 E138 0 1 0E 1 1 1 0
 2148  21 E139 0 1 0E 1 1 1 0
 2156  00 2121 1 0 08 1 1 1 0 -- /PAWR should have gone low, too... it doesn't because the PLB means that this address is treated as $E02121, not $002121
 2164  C2 E13A 0 1 0E 1 1 1 0 - REP #$30
 2172  30 E13B 0 1 0E 1 1 1 0
 2186  A9 E13C 0 1 0F 1 1 1 0 - LDA #$2202
 2194  02 E13D 0 1 0F 1 1 1 0
 2202  22 E13E 0 1 0F 1 1 1 0
 2210  A2 E13F 0 1 0F 1 1 1 0 - LDX #$F400
 2218  00 E140 0 1 40 1 1 1 0
 2226  F4 E141 0 1 40 1 1 1 0
 2234  A0 E142 0 1 40 1 1 1 0 - LDY #$0008
 2242  08 E143 0 1 40 1 1 1 0
 2250  00 E144 0 1 41 1 1 1 0
 2258  22 E145 0 1 41 1 1 1 0 - JSL $80E314
 2266  14 E146 0 1 41 1 1 1 0
 2274  E3 E147 0 1 41 1 1 1 0
 2282  80 FFFF 1 0 CF 1 1 1 0 -- so why IS the stack wrong?
 2296  80 E148 0 1 42 1 1 1 0
 2304  E1 FFFE 1 0 CF 1 1 1 0
 2312  48 FFFD 1 0 CF 1 1 1 0
 2320  08 E314 0 1 05 1 1 1 0 - PHP
 2334  05 FFFC 1 0 CF 1 1 1 0
 2342  C2 E315 0 1 05 1 1 1 0 - REP #$30
 2350  30 E316 0 1 05 1 1 1 0
 2364  8D E317 0 1 05 1 1 1 0 - STA $4300
 2372  00 E318 0 1 06 1 1 1 0
 2380  43 E319 0 1 06 1 1 1 0
 2388  02 4300 1 0 00 1 1 1 0
 2396  22 4301 1 0 00 1 1 1 0
 2404  8E E31A 0 1 06 1 1 1 0 - STX $4302
 2412  02 E31B 0 1 06 1 1 1 0
 2420  43 E31C 0 1 07 1 1 1 0
 2428  00 4302 1 0 00 1 1 1 0
 2436  F4 4303 1 0 00 1 1 1 0
 2444  8C E31D 0 1 07 1 1 1 0 - STY $4305
 2452  05 E31E 0 1 07 1 1 1 0
 2460  43 E31F 0 1 07 1 1 1 0
 2468  08 4305 1 0 01 1 1 1 0
 2476  00 4306 1 0 01 1 1 1 0
 2484  E2 E320 0 1 08 1 1 1 0 - SEP #$20
 2492  20 E321 0 1 08 1 1 1 0
 2506  8B E322 0 1 08 1 1 1 0 - PHB
 2520  E0 FFFB 1 0 CE 1 1 1 0 -- stack is still wrong
 2528  68 E323 0 1 08 1 1 1 0 - PLA
 2548  E0 FFFB 0 1 CE 1 1 1 0 -- stack
 2556  8D E324 0 1 09 1 1 1 0 - STA 4304
 2564  04 E325 0 1 09 1 1 1 0 
 2572  43 E326 0 1 09 1 1 1 0
 2580  E0 4304 1 0 01 1 1 1 0
 2588  A9 E327 0 1 09 1 1 1 0 - LDA #1
 2596  01 E328 0 1 0A 1 1 1 0
 2604  8D E329 0 1 0A 1 1 1 0 - STA 420B
 2612  0B E32A 0 1 0A 1 1 1 0
 2620  42 E32B 0 1 0A 1 1 1 0
 2628  01 420B 1 0 02 1 1 1 0
 2636  28 E32C 0 1 0B 1 1 1 0 - PLP
 2656  09 FFFC 0 1 CF 1 1 1 0
 2664  6B E32D 0 1 0B 1 1 1 0 - RTL
 2684  E0 FFFD 0 1 CF 1 1 1 0
 2692  08 FFFE 0 1 CF 1 1 1 0
 2700  E0 FFFF 0 1 CF 1 1 1 0 -- fetched return address is $E008E0
 2708  00 08E1 0 1 C8 1 1 1 0 -- parsed as BRK #0
 2716  00 08E2 0 1 C8 1 1 1 0 
 2724  E0 FFFF 1 0 CF 1 1 1 0 -- tries to push bogus return address
 2732  08 FFFE 1 0 CF 1 1 1 0 -- (but's that's ROM)
 2740  E3 FFFD 1 0 CF 1 1 1 0
 2748  09 FFFC 1 0 CF 1 1 1 0
 2756  08 FFE6 0 1 C9 1 1 1 0 -- correctly fetching BRK handler from FFE6
 2764  E0 FFE7 0 1 C9 1 1 1 0
 2772  40 E008 0 1 02 1 1 1 0 - RTI
 2792  09 FFFC 0 1 CF 1 1 1 0 -- flags
 2800  E0 FFFD 0 1 CF 1 1 1 0 -- parse vectors as return address
 2808  08 FFFE 0 1 CF 1 1 1 0
 2816  E0 FFFF 0 1 CF 1 1 1 0
 2824  00 08E0 0 1 C8 1 1 1 0 -- so end up at the same wrong place
 2832  00 08E1 0 1 C8 1 1 1 0

So ... why on earth is the stack pointer randomly dying and changing from 01FB to FFFF? I have no idea. Theoretically only the TCS and TXS instructions should be able to change the stack pointer, and neither are present.

So I have to guess you've got bogons in your CPU. It might be induced by power rail noise, but beyond that I don't have any ideas.

[Poot36]

Well I have tried powering the SNES from a battery pack ~11.5V 0.377A was drawn when it was connected to the fuse in the SNES. Is this high current consumption for a SNES? I also have a LA trace from it running off battery and I don't think it will be very different (I still am having it not give me consistent readings on startup). I also tried 5V from 4 NiMH battery's bypassing the regulator and it drew around 0.300A or so (battery's were somewhat flat). I still got a black screen on all of the tests. Is it possible that there is some sort of big power consumption that happens when it goes bad that I would need a scope with a storage memory to capture? Do the SMD caps on the SNES usually go bad? I wonder if a test program under 2.5K or so would work or not. It would be nice if this http://wiki.superfamicom.org/snes/show/ ... ES+Program tutorial would be rewritten as small as possible and as a NTSC version. Would that be a good test?

[lidnariq]

As far as I know, that sounds like typical power consumption.

Electrolytics eventually dry out, but SMT ceramics should be fine. And I was hoping power rail coupling issues, rather than the wall wart producing bad power... although verifying that it's not the wall wart is useful.

It tentatively looks like any program that doesn't use the stack should be ok, at least for now. So ... here's a hacked together a version of tepples's test that doesn't use the stack at all... the bit where the 65816 doesn't support setting the DBR (A16..A23 during data accesses) except by using the PLB instruction is a lot inconvenient. But for an image that's at most 32 KiB in size, I guess it's trivial to work around (since the DBR powers on as 0)

Patch and sfc file are included. This change is (obviously) a lot more invasive than just changing the linking behavior, so the patch is a good deal larger.

[Poot36]

Well good news it does boot and show the image and both controller ports work. However it usually takes a push of the reset switch to make it work. On first power application it will sometimes show a black screen or a screen with garbled lines, triangles or other nonsense and if I reset it after that it will start working properly and stay working. I have attached a LA traces of it booting to the black screen, after reset and when it is running. The reset trace was triggered off the SYSCK going high due to the address bus not sending the 0x0100 again but was still clocked of the XIN pin. I think this proves the PPUs are ok. Is it possible that one of the unused pins on the CPU is not being grounded or held high properly (internally in the CPU die or externally) and causing this weard condition? I have found that the longer the SNES is left in the working state the less likely that removing power and draining the caps will affect it starting up (ie it will start properly on first power up).


Edit: I think the glitching at first powerup may have been caused by a bad or dirty cartridge connection, will check this tomorrow.

[lidnariq]

I think this proves the PPUs are ok.

It's not an exhaustive test—after all, it's just a single layer of background, with sprites, using SNES mode 0 (four layers of 2bpp graphics). But it does insinuate the only problem you're having is the CPU's stack.

Is it possible that one of the unused pins on the CPU is not being grounded or held high properly (internally in the CPU die or externally) and causing this weird condition?

It's certainly possible that this could be caused by a cold solder joint or a broken bond wire, but I don't really have any ideas where to even guess. Especially without a decap'd 5A22 to look at where the stack pointer is on the die, or what's near it.

We know that the RAM and DMA work, since the sprites show up in the right places and with the right tile.

[Poot36]

Is there any other tests that I can do to try and figure out what else is broken? Is there any games out there that do not use the stack at all? Would it be worth it to pull up and test each of the extra pins on the CPU to see if any of them read differently on my meter? Does this test rule out power rail coupleing?

[lidnariq]

Without going and writing / rewriting some test for all of the PPU modes, it'd be hard to say conclusively. But really, I'd assume one single failure.

Unfortunately, the stack is such an intrinsic part of almost all CPUs that I can't imagine anything existing that doesn't use it. If nothing else, not having the stack means you can't even use interrupts.

It doesn't rule out power rail coupling because the symptom was the stack pointer being reset to FFFF when the PLB instruction executed. I suppose it's conceivable that the PLB instruction is actually the only problem... that sounds easy to test. Here's yet another version of tepples's pad test; this one ONLY omits PLA/PLB/PLK/PLP/PHA/PHB/PHK/PHP instructions, but still uses the stack in JSR/JSL/RTI/RTS/RTL instructions.