Short: A packer for the xpk-package, V1.5 Author: K. Dagef"orde Uploader: dagefoer@ibr.cs.tu-bs.de Type: util/pack --------------------------------------------------------------------------- RAKE A cruncher of the LZ77 family for the XPK-package Version 1.5 Copyright 1995 by Karsten Dageförde Status: FREEWARE License/Disclaimer ------------------ This library may be freely distributed, as long as it is kept in its original, complete, and unmodified form. It may NOT be distributed in a commercial package of any kind without my permission. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Installation ------------ You'll need to install the XPK package first to use this library. The XPK package should be available on most Bulletin Board Systems, so try to get it there. If you already have the XPK package installed, add this library to your system simply by copying the xpkRAKE.library to your LIBS:Compressors/ directory, or if you've got a 68020 (or greater) processor, you should take the xpkRAKE.library.68020' instead. Description ----------- RAKE is an XPK packer sublibrary which implements a highly optimized form of the popular LZ77 compression algorithm. It uses static huffman coding for the 'len' and a three-step coding for the 'offset' information. The major feature of this packer is the highly optimized algorithm for tracking down redundant data. RAKE supports four modes at compression. To speed up compression everytime a better match (than the previous) is found, the 'dictionary' size will be reduced dynamically according to the pack-mode by division ... 0..25 : by 8, 26..50 : by 4, 51..75 : by 2 (using 'lsr.w', of course). 76..100 : The full dictionary size of approx. 18KB will be scanned for redundant data. ----------------------------------------------------------------------------- NOTE: There is no need to repack files packed with RAKE V1.0 - V1.3 (68000 or 68020 version), because RAKE V1.5 is totally compatible with older versions and vice versa, it just works faster. ----------------------------------------------------------------------------- Statistics ---------- Following is a table briefly listing some comparative statistics for NUKE and RAKE. These were generated by xBench on an A3000/25 with 2MB ChipMem and 4MB FastMem, using the AmigaVision executable as data (standard xpk benchmark configuration). Note that memory needs don't include xpkmaster.library's buffers. | Memory usage while Packer UComp Comp CF CSpd USpd | packing unpacking ---------------------------------------------------------------------------- 68020_V1.5 (results from 30-Dec-94 (16Bits - 128K Hashtab)) rake.100 594712 322872 45.8% 86819 660791 | 256K 0K rake.75 594712 324964 45.4% 100288 653529 | 256K 0K rake.50 594712 326908 45.1% 111578 653529 | 256K 0K rake.25 594712 328796 44.8% 119901 646426 | 256K 0K 68000_V1.5 (results from 30-Dec-94 (16Bits - 128K Hashtab)) rake.100 594712 322872 45.8% 82713 512682 | 256K 0K rake.75 594712 324964 45.4% 94699 508300 | 256K 0K rake.50 594712 326908 45.1% 104887 508300 | 256K 0K rake.25 594712 328796 44.8% 111998 503993 | 256K 0K NUKE_V1.0 nuke 594712 326908 45.1% 41472 613105 | 192K 0K History --------- Sep-9-94 V1.0 First public release (68000,68020) Sep-14-94 V1.1 BUGFIX: Uncompressable data (or remainder) should not cause XPKERR_SMALLOUTBUF but XPKERR_EXPANSION ! (Worst case: OutLen = OutBufLen + 5(<K<-handler) (I've got no feedback if xp>K<-handler now works fine (everybody should use xf>H<-handler ;) ). Nov-6-94 V1.3 Using bit-field instructions for 68020 version. Pack-routine now fits in 68020 instruction cache. Further optimizations done increasing packing & unpacking speed :-). Memory shortage causes XPKERR_EXPANSION => files won't be packed but be saved uncompressed by XFH without aborting with an error. V1.4 Not a public release Jan-10-94 V1.5 - Now using MEMF_PUBLIC instead of MEMF_ANY, thus buffers should not be swap by virtual memory programs. - Some optimizations done increasing packing & unpacking speed :) >> Thanks to Denis Ahrens! << - Now using double of hash-entries without increasing memory usage. (Using .w as offset instead .l as address.) This results in a better packing speed :) - Memory shortage causes RAKE to decrease hash-buffer size dynamically, until buffer has reached 0.5KB (XPKERR_NOTPACKED will be returned at this time). Same behavior as MASH. - I have forgotten to delete some ';' in my source: RAKE will now stay in memory after usage, sorry. \\//_ Live long and prosper Contact Address --------------- dagefoer@ibr.cs.tu-bs.de (perhaps, insert diana. after @ !?) OR dagefoer@rzcipa03.rz.tu-bs.de (may expire soon :( ) ============================= Archive contents ============================= Original Packed Ratio Date Time Name -------- ------- ----- --------- -------- ------------- 6194 2517 59.3% 19-Jan-95 15:14:46 xpkRAKE_V1.5/xpkRAKE.doc 6580 3763 42.8% 19-Jan-95 15:10:32 xpkRAKE_V1.5/xpkRAKE_68000/xpkRAKE.library 7032 3778 46.2% 19-Jan-95 15:10:32 xpkRAKE_V1.5/xpkRAKE_68020/xpkRAKE.library -------- ------- ----- --------- -------- 19806 10058 49.2% 20-Jan-95 12:45:52 3 files