Looking for CPU<->SMP interface timing test ROM

Are there any test ROMs available which test for proper timing/handshaking behavior between the S-CPU and S-SMP I/O register interface (i.e. $F4-$F7 or $2140-$2143)? I don't think I ever ran any real tests on that interface in my code. I just hooked the wires up blindly and it seems to work fine but a test ROM would be awesome..........

Does the official Nintendo SNES/SFC testing cart, or the burn-in cart do this? (This is a question for anyone who has actually taken the time to reverse-engineer these -- I have not, and I have used neither)

I don't believe any of the official Nintendo test ROMs do any serious timing testing with the SMP, they just poke the I/O ports and make sure the SMP-side driver responds as expected. I can take a closer look after I'm home from work today if nobody else does.

But, if that's all you need, then I guess they would get the job done.

I think they also do an APU RAM test.

This was useful information. I didn't realize that the Test Cart was actually different from the Burn-In cart. I thought they were 2 different names for the same thing. Thanks!

If somebody is making a program for measuring the CPU to APU clock ratio, it would be interesting to run that tool on different consoles and to collect the results somewhere (or did anybody already do such a thing?) the result might vary depending on things like...
- master clock (PAL vs NTSC)
- accuracy/tolerance of the APU clock resonator
- temperature
- maybe the clocks do even change when the power supply gets overloaded by too many controllers connected or similar things?

There are differences between the different versions of SHVC-CPU-01 let alone the 1-chip APU and the 1-chip SNES.
For example, from looking at various images of 1990 SHVC-CPU-01 boards (look at the number near the cartridge slot):
Unmarked - ? cap, ? , S-CPU (01), S-PPU1 (01), S-PPU2 (01), NEC -D43256AGU-12L
1 board - Large C67 cap, BA6592F, S-CPU A (02), S-PPU1 (01), S-PPU2 (01), LH52A256N-10LL SRAM (note the 100ns speed)
2 board - Large C67 cap, BA6592F, S-CPU A (02), S-PPU1 (01), S-PPU2 (01), MOSEL MS62256CL-10F0
or - Large C67 cap, BA6592F, S-CPU A (02), S-PPU1 (01), S-PPU2 A (02), MOSEL MS62256CL-10FC
3 board - Large C67 cap, BA6592F, S-CPU A (02), S-PPU1 (01), S-PPU2 (01), SONY CXK58257AM-12L (note the 120ns speed)
or 3 board - ?,?, S-CPU A (02), S-PPU1 (01), S-PPU2 B (03), MOSEL MS62256CL-10FC (100ns again)

4 board - no C67, S-ENC BA6594F, S-CPU A (02), S-PPU1 (01), S-PPU2 B (03), SONY CXK58257AM-12L (Note PPU version change)
5 board - no C67, S-ENC BA6594F, S-CPU A (02), S-PPU1 (01), S-PPU2 B (03), SONY CXK58257AM-12L
5 board - Large C67, BA6592F, S-CPU A (02), S-PPU1 (01), S-PPU2 (01), KM62256ALG-10
6 board - no C67, BA6592F, S-CPU (01), S-PPU1 (01), S-PPU2 (01), LH52256N-90TL
(pretty sure it's a 7, but might be 1 again)
7 board - no C67, BA6592F, S-CPU A (02), S-PPU1 (01), S-PPU2 B (03), Panasonic MN44256S-10LL

These production line numbers also appear to show on the heatsink.

There are also differences with the APU (SHVC-SOUND) too, but I only have two of them.

Board B - S-SMP 2SU2V, S-DSP 230B64V, 2x MCM51L832AF10
Board E - S-SMP 10KOY, S-DSP 125A46E, LSI LH5P832N-12T and Toshiba TC51832FL-12

There are B boards with 120ns memory as well (seen online.) I've only seen B and E boards, and other than different ram chips, they are the same.

The B APU board I have, oddly enough was paired with a 4 board, while the E APU was paired with the 3 SNES board. So there might not be any connection between the APU version and the CPU board version.

So there is 120ns SRAM on the 3 SNES board but it's E APU has 100ns. While the 4 SNES board with 120ns SRAM has the B APU with 120ns SRAM. The 3 board has the PPU2 (01), while board 4 has PPU2 B (03) (both of these systems are power-on-black-screen, so likely CPU dead.) Then there is that one strange 6 board with the 90ns SRAM but has S-CPU (01), S-PPU1 (01), S-PPU2 (01), but the photo shows half the parts missing, so I don't know what is with that either.

So just from what I listed above, there are two CPU's, two PPU2's, two different SRAM speeds used on the SNES board and 2 different SRAM speeds used by the APU board.

My guess is that the "revision" number were just different assembly lines, as other than the S-ENC and C67 cap, the only thing that changes is the RAM. If 120ns and 100ns memory don't make a difference, then essentially all the SHVC-CPU-01 boards are the same except where the CPU and PPU2 chips changed.

Also look around I've seen a 1994 SNES-CPU-RGB-01 (2) with DSP-A, 100ns SRAM on the APU side, and 70ns on the PPU side (2/1/3 configuration) but the PPU2 is C. 1992 SNSP-CPU-02 WRAM B, S-CPU B(02), S-PPU1(1), S-PPU2 C (03),1993 SNES-CPU-GPM-02 S-DSP A. SNES-CPU-APU-01 (6) that I found online has S-CPU B (02), PPU1 (01), PPU2 C (03) and WRAM B.

On a SNS-CPU-1CHIP-01 model there is CPUN-A paired with WRAM-B and MOSEL MS62256CL-10FC

I wonder if there is a way to actually figure out what version of the CPU, PPU1, PPU2, S-SMP, S-DSP are. The "Lion King" test appears to id the number (the one I included in brackets in above examples) but not the letter of the chip.

It is well-known that there are two major revisions of CPU (1,2) and three major revisions of PPU2(1,2,3). There's an infamous bug in the CPUrev1 DMA unit that will cause the unit to crash (most likely due to destroying the instruction pointer) if both DMA and HDMA would finish at the ≈same time.

There's also whatever's going on in the 1chip models that may or may not resemble what's inside a "2/1/3" console.

Otherwise, the RAM speed issue won't matter. Nothing in the SNES runs anywhere near fast enough to even come close to caring about 120ns vs faster RAM.

The VRAM and APURAM chips used in different production runs differ in more than speed. Some of them are SRAM and others are PSRAM ("pseudo-static RAM", which is DRAM with a built-in refresh generator making it usable as a drop-in replacement for SRAM). I'm pretty sure that SRAM and PSRAM exhibit quite different bit patterns on power-up.

They do, and for APU RAM, this is the reason the Soul Blader intro tune runs so choppy on some consoles. The player routine reads uninitialized RAM and performs calculations based on it (while it shouldn't).

I dumped power-up APU RAM on a number of consoles and listed them here:
https://docs.google.com/spreadsheets/d/ ... sp=sharing

If anyone is interested in the full APU RAM dumps I should still have them.

> There's also whatever's going on in the 1chip models that may or may not resemble what's inside a "2/1/3" console.

Yep, exactly. They stopped bumping the software revision numbers after CPUr2 and PPU2r3.

The 1CHIP system definitely revises both the PPU and SMP, and likely more. Yet they failed to bump the revision numbers.

> I'm pretty sure that SRAM and PSRAM exhibit quite different bit patterns on power-up.

I'd still really like to have a decent simulation of either of them. I've done lots of power-up WRAM+APURAM dumps and the patterns are always nuts.

My LFSR isn't even remotely accurate, but it does at least expose uninitialized RAM errors much easier. Good for homebrew, bad for the fact that many commercial games fail to initialize RAM >_>

Is there an easy way for a test program to tell a 1CHIP from a 2/1/3?

Not that I know of, no. The PPU artifacts appear after they can be observed by software.

The SMP counter glitch not occurring is probably the easiest method, but it's rather complicated to pull off in practice.

Then again, I have not done extensive testing on a 1CHIP before, so it's possible there are more differences I don't know about that are easier to detect.

I ask because one could slightly tweak a game's dialogue to indicate the console revision in-universe, giving testers something to report without breaking immersion.

I'm bumping this just out of interest.

So my previous post was mostly taken from photos and the two non-working SNES's I had.

I've since acquired a 1/1/1 SFC CPU-01 from Japan (production 6) and a GPM-02 (the one without the "APU can" but still the separate chips) and discovered that the APU can on the 1/1/1 SFC is a different letter than the ones I encountered this one is "C". The APU board has 2 Toshiba TC51832FL-12 on it. The SFC has 2 SONY CXK58257AM-12L, and a BA6592F.


The GPM-02 I got has the 2/1/3 configuration (CPU A 02, PPU1 01, PPU2 B 03) and has S-DSP A, HM9453100FP Ram near the S-DSP, no C67 cap.

I've tested both using a S-Video cable before taking them apart, and then tested the SNES again. I had to take the cover off the SFC to test it because the SFC carts I ordered haven't arrived yet, so I just plugged it in that way.

One thing I did notice, the SFC has cooling vents at the front. I wonder if the SNES SHVC-CPU-01 plague in NA units is maybe a humidity/temperture thing? The SNES that I had that failed, the one I acquired from my sister and the one I got from a used-game shop all had the same CPU-death and all had SHVC-CPU-01 boards of 3,4 or 5 production.

I wonder if there's actually any difference if I swap the C with the E or the B board as the the only difference appears to be the RAM. Or maybe we're all barking up the wrong tree here and the issue (laggy drums,uninitialized memory as mentioned by Ikari) is literately a bug in that game.

I have a question:
If the snes's APU ram was so fast (as i understand between 120 and 100 ns), why the WRAM is so slow ??
It was not a cost problem, because i thing a 120 or 100ns is a complete waste for APU's ram .
It was really for reducing cartridges costs ??

Nintendo is infamously frugal on hardware costs.

They could have easily sprung for fast-speed WRAM in SRAM factor, which would've meant that cartridges could've easily gotten away with transferring critical functions into there instead of having to pay for FastROM.

The anemic CPU would've benefited from the lack of DRAM refresh and faster memory accesses.

Of course, the bigger "what if?" loss was that originally the VRAM was designed to be 128KiB, but got halved to 64KiB before shipping. That would have certainly added a few dollars onto the cost, but one can only guess what would've resulted if we'd had that extra memory. (maybe far nicer graphics, maybe no difference at all.)

Probably little difference, given that only 16 KiB of that could be used for sprites anyway.

How much tweaking would it have taken to lower the CPU latency (or whatever it's called) of the 65816 core, like what Hudson/NEC did with Turbografx?

With 128 KB VRAM, we might have seen more Mode 3 in games...

I don't know how feasible it might have been to hook the CPU up to a 16-bit system bus (as the SA-1 kinda did, but only with the ROM). Could have doubled the speed of DMA and substantially improved processing speed. (Backward compatibility would have been a nightmare, but they didn't end up implementing it anyway, so...) Using SRAM for WRAM, even just the bottom 8 KB, could have sped things up further. Getting rid of the half-cycle strobe, as Hudson did, would have been another big jump.

With the faster DMA, OAM could have been expanded without taking an excessive chunk of VBlank, loosening restrictions on sprite sizes and VRAM coverage. There are six unused bits in OAMADDH, so specifying extra tables could have been supported - or the table position could have been specified in OAM directly, allowing access to all of VRAM. (Now that I think of it, a 16-bit system bus with 16-bit DMA would imply a somewhat different design for the PPU register set...)

Combined with the doubled VRAM, this system would have crushed the Mega Drive even before the addition of the DSP-1. But at what price?

(Oh, and it would have been nice to be able to specify L/R gain on echo sends, rather than just on/off per stereo channel...)

MD was actually gonna have 128KB VRAM at some point also (and TeraDrive computer actually has 128KB VRAM connected, and some dev hardware used 128KB also apparently). DMA bandwidth doubles (as it will make the VRAM bus twice as wide), various tables get another address bit for their location and BGs and sprites can choose which 64KB they get their GFX from (there's no room for an additional bit in the tilemap and sprite table entries). Also makes interlace mode pretty much as usable as non interlaced.

I wonder if a custom DRAM part was really that much cheaper than a pair of PSRAM chips in the SNES...

If they had a SA-1 style CPU in the original system, it would be capable to DMA the entire 16kB of sprites at once and still have a lot of time left over. With the addition of 128kB of VRAM and an improved OAM, you can pretty much animate sprites any old way and not run into problems.

I do honestly regret my comment re: the Mega Drive. All of those changes would have made the SNES a better (and more expensive) console on its own merits; going out of my way to compare this alternate-universe SNES with its real-life rival is kinda pointless and smells of fanboyism. Sega left plenty of potential upgrades on the table too...

I really thing that nintendo don't care too mush of the stock CPU power because they were sure they can extand it easily .
There are too many nonsense choices in the snes's design, 128ko of slow ram(32/64 of faster ram would have been enough),a stock 65816,DMA must be slow because of slow WRAM .
With a simple one phase CPU design, you can double the CPU speed with same RAM/ROM .

I think the goal was the cheapest system possible with an easy evolution ability in mind.

Well, DMA speed was still a problem with enhancement chips, because everything still had to be pushed through to the sPPU side.

You know, I wonder if you can stick an FPGA in the system to act like an overclocked Ricoh 5a22, but I don't know how it would fit. Probably would look like a sloppy mess of wires. Wait, better yet maybe there can be a CPU deactivation mod, to allow the cartridge to control the system directly.