It is currently Wed Oct 18, 2017 9:31 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Tue Jul 05, 2016 3:11 am 
Offline
User avatar

Joined: Sun Jun 05, 2016 1:41 pm
Posts: 74
So far I seem to have a decent implementation of Mapper 16 (Bandai FCG), and was able to run Dragon Ball Z - Kyoushuu! Saiya Jin (Japan) without problems.

However, when loading Datach - Dragon Ball Z - Gekitou Tenkaichi Budou Kai (J), which also uses Mapper 16, the graphics are garbled. This appears to be some Bandai FCG variant. Is it the case that perhaps this ROM should be assigned a different mapper id?

_________________
Tile IDE and tile engine for XNA: http://tide.codeplex.com/
Fancy Fish Mod - Minecraft Mod: http://fancyfishmod.weebly.com/


Top
 Profile  
 
PostPosted: Tue Jul 05, 2016 4:42 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
colinvella wrote:
However, when loading Datach - Dragon Ball Z - Gekitou Tenkaichi Budou Kai (J), which also uses Mapper 16, the graphics are garbled.

My copy of that ROM image is mapper 157 (which I apparently don't support), not 16.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
PostPosted: Tue Jul 05, 2016 5:37 am 
Offline
User avatar

Joined: Sun Jun 05, 2016 1:41 pm
Posts: 74
On the Bigass Nesmapper List (http://tuxnes.sourceforge.net/nesmapper.txt) it is listed under mapper 16, but I suspect it should really run on an FCG variant like 153.

EDIT: It runs just fine on Nestopia. I suspect I'm missing something, perhaps the implementation of a register for higher character or program bank bits. The code seems to be running, so PRG bank switching doesn't seem to be the issue. Then again, this ROM doesn't have a CHR bank defined and, I think, it copies characters off the PRG rom into CHR ram.

_________________
Tile IDE and tile engine for XNA: http://tide.codeplex.com/
Fancy Fish Mod - Minecraft Mod: http://fancyfishmod.weebly.com/


Top
 Profile  
 
PostPosted: Tue Jul 05, 2016 10:12 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
The FCG boards are unique in that the games that use CHR-RAM (i.e. Datach *, Famicom Jump 2) instead of CHR-ROM don't support banking of that RAM.

People who can't read Japanese and so don't care about saving is probably the biggest problem in conflating the five different FCG1/2/LZ93D50 boards. (Followed by the point above)


Last edited by lidnariq on Tue Jul 05, 2016 10:17 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Tue Jul 05, 2016 10:13 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
Nestopia fixes NES headers and ignores the specified header.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 1:34 am 
Offline
User avatar

Joined: Sun Jun 05, 2016 1:41 pm
Posts: 74
Dwedit wrote:
Nestopia fixes NES headers and ignores the specified header.


Does that mean that Nestopia identifies specific game roms and switches to some other mapper? What should the proper mapper be for Datach DBZ in this case?

_________________
Tile IDE and tile engine for XNA: http://tide.codeplex.com/
Fancy Fish Mod - Minecraft Mod: http://fancyfishmod.weebly.com/


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 2:45 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
colinvella wrote:
Dwedit wrote:
Nestopia fixes NES headers and ignores the specified header.


Does that mean that Nestopia identifies specific game roms and switches to some other mapper? What should the proper mapper be for Datach DBZ in this case?

Some clarification: Nestopia doesn't actually *fix* NES headers, it simply has a gigantic database of ROM CRCs and SHA1s that act as "overrides" for some aspects of what the NES header may contain. These are either bad dumps, old dumps, or correct dumps that have incorrect headers (some may have been correct at the time of dumping, but as emulation became more precise, this showed a new mapper was needed, etc.).

This database is what Options -> Database -> Internal refers to. You can uncheck the box and it'll disable doing any kind of overrides. (Options -> Database -> External allows you to refer to a replacement NstDatabase.xml, i.e. possibly one with fixes or is newer than the version that came with Nestopia (keep reading)).

You can always check what Nestopia "decides" to use (for mapper, capabilities, etc.) by toggling that checkbox and looking at View -> Image Info.

The database itself is an .xml file called NstDatabase.xml (warning: web page very large + lots of post-processing done via JS/CSS on GitHub, so page may take a long time to load). I suggest opening up the ROM, getting the CRC out of View -> Image Info, then grepping/searching for that CRC (case-insensitive) in the .xml file; you can double check to make sure it's the correct match by examining the SHA1 too. It should become apparent what the "overrides" are simply by looking at it (in most cases; in other, more obscure cases, it isn't immediately apparent without looking deeper at the code).

So whenever talking about a game/ROM, it's basically mandatory at this point that you give a CRC, SHA1, or MD5 along with the filename. Just saying "Herpy Derpy Adventure Butts 4" isn't accurate enough -- case in point.

Odds are the ROM you have may be old/have "outdated" headers that a newer GoodNES set has since fixed/addressed. I myself just went through the pain of using GoodNES on a romset, repairing something like over 1100 mistakes (between years 2006 and 2016). This thread is a good example of what happens, particularly this post of mine.


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 2:55 am 
Offline
User avatar

Joined: Sun Jun 05, 2016 1:41 pm
Posts: 74
That's a very informative reply, thanks! I always suspected that some emulators work at the individual ROM level but I was ignorant of the details.

Here's my Image Info dump:
Quote:
File: Datach - Dragon Ball Z - Gekitou Tenkaichi Budou Kai (J).zip <Datach - Dragon Ball Z - Gekitou Tenkaichi Budou Kai (J).nes>
Directory: (redacted)
Soft-patched: No
CRC: 19E81461
SHA-1: 87478B635FEFB25FA13C4876E20F505A97426C1B
System: Famicom
Board: BANDAI DATACH JOINT SYSTEM, Mapper 157
PRG-ROM: 256k
V-RAM: 8k
Battery: No
Dump: Unknown


It appears that Datach DBZ is reassigned to the Mapper 157 (Bandai Datach Joint System)

_________________
Tile IDE and tile engine for XNA: http://tide.codeplex.com/
Fancy Fish Mod - Minecraft Mod: http://fancyfishmod.weebly.com/


Top
 Profile  
 
PostPosted: Wed Jul 06, 2016 7:03 am 
Offline
User avatar

Joined: Sun Jun 05, 2016 1:41 pm
Posts: 74
SOLVED :)

I implemented CRC computation of the ROM and started implementing a rudimentary system of header overrides (hardcoded for now). I also implemented support for the Datach Joint ROM System variant, that essentially ignores the banking registers and treats the address range under $2000 as a flat CHR RAM. The DBZ graphics now look OK, but obviously the game needs barcode support to be playable.

_________________
Tile IDE and tile engine for XNA: http://tide.codeplex.com/
Fancy Fish Mod - Minecraft Mod: http://fancyfishmod.weebly.com/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group