Sonic and Sega Retro Message Board: Sonic 2 Split Disassembly - Sonic and Sega Retro Message Board

Jump to content

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

Sonic 2 Split Disassembly

#61 User is offline shobiz 

Posted 16 July 2010 - 03:49 PM

  • Posts: 863
  • Joined: 27-March 05
  • Gender:Male
  • Location:Karachi, Pakistan
  • Wiki edits:4,411
(quoting from the Sonic 1 disassembly thread to avoid taking that off-topic)

QUOTE (MarkeyJester @ Jul 17 2010, 12:07 AM)
macros' which make it easier but not understandable

Hmm do you mind elaborating on this a bit more? It's something we can look into fixing.

#62 User is offline shobiz 

Posted 19 July 2010 - 03:28 AM

  • Posts: 863
  • Joined: 27-March 05
  • Gender:Male
  • Location:Karachi, Pakistan
  • Wiki edits:4,411
Double posting but whatever.

What do you guys think of creating a downloadable version of the current revision of this disassembly, similar to what Hivebrain's done for the Sonic 1 disasm? Are there any particular changes you'd like to make before any such step is taken, or is it fine in its current state?

#63 User is offline MoDule 

Posted 19 July 2010 - 09:45 AM

  • Posts: 308
  • Joined: 03-October 07
  • Gender:Male
  • Project:Procrastinating from writing bug-fix guides
  • Wiki edits:52
I'm all for it. I've still got a few things I haven't committed yet, though I really only feel I need to ask about one:
What's everyone's opinion on giving all the unknown RAM addresses generic unk_*(address) names? It would make rearranging the RAM layout a lot easier. If everyone's okay with that I'll go ahead and commit my changes (though I'm still missing a few addresses used during the special stages which I can't make heads nor tails of).

#64 User is offline MarkeyJester 

Posted 19 July 2010 - 10:58 AM

  • Posts: 1474
  • Joined: 22-July 08
  • Gender:Male
  • Location:Japan
  • Wiki edits:16
QUOTE (shobiz @ Jul 16 2010, 09:49 PM)
(quoting from the Sonic 1 disassembly thread to avoid taking that off-topic)

QUOTE (MarkeyJester @ Jul 17 2010, 12:07 AM)
macros' which make it easier but not understandable

Hmm do you mind elaborating on this a bit more? It's something we can look into fixing.

Well, let's say for example this line during the Vertical Blanking Interval (Sonic 1):

Syntax Highlighted Code: ASM
		writeVRAM	v_spritetablebuffer,$280,vram_sprites


...Of which is an equivilent to the original assembly mnemonics:

Syntax Highlighted Code: ASM
		lea	($C00004).l,a5
move.l #$94019340,(a5)
move.l #$96FC9500,(a5)
move.w #$977F,(a5)
move.w #$7800,(a5)
move.w #$0083,($FFFFF640).w
move.w ($FFFFF640).w,(a5)


This is responsible for setting the VDP, to DMA transfer sprite data from the sprite table buffer (00FFF800) to the VDP's sprite table V-Ram location (incidentally F800), allowing the MC68 to do other tasks.

The issue I find here is that the first one (Running under a Macros) although it's easier to edit by all means (why hell it is rather useful in all honesty), most people would edit/use it there entire lives and not understand WHY it works or even HOW, their knowledge is therefore limited and their understanding of the VDP and it's registers, may never occur. The possibilities are almost endless with the VDP, and understanding how and why it works (Given the original code as help) would help one benefit from a learning point of view.

That was basically what I meant, not to say that I'm "complaining" per se, but I felt that it should at least be noted for future reference.
This post has been edited by MarkeyJester: 19 July 2010 - 11:00 AM

#65 User is offline shobiz 

Posted 19 July 2010 - 11:47 AM

  • Posts: 863
  • Joined: 27-March 05
  • Gender:Male
  • Location:Karachi, Pakistan
  • Wiki edits:4,411
QUOTE (MoDule @ Jul 19 2010, 07:45 PM)
I'm all for it. I've still got a few things I haven't committed yet, though I really only feel I need to ask about one:
What's everyone's opinion on giving all the unknown RAM addresses generic unk_*(address) names? It would make rearranging the RAM layout a lot easier. If everyone's okay with that I'll go ahead and commit my changes (though I'm still missing a few addresses used during the special stages which I can't make heads nor tails of).

I'm okay with it (and I'm kinda used to it from IDA anyway). We should probably add a readme.txt of sorts explaining some of the major changes that have been made (such as the dynamic IDs system and the new way of defining RAM equates) so that newcomers don't get overwhelmed.

QUOTE (MarkeyJester @ Jul 19 2010, 08:58 PM)
Well, let's say for example this line during the Vertical Blanking Interval (Sonic 1):

Syntax Highlighted Code: ASM
		writeVRAM	v_spritetablebuffer,$280,vram_sprites


...Of which is an equivilent to the original assembly mnemonics:

Syntax Highlighted Code: ASM
		lea	($C00004).l,a5
move.l #$94019340,(a5)
move.l #$96FC9500,(a5)
move.w #$977F,(a5)
move.w #$7800,(a5)
move.w #$0083,($FFFFF640).w
move.w ($FFFFF640).w,(a5)


This is responsible for setting the VDP, to DMA transfer sprite data from the sprite table buffer (00FFF800) to the VDP's sprite table V-Ram location (incidentally F800), allowing the MC68 to do other tasks.

The issue I find here is that the first one (Running under a Macros) although it's easier to edit by all means (why hell it is rather useful in all honesty), most people would edit/use it there entire lives and not understand WHY it works or even HOW, their knowledge is therefore limited and their understanding of the VDP and it's registers, may never occur. The possibilities are almost endless with the VDP, and understanding how and why it works (Given the original code as help) would help one benefit from a learning point of view.

That was basically what I meant, not to say that I'm "complaining" per se, but I felt that it should at least be noted for future reference.

I see your point, but the benefits far outweigh the drawbacks in this case IMO, and if someone's keen on learning how to program the VDP manually they can always take a look at the macro source or a document such as genvdp.txt.

#66 User is offline FraGag 

Posted 19 July 2010 - 07:17 PM

  • Posts: 647
  • Joined: 09-January 08
  • Gender:Male
  • Location:Québec, Canada
  • Project:an assembler
  • Wiki edits:6
QUOTE (MoDule @ Jul 19 2010, 10:45 AM)
I'm all for it. I've still got a few things I haven't committed yet, though I really only feel I need to ask about one:
What's everyone's opinion on giving all the unknown RAM addresses generic unk_*(address) names? It would make rearranging the RAM layout a lot easier. If everyone's okay with that I'll go ahead and commit my changes (though I'm still missing a few addresses used during the special stages which I can't make heads nor tails of).

Yes please. There should be no literal absolute RAM address left in the source, so that absolutely nothing breaks when moving stuff around. Ideally, some offsets on registers that point to RAM should also be labelled somehow (possibly using subtraction with 2 labels), but it might be a bit more difficult to do if it's not obvious what the register can point to.

#67 User is offline MoDule 

Posted 20 July 2010 - 08:09 AM

  • Posts: 308
  • Joined: 03-October 07
  • Gender:Male
  • Project:Procrastinating from writing bug-fix guides
  • Wiki edits:52
Well, I guess I can go ahead and commit what I've got. I'm afraid there might still be some RAM addresses missing (besides the special stage ones, that is). I don't suppose there's a smart way to find RAM addresses that don't have the $FFFF prefix? I mean stuff like this:
CODE
; word_917A:
OptionScreen_Choices:
dc.l (3-1)<<24|(Player_option&$FFFFFF)
dc.l (2-1)<<24|(Two_player_items&$FFFFFF)
dc.l ($80-1)<<24|(Sound_test_sound&$FFFFFF)


#68 User is offline shobiz 

Posted 22 July 2010 - 10:40 AM

  • Posts: 863
  • Joined: 27-March 05
  • Gender:Male
  • Location:Karachi, Pakistan
  • Wiki edits:4,411
Can we shorten some of the equate names a bit? E.g. ehz_1 instead of emerald_hill_zone_act_1, GMID_* instead of GameModeID_*, and bit_* instead of button_* and btn_* instead of button_*_mask (copying Hive's naming scheme for this one).

#69 User is offline ICEknight 

Posted 22 July 2010 - 11:01 AM

  • Posts: 8836
  • Joined: 11-January 03
  • Gender:Male
  • Location:Spain
  • Wiki edits:18
What for? This way you don't need to look up what does stuff like GMID stand for...
This post has been edited by ICEknight: 22 July 2010 - 03:27 PM

#70 User is offline shobiz 

Posted 22 July 2010 - 12:45 PM

  • Posts: 863
  • Joined: 27-March 05
  • Gender:Male
  • Location:Karachi, Pakistan
  • Wiki edits:4,411
Because having to type GameModeID_ContinueScreen in your own code would get kinda annoying (though admittedly GMID_* is only 6 characters shorter). emerald_hill_zone_act_1 vs. ehz_1 is a saving of 18 characters, however, and I'm sure everyone knows what ehz is.

#71 User is offline FraGag 

Posted 22 July 2010 - 06:14 PM

  • Posts: 647
  • Joined: 09-January 08
  • Gender:Male
  • Location:Québec, Canada
  • Project:an assembler
  • Wiki edits:6
I definitely agree for the zones/acts constants. For GameModeIDs, I'm not sure; on one hand, as ICEknight said, acronyms/abbreviations may be cryptic until you look them up. On the other hand, they always get moved to Game_Mode. Having "game mode" spelled out twice on the same line is redundant, but then shortening "GameModeID" to "GMID" can lead to conflicts if something else is shortened to "GMID". That said, then I made all those IDs, I used shorter names for the others, so we might as well just go with GMID...

#72 User is offline Spanner 

Posted 22 July 2010 - 06:18 PM

  • Mako Retro
  • Posts: 2785
  • Joined: 02-June 07
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic the Hedgehog Hacking Contest, Other Stuff
  • Wiki edits:2,193
A universal labelling scheme would make some matters easier for both SVN disassemblies. This would at least make a start to it.
This post has been edited by SOTI: 22 July 2010 - 06:19 PM

#73 User is offline shobiz 

Posted 23 July 2010 - 05:28 AM

  • Posts: 863
  • Joined: 27-March 05
  • Gender:Male
  • Location:Karachi, Pakistan
  • Wiki edits:4,411
QUOTE (FraGag @ Jul 23 2010, 04:14 AM)
I definitely agree for the zones/acts constants. For GameModeIDs, I'm not sure; on one hand, as ICEknight said, acronyms/abbreviations may be cryptic until you look them up. On the other hand, they always get moved to Game_Mode. Having "game mode" spelled out twice on the same line is redundant, but then shortening "GameModeID" to "GMID" can lead to conflicts if something else is shortened to "GMID". That said, then I made all those IDs, I used shorter names for the others, so we might as well just go with GMID...

All right, cool. What about the button constants?

#74 User is offline ICEknight 

Posted 23 July 2010 - 10:38 AM

  • Posts: 8836
  • Joined: 11-January 03
  • Gender:Male
  • Location:Spain
  • Wiki edits:18
QUOTE (SOTI @ Jul 22 2010, 06:18 PM)
A universal labelling scheme would make some matters easier for both SVN disassemblies. This would at least make a start to it.

...Perhaps we could start by using the known labels from the original source files by Sonic Team? We have a few of them, don't we?

#75 User is offline Andlabs 

Posted 23 July 2010 - 10:56 AM

  • 「いっきまーす」
  • Posts: 2175
  • Joined: 11-July 08
  • Gender:Male
  • Project:Writing my own MD/Genesis sound driver :D
  • Wiki edits:7,061
We have label names found in the symbol tables of the S&KC exe. That said, I dunno if a universal naming scheme would extend nicely to other games. Maybe it should stay with S1-3K only, but first we need to finish up our S&K split. And even if we do that, would having to abandon descriptive labels for the somewhat constrained ones Sonic Team used be worth it?

As far as abbreviations go, I don't see how abbreviating zone names would not be common sense. As far as everything else goes, you are probably better off leaving them alone.

  • 8 Pages +
  • ◄ First
  • 3
  • 4
  • 5
  • 6
  • 7
  • Last ►
    Locked
    Locked Forum

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