FDS unable to utilize the DPCM channel?
Moderator: Moderators
FDS unable to utilize the DPCM channel?
Playing several FDS games over the years, I couldn't help but notice that none of them use the DPCM channel for drums or samples. A lot of FDS-to-NES ports would end up using it. It got me wondering, could disk loaded games utilize the channel at all? If so, which game(s) use(d) it? I think it's some limitation imposed by DPCM's expectation of the quick connection between system and cart to load samples from, but that's just a guess. This is a question not often or explicitly asked on the internet, I see, so here it is.
Re: FDS unable to utilize the DPCM channel?
That is a very interesting observation. I have never noticed this. I don't think that it could be a memory speed issue because memory accesses are the same speed whether running code or fetching DPCM samples.
DPCM has a bug where it can cause multiple reads. This causes the well-known issue reading the controllers. The extra read causes a bit to be lost from the controller. I am wondering if there are any FDS registers that have an effect just by reading them, and if the multiple read could cause a problem there as well. According to the wiki, the FDS's IRQ can be acknowledged by reading $4030. I am not seeing how a double-acknowledge would typically be a problem though. Maybe there is something else that is affected just by reading?
Also to consider is that the FDS has its own built-in ROM. It is possible that there is some aspect of the ROM that wasn't designed with multiple reads in mind.
DPCM has a bug where it can cause multiple reads. This causes the well-known issue reading the controllers. The extra read causes a bit to be lost from the controller. I am wondering if there are any FDS registers that have an effect just by reading them, and if the multiple read could cause a problem there as well. According to the wiki, the FDS's IRQ can be acknowledged by reading $4030. I am not seeing how a double-acknowledge would typically be a problem though. Maybe there is something else that is affected just by reading?
Also to consider is that the FDS has its own built-in ROM. It is possible that there is some aspect of the ROM that wasn't designed with multiple reads in mind.
Re: FDS unable to utilize the DPCM channel?
I remembered the table tennis FDS game had speeches, don't know whether it was utilising the DPCM channel, and it's not used for percussion in music (I think).
Another problem is since you cannot bankswitch ROM data into PRG area(unless you can stand LOADING... from disk every few seconds) if you try to use most of the RAM at $C000 - DFFF for DPCM samples that will further reduce the amount of work RAM for holding game programme, map data and the like (that the FDS Bios occupying $E000 - $FFFF, reducing the available space for DPCM samples to half doesn't help either).
Another problem is since you cannot bankswitch ROM data into PRG area(unless you can stand LOADING... from disk every few seconds) if you try to use most of the RAM at $C000 - DFFF for DPCM samples that will further reduce the amount of work RAM for holding game programme, map data and the like (that the FDS Bios occupying $E000 - $FFFF, reducing the available space for DPCM samples to half doesn't help either).
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: FDS unable to utilize the DPCM channel?
I don't believe there's any hardware conflict that prevents DPCM when using the FDS?
I think Gilbert's answer is probably the strongest factor. DPCM samples are huge, and without bankswitching they take up a lot of space you could be using for other things.
For the same reason I think you'll hardly ever see DPCM in NROM cartridge games. You see a lot more DPCM use with MMC3 games which could bankswitch the sample area.
Incidentally, SMB2 replaced/simulated a lot of the FDS sound effects of the original game with DPCM... and it uses MMC3.
I think Gilbert's answer is probably the strongest factor. DPCM samples are huge, and without bankswitching they take up a lot of space you could be using for other things.
For the same reason I think you'll hardly ever see DPCM in NROM cartridge games. You see a lot more DPCM use with MMC3 games which could bankswitch the sample area.
Incidentally, SMB2 replaced/simulated a lot of the FDS sound effects of the original game with DPCM... and it uses MMC3.
Re: FDS unable to utilize the DPCM channel?
Thanks for the insight. So it sounds like more of a logical choice given the RAM/ROM data limitations on the FDS than something it was incapable of. Especially as there are FDS games that use it, they just seem smaller in scope or don't require a lot of graphical data alongside usage of the samples. Another such example seems to be Doremikko. PCM drums seem to be present in the Gradius tune.
- Jarhmander
- Formerly ~J-@D!~
- Posts: 569
- Joined: Sun Mar 12, 2006 12:36 am
- Location: Rive nord de Montréal
Re: FDS unable to utilize the DPCM channel?
Couldn't it be that some of the BIOS routines are timing sensitive and would be thrown off by "unpredictable" DPCM DMA fetches?
((λ (x) (x x)) (λ (x) (x x)))
Re: FDS unable to utilize the DPCM channel?
Maybe while reading a disk, that’s an interesting thought.
You know how Super Mario Bros 1 does the DMC thing between levels to change to volume of the triangle channel? Does the FDS version do this? I think that would count. How about Super Mario Bros 2 (FDS)?
You know how Super Mario Bros 1 does the DMC thing between levels to change to volume of the triangle channel? Does the FDS version do this? I think that would count. How about Super Mario Bros 2 (FDS)?
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: FDS unable to utilize the DPCM channel?
FDS games don't tend to use the BIOS very often (if at all, after startup). Mostly just for loading from disk.Jarhmander wrote: ↑Tue May 17, 2022 8:25 pm Couldn't it be that some of the BIOS routines are timing sensitive and would be thrown off by "unpredictable" DPCM DMA fetches?
The disk interface is interrupt driven and I don't believe it relies on precise cycle timing. The DPCM fetch delays shouldn't be enough to throw it off.
Similarly, we don't have a read-clocked shift or increment, like happens with $4016 or $2007, so I'm not sure if the read conflict problem would matter either?
Because of the IRQ needs, we can't do NMI during disk load, so the idea of doing DPCM at the same time is sort of moot? Music and sound isn't really an option while loading from disk anyway.
Those games do this, but $4011 writes don't have any known conflicts. It's only the DPCM playback that causes an issue via its sample fetch. Just setting the DAC's output level doesn't have side effects like that.
Re: FDS unable to utilize the DPCM channel?
I've recently been examining and building ROM hacks for the FDS game Family Composer. It uses DPCM samples, but they're very short blips (49 bytes) that aren't very interesting. In Mesen, I used the APU viewer to mute all sound channels except DMC, and used the Memory Tools color coding to watch when the following ranges are accessed:
DF00: is 49 zero bytes, but when it's accessed it sounds like various low-pitched blips. (For example when REGGAE is selected, this range is repeatedly accessed, but sounds two different blip types.) I haven't checked the exact code used, but maybe it directly loads the DMC channel with some starting value before playing the sample?
DF40: is 48 bytes of F0 0F pattern and 1 byte of zero. Sounds like a high-pitched blip.
DF80: is another 49 zero bytes, but it sounds silent in Mesen, at least when all channels except DMC are muted. When everything is unmuted, I can't hear any obvious audible side-effect on any of the other channels, but I didn't investigate deeply.
Also of possible interest: The area of memory the DMC samples are in is loaded from a file called SNDEDT. I wonder if that might be a common filename used for loading DMC samples?
I'm not sure how typical it is, but I've noticed Family Composer uses BIOS routines to load pattern tables and nametables. (For example, to update the BAR number display.)rainwarrior wrote: ↑Tue May 17, 2022 10:32 pmFDS games don't tend to use the BIOS very often (if at all, after startup). Mostly just for loading from disk.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: FDS unable to utilize the DPCM channel?
A few FDS games that use DPCM:
- Apple Town Story: Little Computer People
- Exciting Soccer
- Final Command: Akai Yousai
- Doremikko
- Gyruss
- Sexy Invaders
- Apple Town Story: Little Computer People
- Exciting Soccer
- Final Command: Akai Yousai
- Doremikko
- Gyruss
- Sexy Invaders
Re: FDS unable to utilize the DPCM channel?
The hardware conflicts would just mean stopping all samples before loading from the disk.
It's basically just storage size limits that stops games from using the DPCM channel.
Usually the entire game program (including the music engine and all music) is loaded from Side A when the game boots up. Then the game loads graphics and level data as needed from Side B. Overlays for code are not common.
But because the entire game program and music engine are all loaded from Side A, you want to have it use less memory.
It's basically just storage size limits that stops games from using the DPCM channel.
Usually the entire game program (including the music engine and all music) is loaded from Side A when the game boots up. Then the game loads graphics and level data as needed from Side B. Overlays for code are not common.
But because the entire game program and music engine are all loaded from Side A, you want to have it use less memory.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: FDS unable to utilize the DPCM channel?
The FDS even has DMC-fortified controller-reading BIOS calls as well as non-fortified versions.