nesdev.org

I'm messing around with Nintendulator for the first time (via VMware), along with Donkey Kong and its disassembly (from romhacking.net).

A fairly simple behavior is puzzling me: when you pause DK, it waits a few frames and then disables the sprites onscreen. I say 'disabled' with some certainty - according to Nintendulator, the sprites' y-coordinates have not been changed to #FF, so they're still in place, just 'invisible.' My assumption was that sprites were disabled via $2001, but I can't figure out exactly where in the source this happens.

I've found three $2001 references:

1. In the NMI handler, after a controller read. This would be my top candidate:
2. In a routine that disables the BG:
3. In the initial PPU setup:
First, am I correct that excerpt one is disabling the sprites on pause? If so, why only the sprites and not the BG? I assume it's contingent upon what's currently loaded in variable $11 (PPU control 2 copy). And finally, why include this behavior? Is it to prevent players from 'planning ahead' while the game is paused? Does arcade DK behave this way? I assume there's no pause on the arcade game...

Quick look in RAM viewer reveals that the sprite table isn't changed at all while pausing the game.
So it uses 2001 to mask out the sprites.

Dwedit wrote:Quick look in RAM viewer reveals that the sprite table isn't changed at all while pausing the game.
So it uses 2001 to mask out the sprites.

I also set a breakpoint on the sprite rendering bit in $2001 being set to 0 and find it is indeed set to 0 on a pause.

Thanks for the confirmation. Any clue on where this mask happens? During NMI?

It probably hides the sprites as an indication the game has been paused. It does so after so many frames because first it plays the "game pause jingle" sound effect or music jingle. It may be to stop you from planning your very next move but I doubt that was really the intention. I really think it's just to indicate the game is paused in a very simple and effective way.

MottZilla wrote:It probably hides the sprites as an indication the game has been paused. It does so after so many frames because first it plays the "game pause jingle" sound effect or music jingle. It may be to stop you from planning your very next move but I doubt that was really the intention. I really think it's just to indicate the game is paused in a very simple and effective way.

Good point. Usually the simpler explanation is the best. I was just leaning more toward the 'prevent planning' angle since the programmers didn't just create a pause overlay, similar to the 'Game Over' screen.

noattack wrote:

MottZilla wrote:It probably hides the sprites as an indication the game has been paused. It does so after so many frames because first it plays the "game pause jingle" sound effect or music jingle. It may be to stop you from planning your very next move but I doubt that was really the intention. I really think it's just to indicate the game is paused in a very simple and effective way.

Good point. Usually the simpler explanation is the best. I was just leaning more toward the 'prevent planning' angle since the programmers didn't just create a pause overlay, similar to the 'Game Over' screen.

My original guess before running the game to try anything was that they turned sprites off to clear the area where "PAUSED" would be printed on the screen so that you could see that it was paused. But, there's no such indication given. Then I thought perhaps it was done to reduce burn-in on the CRT. The moveable objects, if left on screen for a long time during an extended pause, would be more noticeably burned-in than the background. But then, I don't know the history of DK and whether or not the NES version was a direct arcade port.

cpow wrote: Then I thought perhaps it was done to reduce burn-in on the CRT. The moveable objects, if left on screen for a long time during an extended pause, would be more noticeably burned-in than the background.

Interesting idea. Why are sprites more prone to burn vs. BG tiles?

Not sure about the port process. Apparently DK wasn't coded in-house so Nintendo had to reverse engineer the arcade version to code their follow-up, DK Jr. Perhaps they had to do the same to port to the Famicom?

noattack wrote:Interesting idea. Why are sprites more prone to burn vs. BG tiles?

Brighter. I don't have a copy of Donkey Kong in front of me to confirm, but I know older games tended to have black backdrops, and I seem to remember things in the background had more dark ($0x) and medium ($1x) colors, reserving bright ($2x) and light ($3x) colors for sprites. (As for grays, $00 is about the same as $1x, and $10 is about the same as $2x.)

It's also possible that when the game pauese its just spinning in a loop waiting for you to press the button to unpause it. Therefore, never writing to $4014 and if that happens the sprites disappear off the screen even though the sprites are not disabled from $2001. The OAM data will disintegrate after a few frames if not updated frequently updated. (I believe Ice climbers does the same thing.) To prove this, you could try a breakpoint at $4014, if its not being written to while paused.

lazigamer wrote:It's also possible that when the game pauese its just spinning in a loop waiting for you to press the button to unpause it. Therefore, never writing to $4014 and if that happens the sprites disappear off the screen even though the sprites are not disabled from $2001. The OAM data will disintegrate after a few frames if not updated frequently updated. (I believe Ice climbers does the same thing.) To prove this, you could try a breakpoint at $4014, if its not being written to while paused.

Donkey Kong writes to $4014 during pause.

lazigamer wrote:Therefore, never writing to $4014 and if that happens the sprites disappear off the screen even though the sprites are not disabled from $2001.

This is not true.

The OAM data will disintegrate after a few frames if not updated frequently updated.

OAM only disintegrates when rendering is disabled. I'm not sure if that happens if only sprites are disabled (this is irrelevant though, since your theory is that they are not disabled at all). If rendering is not disabled, the PPU reading from the OAM is enough to keep that memory "alive", DMA's are not required for that. Also, if the OAM was fading, the sprites wouldn't simply disappear, they would glitch up.

Hello everyone,

I am the one that disassembled partially the DK rom and uploaded it to romhacking. Nice to see that someone thought it would be interesting. Just dropping by to send some regards and to humbly announce that, after a hiatus of a year, I retook the disassembly project for a while. I have a new version which I will be uploading soon.

Great to hear. Definitely post here when you have a new version uploaded. I'd be interested in taking a look.

I have just uploaded it yesterday. If you have any corrections, suggestions or want to contribute, feel free.