Fixing an Odd Issue with the Sonic 2 Xenowhirl Disassembly

Lately, I've been messing with the continue screen, and I've noticed that when I had more then one continue, it crashed. after some back tracking and sniffing around, I found the issue to be neither my fault or Sonic teams fault, but rather, a horrifically atrocious issue involving the Xenowhirl Disassembly itself. If your using the Xenowhirl disassembly, follow this guide immediately, if you haven't fixed the issue already. Failure to do so will result in the Continue screen suffering from horrible issues (like, as I mentioned before, game breaking freezes and crashes). This has of course already been fixed in the Github disassembly, so if you're using it, don't worry; this doesn't apply to you.

Go to "loc_7AF8:". You should see the following code.

_move.b #$DA,0(a1) ; load objDA
move.w (a2)+,x_pixel(a1)
tst.b d2
beq.s +
subi.w #$A,x_pixel(a1)
+
move.w #$D0,y_pixel(a1)
move.b #4,mapping_frame(a1)
move.b #6,routine(a1)
move.l #$7CB6,mappings(a1)
move.w #$8524,art_tile(a1)
bsr.w JmpTo_Adjust2PArtPointer2
move.b #0,render_flags(a1)
lea next_object(a1),a1 ; load obj addr
dbf d1,loc_7AF8
lea -next_object(a1),a1 ; load obj addr
move.b d3,subtype(a1)

Replace

move.l #$7CB6,mappings(a1)

With

move.l #ObjDA_MapUnc_7CB6,mappings(a1)
That's it; the continue screen will function normally.

Why is this an issue, you ask? Well, as many of you know, the Xenowhirl disassembly hasn't been "refined" as much as other disassemblies like the Github one, so it has some oddities and not-so-user-friendly things floating around it. This appears to be an issue that fell through the cracks during the disassemblies creation; instead of changing the mappings pointer to the name of the label here, like with all the other mappings, this still uses a raw value. This means that if you add or remove a single byte or more from any code, level art, mappings, etc., the entire game will be off-shifted, and this one broken mappings pointer will no longer point to it's appropriate mappings; instead, it will likely run into useless gibberish, causing the game to fall apart the moment it attempts to display the "Mini Sonics" or "Mini Tails" which hover above the continue screen, displaying the amount of continues you have.

 

This might actually help explain that one HTZ bug I had forever ago and couldn't fix. When the Special Stage code is deleted, HTZ's art gets fuxed up.
Perhaps this tutorial indirectly explains the cause. I thank you, good sir, for a potential reason the bug happens; it's one I've been trying to tackle ever since the old versions of my hack.

 

This bug is very old news. Although I'm surprised that it hasn't been fixed already before you go to download it. Also, I'm pretty sure there's another object with the exact same issue in Xeno but I cannot remember which one it is.

 

Would it be worth someone applying this fix to a new Xenowhirl disassembly and updating the one on Retro? That way, there's no fix needed. I think something was done similar with the Sonic 1 ASM68K, when the old ASM68K didn't work properly (didn't allow long directory names or something).

 

Yes Dandaman, according to ASM68K itself (provided with the disassembly, you can open it with any text editor), Nemesis took on the job and fixed it up. I would hope there was a decompiled code of the assembler around somewhere, so we could take a look at some other nasty "bugs" or inconveniences with it, but I haven't seen around even with google searches and if there is one, then that's probably with Nemesis himself.

 

Yeah. Back in 2010 when I started hacking in assembly, the non-Nemesis edited versions didn't work for me because it would have to be placed in the C:\ directory or it wouldn't work, which resulted in a lot of people just using SNASM68K. Other people seem to have it for some reason. Eventually this file got replaced with the Nemesis variant.



:')

 

@ThomasSpeedrunner: Possibly, although instances of this are obviously quite rare. Good luck finding the problem!

@redhotsonic: I wasn't aware that was supposed to be common knowledge. Seeing as I've been on the hacking scene for a little over a year now, and have been working with S2 for quite some time, I feel this was important so that those who weren't aware could fix it. Also, I would love to know which other object has this problem (I could add it to the list, and fix it in my own hack; I hate this annoying little issue :|)

 

​The original version of the disassembly should be kept for historical purposes.

Also, there's already an updated version of the disassembly.

 

But does that not mean we could not provide a download for a disassembly with some common bugfixes (such as this one) applied, for users convenience? Or you propose everyone should fix this each time separately or user the Git version? I don't really see point in the latter over the former.

 

I've actually been considering pulling up a blank Xenowhirl Disassembly and adding in a few features/labels/bug fixes from my S2 hack as well as the Github disassembly (Not the dumb or confusing stuff, though, just like replacing lists of dc's with clarifying macros types of things). I haven't gotten around to it yet, but when I do, I'll be sure to release it when I do. It won't be ReadySonic, I won't add a switch to turn knuckles on or anything like that, it'll just be a better Xenowhirl Disassembly.

 

Improving the Git disassemblies is also an option, guys. Eight years of refinement isn't worth being thrown away just because somewhere along the line something 'dumb' happened.

 

Clownancy, just because you prefer Git, does not mean everyone must use it, some people may like Xeno more. Of course in case of the Git disassembly for Sonic 2 is in many ways better (unlike Sonic 1 Git, which is more or less not usable), but some of the things in it make it harder to use or get used to. If people wish to use or modify the Xeno disasm, why you should bother to stop them, they are not doing any harm to really anyone, but improving the user experience for some (potential Xeno users). I think this "battle" over which disassembly is the better one is simply redundant because all people have their preferences, and we should allow them to express it.

 

Stop twisting everyone's words. Neither MainMemory or I objected to separate continuations. Also, that's not my username.

 

Both disassemblies have their pros and cons, and since it all goes down to opinion, it's better to have more disassemblies then the one. My goal was just to give those who prefer the Xenowhirl disassembly (myself included) a better version of it, with less issues like the one this topic started with. Plus, going back and "reverting" changes on the Github disassembly seem like it could cause edit wars or something... Not too sure about that one, as I don't really use Github in general, but you get the point.

EDIT: Don't start posting about why disassembly A is better then disassembly B. This is not a disassembly war, and if anyone starts one, I'll lock this topic without warning. Everyone has their opinions, and repeating what is already known won't change them.

 

Well, if it's reverting significant changes... The same could be said about assembler. Both the Hivebrain and Git S1 disasms saw use of asm68k. Both eventually got ported to assemble under AS. Thing is, these AS versions never replaced the originals. MapMacros didn't replace the default and break compatibility with SonMapEd, and it could be said that Git never replaced Xeno (after all, it's still available and heavily advertised).

But, anyway, my earlier point was that, if your dream disasm is Xeno with changes Git already has - changes that are very wide-span and difficult to merge manually, like the mass labeling changes - it sounds like it would be easier to just change the Git disasm to fix whatever's so bad about it. But, like I said, if the changes are akin to stripping elements, which would be fairly controversial, then make it a branch (or fork. Not sure what the right word is).

As much as I hate the idea of what was done to the S1 disasm, I know having its main ASM file split can be good to some, bad to others. That's why, when a serious suggestion was made for the Git S2 disasm to follow suit, I recommended such a change be kept to its own branch, so both parties can be happy, and one won't have been robbed of their coding style in favour of the other.

Of course, replacing a file, apparently only kept for historical reasons, is wrong for a whole other set of reasons. Don't take it the wrong way.

 

If it's for historical purposes, then of course leave it. At least now most people will be aware of the error (and if not, when they come to seeing the continue screen not working, they'll look for a fix and will find this).

Issue is, there's no perfect disassembly for everyone; you just have to find the one you most prefer or suits your needs; whether old or new. Mine is Xeno, Clownacy is Git, and I respect why he prefers Git, and I'm sure he respects why I prefer Xeno. End of the day, if you make a great game out of using it, who cares  

 

If I can just bump this topic back up to point out another Xenowhirl mess-up...

loc_A3DA:
ori.b #$7C,d4
lea (ObjB2_SubObjData).l,a1
ObjCC, loc_A3DA is supposed to be an offset table, yet, in Xenowhirl, it's been disassembled into instructions. Namely, 'ori.b #$7C,d4'. The proper data, as corrected in the Git disasm, is...

loc_A3DA:
dc.w loc_A3DE-loc_A3DA
dc.w loc_A456-loc_A3DA
; ===========================================================================

loc_A3DE:
lea (ObjB2_SubObjData).l,a1
This also means that the unused code above off_A468 isn't actually unused, and is, in fact, loc_A456.

 

Turns out loc_A3DA wasn't the only one. loc_132FE is also a broken offset table. The first entry should point to loc_13302, and the second should point to the "unused/dead code" above return_1337A.