MMC3 "when does the irq fire" test rom
Moderator: Moderators
Re: MMC3 "when does the irq fire" test rom
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.
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.
Re: MMC3 "when does the irq fire" test rom
Did you read the Disch's doc? Here's a quote.infiniteneslives wrote:I still fail to see how you came up with those numbers from disch's docs... What's your logic behind all this?the IRQ counter should decrement on PPU cycle 260,268,276... or 315
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"? It's a shame to read that. 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.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?
Re: MMC3 "when does the irq fire" test rom
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.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.
Which "repro MMC3 chip" are you talking about?
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: MMC3 "when does the irq fire" test rom
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.
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
Re: MMC3 "when does the irq fire" test rom
*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.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.
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)
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: MMC3 "when does the irq fire" test rom
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..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.
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
Re: MMC3 "when does the irq fire" test rom
8x8. I believe it was Retrostage's board.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?
It's completely reproducible, and the ROM does nothing weird. There is no scrolling. And emulators also act that way.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.
I counted pixels by counting cycles and then multiplying by 3.
Re: MMC3 "when does the irq fire" test rom
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.
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.
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 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.
Re: MMC3 "when does the irq fire" test rom
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
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
Re: MMC3 "when does the irq fire" test rom
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.
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.
Re: MMC3 "when does the irq fire" test rom
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?
Re: MMC3 "when does the irq fire" test rom
On the topic of unclear docs, the Scrolling page says:
AndBecause 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.
According to lidnariq, the change only becomes visible 1-2 tiles later. Can somebody with wiki rights correct that page?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.
Re: MMC3 "when does the irq fire" test rom
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.
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.
Re: MMC3 "when does the irq fire" test rom
My problem is not that you made a mistake.calima wrote:However, you made the same kind of mistake you accused me of, without admitting yours. What is that if not petty?
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.