Today, I noticed something with "Super Mario Bros.": When I played it, horizontal lines appeared on the screen sometimes.
Unfortunately, when I got my camera from the cellar, the issues didn't appear anymore, so I have to simulate it with an emulator screenshot.
If I remember correctly, it looked similar to this:
Sometimes it appears in black, sometimes in white and here it appeared in green.
It's definitely not an interference from the video cable or from the TV itself since this only happens with SMB and no other game. But it doesn't happen whenever I have the cartridge in the console. Although I remember that the same thing happened two years ago as well, so it's not a new phenomenon.
My question is: Is this some software-related glitch that happens on all cartridges since it's part of the code? Or is it an issue that happens due to faulty or dirty contacts?
It's a bug in the game (or a bug in the hardware, depending on your point of view).
Thread discussing it:
http://forums.nesdev.com/viewtopic.php?f=2&t=10104Basically if you write to $2000 mid-screen there's a chance it'll mess up the scroll for that line. Super Mario Bros. tries to turn off the NMI flag to prevent re-entrant NMI (e.g. if there are too many creatures onscreen and there is slowdown) but when it's done and turns it back on, sometimes the timing conflicts perfectly with a rendering operation that causes this glitch.
Thanks. So, that means nothing is wrong with my cartridge and I don't have to buy a new one..
This bug doesn't exist on PAL systems nor on VS System PPUs I heard. I had never seen it before I got my Famicom.
rainwarrior wrote:
It's a bug in the game (or a bug in the hardware, depending on your point of view).
Thread discussing it:
http://forums.nesdev.com/viewtopic.php?f=2&t=10104Basically if you write to $2000 mid-screen there's a chance it'll mess up the scroll for that line. Super Mario Bros. tries to turn off the NMI flag to prevent re-entrant NMI (e.g. if there are too many creatures onscreen and there is slowdown) but when it's done and turns it back on, sometimes the timing conflicts perfectly with a rendering operation that causes this glitch.
This was my first thought, except for the fact the glitch line is
green. Unless it turns out DRW got confused and it was just the same color as the bricks, that is.
Sik wrote:
rainwarrior wrote:
It's a bug in the game (or a bug in the hardware, depending on your point of view).
Thread discussing it:
http://forums.nesdev.com/viewtopic.php?f=2&t=10104Basically if you write to $2000 mid-screen there's a chance it'll mess up the scroll for that line. Super Mario Bros. tries to turn off the NMI flag to prevent re-entrant NMI (e.g. if there are too many creatures onscreen and there is slowdown) but when it's done and turns it back on, sometimes the timing conflicts perfectly with a rendering operation that causes this glitch.
This was my first thought, except for the fact the glitch line is
green. Unless it turns out DRW got confused and it was just the same color as the bricks, that is.
It was probably at a different place, where there were pipes on-screen.
Oh right, I forgot about the pipes =S (could have been the pipes that lead to the bonus stage)
Arkanoid seems to suffer from the same problem.
I remember seeing it happen in Zelda 2, in the side-scrolling areas.
Also, kevtris found a spot in Rygar where this glitch seems to be reproducible. I'm pretty sure it was this same glitch. It's in the second area, immediately after the sunset area. There's a tree with a door on the left branch, and a rope on the right. Climbing near the top of that rope caused it to happen. Just going by memory, hope I'm remembering right.
Rygar also has this problem. I discovered it on the HDMI adapter work. If you go up the first rope you come to, go across 1 screen then down the 2nd rope and just hang on the rope, one of the scanlines of the tree trunk will wiggle occasionally. After seeing it there, I saw it easily on SMB and several other games, too.
At first I thought it was the adapter but turns out it is in the PPU. Also, the EXT pins will glitch sometimes when 2000 is written to also, which causes the pixels to "sparkle" because they seem to glitch a little bit (saw this on the logic analyzer).
I had to add a facility to control which PPU/CPU alignment is in use to kill the sparkling. Interestingly it does not stop the scanline wiggling though. The "Desparkle" setting is really a CPU/PPU alignment selector. It actively changes the alignment during operation by dropping PPU clock(s) occasionally to force one of the alignments.
thefox wrote:
Arkanoid seems to suffer from the same problem.
That game has horizontal mirroring and shouldn't have that problem at all.
Dwedit wrote:
thefox wrote:
Arkanoid seems to suffer from the same problem.
That game has horizontal mirroring and shouldn't have that problem at all.
Yeah that's why I was a little bit surprised to see it, but I wasn't sure whether I should trust the thread's assessment that the problem doesn't happen with horizontal mirroring.
You can draw your own conclusions from this Twitch stream capture:
http://www.twitch.tv/themexicanrunner/v/8625249 (requires Flash). You can see the glitch at around 10:55 mark, then again at around 11:06 (these are not the only places, just what I could find quickly right now). Based on an emulator breakpoint the game typically writes to $2000 around scanlines 40-60 (depends on game load and can vary by more than that), which matches up with where the glitch shows up in the video.
Dwedit wrote:
That game has horizontal mirroring and shouldn't have that problem at all.
...and we're back to trying to figure this out!
Another one to the list of games where this happens: Rambo (vertical mirroring)
Has anyone tested different PPUs to see if perhaps this was fixed in a later revision? I recently restored and NESRGB-modded another NES, and I started noticing this a lot on that console while playing SMB1 yesterday. On my other NESRGB-modded NES, I never really noticed this. Maybe I just got lucky and that NES didn't boot in that CPU-PPU alignment much when I played SMB1.
EDIT: Well, I just tried the glitch test rom on both consoles, and I get the glitch on both. But still, I wonder if this happens on all PPU revisions.
One time I was playing SMB3 on a cartridge, in level 2-1, and a wand fell out of the sky, spinning. It hit the ground and bounced off as usual. I picked it up and the game crashed. True story.
Is this a common hardware glitch? j/k
I'd imagine something like that would just be a bug in the game triggered by some random series of events and wouldn't have to do with hardware.
Kind of like this:
https://www.youtube.com/watch?v=0TWQr0_fi80 Look what happens around 2:00...
darryl.revok wrote:
j/k
I'm not sure what the glitch was in the DKC video. I guess I'm not familiar enough with that game to recognize it.
My buddy swears that his son jumped out of the lava in SMB1 once. He says he would believe it if he hadn't have seen it. I don't think I've seen that glitch in a speedrun video before.
If anything, it was probably SMB1's wall jump glitch. If you hit the wall at the right angle, you have one frame where your foot is inside the wall and you can jump again. And lava in SMB1 is just a decorated pit, so a wall jump makes sense.
In Super Mario 64, the timing window for wall jumping was widened intentionally, and it was given its own animation and a few Stars that require it.
tepples wrote:
In Super Mario 64, the timing window for wall jumping was widened intentionally, and it was given its own animation and a few Stars that require it.
That's pretty misleading. In Super Mario Bros, it is nothing but a bug where Mario is stuck "inside" the wall briefly and as a result is considered grounded, primed for a jump. In Super Mario 64, the implementation, appearance, usage technique, and applications are all different...
mikejmoffitt wrote:
tepples wrote:
In Super Mario 64, the timing window for wall jumping was widened intentionally, and it was given its own animation and a few Stars that require it.
That's pretty misleading. In Super Mario Bros, it is nothing but a bug where Mario is stuck "inside" the wall briefly and as a result is considered grounded, primed for a jump. In Super Mario 64, the implementation, appearance, usage technique, and applications are all different...
That's sort of what I meant:
"appearance" => '"its own animation"
"applications" => "a few Stars that require it"
darryl.revok wrote:
I'm not sure what the glitch was in the DKC video. I guess I'm not familiar enough with that game to recognize it.
He essentially warped from world 3 to world 6 after walking through that secret area by doing a random sequence of events beforehand. He broke the wall just as if he where using a barrel with Espresso, which isn't supposed to be possible.
thefox wrote:
Dwedit wrote:
thefox wrote:
Arkanoid seems to suffer from the same problem.
That game has horizontal mirroring and shouldn't have that problem at all.
Yeah that's why I was a little bit surprised to see it, but I wasn't sure whether I should trust the thread's assessment that the problem doesn't happen with horizontal mirroring.
I think I figured this one out. The game is writing zeroes to
$2005 during rendering. (Happens at around scanline ~50 during rendering, but varies.) While this would normally be fine, when the writes fall on the magic dot, it ends up corrupting
v.
Here's the post that inspired me to check it out:
viewtopic.php?p=114350#p114350