Wow this got crazy ! I haven't looked back here for a little bit now. Sorry to spark such a heated debate!

You know since I'm not a programmer or started down that road yet I will be simply getting a retrogen to play my old faves ...

Thanks for the quick run down Aaendi and I will revisit this if I decide to give it a go. Thanks everyone for your input

Why haven't I heard that rumor before?  I've heard a lot of rumors about CPU speed and slowdowns, but not that one.  There is a hair of truth in it, because from my experience, in order for it to automatically slowdown when needed, you have to keep the NMI interrupt disabled, until the end of the main routine.  If the NMI is kept enabled throughout the frame, the NMI will cut the CPU off in the middle of the main routine, causing glitches and possibly even a crash.

EDIT: Accidentally got NMI and IRQ mixed up.  Fixed.

Isn't the sprite flicker just a result of the 8 sprite/scanline limit? So they interleave the sprites every other frame to display more at a time? I'm not a expert.

Yes.  Some people just like to blame everything on the CPU.

Aaendi, no that is incorrect. There isn't a hair of truth in it at all. What happens when the game slows down, if I didn't already explain this.

The game is running fine but for some reason new objects are now on the screen and it's going to take more time for the CPU to calculate everything that is happening. So what happens that you should understand is this. The CPU and PPU (graphics chip) are separate. The PPU will run even if the CPU weren't running. The PPU runs constantly in a loop drawing scanlines. When the PPU is drawing scanlines, the CPU cannot access VRAM, meaning it cannot alter what appears on the screen (tiny exceptions exist). So the system has an interrupt called NMI. This happens every time the PPU finishing drawing the frame. At this point there is a very small window called Vertical Blank. During this time the VRAM and scrolling and other parameters can be updated. So what happens is the CPU is not yet done calculating everything so when the NMI happens, it checks to see "do I have a frame update ready?" and it will see that no, the main thread has not yet completed its calculations. So what happens? It has no video update and lets the main thread continue. The result is for this frame, we had no update so the game appears to slow down. Some of this language or details are not exact but this is the premise to make it easier to understand.

So, when the CPU load is light, every time the PPU is done drawing the CPU gets to update the video frame. However when the CPU load is too heavy, the CPU doesn't have a frame update ready in time when the PPU is done drawing and this frame is lost so the same frame is displayed again which in motion looks like slowdown.

Pegboy, your theory is correct. Without the program doing anything to compensate the result would be sprites after the 8th being invisible. But the games are programmed to prevent this usually, which results in as you say, they change each frame which sprites get drawn and the result is flickering when there are more than 8 sprites on a line.

This is what I was trying to explain, except you can also let the game slowdown by disabling the NMI interrupt at the beginning of main code, and enabling NMI at the end, so that the CPU doesn't get interrupt.  I just mistakenly called NMI "IRQ" in my last post.

Yes, games that tend to run entirely in NMI (SMB1 is among them I believe) are like that. Either way it's pretty much the same deal, the CPU needs more time to be ready for the video update so the result is a slowdown in the framerate as far as new frames go.

When you say games that run entirely in NMI, do you mean during v-blank period, or do you mean games that don't "return from interupt" with the main code written directly after vblank code. That's the way Busty Baby Blows Bots does it. It never returns from an NMI interupt, because the v-blank code and main code are in the same loop, eventhough the main code lasts much longer than v-blank period.