nesdev.org

I was just reading the page at http://nesdevwiki.ath.cx/index.php/PPU_Frame_Timing

And I'm now wondering: Is the CPU-PPU alignment problem the reason why Super Mario Bros screws up the demo all the time? Or is some other feature of the NES causing it?

You mean the one where it appears to have two slightly different demos, one where Mario dies and one where he stays big?

In the NTSC version, one version has him end up next to a pipe, while the other one kills him. Both times he successfully collects the mushroom.

In the PAL version of SMB1, the demo always results in Mario dying. Both times, he fails to hit the [?] block to release the mushroom. This is because the physics were altered for the PAL version, but the demo sequence was unchanged.

Could this also be the reason why fireballs don't always end up in the same place even though initiated at the same spot?

Like sometimes you aim really close to an edge of a brick, and it goes over the edge, and other times it hits the edge.

No, from what I understand CPU-PPU alignment only affects things when you are trying to play with the PPU registers when the screen is drawing.

I don't think most games allow their virtual worlds to be affected by PPU timing; PPU timing only affects what appears on screen. Yes, it might affect the time of a controller read, thus indirectly affecting the game world, but what else could affect it?

There is a three-frame delay on the "second" demo that isn't present on the "first" demo. This is caused by the interval timer continuing to run between the two demos. When Mario touches the goomba and dies on the "second" demo, the master timer control freezes all timers (including interval timer control), then the game clears the screen and continues the timers once again.

This three-frame discrepency also affects the frame counter at $09, which is not affected by the master timer control, but is also reset everytime the game goes back to the title screen (unlike interval timer control which only gets reset on power-up). The frame counter is responsible for controlling the timing of several subroutines, and since the player-to-enemy collision detection handler only executes once every other frame (specifically on even frames) it will execute one frame later on the "second" demo than it is supposed to, causing the different outcomes.

Anyway, long story short, the misalignment is caused by the game, not the hardware. This is as sound an explanation as I can come up with for now.

You think Nintendo did it intentionally?

No, I don't think the original programmer(s) intended for there to be two outcomes from one set of demo data. On the other hand they probably also decided it wasn't worth the trouble of fixing to break deadline.

The most likely reason in any game for the demo to screw up is that it was recorded before the game was finished, and there were some slight changes to the game's mechanics after the recording.

In Nintendo's developer manual for the SNES, they explicitly warn about demo code and to verify that the demo works as expected before final submission. I'll bet they based that warning on their own developing experience.