|
| |
Released At :
Breakpoint 2009
Credits :
Download :
Look for downloads on external sites:
Pokefinder.org
Summary
Submitted by Kabuto on 14 April 2009
An ALZ64 manual
Introduction
------------
ALZ64 is a LZMA-based compressor for C64 executables. It achieves great compression ratios at the cost of slow decompression.
The main application are 4K intros where decompression time is about 10 seconds. Larger demos would take forever to decompress while smaller demos would sacrifice compression efficiency due to the relatively large decomperssor.
The compressor itself runs under Windows and also under Linux using Wine.
Usage
-----
There are a few important limitations. First of all, ALZ64 overwrites most of the RAM from $000 to $7FF so be prepared for trouble if you call ROM routines from your compressed intro (4K intros will hardly ever call ROM routines - if you still really need to, add jsr $fd50/jsr $fd15 to the start of your program). Also, due to that you cannot use it to compress intros that need to be loaded before $0800. Furthermore, a feature left in you might not really expect is the state of $1 after decompression which is $30 by default - better set it to $37 if you don't know the intro you're about to compress well enough (-1 $37).
Next, ALZ64 needs to know how to start your intro. There are 2 options: -s tells ALZ64 to parse and remove the BASIC SYS starter. This should work well with most existing programs written in 100% ASM. (There's at least one intro that use basic to precalc sinus tables - such intros cannot be compressed with ALZ64). Otherwise, if your uncompressed intro is to be started with SYS after loading you need to specify the SYS address, e.g. -e 4096 or -e $1000 for SYS 4096.
There are 2 builtin options to further increase compression ratio.
The first one is a code morpher. It basically transforms the code section (a contiguous piece of memory, e.g. -f $080D $0300 for $0300 bytes of memory starting at $080D) so it hopefully compresses better. Sometimes it helps and sometimes it doesn't. The larger the code the greater the chances that this option helps. But make sure that the code section should not contain anything that's not code when using this option - non-code can drastically decrease compression efficiency.
The second one (named "arithmetical hints" which might be a bit misleading) helps if your intro contains lots of or large equally increasing (or decreasing) series of bytes of the same distance. Such series can often be found in character line address lists or speedcode. Think about arithmetical hints as a mean to subtract a linearly increasing value from each member of the sequence. You have to specify the address of the first sequence element, the number of elements, their difference and their distance in this order.
In general arithmetical hints are only useful if they help alot as using them forces ALZ64 to add code to undo their changes. Also each hint needs to be appended to your intro so they can be undone after decompression. Whether or not an "arithmetical hint" helps depends on the particular situation.
Let me give a few examples:
Example: Low bytes of the addresses of all 25 screen rows
$0900 00 28 50 78 A0 C8 F0 18 40 68 90 B8 E0 08 30 58 80 A8 D0 F8 20 48 70 98 C0
Guess what -e $0900 25 40 1 does?
$0900 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
This of course helps alot.
Example: Linear sequence with an outlier. This demonstrates that if there are 2 similar sequences directly after another or a few outliers within a larger sequence you can still use a single hint.
$0A00 00 01 02 03 04 05 06 07 10 09 0A 0B 0C 0D 0E 0F 11 12 13 14 15
-e $0a00 21 1 1 creates the following result:
$0A00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 01 01 01 01 01
Example: Speedcode (STA $0400, X to STA $0700, X)
$0B00 9d 00 04 9d 00 05 9d 00 06 9d 00 07
-e $0B02 4 1 3 results in:
$0B00 9d 00 04 9d 00 04 9d 00 04 9d 00 04
Even as only 3 bytes actually got changed the better compression is likely to outweigh the costs of the additional hint. (3 plain bytes and then a repetition of the previous 3 byts for 9 bytes instead of 6 plain bytes plus 3 repetitions of 2 bytes each).
$0C00 00 01 02 03 04 05
This is unlikely to benefit from arithmetical hints. Bytes in sequence with similar values are already handled acceptably well by the LZMA-like compressor (e.g. without taking the decompressor into account the byte sequence 00 01 02 03 ... FE FF (256 bytes) gets shrunk by 20% - not much but better than what all existing C64 packers I am aware of can do about it).
The options for "arith hints from program" were meant for such hints to be automatically generated by an assembler. I don't remember the precise syntax and don't know where the source code is, unfortunately :(
Credits to iAN CooG for the jsr $fd50/jsr $fd15
|
Summary
Submitted by Akira on 14 April 2009
ALZ64 - high efficiency executable packer for C64
Usage: ALZ64 [options] inputprg packedprg [decompressor starter]
Options:
-s Parse & remove BASIC SYS starter from program
-e addr Load program as is and enter at that location
-1 value Set state of $1 after program has finished (default is $30)
-a Use arith hints from program
-as Strip arith hints from program
-f addr size
Preprocess that code area
-h addr count step dist
Gives an arithmetical hint manually (can be specified multiple times)
Addresses and sizes can be given either decimal or hex with preciding $.
|
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
