nesdev.com
http://forums.nesdev.com/

MMC3 "when does the irq fire" test rom
http://forums.nesdev.com/viewtopic.php?f=2&t=16522
Page 2 of 3

Author:  Zepper [ Mon Sep 25, 2017 6:16 am ]
Post subject:  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.

Author:  Zepper [ Mon Sep 25, 2017 6:21 am ]
Post subject:  Re: MMC3 "when does the irq fire" test rom

infiniteneslives wrote:
Quote:
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:
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)

Quote:
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:

Author:  tepples [ Mon Sep 25, 2017 7:32 am ]
Post subject:  Re: MMC3 "when does the irq fire" test rom

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?

Author:  infiniteneslives [ Mon Sep 25, 2017 8:56 am ]
Post subject:  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.

Author:  lidnariq [ Mon Sep 25, 2017 10:22 am ]
Post subject:  Re: MMC3 "when does the irq fire" test rom

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)

Author:  infiniteneslives [ Mon Sep 25, 2017 10:40 am ]
Post subject:  Re: MMC3 "when does the irq fire" test rom

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.

Author:  calima [ Mon Sep 25, 2017 11:04 am ]
Post subject:  Re: MMC3 "when does the irq fire" test rom

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.

Quote:
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.

Author:  Zepper [ Mon Sep 25, 2017 11:26 am ]
Post subject:  Re: MMC3 "when does the irq fire" test rom

Just to clarify the things, please, read here and here.

Author:  lidnariq [ Mon Sep 25, 2017 12:02 pm ]
Post subject:  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.

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.

Author:  calima [ Mon Sep 25, 2017 11:48 pm ]
Post subject:  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

Author:  lidnariq [ Mon Sep 25, 2017 11:57 pm ]
Post subject:  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.

Author:  calima [ Tue Sep 26, 2017 12:15 am ]
Post subject:  Re: MMC3 "when does the irq fire" test rom

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?

Author:  calima [ Tue Sep 26, 2017 1:36 am ]
Post subject:  Re: MMC3 "when does the irq fire" test rom

On the topic of unclear docs, the Scrolling page says:
Quote:
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
Quote:
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?

Author:  tepples [ Tue Sep 26, 2017 6:22 am ]
Post subject:  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.

Author:  lidnariq [ Tue Sep 26, 2017 10:27 am ]
Post subject:  Re: MMC3 "when does the irq fire" test rom

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.

Page 2 of 3 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/