don't click here

New Potential for Disassembly

Discussion in 'Engineering & Reverse Engineering' started by Quickman, Feb 2, 2004.

Thread Status:
Not open for further replies.
  1. Feb 2, 2004 #1
    Quickman

    Quickman

    be attitude for gains Tech Member
    5,596
    18
    18
    :x
    omg porjcet
    This is IDA, an assembly code disassembler for many processors, including the M68k.

    What's so special about IDA? It features FLIRT (Fast Library Identification and Recognition Technology). FLIRT, in a nutshell, can tell you what high-level programming language a given assembly code was originally written in.

    Why is this useful? If the programming language used in Sonic game production is one recognised by IDA (and it's likely to, given that Sonic Team are not likely to have gone to all the trouble of developing a whole programming language to write a game) then we can probably reconstruct the original source code, which would open up a whole new realm of Sonic ROM hacking, and possibly even more secrets.

    I haven't tried it yet. All I know is it is compatible with the M68k processor. I'll update here when I try it.
     
  2. Feb 2, 2004 #2
    Icy Guy

    Icy Guy

    Hedgehog. Sonic the Hedgehog. Member
    776
    0
    0
    California
    GoldenEye 007 level hack
    I think I tried it a couple times with Sonic 2, but I could never get anything to work right. I'd always get errors, which were probably caused by my piddling 128 MB of RAM.
     
  3. Feb 2, 2004 #3
    LOst

    LOst

    Tech Member
    4,891
    6
    18
    It won't recognise the Sonic ROM. It's not programmed with a high-level programming language.
     
  4. Feb 2, 2004 #4
    Quickman

    Quickman

    be attitude for gains Tech Member
    5,596
    18
    18
    :x
    omg porjcet
    They can't possibly have scripted the whole thing in assembly code themselves though.
     
  5. Feb 2, 2004 #5
    XFox Prower

    XFox Prower

    Member
    1,196
    0
    0
    x86 Assembly, Tails Search Assistant
    Why would you say that? I'd say they took every step possible to compress the art in Sonic 2 and other roms to fit in the small cart sizes that they did. But judging by how Sonic & Knuckles Collection was 16 mb to emulate a 4 mb rom, it's the higher level programming languages that they don't specialize in. I don't know what sadx:pc is like and what the requirements are compared to it's original but it's likely a bit unoptimized. I doubt they used just Notepad programs to write the assembly. At the least, they probably had some syntax highlighting or keyword managing Notepad enhancement such as Edit Plus (there's a 3rd party plugin for ASM 68000 but it's not the best).
     
  6. Feb 2, 2004 #6
    LocalH

    LocalH

    roxoring your soxors Tech Member
    3,309
    29
    28
    wouldn't you like to know
    Guitar Hero II Deluxe
    I would be willing to bet money that at least 99% of the Genesis Sonic games are coded in ASM. The only thing that might not be, would possibly be some of the initial setup code, especially if it was shared amongst an assload of games. The Genesis came out at a time when, while it was more feasible than with the 8-bit consoles, ASM still held a lot of advantages over C or other HLLs. That's why there's no such thing as a Genesis HLE (similar to UltraHLE for the N64), because there's no 'high level' to simulate. The games pretty much bang directly on the hardware. Unless you want to call the VDP command and data ports one for some reason, there's no graphics API on the Genesis, but just the VDP registers.
     
  7. Feb 2, 2004 #7
    LocalH

    LocalH

    roxoring your soxors Tech Member
    3,309
    29
    28
    wouldn't you like to know
    Guitar Hero II Deluxe
    Since SA:DX (and, by extension, SA) came out on the NGC and the DC, in a time where high-level programming carries with it huge wins for the development process, I would imagine it was coded in C, or at least a substantial portion of it. At most, I'd think they had to rewrite the graphics and sound code to utilize each system's APIs, but I'd wager that the core logic is entirely from the same codebase, with only bugfixes if anything.

    Also, just in case anyone feels like nitpicking, when I say C in this context, I'm usually referring to both C and C++.
     
  8. Feb 2, 2004 #8
    GerbilSoft

    GerbilSoft

    RickRotate'd. Administrator
    2,971
    76
    28
    USA
    rom-properties
    Sonic Adventure DX PC is compiled with the Intel C++ compiler and Microsoft Visual Studio .NET (bleah). These compilers are obviously pretty bad - they both leave in compilation arguments in the final executable. There's probably a few megabytes of garbage in the final sonic.exe file consisting of just the compilation stuff.
     
  9. Feb 2, 2004 #9
    LOst

    LOst

    Tech Member
    4,891
    6
    18
    Hey, you're talking about Yuji Naka here. At the time he wrote Sonic, he had worked for many years programming games in pure assembly language.

    Also he's a Japanese! I have never seen any other people working so hard on something like Japanese people.

    Why do you think Sonic 2 is better than Sonic Spinball?

    Sonic 2 = Japanese - Assembler
    Sonic Spinball = US - C
     
  10. Feb 3, 2004 #10
    XFox Prower

    XFox Prower

    Member
    1,196
    0
    0
    x86 Assembly, Tails Search Assistant
    Often the most direct way is the simplest way. Here's a java script example:


    <body>
    <div id="out">
    </div>

    <script>
    <!--
    O=Array("1","8","6","8","7","2","5","2","3","2","2","4","8","6","2","6")

    for(I=0;I<16;I++)
    {
    if(Math.floor(I/4)==I/4){document.getElementById('out').innerHTML+="<br />"}
    document.getElementById('out').innerHTML+=O
    }

    -->
    </script>
    </body>

    The goal was to write the array contents to the screen and put a line break to separate it into 4 rows. Then I came up with an even better solution (replace above):

    for(I=0;I<16;I++)
    {
    document.getElementById('out').innerHTML+=O
    if(!((I+1)&3)){document.getElementById('out').innerHTML+='<br />'}
    }

    The 2nd isn't pretty, but it's faster and it gets the same result in less space. Never overlook the power of bitwise operators.

    Assembly and Genesis programming didn't involve any interpreting script or operating system on top of the hardware. It was intended directly for the hardware. There's no doubt that every byte in the dumped Sonic roms we study had a purpose (whether used or not) and the programmers knew exactly what all of it was intended to do. It''s not the type of language that sticks in your mind 6 months after a project. But they had full control over every byte in these roms, they knew what they were doing, and they succeeded. Programs like Visual Studio isn't one of those languages where you know what goes into your program, nor would you have full control over it. (I'll hold back on assaulting the Microsoft empire of non-standard programs and languages promoting laziness and depency of their products for now). If Assembly were still used the way it was in the past, we wouldn't even have a need for 1 GB of RAM and all those programs out there with the sky high system requirements. Assembly may be ancient, but it's precise :P
     
  11. Feb 3, 2004 #11
    Quickman

    Quickman

    be attitude for gains Tech Member
    5,596
    18
    18
    :x
    omg porjcet
    That's true. I always asserted that if I found various well-maintained utilities for Windows 3.1 I would happily revert to it. Most stable Windows I ever did use.
     
Thread Status:
Not open for further replies.