don't click here

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

Discussion in 'Engineering & Reverse Engineering' started by biggestsonicfan, Jun 1, 2020.

  1. biggestsonicfan

    biggestsonicfan

    Model2wannaB Tech Member
    1,610
    416
    63
    ALWAYS Sonic the Fighters
    sfight160.png sfight159.png

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

    Screenshot_20220815_121703.png

    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.
    Screenshot_20220815_121645.png

    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!
     
    Last edited: Aug 15, 2022
  2. biggestsonicfan

    biggestsonicfan

    Model2wannaB Tech Member
    1,610
    416
    63
    ALWAYS Sonic the Fighters
    Been a while, eh?

    Screenshot_20230502_121214.png

    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.
     
    Last edited: May 3, 2023
    • Informative Informative x 2
    • List
  3. E-122-Psi

    E-122-Psi

    Member
    2,470
    612
    93
    Concerning music checks, I wondered if there's any bug concerning why the proper Death Egg Hangar theme never plays in its stage.

    I know in the remake it plays North Wind instead, I think in the original game it plays nothing at all. I wonder if this was maybe because the music was meant to play over the actual Act Start jingle instead, since the song has its own sort of startup intro (and let's face it, you'd barely hear most of the song anyway).
     
  4. biggestsonicfan

    biggestsonicfan

    Model2wannaB Tech Member
    1,610
    416
    63
    ALWAYS Sonic the Fighters
    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.
     
  5. biggestsonicfan

    biggestsonicfan

    Model2wannaB Tech Member
    1,610
    416
    63
    ALWAYS Sonic the Fighters
    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"
     
    • Informative Informative x 4
    • List
  6. biggestsonicfan

    biggestsonicfan

    Model2wannaB Tech Member
    1,610
    416
    63
    ALWAYS Sonic the Fighters
    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.
     
    • Like Like x 6
    • Informative Informative x 1
    • List
  7. biggestsonicfan

    biggestsonicfan

    Model2wannaB Tech Member
    1,610
    416
    63
    ALWAYS Sonic the Fighters
    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.
     

    Attached Files:

  8. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,200
    429
    63
    Japan
    I thought I'd take a stab at this,

    The data isn't 68k opcode/instructions,

    Hardware spec sites state the 68k is used as the CPU for controlling the sound chips, so I tried looking at the Yamaha application manual to check out its' address/data map. I couldn't find a correlation where the data made sense, so I'm starting to doubt it's anything 68k related, at least not sound related. I was hunching that it could be addresses in memory for the sample data, but the chip requires more data than 6 bytes for that.

    The data you zipped up and shared is unfortunately incomplete. It's 0x741C bytes, twice as big, because the data itself is loaded words at a time:
    Code (Text):
    1.                 ldos    (r4), r7
    2.                 st      r7, (r11)
    3.                 addo    2, r4, r4

    The ldos (Load ordinal short) loads two bytes and 0 extends to 4 bytes, and 2 is advanced on the address (r4) each count.

    We have the first three long-words at B630C which are referenced by the subroutine, setting it up to process the data following (don't ask how, I don't have a memory map to work out what's going where).

    At B6318 is the start of the data you zipped, and it ends at BD734.

    Following this are two longs of padding 0 data, followed by another eerily similar data with identical 3 longs (the same as B630C), this one is referenced by another subroutine in a similar manner, but accessing equates labelled as "GEO_/insertvariation/".

    The data itself from B6318 to BD734 appears to be in segments of 6 bytes, here's a snippet:

    [​IMG]

    Left is the original raw data in its native little endian, given the data is read a word at a time, I have endian swapped it for the right side. Same data, just Big Endian.

    It looks to me like the first two words are parameters while the third word is flag/mark/instruction. Sometimes the two parameters come together (if swapped around, you can somewhat see on the right, the positive 0000 0001, 0000 0002 and negative FFFF FFFD, FFFF FFF8), it sometimes also appears as a potential local address. Sometimes the two words don't correlate, but it's always in groups of 6 bytes visually.

    Is it possible this is related to geometry?

    Here's a copy of the full data, a big endian copy is inside also.

    Hope this helps.
     
    • Informative Informative x 2
    • List
  9. biggestsonicfan

    biggestsonicfan

    Model2wannaB Tech Member
    1,610
    416
    63
    ALWAYS Sonic the Fighters
    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:
     
    Last edited: Apr 9, 2024 at 10:22 AM
    • Informative Informative x 1
    • List