ASM Sonic the Fighters - Disassembly (and discoveries from it)

Not really. There's a lot yet to be understood about the makeup of characters, so skeleton data is a little weird, especially because the type definition for the skeletons seem to be "Not-Bark" or "Bark" which doesn't make all that sense to me so far.

 

It has literally taken me this long to find where the used credits are stored. The unused credits have routines which share the same ROM space as the end-of-game cutscene... the used credits, however are stored in the "draw_vs_routines" where things like "YOU LOSE" or "GAME OVER" or "CHALLENGER COMES" routines get drawn...

 

This is what happens when you give Bark the "Not-Bark" skeleton lmao

 

To be perfectly honest, I don't think the skeleton data itself is a mystery anymore. I just don't understand where the data that forms the skeletons is pulled from.

 

It's 100% related. The model handling aspects between the entire generation of Sega's Model2 hardware are identical. Skeleton and animation data are extractable from House of the Dead, however I don't understand where that information is pulled in Sonic the Fighters.

 

In insanely massive news, I've started investigating the PS3 executable which is used to emulate Sonic the Fighters and lo and behold, it contains source level labels for functions/subroutines. And just moments ago, I discovered that it also indicates where these labels go. A massive update is going to happen to the disassembly in a bit, but it's going to take a little time to implement.

 

Well, to be honest, I don't know the PS3 version that well. As discussed a long time ago, the PS3/X360 versions both use the Japanese Sonic the Fighters base ROM for the game's program data. My theory was that the emulator altered the code in memory, but upon memory dumping in a PS3 emulator, the size of the ROM is shrunk, data is seemingly removed and inserted, and you can't plug it into a model2 emulator because it's riddled with invalid 80960 instruction codes (something the official emulator bizarrely ignores). I'm very curious as to how the changes work, Honey's data being fixed and the character select screen stuff, but I don't have the knowledge or resources to scratch beneath just the surface of the official emulator code..

 

Well, yes, and this is something I have been trying to do on my own, as I've fixed Honey's squished parts and title cards. And while it wouldn't be hard to just create a routine that sees if we're at the character select screen, if the current character is Amy, and the start button is being held to give us Honey, the fact is we don't know how the PS3/360 version is doing it.

And while we know they patch the ROMs after the fact, seeing that the ROM in memory is not a valid (or even working) ROM is not very reassuring to detect what differences might have been patched into memory.

 

It was extremely frustrating to see the memory dump all garbled, but I'm not about to learn PS3 executable reverse engineering from the ground up just to figure out what it's doing lol. I feel like I could guess and get the right results before I reverse engineer to the point where I find out exactly how the PS3 ver does it, LOL!

 

I realize I've been very very slow to push the labels to the disassembly repo, it's been a tedious project. The labels which came from the Sonic the Fighters PS3 executable were a 1:1 address match to the data. However labels seemed to have been cherry picked at random, and do not contain all labels used in the source code. Virtua Fighter 2 and Fighting Vipers also have these labels, and I am meticulously comparing routines and functions to best add labels to the Sonic the Fighters disassembly for as much official documentation to exist as humanly possible. The StF disassembly now has over 1,000 official Sega labels in it, but there's still probably 1,000 labels left for me to manually comb through to see if they match Sonic the Fighters or not.

In related news, work on the Sonic the Fighters decompilation has begun. The disassembled code can now be built with GCC with an i960-elf target. The "main" and "main_loop" functions will be the first to be disassembled and once those produce 1:1 C equivalent code, the decompilation repo will be pushed to github.

 

I would not say that is a reasonable expectation to have, no. If and when I get main and main_loop decompiled, the entire rest of the binary will also need decompilation for that. This does not include audio or graphics handling, as the audio is handled by a separate processor and binary altogether while the graphics are handled by proprietary Fujitsu DSPs. Getting a decompilation running on anything, even PC, other than the i960 hardware it was designed for would require a monumental effort.

 

I have a few online backups of the IDA database, but I am really pushing to write an article about the discovery of the labels at the same time I push the updated disassembly.

I am terribly backlogged