[Clownacy]

Something needs to be done about the zonewarning macro. Its constant outputting of warnings continues to mess with the log output. I could disable the build halt in build.bat when a log file is detected, but I'm thinking of something more direct. That macro's annoying: it hides all of the real errors in a sea of ohnotheendingisntproperlyimplemented, and I've seen it confuse and even drive away Hivebrain users looking to migrate. I can't think of any fixes that aren't hackish and/or completely miss the point of the macro (have a flag for if the list is meant to contain the ending, that stuff).

While I'm at it, the music and sfx macros are almost pointless too. There only exist ones for jsr/jmp, not bsr/bra or even ones for if the move is a byte... Then again, I think I can repurpose those so that a variable at the top of sonic.asm can optimise them all. I think I can cover those macros.

So, any ideas on tackling this zonewarning over-warning problem?

This post has been edited by Clownacy: 05 August 2014 - 07:41 AM

[MainMemory]

I'd have separate macros for with and without the ending.

[Clownacy]

Yes, that's probably the best way. It's just, the macro's there to tell you when something doesn't support all 7 zones, but the thing is that that's always going to be the case, unless you were to revamp the ending.

music and sfx macros have been expanded. Their usage isn't as simple anymore since you can't leave any arguments undefined. I dunno, it was going to happen eventually. It's a macro, all it'd do is make usage more complicated with the upside being batch modification. Speaking of which, an optimisation is in place. It's nothing too great, I don't know how to calculate when to use a branch over a jump through a macro (especially asm68k macros), so the only optimisation there is to force all moves to use byte-sized operands. I would say that since the input is always 8 bits, moveq would be appropriate, but apparently it sign extends the byte to a long. By default, all sound IDs are $80+ so that 8th bit would be set... In my testing, moveq had no negative effects, but I'd rather play it safe. I still don't know if, when d0 is moved to RAM, the sign bit is moved back into the byte space.

Thinking back to it, the usage of move.b may be in vain: It seems that the execution times of a move.w and a move.b are the same, and the size doesn't differ, either. I probably shouldn't have doubted Regen and stuck with moveq.

[Clownacy]

Since the disassemblies page lists it among other non-historical disassemblies, would it be right for there to be an up-to-date GitHub Project Two-Eight branch of the S1 disasm? The official one that's hosted on info.sonicretro is based on the historical Hivebrain disasm, and contains a major bug/oversight in which the good ending doesn't have the layout change when the emeralds vanish. I'm not talking Kraminator Special or anything like that, just the conversion to the 128x128 chunk system.

I've already created a Two-Eight disasm based on a newer copy of the Git disasm, and it seems to be too extensive to just cram into a guide. It probably could be done but... it sounds like it would be one of those pain-in-the-ass guides that you'd have to follow every time you start with a fresh disasm.

On a similar topic, again about the S1 disasm, what should be done if someone wants a MapMacros disasm using the AS Macro Assembler? Should there be a branch that combines the two, or is there an easy way for the user to merge the features themselves?

This post has been edited by Clownacy: 12 August 2014 - 08:45 PM

[MainMemory]

You can't easily combine the MapMacros and AS branches, because you would need the AS version of the SpritePiece.asm file, and some mappings files contain ASM68K-specific syntax to ensure bit-perfectness when entries point into the middle of other entries.

I think ideally all the mappings files would be using the macros, but that renders them unreadable by SonMapEd.

To the part about Project Two-Eight, I think it might be a bit beyond the scope of the repos, but then again one could say the same for the S&K disassembly being able to build a full S3K ROM.

This post has been edited by MainMemory: 13 August 2014 - 12:12 AM

[Clownacy]

Holy cow, finally! The fustercluck that is Git Project Sonic 1: Two-Eight is complete. It's hard to evaluate your changes when the changelog alone is a small book! The branch's name is big and clunky, but I preferred it to be descriptive instead of brief, though I won't stop any changes to it.

Rambling:
It's based on the master (asm68k) branch, at least until hybrid branches become a thing.
There was a bug mentioned here that existed in both the original Two-Eight and King's updated version, but it's been fixed in this one. The cause was dodgy object definitions for the path-switchers at the height of the loops (they're meant to be ground-only but weren't).
Code has been optimised from the original Hivebrain-based source in several areas.
The path-switchers have had a feature added from the S2 betas: With the debug cheat enabled, the path-switchers are visible (using ring graphics) and, when crossed, play the checkpoint sound. It really is a practical feature! It's strange that it was took out in the first place.
The original Two-Eights missed some areas when it comes to dynamically modified layouts: The LZ splash object checks for if the LZ3 layout has been modified, and the good ending attempts to modify two 256x256 chunks. These instances have been fixed.
SonLVL and SonED2 (non-v1.0x) compatibility is there. v1.0x didn't seem to have a mix-and-match format system, so I couldn't make that work. Both programs can modify the good ending (post-emerald vanish) and LZ3 (when the wall is gone).
SYZ's background is a little messed up. The number of chunks had to be reduced, and the background took a blow because of that. This has been a problem since the original Two-Eight. Both REV00 and REV01 now use the same background layout.

This post has been edited by Clownacy: 15 August 2014 - 03:20 PM

[MainMemory]

All AS-using disassemblies now generate listing files by default, which makes it much easier to see the addresses of labels, while not being nearly as time-consuming as generating a MAP file (in fact, a listing file hardly affects assembly time at all).

[Clownacy]

A revision toggle has been added to the S2 disasm. Now both REV01 and REV00 can be built.

The build.bat file has been modified to produce a ROM even if there are warnings. This is because REV00 causes one by default, making it otherwise unbuildable.

[Clownacy]

Little late in saying this: Sonic 2's disasm can now build REV02. A bunch of additional toggles have been added to make this work, most of which are linked to the allOptimizations option, because who wouldn't want to get rid of those awful JmpTos?

Currently, these optimisations are limited to how well they were done in REV02, and could stand to be improved, while allowing the inferior REV02 way for bit-perfection reasons. For example, REV02 tries to optimise as many add/subs to addq/subq as possible, but misses a few. The same applies to the JmpTo removal.

[D.A. Garden]

Somewhat of an odd question but I'm curious; if it can now build REV02, does this include the broken Wing Fortress Zone rising/falling staircase platforms that, for some reason, were broken in REV02, but not REV00 or REV01? This is the only new issue I can think of right now that arose between them.

[Clownacy]

The what? That's news to me. But, the built ROM is bit-perfect to the ROM extracted from Sonic Compilation, so everything should be there. There's also this bug, which was pointed out in the disasm.

This post has been edited by Clownacy: 15 February 2015 - 09:47 AM

[flamewing]

Just leaving this here, for the n00bspeople that are new to Git: some very good tutorials explaining Git stuff, from basic to advanced. Note that when they do mention BitBucket and/or Atlassian's own tools, all of it also applies to GitHub as well. Might worth putting on the OP.

[MainMemory]

I've added that link to the OP.