don't click here

Sonic 1 Disassembly

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

  1. JoseTB


    Tech Member
    Took a quick look on the project, just out of curiosity. I like the direction it's taking so far, but some suggestions for the variable naming:

    I would rename these to v_hscrolltablebuffer and v_spritetablebuffer, since they aren't the actual sprite table or hscroll table data, but a mirror that is copied, I think once every frame, during the vsync, I don't fully remember the details.

    I would change this to the following since it's not entirely correct:

    Aditionally I'm gonna suggest to use another prefix after the "variable" or "flag" identifier for the "environment" in which the variable is used. For instance: v_level_rings, v_camera_screenposx, v_snd_fm1_ptr, v_pal_fadestart - you get the idea. Also, the prefix "v" for "value" could be extended to specify the variable length (b, w, l, or array)
  2. NeKit


    Sonic SCANF
    Looks like I have found a bug. When time is 9 minutes, and you have more than 0 rings, the time counter label doesn't swap red/yellow colors, it just stays yellow.
  3. Alriightyman


    I am back... from the dead! Tech Member
    Somewhere in hot, death Florida
    0101001101101111011011100110100101100011 00000010: 0101001100000011 01000101011001000110100101110100011010010110111101101110
    I just had to comment on something. Having played around with this disassembly, the only thing I find annoying, as of now, is with mappings. For those of us who use SonMapEd, you would get an error for replacing them and would have to re-add the label to it in the included file. In the old disassembly, they were labeled then included. I think it would be better if it were the other way around. Just a thought though. :) Other than that, I really like the way this is headed.
  4. Spanner


    The Tool Member
    Okay, what pisses me off with this disassembly is that previous labels aren't referenced. If possible, could a list be added to the disassembly containing the original 2005 labels and the current ones. You could also contribute to the SCHG:Equivalent Subroutines.
  5. Hivebrain


    53.4N, 1.5W
    Thanks. I'll make those changes in my next update.

    I thought about that, but I'm not keen on adding lots of extraneous labels. Maybe we could beg Xenowhirl to make a version that preserves labels.

    Many labels were changed because they were inaccurate, unhelpful or just plain wrong. I've no intention of putting them back. However, I will add labels from the latest S2 disassembly.
  6. Andlabs


    「いっきまーす」 Wiki Sysop
    Writing my own MD/Genesis sound driver :D
    Question: why is the asm68k error log redirected to errors.txt? Logging errors to a file doesn't show anything on the console (not even an "assembly failed with errors; see error.txt for details" message), and there's no error checking in the build.bat file, so I can never be sure unless I cat error.txt each time to make sure it built right.
  7. Hivebrain


    53.4N, 1.5W
    I find errors.txt extremely useful. What's the alternative?
  8. Andlabs


    「いっきまーす」 Wiki Sysop
    Writing my own MD/Genesis sound driver :D
    I can see how errors.txt is useful, but the problem is that when you have it on, asm68k doesn't report anything to the console, and there's no error checking so the rest of the batch file runs, so you'll never know whether or not the build succeeded until you play your ROM, realize it didn't change, then check errors.txt. If we could do something like

    Code (Text):
    1. asm68k blah blah blah
    2. if errorlevel 1 goto error
    3. rem rest of stuff
    4. goto end
    5. :error
    6. echo build failed; see errors.txt for details
    7. :end
    this problem would go away.
  9. FraGag


    Tech Member
    Or just add
    Code (Text):
    1. type errors.txt
  10. While doing some bits here and there for my SMPS player, I came across this code snippet:

    Code (Text):
    1. word_72790:     dc.w $25E, $284, $2AB, $2D3, $2FE, $32D, $35C, $38F, $3C5
    2.                 dc.w $3FF, $43C, $47C, $A5E, $A84, $AAB, $AD3, $AFE, $B2D
    3.                 dc.w $B5C, $B8F, $BC5, $BFF, $C3C, $C7C, $125E, $1284
    4.                 dc.w $12AB, $12D3, $12FE, $132D, $135C, $138F, $13C5, $13FF
    5.                 dc.w $143C, $147C, $1A5E, $1A84, $1AAB, $1AD3, $1AFE, $1B2D
    6.                 dc.w $1B5C, $1B8F, $1BC5, $1BFF, $1C3C, $1C7C, $225E, $2284
    7.                 dc.w $22AB, $22D3, $22FE, $232D, $235C, $238F, $23C5, $23FF
    8.                 dc.w $243C, $247C, $2A5E, $2A84, $2AAB, $2AD3, $2AFE, $2B2D
    9.                 dc.w $2B5C, $2B8F, $2BC5, $2BFF, $2C3C, $2C7C, $325E, $3284
    10.                 dc.w $32AB, $32D3, $32FE, $332D, $335C, $338F, $33C5, $33FF
    11.                 dc.w $343C, $347C, $3A5E, $3A84, $3AAB, $3AD3, $3AFE, $3B2D
    12.                 dc.w $3B5C, $3B8F, $3BC5, $3BFF, $3C3C, $3C7C
    I noticed something similar. Then I looked and... It's the FM note values present in the RAM. I've made a little table:

    Code (Text):
    1. 025e = (b-0)
    3. 0284 = c-1
    4. 02ab = c#1
    5. 02d3 = d-1
    6. 02fe = d#1
    7. 032d = e-1
    8. 035c = f-1
    9. 038f = f#1
    10. 03c5 = g-1
    11. 03ff = g#1
    12. 043C = a-1
    13. 047C = a#1
    14. 0A5E = b-1
    16. 0a84 = c-2
    17. 0aab = c#2
    18. 0ad3 = d-2
    19. 0afe = d#2
    20. 0b2d = e-2
    21. 0b5c = f-2
    22. 0b8f = f#2
    23. 0bc5 = g-2
    24. 0bff = g#2
    25. 0c3c = a-2
    26. 0c7c = a#2
    27. 125e = b-2
    29. 1284 = c-3
    30. 12ab = c#3
    31. 12d3 = d-3
    32. 12fe = d#3
    33. 132d = e-3
    34. 135c = f-3
    35. 138f = f#3
    36. 13c5 = g-3
    37. 13ff = g#3
    38. 143C = a-3
    39. 147C = a#3
    40. 1A5E = b-3
    42. 1a84 = c-4
    43. 1aab = c#4
    44. 1ad3 = d-4
    45. 1afe = d#4
    46. 1b2d = e-4
    47. 1b5c = f-4
    48. 1b8f = f#4
    49. 1bc5 = g-4
    50. 1bff = g#4
    51. 1c3c = a-4
    52. 1c7c = a#4
    53. 225e = b-4
    55. 2284 = c-5
    56. 22ab = c#5
    57. 22d3 = d-5
    58. 22fe = d#5
    59. 232d = e-5
    60. 235c = f-5
    61. 238f = f#5
    62. 23c5 = g-5
    63. 23ff = g#5
    64. 243C = a-5
    65. 247C = a#5
    66. 2A5E = b-5
    68. 2a84 = c-6
    69. 2aab = c#6
    70. 2ad3 = d-6
    71. 2afe = d#6
    72. 2b2d = e-6
    73. 2b5c = f-6
    74. 2b8f = f#6
    75. 2bc5 = g-6
    76. 2bff = g#6
    77. 2c3c = a-6
    78. 2c7c = a#6
    79. 325e = b-6
    81. 3284 = c-7
    82. 32ab = c#7
    83. 32d3 = d-7
    84. 32fe = d#7
    85. 332d = e-7
    86. 335c = f-7
    87. 338f = f#7
    88. 33c5 = g-7
    89. 33ff = g#7
    90. 343C = a-7
    91. 347C = a#7
    92. 3A5E = b-7
    94. 3a84 = c-8
    95. 3aab = c#8
    96. 3ad3 = d-8
    97. 3afe = d#8
    98. 3b2d = e-8
    99. 3b5c = f-8
    100. 3b8f = f#8
    101. 3bc5 = g-8
    102. 3bff = g#8
    103. 3c3c = a-8
    104. 3c7c = a#8
  11. Hivebrain


    53.4N, 1.5W
    For those who haven't noticed, I've been updating the disassembly again recently. The latest things I added are long conditional jumps for when beq and suchlike are out of range. Here's an example:

    Code (ASM):
    2. jeq:        macro loc
    3.         bne.s   @nojump
    4.         jmp loc
    5.     @nojump:
    6.         endm
  12. That's a pretty damn cool idea, it'll make fixing out of range errors much easier for people who are new to ASM. (Or maybe not, since most of them seem to prefer using a 5 year old disassembly instead :/)
  13. Mercury


    His Name Is Sonic Tech Member
    Location Location
    Speaking of the Sonic 1 Disassembly, I've noticed that the obHeight and obWidth constants are incorrectly named - they need to be reversed: obHeight to obWidth and obWidth to obHeight.

    I'm not exactly sure how to do this myself as I've never updated the SVN before.
  14. amphobius


    doing more important things with my life Member
    Problem being there aren't any references to the old labels. Additionally, most guides use the 2005 dissasembly, too.
  15. Spanner


    The Tool Member
    This is the main problem why people aren't using this disassembly. The Sonic 2 SVN disasm references old labels, the 2005 labels could at least be referenced. Also, I'm sure most people would rather have a quick download rather than having to set up a SVN client for the latest version.

    As for the guides, that is true. Most people are used to the 2005 disassembly and they will probably use it until issues with the SVN disasm are fixed. Then, guides can be rewritten for the SVN disasm.
    And once that happens, somebody can fill up SCHG:Equivalent Subroutines
  16. Hivebrain


    53.4N, 1.5W
    Are you sure about that? The Sonic 2 disassembly has $16 as width and $17 as height too.
  17. Code (ASM):
    1. y_radius =      $16 ; collision width / 2
    2. x_radius =      $17 ; collision height / 2
    The labels are right, the comments are wrong (width and height are switched around). I just fixed that in the S2 SVN, it should be fixed in this too.
  18. MarkeyJester


    Original, No substitute Resident Jester
    I'm pretty sure the reason is because the older disassemblies are generally easier to obtain and setup, there as SVN (having to be downloaded individually unless an SVN client is being use (Which most who aren't deep within the community tends not to use anyway)) is not as easy. And my reason for not using Sonic 2 SVN is because of it's complexity, long lable names, macros' which make it easier but not understandable, and having the lables from the older disassemblies leaves it looking like a complete mess, and messy code tends to make the programmer feel less incline to work on their project, it's like climbing a mountain and seeing that what's up ahead is more bumpy than expected.

    As for the conditional jumps, not a bad idea and pretty genius, though I can see it being used in places where something more optimal could be written insted and have the same effect.
  19. Spanner


    The Tool Member
    Just noticed that you uploaded the SVN version on the wiki. Are you going to manually upload the latest version every month as an attempt to get more people to use the disassembly?

    It's a good idea considering that the WebSVN downloads never work, but again, more people are used to the 2005 disasm.
  20. Hivebrain


    53.4N, 1.5W
    I've fixed the obHeight/obWidth issue, and created a downloadable copy of the disasm here:

    Labels from old disassemblies will not be restored, because they're incorrect in many cases, and they make things look cluttered as MarkeyJester said.