[Bgvanbur]

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:

based on asm-2.0b5.zip
changes to asmx.h, asmx.c, and asm68k.c

68k changes

unopt (all of which make warnings when could make optimization)
make 0(a0) use a word for 0x00 displacement
always use Bxx.W for Bxx with no size specified
Bcc.1 and Bcc.2 support
clear upper byte of word for immediate byte instructions
added warning to addi/subi when quick instruction possible
added warning to move.l #<data>,Dn when quick instruction possible
added warning to cmpi #0 when tst is possible
added warning when instruction size is w/l and abs operand is odd
added warning when instruction size is w/l and d16(pc) is odd
added opt flag that this processor is word aligned

asmx changes

-u unopt support, currently only used by 68k
-n allows using narg in macros and \0 now is the macro suffix
-m allow multiply defined labels
adds -pu0, -pu1, -pa0, -pa1, -pd0, and -pd1 to control the padding for unused values, align, and ds
label support for if
better padding support for large pads (ds,bsz,fill)
added pad commands: bsz,zmb,fill
added conditional commands: endc,ifdef,ifndef,elsifdef,elsifndef
added align commands: balign,cnop
added ds aliases: blk.b,blk.w,blk.l,blkl,dcb.b,dcb.w,dcb.l,space
added repeat aliases commands: endr,rept
align can specify the fill value (second argument)
allow whitespace label colon to be use the label
if a file is not readable, try converting between / and \ and vice versa
if an equ has a unknown value on pass 1, call AddSym instead of DefSym
if processor is word aligned, add warning when not word aligned on word/line defines or pads

[FraGag]

_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)

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.

[Hivebrain]

The whole point of local labels is that you can use the same word again and again.

[Bgvanbur]

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.

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 see you've changed several local labels to avoid identical names. Is this a limitation in asmx? Does it support local labels at all?

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.

This post has been edited by Bgvanbur: 12 November 2010 - 09:10 AM

[FraGag]

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.

No, this is the only difference between the original ROM and the s1built.bin produced by asm68k.

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.

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.

[Bgvanbur]

No, this is the only difference between the original ROM and the s1built.bin produced by asm68k.

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

[Andlabs]

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?

[Hivebrain]

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?

That's fine. The Z80 part is compressed though, so it wouldn't be recompilable.

[Bgvanbur]

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.

[Xenowhirl]

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?

That's fine. The Z80 part is compressed though, so it wouldn't be recompilable.

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.

[FraGag]

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!

[MainMemory]

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

[The Prof]

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.

[MainMemory]

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.

[KingofHarts]

MainMemory, on 03 February 2013 - 10:03 AM, said:

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.