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

[LocalH]

The two sets of grabs I posted each exhibit the glitch on two different lines. The first set seems to be exactly in the middle of the fourth block below sprite 0, and the second set seems to be halfway through the bottom tile of the fifth block below sprite 0. Your grab appears to be within one or two lines of the fourth block below sprite 0.

I can't get a nametable dump right now, I don't even have a suitable emulator handy on my computer and I'm about to head out for the night. If someone else hasn't done it by the time I get back to my computer tomorrow then I'll seek out a suitable emu and do it.

[tepples]

Note: frame numbers may or may not be slightly inaccurate, as I merely threw the .mp4 file into a barebones Avisynth script using DirectShowSource and loaded it into Virtualdub, and I noticed that I didn't seem to seek accurately on my machine when scrubbing backwards then forwards again.

Yeah, DirectShowSource can be a bit inaccurate. You might want to transcode to AVI using FFmpeg or something and then use AVISource. And you might want to deinterlace at some point in the chain to decompose each frame into the two fields that make it up, as the NES program operates on a field basis.

[MARIO CHIP 1]

I neglected to mention in my first post there is actually one other game I have noticed this on, namely Zelda 2 (on FDS)

I haven't tested it as much as SMB, but it seemed similar enough. It only appeared on 1 or 2 startups (out of maybe 10~15 it took me to play through the game) and I think the line only showed in the sidescrolling scenes, not on the world map.

So, SMB1 (cart), SMB2 (FDS), and Zelda 2 (FDS) is the full list of games I've seen it in.
Do these games have anything in common? (Well, Mario 1 and 2 are obvious, but Zelda?)

I am still pretty damn sure it can't appear in all games, as I have played many others on the same system after noticing it in Mario. Like for example Zelda 1, Metroid, and Kid Icarus on the FDS (beat them all), many runs through Mario 3 and Rockman 2, Kirby's Adventure, Punch Out... and lots of others. None showed glitchy lines ever.

I'm also sceptical about bad connection with the cartridge causing this. It was my first hypothesis, but I have cleaned the SMB cart and it works very stable now. I can wiggle it around when the game is running without any problems. Wiggling it also cannot make the glitchiness appear or go away. Neither can resetting by the way. Only a full power cycle can.

[Grapeshot]

Here's some more video I took of this while testing yesterday.

http://www.youtube.com/watch?v=uPbakGFGceY

[LocalH]

Yeah, DirectShowSource can be a bit inaccurate. You might want to transcode to AVI using FFmpeg or something and then use AVISource. And you might want to deinterlace at some point in the chain to decompose each frame into the two fields that make it up, as the NES program operates on a field basis.

I thought about transcoding it but I figured the frame numbers weren't really that important. Also, the .mp4 was only 512x384 from the download link posted and as the video looked to have had the fields decimated prior to upload, there were no interlaced frames to separate (another reason why frame numbers weren't important). Anybody got a 480i capture of the glitch occurring? With the ability to see it happening at full NES resolution and frame rate, we may discover that, for example, the glitch only happens on a tile boundary or something similar. Would probably make it easier to pinpoint exactly where in the nametable the glitch is pulling from, as well.

[MottZilla]

I recall seeing the exact same behavior in Zelda 2 when I was playing it recently. I first wondered if it was a software issue and then later figured maybe it has something to do with the age of the system.

[mikejmoffitt]

I have had this happen on my old NES when I had it, and it happens on my Famicom playing the SMB cart as well. I do not think it has anything to do with cartridge cleanliness / contact.

[TmEE]

I remember seeing it on some famiclones with some pirate carts.

[MARIO CHIP 1]

Now I've seen it in Zelda 1, too.
It's a lot less frequent than in Mario. It only happened on a few horizontal screen transitions in the overworld.

Surely this is related to horizontal scrolling somehow?

[Drag]

I've been seeing this on SMB for the longest time, but I've also seen it in Kid Icarus. On Kid Icarus, I only see it in the horizontally scrolling stages, and it seems to occur more frequently on certain playthroughs, and less frequently on others.

This happens both on my Power Pak and on the actual cartridge. Strangely, I don't recall seeing it on any newer games, just really older generation games. I wonder why?

[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.

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).

[BMF54123]

It's worth noting that I have never seen this glitch occur while playing Vs. Super Mario Bros.--or any other game--on a real Vs. board, but it DOES occur in my MMC1 NES port of the game. Presumably, whatever PPU quirk is causing this was fixed in the RGB PPU (or it's caused by some other component that's different/not present on a Vs. board).

I'm glad this is finally getting some attention. I've wondered about this since I was a kid!

[Drag]

Yeah, whatever it is, it's some kind of flaw within the PPU. I don't think the cart connector or the cartridge has anything to do with it.

It seems that it's only Loopy_V getting corrupt, and not Loopy_T. That's why it's only a single scanline, and not the entire bottom part of the screen.

Does Kid Icarus have some kind of sprite zero detection? Again, I saw this scanline glitch on the horizontal segments of that game too, and I don't believe it uses sprite zero detection for anything.

[tepples]

The only way it would interact with sprite 0 is if the glitch caused the background under sprite 0 to shift such that the intended pixels are not opaque. A timeout would keep the game from freezing in that instance.

[blargg]

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?

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?

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