Question about DMC channel sample size

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
User avatar
bleubleu
Posts: 106
Joined: Wed Apr 04, 2018 7:29 pm
Location: Montreal, Canada

Question about DMC channel sample size

Post by bleubleu » Sun Jan 24, 2021 1:26 am

Hey guys!

I am working on improving DPCM support in FamiStudio and I was re-reading the DMC channel doc and I have a question.

What do guys think was the reasoning behind samples start addresses being 64-bytes aligned, while having their size being 16x + 1 ?

That "+1" is really wrecking my brain.

Why always play that extra byte? Wouldn't it have made more sense to have sample sizes simply rounded to a nice 16-bytes? Seems like this forces to you add padding between samples in most situation. The only reason I can think of it being designed like this is that it opens up the possibility of having 1 byte samples.

Also, I can clearly see some in NSFs, where samples sizes were already a nice multiple of 64, that they are often located one after the other in memory, without any padding. So I guess nobody cared and just assume an extra byte would be played?

Thanks!

From the wiki:

Code: Select all

    $4012      AAAA.AAAA     Sample address (write)
    bits 7-0   AAAA.AAAA     Sample address = %11AAAAAA.AA000000 = $C000 + (A * 64)

    $4013      LLLL.LLLL     Sample length (write)
    bits 7-0   LLLL.LLLL     Sample length = %LLLL.LLLL0001 = (L * 16) + 1 bytes
-Mat

User avatar
Jarhmander
Formerly ~J-@D!~
Posts: 521
Joined: Sun Mar 12, 2006 12:36 am
Location: Rive nord de Montréal

Re: Question about DMC channel sample size

Post by Jarhmander » Sun Jan 24, 2021 7:14 am

bleubleu wrote:
Sun Jan 24, 2021 1:26 am
Hey guys!

I am working on improving DPCM support in FamiStudio and I was re-reading the DMC channel doc and I have a question.

What do guys think was the reasoning behind samples start addresses being 64-bytes aligned, while having their size being 16x + 1 ?

That "+1" is really wrecking my brain.

Why always play that extra byte? Wouldn't it have made more sense to have sample sizes simply rounded to a nice 16-bytes? Seems like this forces to you add padding between samples in most situation. The only reason I can think of it being designed like this is that it opens up the possibility of having 1 byte samples.

Also, I can clearly see some in NSFs, where samples sizes were already a nice multiple of 64, that they are often located one after the other in memory, without any padding. So I guess nobody cared and just assume an extra byte would be played?

Thanks!

From the wiki:

Code: Select all

    $4012      AAAA.AAAA     Sample address (write)
    bits 7-0   AAAA.AAAA     Sample address = %11AAAAAA.AA000000 = $C000 + (A * 64)

    $4013      LLLL.LLLL     Sample length (write)
    bits 7-0   LLLL.LLLL     Sample length = %LLLL.LLLL0001 = (L * 16) + 1 bytes
-Mat
The accepted theory is that there's an off by one error in the hardware, and that's easily conceivable. That +1 in DPCM length isn't much noticeable, except if you use the looping feature of the channel.

It's even more apparent that it's an off by one error because when using the IRQ feature, that IRQ fires right at the beginning of the last (+1) sample. Meaning that it fires, but the channel is still playing its last sample.
((λ (x) (x x)) (λ (x) (x x)))

User avatar
za909
Posts: 226
Joined: Fri Jan 24, 2014 9:05 am
Location: Hungary

Re: Question about DMC channel sample size

Post by za909 » Sun Jan 24, 2021 8:24 am

I personally suggest ignoring the extra byte, or changing every sample to start with a byte of $55 or $AA to completely remove any unwanted change to the DAC level. It's not really worth doing all that padding to work around a barely noticeable artifact like that, but that's just my take on it.

User avatar
bleubleu
Posts: 106
Joined: Wed Apr 04, 2018 7:29 pm
Location: Montreal, Canada

Re: Question about DMC channel sample size

Post by bleubleu » Sun Jan 24, 2021 6:36 pm

Jarhmander wrote:
Sun Jan 24, 2021 7:14 am
The accepted theory is that there's an off by one error in the hardware, and that's easily conceivable. That +1 in DPCM length isn't much noticeable, except if you use the looping feature of the channel.
That makes so much sense, by far the best explanation. Thanks!
za909 wrote:
Sun Jan 24, 2021 8:24 am
I personally suggest ignoring the extra byte.
Yeah, i'm kind of heading that way. If it was good enough for most games, then i'll probably do the same.

Thanks guys!

-Mat

stan423321
Posts: 35
Joined: Wed Sep 09, 2020 3:08 am

Re: Question about DMC channel sample size

Post by stan423321 » Wed Feb 10, 2021 10:00 am

Jarhmander wrote:
Sun Jan 24, 2021 7:14 am
The accepted theory is that there's an off by one error in the hardware, and that's easily conceivable. That +1 in DPCM length isn't much noticeable, except if you use the looping feature of the channel.

It's even more apparent that it's an off by one error because when using the IRQ feature, that IRQ fires right at the beginning of the last (+1) sample. Meaning that it fires, but the channel is still playing its last sample.
How is the latter part an error? If you want continuously decoded samples, firing the IRQ after the last sample stopped playing would be already too late, wouldn't it?

User avatar
rainwarrior
Posts: 8006
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Question about DMC channel sample size

Post by rainwarrior » Wed Feb 10, 2021 6:12 pm

za909 wrote:
Sun Jan 24, 2021 8:24 am
I personally suggest ignoring the extra byte, or changing every sample to start with a byte of $55 or $AA to completely remove any unwanted change to the DAC level. It's not really worth doing all that padding to work around a barely noticeable artifact like that, but that's just my take on it.
Starting with $55 is the least noticeable way to do this compromise. A lot of games just assumed it was an even multiple of 16 and have a noticeable blip of noise at the end of all their samples. Even $55 has an audible and distinct tone to it, very much not silent, but definitely the least offending thing to use as fill. ($00 or $FF are similarly appropriate as a fill compromise, but they also end up displacing the counter.)

Personally I think the 15 bytes of padding is worthwhile to eliminate the whole problem, especially in a very musically-focused application, but it depends on how much that space matters to you, and the nature of the samples you're using. Given that most DPCM samples are a few hundred bytes anyway, an extra 15 might not be a terribly significant collateral.

User avatar
za909
Posts: 226
Joined: Fri Jan 24, 2014 9:05 am
Location: Hungary

Re: Question about DMC channel sample size

Post by za909 » Thu Feb 11, 2021 4:41 pm

rainwarrior wrote:
Wed Feb 10, 2021 6:12 pm
Starting with $55 is the least noticeable way to do this compromise. A lot of games just assumed it was an even multiple of 16 and have a noticeable blip of noise at the end of all their samples. Even $55 has an audible and distinct tone to it, very much not silent, but definitely the least offending thing to use as fill. ($00 or $FF are similarly appropriate as a fill compromise, but they also end up displacing the counter.)

Personally I think the 15 bytes of padding is worthwhile to eliminate the whole problem, especially in a very musically-focused application, but it depends on how much that space matters to you, and the nature of the samples you're using. Given that most DPCM samples are a few hundred bytes anyway, an extra 15 might not be a terribly significant collateral.
Just to clarify, as I've only implied this, but in my mind these samples are contiguous and exist as a "block" in the ROM without extra padding at all (always a multiple of 4 used in the length register except for the last sample in the "block" where it doesn't matter). So every sample bleeds one byte into the next sample, but if that next sample starts with $55 the effect should be negligible.

Post Reply