Talk:APU DMC

Similarly to the noise channel, the DPCM channel's frequency counter on the die is a 9-bit linear feedback shift register (with taps at the 5th and 9th bits); when I take the counter values from the on-die ROM and run the LFSR until the result is '100000000', the cycle counts (for NTSC) match once multiplied by 2. --Quietust 05:00, 23 January 2011 (UTC)

I suspect there's no "address increment", but another shift register. Just pay attention to the address wrap - if we had a counter, it would wrap to zero, but instead, it wraps to $8000, like ($10000 >> 1). --Zepper 01:49, 6 June 2011 (UTC)

The generated addresses are linear, and I don't think a shift register can do that. So I'm conjecturing an up-counter here. --Tepples 02:30, 6 June 2011 (UTC)

The DPCM address register is only 15 bits wide (with A15 being connected to the VCC rail @ 2850,5450), and the upper bit (A14) gets initialized to 1 (@ 2565,5365) instead of the last value written to $4012 (and the bottom 6 bits get initialized to 0, but we already know this). --Quietust 03:03, 6 June 2011 (UTC)

DMC find

Looks like the DMC silent flag makes difference for $4011 raw output. If this flag is non-zero, the $4011 value written is ignored by the raw output only. I could test a few NSFs and it works flawlessly. --Zepper 14:53, 14 November 2011 (UTC)

By "the DMC silent flag" do you mean bit 4 of $4015? And what exactly do you mean by "ignored by the raw output only"? Do you mean that values are queued up and take effect after the sample period ends? --Tepples 15:10, 14 November 2011 (UTC)

Well, the silent flag is described in the APU DMC section, "The output unit continuously outputs a 7-bit value to the mixer. It contains an 8-bit right shift register, a bits-remaining counter, a 7-bit delta-counter, and a silence flag". Just read the rest of the APU DMC output unit. About the raw output, I mean the timed writes to $4011 register, as listen in Battletoads (drums) for example. --Zepper 15:31, 14 November 2011 (UTC)

So as I understand it, you're saying that in effect, $4011 writes don't take effect if a sample is not playing. Interesting; is there a test ROM for me to run on my PowerPak? --Tepples 17:20, 14 November 2011 (UTC)

Could you point out the location (within the Visual 2A03) of the hardware responsible for this hypothetical behavior? Because if it's there, I can't see it - the internal signal for "write $4011" comes solely from the address+R/W+CLK lines, and when it's active, it immediately updates the position register (of which only the upper 6 bits are a "delta-counter" - the bottom-most bit is just a simple latch) to match the state of D0-D6. An example, for D6: during a write to $4011, t13375 activates and connects node 13255 to node 10616 (D6), then that updates t13885 and causes node 10957 to be set to the inverse of node 13255, then that updates t13872 and causes node 10881 (PCM_OUT6) to be set to the inverse of node 10957, which works out to be the value of D6. --Quietust 22:55, 14 November 2011 (UTC)

Thanks for verifying it. I suspected it's empirical. It works only when emulating $4011, as such behavior do not exist in the hardware. In short words, it's a trick that can be used for emulation only, avoiding sound pops. Sorry for the inconvenience, if any. --Zepper 00:02, 15 November 2011 (UTC)

I mentioned something similar in the enhancement article. But there's still one problem: What happens when the DMC tries to write back to the position register on the same cycle as a $4011 write? --Tepples 00:23, 15 November 2011 (UTC)

Most of the APU "runs" when M2 is low, while writes to registers happen when M2 is high. The logic that updates the DMC position register appears to be an exception, though - I'm not sure what will happen if a $4011 write happens at the same time as an increment/decrement, but I'm guessing the resulting state would be (position +/- 1) AND (data bits). --Quietust 00:45, 15 November 2011 (UTC)

Well, it's the $4011 position register value (7 bit delta-counter) being treated as wave data (raw) too. Since the silence flag is not zero, the value is ignored as wave data, working as it should be. --Zepper 02:24, 15 November 2011 (UTC)

PAL frequency table

Is this table correct? There are two entries I find really strange, for reasons which I outlined here: http://forums.nesdev.org/viewtopic.php?p=94079#p94079

The two values in question:

$4 : $114 = 276
$C : $062 = 98

I think these should have been:

$4 : $10A = 266
$C : $064 = 100

I don't have a PAL NES to test, but can someone confirm if the table in this article is correct or not? The NTSC table represents a scheme that consistently uses the best match to a tone in an A440 tuning. The PAL table does the same thing except these two pitches which are significantly detuned. Either our table is wrong, or the chip was designed "wrong", and I'm open to either possibility, but as I said I cannot verify for myself. - Rainwarrior 22:50, 18 May 2012 (PDT)

With some help from jrlepage, who has a PAL NES, I have verified that the two frequencies are indeed 276 and 98. I guess they implemented the chip incorrectly. Weird. - Rainwarrior 17:30, 25 July 2012 (PDT)

Just for reference, the table I verified is: 398, 354, 316, 298, 276, 236, 210, 198, 176, 148, 132, 118, 98, 78, 66, 50

- Rainwarrior 17:42, 25 July 2012 (PDT)

Pitch table

I removed the pitch names from the table.

The "pitch table" was really a sample rate table. In the table, the frequencies in Hz are sample points per second, or deltas per second. (When talking about pitch, frequencies in Hz are wave periods per second.) In other words, having pitch names in the table isn't useful. It's as useless as saying CD audio that plays at 44100 samples per second is pitch F11 - 23 cents.

If I've made a mistake, feel free to revert. --Bavi H (talk) 20:53, 28 December 2013 (MST)