what is the spc700 input clock frequency?

Can someone tell me what the input clock frequency to the SPC700 is? Is the spc700 cpu clock input 1.024MHz or 2.048MHz?? Half the docs i read say 1.024M, the other half say 2.048M.

I'm not asking for any "effective" clock rate. I'm asking for the actually clock frequency driven into the CPUK pin of the spc700 by the S-DSP.

The most recent reverse engineering doc i've seen is the fullsnes doc from nocash. He measured it to be 2.048MHz on an o-scope. Also, the snes dev manual says that it is 2.048MHz as well. This makes sense since the spc700 has an 8-bit prescaler for generating the internal timers. And 2.048MHz/(2^8)=8kHz. This is also consistent with other S-DSP docs which say that the S-DSP drives 24.576MHz/12 signal to S-SMP (and 24.576MHz/12=2.048MHz).

Yet I have other docs that insist that the SPC700 clock is 1.024MHz.

Maybe the problem is that the "actual" clock input to the SPC700 is 2.048MHz and the "effective" clock rate is 1.024MHz? And most of the docs are simply are not specifying which they are referring to - actual/effective? Could that be what's causing the inconsistency?

Docs I have say the oscillator that drives the "Sound DSP" is 24.576MHz. The only other thing I can find in the same doc is mention of "Minimum Command Execution Time" which is labelled as "1.953 microseconds / 2.48MHz when active". Pay close attention there: 2.48MHz, not 2.048MHz. But it could be referring to a different/unrelated thing, or be a typo/mistake in the documentation. If you have the same docs I'm referring to (heh heh heh), see pages 2-22-2 and 3-1-1.

Fullsnes - Nocash SNES Specs claims 2.048 MHz, but I measure 1.025 MHz at pin 16 on the S-SMP:

I'm nearly certain that is a typo in the documentation. I don't see how it can be anything else. 2.48M also doesn't jive with any other doc I've seen. It's also not a multiple of 1.024M which all the frequencies I've seen so far (i.e. 2.048M, 3.072M, 24.576) are multiples. There are definitely some other glaring errors in that doc too which lessens it's credibility.


Thanks a lot for taking the time to do that Blargg. nocash does also say in the doc:


Do you think if you had a 10x probe you would also see 2.048MHz?

I guess 2.048M makes a lot more sense to me because if the input clock was only 1.024MHz then they would only need a 7-bit prescaler for the timers (1.024M/(2^7)=8kHz) instead of 8-bit. It seems really strange that they would design an 8-bit prescaler but only ever use 7 of the bits...doesn't it?

The meter has a 4 MHz frequency range, so 1 MHz is well within it. The second photo is of a scope with a 10x probe showing the clock waveform, with the cursors on it showing frequency. It's well within the scope's bandwidth so we're seeing the actual waveform. It's not 50% duty cycle because it's derived from I believe a 3.072 MHz clock (21.57 MHz master crystal/7), where every two out of three clocks are DSP memory cycles (if I remember correctly), with the S-SMP interleaved on every third one.

Very cool. Thanks a lot.

Hmm..21.57MHz/7? I've never seen 21.57MHz listed anywhere. Did you mean 24.576MHz/8? Or am I missing something?

24.576MHz/8=3.072MHz
21.570MHz/7=3.08MHz

It wouldn't be a later revision that derives the clock from master/7 to save the cost of a crystal oscillator, would it?

I was probably just misreading the tiny printing on the crystal. Looking again it's 24.57 MHz, and a divide-by-8 would give the ~3.072 MHz 3x clock.

I can't tell from the pictures, is it showing a 66% or 75% duty cycle?

Hmmm, meter says 75.1%. I'll have to look at the memory access patterns again to see how many DSP accesses are between each SMP access.

Top trace is 32K SRAM /OE, bottom trace is 1.024 MHz clock to S-SMP, 200 ns/div (40 ns/subtick on graticule). So indeed, there are two S-DSP accesses between each S-SMP access.

That looks exactly as what I was mentioning in the "CPUK caution". The signal should 2.048MHz with 50% duty, not 1.024Mhz with 25% duty.
I trust that your tools can handle frequencies up to 4 MHz or higher. But isn't the problem. The problem is that the tools apply some load to the clock line, and that does somehow "collapse" the clock genererator in the chip.
Try the scope with x10 probe. If you still see 25% duty try inserting a big resistor between scope and clock. And mind that the glitch is sticky: once when the clock has "collapsed", it will stay so until you switch power on/off.

The master clock is 24576000Hz, give or take couple hundred Hz as it uses a ceramic resonator rather than a real crystal. I changed the resonator for a real crystal I stole from a sound card in my SNES.

Maybe so. At one point in testing I did see 2.048 MHz 50% duty. Maybe it's the TEST register changing the clock, since we know it can do that. If a 10x (10 M-ohm) probe can disrupt the clock, it's beyond my care to probe and I'll trust your own measurements. I tried a 10M resistor added to that but no signals could get through due to the capacitance of the probe itself. I could see the clock by just moving the probe near the circuit, without even touching, so that wasn't disrupting it. If it's this fickle then for one it has to be in a SNES rather than powered externally, in which case you can't even get to the pin (soldering a wire would obviously be interfering, so that's out). Another stupid endless rabbit hole that I'm not interested in wasting time on, as you've already done the work apparently

I can confirm that the CPUK frequency is indeed 2.048MHz @ 50% duty cycle. I took the board into work and measured it with an ultra-high impedance, ultra-low capacitance o-scope probe and also looked at it on my logic analyzer using internal clocking @ 250MHz. Both of them showed 2.048MHz @ 50% duty cycle.