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

The unused ice cubes have been restored with an unreferenced routine that sets up the stage!



The above is the area of data that sets up Aurora Icefield. The first "2" represents how many sets of setup routines should be processed for the stage.


But as we can see `aurora_nothing` (not an official label) just returns. But the code under that is unreferenced. By moving the pointer in the setup to offset 0x7561C instead of 0x75618, the routine which draws the ice cubes on the stage will properly activate!

 

Been a while, eh?



Recently discovered that the stage background music select routine has an oversight.

If Sonic is Player 1 and Knuckles is Player 2 (multiplayer), North Wind will play. The first check in this routine is if Sonic is player 1. If Player 1 isn't Sonic, it jumps down and checks... if Player 1 is Sonic and if Player 2 is Knuckles.... wait what?

In many instances where two players are checked against eachother, the check is always "fa_rob0" vs "fa_rob1" followed by the opposite check of "fa_rob1" vs "fa_rob0". In this case, values g7 and g8 in the lodb checks need to be swapped at 3F644 and 3F64C.

This is a very simple fix to allow North Wind to be play even if Knuckles is Player 1 and Sonic is Player 2.

 

I actually addressed this in the really old "Sonic Fighters Hacking" thread. At the time I thought this indicated another stage for mechless Eggman, but I think it's just an oversight and North Wind was just inserted and it bumped Hurry Up out of the playable list.

 

A year with no content? Sounds about right, anyway I am just gonna crosspost a tweet:
If you enter "HAC" as your initials after defeating the bonus boss, the initials will change to "894", or pronounceable in Japanese as the name "Hachikuji"

 

A little bit of a non-update, but previously the only way to build the Sonic the Fighters disassembly was to build my own version of GNU's binutils. It was a slightly tedious process and incredibly difficult to get Windows binaries working.

A few years back, I obtained Intel's official compiler/assembler package called "CTOOLS" from a professor at the Oregon Institute of Technology who actually teaches a class in the 80960 architecture (the main CPU that Sonic the Fighters arcade board runs on). I hadn't ever gotten it to work with my disassembly before but after sitting down and ironing out specifics, official tools, which were licensed to freely distribute, can build the game.

This also means that a partial decompilation can be started, as a proper gcc compiler was needed to build the translated C/C++ code, and the GNU utilities were a bit too difficult to build to correctly work with C/C++. That does not mean, however, ports are possible. As I believe the entirety of the program ROMs were written in assembly.

 

So... there's been this large chunk of data in the program binary I just... couldn't disassemble... I've had no idea what this massive chunk of seemingly garbage data was.... until yesterday.

I was actually messing with my Motor Raid disassembly when I noticed something funny in the coprocessor initialization routine... so I took a closer look at Sonic the Fighter's routine and sure enough, they basically did the same thing.

That large chunk of code? It's M68k code that gets loaded into coprocessor. Since this is very new to me, I am very unsure of the specifics, though this might have been obvious to MAME devs for a long while now.

The chunk of data begins at 0xB630C and goes for 0x3A0E (14,862) bytes. Since I have zero experience with M68k, I can't begin to speculate on what this does, and I'm sure the seasoned M68k experts here won't be familiar with the type of things the code does. I've uploaded it as a binary blob if anyone is interested in looking at it.

 

Ah, you are indeed right. I saw loop count divide by two but forgot that it was loaded a word at a time, not a byte.

EDIT: I think we are both slightly off.

The instruction at 0xE7C loads the address 0xB630C into r4, but r4 gets slightly manipulated to 0xB6318 by the time it reaches the data loop at 0xF14.

The loop count is also defined at 0xED0 as 0x741C and then gets divided by 2 right after.

The 0xA1,0x20000, and 1 at the beginning of the data appears to be flags used at the instructions 0xEA8, 0xEB8, and 0xEC4 respectively.

EDIT2: Apparently it is well known to the MAME team that this is how things work...

Interestingly, we can look at their known programs as a base for this information.

An interesting note here in particular:

EDIT3: This should be the final edit of this post, but because this is a blob of another program, which even includes a copyright string in it, it will have to be removed from my disassembly, so an existing romset will be required to extract the blob to build the disassembly in the next update going forward.