Split REV00 and REV02 into their own branches

[Clownacy]

One thing I've heard people really don't like about this disassembly is all the macros and constants. One area I think this can be streamlined is the revision differences:

In order to get three revisions to build from the same codebase, I've had to add some monsterous macros like jmpto/jsrto and rev02even, and they really clutter the code. Not to mention, they're completely unnatural (the original source code sure as heck didn't need these things).

So, I figure, since I was already planning to give Knuckles in Sonic 2 its own branch when I get around to it, because of its massive number of changes, why not do the same for REV00 and REV02?

Admittedly, the other branches (like MapMacros) would become REV01-only. Still, anyone that knows how to use Git can just merge them themselves.

[flamewing]

The original source may not have need these things, but we do. I kind of like the jsrto/jmpto macros because they allow some optimization of original S2 without having to manually hunt down the trampolines.

And people that dislike the S2 disasm because of macros will still dislike it without the jsrto/jmpto macros, because there will still be plenty of macros left.

You may consider doing KiS2 in a manner similar to S3&K disasm: having two possible builds, one where you build the plain UPMEM ROM (which needs to be appended to a combined S&K+S2 to be used, and the S2 data is only pointers), or a S2&K-complete version which does not have duplicate code and assets.

[Clownacy]

Yeah, I was thinking of the KiS2-complete thing, too.

I know splitting the disasm wouldn't magically 'fix' it, in their eyes, but it was more of a personal preference of mine, since that's the one place I agree with them, that it might have gone a bit too far. A bit like the 'sfx' and 'music' macros in Sonic 1 Git. Sure, they allow for bulk conversion of all PlaySound calls, but it seems a bit extreme considering the original source didn't do it, and anyone unfamiliar with the disasm wouldn't know how to use it, right away.

If you want the choice of having the JmpTos or not, why not just use the REV02 branch?

[GabrielRavier]

"considering the original source didn't do it" How do we even know that ?

[Clownacy]

I think it's safe to say that the 'JmpTo's and 'rev02even's are assembler-generated. From the peek we've seen at Sonic 2 Nick Arcade's source code, we can tell that the game's source code was sorted into individual object files, which were then linked together to form a final ROM. The JmpTos are that linker data.

As for the rev02evens, many assemblers (including the one we use for this disassembly) have an option to pad out dc.b instructions to avoid odd address alignment. Chances are, when REV02 was made, someone changed a few of the assembler's settings, causing these differences.

The original source code didn't need JmpTo/JsrTo or rev02even macros, because they were a feature of the assembler. Since we use a different (and likely better) assembler, we have to resort to emulating it, which is extremely messy.

[IntelOrca]

In the past I have uploaded archived source code that were of multiple versions. What I did was commit the first version, then the next version etc. That way the diff between the commits shows what changed between one version and the next. The commits can be tags rather than branches.

The only downside is that those old revisions will no longer receive updates, e.g. updates to symbol names and comments etc. But are the old revisions needed other for historical purposes? I imagine hacks would be made on top of the latest revision.

[Clownacy]

REV02 introduces a number of bugs (edit from the future: this is false), making REV01 debatably the more stable version. Granted, it does fix some bugs too, but there are already guides that fix those. If I remember right, there are no guides for fixing REV02's bugs, since people are just used to hacking REV01, so forcing REV02 on people by default could lead to more bugs sneaking into hacks.

[IntelOrca]

If REV01 is the definite version then could we make that the master and have macros which just enable the fixes introduced in REV02 which people can then enable if they want them?

Is REV01 the cleanest in terms of number of jumptos etc.?

[Clownacy]

The macro thing is what the disasm currently uses. I just find it a very messy solution that we need fake instructions like jmpto and jsrto to pull it off.

REV02 is the cleanest when it comes to JmpTos, since it 'inlines' the redundant ones.

[Clownacy]

Huh. Looking back at this four years later, I don't agree with this at all: I think the three revisions should all go in one branch. Ideally, the jmpto, jsrto, and rev02even macros can be refined, possibly transparently overriding the 'jmp', 'jsr', 'bra', 'bsr', and dc.b instructions instead of being their own thing. I'm trying to figure out what exactly causes a JmpTo to be generated, so that I can do this myself, but I'm stuck at the moment.

[GabrielRavier]

Gotta say I also do think it makes a lot more sense for all three revisions to be in the same branch.

[FraGag]

I'm trying to figure out what exactly causes a JmpTo to be generated, so that I can do this myself, but I'm stuck at the moment.

My hypothesis has always been that Sonic 2 was built from multiple modules that were assembled separately then linked together (just like with C code, .c files are compiled separately then linked together), and the linker was emitting the JmpTo's at the end of a module when necessary.

[Clownacy]

We've been discussing it in #4, and it seems that that's only part of it: it also seems to be a form of automatic branch range extension: if a branch is determined to be out of range, it gets aliased to a JmpTo... but not always, which is what's stumping me at the moment.

[Clownacy]

Huh. Looking back at this four years later, I don't agree with this at all: I think the three revisions should all go in one branch. Ideally, the jmpto, jsrto, and rev02even macros can be refined, possibly transparently overriding the 'jmp', 'jsr', 'bra', 'bsr', and dc.b instructions instead of being their own thing. I'm trying to figure out what exactly causes a JmpTo to be generated, so that I can do this myself, but I'm stuck at the moment.

Boy, do I just love flip-flopping on this! Many of the points that I raised in #76 also apply here, so once again I think that the revisions are better off being split to their own branches.

The added clutter of supporting multiple revisions wouldn't be anywhere near as bad if they were extremely minor, like an altered line of code here and there, but REV00 requires alternate object layout files, which not only complicates the file tree, but also requires that a second SonLVL .INI be provided just for REV00, which I am certain that nobody has ever actually used in the 10 years that it has been there.