MMC3 scanline counter off by 1 between fceux and Nestopia

[lidnariq]

Or do I really have to put background to 0 and sprites to 1? And what happens if I don't (in non-technical terms please: What happens then)?

nesdevwiki:MMC3§IRQ Specifics , the "regarding PPU A12" subsection

[DRW]

Sorry, but I still don't understand this.

For example:
What is A12? What are rising edges? How does a line remain low and what does this mean at all? What is M2?

Is there any explanation that doesn't include a million words that need their own explanation as well?

I just need a clear description: What might be the issue when the sprites are in nametable 0? Does the counter get confused then? Will there be any glitches? Out of sync issues? Wrong colors? Games freezing?
What is the final consequence, the actual observable issue?

Also, what doesn this mean?

The scanline counter will also work when the BG uses the right pattern table ($1000) and the sprites use the left pattern table ($0000), but this is less common.

So, does this mean it doesn't matter? The counter will work with both combinations? If yes, why is this combination less common if it doesn't really make a difference?

[never-obsolete]

The counter won't work as expected. This can manifest as irqs firing too early, too late or somewhere in between. The exact outcome depends on what is being rendered.

In short, A12 is address line 12, m2 has something to do with the cpu clock, going high and low to allow for reads and writes on the same bus.

[lidnariq]

Sorry, but I still don't understand this.

I said to read the "regarding PPU A12" subsection because it directly answers your question without the other jargon. What is unclear about

When using 8x8 sprites, if the BG uses $0000, and the sprites use $1000, the IRQ counter should decrement on PPU cycle 260, right after the visible part of the target scanline has ended.
When using 8x8 sprites, if the BG uses $1000, and the sprites use $0000, the IRQ counter should decrement on PPU cycle 324 of the previous scanline (as in, right before the target scanline is about to be drawn).

?

The only thing missing is what happens if you put both background and foreground from the same 4KiB pattern table, for which the answer is: no IRQs at all.

In practice the answer is: Pick the configuration that that gives the horizontal IRQ phase you want. Use the MMC3's "CHR A12 inversion" control to specify whether the background gets the two 2KiB banks, or the sprites get the two 2KiB banks instead.

[tepples]

How does a line remain low

A line is "low" when it carries a low voltage, which represents a value zero. A line is "high" when it carries a high voltage, which represents a value of one. A line "remains" in a state when its value does not change.

What is A12?

A12 is address line 12, the line whose state differs between addresses that are 2^12 ($1000) bytes apart. PPU A12 is low when the PPU is reading $0000-$0FFF or $2000-$2FFF, or high when the PPU is reading $1000-$1FFF. (The PPU does not read $3000-$3FFF during rendering.) Converting a few addresses from hexadecimal to binary may help you see the pattern:

Code: Select all

      13 12 11 10  9  8  7  6  5  4  3  2  1  0
$0000  0  0  0  0  0  0  0  0  0  0  0  0  0  0
$0001  0  0  0  0  0  0  0  0  0  0  0  0  0  1
$0FFF  0  0  1  1  1  1  1  1  1  1  1  1  1  1
$1000  0  1  0  0  0  0  0  0  0  0  0  0  0  0
$1001  0  1  0  0  0  0  0  0  0  0  0  0  0  1
$1FFF  0  1  1  1  1  1  1  1  1  1  1  1  1  1
$2000  1  0  0  0  0  0  0  0  0  0  0  0  0  0
$2001  1  0  0  0  0  0  0  0  0  0  0  0  0  1
$2FFF  1  0  1  1  1  1  1  1  1  1  1  1  1  1

What are rising edges?

An "edge" is a transition of a digital signal from one state to another. A "rising edge" is such a transition from 0 to 1. Rising edges on A12 indicate a switch from reading $0000-$0FFF to $1000-$1FFF, or from $2000-$2FFF to $1000-1FFF. On the PPU, these represent a transition from the first pattern table to the second, or from the nametables to the second pattern table. During usual MMC3 operation, this happens during the sprite pattern fetch phase of a scanline (x=257 to 320), between dummy nametable fetches and fetches from the second pattern table.

What is M2?

M2 is the primary CPU clock signal going into the Game Pak. It has one rising edge and one falling edge for each full CPU cycle, or 1,789,773 of each edge per second.

What might be the issue when the sprites are in nametable 0?

Nametables (tilemaps) don't matter for this. Pattern tables (CHR, at $0000-$0FFF and $1000-$1FFF) do.

Does the counter get confused then?

Yes.

Will there be any glitches? Out of sync issues? Wrong colors? Games freezing?

What is the final consequence, the actual observable issue?

Using sprites in $0000 and background tiles in $1000 causes the IRQ to trigger around X=325 instead of X=261. If the rest of the timing of the MMC3 interval timer handler assumes X=261, as is the case for the majority of MMC3 games, it might produce a visible glitch that involves the background visibly changing in the middle of a scanline on the split's border, or the background below the split shaking up and down by one pixel, or both.

Using 8x16-pixel sprites from both pattern tables confuses the timer even more, as this increases the time between edges on PPU A12 past the time that the MMC3 is able to filter out, causing the timer to count more than once per scanline. The visible effect of this is a split that appears 8, 16, or more scanlines above where you expect it to appear.

Also, what doesn this mean?

The scanline counter will also work when the BG uses the right pattern table ($1000) and the sprites use the left pattern table ($0000), but this is less common.

So, does this mean it doesn't matter? The counter will work with both combinations? If yes, why is this combination less common if it doesn't really make a difference?

The going hypothesis is that Nintendo provided a manual with the MMC3, and the manual recommended use of background at $0000 and sprites at $1000.

[dougeff]

For once I do understand something.

A12 is this bit in the PPU address.

0001 0000 0000 0000

So, when the PPU is reading from tileset #0, Addresses 0-fff, this bit is zero. When the PPU is reading from tileset #1, addresses 1000-1fff, this bit is one.

If you have the PPU control set to have BG on tileset #0, and sprites on tileset #1, then at exactly dot 256 of a scanline A12 will go from 0 (low) to 1 (high). (It spends the entire scanline drawing BG tiles, and evaluates the next line's sprites during Hblank).

If however, you have BG on tileset #1 and Sprites on tileset #0, A12 will remain high (1) the entire scanline, and won't go from low to high till the end of the H blank period, and the IRQ will fire at the start of the NEXT line.

If you have both BG and Sprites on tileset #0 (or both on #1), then A12 will stay low (0) the entire screen. And the IRQ won't fire.

(Several people posted while I was typing, oh well).

[koitsu]

The going hypothesis is that Nintendo provided a manual with the MMC3, and the manual recommended use of background at $0000 and sprites at $1000.

It's less of a hypothesis and actually confirmed. (Pages 3 and 4 of both MMC3 manuals (1987/12/15 and 1988/05/24) both cover this)

[tokumaru]

What might be the issue when the sprites are in nametable 0? Does the counter get confused then? Will there be any glitches? Out of sync issues? Wrong colors? Games freezing?
What is the final consequence, the actual observable issue?

The worse that can happen is that the IRQ will fire on the wrong scanline, which can be pretty bad.

The scanline counter will also work when the BG uses the right pattern table ($1000) and the sprites use the left pattern table ($0000), but this is less common.

So, does this mean it doesn't matter? The counter will work with both combinations? If yes, why is this combination less common if it doesn't really make a difference?

Using $0000 for sprites and $1000 for the background will cause the IRQ to fire at a different time in the scanline, but will work fine if you use 8x8 sprites exclusively. If you use 8x16 sprites though, even if you don't explicitly use patterns from the $1000 side, the PPU will still do some dummy sprite fetches from that side, causing the scanline counter to malfunction. That's probably the reason why using $0000 for the background and $1000 for sprites is the suggested configuration.