sonicretro / s1disasm Goto Github PK

Enigma Decompression.asm is currently undocumented, unlike Kosinski Decompression.asm.

The Sonic 2 disassembly has a documented Enigma decompressor, and although they have slightly different code, they both share the same code structure.

With the way the macro is set up, let's say you do an "align 2" at an even address. Instead of ignoring it, it will pad an extra 2 bytes. Of course, the larger the alignment value, the larger the unnecessary padding (yes, I know with larger values, it ends up being a rarer occurrence, but still).

Using "(\1-(*%\1))%\1" should prevent this.

This is more of a suggestion, but shouldn't we use "PlayMusic" and "PlaySound" instead of "PlaySound" and "PlaySound_Special"? I'm saying this because, although used interchangably in Sonic 1, the Nick Arcade symbol tables suggest they are meant to be specific, while the labels here suggest they're meant for "sounds" and "special sounds".

(search "bgmset" and "soundset"; their locations match-up near perfectly with Sonic 1

I’ve been trying to make stuff with this and so far the two branches I’ve tried just don’t work.
They are the master and AS branch. What is strange is that older versions break as well. I can’t tell if this is a problem for everyone or just me.

A while ago, I made a commit that added a new macro, zonewarningnoending. This was because the original version, zonewarning, led to a bunch of warnings stemming from how not everything accounted for the ending. The ending itself is a huge hack, not being properly integrated, which led to the old warnings.

I don't think there's a point in trying to error-proof something that's already broken. I'm thinking of just removing zonewarningnoending, and changing zonewarning to only check actual zones.

I can understand this for Windows and possibly Mac OS, but isn't distributing binaries a bad idea for Linux? I mean, we'll never provide up-to-date binaries for every platform out there, but a system like s2disasm's (where the build script compiles the tools on its first run) would support just about anything with GCC on it.

These contain VRAM addresses that have still yet to be made to use the 'ArtTile' constants from Constants.asm.

While I can keep the Windows 'exe's up to date, I don't think I can do anything for OS X and Linux. OS X seems to still use the original p2bin instead of the modified s1p2bin. This has been made even messier with the inclusion of build-time DAC driver compression and s1p2bin_plus, which effectively renders OS X totally incompatible.

• Windows
• OSX
• Linux

I recently scanned the disassembly through VirusTotal, and one of the antivirus engines detected that it contains “BehavesLike.Sality.tc”. Is that a false positive?

I tried this on my Arch installation, only for it to mysteriously fail. After some digging, it turned out s1p2bin was outdated, and bailing since it didn't support the Z80 driver being in more than one segment.

I suppose this ties into #24. I don't have a 32-bit Linux installation anymore, and the guy I used to ask for Mac builds doesn't own a Mac anymore.

• Windows
• Linux 64-bit
• Linux 32-bit
• macOS

A handful of label names in relation to block drawing functions are misleading/incorrect.
For instance, the subroutine on line 4,870 labelled as "DrawBlocks" actually retrieves block mapping data based upon the camera's coordinates, and given horizontal and vertical positions relative to the screen. The actual function for drawing a block, found on line 4,783, is labelled as "DrawTiles" (which is technically correct, but doesn't quite fit for what the subroutine is actually doing).

The recent changes to the files within the _maps folder has caused incompatibility with common editors, such as Flex 2 and SonMapEd. Sure, Flex 2 could be updated to support this, but SonMapEd, an editor plenty still use to this day, will be unable to load these new mappings and DPLC thanks to going out of support years ago. Additionally, if modern editors were updated to support this, it may break compatability with legacy or alternative disassemblies.

How can I build this on my FreeBSD 12.1-RELEASE box? I have 2 assemblers that might be able to handle it:

• vasm
• asl

But I don't exactly which one to use and how to build it properly, so how would I go about building this on *nix?

Apparently the Two-Eight branch misplaced a ring above the loop in GHZ Act 2. This was probably inherited from the original Two-Eight project. There might be other mistakes like this, so maybe a tool to analyse all the differences would be nice.

A while ago, @ValleyBell suggested some changes for the sound drivers of s1disasm, s2disasm, and skdisasm. The changes were that the labels be made more clear, and also follow some kind of standard between drivers. For example, each driver has a different label for UpdateDAC/zDACUpdateTrack/zUpdateDACTrack. He also suggested corrections for erroneous labels like cfHaltSound, which only halts music, and not necessarily all sound. While some changes are so black-and-white I could get away with making them, myself, I feel some of them need discussion first, such as the changing of cfPreventAttack to HoldNote, a change which would not only affect the drivers, but SMPS2ASM, and I feel my previous changing of cfAddKey to cfChangeTransposition was slightly unwelcome because of that.

The AS branch has really nice Z80 support. Obviously that isn't the case with asm68k. I have an experimental branch that builds the driver using a separate assembler, compresses it, and then runs asm68k, which incbin's the compressed file like normal.

There are a few hurdles though. Firstly, finding a good assembler is a little tricky: VASM had a severe bug, last time I checked, ASMX is barebones, and AS is AS. AS is bagage I'd rather we find a proper replacement for in the future, so I don't really want to go with that, VASM flat-out doesn't work with the Z80 driver right now, and that just leaves ASMX.

ASMX ain't that great either. It's barebones, lacking in the most basic features like error messages that print variables or labels, it's buggy, and it's not even under an open-source license. The source code's a pretty easy read though, and I have taken the time to weed out the handful of bugs I've noticed in my fork.

Currently, my branch assembles bit-perfect, but there are still issues.

The Z80 driver and the ROM itself are both dependant on each other: the Z80 driver needs to know where the Sega chant is, and the 68k sound driver needs to know where the timpani pitch is.

To address this, I have a file a bit like C's .h files, which is included by both the Z80 and 68k code. This file contains hardcoded values for things like the Sega chant location, size, and where the Z80 timpani pitch is. If either assembler detects the constants don't match their generated equivalents, it flags a warning telling you what to change them to, but still assembles a ROM anyway. This is comparable to how S2's driver handles the size of the compressed driver.

But my question is, is this worth it? It technically makes using the disasm more difficult, since whenever you shuffle the ROM around, you have to update the header file. Not to mention, things like the Mega PCM installation guide obviously don't detail taking out the Z80 build system. Not that the Git disasms ever really cared about backwards-compatibility, I guess.

So i want to use sonani app since i want to edit some animation though theres no sonani.ini file to select so could you add it?

I cant download a file with all the chunks for a level, I would really love it if you could show me a way to get a png or something like that for all the chunks (websites show objects but not level chunks). More important than you think please help as i need to use this for my Round Table Assessment

while searching for a hex byte shown in the sonic.lst file, it does not show up in any hex editor for the ROM file

or, i cannot find it because i am blind (i can literally do this in sonic.asm but i am experimenting something)

Change the permissions on p2bin to compile sonic 1.

Before:

lua build.lua 
Uncompressed driver size: 1BC6h bytes.
sh: line 1: build_tools/Linux-x86_64/p2bin: Permission denied

After:

lua build.lua 
Uncompressed driver size: 1BC6h bytes.

I'll grant that when Nemesis introduced the concept of the split disassembly it was a big step forward, but between seeing things like the work pret has done and knowing from the Nick Arcade prototype that Sonic Team's code made liberal use of crossreferences and symbols exports, I'm forced to wonder why Sonic ROM hacking persists in working with a single giant text file. Look at pokecrystal, for example - the main file main.asm is only 20.3 kilobytes and rarely needs to be touched because all the code is separated out into other files for ease of reference and crossreference. By contrast, sonic.asm is 237 kilobytes, and it gets worse the more featureful the games get - s2.asm is 2.54 megabytes, sonic3k.asm is 4.25 megabytes.

hey I was wondering where is this variable because its asking me to set it to 1 on the github page for it and I Cant even find it which asm file is it normally in. because without it I'm getting this

sonic.asm(19):10: error #10001: error in opening file
"Sonic-2-Clone-Driver-v2/Definitions.asm": No such file or directory
include "Sonic-2-Clone-Driver-v2/Definitions.asm"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fatal error, assembly terminated

The AS branch now assembles the Z80 DAC driver, but the resulting ROM is not bit-perfect. This is because of the Kosinski compressor (K-Compressor2.cpp), which was imported from the S&K disasm. It seems, both there and here, it does not mimic the compressor used by Sonic Team, as S2's Saxman compressor does.

I do not possess the know-how to correct this myself, so I've added the same workaround employed in the S&K disasm: there's an option to assemble the driver, or binclude a pre-assembled/compressed copy of it. It would be nice to be rid of this, though.

AS is GPLv2-licensed. It took me forever to find the source. You should include the AS license in AS/, and a README saying where to get the AS source from.

(In the mean time I'll get back to seeing if I can get this thing to build on a Raspberry Pi 3. Edit: It works!)

I can't figure out where stuff like the Snare and Kick DAC sounds are located, could there be some easier way to find them?

You forgot to put "Sonic pattern load cues.asm" in the "_inc" folder.

As discovered a few days ago, the prototype has an unused palette cycle for Marble Zone. Turns out it's in the final game too... and this disassembly just groups it with the SBZ3 waterfall cycle.

How do i spindash?

Honestly, these 2 macros and optimization option are useless. The macros are overly convoluted and considering "OptimiseSound" is the only optimization option in the entire disassembly as far as I can see, what's the point? It's not like changing all the PlaySound branches to be direct writes would save many cycles considering that they are only called a few times in a single frame. Also, the "music" and "sfx" names are pretty much misnomers, since the sound queues aren't limited to a particular sound type (See loc_47D4 and LevSel_Credits, for instance).

SonED2 can make own level editor. I saved SonED2 project. Close your program & Open program. Open the SonED2 project. Loaded SonED2 project doesn't appear graphics titles. It's corrupted.

Screenshots:

Green hill zone act 1

Green hill zone act 2

Loaded Marble zone act 1. opening green hill zone act 2 project causing loaded ghz palette & doesn't loaded tiles

Please fix this

Hi, I'm a beginner at this, and first want to say I love the work!
But when opening this up in SonLVL I seem to be getting some weird red, yellow and green blocks.
As you see in the screenshot, these are the flowers and the top of the waterfall. Are they missing? Or is it because (I think) they are animated in the game?
And how can I display them better for export to PNG?

There's also a yellow line around the looping which is a bit weird.

Thanks

I don't really see a reason to make REV00 the default when it's so much more inferior. If anything, I think building an older version of the game should be the option that's hidden away behind an assembler flag.

I might bring up a similar issue for S2's REV02 later, when I split its bugs into a 'Sonic Classics' build.

REVXB is a debatable build (and really hackishly done), so I don't think I'll ever suggest making that the default.

I think there might need to be some usability tweaks to make this really work though, like changing the SonLVL files so REV01 gets SonLVL.ini, and REV00 gets SonLVL.rev00.ini, to prevent newbs from using the wrong one.

There's no advantage to having the level order stored in a separate binary file, it would be much easier to work with in ASM.

I am making a rom and i already edited it before i tried this

I don't want to be a complete repo-dictator, so I want to get some input from users and contributors before making this change.

The master (asm68k) branch is starting to lag quite a bit behind the AS branch: advantages that the AS branch has over the asm68k branch include...

• Support for platforms besides Windows.
• A disassembled DAC driver.
• Split DPCM samples.
• Disassembled music and SFX data (in SMPS2ASM format).

Additionally, AS is the only supported assembler of the Sonic 2 and Sonic 3 & Knuckles disassemblies. Promoting asm68k as the default assembler contributes to fragmentation, making it more difficult for people to share code that works across all Git disassemblies. Examples of this are Flamewing's DMA queue, debugger, and sound driver, which are intended to be ported to either of the three games, but are incompatible with asm68k. I also frequently find myself referring people to the AS branch instead of the asm68k branch whenever I make a tutorial on porting assets from later games back to Sonic 1.

I suppose, if this goes through, then we may have to consider rebasing the MapMacros and Project Sonic 1: Two-Eight branches on the AS branch as well.

I think my SonED2 broke my game,or XVI32,when in the game im reach an trigger to boss fight,it make's to appear an illegal instruction,please tell to how fix it.

while searching for a hex byte shown in the sonic.lst file, it does not show up in any hex editor for the ROM file

or, i cannot find it because i am blind (i can literally do this in sonic.asm but i am experimenting something)

Please so i can actually edit it properly in flex2