Is it possible to mix DMC samples in software?
Moderator: Moderators
Is it possible to mix DMC samples in software?
I'm not sure if there are mappers that can map CHR-RAM to ROM area, but I was wondering if there is a way to mix two DMC samples in software an put the result in CHR-RAM in area where the DMC channel can play it? If there is a way, I don't think simply adding the samples together would work, which is how regular PCM signals are added together.
Avatar is pixel art of Noah Prime from Astral Chain
Re: Is it possible to mix DMC samples in software?
CHR-RAM no (DMC can't read from CHR area), but PRG-RAM yes, for example MMC5 and the FDS. It would be rather simple to have your own simpler mapper that can map RAM to DMC-readable area $8000-$FFFF.
The problem is that DMC is very limited in the way that a "1" bit mean go up, and a "0" bit means go down. In order to mix 2 signals together, you'd have to average them somehow using multiple bits from both inputs. The first idea that comes to my mind is take 2 bits from both samples, and count the 1s, then divide the result by 2 and this is the # of 1s that there should be in the 2-bit output. Another approach would be converting to PCM internally, and convert back to DPCM after the merging. No matter what, the result will always be distorted and sound even poorer than the original DMC samples.but I was wondering if there is a way to mix two DMC samples in software an put the result in CHR-RAM in area where the DMC channel can play it?
Considering how much work this is for the CPU I'd consider working with PCM and $4011 instead, since that's also a lot of work for the CPU but at least you could have a better quality output.
No it won't work.If there is a way, I don't think simply adding the samples together would work, which is how regular PCM signals are added together.
Last edited by Bregalad on Fri Dec 25, 2020 8:06 am, edited 1 time in total.
Useless, lumbering half-wits don't scare us.
Re: Is it possible to mix DMC samples in software?
PCM could be mixed.
It would be a very slow process, and in the end you would have only 0.5 - 1 seconds of audio. (for a $2000 byte PRG RAM)
It would be a very slow process, and in the end you would have only 0.5 - 1 seconds of audio. (for a $2000 byte PRG RAM)
nesdoug.com -- blog/tutorial on programming for the NES
Re: Is it possible to mix DMC samples in software?
You can always go full Paprium and embed a 24-channel playback chip on the cart.
Re: Is it possible to mix DMC samples in software?
You could try interleaving the bits from the two DPCM samples (That is the first 2 bits of the mixed sample is the first bit of the sample #1 followed by the first bit of sample #2). With this you'll also need to play the mix at double the speed to compensate for the extended length of the mix.
It sounds half decent but you got to be careful with bit and byte endianness and clipping/over-driving the resulting sound.
It sounds half decent but you got to be careful with bit and byte endianness and clipping/over-driving the resulting sound.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Is it possible to mix DMC samples in software?
Naively converting PCM to DPCM is fairly simple: for each sample, if the current DPCM output level is more than the desired PCM, put a 0, else put a 1. (If you wanted to "mix" DPCM, you'd essentially be doing something equivalent to converting the DPCM to PCM and approximately following the desired output.)
The harder problem is just throughput. At the highest samplerate you have to generate more than 500 samples per frame. The problem here is kinda the same as when just generating PCM. DPCM will take a similar amount of CPU per sample, but the quality will be much, much worse at the same samplerate. 11kHz PCM sounds much better than 33kHz DPCM.
So, the whole advantage of DPCM here isn't so much that you could save CPU, but that you can synchronize differently. If you want to do other stuff alongside PCM you'd usually need an IRQ to drive it, but with the DPCM you could do execution in batches instead. They both have synchronization problems (esp. working around an OAM DMA).
The harder problem is just throughput. At the highest samplerate you have to generate more than 500 samples per frame. The problem here is kinda the same as when just generating PCM. DPCM will take a similar amount of CPU per sample, but the quality will be much, much worse at the same samplerate. 11kHz PCM sounds much better than 33kHz DPCM.
So, the whole advantage of DPCM here isn't so much that you could save CPU, but that you can synchronize differently. If you want to do other stuff alongside PCM you'd usually need an IRQ to drive it, but with the DPCM you could do execution in batches instead. They both have synchronization problems (esp. working around an OAM DMA).