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

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

User avatar
ulfalizer
Posts: 349
Joined: Fri Mar 08, 2013 9:55 pm
Location: Linköping, Sweden

Re: Random glitchy line in Super Mario Bros. on real hardwar

Post by ulfalizer »

Some of the latches for the $2000/$2001 flag bits have a transistor on their outputs to prevent the value from being read while the bit is being written (though the old value will probably still be read during the write due to capacitance on the output wire). Looks like e.g. the monochrome bit and the blue emphasis bit doesn't have such transistors though (or doesn't use them at least, you get a cut-off wire on the other side).

Here's an experiment that would be interesting to try: Set either the monochrome bit or the blue emphasis bit to 1 in a loop during rendering. If that produces colored/un-emphasized spots on the screen, then it's a problem with reading the value at the wrong time while it is being written.
User avatar
BMF54123
Posts: 410
Joined: Mon Aug 28, 2006 2:52 am
Contact:

Re: Random glitchy line in Super Mario Bros. on real hardwar

Post by BMF54123 »

Bit of a bump, but I seem to have fixed this problem in my NES port of Vs. Super Mario Bros. All I had to do was modify the game so that it never disables NMI, but uses a flag in RAM instead (as most newer games seem to do):

- When NMI hits, check this flag; if it is clear, proceed with the usual NMI routine, otherwise RTI
- Flag is set at beginning of NMI routine (main game loop) and cleared at the end

Voila, no more glitchy line. Of course, this doesn't fix the status bar flickering when the game slows down, since that would be a somewhat more involved hack, and difficult to do without a disassembly of the Vs. version (and I didn't really want to alter the game's normal behavior anyway, for accuracy's sake).
User avatar
rainwarrior
Posts: 8735
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Random glitchy line in Super Mario Bros. on real hardwar

Post by rainwarrior »

Yes, I agree that is a safe/easy/simple way to prevent re-entrant NMI. It's what I now do in my own projects.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

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

Post by Dwedit »

It's still unclear exactly what the timing is for the glitch, and what the actual behavior is.
It seems to happen when "T" is changed for any reason, such as $2000 writes, or scrolling/VRAM address register writes.
It seems to affect the value that is written to "V" without affecting the value of "T".

Which dot does the write to "T" need to happen at? Is it 255, 256, or 257? I'm seeing Dot 255 mentioned in the thread, Dot 256 is the Vertical Increment of "V", and Dot 257 is when horizontal bits of "T" are copied to "V".
Is there any effect besides setting the horizontal nametable bit to 0?
Does the glitch also happen with vertical scrolling if you wrote to "T" at a precise time? (Around Dot 304 of prerender line) Would it set the vertical nametable bit to 0?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

Follow-up and exact cause is found in this thread:
viewtopic.php?f=3&t=18113

TL;DR - viewtopic.php?p=230416#p230416
1- The 2A03 asserts M2 before the data bus is stable (it will contain open bus at this time)
2- All writes from the 2A03 occur over multiple pixels inside the 2C02
3- If a write starts on the same dot that the X coordinate is copied from T to V (what the wiki calls "dot 257"), and the 2A03-vs-2C02 subpixel phase is correct, the value of open bus is what is in T at the moment of reload. The following pixel, the correct value is written to T, but V already contains the wrong value.
Post Reply