General Gunstar Heroes rambling
Posted: Tue Dec 31, 2019 9:42 pm
A while back I started disassembing Gunstar Heroes, got busy and shelved it. Over xmas I had some time to chip away at it, so I thought I'd put out a post with some of the things I discovered.
In no particular order:
The 'SEGA' animation at the start generates multiple scaled copes of the logo on the CPU on start-up and animates between them. The original unscaled SEGA logo appears to be the only uncompressed graphics in the rom.
Palettes are defined independently as 16 uncompressed colours, then referenced in palette sets which are just pointers to 4 palettes to load at once.
Palette line 0 seems to be dedicated to the background and 'near camera' objects.
Palette line 1 is dedicated to the main forground plane.
Palette line 2 is standard colours plus P1 colours
Palette line 3 is more standard colours plus P2 colours.
Lines 0 and 1 are swapped out per level (or per sub-level) but 2 and 3 are always loaded;
A 2kb section of RAM (starting at 0xEE00) is set aside for horizontal interrupt code. The interrupt vector is statically set to EE00, and h-interrupt code is copied into the buffer as needed. There appears to be six different chunks of h-interrupt code but I haven't looked into which does what yet. Occasionally when there's no h-interrupt effect active, the code manually copies a RTE word into the buffer. I thought it was neat that rather than have a static h-interrupt code block with a switch statement they sacrificed some RAM to reduce the overhead as much as possible.
The total rom is exactly 1Mb, and has only 177 bytes of padding at the end. There seems to be very little 'dead' code or data, so I assume they kept optimising until they could fit the final game in a 1Mb cart.
As mentioned before ( viewtopic.php?f=2&t=2921 ) there's a custom decompression algorithm that can decompress to CPU or VDP, which seems to be mostly used for pattern data. I've found another separate decompression algorithm but I haven't figured out how it works or what it's used for yet. It seems to be some kind of RLE algorithm, but I'm not sure if it's a standard one. It seems to be used for tilemap data.
There's an RNG that ticks at least every v-sync, which seems identical to that found in the Sonic 3 / S&K disassembly. Oddly, the RNG seed seems to be identical except decremented by one.
There's a huge jump table with 400+ entries at 0x054C. It's tbe biggest jump table by far so I'm guessing it's the entity table.
The ROM is split exactly in half - the first 512kb is code, music and sfx and a little padding to 0x80000, the second half is all game data.
The sound driver code is identical to the one in Sonic 1.
There's also a lot of blocks of data that I'm identifying as code which the original Exodus active disassembly must have missed. I don't know if anyone can recommend a tool to translate data sections (dc.b defined values) into asm syntax?
In no particular order:
The 'SEGA' animation at the start generates multiple scaled copes of the logo on the CPU on start-up and animates between them. The original unscaled SEGA logo appears to be the only uncompressed graphics in the rom.
Palettes are defined independently as 16 uncompressed colours, then referenced in palette sets which are just pointers to 4 palettes to load at once.
Palette line 0 seems to be dedicated to the background and 'near camera' objects.
Palette line 1 is dedicated to the main forground plane.
Palette line 2 is standard colours plus P1 colours
Palette line 3 is more standard colours plus P2 colours.
Lines 0 and 1 are swapped out per level (or per sub-level) but 2 and 3 are always loaded;
A 2kb section of RAM (starting at 0xEE00) is set aside for horizontal interrupt code. The interrupt vector is statically set to EE00, and h-interrupt code is copied into the buffer as needed. There appears to be six different chunks of h-interrupt code but I haven't looked into which does what yet. Occasionally when there's no h-interrupt effect active, the code manually copies a RTE word into the buffer. I thought it was neat that rather than have a static h-interrupt code block with a switch statement they sacrificed some RAM to reduce the overhead as much as possible.
The total rom is exactly 1Mb, and has only 177 bytes of padding at the end. There seems to be very little 'dead' code or data, so I assume they kept optimising until they could fit the final game in a 1Mb cart.
As mentioned before ( viewtopic.php?f=2&t=2921 ) there's a custom decompression algorithm that can decompress to CPU or VDP, which seems to be mostly used for pattern data. I've found another separate decompression algorithm but I haven't figured out how it works or what it's used for yet. It seems to be some kind of RLE algorithm, but I'm not sure if it's a standard one. It seems to be used for tilemap data.
There's an RNG that ticks at least every v-sync, which seems identical to that found in the Sonic 3 / S&K disassembly. Oddly, the RNG seed seems to be identical except decremented by one.
There's a huge jump table with 400+ entries at 0x054C. It's tbe biggest jump table by far so I'm guessing it's the entity table.
The ROM is split exactly in half - the first 512kb is code, music and sfx and a little padding to 0x80000, the second half is all game data.
The sound driver code is identical to the one in Sonic 1.
There's also a lot of blocks of data that I'm identifying as code which the original Exodus active disassembly must have missed. I don't know if anyone can recommend a tool to translate data sections (dc.b defined values) into asm syntax?