[felineki]

Hi, I've been studying Capcom's CPS2 arcade system. From looking at the MAME driver I can tell that each region of the graphic ROM is formed by interleaving four separate files. Meaning in order to get something I can edit, I need to create a merged file that starts with the first two bytes of the first file, then the first two bytes of the second file, then the first two bytes of the third file, then the first two bytes of the fourth file, then the second two bytes of the first file... etc. I'll also have to split that end result back into the separate files once I'm done with the editing in order to make it run in the game. I've tried looking for a tool that can do this for me, but have yet to have any luck. Any suggestions or recommendations as to how to go about doing this? Thanks!

[UglyJoe]

There's a simple joiner here: http://www.romhacking.net/forum/index.php/topic,10979.msg168315.html

[felineki]

Thanks, I'll try it out.

EDIT: It doesn't seem to be doing quite what I want. It's overwriting bytes rather than adding them.

Let's say my two base files are like this:

File 1: 1234
File 2: ABCD

The program you linked to seems to be giving me this: 1B3D

What I want is this: 1A2B3C4D

There's also the problem of how to split the merged file back into its former parts once editing is done.

EDIT2: I seem to have found a program that will do the interleaving here. That still leaves the problem of splitting the merged file, and whether or not I can actually get the merged file to work properly in a graphics editor.

[Ryusui]

It'd be simple enough to write your own in Visual Basic or something. The BinaryReader class is your friend.

[felineki]

I don't have any programming experience, but I suppose I should look into it eventually. I'm also not having any luck with getting my merged file to display properly in a graphic editor, so I'm not getting anywhere fast.
September 04, 2011, 09:09:25 pm - (Auto Merged - Double Posts are not allowed before 7 days.)I changed the thread title to reflect the greater overall topic, since there seems to be more going on here.

Anyway, let's take Night Warriors (romset nwarr) as an example. Looking at the MAME driver, it says this:

ROM_REGION( 0x2000000, "gfx", 0 )
ROMX_LOAD( "vph.13m",   0x0000000, 0x400000, CRC(c51baf99) SHA1(2fb6642908e542e404391eb17392f8270e87bf48) , ROM_GROUPWORD | ROM_SKIP(6) )
ROMX_LOAD( "vph.15m",   0x0000002, 0x400000, CRC(3ce83c77) SHA1(93369b23c6d7d834297434691bb047ee3dd9539c) , ROM_GROUPWORD | ROM_SKIP(6) )
ROMX_LOAD( "vph.17m",   0x0000004, 0x400000, CRC(4f2408e0) SHA1(cd49c6b3c7e6470c6058f98ccc5210b052bb13e2) , ROM_GROUPWORD | ROM_SKIP(6) )
ROMX_LOAD( "vph.19m",   0x0000006, 0x400000, CRC(9ff60250) SHA1(d69ba4dc6bd37d003245f0cf3211d6e2623005b8) , ROM_GROUPWORD | ROM_SKIP(6) )
ROMX_LOAD( "vph.14m",   0x1000000, 0x400000, CRC(7a0e1add) SHA1(6b28a91bd59bba97886fdea30116a5b1071109ed) , ROM_GROUPWORD | ROM_SKIP(6) )
ROMX_LOAD( "vph.16m",   0x1000002, 0x400000, CRC(2f41ca75) SHA1(f4a67e60b62001e6fe75cb05b9c81040a8a09f54) , ROM_GROUPWORD | ROM_SKIP(6) )
ROMX_LOAD( "vph.18m",   0x1000004, 0x400000, CRC(64498eed) SHA1(d64e54a9ad1cbb927b7bac2eb16e1487834c5706) , ROM_GROUPWORD | ROM_SKIP(6) )
ROMX_LOAD( "vph.20m",   0x1000006, 0x400000, CRC(17f2433f) SHA1(0cbf8c96f92016fefb4a9c668ce5fd260342d712) , ROM_GROUPWORD | ROM_SKIP(6) )

This seems to say that the first 16MB of graphics data are made from the odd-numbered ROM files, and the next 16 from the even-numbered ROM files. Also that each of these 16 MB sections is composed of interleaved 2-byte chunks from its 4 composite files. Hence the original question in this topic.

But when I go into MAME and look at the "gfx" region in the memory viewer, it seems to be something completely different from the contents of the raw ROMs as viewed in a hex editor:

MAME Memory Viewer VS. Hex Editor

After looking closely, the data in the MAME memory viewer seems to correspond directly to the actual graphics as seen in the tileviewer, but I can't for the life of me figure out what the relation between it and the base ROMs is.

[felineki]

Well, after doing some more research and experimenting, I seem to have the graphics opening properly in Tile Molester.  Once I get a couple more things figured out, I'll show how to get it working.

EDIT: In general, here's how it seems to work:

The typical game has 8 graphics ROMs, labeled 13-20. The first half of the graphic data is formed from the odd-labeled ROMs, the second half is formed from the even-labeled ROMs.

Each of those halves are composed of chunks 1,048,576-bytes long, which alternate between the even and odd words of the ROMs composing them. Meaning that the first 1,048,576 bytes of graphics data is composed of the first 524,288 even words of the associated ROMs, the second 1,048,576 bytes is composed of the first 524,288 odd words of the associated ROMs, the third 1,048,576 bytes is composed of the second 524,288 even words of the associated ROMs... etc.

Within each of those chunks, words from two of the associated base ROMs are interleaved for each 8x8 subtile (64 bytes). The ROMs read from alternate between each subtile. Meaning the first subtile is comprised of interleaved words form the first two of the four associate ROMs, the next tile is comprised of interleaved words from the second two of the four associate ROMs. So, for example, the very first subtile would be comprised of alternating words from ROMs 13 and 15, the second would comprised of alternating words from ROMs 17 and 19, the third would switch back to alternating words from ROMs 13 and 15... etc.

So to get the graphics loading in Tile Molester you need to follow these 5 easy (?) steps:

1. Split each base ROM into its even and odd words.
2. Interleave these on a word basis into eight files: The 13-15 evens, the 13-15 odds, the 17-19 evens, the 17-19 odds, the 14-16 evens, the 14-16 odds, the 18-20 evens, and the 18-20 odds.
3. Interleave each half's evens together and each half's odds together, both on a 64-byte basis. You should now have four files: the 13-15-17-19 evens, the 13-15-17-19 odds, the 14-16-18-20 evens, and the 14-16-18-20 odds.
4. Interleave each half's odds and evens with each other on a 1,048,576-byte basis: You should now have two files, the 13-15-17-19 and the 14-16-19-20.
5. Append the latter to the former.

The file should now open in Tile Molester with the following settings: 4bpp planar codec, row-interleaved.

NOTE that this will only work for the 16x16 tiles. There are also 8x8 and 32x32 tiles stored in the same data, but working with those will likely require another method.

...Whew! 

EDIT: Corrected a mistake: The graphics alternate between even and odd words on a megabyte (1,048,576 bytes) basis, not 8192-byte. The latter number is the amount of tiles in a megabyte of data, I confused it for the amount of bytes. Sorry about that.

EDIT AGAIN: Somehow I overlooked the switching between ROMs from tile to tile... Man, with how clumsy I am about this stuff it's a miracle I got it working at all. But now that I've run through everything again it SHOULD work as written. *Crosses fingers*

[Nightcrawler]

Sounds like good material for some documentation to preserve the information. This forum topic/post will be buried when it's no longer active, and eventually be lost.