 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,472,135 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
04-23-24 03:51 PM |
|
| Guest: Register | Login | |||
| 0 users currently in ROM Hacking | 2 guests | 1 bot |
| Main - ROM Hacking - Figuring out compression formats? | New thread | New reply |
| Skreeny |
| ||
 Cobrat Level: 56 Posts: 509/653 EXP: 1321454 Next: 76722 Since: 02-21-07 Last post: 5338 days Last view: 4839 days |
I've hit a bit of a snag trying to edit levels in Ecco the Dolphin (Genesis version). The levels themselves are in an easy enough format to understand; the problem is that the 128x128 chunks are compressed, as are the level graphics.
Does anyone know of a particularly good way to figure out how to decompress these things? I've been thinking that the best way would be to try to trace through when they're loaded into RAM, but I don't know 68k assembly yet, and am therefore hoping for a different way 
I have an example in both compressed and uncompressed form, if someone wants to see it. |
| GuyPerfect |
| ||
 Paratroopa Level: 30 Posts: 139/155 EXP: 152566 Next: 13303 Since: 03-14-07 Last post: 6042 days Last view: 5991 days |
The way that I've found to be effective is to use an emulator that can display the contents of system memory. I did it with various F-Zero games and B.O.B. this way:
Basically, I find the spot in RAM where the decoded data is stored. Then I find the spot in ROM where the encoded data is stored. Then I slowly change a few bytes in the ROM data and see how it gets loaded into RAM. I say "When this is in ROM, that ends up in RAM. Why is that?" and attempt to fill in the blanks. It can be a little tedious, but it doesn't require disassembling the ROM; and thusly anything you make with it won't violate the copyright of the original game's binary. (Not that ROM hackers are worried about violating copyrights, but still) |
| Tweaker |
| ||||
 Red Koopa Level: 28 Posts: 137/139 EXP: 129799 Next: 1539 Since: 02-19-07 From: Rochester, NY Last post: 5792 days Last view: 5698 days |
I'm betting the level tiles use Nemesis compression, and the 128x128 mappings use Kosinski compression. You can find decompressors for these formats at http://info.sonicretro.org/Program_Files and downloading "The Sega Data Compressor" (TSDC). ____________________
|
| Skreeny |
| ||
|
Cobrat Level: 56 Posts: 511/653 EXP: 1321454 Next: 76722 Since: 02-21-07 Last post: 5338 days Last view: 4839 days |
Tweaker: That's a broken link. However, assuming the version on Hacking CuLT is up to date, it doesn't work for this, anyway. The Kosinski decompressor creates a lot of gibberish from the in-ROM data while the Nemesis decompressor crashes on the tiles.
GuyPerfect: I tried that, but the results were too unpredictable to be useful. Various values that moved verbatim into the RAM, a few other ones that'd make the whole thing explode... So... yeah. Trying that "read through the trace of the routine" thing. 68k seems easy enough, as long as I keep a reference handy. |
| GuyPerfect |
| ||
|
Paratroopa Level: 30 Posts: 145/155 EXP: 152566 Next: 13303 Since: 03-14-07 Last post: 6042 days Last view: 5991 days |
Based on your description, it sounds like you're dealing with LZ. Changing the "distance" value will scramble the data up something fierce, while changing literal-copy bytes will produce the same thing in RAM that's in ROM. |
| Main - ROM Hacking - Figuring out compression formats? | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 57, rows: 82/82, time: 0.016 seconds. |
