don't click here

Sonic 1 Disassembly

Discussion in 'Engineering & Reverse Engineering' started by Hivebrain, Dec 26, 2008.

  1. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    Discuss changes here, particularly controversial changes. The disassembly builds a ROM which is almost identical to the original ROM. There is one instruction that had to be changed. It may be possible to correct this now that we're using asm68k.

    Here's a brief to-do list:
    - Split some more stuff.
    - Use more local labels in objects that don't have them.
    - Do text search for "loc_" and "locret_" and rename them better.
    - Use ids instead of object numbers, level numbers and game modes.
    - Implement ids in all files (already done for sonic.asm).
    - Macros for angle/trig object stuff.
    - Merge obRange and obRanges macros.
    - Add JP1 files with 0/1 variable to switch between them.
     
  2. Mind telling what this instruction was?
     
  3. drx

    drx

    mfw Researcher
    2,254
    350
    63
    :rolleyes:
    I'm guessing exg d0,d1
     
  4. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    Line 133 in "_incObj\85 Boss - Final.asm"

    Code (ASM):
    1. exg d0,d1
    Swapping d0 and d1 has no effect on the output ROM.
     
  5. Sik

    Sik

    Sik is pronounced as "seek", not as "sick". Tech Member
    6,718
    1
    0
    being an asshole =P
    ...

    What the hell was rejecting that instruction? o_o;
     
  6. nineko

    nineko

    I am the Holy Cat Tech Member
    6,298
    475
    63
    italy
    Maybe I'm using an outdated disassembly so I don't know if this has been fixed, but right after Title_LoadText there is this line:
    Code (Text):
    1. move.w  #0,($FFFFFFF0).w; disable debug mode
    The comment is misleading, it should read "disable DEMO mode".
    I'll post more if I find them.
     
  7. drx

    drx

    mfw Researcher
    2,254
    350
    63
    :rolleyes:
    Assemblers tend to assemble exg d1,d0 into exg d0,d1. While those instructions do (almost) exactly the same, they have different opcodes.
     
  8. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    Object ids are defined in "_inc\Object Pointers.asm". I've used them in sonic.asm, but they still need adding to all the smaller asm files where relevant.

    Could exg be redefined with a macro?
     
  9. FraGag

    FraGag

    Tech Member
    Thanks, I've been waiting for this for a while! I'll have to get used to your naming convention before I get started though. Speaking of which, we should decide whether we take your names or Xenowhirl's for Sonic 2, to make porting code between both games easier.
     
  10. Sik

    Sik

    Sik is pronounced as "seek", not as "sick". Tech Member
    6,718
    1
    0
    being an asshole =P
    So basically assembler developers love to make their life harder? Because implementing such a behaviour requires extra code, in fact >_>
     
  11. Overlord

    Overlord

    Now playable in Smash Bros Ultimate Moderator
    19,218
    965
    93
    Long-term happiness
    For anyone still coding in assembly today voluntarily, that's probably true, to be honest =P

    Note I said voluntarily, before the legions of hack coders jump on me.
     
  12. Sik

    Sik

    Sik is pronounced as "seek", not as "sick". Tech Member
    6,718
    1
    0
    being an asshole =P
    And OS developers.

    Besides when proramming for very old (and hence slow) hardware trying to achieve for full speed, assembly is the only option. Now, if you try to do that with new hardware...
     
  13. Overlord

    Overlord

    Now playable in Smash Bros Ultimate Moderator
    19,218
    965
    93
    Long-term happiness
    I thought most of modern-day OSes were written in C now?

    You're quite correct on the first sentence. The second - it's a bit ehhh. It's like Gentoo users who compile every app for their system - sure, it'll go faster, but is an app starting in 0.98 seconds really noticable over 1.0?
     
  14. Nibble

    Nibble

    Oldbie
    Ideally most of it would be written in C. However, at the very lowest levels of the OS, you'd eventually have to get into assembly because you simply can't directly interact with hardware in the same way you can with assembly. That said, you can create a higher-level C interface over some nitty-gritty asm and have the vast majority of the OS written in C/C++.

    Not that I'm an expert on OS design or anything, but that's how I understand it. :P

    Semi on-topicness: One of these days I should get into Genesis programming and 68k asm, and create/hack something awesome. Just that I'm already doing a ton of other stuff.

    I do love all the work that's gone into Sonic disassemblies; I can almost understand it, even without extensive knowledge of assembly.
     
  15. Sik

    Sik

    Sik is pronounced as "seek", not as "sick". Tech Member
    6,718
    1
    0
    being an asshole =P
    This. No matter what, some things are very processor specific, and those things have to be done in assembler because they aren't featured in any high-level language. They're often wrapped into functions, indeed, but still you need to use assembly, unless you're so crazy you create your own high-level language exclusively for the operating system. But then you're using assembly for the compiler, unless you're even crazier and compile directly into machine language X_X

    More to my point. There's little point programming in assembly for new hardware both because most likely it won't be noticeable, and actually there are so many different types of technology that what speeds up in one processor may slow down horribly in another one - even if newer. Sometimes it may even hurt (using RDTSC for timing fails miserably in any kind of multiprocessor or multicore enviroment). So no.
     
  16. Spanner

    Spanner

    The Tool Member
    *bump*
    Okay, I was thinking, wouldn't it be better if variables were used for the sounds? It would save issues for example, let's say you ported the Sonic 3 Sound Driver to S1. It may be unpopular due to how it works but sounds are practically everywhere and using variables in place of the audio $** request would probably be better. For example:
    Code (ASM):
    1. audio $8C
    Would become:
    Code (ASM):
    1. audio Music_Boss
    And if you wanted to change the music:
    Code (ASM):
    1. Music_Boss = $8C ; change the $** to another music ID
    Just saying.
     
  17. FraGag

    FraGag

    Tech Member
    I've implemented this in the Sonic 2 disassembly (in a more clever way, even, similar to how object IDs are currently defined) and it would indeed be a nice addition for this disassembly.
     
  18. Spanner

    Spanner

    The Tool Member
    It was in the Sonic 2 Split Disassembly, which was the inspiration for my post. Still, variables and equates are useful as long as you don't get over the top with them.
     
  19. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    I will be doing this soon. IDs would be defined more like this though:

    Code (ASM):
    1. bgm_Boss: equ (ptr_Music_Boss-Music_Index)/4
    That's how I've been doing other IDs. Palette scripts and PLCs could probably do with being IDed as well.
     
  20. Sik

    Sik

    Sik is pronounced as "seek", not as "sick". Tech Member
    6,718
    1
    0
    being an asshole =P
    The Sonic 3D disasm also has this kind of IDs too - especially since the SFX ones aren't so obvious as you have to add $32 from what appears in the Sound Test =/