User blog:RottenBlock/Sys0Decompiler Update

This is the latest release of Sys0Decompiler and its source, version 0.5. It provides support for most of AliceSoft's System 1 games, though in some cases you may have to mind additional steps that I'll discuss below.

Download: MediaFire

As an overview:
 * The Windows/DOS versions of Little Vampire, Crescent Moon Girl, DPS, and the Toushin Toshi Hint Disk will decompile without additional fuss.
 * Dangerous Tengu Legend contains what I've dubbed "junk code": code that exists beyond the EOF character that normally divides source code in an DAT archive. Page 0's junk code is actually valid, which the decompiler will tell you if you decompile it. This junk code must be extracted using a feature I've added: Advanced Settings -> Output Junk Code. I recommend the game be decompiled normally, and then junk code decompiled to a seperate folder, at which point the junk code version of Page 0 can be manually corrected into a valid code file that will replace the original (simply removing EOF and null characters should do the trick, at least in this instance).
 * The Windows/DOS version of Intruder requires the external fix described below.
 * Versions of games for other computers may or may not require the fix depending on the product, but most seem to decompile fine.

Troubleshooting Issues with Multiple Disk Files
Older Alicesoft games split their code across multiple disk files entitled ADISK.DAT, BDISK.DAT, etc, depending on system. Unfortunately, this division sometimes results in strange irregularities. Examples include: Not only do these potential causes make a single, unified solution for Sys0Decompiler impossible, but some can become the source of decompile errors by damaging or confusing file headers. The only solution, then, is for the end programmer to diagnose and correct the problem manually using ALDExplorer.
 * Identical files on multiple disks.
 * Distinct files with the same name on multiple disks.
 * Alternate versions of specific .DAT files included on multiple disks to minimize disk-swapping (for example, Rance 1 on the X68000 contains different copies of ADISK.DAT on every disk with different data depending on the disk's needs). These may include identical or distinct files.

Bear in mind that compiled code is 1-oriented, but decompiled code is 0-oriented (so dis0001.sco corresponds to page0000.adv), an irregularity that is reflective of actual AliceSoft data and code.

Various troubleshooting suggestions include:
 * The header errors caused by identical files on multiple disks can typically be fixed in the following fashion, which doubles as a useful first test if you are unsure if the files are identical. Using ALDDecompiler, open the source DISK files and select Import/Export -> Export All to export the compiled .SCO files to an external folder. Then, select File -> Create Empty Archive File and select a .DAT file (don't mind that the file defaults to the name ACG.DAT). Next, select Import/Export -> Import and add new files... and select the contents of the .SCO folder. Save this file as ADISK.DAT (do not overwrite the original source, just in case), and decompile this version instead of the original.
 * If files are distinct on multiple disks, you will have to decompile them seperately and compare them. At present, Sys0Decompiler can only decompile ADISK.DAT files followed by B, C, etc, so you will have to isolate and rename the archives. Once you have the decompiled versions of multiple files, it will fall to you as the end programmer to resolve the issue of which code is called and when. On a hard drive with a single executible, we don't have the odd luxury of code files that can change form depending on the current "disk."

Known Decompile Errors with this Version

 * No amount of troubleshooting in this version has been able to resolve a matter with Rance 1 on the X68000. Page jumps suggest that there is meant to be combat code on Page 10 (the equivalent of FIGHT.ADV in the 3.5 remake), but despite multiple versions of page 10 existing in the archives, none seem to contain the combat code. It is likely the code is located elsewhere, but why, and if any changes to Sys0Decompiler could account for them, is unclear.