don't click here

New Sonic 1 Disassembly

Discussion in 'Engineering & Reverse Engineering' started by Spanner, Oct 23, 2021.

  1. Spanner

    Spanner

    The Tool Member
    Cross-posted from SSRG as Hivebrain didn't make a new thread regarding the new version, as I checked beforehand.

    This might interest some people.

    For years, the Sonic 1 disassembly on Sonic Retro's GitHub (and predecessors like SVN and Hg) have been seen as somewhat controversial and divisive by some.

    From what was a very easy to work with disassembly by Hivebrain in 2005, turned into something else which was not the best to work with, in the opinion of some.

    Some people didn't like the excessive splitting of files, others had issues with the structure which had been radically changed.

    Whilst the Sonic 2 GitHub disassembly also had changes throughout the years, they were never seen as too controversial to the changes made with Sonic 1's.

    Many people still use the older 2005 disassemblies, and many guides still target them too, although some of course refer to GitHub too. Either way, it's 2021, and the disassemblies were never commonly used as one.

    Over the years, there have always been discussions about new disassemblies, but nothing ever went mainstream. Even I had an idea to try and make the disassemblies easier to work with, with a similar structure and layout for all of them, which never came to fruition. It would have made things easier to work with, had things just been the same.

    And there were others who had plans too over the years, including those who were involved with SSRG over the years, but again, nothing much came out of them for the most part. Not in terms of a Sonic 1 or 2 disassembly in full use today. And that's not to say they still can't be done. But the fact is, it has taken forever for something major to come out. A lot of issues, should have been addressed many years ago, but sadly were not.

    It has been outright difficult for people to come together and agree on a standard, because everyone has their own way of doing things.

    Well, it looks like something is being done, more than 11 years later. And it's certainly worth watching.
    [​IMG]

    For the last few months, Hivebrain, with a few contributors, have forked and reworked the Retro disassembly into a new version which is worth taking a look at.

    Many files have been unsplit, which addresses a major complaint, and there are other fixes and improvements made too.

    Obviously the disassembly is being worked on still, but it does seem rather promising, the question will be of course will it get people to switch to this new disassembly, or will people remain on the older ones?

    After all, the 2005 Sonic 1 and 2007 Sonic 2 disassemblies still get used.

    And somehow, there are people still using non-disassembly tools like ESEII. But that's a discussion for another time.

    If you have any comments regarding improving this disassembly, you are best to ask them on GitHub, although Hivebrain has an account here so could likely post here too.
     
    • Like Like x 3
    • Useful Useful x 2
    • List
  2. Brainulator

    Brainulator

    Regular garden-variety member Member
    I have wondered: is Hivebrain's end goal here to create an alternative to the Sonic Retro GitHub version or eventually merge the two?
     
  3. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    I would have eventually, but it's still very much a work in progress.

    This is a bit of a misconception. I didn't stop in 2005, I kept working on it until 2010-ish, which is what became the Github version. I'm responsible for a lot of the differences between the 2005 and Github disassemblies, including splitting the code into separate files.

    I wrote a tool (ASMUnsplitter) to unsplit the files so I could more easily rework things. For instance, it's easier to do string search/replacements on a single file. My plan is to have everything split up again, but in a slightly more organised way. AuroraFields came up with an idea involving macros to help with that.

    I've made significant changes that break compatiblity with various guides and tools including SonLVL. It'll be more of an alternative than a replacement.
     
  4. Spanner

    Spanner

    The Tool Member
    MainMemory will make it compatible with SonLVL at some point, I was asking them about it recently.

    Thanks for clearing things up. I did see you had made some tools to help with the disassembly. Also, what made you split things up in the past anyway?
     
  5. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    The unsplit asm is over 1.7MB, which makes it rather difficult to use. Splitting it up makes things much more manageable, or at least I find it does anyway.
     
  6. Overlord

    Overlord

    Now playable in Smash Bros Ultimate Moderator
    19,214
    956
    93
    Long-term happiness
    [​IMG]

    Seriously though - is this likely to unify everyone under one S1 disasm at last or just fragment things even further? From my understanding it was bad enough with the two.
     
  7. Brainulator

    Brainulator

    Regular garden-variety member Member
    Given Hivebrain's response to me, it's meant to be an alternative to the one on GitHub, so I really don't think that comic (which I've seen enough times in relation to Sonic hacking within the past ~2 weeks, mind y'all) applies here.

    That said... what even is the problem here? Given all the various forks of the GitHub disassembly, as well as the multitude of options for things like emulators, sound drivers, editors, and assemblers, I can very much see the appeal of branching off from the main thing in order to document a game and make editing it easier without having to be bottlenecked by fears of gridlock.
     
  8. Billy

    Billy

    RIP Oderus Urungus Member
    2,117
    178
    43
    Colorado, USA
    Indie games
    People forget that software, like art, is never finished, only abandoned.

    I can think of at least one. When you're a newbie who wants to learn how to work with Sonic 1, but every guide points you at a different disassembly, which are incompatible with eachother. How much that matters is subjective, of course.
     
  9. Brainulator

    Brainulator

    Regular garden-variety member Member
    That is annoying, to some extent, but if you know what you're doing, everything should be easily workable, since much of the code itself is the same (this is including REV00/1).
     
  10. rata

    rata

    Member
    688
    72
    28
    Argentina
    Trying to be useful somehow.
    Know what you're doing and being completely new on the modding work are completely opposites, my friend. I recall having horrors when some guide was for the 2005 dissasembly instead of the github I was trying to use.
     
  11. biggestsonicfan

    biggestsonicfan

    Model2wannaB Tech Member
    1,605
    406
    63
    ALWAYS Sonic the Fighters
    As someone who's still working to prep a disassembly for the Retro github, my ASM file starts at 8.6 MiB. I can't see how that's fun for anyone, and am taking baby steps into figuring out how to split it up. So I guess I'd like to know: Outside guides which used unsplit ASM, why would people be against a split ASM?
     
  12. nineko

    nineko

    I am the Holy Cat Tech Member
    6,296
    475
    63
    italy
    Well, for one, I prefer when a guide says
    Code (Text):
    1. Open file x.asm
    2. Look for label 123
    3. Do this
    4. Look for label 321
    5. Do that
    Rather than
    Code (Text):
    1. Go to a mysterious subfolder
    2. Open y.asm
    3. Do this
    4. Good now close y.asm and go to a completely different mysterious subfolder
    5. Open z.asm
    6. Do that
    Sure the 2005 sonic1.asm is big, but even good old Notepad can edit it with minimal lag if you (like me) don't want to install a fancy text editor.
     
    Last edited: Nov 9, 2021
  13. InvisibleUp

    InvisibleUp

    friendly internet ghost Member
    139
    13
    18
    I figure that any modern text editor (ex: VS Code, Atom, etc.) can open folders and do a simple search on any file within that folder. I'm a fan of the layout of Pret's various Pokémon disassemblies, such as pret/pokered, because they split the game up into logical elements (ex: different game modes, groups of utility routines, etc.) which makes browsing around and finding a specific function outside the context of a tutorial easier.

    But then again I've never done a ton of MD hacking so perhaps my argument is moot. I'm glad this disasm exists for the people who want it, at least.
     
  14. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,188
    398
    63
    Japan
    I mentioned this briefly in Discord as there was a discussion going on there, so I'll reiterate;

    The main issue with segregating source files is the inability to find things. The solution most people propose is "well if it's logically organised, things would be easier to find", and that's true only to a degree. Familiarity is an issue, for no matter how logical the fragments are, people will still have trouble finding them.

    The solution I propose and have tried, is having a copy of labels (those which are referenced from outside the file) commented out nearby the include directive:

    Code (Text):
    1. ; ===========================================================================
    2. ; ---------------------------------------------------------------------------
    3. ; Error exception routines
    4. ; ---------------------------------------------------------------------------
    5. ; Error_Bus: ErAddress: ErIllegal: ErrDivide: InstCheck: InstTrapV:
    6. ; Privilege: TraceMode: Instr1010: Instr1111: Exception:
    7. ; DebugArt: DebugArt_End:
    8.         include    "Common Library\Error Handler.asm"
    9.  
    10. ; ===========================================================================
    So if one were to search "Error_Bus:" (with the colon), it would lead them down to the include directive, making it easier to find the segregated file's location.

    Someone did mention "the operating system has folder/file searching mechanisms", which is true, however, I have found it to fail in the past. Sometimes the failure is because the folder isn't indexed, however, other times I have found it failing for seemingly no reason at all. Regardless, it'd make finding a label much quicker if you can search in the text editor there and then.
     
  15. nineko

    nineko

    I am the Holy Cat Tech Member
    6,296
    475
    63
    italy
    Also, with a perfect timing, this recent post furthers the point:
    Of course we know that routines can be called from and to each included file, but it's easy to understand where this legitimate confusion comes from.
     
  16. RazorKillBen

    RazorKillBen

    Benny the Hog Member
    10
    1
    1
    London, UK
    Sonic Seasons
    As someone completely new to the scene with hopefully, fresh eyes, the biggest hurdle so far for me has almost certainly been the disconnect between some of the guides, tips, archived posts and the disassembly. Some of the guides and ancient posts I've dove into for answers don't match up with what I see on screen.

    As a newbie, it leaves one in the terrifying position of asking a very simple question that's probably been asked a thousand times before, but the resources and posts answering these questions don't make a lot of sense anymore. A great example is that I used the STE tool earlier to learn about text editing and it told me to paste it into the Sonic.asm file which is completely the wrong file and had to spend a bit of time working out the structure.

    Not to come across as a negative, because I cannot imagine opening a hex editor in comparison, but I did just want to add my two cents because it seems such a shame for all this archived knowledge to slowly become obselete as the new "standard" becomes so different.
     
    • Agree Agree x 2
    • Like Like x 1
    • List
  17. Spanner

    Spanner

    The Tool Member
    The confusion between versions, or rather the amount of changes being made, has reminded me of a point. And it's one I made many years ago, that I believe got ignored...

    One of the faults with the newer disassemblies, over the older ones, Sonic 1 in particular, were that references to old labels were being outright discarded, rather than just referenced.

    I am not sure if this was ever resolved, but when you have all these guides, still using old versions, then there should at least be something to guide people to the new layout.

    Of course, there are a lot of guides, split over various websites and other resources. That has always been the case for many years.

    Some may have the opinion of "why not just rewrite them to use the new stuff", but that would open up more cans of worms there.

    However if the original creators had no objection to being edited for new disassemblies, then fair enough. Some of this can be seen as a barrier although many people can overcome it.

    I don't think people would expect everything to be referenced, mainly the important functions at least, and then go from there. If people can understand what I mean?

    People can argue about how it just makes things more messy but at the end of the day these disassemblies have a lot of scope for improvement, regardless of version, and public feedback should be taken into consideration.
     
  18. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    I'll probably include a file packed with equates for other disassemblies, so people can just drop in their old code and it should work without modification.
     
  19. kazblox

    kazblox

    Member
    178
    27
    28
    Diassemblies and decompilations.
    Not to offend Hivebrain for his earnest efforts in updating his disassembly, and what am I about to say isn't targeting him nor anyone else, but in my view, the only proper, true way to resolve a split disassembly's layout scheme is to follow the original file boundaries and linking schematics as much as possible.

    We have partial symbol layouts from the Nick Arcade prototype of Sonic 2, linker layouts plus source for a version of SEGA's 68000 sound program similar to the one used in Sonic 1, and JMP intersections per every? file boundary for every build we have of Sonic 2 up until REV02*; including even the Nick Arcade prototype itself, and it's useful that way, due to how it's the closest to Sonic 1 in terms of source. They must not be ignored, even though many people have different ideas on what boundaries should be put in place.

    * Clownacy has done a sort-of writeup on these mystery JMPs in the past at the Sonic Stuff Research Group.
     
    • Agree Agree x 3
    • Like Like x 1
    • List
  20. Spanner

    Spanner

    The Tool Member
    This could work. You could also create a program which converts older code to newer labelling, maybe have it so the old code or replaced label / equate is a comment next to it, so people understand the change.