Has this been confirmed via testing on original hardware? It seems very unlikely to me. How is the MMC5 supposed to know whether sprites are 8x8 or 8x16?Registers $5120-$5127 apply to sprite graphics and $5128-$512B for background graphics, but ONLY when 8x16 sprites are enabled.
Otherwise, the last set of registers written to (either $5120-$5127 or $5128-$512B) will be used for all graphics.
MMC5 CHR banking
Moderator: Moderators
MMC5 CHR banking
According to the Wiki:
Re: MMC5 CHR banking
It can spy on writes to $2000.AWJ wrote:How is the MMC5 supposed to know whether sprites are 8x8 or 8x16?
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: MMC5 CHR banking
Can. But does it? It could also log sprite reads and…yeah, that would take a lot more silicon.
Re: MMC5 CHR banking
The big question I have from that is why would that be desirable ?
It feels like it "has" to be a side effect of how they implemented this extended sprite banking, but I don't have any ideas as to what original constraint would make this simpler than just always having sprites come from a disjoint banking space than the background, regardless of whether the sprites were 8x8 or 8x16.
It feels like it "has" to be a side effect of how they implemented this extended sprite banking, but I don't have any ideas as to what original constraint would make this simpler than just always having sprites come from a disjoint banking space than the background, regardless of whether the sprites were 8x8 or 8x16.
Re: MMC5 CHR banking
Playing Devil's Advocate…
- Having concurrent banking helps when you're doing raster effect banking that includes sprites.
- Having 8x16 sprites means you're using significantly more data on sprites.
- 8x8 banking already permits BG-disjoint banking of sprites, by PPUCTRL.d3-4 = {10,01} and having different banking registers for $0xxx and $1xxx.
- Having a mode where it acts like a traditional mapper possibly reduces programmer learning time.