MMC3 irqs again... 8x16 sprites?
Moderator: Moderators
MMC3 irqs again... 8x16 sprites?
How do MMC3 irqs interact with 8x16 sprites, which draw from either of the two pattern tables?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Simple - you make sure all of your sprites are coming from the upper pattern table.
That, or you make absolutely certain that all sprites present in the lower pattern table come first and that you always have at least one sprite in the upper pattern table (or at least one unused sprite) per scanline.
That, or you make absolutely certain that all sprites present in the lower pattern table come first and that you always have at least one sprite in the upper pattern table (or at least one unused sprite) per scanline.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Short answer: It will usually screw up.
Long answer: with the "normal" setup (BG uses $0xxx, all sprites use $1xxx), A12 will rise 8 times per scanline (once for each sprite fetch). Only the first of those will actually count the IRQ counter, presumably the others are filtered out and ignored because they're close to each other. However if a gap is stuck between them (such as mixing $0xxx and $1xxx 8x16 sprites) it's possible for the IRQ counter to be clocked multiple (I'd imagine up to 4) times per scanline.
I don't think it's known exactly how close together the rising edges have to happen in order for them to be ignored -- though I'd think it's somewhere between 13 and 24 PPU cycles. I'm pretty sure it can't be less than 13, since one game (don't remember which one) uses $1xxx for BG and $0xxx for sprites, and if you emulate the gap with less than 13 cycles it will count twice per scanline (once at cycle 324, and again at 4 -- instead of just cycle 324 which is intended).
EDIT -- Mario Adventure, a popular hack of Super Mario Bros. 3, mixes $0xxx and $1xxx 8x16 sprites, since at the time, the hack author was unaware of that behavior and emus at the time didn't show the error. I used this game for testing this behavior in my emu. Here is a screenshot of it borking (Nintendulator and NEStopia show similar results):
Long answer: with the "normal" setup (BG uses $0xxx, all sprites use $1xxx), A12 will rise 8 times per scanline (once for each sprite fetch). Only the first of those will actually count the IRQ counter, presumably the others are filtered out and ignored because they're close to each other. However if a gap is stuck between them (such as mixing $0xxx and $1xxx 8x16 sprites) it's possible for the IRQ counter to be clocked multiple (I'd imagine up to 4) times per scanline.
I don't think it's known exactly how close together the rising edges have to happen in order for them to be ignored -- though I'd think it's somewhere between 13 and 24 PPU cycles. I'm pretty sure it can't be less than 13, since one game (don't remember which one) uses $1xxx for BG and $0xxx for sprites, and if you emulate the gap with less than 13 cycles it will count twice per scanline (once at cycle 324, and again at 4 -- instead of just cycle 324 which is intended).
EDIT -- Mario Adventure, a popular hack of Super Mario Bros. 3, mixes $0xxx and $1xxx 8x16 sprites, since at the time, the hack author was unaware of that behavior and emus at the time didn't show the error. I used this game for testing this behavior in my emu. Here is a screenshot of it borking (Nintendulator and NEStopia show similar results):
Does the IRQ counter still use the default 8x8 sprite pattern table while the PPU is set to display 8x16 sprites? So the 8x16 sprites would generally have to match the ppu's flag, or else it would get odd MMC3 IRQ behavior?
I noticed that Tiny Toon Adventures mixes the right and left pattern table, but it uses the right pattern table exclusively until the status bar is displayed, then bankswitches in clear graphics for the right table, then displays sprites from the left table.
I noticed that Tiny Toon Adventures mixes the right and left pattern table, but it uses the right pattern table exclusively until the status bar is displayed, then bankswitches in clear graphics for the right table, then displays sprites from the left table.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
No. $2000.3 has zero effect when it's 8x16 sprites. The only thing that really matters is which pattern table the graphics are being fetched from. If they're being fetched from $0xxx, A12 is low, if they're being fetched from $1xxx, A12 goes high (rising edge).
This will happen 8 times every scanline for sprite fetches (but again only the first is used -- the rest are filtered out because they're so close together). Whether or not A12 rises depends on which pattern table byte is fetched for the sprites that happen to be in-range for the scanline. In the event that there's less than 8 sprites on a scanline, the remaining dummy fetches are performed with a dummy value of $FF (so for 8x16 sprites, they will always fetch from $1xxx).
What Tiny Toon Adventures does is common practice in a few games (I believe FF3 does something similar). The IRQ counter IS counting irregularly in those cases, but because the game is not using the IRQ counter for those parts, it doesn't matter.
This will happen 8 times every scanline for sprite fetches (but again only the first is used -- the rest are filtered out because they're so close together). Whether or not A12 rises depends on which pattern table byte is fetched for the sprites that happen to be in-range for the scanline. In the event that there's less than 8 sprites on a scanline, the remaining dummy fetches are performed with a dummy value of $FF (so for 8x16 sprites, they will always fetch from $1xxx).
What Tiny Toon Adventures does is common practice in a few games (I believe FF3 does something similar). The IRQ counter IS counting irregularly in those cases, but because the game is not using the IRQ counter for those parts, it doesn't matter.