Short: Amiga executable and data cruncher Author: bifat/tek Uploader: bifat@neoscientists.org Type: util/pack Version: 0.51 Architecture: m68k-amigaos Cranker by The Electronic Knights --------------------------------------------------------------------- Cranker is an Amiga executable (and data) cruncher. It decrunches while loading and decrunching requires no additional memory. Cranker is by far the fastest way to run large executables from disk on old, unexpanded Amigas like Amiga 500, 600, and 2000. The source of the loader/decruncher is provided as an example, and you can specify a custom decruncher in the commandline. An example decruncher is included that demonstrates a progress display. Also, a raw data cruncher and decruncher is included. Kickstart 1.x is sufficient and a 68000 CPU is fast enough, but the cruncher requires a lot of memory. Rationale: Large OCS demos (onefilers) often reserve most available memory in their executable sections. This is best practice and recommended. Crunching them with most crunchers like Imploder or Powerpacker is not an option, because all crunched data plus all sections must fit into memory at the same time, so the demo will fail to run in the minimal configuration (typically 512k+512k). Titanics cruncher was 30 years ahead of its time in that it includes a decruncher that loads from an overlay hunk, which requires little or no additional memory. Unfortunately the Titanics decruncher is very slow (it probably does not really load and decrunch at the same time, but alternates between loading and decrunching), and its crunch ratio is bad. Another issue found with Titanics is that if a program disables multitasking, the disk motor can keep spinning for the whole time it is running. Cranker addresses all this, and more. It certainly does load and decrunch at the same time, it uses no additional memory, it has a solid crunch ratio, and it is blazingly fast. It possibly includes the only executable decruncher that does real asynchronous I/O. Since version 0.40 Cranker also addresses the disk motor issue. As of version 0.51, only an Amiga executable is included. See src/INSTALL on how to build Cranker yourself and using it on different platforms. Some benchmarks: Rebels Retrodentro, crunched size: ---------------------------------- Original : 499768 Bytes Titanics : 236388 Bytes Cranker : 217548 Bytes Imploder : 213332 Bytes - does not work with 1mb Shrinkler: 179472 Bytes Starting time, Kick 1.3: ---------------------------------- Cranker : 20s Imploder : 28s - does not work with 1mb Titanics : 35s Original : 41s Shrinkler: 87s Starting time, Kick 2.04: ---------------------------------- Cranker : 14s Imploder : 24s - does not work with 1mb Original : 33s Titanics : 46s Shrinkler: 86s Usage: $ cranker argument template: -f FROM/A input file -o TO/A output file -mo MAXOVH/N max. overhead (else store hunk, or error) Data options: -cd CDATA/S crunch raw data -dd DDATA/S decrunch raw data -eo ENCOVH/S encode overhead into first header byte Executable options: -t TEXT/K text to display while loading -nf NOFLASH/S no color flashing when decrunching -s STORE/S do not crunch, store all hunks -m MERGE/S merge hunks (dangerous) -ed EXTHEAD/K use external decruncher from this file Expect bugs and problems. In any case, keep your original binary. Feedback is welcome. Some technical info: Cranker does not allocate memory. All allocations are made by the OS loader. Hence it is decided right at the beginning if the executable fits into memory and will be loaded at all. Cranker uses a combination of techniques, hunk overlay, asynchronous and buffered I/O, and overlapping, in-place decrunching with one of the fastest decrunchers in existence. A small logic allows to switch between async and buffered loading, for coping with reloc tables efficiently. Relocs are packed into 1, 2, and 4 bytes entities. Due to its complexity, the decrunch header is quite large, but it probably can be further optimized for size. The decrunch header and a few extra bytes to allow overlapping/in-place decrunching are the only memory that adds to the required memory of the executable. It will be freed by the OS at exit, like all other sections. The Cranker decruncher is so fast that I suspect that the construct is I/O bound under all practical circumstances, even if asynchronoucy kicks in just a little. Download: http://neoscientists.org/~bifat/binarydistillery/cranker.lha Precompiled Linux, Windows, Mac OS X binaries: http://neoscientists.org/~bifat/binarydistillery/cranker/ Authors: Coding by Bifat/TEK LZO by Markus Franz Xaver Johannes Oberhumer Changes: 0.51 Partially uninitialized hunks are now supported. Debug and symbol hunks are now handled and stripped away. The merge option appears to be more stable now. Added -eo option to encode the overhead into the crunched data header. Suggested by Origo. The build procedure and sources have been cleaned up. The Linux, Windows, and Mac OS X binaries have been dropped from this package. See src/INSTALL on building them yourself. 0.42 The Amiga version now works on Kickstart 1.x and on 68000 CPUs, a FPU is no longer required. Requested by Sachy. Crunching fastmem hunks is now supported. Added an external example decrunch header. 0.40 When an executable was started that disabled multitasking, the disk motor could keep spinning while the executable was running. Corrected by synchronizing on an ACTION_FLUSH packet. Found the same issue with Titanics later, so this is another reason for using Cranker now. 0.31 Mac OS X version and Makefile included, supplied by Bonefish. Thanks! 0.3 Added options CDATA, DDATA, MAXOVH, MERGE, renamed EXTDECR to EXTHEAD. Removed former hardcoded limit of 64 bytes maximum overhead. 0.21 Fixed a bug in the decrunch header when a load error occurred 0.2 Added options for displaying text and to avoid poking to the bgcolor register. Incompressible hunks are being stored now. The source of the decrunch header is now included and a custom header can be specified in the command line. This way you can use Cranker as a loader system, show a progress bar, or disable crunching in the commandline and just exploit async I/O to show an effect while loading. 0.1 initial release