Off the bat, I'll very briefly list off some things to know. Levels are stored in a very similar method as Sonic 1's levels, but the block data in the chunks is stored like Sonic 2. Chunks, blocks, and collision indexes are compressed into the "Star" format, dubbed by drx. Collision is stored identically, albeit arrays are smaller. There's some sort of angles being handled here, but I'm currently unsure where they're handled. Ristar levels will work perfectly in SonLVL if you modify the source code to make Sonic 1 projects use Sonic 2's "ChunkBlocks". Currently, data in the Star format can only be decompressed, as there's no available compression tool. It seems to be similar to Kosinski, in fact replaces where Kosinski should be in these games. It's even set up identically: Code (Text): lea Source, a0 lea Destination, a1 jsr StarDec There's a LOT of game modes, almost all of them are blank. $50 is the Sega screen, $54 is the opening sequence, and $0C is the level mode. I'll showcase a video of a level edit test I've done so far: May list more things off later, but this is a generalization of what I have down so far.
It's pretty dang cool that you managed to reverse engineer an LZ-derived codec from nothing but ASM, even if it's just the decoder! Don't be distraught if the benefit you derive from reverse engineering the compressor doesn't justify the elbow grease, you can always hack a config option into SonLVL that converts Star/Kosinski assets from the vanilla ROMs to LZ4 and then patch an LZ4 decoder into the ROM. However, the value added for you depends on whether you are more interested in the research itself or in arming other people with tools they can use to provide you with free entertainment in the form of Ristar hacks! :-) I spent some time working on my own LZ4 for 68k ASM a while back before I realized LLVM could write better 68k code than me, especially if I disable loop unrolling and all the other optimizations designed around a 3GHz CPU w/ >16GB RAM and several MB of cache. My way of getting that 68k code is pretty cumbersome, though: compile w/ 68k as the target, link LZ4 as a static library, run "disas" on it, then copy and paste the 68k ASM of the LZ4_decompress_safe function. EDIT: Before I forget, most of the macros you want set or don't want set for an embedded m68k target are correctly enabled/disabled, but make sure you define the following macro so that no calls to malloc/calloc/free are in the code: LZ4_STATIC_LINKING_ONLY_DISABLE_MEMORY_ALLOCATION LZ4 is gracious enough to use as little of the C standard library as possible, but this still leaves calls to memmove which may or may not exist in your environment, but that can be done in a couple lines with stack memory as the intermediate buffer. Other than that, the code to do the decompressing is only about 200 lines when you subtract the LZ4_FAST_DEC_LOOP code that won't get compiled into your target, and the assert() calls only show up in debug builds.
Sorry if I wasn't clear. The decompression tool was not written by me. The decompression tool was written by drx, who also cracked the format. The video shown has the level loading routine hacked to use a more common compression method that the community is familiar with.
