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

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
zxbdragon
Posts: 498
Joined: Mon Dec 12, 2011 8:15 pm

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

Post by zxbdragon »

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
Chuugoku Taitei (Sachen)_001.png
Chuugoku Taitei (Sachen)_001.png (8.25 KiB) Viewed 7863 times
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

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.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

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

Post by koitsu »

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.
zxbdragon
Posts: 498
Joined: Mon Dec 12, 2011 8:15 pm

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

Post by zxbdragon »

Thank you lidnariq and koitsu!
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

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

Post by NewRisingSun »

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:

Code: Select all

.... ..CN
C: CHR data source for PPU $0000-$0FFF
    0: CHR-ROM from MMC3
    1: CHR-RAM
N: Nametable data source
    0: Console CIRAM, two pages, MMC3 mirroring
    1: Cartridge RAM, four pages
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.
zxbdragon
Posts: 498
Joined: Mon Dec 12, 2011 8:15 pm

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

Post by zxbdragon »

NewRisingSun wrote: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:

Code: Select all

.... ..CN
C: CHR data source for PPU $0000-$0FFF
    0: CHR-ROM from MMC3
    1: CHR-RAM
N: Nametable data source
    0: Console CIRAM, two pages, MMC3 mirroring
    1: Cartridge RAM, four pages
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!
Attachments
Chuugoku Taitei (Sachen)_001.png
Chuugoku Taitei (Sachen)_001.png (12.7 KiB) Viewed 6873 times
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

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

Post by NewRisingSun »

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.)
Attachments
mapper243.cpp
(2.1 KiB) Downloaded 196 times
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

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

Post by Quietust »

NewRisingSun wrote: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.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

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

Post by NewRisingSun »

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?
Attachments
mapper243.cpp
(1.66 KiB) Downloaded 195 times
zxbdragon
Posts: 498
Joined: Mon Dec 12, 2011 8:15 pm

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

Post by zxbdragon »

NewRisingSun wrote: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.
Chuugoku Taitei (Sachen)_001.png
Chuugoku Taitei (Sachen)_001.png (11.58 KiB) Viewed 6829 times
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

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

Post by Quietust »

NewRisingSun wrote: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?
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.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

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

Post by NewRisingSun »

Quietust wrote:Savestates will automatically detect how much RAM to include - they stop once they encounter uninitialized data.
Okay. So does the CHR RAM field of the NES 2.0 header get used outside the mapper DLL?
Quietust wrote: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.
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.
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

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

Post by Quietust »

NewRisingSun wrote:So does the CHR RAM field of the NES 2.0 header get used outside the mapper DLL?
Yes - it restricts the number of CHR RAM banks you can map (for NES 1.0 headers, the limit is set to 32KB).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
kazblox
Posts: 35
Joined: Thu Feb 23, 2017 2:27 pm

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

Post by kazblox »

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