SMB3 glitch

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
rodri042
Posts: 9
Joined: Wed Mar 06, 2019 11:57 pm

SMB3 glitch

Post by rodri042 »

I need some help to figure out why this glitch happens:
https://imgur.com/a/l92JuIS

Should I debug my scrolling logic? the MMC3 IRQ counter?
Except that weird thing on the menu bar, the game looks fine.
Fiskbit
Posts: 428
Joined: Sat Nov 18, 2017 9:15 pm

Re: SMB3 glitch

Post by Fiskbit »

It looks like you're not supporting mid-screen writes to the PPU's t and v registers, which are done via $2000, $2005, and $2006. Do you have problems in other games that perform mid-screen updates to the scroll position? Does vertical scrolling work properly in Zelda 1, for example?

Another thing is that it looks like SMB3 is using $2006 writes while rendering is off. Whether rendering is on or off, these $2006 writes have the same effect on the internal registers.
User avatar
rainwarrior
Posts: 8211
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: SMB3 glitch

Post by rainwarrior »

Fiskbit linked the wiki article which should give you what you need to implement it properly.

I want to note that SMB3 has a very "messy" IRQ that does some extra writes that aren't necessary. Like right off the bat it will write four 0s to $2006 instead of just 2 for that first "blank" line above the status bar.

After the 4 zeroes, it writes some MMC3 registers for CHR banking does the CHR banking for the status bar, then finally does the two $2006 writes that actually set the scroll for status bard. Then it reads $2007 (!!) which... I don't know if that's to intentionally increment the address or what.

The last thing in the IRQ is two writes to $2005. The second one of these doesn't actually have an effect mid-screen. It writes the "old" scroll value (intended for the top of the screen) here but it actually doesn't matter what value is written because it does not take effect now.

Southbird's disassembly might help follow along: https://github.com/captainsouthbird/smb ... prg031.asm
User avatar
tokumaru
Posts: 12209
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: SMB3 glitch

Post by tokumaru »

It's surprising how oblivious Nintendo's own developers were to these kinds of hardware quirks... Probably means that the official documentation was pretty lacking. And this isn't even an early title for the system.
User avatar
dougeff
Posts: 2932
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: SMB3 glitch

Post by dougeff »

The read from $2007. Is that with rendering on or off? From the wiki...

"Outside of rendering, reads from or writes to $2007 will add either 1 or 32 to v depending on the VRAM increment bit set via $2000. During rendering (on the pre-render line and the visible lines 0-239, provided either background or sprite rendering is enabled), it will update v in an odd way, triggering a coarse X increment and a Y increment simultaneously (with normal wrapping behavior)."

If rendering is ON, then that read from $2007 should shift the bottom part of the screen up 1 pixel. That might have been what was intended.

Edit... after looking at the disassembly, Rendering is off, so I'm not sure this would affect anything, due to 2 writes to $2005 overwriting it anyway (the course X). I wonder, if that read from 2007 was removed, would it look the same?
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
rainwarrior
Posts: 8211
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: SMB3 glitch

Post by rainwarrior »

dougeff wrote: Sun May 08, 2022 5:50 amI wonder, if that read from 2007 was removed, would it look the same?
Replacing it with NOPs in Mesen it seems to look exactly the same.
Fiskbit
Posts: 428
Joined: Sat Nov 18, 2017 9:15 pm

Re: SMB3 glitch

Post by Fiskbit »

The $2007 read won't matter. When the nametable is set at the end of vblank for scrolling, it's set with 1-increment mode. Because rendering is off when $2007 is read, you get a 1-increment, which affects v's x, and v's x gets reloaded at the end of the visible portion of the scanline, so this gets undone.

Zelda 1, on the other hand, does two $2007 reads with rendering enabled, which causes 2 y increments that definitely are seen (though one can be lost if it collides with the standard normal y increment), as well as coarse x increments that only effect the remainder of that scanline.
rodri042
Posts: 9
Joined: Wed Mar 06, 2019 11:57 pm

Re: SMB3 glitch

Post by rodri042 »

Thanks everyone! I started to implement scrolling using v/t and it fixed the issue.
Post Reply