SNES rev 1 black screen at startup

[lidnariq]

Also, I did make the ROM 128 KiB for a simple reason: The DMA source offset is the start of bank 2 ($8000 in the ROM file), so a transfer of the highest possible length (65536 bytes) still wouldn't read data past the end of ROM data. In the case of a ROM file truncated to 32 KiB, I don't know whether transfers bigger than that (i.e., >$8000) are executed correctly at all.

Oops.

That said, Nocash tells me that the bank never changes in an (A bus→B bus) DMA transfer, so a transfer that starts at $008114 or at $018000 will eventually end up overflowing from $00FFFF to $000000 or from $01FFFF to $010000, respectively.

On the off chance that moving things around a little matters, here's the original 128 KiB ROM, pre-reinterleaved for poot36's HiROM test cart:

[Poot36]

Well I just tried the new rom and I left it on $0B99 for 10 min and it did not crash. I will try one address up and one address down for 10 min each and see if I can get a result.

[Poot36]

I tried the two other address's and no crash. Is it possible that a high rom cart does not cause a crash or my CPU is messed up in such a way that it ironically does not crash? I assume a crash would involve loss of video (or very corrupted video) or controller input correct? If so I have not experienced this yet.

[Ramsis]

Whoa, too many misconceptions ...

First of all, it is not addresses you adjust with the d-pad at all but the length of the potentially disruptive DMA executed once per frame, i.e. 60 times per second, and during the so-called active display period.

Secondly, the amount of times you let it do these DMAs is in no way related to the occurrence of glitches and/or crashes. If you see any flickering, the DMA<>HDMA clash is definitely triggered. Its consequences are unpredictable. According to Nintendo, the CPU might stop working altogether (i.e., in my ROM the d-pad would become unresponsive), or HDMA might not be implemented correctly (which presumably causes the flickering).

Some CPUs might react differently than others though. If your v1 CPU never crashes, then that's actually good. I highly doubt it's got anything to do with the mapping of the test ROM or an unreliable console though.

I tried the two other address's and no crash.

Three transfer lengths is not enough. Please try every single length from $0B90 through $0B9F (16 values), but don't bother watching and waiting if you don't observe anything unexpected within two seconds. If there are no immediate glitches, then they won't happen even in two years.

Edit: The $C1XX range is a very good place to trigger the glitch, too.

[Poot36]

Well I tried all of the data transfer lengths and no crash. So I guess I can't provide any LA trace data from a crash because I don't get one. By the way my CPU has these markings on it (S-CPU A, 5A22-02, 1HA 71).

[lidnariq]

OH. Well. That's a rev 2 CPU. Well then.

[Poot36]

The weard thing is the date on the SNES is from 1991. And I believe that the serial number starts with 10 or 11. Could the CPU have been replaced as part of a recall or other similar program?

[lidnariq]

I don't actually know how early N did the hardware revision of the SNES CPU ... or the PPU2 revisions either, for that matter.

Here's a random picture of someone's IC revisions 2/1/2 SHVC-CPU-01 mainboard, so it seems N did the bug fixing before they did the cost reductions.

[Ramsis]

OH. Well. That's a rev 2 CPU. Well then.