What the DMC actually is

The NES’s delta modulation channel is not a sample player in the sense a modern musician means. It is a 1-bit delta playback engine: a stream of single bits, each one nudging a 7-bit output counter up or down, clocked at a rate you choose from a 16-entry table. The NESdev wiki describes it as an “automatic 1-bit delta-encoded sample playback unit” whose 7-bit counter can also be loaded directly by the CPU through $4011 (APU DMC).

That distinction matters for the drum question. A kick or snare rendered as a DMC sample is not stored as a waveform. It is stored as a sequence of decisions: go up, or go down. The channel reconstructs an approximation of the waveform by integrating those decisions. If you want to understand why NES percussion sounds the way it does, and why the CPU cost is what it is, you have to start at the bit level.

One framing note before going further: the retrieved documentation describes the DMC as a general-purpose delta playback channel. It does not document any specific commercial game’s use of DMC samples for drums. Treat “drums as 1-bit samples” as a use case the hardware permits, not as a claim about what any named title did. The register mechanics and cycle costs below are sourced; the musical application is inference from those mechanics.

The register map: four writes and a control bit

The DMC occupies $4010 through $4013, with playback started and stopped through bit 4 of $4015. Each register has a precise job.

$4010: rate, loop, and IRQ enable

The low four bits of $4010 select a playback rate index from $0 to $F. The wiki states that the rate bits “determine for how many CPU cycles happen between changes in the output level during automatic sample playback” (APU DMC). Bit 6 is the loop flag; bit 7 enables the sample-end IRQ.

The period table is the only numeric anchor you need for budgeting. On NTSC, rate $F clocks every 54 CPU cycles; rate $0 clocks every 428. The full NTSC sequence is 428, 380, 340, 320, 286, 254, 226, 214, 190, 160, 142, 128, 106, 84, 72, 54 CPU cycles per output bit. PAL values differ slightly; the wiki lists them separately.

Those periods are per bit, not per byte. A byte is eight bits, so at rate $F a byte lasts 432 CPU cycles, and at rate $0 it lasts 3,424. That is the number that governs both the pitch of the reconstructed waveform and how often the memory reader has to refill the sample buffer.

$4011: the direct counter load

Writing to $4011 sets the 7-bit output counter directly. This is the escape hatch: you can bypass delta playback entirely and drive the counter from CPU writes, which the wiki notes allows “flexible manual sample playback via CPU” (APU DMC). It is also how you set a starting level before a delta-encoded sample begins, and how you silence the channel when using it for IRQ timing.

One hardware quirk is documented: if the automatic playback unit clocks the counter on the same cycle as a $4011 write, the write can be ignored. The wiki flags this explicitly. If your trace shows a counter value that does not match the write you issued, check for a coincident timer clock before assuming an emulator bug.

$4012 and $4013: address and length

The address and length fields are encoded, not direct. The wiki gives the formulas:

• Sample address = $C000 + (A * 64), where A is the byte written to $4012.
• Sample length = (L * 16) + 1 bytes, where L is the byte written to $4013.

Both are reload values. Restarting the sample reloads the address counter and bytes-remaining counter from these registers. The address granularity is 64 bytes, so you cannot place a sample at an arbitrary byte boundary; the length granularity is 16 bytes plus one, so the shortest sample is one byte and the longest is 4,081 bytes.

The CPU memory map page adds a practical constraint: DPCM samples are limited to $C000–$FFF0, and playback wraps from $FFFF to $8000 (CPU memory map). The wiki notes that using the wraparound is challenging because of banking and the interrupt vectors at the top of the address space. For most engines, the usable window is the straight $C000–$FFFF range.

$4015: start, stop, and status

Bit 4 of $4015 enables the DMC. Writing the bit set restarts playback only if the bytes-remaining counter is zero; if bits remain in the shift register, those finish first. Writing the bit clear sets the bytes-remaining counter to zero, so playback finishes before the next fetch. Reading $4015 returns the DMC interrupt flag in bit 7 and the sample-playback-active flag in bit 4.

There is a documented IRQ quirk worth knowing if you use the DMC as a timer: the IRQ is generated when the last byte is read, not when the last bit plays. The wiki recommends writing $4015 three times in a row when starting a dummy sample for timing purposes, because the sample buffer can empty between writes and trigger an immediate IRQ.

How a bit becomes a voltage

The output unit is an 8-bit shift register feeding a 7-bit up/down counter. On each timer clock, the least significant bit of the shift register decides the direction. The wiki is precise about the step size: a 0 decrements the counter by 2 if the current level is above 1; a 1 increments by 2 if the level is below 126. The difference per bit is 2, not 1. The shift register then shifts right.

This is the detail that trips people up when reading a DMC sample dump. The bits are consumed least-significant-bit first within each byte. A byte of $00 is eight decrements; a byte of $FF is eight increments. A byte of $AA (binary 10101010) produces alternating increments and decrements starting from the low bit, which is 0, so the sequence is down, up, down, up, and so on. If you disassemble a sample and the waveform looks inverted, check your bit order before blaming the encoder.

The counter clamps at the rails rather than wrapping. That means a long run of 1s saturates at 126 and stays there; it does not roll over to 0. This is why DMC samples tend to have a characteristic flat-topped look when they hit the ceiling, and why encoders that do not account for the clamp can produce audible distortion at high amplitudes.

What happens when the buffer runs dry

The output unit and the memory reader run in parallel. The output unit consumes bytes from an 8-bit sample buffer; the memory reader refills that buffer via DMA. If the buffer is empty when the shift register finishes a byte, the output unit does not update the output level for the next eight timer clocks. The wiki states this directly: “If the sample buffer is empty: do not update the output level for the next eight timer clocks and buffer empty check repeats.”

In practice, this is a hold, not a glitch. The counter stays at its last value for eight bit-periods. If the DMA is late, you hear a flat segment rather than a dropout. For percussion, a short hold at the tail of a sample is often inaudible; a hold in the middle of a transient is not. This is one reason sample length and rate interact: a faster rate consumes bytes faster and gives the DMA less slack.

The memory reader and the DMA cost

The memory reader has three internal pieces: an address counter, a bytes-remaining counter, and the 8-bit sample buffer. When the buffer is empty and bytes remain, the reader performs a DMA fetch. The address counter increments after each fetch and wraps from $FFFF to $8000. The bytes-remaining counter decrements; when it reaches zero, the loop flag either reloads the address and length from $4012/$4013 or the sample ends and, if enabled, the IRQ flag is set.

The cycle cost is where the honest accounting matters. The APU DMC page says the DMA “halts the CPU for 1-4 cycles to read the target byte” (APU DMC). The DMA page is more specific: “DMC DMA normally takes 3 or 4 cycles, depending on whether alignment is needed” (DMA). The 1–4 range on the DMC page and the 3–4 range on the DMA page are consistent if you read the first as the halt window and the second as the full transfer including the dummy cycle and optional alignment.

The DMA page breaks the sequence down: a halt cycle, a dummy cycle, an optional alignment cycle, and the get. Load DMAs, which occur after $4015 bit 4 is set with an empty buffer, are scheduled to halt on a get cycle during the second APU cycle after the write, which is the third or fourth CPU cycle. Reload DMAs, which occur when the output unit empties the buffer, are scheduled to halt on a put cycle. Because of that scheduling difference, load DMAs take three cycles and reload DMAs take four unless the halt is delayed by an odd number of cycles.

That asymmetry is the practical takeaway for a music engine. Starting a sample and letting it run are not the same cost. If you start several samples in a frame, the load DMAs land on a predictable cycle relative to the $4015 write; the reload DMAs that follow are scheduled against the put cycle and can be delayed by whatever the CPU is doing. A trace that shows only the total frame time will hide this; a trace that marks each DMA halt will show it.

Overlap with OAM DMA

DMC DMA and OAM DMA use independent units. When they collide, DMC gets priority and OAM pauses. The DMA page gives the common-case cost: “In the common case, DMC DMA occurring during OAM DMA will cost only 2 cycles: 1 cycle for the DMC DMA get and then 1 cycle for OAM DMA.” That is cheaper than a standalone DMC DMA because the no-operation cycles overlap.

This matters if you are pushing sprite updates during active DMC playback. The naive budget of 3–4 cycles per fetch overestimates the cost when the fetch lands inside an OAM transfer. It also means the worst case is not simply the sum of the two transfers; the interaction depends on alignment.

The register-conflict hazard

On the 2A03 used in the NTSC NES and Famicom, a DMC fetch that coincides with a read of a register with read side effects causes extra reads. The wiki names the affected registers: controllers via $4016 or $4017, PPUDATA at $2007, and the Vblank flag in PPUSTATUS at $2002. The result is “data loss or corruption” (APU DMC).

The DMA page explains the mechanism: when the CPU is halted, the 6502 core repeats the last read cycle, and on the 2A03 those repeated reads are externally visible. If the last read was a controller port, the controller sees multiple reads and the shift register advances more than once. The page notes that the 2A07 PAL CPU is suspected to put a different address on the bus during no-operation cycles, which mitigates the problem, but the source does not claim the PAL part is fully immune.

For an engine that polls controllers every frame while DMC playback is active, this is a checkable property of the code, not a matter of luck. The standard workaround is to read controllers with interrupts disabled and to ensure the read sequence is not interrupted by a DMC halt, or to read controllers only when the DMC is stopped. If you are auditing a disassembly, look for controller reads inside a region where $4015 bit 4 is set and the sample buffer is likely to be refilled.

Budgeting a drum kit against the CPU

The DMC gives you one sample channel. The other four channels — two pulses, triangle, noise — are generated by hardware timers and do not steal CPU cycles for playback. The DMC does, because it fetches its own data. That is the trade: you get a sampled transient at the cost of periodic CPU stalls.

The budget is straightforward once you fix the rate. At rate $F, a byte lasts 432 CPU cycles and the DMA costs 3–4 cycles, so the overhead is under one percent of the byte period. At rate $0, a byte lasts 3,424 cycles and the overhead is proportionally smaller. The cost is not the per-byte DMA; it is the unpredictability of when the halt lands relative to your code. A reload DMA scheduled on a put cycle can be delayed by up to three cycles if the CPU is in a write-heavy sequence, and the delay shifts the fetch later in the frame.

For percussion, the useful rates are the fast end of the table. A snare transient that lasts a few milliseconds needs a high bit rate to capture the attack; at rate $F, 54 cycles per bit, a 4,081-byte sample is 32,648 bits and lasts about 1.76 million CPU cycles, which is roughly 59 frames at 29,780 cycles per frame. That is far longer than any drum hit needs, so the length register is usually set well below maximum. The exact length is a design choice, not a hardware constraint.

The loop flag is the other tool. A short looped sample can serve as a sustained tone or a repeating percussion texture, and the loop reload is automatic: when the bytes-remaining counter reaches zero with the loop flag set, the address and length reload from $4012/$4013. The wiki notes that the loop flag inhibits the IRQ pending flag, so you cannot use the sample-end IRQ and looping at the same time.

Building a reproducible artifact

The claims above are checkable against a trace. A minimal artifact for a DMC drum experiment has four parts:

1. The $4010 value, decomposed into rate index, loop flag, and IRQ enable. Write it as a binary literal so the bit positions are unambiguous.
2. The $4012 and $4013 values, with the computed address and length shown alongside. For example, $4012 = $C0 gives address $C000 + ($C0 * 64) = $F000; $4013 = $10 gives length ($10 * 16) + 1 = 257 bytes.
3. The $4015 write that starts playback, with the cycle count from the write to the first DMA halt. The DMA page predicts a load DMA on the third or fourth CPU cycle after the write.
4. A marker for each subsequent reload DMA, with the cycle count between the buffer-empty event and the halt. The DMA page predicts a put-cycle schedule for reloads.

An emulator trace that logs APU register writes and DMA halt cycles will show all four. If the observed halt counts differ from 3–4, check whether the halt was delayed by a write or an interrupt; the DMA page lists delays of up to three cycles for read-modify-write instructions and interrupts.

The sample data itself is the other half of the artifact. A hex dump of the 257 bytes, with the bit order annotated, lets a reader reconstruct the counter trajectory by hand: start at the $4011 value, read each byte least-significant bit first, add or subtract 2 per bit, clamp at 1 and 126. If the reconstructed trajectory does not match the audio, the discrepancy is in the encoding or the starting level, not in the playback hardware.

What this means for the drum question

The DMC can store a drum hit as a 1-bit delta stream. The hardware supports it: the rate table covers the frequencies a percussion transient needs, the length register allows samples short enough to fit a hit, and the loop flag allows repetition. The cost is a periodic CPU stall that is small per byte but variable in timing, and a register-conflict hazard that constrains when you can read controllers and PPU data.

What the retrieved sources do not establish is which games used the channel this way, at what rates, or with what sample lengths. Those are questions for a disassembly or a trace of a specific ROM, not for the register documentation. The documentation tells you what the hardware can do and what it costs; the artifact tells you what a particular engine did with it. Keeping those two kinds of claim separate is the difference between a register-level analysis and a story about how games used to sound.

FAQ

Is a DMC sample stored as PCM?

No. It is a stream of 1-bit deltas. Each bit increments or decrements a 7-bit counter by 2, with clamping at the rails. The counter output is the audio signal. A PCM waveform would store absolute amplitude values; the DMC stores only direction.

Why does my DMC sample sound flat at the top?

The counter clamps at 126 rather than wrapping. A long run of 1 bits saturates the counter and holds it there. If your encoder does not account for the clamp, loud passages will flatten. Reduce the amplitude of the encoded signal or shorten the runs of identical bits.

How much CPU time does DMC playback steal?

Each fetch costs 3 or 4 cycles depending on alignment, per the DMA page. The fetch happens once per byte, so the overhead relative to the byte period is small: at rate $F, a byte lasts 432 cycles, so the DMA is under one percent. The larger cost is the unpredictability of when the halt lands, which can delay other timed code.

Can I use the DMC and read controllers at the same time?

On the 2A03, a DMC fetch coinciding with a controller read at $4016 or $4017 causes extra reads and corrupts the result. The workaround is to read controllers when the DMC is stopped, or to use a read sequence that is not interrupted by a DMC halt. The 2A07 is suspected to mitigate this by putting a different address on the bus during no-operation cycles, but the source does not claim full immunity.

What is the longest DMC sample?

The length formula is (L * 16) + 1 bytes with L an 8-bit value, so the maximum is 4,081 bytes. The address must be in the $C000–$FFF0 range, and playback wraps from $FFFF to $8000. The CPU memory map page notes that using the wraparound is challenging because of banking and the interrupt vectors.

Can the DMC generate an interrupt?

Yes, if bit 7 of $4010 is set and the loop flag is clear. The IRQ is generated when the last byte is read, not when the last bit plays. The wiki recommends writing $4015 three times when starting a dummy sample for timing, because the buffer can empty between writes and trigger an immediate IRQ.