In the vein of HorvatM’s tool, I’ve created a Python tool that can take Bitmaps and convert them to a graphical format that the VB expects.
For an attempt at authenticity, I want the output to be similar to SCR2C.EXE and CGX2C.EXE. Since Nintendo didn’t provide source for these tools, I have a few questions regarding them for those who may be familiar with their use and origin.
So far, I’ve determined that they were compiled using Borland C and are just generic array generators so to speak. I have not figured out what .SCR and .CGX represent, other than they appear to be related to a poorly-documented tool called SGC-CAD. There is NOT a one-to-one correspondence between the output C files and the actual data for the .CGX file, but there is a partial one-to-one correspondence between the C array and the binary data for the .SCR file I examined. In both cases, I found the following string embedded in the assets:
NAK1989 S-CG-CADVer1.11 930511 F
930511 is obviously a date code for May 11, 1993. The string appears to also be found in some official SNES games as well. However, in that case, the string is embedded in the ROM itself, as opposed to the assets. Does anyone more familiar with Nintendo development kits have some backstory on these tools?
I also have questions re: the output of GCX2C and SCR2C themselves, again for authenticity :P. For convenience I’ve provided snippets. First up is the character table from the sample software. Nothing really fancy/notable here. Each tile is commented for convenience. Curiously however, the second line of comments is missing.
/*<<<<<<<<<< CG DATA from SCG-CAD CGX2C.EXE ver2.0 Nintendo R&D1 >>>>>>>>>>*/
short cgx_sample[] = {
0x0000,0x3FF0,0xF03C,0xFC3C,0xF33C,0xF0FC,0xF03C,0x3FF0, /* (0x000) */
0x0000,0x03C0,0x03F0,0x03C0,0x03C0,0x03C0,0x03C0,0x0FF0, /* (0x001) */
0x0000,0x3FF0,0xF03C,0xF03C,0x3C00,0x0FC0,0xC0F0,0xFFFC, /* (0x002) */
0x0000,0x3FF0,0xF03C,0xF000,0x3FC0,0xF000,0xF03C,0x3FF0, /* (0x003) */
0x0000,0x3FC0,0x3CF0,0x3CF0,0x3C3C,0x3C3C,0xFFFC,0x3C00, /* (0x004) */
0x0000,0x3FFC,0x003C,0x003C,0x3FFC,0xF000,0xF03C,0x3FFC, /* (0x005) */
0x0000,0x3FF0,0x003C,0x003C,0x3FFC,0xF03C,0xF03C,0x3FF0, /* (0x006) */
0x0000,0xFFFC,0xF03C,0xF03C,0x3C00,0x0F00,0x0F00,0x0F00, /* (0x007) */
0x0000,0x3FF0,0xF03C,0xF03C,0x3FF0,0xF03C,0xF03C,0x3FF0, /* (0x008) */
0x0000,0x3FF0,0xF03C,0xF03C,0xFFF0,0xF000,0xF03C,0x3FF0, /* (0x009) */
0x00C0,0x00F0,0x3FFC,0x3FFF,0x3FFC,0x00F0,0x00C0,0x0000, /* (0x00A) */
0x0300,0x0F00,0x3FFC,0xFFFC,0x3FFC,0x0F00,0x0300,0x0000, /* (0x00B) */
0x00C0,0x03F0,0x0FFC,0x3FFF,0x03F0,0x03F0,0x03F0,0x0000, /* (0x00C) */
0x03F0,0x03F0,0x03F0,0x3FFF,0x0FFC,0x03F0,0x00C0,0x0000, /* (0x00D) */
0x0000,0x03C0,0x03C0,0x0000,0x0000,0x03C0,0x03C0,0x0000, /* (0x00E) */
0x0000,0x0000,0x0000,0x0000,0x03C0,0x0300,0x00C0,0x0000, /* (0x00F) */
On the other hand, the BG (or SCR data as they call it), has some interesting properties. In particular, the comments denoting the offset from the background start suggest that each 32 tiles are interleaved with data that is 1kB apart when loaded into BG memory, but I can’t find any code snippets in the sample software to suggest this is the case. Does anyone have an idea as to what addresses the comments represent, and why they may be interleaved? An address interleave of 32 doesn’t even make sense, since BG segments must be at least 64 tiles in height/width.
Additionally, what in the WORLD is up with that second line of comments XD? It looks like DOS gave up and decided to print out whatever it felt like (note I pasted this using Code Page 437. What does Japanese MS-DOS use)?
EDIT: I needed to use Shift-JIS encoding. The translation/proper glyphs on the second line can be found here: http://goo.gl/SzHhLa
/*<<<<<<<<<< SCR DATA from SCG-CAD SCR2C.EXE ver2.5 by Nintendo R&D1 >>>>>>>>>>*/
/* ìsÉö(64) ÆΩÅπé░(0) */
short scr_saru_bg[] = {
0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF, /* 0x0000 */
0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,
0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x02F5,0x03FF,
0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,
0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF, /* 0x0400 */
0x03FF,0x03FF,0x0280,0x0281,0x0282,0x03FF,0x03FF,0x03FF,
0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,
0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,
0x03FF,0x02F3,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF, /* 0x0020 */
0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x02FA,0x03FF,
0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,
0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x02F4,0x03FF,
0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF, /* 0x0420 */
0x03FF,0x0283,0x0284,0x0285,0x0286,0x03FF,0x03FF,0x03FF,
0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,
0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,0x03FC,
0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF,0x03FF, /* 0x0040 */
Additionally, I find it curious that the arrays generated aren’t const-qualified. I know from experience that gccVB will run out of RAM space quickly if you don’t const-qualify data. For those who have used VUCC, does VUCC expect array data to be stored in ROM to be const-qualified?
Perhaps a disassembly is in order…
