MMC3 "when does the irq fire" test rom

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
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: MMC3 "when does the irq fire" test rom

Post by Zepper »

Firstly, tepples is correct.
Next, it's surprising you don't know the MMC3 IRQ logic. ALL the info I got came from Disch, and some details from blargg's test ROMs. Again, it's a big surprise to me of how most of you don't even know about the MMC3 IRQ logic - a CHANCE of A12 rising at PPU dot 260, 268... at every 8 dots due to the sprite fetches, then at 4,8,12... on PPU background fetches.

Now, if you have any questions, please, contact Disch. I'm not the right person for it. Sorry for the trouble.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: MMC3 "when does the irq fire" test rom

Post by Zepper »

infiniteneslives wrote:
the IRQ counter should decrement on PPU cycle 260,268,276... or 315
I still fail to see how you came up with those numbers from disch's docs... What's your logic behind all this?
Did you read the Disch's doc? Here's a quote.

Code: Select all

This 8-dot sequence is repeated for each tile.. meaning there are 42 opportunities for A12 to rise.  These
opportunities occur on the following dots:

4, 12, 20, ..., 244, 252                 (32 BG tiles)
260, 268, 276, 284, 292, 300, 308, 316   (8 Spr tiles)  <<-- HERE!
324, 332                                 (2 BG tiles)
No one here understands your wiki edits, and when asked, you're telling us to guess and dumping worthlessly dumping disch docs. Are you intentionally trying to make this some sort of puzzle?
"No one"? It's a shame to read that. :oops: :oops: Does it always happen... or just for you? ALL my edits take information from HERE. All the "incomprehensible" edits were taken from HERE. I'm really upset now... sorry. :? :oops: :cry:
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: MMC3 "when does the irq fire" test rom

Post by tepples »

calima wrote:The current wiki is wrong. My test ROM showed that the repro MMC3 chip fired on pixel 315, just like mednafen or the previous wiki description.

The ROM is using $0000 for bg and $1000 for sprites.
8x8 or 8x16? Because pixel 315 sounds like you're putting seven 8x16 pixel sprites from $0000-$0FFF in front of either one 8x16 pixel sprite from $1000-$1FFF or one empty secondary OAM location.

Which "repro MMC3 chip" are you talking about?
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: MMC3 "when does the irq fire" test rom

Post by infiniteneslives »

Sorry to have upset you, it wasn't my intention. Part of my confusion is lack of clarity of the original statement. "260,268,276... or 315"

What's the ... about, are there numbers in there you're not listing? 315 isn't on disch's list.

If there isn't much of an explanation as to why or how one gets the IRQ to fire at those times, randomly listing some of the potential times isn't helpful. In some place like the wiki it makes more sense to explain what rules must be followed to get IRQs to fire at 260. We could have practically an entire wiki page devoted to when it will fire if those rules aren't followed.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC3 "when does the irq fire" test rom

Post by lidnariq »

calima wrote:The current wiki is wrong. My test ROM showed that the repro MMC3 chip fired on pixel 315, just like mednafen or the previous wiki description.

The ROM is using $0000 for bg and $1000 for sprites.
*shrug* The MMC3 IRQ hardware is known to use this signal for its clock: a rising edge of PPU A12 after PPU A12 has been low for at least 6 pixels.

If you're seeing it assert on pixel 315, I don't know what you're doing, but there's something suspect. Maybe just how you're counting pixels. Maybe your fine X scroll value.

Per the timing convention in this timing diagram: https://wiki.nesdev.com/w/index.php/Fil ... timing.png the IRQ should be asserted on cycle 261 (the first pattern table fetch during the sprite fetch portion) or on cycle 325 (the first pattern table fetch during the background fetch portion)
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: MMC3 "when does the irq fire" test rom

Post by infiniteneslives »

lidnariq wrote:The MMC3 IRQ hardware is known to use this signal for its clock: a rising edge of PPU A12 after PPU A12 has been low for at least 6 pixels.
I believe it's more accurate for the amount of time PPU A12 must be low to be referenced to CPU M2 clock cycles, but I agree that's more confusing..

This is all part of why MMC3 is considered so complex. It's not the mapper hardware is that complex, it's the signals that drive the mapper which are complex. The chip must sense scanlines via signals it has available to it (mainly PPU A12, and also CPU M2 for a sense of time). Thus one must have a strong grasp of the PPU and CPU signals and their timing to fully understand when to expect an IRQ to fire.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: MMC3 "when does the irq fire" test rom

Post by calima »

tepples wrote:8x8 or 8x16? Because pixel 315 sounds like you're putting seven 8x16 pixel sprites from $0000-$0FFF in front of either one 8x16 pixel sprite from $1000-$1FFF or one empty secondary OAM location.

Which "repro MMC3 chip" are you talking about?
8x8. I believe it was Retrostage's board.
If you're seeing it assert on pixel 315, I don't know what you're doing, but there's something suspect. Maybe just how you're counting pixels. Maybe your fine X scroll value.
It's completely reproducible, and the ROM does nothing weird. There is no scrolling. And emulators also act that way.

I counted pixels by counting cycles and then multiplying by 3.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: MMC3 "when does the irq fire" test rom

Post by Zepper »

Just to clarify the things, please, read here and here.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC3 "when does the irq fire" test rom

Post by lidnariq »

Having looked closely in the test ROM:

The IRQ is PHA, 20 NOPs, then 24 cycles of LDA #imm STA 2006/5/5/6. This should take 201 pixels. (How did Calima get 195?). edit: Plus it takes 7 cycles to enter an IRQ (Total: 222 pixels). Additionally, because this changes the scroll location instead of something with less latency (like emphasis), there's another 16-ish pixels of latency afterwards.

Additionally, the IRQ interrupts a "CMP zp; BEQ rel" loop so there's up to 3 CPU cycles = 9 pixels of jitter in the resultant IRQ timing.

If I change the 2006/5/5/6 write sequence to one that instead sets the greyscale bit at the same time as the original final 2006 write, the edge moves ≈20-12 pixels to the left, as expected.

All emulators finally display the updated scroll somewhere around on-screen coordinate (160), meaning that the IRQ was asserted somewhere around on-screen pixel (260). So, there you go: your test shows that IRQ is asserted on pixel 260, as previously stated.
calima wrote:The current wiki is wrong. My test ROM showed that the repro MMC3 chip fired on pixel 315, just like mednafen or the previous wiki description.
An awful lot of people who are at least as smart as you and many of whom have tremendously greater domain knowledge have put an awful lot of effort into documenting things. Some of them are still present. A little humility would serve you well.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: MMC3 "when does the irq fire" test rom

Post by calima »

Zepper is one of them, having made a successful Windows emulator, and the original documentation was his.

You are correct that I made a mistake in that I didn't count the 7 cycles to enter an IRQ. However you also made a mistake, there are 19 nops, not 20.

PHA = 3
19 NOPS = 19 * 2
4 LDA #imm = 2 * 4
4 STA ABS = 4 * 4

3 + 19*2 + 2*4 + 4*4 = 65
65 * 3 = 195
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC3 "when does the irq fire" test rom

Post by lidnariq »

And you misinterpreted it, and you doubled down when you were told you had misinterpreted it.

Nothing in Zepper's original documentation obviously meant "there are 8 physical variations of the MMC3". That's all on you.

When the options are "Maybe Calima can't count" or "Maybe everyone else is wrong", you should seriously consider the former.

And when you retaliate with nitpicking? That just makes you look like a petty fool.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: MMC3 "when does the irq fire" test rom

Post by calima »

You respond to a post proving you can't count with "calima can't count" :D

edit: I'm sorry, this was unnecessary. However, you made the same kind of mistake you accused me of, without admitting yours. What is that if not petty?
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: MMC3 "when does the irq fire" test rom

Post by calima »

On the topic of unclear docs, the Scrolling page says:
Because this method sets v immediately, it can be used to set the scroll in the middle of the line. This is not normally recommended, as the difficulty of exact timing and interaction of tile fetches makes it difficult to do cleanly.
And
By writing twice to $2006, the second write causes an immediate full reload of v from t, allowing you to update the vertical scroll in the middle of the screen.
According to lidnariq, the change only becomes visible 1-2 tiles later. Can somebody with wiki rights correct that page?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: MMC3 "when does the irq fire" test rom

Post by tepples »

The effect on fetches is immediate. The effect on actual output pixels is delayed until the already-fetched pattern data passes through the shift registers that decode planar tile format and perform fine scrolling.

Requests for edits like this to address cross-cutting concerns everywhere, such as how the timing of mid-scanline v changes interacts with the pixel decoding and fine scroll processes, are part of how the wiki becomes more verbose and harder for a novice to read.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MMC3 "when does the irq fire" test rom

Post by lidnariq »

calima wrote:However, you made the same kind of mistake you accused me of, without admitting yours. What is that if not petty?
My problem is not that you made a mistake.

It's that, when told you had made a mistake, you insisted you hadn't, requiring that I look inside the details of what you had done to prove the specifics of the mistake.

When you retaliate with "I made a mistake, but you ALSO made a mistake"— That's what's petty. That's a false equivalence, because I wasn't using the exact calculation to conclude something that was untrue.
Post Reply