MMC3 question - NESdev BBS

MMC3 question
by darklink on 2006-08-05 (#16003)

I read Kevin's MMC3 document and have several question.
http://www.tripoint.org/kevtris/mappers/mmc3/index.html

1:
what clocks the IRQ counter. In many documents it is the ppu A13 line, after 0->1 42 times, clocks the IRQ counter once. but others(include some topics in this thread) it is A12 rising edge... which is right ?

2:
does the dummy scanline before VINT clock the IRQ counter ?

3:
for cards with VRAM rather than VROM. Does the swap mechaism control via 8000 and 8001 work as VROM does ?

4:
a question not relate to MMC3--When does the PPU update the horizontal and vertical counter from latch? Does it in 256 cc (total 341cc per scanline).

by dvdmth on 2006-08-05 (#16004)

1. Rising edge of A12. The A13 line is not connected to the MMC3 anyway.

2. The scanline before VBlank does not clock the MMC3. The dummy scanline after VBlank does. In short, the MMC3 will be clocked 241 times per scanline (assuming normal pattern table configurations).

3. Yes. Games using CHR-RAM have to write to $8000/1 at startup to ensure that the CHR-RAM is properly seen by the PPU.

4. The horizontal scroll registers are reset to the latch at cycle 257 of each scanline. The vertical registers are incremented at cycle 251 of each scanline. During the pre-render scanline, all registers (horizontal and vertical) are reset at cycle 304. (These timings assume cycles 0-255 corresponding to on-screen drawing and 256-340 corresponding to HBlank.)

by darklink on 2006-08-06 (#16023)

Thanks very much !

Quote:
2. The scanline before VBlank does not clock the MMC3. The dummy scanline after VBlank does. In short, the MMC3 will be clocked 241 times per scanline (assuming normal pattern table configurations).

So games using MMC3 IRQ must be very very carefully designed.
using 8*16 sprites, using pattern table 1, and access palette.... each of these might clock IRQ counter many times during a scanline. Is that so ?

Quote:
3. Yes. Games using CHR-RAM have to write to $8000/1 at startup to ensure that the CHR-RAM is properly seen by the PPU.

games with VRAM usually of 8K size, right ?

by tepples on 2006-08-06 (#16024)

darklink wrote:
games with VRAM usually of 8K size, right ?

Only a few games have CHR RAM larger than 8 KiB. The only one I can think of is Videomation, on a CPROM board, which has 16 KiB.

A few MMC3 games use mappers with both CHR RAM and CHR ROM. These include the Rare pinball sims that use the TQROM board (Pinbot and High Speed), which have an 8 KB CHR RAM bank in addition to CHR ROM, and a couple Chinese RPGs on a functionally similar board that copy Chinese character glyphs from PRG ROM to CHR RAM.

by Disch on 2006-08-06 (#16029)

darklink wrote:
So games using MMC3 IRQ must be very very carefully designed.
using 8*16 sprites, using pattern table 1, and access palette.... each of these might clock IRQ counter many times during a scanline. Is that so ?

Palette fetches don't run through the cartridge (the palettes exist in the PPU), so the MMC3 is unaffected by them. The MMC3 does see the name, attribute, and pattern table reads though.

Pretty much, only CHR fetches affect the IRQ counter. The only rises "seen" by the MMC3 are done when the PPU Address is updated via $2006/$2007 -- or during rendering as CHR from the "right-hand" pattern table is fetched.

When name and attribute bytes are fetched, A12 goes low
When CHR from the "left" ($0xxx) pattern table is fetched, A12 goes low
When CHR from the "right" ($1xxx) pattern table is fetched, A12 goes high

Typically, games will have all background tiles use the $0xxx pattern table, and all sprite tiles use the $1xxx pattern table (even when in 8x16 sprite mode -- the games make sure sprites are using the $1xxx pattern table). This will cause A12 to rise exactly 8 times every scanline (on cycle 260, 268, 276, 284, 292, 300, 308, and 316). However the MMC3 somehow filters out rises which are close together -- so only the first of these rises will clock the counter.

As long as the game sticks to the BG on left, sprites on right rule, the counter will work fine. But when the game starts mixing left and right 8x16 sprites, it is possible to have the IRQ counter clocked multiple times in one scanline.

by Quietust on 2006-08-06 (#16032)

Disch wrote:
darklink wrote:
So games using MMC3 IRQ must be very very carefully designed.
using 8*16 sprites, using pattern table 1, and access palette.... each of these might clock IRQ counter many times during a scanline. Is that so ?

Palette fetches don't run through the cartridge (the palettes exist in the PPU), so the MMC3 is unaffected by them.

Actually, the MMC3 does see palette reads and writes, but just the addresses - remember, when you read from the palette via $2006/$2007, the PPU fetches the underlying nametable byte into the I/O buffer (don't recall what happens on writes).

by Disch on 2006-08-06 (#16034)

No way.... I meant the fetch for the color to be output... like for each pixel (I'd assume once every PPU cycle). There's no way all of those fetches get run through the cartridge.... do they?

I mean I'm sure palette reads/writes through $2007 do... yeah... but not during rendering...

by darklink on 2006-08-10 (#16101)

Oh, now I understand how it works...
I got a wrong view before this post...
Thanks very much !!