Sansuu 3 - CNROM / Mapper 185 question

[etabeta]

Hi,

I've just implemented in MESS Mapper 185 (i.e. CNROM + diodes to handle CHR banking), and I found a small problem with Sansuu 3.

According to the old discussions of this forum, at start the games of this mapper write two values as a protection trick to test CHR banks. values are the following

Off On Title
F0h 0Fh Bird Week
00h 33h B-Wings
00h 11h Mighty Bomb Jack
20h 22h Sansuu 1 Nen - Keisan Game
20h 22h Sansuu 2 Nen - Keisan Game
00h FFh Sansuu 3 Nen - Keisan Game
13h 21h Spy vs Spy

Following Nestopia, I implemented the presence of the pin as a mask (0x03) which compares the written data with the pin CE-/CE state.

as the table above shows, the code should work as follows:

Code: Select all

if ((data & pin_mask) != pin_state)  -> next CHR read returns open_bus;
else -> next CHR read returns chr_data

this works fine with all the games but Sansuu 3 (I'm using the dump confirmed as good in bootgod's db), which in my emu writes 20h 2ah instead of the 00-ff in the table.

the problem is that according to bootgod xml db this game has both pins set to CE, hence the second write 0x2a does not meet the required condition and open_bus is returned in place of CHR.

I would like to know how the game behaves in your emulators (I'm on MacOSX so I cannot directly test most of the emus), because I can only see three reasons for the behavior I see in MESS:

1. the pin settings in Bootgod's db are wrong (pin 26 should be /CE not CE), so the mask has to be corrected (this would fix Sansuu 3 in MESS, and it's currently what I'm doing to workaround the problem)
2. my emu writes the wrong values (i.e. 0x00-0xff in the table are correct), but it seems strange to me that this only game shows this problem
3. Bootgod is correct, but the pin settings do not exactly work as previous research assumed

I strongly hope the answer is not 3, because it seems strange that a 'simple' PCB like CNROM needs a more complicate implementation for these pins.

Thanks in advance for the help

[Dwedit]

There might be a bus conflict. What address is written to, and what's the data at that address?

[etabeta]

I hadn't thought to bus conflict (because the old mapper 185 discussion claimed the game writes to addresses which would not suffer conflicts), however it seems the problem is not bus conflict:

1st write: 0 to 0x805c (value in memory: 0)
2nd write: 2a to 0x805d (value in memory: 2a)

on the other hand, I managed to get a copy of the old Sansuu 3 dump (the one in GoodNES) and it writes 0x00 and then 0xff as the old table...

in other words, there is also some chance that the old dump (98DC1099) had simply a different behavior compared to the new dump (87DA4BD0). I think I will ask Bootgod if he can re-check the pin settings of the cart he dumped: it might be that the CE-CE choice had been made based on the old dump and he hadn't verified it when he redumped it!

or is MESS the only emu to write different values than the ones reported by the table?

p.s. checksums above are calculated without header, for 128k=0x20000 long files

[BootGod]

I'll check it out for you, just need to find the cart first....

[BootGod]

It's like you figured, pin 26 was wrong should be:

pin 26 = /CE
pin 27 = CE

I used to have to enter that pin stuff by hand, so I guess I'm not surprised I mistyped one. I later made it so the CNROM plugin sends some special data back gathering this info for you.

[etabeta]

oh great! thanks for checking.