Thanks for posting those.
Now I have what I believe is a somewhat late PAL SNES that seems to hate a lot of blargg's tests.
The DSP test seems to deviate during the "KON then KOFF" test. KON should immediately silence the volume envelope, set the state to attack and start increasing the volume envelope and playing the sample after the initial KON delay. Setting KOFF should set the state to release and decrease the envelope by eight every sample.
I would imagine this test examines the envelope value, so it wouldn't need a sample. It looks as though 00-07 are the channels with the next ten values being the envelope output. According to anomie_dsp there the high bit should always be zero, so that column of 80 seems rather mysterious. It might be reading the value as it is getting set and picking up noise, but perhaps there is something else going on.
Now the memory access test, this one has both a standalone version as well as being included in the SMP test. My SNES fails both. The CRC is different from one run to the next.
This is the output from one particular run of the standalone version:
The output is a breakdown of opcodes that contain cycles that involve memory accesses, but the output here is notably wrong in a lot of places. "R" is "read", "W" is "write". "D" is data which can be either read or write depending on mode. The numbers are first read, second read, and so on.
I wouldn't expect for there to be actual differences in the cycles themselves. It's far more likely there is some inconsistency with DSP writes on my system that the test doesn't account for. The technique should be to have the echo buffer write at or around the point where the SMP would perform a memory access.
Timing is absolutely critical here, so if the method used to synchronise the SMP and DSP is off by one on some systems then it's going to cause problems. There might be a few different ways, but I would suspect watching for timer updates may have been appealing.
I did stitch that image together, but the intermittent black lines indicate the screen is updated using forced blanking as opposed to vblank, so either test failing does not seem at all likely to be caused by anything timing related on the CPU/PPU side.
I haven't looked at what either test is actually doing, so my interpretations could be very wrong. They might even be doing something even more exotic.
blargg's mul/div tests never behaved on my system either. The multiplication one at least produced a consistent CRC, but the division one was very erratic producing one of thirty or so different hashes at random. Neither test ever passed.
Perhaps a few people with a few different consoles could test all these and note whether they pass all tests or fail any of them? I'd at the very least like some reassurance that these anomalies aren't completely unique to my own SNES.
If anyone has better/different explanations for any of these, that would be nice too. ^_^