General Gunstar Heroes rambling

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Post Reply
OrangyTang
Interested
Posts: 29
Joined: Tue Feb 23, 2016 4:45 pm

General Gunstar Heroes rambling

Post by OrangyTang » 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?

Miquel
Very interested
Posts: 489
Joined: Sat Jul 30, 2016 12:33 am

Re: General Gunstar Heroes rambling

Post by Miquel » Wed Jan 01, 2020 12:50 pm

OrangyTang wrote:
Tue Dec 31, 2019 9:42 pm
Palettes are defined independently as 16 uncompressed colours, then referenced in palette sets which are just pointers to 4 palettes to load at once.
Makes sense that way, palettes can be loaded anytime. You can compress them do, there are unused bits, but bit manipulation is not cheap at cpu level.
OrangyTang wrote:
Tue Dec 31, 2019 9:42 pm
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;
By standard colors, do you mean static colors? They don’t change at all so can be used by any foe, for example.
OrangyTang wrote:
Tue Dec 31, 2019 9:42 pm
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.
I still think how Sonic games do is best: point the exception to ram, then do a jump to a procedure on rom (“jmp xxx.w” or “bra.w xxx”); this way “switch” is still avoided and no precious ram is wasted.
OrangyTang wrote:
Tue Dec 31, 2019 9:42 pm
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.
Is there ONLY one call of the RNG per frame? It seems a little silly since two foes sync on frame will do exactly the same action, with so many foes on screen...
OrangyTang wrote:
Tue Dec 31, 2019 9:42 pm
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.
I suppose you mean a jump table to the “IA” of entities. That could be done with a “function pointer” per entity too.
Help. Spanish TVs are brain washing people to be hostile to me.

OrangyTang
Interested
Posts: 29
Joined: Tue Feb 23, 2016 4:45 pm

Re: General Gunstar Heroes rambling

Post by OrangyTang » Wed Jan 01, 2020 3:49 pm

Miquel wrote:
Wed Jan 01, 2020 12:50 pm
By standard colors, do you mean static colors? They don’t change at all so can be used by any foe, for example.
Yes they're static and don't change for the whole game - at least during regular gameplay. Title screen, cutscenes and oddball gameplay (the scrolling shooter section) do their own thing.
Miquel wrote:
Wed Jan 01, 2020 12:50 pm
I still think how Sonic games do is best: point the exception to ram, then do a jump to a procedure on rom (“jmp xxx.w” or “bra.w xxx”); this way “switch” is still avoided and no precious ram is wasted.
That's a pretty neat way of doing it, but you do have an extra jump. The 2kb buffer seems carefully chosen - the biggest h-interupt routine is exactly 2kb of code iirc.
Miquel wrote:
Wed Jan 01, 2020 12:50 pm
Is there ONLY one call of the RNG per frame? It seems a little silly since two foes sync on frame will do exactly the same action, with so many foes on screen...
It's ticked in the vsync every frame (except for loading frames when the display is black). Then called again before the value is actually used.
Miquel wrote:
Wed Jan 01, 2020 12:50 pm
I suppose you mean a jump table to the “IA” of entities. That could be done with a “function pointer” per entity too.
Yes, the actual entity logic / behaviour. I can't think of anything else that would require a jump table that big - the next biggest I've identified is the 'screen' table (intro/title/options/gameplay/etc.) and that's only 16-ish long. Annoyingly it's proving quite hard to track down where the entites are actually stored and initialised so I haven't really proved this.

Miquel
Very interested
Posts: 489
Joined: Sat Jul 30, 2016 12:33 am

Re: General Gunstar Heroes rambling

Post by Miquel » Sat Jan 04, 2020 10:53 pm

OrangyTang wrote:
Tue Dec 31, 2019 9:42 pm
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.
For some reason I just thought of it, the sprites of the two main characters/heroes are dynamically loaded, are those also dynamically decompressed?

If it's the case it will be very interesting to know how it's done.
Help. Spanish TVs are brain washing people to be hostile to me.

OrangyTang
Interested
Posts: 29
Joined: Tue Feb 23, 2016 4:45 pm

Re: General Gunstar Heroes rambling

Post by OrangyTang » Mon Jan 06, 2020 11:28 am

I haven't identified those graphics yet, but so far *all* graphics other than the SEGA logo are compressed in ROM.

I suspect the main characters will be loaded/unloaded as the game progresses, since there's an oddball scrolling-shooter level in the middle that uses completely different player sprites.

Miquel
Very interested
Posts: 489
Joined: Sat Jul 30, 2016 12:33 am

Re: General Gunstar Heroes rambling

Post by Miquel » Mon Jan 06, 2020 3:22 pm

By dynamically loading I mean that, when the sprite changes, its tiles are loaded from rom to ram the previous frame, the space of vram that occupies the sprite is always the same. The idea is to have large animations for the main character, which is the most repetitive one, so can lead to visual sadness, without wasting much vram; since bandwidth is pretty good usually most games do this technic.

You can check with a vdp debugger that “Gunstar Heroes” uses it too.
Help. Spanish TVs are brain washing people to be hostile to me.

Post Reply