don't click here

Sonic 1 Disassembly

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

  1. Spanner

    Spanner

    The Tool Member
    Well I hope you enjoy your low takeup. Nobody is going to switch to a disassembly which has radically been changed and is going to confuse people. If you're not going to reference them inside the disassembly, create a text file that's provided with the disasm with the major label changes and update the equivalent subroutines table. This would give some guidance. Then again, maybe a global labelling scheme for both disassemblies could be looked at.
     
  2. Selbi

    Selbi

    The Euphonic Mess Member
    1,497
    48
    28
    Northern Germany
    Sonic ERaZor
    I love you! I've been waiting for this for over 3 years. =D
     
  3. Mercury

    Mercury

    His Name Is Sonic Tech Member
    1,740
    21
    18
    Location Location
    AeStHete
    Thank you! :) It threw me for awhile until I figured out that they were wrong. Now nobody else using it will have to go through that.
     
  4. qiuu

    qiuu

    Tech Member
    144
    9
    18
    Blue Ball & Blocks
    Do you notice you keep reiterating the same point over and over again?
    It's a minor drawback (especially to beginners) compared to the huge advantages the new disasm offers.

    Anyway, so you finally shut up, here's that freakin' list: http://geoo.digibase.ca/Genesis/s1_labellist.txt
    Hope considering that you've been crying for it for ages, you'll actually make something from it now.

    (It's been autogenerated by the following rather primitive program: http://geoo.digibase.ca/Genesis/s1_labellist_make.cpp Some additional fixes have been applied to the file afterwards. Not guaranteed to be perfect.)
    EDIT: small bugfix
     
  5. Spanner

    Spanner

    The Tool Member
    Yeah, I did use it for something:
    SCHG:Equivalent_Subroutines
    More will be added eventually. People are encouraged to add new things to it.
     
  6. Bgvanbur

    Bgvanbur

    Tech Member
    128
    1
    0
    USA
    a disassembly, some small Sega CD projects
    I have made some edits to Sonic 1 (svn revision 208):

    9 changes to @ type labels where ambiguous which label to use
    sonic.asm: include of "maps\LZ Blocks.asm" was not the correct case
    _incObj/85 Boss - Final.asm: asm68k sorts the registers for exg, so changed "exg d1,d0" to "exg d0,d1" so now both asmx and asm68k produce same binary (note asmx is true to the 68k programmers reference manual)
    _inc/Object Pointers.asm: fixed warnings for undefined symbolic ptr_ObjectFall

    With these updates and updates I made to asmx I can assemble Sonic 1 with either asm68k.exe or asmx to produce the same original binary. I have emailed Bruce Tomlin Saturday about my updates (in case he wanted to use any of them) and inquiring about his software license for asmx (to determine if and how I can release my asmx updates). Still no response from Bruce Tomlin though.

    A list of the changes I made for asmx:

     
  7. FraGag

    FraGag

    Tech Member
    exg d1,d0 is the correct original instruction. If you aim for compatibility with the asm68k build, then yes, you have to swap the operands. However, if you want to get a ROM that is a bit-perfect copy of the original ROM, you must use exg d1,d0. Of course, in practise, both forms behave identically.

    I see you've changed several local labels to avoid identical names. Is this a limitation in asmx? Does it support local labels at all?

    The rest is great. Thanks for your contribution!

    Also, as MainMemory pointed out in the FAQ thread, please add your name at the end of your future commit messages.
     
  8. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    The whole point of local labels is that you can use the same word again and again.
     
  9. Bgvanbur

    Bgvanbur

    Tech Member
    128
    1
    0
    USA
    a disassembly, some small Sega CD projects
    Are there other aspects of the asm68k build that make inconsistent binaries with the original ROM? I was using the s1built.bin in svn as if was same as the original ROM.

    I added temporary label support to asmx where it would search for closest temporary label in the same file. I corrected the ones where they was a closer label and a different label was actually used. So of these even seemed ambigious to me which label was the one to use.
     
  10. FraGag

    FraGag

    Tech Member
    No, this is the only difference between the original ROM and the s1built.bin produced by asm68k.

    The scope of a local label is delimited by non-local (I.e. global) labels. That means you can't reference a local label if there's a global label defined between the reference and the definition of the local label. It is an error to define multiple local labels with the same name in the same scope (I.e. between 2 given global labels); however, as Hivebrain said, the same name can be used multiple times, as long as it's used in separate scopes.
     
  11. Bgvanbur

    Bgvanbur

    Tech Member
    128
    1
    0
    USA
    a disassembly, some small Sega CD projects
    Thanks for the info. I have reverted my change to the exg.
     
  12. Andlabs

    Andlabs

    「いっきまーす」 Wiki Sysop
    2,175
    1
    0
    Writing my own MD/Genesis sound driver :D
    Would you all mind if I split out all the SMPS stuff into a separate .asm file, label it, and add a Z80 driver disassembly?
     
  13. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    That's fine. The Z80 part is compressed though, so it wouldn't be recompilable.
     
  14. Bgvanbur

    Bgvanbur

    Tech Member
    128
    1
    0
    USA
    a disassembly, some small Sega CD projects
    I would love to see this included.
     
  15. Xenowhirl

    Xenowhirl

    Tech Member
    175
    0
    0
    The compressed Z80 sound driver in the Sonic 2 disassembly is "recompilable"; you can edit the z80 code, build s2, and find the edited z80 driver assembled and compressed into the output binary. So it's possible. But I wouldn't disagree if you say it's more trouble than it's worth to implement that into the Sonic 1 disassembly.
     
  16. FraGag

    FraGag

    Tech Member
    I've committed project files for SonED2 v11.02.24 that match the directory structure of the disassembly in revision 261 (revision 262 removes the old files in misc).

    If you had modified the starting locations in your hack, you'll have to make the changes in the files under the new startpos directory. Also, make sure to get the edits made in the .asm files as well as the new .asm files that reference the new starting position files.

    There are more projects than what is included with SonED2 v11.02.24: there are additional projects for the starting locations of the credits demos and for the JP1 versions of the special stages.

    Enjoy!
     
  17. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,735
    334
    63
    SonLVL
    Just pushed a new "MapMacros" branch which converts all sprite mappings to my macros while preserving bit-perfect builds.
     
  18. The Prof

    The Prof

    The Island Professor Member
    107
    0
    16
    Orkney, Scotland
    Sonic 1 Yarmar Edition
    While I was fixing some problems caused by incompatibities between this disassembly and SonMapEd, I ran into a couple of errors which I think were due to mistakes in the disassembly.

    In ...\_anim\Sonic.asm there is a part labeled "id_Hang:". This is labelled "id_LZHang:" in ...\anim\Sonic (without frame IDs).asm. The difference in labelling doesn't affect a normal build, but if someone prefers not to use the frame IDs, it throws up an error when being built.

    Secondly, and I'm not 100% sure this is a mistake, but on line 17 of ...\incObj\sub ReactToItem there is a frame ID mentioned. I don't think this happens throughout the rest of the disassembly, so it seems odd that it should happen there.

    Would it be worth writing a guide or something on making this disassembly compatible with SonMapEd? Being able to use familiar tools might help uptake a bit at least.
     
  19. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,735
    334
    63
    SonLVL
    I don't think there's anything that can be done to make people stop using the 2005 disassembly. We could try making it more "SonMapEd friendly", and we could try putting all the code back into one asm file, but in the end, everyone's got their way of doing things, they won't change, and will insist to newcomers that their way is the best way.
     
  20. RetroKoH

    RetroKoH

    Member
    1,662
    22
    18
    Project Sonic 8x16
    I'm starting to feel like I'm the only one who prefers the asm split up the way it is in the Sonic 1 disassembly...
    I've done the same to Sonic 2... though SonLVL doesn't take too kindly to that for some reason.