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.
Random glitchy line in Super Mario Bros. on real hardware?
Moderator: Moderators
Re: Random glitchy line in Super Mario Bros. on real hardwar
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).
- 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).
- BMF
RuSteD LOgIc
RuSteD LOgIc
- 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
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.
Re: Random glitchy line in Super Mario Bros. on real hardware?
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?
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!
Re: Random glitchy line in Super Mario Bros. on real hardware?
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.
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.