I sat down and traced the Dragon Ball module, and found the following pin order for the mapper, the middle chip-on-board (clockwise, starting at 10 o'clock on the component side):
M2 D0 D1 D2 D3 D4 D5 D6 D7 A0 A1 /IRQ A2 A12 A13 A14 PPUA11 PPUA12 gnd R/W /ROMSEL PRGA13 PRGA14 PRGA15 PRG/OE CHRA11 CHRA12 CHRA13 CHRA14 CHRA15 CHRA16 CHRA17 PRG/CE +5V
I was going to say that I didn't know of any mappers that had a register mask of $F007, but...
mohle wrote:
What i found out about the Dragon Ball module: It should be a Mapper 91 Card!
Well, if so, you should be able to do something like this:
Code:
board <- {
mappernum = 91,
vram_mirrorfind = true,
ppu_ramfind = false,
cpu_rom = {
size_base = 0x4000,
size_max = 0x20000,
banksize = 0x2000,
},
ppu_rom = {
size_base = 0,
size_max = 0x20000,
banksize = 0x800,
}
};
function cpu_dump(d, banks, bank_size)
{
for (local i=0; i < banks-1; i++) {
cpu_write(d, 0x7000, i);
cpu_read(d, 0x8000, bank_size);
}
cpu_read(d, 0xE000, bank_size);
}
function ppu_dump(d, banks, bank_size)
{
for (local i=0; i < banks; ++i) {
cpu_write(d, 0x6000, i);
ppu_read(d, 0x0000, bank_size);
}
}
(caveat: don't have a kazzo, can't test above code)
In general, dumping carts with unknown mappers is hard. One usually has to start off with an NROM dump and load it in a debugging emulator and look for register writes, then try recapitulating those same writes to the hardware.
Sometimes the original authors made that harder with lots of misleading writes to memory that didn't actually do anything, and copying things from ROM to RAM and decrypting them; e.g. kevtris has a writeup about one that he actually had to single-step through execution using his CopyNES to find out how the hardware worked.
