Sonic 1 Disassembly

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.

 

I love you! I've been waiting for this for over 3 years. =D

 

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.

 

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

 

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

 

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:

 

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.

 

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.

 

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.

 

Thanks for the info. I have reverted my change to the exg.

 

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?

 

I would love to see this included.

 

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.

 

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!

 

Just pushed a new "MapMacros" branch which converts all sprite mappings to my macros while preserving bit-perfect builds.

 

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.

 

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.

 

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.