Random glitchy line in Super Mario Bros. on real hardware?

[tepples]

I'm thinking the timing occasionally creates a bus conflict (or some other glitch) when reloading the horizontal scroll bits at x=257. Bus conflicts in NMOS tend to use AND logic, as seen in SAX instruction and discrete logic mappers, which produces a preponderance of zero bits. Games that don't scroll horizontally are already more likely to leave a zero in the horizontal scroll bits.

Can you elaborate? I don't think SMB is rewriting PPU registers mid-frame, or any registers for that matter. Do you mean a conflict in mapper PRG bank switching putting some spikes on the power rails and affecting the PPU?

No, I'm just saying that in NMOS, conflicts tend to cause things to become 0 more often than 1, and you discovered that bank switching is an example of this tendency to become 0. SMB1 doesn't use bank switching at all.

Implication for developers: This could be another reason why games need a timeout on their sprite 0 wait routines. The simplest timeout increases the sprite 0 jitter from 7 cycles (bit/bvc) to 9 (bit/bmi/bvc).

Huh, timeout? You're suggesting that sometimes it doesn't catch sprite hit and this causes the glitch?

No, the other way around. I'm saying the glitch causes it not to catch sprite hit, and games need to be prepared for a failure to catch sprite hit.

BTW, can't you use a bit/beq loop followed by a bmi timed_out to keep 7-cycle latency?

Good point.

[Grapeshot]

Question for anyone who understands Visual 2C02: Would writing to $2000 on one specific cycle (possibly only on one PPU/CPU clock alignment) while the bits in the PPU address are updated cause this?

The last thing Super Mario Bros. does in its NMI routine is write to $2000 to turn the NMI back on. If you mark every write to $2000 by changing the tint bits, you can see that this tends to occur about halfway down the screen (approximately where the glitchy line would be). Zelda does something similar when scrolling horizontally.

[blargg]

Nice, next chance I get I'm going to see if I can continuously trigger this effect. That's got to be it.

[mikejmoffitt]

I managed to consistently trigger it at a spot in 1-2 towards the end. In about a year I can have a video uploaded, given my current connection speed...

Edit: here it is: http://www.youtube.com/watch?v=P6DAWhLz ... e=youtu.be

[tepples]

If Grapeshot's hypothesis turns out true, it reminds me of the bug causing missed frames when spinning on bit 7 of $2002. Then perhaps one way to avoid it is not to write to $2000 except near a scroll split, and instead use some other way to work around NMI-in-NMI. If, as Drag claims, it is less common in later games, that could be three things: later games using SMB3-style horizontal mirroring with horizontal scrolling (and thus a bus conflict on bit 10 of v has no effect), later games doing less processing in the NMI handler as opposed to the SMB1-style "super loop", or just ignoring nested NMIs in software. But if $2000 write conflicts are the cause, sprite 0 spin waits would be less affected.

Statistics would be appreciated for what games turn NMI off and on mid-frame.

[MottZilla]

I believe I noticed this in Zelda 2, perhaps someone wants to check if it's programmed this way as well?

[thefox]

I believe I noticed this in Zelda 2, perhaps someone wants to check if it's programmed this way as well?

Yes it is.

[blargg]

Happens merely writing $01 to $2000 repeatedly in an infinite loop with vertical mirroring. Next to nail down the timing.

EDIT: Seems that a write around pixel 255 is the cause. H/V scroll positions are irrelevant. Only occurs for two of the four CPU-PPU alignments (the two middle ones in the table I posted a while back, one of which is the "preferred" one). Hmmm, and only occurs reliably for preferred alignment (third in table).

Also, only occurs when write is at one particular dot. Not more than one. Clear now why it occurs so rarely in SMB, since you can only even hit this dot on every third scanline.

Maybe someone can probe this with Visual 2C02 now to see what's happening and exactly which dot it occurs on.

[Sik]

If Grapeshot's hypothesis turns out true, it reminds me of the bug causing missed frames when spinning on bit 7 of $2002. Then perhaps one way to avoid it is not to write to $2000 except near a scroll split, and instead use some other way to work around NMI-in-NMI. If, as Drag claims, it is less common in later games, that could be three things: later games using SMB3-style horizontal mirroring with horizontal scrolling (and thus a bus conflict on bit 10 of v has no effect), later games doing less processing in the NMI handler as opposed to the SMB1-style "super loop", or just ignoring nested NMIs in software. But if $2000 write conflicts are the cause, sprite 0 spin waits would be less affected.

Statistics would be appreciated for what games turn NMI off and on mid-frame.

I would expect most games to use NMI to just set a flag and do the actual processing outside the interrupt. That's the usual way to handle vblank timing on most systems, really (though of course that didn't stop many programmers from doing it in other ways). Note that this means the interrupt itself would be most likely less than half a scanline long, it's just write a single value to RAM and then return =P Of course this would also happen in vblank so it would never be visible.

[tepples]

What Sik is referring to is an NMI handler like that used in Concentration Room, Lawn Mower, Thwaite, and Zap Ruder:

Code: Select all

nmi:
  inc nmis
  rti

In before tokumaru points out that doing VRAM updates, the music engine, and the status bar split in the NMI handler makes sure that your music doesn't slow down and your sprite 0 split doesn't have a seizure even if the game slows down.

[tokumaru]

In before tokumaru points out that doing VRAM updates, the music engine, and the status bar split in the NMI handler makes sure that your music doesn't slow down and your sprite 0 split doesn't have a seizure even if the game slows down.

Oh, you know me too well! I almost clicked the "quote" button as soon as I read the first sentence in Sik's post. But Yeah, this does make a huge difference in NES games IMO. It's as simple as this: if you don't interrupt the game logic for crucial PPU/APU updates that are timed from VBlank, things will screw up if there's any lag. The flag method is perfectly fine if you're absolutely sure the game logic will never take longer than a frame to finish (i.e. the entire game has no lag).

[Dwedit]

From looking at the SMB1 screenshot, it appears as if the X nametable bit for scrolling becomes 0, and no other bit of X scrolling is affected at all.

[tokumaru]

So... writing to $2000 mid-frame near the end of the scanline messes up the horizontal scroll for the next scanline, is that it?

[rainwarrior]

I'm with tokumaru w.r.t. what to put in your NMI.

[blargg]

So... writing to $2000 mid-frame near the end of the scanline messes up the horizontal scroll for the next scanline, is that it?

Yes, if you're not using horizontal mirroring and are writing an odd value (bit 0 set) to $2000.