Talk:INES Mapper 163: Difference between revisions
(→VRAM Scanline switching: 163 and 96) |
m (→VRAM Scanline switching: revert self: you said that) |
||
Line 11: | Line 11: | ||
::If anyone has such cartridge, then see if you are able to put a program to set Y scroll to nonzero to see if there is a difference which you describe. --[[User:Zzo38|Zzo38]] ([[User talk:Zzo38|talk]]) 13:47, 27 January 2014 (MST) | ::If anyone has such cartridge, then see if you are able to put a program to set Y scroll to nonzero to see if there is a difference which you describe. --[[User:Zzo38|Zzo38]] ([[User talk:Zzo38|talk]]) 13:47, 27 January 2014 (MST) | ||
Revision as of 03:27, 28 January 2014
VRAM Scanline switching
Despite its annoying pirate features, this mapper is on the whole rather simple. A complex scanline counter seems unlikely. The games I've seen all use this feature only for a static title screen, which got me to thinking: What if it isn't scanline based at all? I implemented the following setup in Bizhawk and it appeared to work for all of the games that I could try with no graphical glitching:
Whenever PPU A13 transitions from 0 to 1, latch the current value of PPU A9. When the 'c' bit is on, use that latched value instead of PPU A12 as the input to CHR RAM A12.
(Note that Bizhawk implements an accurate PPU fetch pattern, including all dummy fetches). This method is reminiscent of Mapper 096 and can be implemented with discrete hardware or with a very small number of gates in a ASIC or CPLD. Natt (talk) 10:10, 27 January 2014 (MST)