Sonic and Sega Retro Message Board: Planning to hack Sonic 1? - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
Loading News Feed...
 

Planning to hack Sonic 1? UPDATE #2: "stitch.exe" - unsplitting split disassemblies

#1 User is offline Mercury 

Posted 28 January 2011 - 02:36 PM

  • His Name Is Sonic
  • Posts: 1675
  • Joined: 13-November 08
  • Gender:Not Telling
  • Location:Location Location
  • Project:AeStHete
  • Wiki edits:130
UPDATE #2: You can go to this post for a program that'll stitch together a split disassembly.

UPDATE: You can disregard the following and go straight to this post for a full equivalency list instead.

When hacking Sonic 1, one of the first steps is to decide which disassembly to use. When I did it myself, I went with the SVN one, both because I wanted the latest version and also because I had had trouble getting the 2005 one to work.

However, since then I've heard a lot of people explain why they'd rather use the 2005 one and they're very good reasons.

Prime amongst the reasons is this: Because the SVN disassembly doesn't preserve old labels or offsets as comments, it's hard to find your way around or follow old guides that are intended for older versions.

People were working on SCHG:Equivalent Subroutines to help with this, but it's a lot of work and it's far from complete.

I was trying to think of some way to solve the problem and I thought of this:

When building the SVN, you can opt to output a file called "sonic.lst". Here's an example of what it looks like inside:

Syntax Highlighted Code: ASM
 
00001420 TilemapToVRAM: ; XREF: GM_Sega; GM_Title; SS_BGLoad
00001420 4DF9 00C0 0000 lea ($C00000).l,a6
00001426 283C 0080 0000 move.l #$800000,d4
0000142C
 
0000142C Tilemap_Line:
0000142C 2D40 0004 move.l d0,4(a6)
00001430 3601 move.w d1,d3
00001432
 
00001432 Tilemap_Cell:
00001432 3C99 move.w (a1)+,(a6) ; write value to namespace
00001434 51CB FFFC dbf d3,Tilemap_Cell
00001438 D084 add.l d4,d0 ; goto next line
0000143A 51CA FFF0 dbf d2,Tilemap_Line
0000143E 4E75 rts
 


As you can see, it shows the disassembly on the right with the offsets and built data on the left. This is an incredibly useful resource, though - one can search for an offset to find the label associated with it, or vice versa.

Better yet, if one has the equivalent file for the 2005 version, one can find the old label names, too.

The files are somewhat large, so anyone who uses plain old Notepad for hacking might have trouble using them, but if you use Notepad++ or some equivalent (as everyone should =P) then having these will help you when following guides that aren't necessarily for your version of the disassembly.

Is this a good idea? Does it solve the problem? Is there something I may be missing? It would be great if more people could have the opportunity to use the SVN version.
This post has been edited by Mercury: 15 February 2011 - 05:05 AM

#2 User is offline Selbi 

Posted 28 January 2011 - 03:15 PM

  • Obligatory new year's avatar remake.
  • Posts: 1395
  • Joined: 12-May 08
  • Gender:Male
  • Location:Northern Germany
  • Project:Sonic ERaZor
  • Wiki edits:320
This is pretty neat! You could also use a hex editor, but this way it's much quicker! I can't do any greater testing as of now, since I don't have any greater use for it nor want to waste space (my HDD is a step away from exploding). But count me into the group of people who appreciates this. =)


However, the reason why I don't use the SVN disassembly is not really because of the new names for labels (infact, that makes things clearer than just loc_XXXX). My real issue is:
Why the fuck, did you have to split each and everything into seperate files? That doesn't help ANYONE!
When I work on something, I open sonic1.asm, type in something like "Obj01" and I'm there. Oh look, they excluded the objects into seperate files. So you go to the _incObj folder and try to find the Sonic object, just to find out that they splitted that thing into seperate files as well.

FraGag, Hivebrain and whoever worked on the SVN disassembly as well, please explain why you had to add an unnecessary time waster.
This post has been edited by Selbi: 28 January 2011 - 03:16 PM

#3 User is offline Ravenfreak 

Posted 28 January 2011 - 05:06 PM

  • Beast Boy Stahp
  • Posts: 2172
  • Joined: 24-November 08
  • Gender:Female
  • Location:O'Fallon Mo
  • Project:Mighty No. 9 Universe,various hacking projects
  • Wiki edits:112
I believe the reason why they did that is to organize the split disassembly, it makes it more easier to navigate for beginners I suppose. As for your idea Mercury, I think it's a great one. ^_^

#4 User is offline FraGag 

Posted 28 January 2011 - 06:55 PM

  • Posts: 643
  • Joined: 09-January 08
  • Gender:Male
  • Location:Québec, Canada
  • Project:an assembler
  • Wiki edits:6
I've mainly been using listings to figure out what part of the code crashes. When I enable the trace log feature in Gens Rerecording, it dumps the address, instruction and registers for each instruction that it processes, and I can use the listing to map an address to the original assembly code. Seeing instructions out of context is often useless (just look at how many times an instruction like "moveq #0,d0" appears in the code; or try to figure out where a branch or jump leads to when all you see is the offset or address), seeing the labels and comments around the instruction in the disassembly really helps figuring out the cause of the bug.

QUOTE (Selbi @ Jan 28 2011, 03:15 PM)
However, the reason why I don't use the SVN disassembly is not really because of the new names for labels (infact, that makes things clearer than just loc_XXXX). My real issue is:
Why the fuck, did you have to split each and everything into seperate files? That doesn't help ANYONE! [citation needed]
When I work on something, I open sonic1.asm, type in something like "Obj01" and I'm there. Oh look, they excluded the objects into seperate files. So you go to the _incObj folder and try to find the Sonic object, just to find out that they splitted that thing into seperate files as well.

FraGag, Hivebrain and whoever worked on the SVN disassembly as well, please explain why you had to add an unnecessary time waster.

Sonic 2 hasn't had its code split (yet), so I have nothing to do with this. However, I support splitting parts of the code in separate files. I did split the code of every object as well as the code of the sound driver in a test hack of Sonic 1, and I found this easier to navigate, being able to have several files open at once instead of a single view, perhaps 2 views if your editor supports it, in the single code file. When I'm trying to work on or study a more or less large piece of code, I want to keep focused on it, but sometimes I have to scroll up or down a few screens to reach another point in the code. Using the scroll bar thumb (which I prefer doing compared to other means of navigation like Page Up/Down or Ctrl+F) in a file with over 80000 lines is difficult because it can skip over more code than can fit on a screen by moving the mouse only by 1 pixel. However, perhaps all of Obj01's code could have stayed in the same file; that's what I did in my test hack, and it's only about 2000 lines, so it's pretty manageable.

That said, I'm planning on making a code editor that will allow one to do a search that will look into included files as well (and the included files would open in the same code editor, togglable with a +/- icon in the margin, similar to how code folding works in other editors). I'm also planning on integrating the listing features (such as the addresses and opcodes) directly in the editor, putting the information in margins you could make visible when needed.

#5 User is offline nineko 

Posted 28 January 2011 - 07:01 PM

  • I am the Holy Cat
  • Posts: 5255
  • Joined: 17-August 06
  • Gender:Male
  • Location:italy
  • Project:I... don't even know anymore :U
  • Wiki edits:5,251
Well it's definitely a matter of preferences because I agree with Selbi, I prefer to have everything in the same file.

#6 User is offline DigitalDuck 

Posted 28 January 2011 - 10:14 PM

  • Keepin' it cool.
  • Posts: 2860
  • Joined: 23-June 08
  • Gender:Male
  • Location:Lincs, UK
  • Project:Sonic 2 Random Levels, TurBoa, a few secret ones
QUOTE (nineko @ Jan 29 2011, 12:01 AM)
Well it's definitely a matter of preferences because I agree with Selbi, I prefer to have everything in the same file.


I see it as being essentially the same thing as object-orientated vs. imperative - while the latter is practically dying out, some people still prefer to have everything in the same place.

Add me to that list too.

#7 User is offline DalekSam 

Posted 29 January 2011 - 09:13 AM

  • woop woop pull ova dat ass too fat
  • Posts: 1774
  • Joined: 19-February 08
  • Gender:Male
  • Location:Northern Ireland, Belfast
  • Project:Sonic Thrash, Amphobius
  • Wiki edits:165
QUOTE (DigitalDuck @ Jan 29 2011, 03:14 AM)
QUOTE (nineko @ Jan 29 2011, 12:01 AM)
Well it's definitely a matter of preferences because I agree with Selbi, I prefer to have everything in the same file.


I see it as being essentially the same thing as object-orientated vs. imperative - while the latter is practically dying out, some people still prefer to have everything in the same place.

Add me to that list too.

I'm not a fan of everything being split into various places, either, if it's in the same place it's much more convenient for me.

#8 User is offline Selbi 

Posted 29 January 2011 - 09:25 AM

  • Obligatory new year's avatar remake.
  • Posts: 1395
  • Joined: 12-May 08
  • Gender:Male
  • Location:Northern Germany
  • Project:Sonic ERaZor
  • Wiki edits:320
QUOTE (FraGag @ Jan 29 2011, 12:55 AM)
That said, I'm planning on making a code editor that will allow one to do a search that will look into included files as well (and the included files would open in the same code editor, togglable with a +/- icon in the margin, similar to how code folding works in other editors). I'm also planning on integrating the listing features (such as the addresses and opcodes) directly in the editor, putting the information in margins you could make visible when needed.

Or, you know, you could just upload an alternate version of the disassembly where all the files are included. A program which allows the user to do that himself wouldn't be a bad idea either (infact, if you'd give me the permission, I could do that as well). I mean really: Wasn't this disassembly intended to be easier to use and especially for newer users? I'm not sure if you've ever considered thinking about this.
And making your own editor? Please no! I'm pretty sure most of us already found the editor they can work best with, for me it's Notepad2.

I mean come on, your goal is to make lots of people use this disassembly, isn't it? Because if that's true, why would you design it to your own style, rather than the common one everybody uses?

#9 User is offline Spanner 

Posted 29 January 2011 - 11:19 AM

  • Mako Retro
  • Posts: 2775
  • Joined: 02-June 07
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic the Hedgehog Hacking Contest, Other Stuff
  • Wiki edits:2,193
FraGag has been working on his own programs for at least over a year. Nothing wrong with that.

#10 User is offline Andlabs 

Posted 29 January 2011 - 12:25 PM

  • 「いっきまーす」
  • Posts: 2175
  • Joined: 11-July 08
  • Gender:Male
  • Project:Writing my own MD/Genesis sound driver :D
  • Wiki edits:7,061
Shouldn't complaints about Hivebrain "doing stuff wrong" (super emphasis on the quotes) have been made when he first did them in the SVN project thread?

That said another problem I see is that most of the guide on the wiki still use the old disassembly. They should be updated to use the SVN one... I might do that later.

Finally, and this is for Mercury: before you make that sonic.lst, make sure you fix all the zero offset "forced optimizations". I just tried the current svn build myself, and it doesn't match the final ROM because lines like
CODE
move.w #4,0(d0)
get optimized to
CODE
move.w #4,(d0)
which has a completely different encoding when assembled. (This happens because the 0 might be a macro in the original source code — and watch, it might be a macro now.)
This post has been edited by Andlabs: 29 January 2011 - 12:26 PM

#11 User is offline FraGag 

Posted 29 January 2011 - 06:22 PM

  • Posts: 643
  • Joined: 09-January 08
  • Gender:Male
  • Location:Québec, Canada
  • Project:an assembler
  • Wiki edits:6
QUOTE (Selbi @ Jan 29 2011, 09:25 AM)
Or, you know, you could just upload an alternate version of the disassembly where all the files are included. A program which allows the user to do that himself wouldn't be a bad idea either (infact, if you'd give me the permission, I could do that as well).

I considered doing that. I also considered making a version of the disassembly without the fancy macros and constants. That would separate the "research" disassembly from the "hacking" disassembly.

QUOTE (Selbi @ Jan 29 2011, 09:25 AM)
And making your own editor? Please no! I'm pretty sure most of us already found the editor they can work best with, for me it's Notepad2.

Actually, it will be much more than a code editor. I'm planning on making other editing tools (level editor, mappings editor, etc.) that all run inside a single program. Those editing tools would benefit from the power brought by the assembler library I'm working on, which lets a host program assemble something in memory and access the assembled data and all the symbols. Thanks to this, I'll be able to make smarter editors that don't have the limitations of the current editors (e.g. SonMapEd being unable to load certain sprite mappings). Also, having an editor that is able to communicate with the assembler will make it easier to implement refactoring features (the first one I want to implement is "rename symbol" — and no, find & replace is not good enough) or to suggest error corrections or optimized code patterns that can be applied in one or two clicks.

Additionally, I'm planning on overhauling the disassemblies to be based on my new assembler to take advantage of its new features, one of which will be useful for Sonic & Knuckles. In fact, I would like to make my own disassembler as well, that would work with ASM files directly (instead of a database like IDA does) and that would target my assembler, such that it will be guaranteed that the generated code will assemble back to a bitwise copy of the original ROM image.

I almost feel bad for trying to suck everybody into my "vendor lock-in" (except it's not really vendor lock-in because my tools will be free software and cross-platform). I understand that it's completely different from the current hacking workflow. I've been used to work in an IDE, so it feels natural for me to try to replicate this environment for hacking.

QUOTE (Selbi @ Jan 29 2011, 09:25 AM)
I mean come on, your goal is to make lots of people use this disassembly, isn't it? Because if that's true, why would you design it to your own style, rather than the common one everybody uses?

I think it's fair to try new ways of working with the disassembly. Splitting related parts of code to a file requires comprehension of the code, which can't be done easily by software, but pre-including all .asm files in a single one can be done much more easily (include.exe does just that, only using a different syntax).

#12 User is offline Aerosol 

Posted 29 January 2011 - 08:32 PM

  • FML
  • Posts: 6394
  • Joined: 27-April 08
  • Gender:Male
  • Location:New York
  • Project:Sonic (?): Coming summer of 2055...?
That sounds wonderful FraGag. I look forward to a reveal.

#13 User is offline DalekSam 

Posted 30 January 2011 - 07:39 AM

  • woop woop pull ova dat ass too fat
  • Posts: 1774
  • Joined: 19-February 08
  • Gender:Male
  • Location:Northern Ireland, Belfast
  • Project:Sonic Thrash, Amphobius
  • Wiki edits:165
QUOTE (Andlabs @ Jan 29 2011, 05:25 PM)
They should be updated to use the SVN one... I might do that later.

...and then you piss off everyone still using the 2005 disassembly.

This is the true dilemma - because the old 2005 disassembly and the SVN one are radically different, people don't know where to go - go with compatibility with the guides, or fuck with your own head converting labels and what have you to the SVN version. Then there's people who have been using the 2005 one for a long time - how do you get them to switch?

Yes, I realise that the newer one is partially better, but references to the old labels - which always help - have been said that they're denied.

Personally, I'm not really bothered that much about Sonic 1 since I myself prefer Sonic 2, but even just a file with references to like, Obj01 -> whatever it is in the SVN disassembly. And if a file's been split - give its new location! It's basically the same idea as Mercury's one, but with more convenience, I believe.
This post has been edited by DalekSam: 30 January 2011 - 07:40 AM

#14 User is offline Spanner 

Posted 30 January 2011 - 08:29 AM

  • Mako Retro
  • Posts: 2775
  • Joined: 02-June 07
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic the Hedgehog Hacking Contest, Other Stuff
  • Wiki edits:2,193
QUOTE (DalekSam @ Jan 30 2011, 12:39 PM)
QUOTE (Andlabs @ Jan 29 2011, 05:25 PM)
They should be updated to use the SVN one... I might do that later.

...and then you piss off everyone still using the 2005 disassembly.

This whole issue is going to remain for a long time until there is a suitable resolution.

#15 User is offline Selbi 

Posted 30 January 2011 - 11:05 AM

  • Obligatory new year's avatar remake.
  • Posts: 1395
  • Joined: 12-May 08
  • Gender:Male
  • Location:Northern Germany
  • Project:Sonic ERaZor
  • Wiki edits:320
Another solution would be to add the old labels in comments as in the 2007 version of the Sonic 2 disassembly. Example:
Syntax Highlighted Code: ASM
; loc_1CC6C:
Obj02_CheckGameOver:

Personally, that way everything would be fine for me (disregarding the split content).

  • 2 Pages +
  • 1
  • 2
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users