Issues with musical tones via PCM ($4011 writes)

Discuss NSF files, FamiTracker, MML tools, or anything else related to NES music.

Moderator: Moderators

Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Issues with musical tones via PCM ($4011 writes)

Post by Fiskbit »

Sound quality should just be determined by your writes to $4011 - their timing and the values you use. Keeping NMI off and not using sprites shouldn't cause any sound issues.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Issues with musical tones via PCM ($4011 writes)

Post by rainwarrior »

Dacicus wrote: Sun Jan 29, 2023 8:12 am
rainwarrior wrote: Sun Jan 29, 2023 12:05 amYes, it's generally best not to attempt that.
Just to clarify, do you mean attempting the NMI on/off thing?
I meant attempting OAM DMA, which necessitates a pause in the playback that will certainly be as long as several samples.

Using any NMI would also cause a problem, because you probably cannot reliably account for the cycles it consumes, so yes it's a good idea to keep NMI off during playback like this too.

An alternative way to handle this is with sample playback using an in-cart IRQ device, though that has many of its own issues to solve.
Fiskbit wrote: Sun Jan 29, 2023 9:34 amNote that you can still write OAM manually during vblank at a substantial cost, allowing you to sprinkle $4011 writes throughout at the right times, and you can cut down on this cost by limiting how much of OAM you use and accounting for the glitches from updating $2003.
Is there actually a way to account for the problems resulting from $2003? The wiki doesn't describe what it means that writes to it "reliably corrupt" OAM, other than if you manage to write all 256 bytes and leave the final position at 0 it can be eliminated, which isn't really an option here? The issue of OAMADDR > 7 clobbering the first 2 sprites can be worked around, I think, but if the first write "corrupts" something else, what's the workaround for that? Edit: I'm going to take this question to its own thread instead. (The short answer seems to be: don't write $2003 to avoid its corruption, and let the renderer set OAMADDR to 0 for you? Finally, account for sprites 0 and 1 being overwritten.)

I do think that background tile updates via $2007 are somewhat feasible, though, if a little bit tricky to try and time between samples via $2001 polling.
Post Reply