Chuugoku Taitei (Sachen).nes is bad dump? emu bug?

File: Chuugoku Taitei (Sachen).nes
Directory:
Soft-patched: No
CRC: 037006F7
SHA-1: C0BABB7AA3D15F3FC66E017CD923C34EEDA22C33
System: NES-NTSC
Board: mapper 4?? mm3?
PRG-ROM: 256k
CHR-ROM: 128k

In GoodNES, the board is marked as Mapper 116 (Huang-1), but in emulation, the game seems to rely on
1- having RAM, unlike what http://wiki.nesdev.com/w/index.php/INES_Mapper_116 says, and
2- the register at $4100 mapping 0 to MMC3-like behavior, and
3- switching between mapper modes during runtime.

I think it's more likely bad emulation, due to insufficient documentation.

Agreed with lidnariq -- this looks more like incorrect emulation of a mapper. especially since the CHR data shown that's garbled happens at a specific scanline.

Reverse-engineering of the ROM, and/or having the actual cart/board, would be needed here.

Thank you lidnariq and koitsu!

Results from debugging:

• Extended register at $4100
• Battery-backed WRAM at $6000
• MMC3 at $8000-$FFFF
• At least 4K of CHR-RAM in addition to CHR-ROM, used for Chinese text
• Four pages of additional nametable RAM, used for the playboard but not the status bar

Extended register bits:
When C=1, N seems to be ignored, i.e. register values 2 and 3 seem to behave identically.

I suppose no mapper number has been assigned for this yet.

this mapper irq It may not seem like standard MMC3

Your proposal and I code as before

status bar is bug!

The status bar will become corrupt as the playboard scrolls if you don't keep the console CIRAM and the four additional nametable pages separate. Attached is my WIP Nintendulator source, which does not show a corrupt status bar. (I temporarily reused mapper number 243.)

Remark: you aren't saving ExNameTable, which will cause Problems once you start using savestates. A much better option is to simply use SetCHR_RAM - version 0.975 provides 256KB, and even 0.970 provides 32KB.
Also, modes 2 and 3 leave PPU $1000-$1FFF uninitialized, which probably isn't what you want.

Like this? I'm not that familiar with the save/load interface. From where does it know how much CHR RAM to save, in particular in the absence of a NES 2.0 header?

thank you! case 1 exnmt.working in nestopia.

CHRRAM save,but ines 2.0 emu not woking save.

Savestates will automatically detect how much RAM to include - they stop once they encounter uninitialized data.

The logic you currently have is mapping the first 4KB of CHR RAM to both $0000-$0FFF and $1000-$1FFF for modes 2 and 3, and the second 4KB to the nametables in mode 1. It wasn't fully clear from the prior description if that's how it's supposed to work.

Okay. So does the CHR RAM field of the NES 2.0 header get used outside the mapper DLL?Remember that this is all based on debugging the game and tweaking the mapper emulation code until no more glitches are observable. I don't have the cartridge itself, so I cannot say how the cartridge hardware works internally. As a result, because it seems to make no difference for the game what PPU $1000-$1FFF maps to in modes 2 and 3, my description was necessarily lacking on this aspect.

Yes - it restricts the number of CHR RAM banks you can map (for NES 1.0 headers, the limit is set to 32KB).

This looks A LOT like a heavy extension of the Street Heroes board. It even has the same extended register.