It is currently Fri Nov 24, 2017 7:15 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 41 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Fri Sep 22, 2017 7:21 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 585
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.


Attachments:
mmc3irqtest.nes [24.02 KiB]
Downloaded 31 times
Top
 Profile  
 
PostPosted: Fri Sep 22, 2017 10:56 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
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.


Top
 Profile  
 
PostPosted: Fri Sep 22, 2017 12:40 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1925
Location: WhereverIparkIt, USA
FYI, blargg's mmc3_tests 5 & 6 check for normal and alt MMC3 variants.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Fri Sep 22, 2017 4:21 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5842
Location: Canada
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.


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 11:04 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 585
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.


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 11:05 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 585
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)


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 11:52 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
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.


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 2:00 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19257
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 3:04 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
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.


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 3:26 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10119
Location: Rio de Janeiro - Brazil
That "260,268,276... or 315" is confusing as hell. I still have no idea what that means.


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 7:59 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
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).


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 8:59 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1925
Location: WhereverIparkIt, USA
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?

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 9:16 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
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?


Last edited by lidnariq on Sun Sep 24, 2017 9:19 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Sep 24, 2017 9:18 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19257
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Mon Sep 25, 2017 2:32 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 585
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 41 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot], Yahoo [Bot] and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group