This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

assertion of 6502 READY signal during DMC DMA cycles

assertion of 6502 READY signal during DMC DMA cycles
by on (#93392)
Hi,

According to the wiki, DMC DMA cycles are suggested to be 4 CPU clocks long (or less), with the first 3 clocks being just re-reads of the presently executing CPU clock (due to possible interrupt stack writing behavior which cannot be stopped on the 2A03's 6502), and then the last clock being the actual DMC DMA byte fetch.

The wiki also mentions how this DMA operation will cause false reads on hardware streaming ports such as $4016/7, $2007, and even $2002 on a coincidental execute of a 6502 opcode that makes a load from those addresses, during a DMC DMA fetch.

I've always noticed how many games would stop all game animation just to play back some DMC samples (RARE games in particular), but noticed that apparently Nintendo and especially Konami games never suffered the drawback of the DMC DMA unit's side effects on say the reading of the controller ports (i.e., $4016).

How did Konami master the use and/or timing of the DMC unit, so as to not cause any disturbance on reads from the controller ports (there's a ton of samples played during in-game action)? Did they tie their DMC sample init code in tightly with the controller reading? And if so, how did they avoid a coincidental DMA fetch for a sample lasting over several frames with $4016/7 reads? Or, did they use very specific DMA frequencies that would somehow work across multiple video frames? Were they just lucky, or just really good NES programmers (I tend to believe the latter)?

Just curious is all, as it seems the DMC was too much of a headache for many commercial developers to bother trying to use for their games (I can understand why ;)

by on (#93393)
Games like Battletoads did not play DMC samples. It played streaming PCM by using timed code. When using timed code to play PCM samples, you can't generally run game code at the same time, but Ultimate Stuntman tried to pull it off.
The reason Battletoads didn't use DMC is the mapper it uses. 32k bankswitching with no fixed bank. You'd need to duplicate the samples into all ROM banks used during gameplay. (It's also possible to use DMC instead of streaming PCM, if you freeze the game so there's no chance of the wrong bank being mapped in when the samples are fetched, but why bother.)

DMC really isn't that much of a headache.
Read the joystick twice. If they match, great! If not, read it one more time and use that.
That's the solution to the joystick problem.

For Video RAM reading, it's a minor headache. You'd need to disable DMC during times where you read from video memory. Usually you'd do this to load data out of CHR-ROM, or read back map attribute data for scrolling code. If you use DMC, you can't read back attribute data reliably. So just don't do it.

For PPU status reads, it's really not much of a problem. You don't often care about the VBL flag, since it goes away after one read anyway. Multiple reads won't change anything else, so sprite 0 hits aren't affected.

by on (#93394)
Ah, I see. Thanks for the clarification on Battletoads use of direct PCM writing (no wonder those samples sounded pretty good!).

Reading the controllers twice is a pretty nice idea to avoid the DMA bug; I can see now that this wouldn't be the most obvious thing for coders to do, while trying to program the seemingly innocent DMC DMA sample playback hardware back in the 80's.