Castlevania 3 graphics missing or garbled

[KevinGoodsell]

Castlevania III has serious graphical glitches. Tested with the USA and Europe versions and they looked very similar. The Japanese version appears to be fine.

The intro screens with the film scrolling effect appear normal, the title screen is mostly OK but has a large black area where most of the title should be. The name entry screen is fine, and the beginning screen that shows the character kneeling at an altar also looks fine, but once game play starts many of the sprites and background tiles are just missing. The player character isn't drawn at all, though the whip is visible when it is used.

ROM MD5s for reference:

e5ed68ca92ca3c5c7a1e5c35001a7f45 Castlevania III - Dracula's Curse (USA).nes 716084ccd006ecb4cdd171d2dbb9df08 Castlevania III - Dracula's Curse (Europe).nes

I suspect this is an MMC5 issue, since the USA & Europe releases used that chip while the Japanese release did not. I tried testing other MMC5 games, but most of them are either strategy games that make no sense to me, or are Japanese games that I can't make progress in. The one other MMC5 game that I was able to meaningfully test was Laser Invasion, which also shows graphical problems. Specifically, the helicopter on the title screen (shown rather briefly) is partly garbled, the graphics on the missile type selection screen appear garbled, and during game play no projectiles are visible, and the targeting reticle is not drawn.

[SegaSnatcher]

Not experiencing these issues. I'm using 2.0 NES rom set.

Are you running latest NES core release?

Your rom might just have a bad header.

Information on my CV3 NA rom.

MD5: 561999DAA97A1C30C81CAB5142A1D672

SHA-1: 0BB28DD9C2F8DFABB3349D1F65407B941EE78435

[paulb-nl]

Probably the same as #193

Can you show the header information?

[KevinGoodsell]

It does look exactly like the screenshots in #193. I also confirmed that my SHA1 is the same as the one rgavril included in that issue. I thought I checked closed issues, but maybe I missed it.

I'm happy to provide header information, but I'm not sure how to usefully do that. I could provide a hex dump of the headers if that's useful.

Curiously I happened to be working on a script to categorize and organize NES roms and have checked all of my roms against two different databases and looked for discrepancies, I'm fairly sure that I found no problems with these. But I think that would only confirm that the rom bytes are accurate, and some (but not all) of the header info.

I can look into this more tomorrow, including adding any details and examining the headers myself. Thank you.

[paulb-nl]

You can load the game in Mesen and then Tools->Log window will have all the information. You can change the header with Debug->Edit iNes header.

Here is what I get:

File CRC32: 0x7CC9C669

[DB] Initialized - 15541 games in DB
PRG CRC32: 0x95CA9EC7
PRG+CHR CRC32: 0xED2465BE
[iNes] Mapper: 5 Sub:0
[iNes] PRG ROM: 256 KB
[iNes] CHR ROM: 128 KB
[iNes] Mirroring: Horizontal
[iNes] Battery: No
[DB] Game found in database
[DB] Mapper: 5  Sub: 0
[DB] System : NesNtsc
[DB] Board: NES-ELROM
[DB] Chip: MMC5
[DB] PRG ROM: 256 KB
[DB] CHR ROM: 128 KB
[DB] Battery: No
[DB] Database info will be used instead of file header.

[Kitrinx]

Please check https://github.com/Kitrinx/NES_Header_Repair to verify and repair your rom headers.

[KevinGoodsell]

I have a likely explanation for the issue. The nesdev wiki has this note about MMC5:

"The MMC5's EXRAM is not included in the CHR-RAM size, as it can be mapped by software to CPU, PPU, or no address space at all."

https://wiki.nesdev.com/w/index.php/NES_2.0

However, this Castlevania III ROM does in fact indicate 8 KiB of CHR-RAM (byte 11 is 0x07). The same is true of the Laser Invasion ROM that also has problems. I changed this field to 0, tested Castlevania III, and all of the observed graphical problems are gone.

The only possible case I can see for considering this a bug is if there's a choice between whether to trust the mapper or the CHR-RAM header when they are potentially in conflict. It seems like many emulators get this "right", so maybe it's worth handling in mister? But I won't be particularly bothered if you opt to close this bug.

Thank you.

[Kitrinx]

What many emulators do is completely ignore the header and use their own internal database instead. This is likely why they work while mister is having trouble with the incorrect header. I'm going to say it's not-a-bug as it stands. MiSTer relies on headers to be accurate to work. If you use that database and script I linked above it should repair that header and the others for you.