Does anyone fully understand this mapper ? I've currently implemented it like this:
Odd writes (1st write, 3rd write, 5th, 7th, etc): make ppu pattern tables point to a dummy rom containing the data that was written. eg. write 0x13 to the mapper, and reads from the ppu pattern tables will return 0x13. If nothing (0) was written, point it to a dummy rom containing 0xff.
Even writes: make ppu pattern tables point to the default 8k chr rom.
This makes every game work, even that silly Banana game. But Banana has some graphics problems.
I thought Banana was a bad dump.
*Bump*
Banana was redumped recently, and it appears to be good as far as I can tell. However, the dump has been assigned to use mapper 3 in the iNES header. Does Banana use mapper 185 or mapper 3?
P.S. If someone needs the redump, let me know.
As long as this is bumped... I might as well bring up that in my recent efforts to add support for this mapper, I've discovered that these games appear to use unprepped RAM and expect it to be zero. Mighty Bomb Jack, for example... I got it to run, but the graphics were all distorted until I changed my emu to flush RAM with 0 instead of FF on powerup.
Anyone had any similar experiences with that?
All mapper 185 games work fine here, with ram at ff (and 0 too).
It seems Banana was released on 2 kinds of boards then ?
If I delete the 8K vrom from the GoodNES probable bad dump, and add the 16K vrom of CaH4e3's redump to it, it works too. Bankswitching is the same as CNROM.
Something else about Bananablah... if you go to the design section, you can see that the game uses a tape device. I can't figure out how it works...
save (I don't see it writing actual level data):
1: write lots of byte pairs, that, when added to eachother, always result in $103 (eg. 17, ec... or f4, 0f) to $4016
2: write byte pairs ff, 04 several times to $4016 (ff+4=$103 again)
3: write byte pairs fd, 06 eight times to $4016 (fd+6=guess ;p )
4: same as 2
load:
1: same as save 1, except eight times instead of lots
2: read from $4016 in a loop (haven't looked yet what it does with the data)
PRG 256Kbit, CHR 128Kbit. No other chips, only 74LS161 for CHR bankswitching. Game itself just perform simple test for CHR banks presence and correctness. According to PCB, it uses four data bits for selecting CHR bank: 0, 1, 4, 5. 0 bit select CHR bank (emulators ignore the rest bits, so bankswitching works fine as CHROM), but 1,4,5 should satisfy some condition for normal bankswitching on real cart, if not CHR is selecting as open bus (or somthing like that). Some kind of copy protection.
GoodNES have full 16K CHR dumps, marked as [hM03] and they all simple CHR overdumps, have 16K original CHR and 16K dummy CHR banks.
http://cah4e3.kicks-ass.net/dumping/oth ... a01-lo.jpg
http://cah4e3.kicks-ass.net/dumping/oth ... cir-lo.jpg
