SNES APU on logic analyzer

Here are some logic analyzer pics of the 65816 CPU interface to the S-SMP (the first 8 signals) and the primary control signals on the S-DSP (the last 7 signals). The logic analyzer was set to internal sampling at 250MHz. The duty cycle and period measurements shown below are not going to be exact but they will be within +/- 4ns. The logic analyzer was set to trigger when a CPU read of $2140 returned the value $AA after the SNES was reset. The trigger point was set to the 10% position. I only captured 32K samples but I can capture more than that. The game running is SMW, probably doesn't make much of a difference though.

High-Level View (shows all samples)
Medium-Level View (shows zoomed in selection of samples)
CPUK Duty Cycle
CPUK Period
PD3 Duty
PD3 Period
CE0x Duty (Edit1=Added, Edit2=Ignore)
CE0x Period (Edit1=Added, Edit2=Ignore)
SNES Schematic (for reference)

Some interesting things to note:
- The CPUK frequency is 2.048MHz as I stated in a previous post regarding CPUK. But here is the proof if anyone wanted it. I could get some o-scope screenshots too, but there's really no need at this point.
- It seems quite clear to me that PD3 is the "clock-enable" signal to the SMP. The PD3 signal is high on every other rising edge of CPUK, making the SMP's effective clock frequency 1.024MHz.
- I'm still trying to figure out what PD2 is. It would seem to me that PD2 must be the read/write strobe to the DSP so that the DSP chip can know whether the SMP is reading/writing to SRAM (so that the SRAM WEx/OEx signals can be driven appropriately). However, if you look at the WEx and OEx signals they seem to be perfectly periodic, as if they were clocks. I think this must just be something that I don't understand yet about how the SNES audio works. (I have only just started looking at this stuff). Any insights?
- Looking at the high-level image the CE0x strobe is also another perfectly periodic signal. Any insights?

--

EDIT1: Added CE0x measurements.
EDIT2: Ignore CE0x measurements as the signal shown as CE0x/CE1x/OEx/WEx are actually different signals.

Is CE0x anywhere close to 32 kHz? That's the output frequency of the audio DAC.

Interestingly enough it's 64kHz... ?

64 kHz would be enough for outputting samples in the order L, R, L, R.

epic fail. Just FYI, before anyone else replies trying to make sense of this, I hooked up some of my probes to the wrong header pins. I will correct the images momentarily and post some new ones. Here are the corrections (which make a whole lot more sense!!):

CE1x = MUTEx
CE0x = MCK
OEx = SCLK
WEx = BCK

Sorry for the confusion. On the other hand, now I'm super-excited to see what the true signals look like. Haha.

UPDATE: W00t!! Confirmed the suspected PD2/PD3 behavior and their signal directions!! Will post the findings tomorrow (er, today actually). But right now time for bed.

So like I said in my previous post I have confirmed the behavior/purposes/direction of the PD2 and PD3 signals that run between the S-SMP and S-DSP.

PD3 = Clock-Enable signal from S-DSP to S-SMP. PD3 is high on every other rising edge of CPUK. Making the effective clock frequency 1.024MHz.

PD2 = Tri-state control signal from S-SMP to S-DSP. This signal is used by the S-DSP's MD bus I/O buffers to control when it should drive the MD bus (on a write to SRAM), or tri-state the MD bus (on a read from SRAM). You can see in the high and medium level zoom screencaps below how the PD2 signal coincides with the S-DSP's WEx strobe.

High-Level View (shows all samples)
Medium-Level View (shows zoomed in selection of samples)

And here is a capture of the 65816 trying to read $AA, then $BB from $2140 during the ROM bootstrapping. It fails the first two times then succeeds the 3rd time. It fails because the SMP was still busy zero-filling RAM during the first two attempts.

$2140 Reads

I will update my schematic with this new information.

UPDATE: Schematics updated: https://dl.dropboxusercontent.com/u/36237540/SNES/jwdonal/schematics/snes_schematic.zip

This SPC700 IPL boot rom is screwy. Not only does it put the stack at $01EF instead of $01FF as everyone is well aware, but it only ever clears addresses $EF-$01 of the zero page. It doesn't ever even clear $FF or $00. This was throwing me off because i was trying to trigger my LA on the last write to $00 but it wasn't triggering. I had thought there was something wrong with my trigger settings. Anomie's spc700.txt is actually wrong on this. The disassembly of the ROM says that it clears the zero page, but it doesn't. It only mostly does...haha.

Just thought I would ask...is there anything in particular anyone would like me to check out while I've got this thing all hooked up?

This was my interpretation of the boot ROM back when I was working on SPC-700 stuff:

I would really, really appreciate as precise as possible measurements of the S-CPU clock speed on both NTSC and PAL (or if you only have one, just that one is better than nothing)

I know that the 21576000hz S-SMP clock tends to actually be closer to 24606720hz. I wonder if there is similar observed bias with the NTSC and PAL S-CPU clock rates.

Current guesses are 21477272hz for NTSC, and 21281370hz for PAL. That number comes from NES emulators though, I don't know that anyone's ever actually tested the PAL CPU clock speed before.

To get that really really precise measurement I would need a good oscilloscope with good high-impedance, low-capacitance probes...which I don't have at the moment. I can't get a precise frequency measurement on a clock with a logic analyzer. Only +/- 4ns resolution. So sorry, but I will be getting an o-scope pretty soon so I'll keep your request in mind.

Can you measure something that's said clock divided to a lower frequency? That increases the effective resolution 4ns gives.

The nominal clocks speeds and multipliers/dividers should be as so http://nocash.emubase.de/fullsnes.htm#s ... scillators
PAL and NTSC color clocks are based on the television standards, which doesn't leave much room for speculation (unless nintendo should have made some terrible mistake when purchasing their oscillators).

APU clock comes from a separate "24.57MX" oscillator, assuming that 1.024MHz and 32kHz are the exact nominal clocks, then the exact nominal APU oscillator value should be 24.576MHz (for both PAL and NTSC).

If you've measured 24606720hz as APU clock in relation to Main CPU... that's at least more or less confirming that values... though the APU is bit faster as expected and/or the Video/MainCPU slower as expected. Do you get same ratios on different consoles? It might be just caused by some tolerance in the accuracy of the used oscillators.

The measured value (24606720 Hz) is 0.125% faster than the nominal frequency (24576000 Hz). That would cause the audio pitch to shift upwards by about two cents relative to a perfect oscillator. I think that's close enough.

The main oscillator must have much better regulation; NTSC requires that the oscillator be within ±0.0003% of the nominal value. Too far away from that, and there won't be any color. (PAL most likely has similar requirements, although I haven't found the exact value yet.)

The SPC clock is coming from a ceramic resonator instead of a crystal, those have much higher error margin.

I'd go so far as to say that ceramic resonators are expected to have 0.1% error, and that it is expected to drift dramatically as a function of temperature and age. (A random datasheet says 0.3%/ten years and 0.3%/30°C)

Both Alpha-II and I want to say anomie measured theirs and found the APU sample rate at around 32040hz. * 768 gets you 24606720hz. I also believe an snes9x.com forum member confirmed that sample rate as well.

http://www.alpha-ii.com/Info/snes-spdif.html

By the way, how in the world does S-CLK do a *6 /5 on the PAL crystal? That's ... you'd think there would be serious rounding errors introduced that way ...



Ah, now this I did not know. That is very interesting.

I wonder whether we should go with 32000hz (the "perfect" value), or the more observed value of 32040hz, then.

Software will definitely be able to tell the difference, especially HDMA audio streamers.

If it's a ceramic resonator, then software should expect to have to adapt to different frequencies over the course of a single execution as the console heats up.

Don't know how, but it does definetely take 17.xMHz as input, and spits out 21.xMHz (as a nice evenly spread waveform, all cycles having the same length, without visible rounding errors). And the *6/5 formula can be verified by counting the number of clock cycles per frame, or by comparing it against the APU clock.
Maybe the frequency conversion is done on the fly, or maybe it's done in separate multiply-then-divide steps. Division would be simple (just skip some clock cycles). Multiply by six is more difficult (probably some analog trickery that inserts extra cycles), accuracy isn't too important as the result will get resynchronized on each 6th clock cycle, that will eliminate any rounding errors (eg. if the first 5 cycles are 1% longer than they should be, then the 6th cycle will become shorter accordingly).

Multiplying by 6 uniformly and exactly is trivial if you're doing the multiplication in analog (using a PLL). (Dividing by 5 subsequently is easy, regardless)

I was just gazing on a SNES mainboard, like here http://commons.wikimedia.org/wiki/File: ... B01_01.jpg The blue thing is the ceramic resonator (APU clock source), and the silver thing underneath of the red trimmer is the crystal (main cpu and video clock source)...
My question is: What is that red trimmer used for? Does it allow to adjust the clock frequency? Or does it adjust the height (voltage) or shape (sine) of the clock's waveform? Or something else?

The red one made image black and white on my TV over composhit or S-video in some positions, occasionally also made the pattern on vertical lines shift. I would say adjusts the freq.

It's a frequency trimcap, which you can see in sector A4 on jwdonal's retranscribed schematic.