Abnormal SPC-DSP reads

Abnormal SPC-DSP reads
by Disch on 2008-05-22 (#33574)

Pretty straightfoward question here, but the answer might not be so simple. Anomie's docs don't clarify... at least not that I saw.

Since the DSP can read from any address for both BRR and Echo data, I'm wondering whether or not these reads should be treated like normal CPU reads.

That is... if the DSP were to read from $00Fx, would it get register contents? Or would it get some dummy value (open bus, maybe?). And would these reads impact the respective areas of the system (like, resetting timer 0's output value if reading $00FD)?

What about $FFC0-FFFF if the IPL Boot ROM is enabled? Would it still read the RAM contents in that area, or would it get the Boot ROM?

EDIT -
Why not ask about writes too. If the DSP writes to $00Fx (by way of Echo buffer writes), would these writes occur? Or are they somehow blocked. Anomie's doc gives me the impression that they'd be ignored with his description of $F8/F9: "These registers act like RAM, except that they can still be written when $F0 bit 1 is set and are not altered by S-DSP echo buffer writes."

Also a somewhat related but not as important question: is it possible for the CPU and DSP to conflict by accessing the same area at the same time. Like, say, if the CPU is writing new BRR data while the DSP is fetching it -- could this cause the DSP to fetch a 'messed up' value?

Thanks in advance!

PS - my terminology may be wrong here. What's the proper name for the SPC's processor... S-SMP? Is the DSP the "S-DSP"? Then what is the "S-CPU" -- is that the SNES's 65c816?

by blargg on 2008-05-22 (#33578)

Quote:
if the DSP were to read from $00Fx, would it get register contents? Or would it get some dummy value (open bus, maybe?). And would these reads impact the respective areas of the system (like, resetting timer 0's output value if reading $00FD)?

All DSP accesses go to RAM, never to $Fx registers.
CPU reads from $Fx always use the registers (even the two that act like RAM).
CPU writes to $Fx go to the registers AND RAM.

Quote:
What about $FFC0-FFFF if the IPL Boot ROM is enabled? Would it still read the RAM contents in that area, or would it get the Boot ROM?

The ROM has no effect on DSP RAM accesses.
CPU reads from $FFC0-$FFFF use the ROM if enabled.
CPU writes to $FFC0-$FFFF always go to RAM.

Quote:
is it possible for the CPU and DSP to conflict by accessing the same area at the same time?

No; for every potential CPU memory access, there are two DSP memory accesses interleved between. So you have a CPU DSP DSP CPU DSP DSP ... access pattern continuously. This means that the CPU and DSP cleanly interleve, making emulation simpler.

Quote:
What's the proper name for the SPC's processor... S-SMP? Is the DSP the "S-DSP"? Then what is the "S-CPU" -- is that the SNES's 65c816?

Yeah, though CPU and DSP are clear enough when talking about the DSP alone.

by Disch on 2008-05-22 (#33581)

Awesome. That's all good news. Couldn't imagine a more emu-friendly setup than that! =D

Thanks a bunch, blargg.

EDIT -

on a somewhat unrelated note... I spotted some minor copy/paste error in apudsp.txt (well not even error -- just inconsistency). After the gauss LUT, some sample code is given with comments:

Quote:
// The above 3 wrap at 15 bits signed. The last is added to that, and is
// clipped rather than wrapped.

"clipped" here is referring to "clamped" (capping) and not the "clipped" as used elsewhere in the doc (wrapping). I made a note of this because of my earlier confusion with the term "clip" and the respective notes at the start of the doc.

Minor detail, but I figure I might as well say something somewhere.

by blargg on 2008-05-22 (#33587)

Yeah, the terminology is confusing. Clip to me is synonymous with wrapping, since it suggests that the upper bits are clipped off and discarded. Clamp sounds like what pliers or a clamp would do to something: force things past some point back to that point. I think in the DSP field the more common term is saturation, which brings to mind the fact that once something is saturated, it can't normally hold any more.

by Disch on 2008-05-22 (#33588)

I always thought of clipping as capping (stopping at max value) because that's how the term is usually used in audio. But it does make logical sense to use it the other way, as well. Due to the confusion I've been trying to refrain from using that term in my code and things. I find myself using 'cap' instead.

I tend to use 'wrap' for the opposite... since that term leaves little/no room for confusion.

But yeah... whatever.

by Bregalad on 2008-05-23 (#33595)

Quote:
The ROM has no effect on DSP RAM accesses.
CPU reads from $FFC0-$FFFF use the ROM if enabled.
CPU writes to $FFC0-$FFFF always go to RAM.

That's great, as it's possible to redefine the reset code yourself without affecting the existing one, then disable ROM instantly without risking to have the CPU crashing if the programm is reset at that time.

I remember seeing some games like Secret of Mana in SNES9x work fine on power on, but when reset you would get crap sound instead, probably because of ROM/RAM switch issues.

Also, I've noted than most SPC player/SNES emulators doesn't emulate DSP echo read/writes at all, so any casual devlopper could use area as normal RAM and enable echo buffer for this area too, causing conflics and either crap samples to be played or the thing to crash on real hardware, while all would be fine in emus.

On the other hand, a software could do weird effects by writing data to the echo buffer and those wouldn't work on most emulators/SPC players as they would use their own echo buffer instead.

by blargg on 2008-05-23 (#33596)

Bregalad wrote:
That's great, as it's possible to redefine the reset code yourself without affecting the existing one, then disable ROM instantly without risking to have the CPU crashing if the programm is reset at that time.

Nope, the IPL ROM is switched back in when the SNES is reset. The ROM is good for getting initial code in, and little else, since its functionality can be duplicated by the uploaded code, and it occupies the area where the table for the optimized TCALL instruction is.