There wasn't any existing test ROM to see what kind of MMC3 chip any given board has, so here's one. It will show you which of the wiki's "IRQ tick happens at 260,268,276... or 315" pixel values is correct for your chip.
The offset is 195 pixels, so if you measure the effect starting at 169 pixels, 169 - 195 + 341 = 315, that chip would be the 315 type.
Mednafen is exactly correct, fceux seems to be off by 8 pixels.
What exactly is the problem that you're testing for?
The actual hardware MMC3's IRQ fire timing is known; the only variation from IC to IC has to do with the behavior when a period of 0 is chosen.
FYI, blargg's
mmc3_tests 5 & 6 check for normal and alt MMC3 variants.
calima wrote:
fceux seems to be off by 8 pixels.
FCEUX's new-PPU render/CPU synch granularity is only once per 8 pixels, so it's hard for it to do better than that.
lidnariq wrote:
What exactly is the problem that you're testing for?
According to the wiki, there are four MMC3 variants. "the IRQ counter should decrement on PPU cycle 260,268,276... or 315". I needed to find out which this specific chip was.
infiniteneslives wrote:
FYI, blargg's
mmc3_tests 5 & 6 check for normal and alt MMC3 variants.
I had tried these in fceux, and neither of them printed when the irq happened. (edit: fceux also failed some tests)
calima wrote:
According to the wiki, there are four MMC3 variants. "the IRQ counter should decrement on PPU cycle 260,268,276... or 315". I needed to find out which this specific chip was.
... I don't know how that nonsense got in there?
No, I don't know why Zepper added that
crap. It's confusing. Nintendo's MMC3s will only fire an IRQ on the first rising edge of PPU A12 within a group, which should always be PPU cycle 260 or PPU cycle 324.
The later values could only possibly make sense if he was referring to mis-screen raster effects changing the Pattern table mapping bits of $2000 in the middle of a scanline.
It depends on how many 8x16 pixel sprites from the "wrong" half of the pattern table are in front of the first one from the "correct" half.
lidnariq wrote:
No, I don't know why Zepper added that
crap. It's confusing.
I'm here & watching every discussion over 20 years. So, take a wild guess.
That "260,268,276... or 315" is confusing as hell. I still have no idea what that means.
Here or
here.
Code:
Detailed IRQ Operation
---------------------------
MMC3 detects scanlines by watching A12 ($1000) on the PPU bus. Every time a rising edge occurs (transitions
from 0->1), and it hasn't been too close to the previous rising edge, the IRQ counter gets clocked.
Under *normal* conditions (BG using $0xxx, sprites using $1xxx), A12 will rise exactly 8 times every scanline
(once for each sprite CHR fetch). However the 8 rises are so close together that only the first is 'seen'.
During rendering and pre-render scanlines the PPU is fetching NT and CHR data from the cart through a series
of reads. Each read updates the PPU Address lines (including A12), and each read takes 2 PPU cycles (2
dots). There are 4 reads per tile, and 42 tiles per scanline:
- 32 BG tiles
- 8 Sprite tiles (for the next scanline)
- 2 BG tiles (for the next scanline)
Each tile requires 4 reads, each read is 2 dots:
dot 0: Name table fetch ($2xxx -- A12 is low)
dot 2: Attribute fetch ($2xxx -- A12 is low)
dot 4: Low CHR fetch ($0xxx or $1xxx -- A12 is low or high)
dot 6: High CHR fetch ($0xxx or $1xxx -- A12 is low or high)
If the tile being fetched is using the right-hand pattern table ($1xxx), then A12 goes high on dot 4 of that
8-dot sequence. Otherwise, A12 stays low throughout.
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)
324, 332 (2 BG tiles)
(You might be able to see now how I came up with those 260, 324 numbers I threw at you earlier)
MMC3 seems to ignore rises that are too close together. This is why the 8 sprite fetches will only clock
the counter once. Exactly how far apart the rising edges have to be is unknown, but it is somewhere between
14 and 16 dots. So any two consecutive opportunities are too close together (including the most distant
332->4), but any two non-consecutive opportunities will both be acknowledged.
Figuring whether the tile is being fetched from $0xxx or $1xxx is usually easy. BG and 8x8 sprites are
always fetched from an assigned pattern table (configurable by PPU reg $2000). However, 8x16 sprites can
come from either pattern table. So which tile is begin fetched depends on which sprite is being fetched....
which depends on what scanline you're on, and what sprites are found to be in-range on that scanline. For
scanlines which contain less than 8 sprites, tile $FF is fetched as a dummy (in 8x16 sprites, this would be
from the $1xxx pattern table).
This is why, when you have 8x16 sprites, ALL sprites must use the right-hand pattern table. If you have
sprites using the left and the right, you'll probably end up having some scanlines where the IRQ counter
counts the same scanline multiple times! All depending on which sprites are in-range and when. For example,
if there are 4 sprites on the scanline using $0xxx, and 4 using $1xxx, the IRQ counter might count the
scanline anywhere from 1 to 4 times!
0,0,0,0,1,1,1,1 <--- all 4 rises consecutive, will only clock once
0,1,0,1,0,1,0,1 <---- all 4 rises nonconsecutive, counter clocked each time!
This is also why the IRQ counter isn't clocked when both BG and sprites use the left pattern table (since
there is never any rising edge, the MMC3 never detects any scanlines).
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? 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?
There were a bunch of threads on the forum during March-April 2016 about MMC3 issues. (
viewtopic.php?t=12562 ;
viewtopic.php?t=14048 ;
viewtopic.php?t=14056 ;
viewtopic.php?t=14103 )
Evidently, the problems that Zepper had boiled down to MMC3 games that use 8x16 sprites in an inconvenient manner. (I didn't know there were any. It'd be good to make a partial list of these games.) The cryptic comment about "one of the following 10 alignments" didn't explain
why one or another would be chosen, and so Calima assumed there were variations in hardware. (Oh well)
I've attempted to update the wiki page in a way that will both prevent someone else from recapitulating Calima's confusion, and also make the point that Zepper was attempting to make.
However, I'm still not clear on how the counter could be decreased on PPU cycle 332. Per
https://wiki.nesdev.com/w/index.php/Fil ... timing.png , that should be the
second background tile fetch...
—
Another thing I'd like someone else to check: We have
a report that the PPU will spend its "idle" pixel driving the address bus to $1xxx, which would cause an MMC3 with sprites and backgrounds set to the $0xxx page to still generate IRQs. Does anyone have the ability to cross-check this?
Quote:
260, 268, 276, 284, 292, 300, 308, 316 (8 Spr tiles)
If one 8x16 sprite from the "wrong" pattern table preceding the first sprite from the "right" one is in range, the PIT is clocked at 268 instead of 260. If two such sprites are in range, the PIT is clocked at 276.
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.
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.
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.
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.
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?
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.
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)
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.
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.
Just to clarify the things, please, read
here and
here.
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.
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
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.
You respond to a post proving you can't count with "calima can't count" 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?
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?
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.
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.
I had proof, you had "because I say so", so of course I'm going to believe the proof, no matter the person saying otherwise.
In this case my proof was wrong indeed, but to prove or disprove something it's not enough to say "it is so". Even if you have 20 years experience, I will still expect hard proof instead of believing you blindly.
And that's what I meant by humility.
Assuming that you're infallible. You're not. No one is. Assuming you couldn't make a mistake. Assuming that your model was accurate. It wasn't just me telling you.
It's not about the fact the proof was mine, it's about proof over words. Had the proof been by anyone else, I would still have believed it over anyone's words, after running it and witnessing the results.
If there's hard proof the sky is blue, and you get a sky expert telling you it is green, are you going to believe the expert without proof?
Strained metaphor, much?
Your proof was based on faulty assumptions. Your evidence that /IRQ was asserted at pixel 315 had more in common with proving that a soccer pitch was 86 meters long because you assumed that your measuring tape was accurate. When we pointed out that the rule book said "it's 100m", you denied it, and ultimately required that I go and find your measuring tape and show that it wasn't trustworthy.
Your proof wasn't "hard". It was about as squishy as possible. But you assumed it was correct and when someone told you you were wrong you didn't reevaluate your assumptions.
I'm sorry
lidnariq for the recent trouble, really. I though that such MMC3 information was well-known and... trivial.
I never stopped development on RockNES, and it's the only one still alive in
20 years (1998-2018).
I'm no scientist, but one experimental result does not equal proof...
One experimental result may, however, provide proof that a budget for a properly designed experiment is desirable.
lidnariq wrote:
Your proof wasn't "hard". It was about as squishy as possible. But you assumed it was correct and when someone told you you were wrong you didn't reevaluate your assumptions.
Says who? I checked my calculations after those posts, and found they were correct. I also checked the Scrolling page, and found no indication the effect would be delayed (this is now fixed thanks to tepples). At that point, I indeed expect proof. It is not an insult to your authority that I expect proof, when I have proof showing otherwise.
Quote:
ultimately required that I go and find your measuring tape and show that it wasn't trustworthy.
That's how proof works. It can only be overridden by better proof. Why is that an issue to you?
edit: mention the scrolling page.
Well, rather than insisting that you were infallible, you could have instead posted the source and asked politely what was wrong. That would have same the same end result without being combative.
Do you really not understand why I'm harping on humility? It's not like this is the first time that your demeanor of "I'm the smartest most infallible human and everyone else is an idiot" has annoyed me; it's just the first time where I knew it was trivially wrong.
Yes, I could have worded it better, I agree.
I see why it bothers you, though in others it does not bother me in the least. I will try to write more politely.