Noise/DMC clock rate edge cases

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Noise/DMC clock rate edge cases
by on (#166677)
So the APU clock rate is half the CPU clock rate. But as an additional punch in the balls, the Triangle uses the CPU clock rate instead of the APU. And the frame sequencer uses "half cycles" so conceptually it might as well just use the CPU clock rate as well.

Additionally... the channel period is actually 1+ whatever is written due to the way the counter wraps.

This is all leading to some confusion for me on how DMC and Noise are clocked. The wiki is woefully unclear, so hopefully someone here can clarify:


Code:
Unit               Clock rate       Period
-------------------------------------------------------------------
FRAME SEQUENCER:    CPU             2 * value as shown on wiki
PULSE:              APU             1 + value written
TRIANGLE:           CPU             1 + value written
NOISE:              APU             ??? value from table    (+1 or not?)
DMC:                CPU             value from table


Since the frame sequencer clocks are outlined on the wiki in the form of "time stamps" and not really periods, I am reasonably sure there isn't a +1. Though I use *2 to convert to CPU cycles so I don't have to deal with half cycles.

Where my confusion comes in is with Noise/DMC. Those values are read from a table and are not used "as written" like Pulse/Tri are.... so would they still have the +1?



EDIT:

Ugh... also I just double-checked the DMC page on the wiki and it says the table numbers are in CPU cycles.... so is the DMC clocked by the CPU clock as well?

Is there ANY point to tracking APU cycles other than dividing the pulse clocks in half?


EDIT 2:

But the DMC wiki does say the table is the number of cycles between clocks... so I guess that answers the question for the DMC. Noise is still unclear, though.


EDIT 3:

So I checked an old emu source and it looks like the Noise numbers on the wiki are in CPU cycles.....

.... so APU cycles are pretty much entirely worthless. I'm saying "screw it" and doing everything in CPU cycles.

Here's a new table to show what I'm doing. If there's a mistake here, please let me know. Also clarification as to whether or not there's a +1 (or +2) to the noise period is still welcome/desired. I'm going to assume it's the same as the DMC and there is no +1.

Code:
Unit               Clock rate       Period
-------------------------------------------------------------------
FRAME SEQUENCER:    CPU             2 * value as shown on wiki       (conceptually)
PULSE:              CPU             2 * value written          + 2
TRIANGLE:           CPU                 value written          + 1
NOISE:              CPU                 value from table       + ?   (I assume +0, but could be +1 or +2?)
DMC:                CPU                 value from table
Re: Noise/DMC clock rate edge cases
by on (#166681)
I don't know why the wiki has any information in terms of "APU clocks", everything should be in CPU clocks, IMO. The reason the wiki is in the state it is, is that some people who added content felt differently about this. :P

The idea of an APU clock is mostly an internal implementation detail. I'm not sure if it could lead to a 1 cycle delay of the output depending on alignment (haven't tested this) but whether or not that happens you're still dealing with the CPU clock anyway. I don't see the point.

The DMC table is in CPU clocks and does not feature a +1. All the period values are even, though, as you may notice, and the evidence points to an "APU clocks" internal implementation. (i.e. the tuning scheme makes logical sense with precision to every second CPU clock; if it could do every clock they would have used more accurate period values)
Re: Noise/DMC clock rate edge cases
by on (#166682)
In response to your edit asking about noise: there is no +1, the table of values is the actual periods.

The easy verification of this that comes to mind is the top few periodic noise values are octaves apart, and seeing "4, 8, 16, 32, 64" in the table bears this out. If there was a +1 these would not be an octave apart.

Back to the idea of +1, though, the DMC sample length has a "+1 byte" errata, which is really unfortunate, because the looping samples feature seems to have clearly been designed around a tuned scale, which is completely borked by this. So there is a +1 on the DMC (just not in the sample period; rather in the sample length), and it's really confusing because it seems to go against the other feature design.
Re: Noise/DMC clock rate edge cases
by on (#166683)
Okay you responded in the middle of a 3rd edit. XD

So it sounds like we're in agreement. APU cycles are stupid and I should just use CPU cycles for everything. No +1 on Noise or DMC -- that's good to know!

Also, yeah I know about the +1 byte on the DMC. But that's a separate thing.

Thanks, rainwarrior.