LHWARP 1.21 6th January, 1990 A disk tracker for the Amiga Written by Jonathan Forbes What is Lhwarp? (Pronounced L-H-WARP) Lhwarp is a program which will read tracks directly from your floppy disk, compress them, and output them to a file. The advantages of using Lhwarp are: o The entire disk structure, including the boot block, is preserved. o Lhwarp will always produce a smaller output file than ARC, ZOO or WARP. (note: this is only true when the default compression algorithm is used) o Lhwarp will only archive sectors which contain data, by using the disk's bitmap (however, Lhwarp will gladly compress every single sector on the disk, if you wish.) o Using Lhwarp is much less hassle than archiving each and every file individually. o The bootblock of any disk being either read or written is displayed, so that bootblock viruses can easily be found. Lhwarp will produce files much smaller than those produced by Warp, due to the fact that Lhwarp uses a more efficient compression algorithm (Adaptive Huffman Encoding); the same algorithm used in LHARC. Typically, an Lhwarp file will be 80% of the size of an equivalent Warp file, resulting in quite reasonable hard drive space savings. In addition, Lhwarp will only archive sectors which contain data; deleted information is not archived (unless you explicity request this to be done.) When compressing or decompressing data, sectors which contain data are marked with a '.' character, while sectors which do not contain data are marked with a '_' character. If the -m option is specified, all sectors will be marked with '.' automatically. Lhwarp's main (and perhaps only) disadvantage is that compression time is very large; it can take from 20 to 25 minutes to compress an entire disk (80 tracks.) There is not too much which can be done about this; you have to pay a price for the extra power. However, this is not as bad as it may seem; a disk only has to be Lhwarp'd once; after Lhwarp'ing, the output file will be transferred via a modem, from BBS to BBS. Because the file will be that much smaller than an equivalent file produced by Warp, the file will take less time to transfer, resulting in a lower phone bill. And, as mentioned before, it will occopy less space on the destination system. Algorithms For those who simply must have a faster compression rate, Lhwarp provides two additional compression algorithms; squeezing and vaporising (the latter is the 14 bit version of UNIX Compress.) Both are much faster than the LHARC Adaptive Huffman Encoding algorithm (called "freezing.") However, neither of them comes close to the compression ratio of freezing. Even so, the huge speed increase and reasonable compression rates should appeal to those who are less concerned with compression efficiency, and more concerned with speed. Freezing remains the default compression mode. Using the -c switch will cause the disk to be vaporised (not literally), while the -s switch will cause the disk to be squeezed. The -b option will cause each individual track to be either vaporised or squeezed, depending on which produces the smallest output. The -q option will cause Lhwarp to use its fastest and most reasonable algorithm on the disk. Currently, this is squeezing. Admittedly, vaporising is faster, but vaporising often generates track output which is actually larger than the track itself, and squeezing is almost as fast (certainly it's faster than freezing.) The most recommended option for speed, is the -b option, to select both algorithms; compression time is only a few minutes longer than that of one of the algorithms, and different algorithms sometimes work better for different disks. You cannot currently combine freezing with any other algorithm; this is for your own benefit; I have yet to see freezing beaten by vaporising or squeezing for any one track, ever! However, if you find that vaporising and squeezing frequently do compress tracks more efficiently, please inform me. To compress the NewTek DYNAMIC HI-RES demo disk: Compression Size Time (approximate) ----------- -------- ------------------ Freezing 671630 20:00 minutes Vaporising/Squeezing 770722 10:30 minutes Squeezing 803714 07:30 minutes Vaporising 869515 06:30 minutes Warp program 796665 15:00 minutes At this point in time, Lhwarp does not check to see if the output for a track is larger than the input; this is why vaporising produced such a huge file; many tracks compressed from 11k to 13k. This will be corrected in a future version. Viewing Lhwarp also supports viewing; you may see how Lhwarp has compressed a disk (which tracks are contained in the file, which algorithm was used to compress them, the source and destination lengths of each track, the number of sectors compressed, and the sector map of each track.) The viewing option will also display any attached text. After any attached text is displayed, you must press return; this was implemented so that the displaying of the boot block won't scroll the text off the screen. More Information Lhwarp output files have the suffix ".LHW". If the filename you give Lhwarp does not end in ".LHW", Lhwarp will append ".LHW" to it. Please leave the suffix alone, and don't change it to ".WRP". The Adaptive Huffman Encoding algorithm was originally coded by Haruyasu Yoshizaki, and is the same algorithm used in LHARC 1.13c. When the more efficient LHARC 2.0 arrives from Japan, that algorithm will instead be used. Lhwarp was compiled and very heavily optimised under Lattice C 5.04. Even though Lattice produces very fast code, Lhwarp needs all the speed it can get. I have rewritten a few of Lhwarp's compression functions in assembly language, and performance has improved significantly. Nevertheless, the Lzhuf routines, which are now a mixture of Lattice C 5.04 code and assembly language, are much faster than those in either Amiga Lharc, or the previous versions of Lhwarp. When compressing an arbitrary 40k file: Encode time(s) Decode time(s) Lharc 60 15 Lhwarp 1.03 55 13 Lhwarp 1.10 47 11 Lhwarp 1.11 39 11 Lhwarp 1.20 39 10 Lhwarp 1.21 39 10 Parameters To view Lhwarp's parameters, type "Lhwarp"; they are included within the program. You will be presented with: Usage: LHWARP [-option] Read or Write -m: ignore bitmap -q: quick compression -s: squeeze -c: compress-14 (vaporise) -b: both squeeze/vaporise -v: view output file Drive number (0 for internal, 1 ... 3 for external) Output|Input filename Track number (0 ... 79) [valid only in read mode] Track number (0 ... 79) [valid only in read mode] Append text in to output file [optional] Examples are: a) Lhwarp READ 0 mydisk 0 79 This will read tracks 0 to 79 of the disk in drive 0 (i.e. the entire disk), and will output the result to "mydisk.lhw" Only sectors which contain data will be archived. b) Lhwarp READ 0 mydisk 0 79 mytext This will read tracks 0 to 79 of the disk in drive 0 (i.e. the entire disk), and will output the result to "mydisk.lhw". Only sectors which contain data will be archived. The text from the file "mytext" will be imported to the output file. Any text stored in the output file will be displayed when the disk is unarchived. c) Lhwarp -m READ 0 mydisk 0 79 This will read tracks 0 to 79 of the disk in drive 0 (i.e. the entire disk), and will output the result to "mydisk.lhw". All sectors will be archived, regardless of whether or not they contain data; the disk's bitmap is ignored with the '-m' option. d) Lhwarp WRITE 1 mydisk This will output all tracks stored in mydisk.lhw to drive 1. If any text was in the output file, it will be displayed. e) Lhwarp -c READ 0 mydisk 0 79 Same as a), except that the disk will be "vaporised." f) Lhwarp -s READ 0 mydisk 0 79 Same as a), except that the disk will be "squeezed." g) Lhwarp -b READ 0 mydisk 0 79 Same as a), except that tracks will be either squeezed or vaporisied, depending on which is more efficient. h) Lhwarp -m -c READ 0 mydisk 0 79 Same as e), except that the bitmap will be ignored. i) Lhwarp -v mydisk View composition of the file MYDISK.LHW. Please note that you must combine options in the format of: 'Lhwarp -a -b -c ...' Not: 'Lhwarp -abc ...' The latter may have unpredictable results (most probably all options but '-a' will be ignored.) Virus detection Some people have complained about Warp in that it aids the spreading of boot block viruses. It is for this reason that Lhwarp will display the bootblock of any disk it reads or writes, so that one can see what is being Lhwarp'd. Any non-standard looking bootblock should be viewed with suspicion. If you see a non-standard bootblock in read mode, this means that the disk you are reading from might possibly contain a virus. If you see this in write mode, it means that the file you are writing out to your disk may contain a virus. In either case, you should load a virus checker to make sure (such as VirusX 4.0) Specifications Lhwarp uses ETD_READ and ETD_FORMAT to read/write directly from/to the trackdisk.device. The 16 bytes of label information for each sector are saved in the output file. A 32-bit CRC protects data integrity. Future Possibilities o Support for raw track reads and writes o Merging output files o Mix raw/normal tracks in a single file Acknowledgements Huffman routines - Haruyasu Yoshizaki (lzhuf.c, v1.13c) Compress - S.Thomas, J.McKie, S.Davies, K.Turkowski, J.Woods, and J.Orost (compress.c) Squeezing - William Swan (sq.c/usq.c) Bitmap information - Leo Schwab (diskmap2.c) This Program Lhwarp is a freely distributable, copyrighted piece of software. You do not have to pay money to use it, and may upload it wherever you choose, but you are not allowed to sell Lhwarp for profit, or include Lhwarp on a disk which is sold for profit, without the author's (Jonathan Forbes) permission. I can be contacted at 416-927-7844 (voice.) Disclaimer I am in no way responsible for anything this program does; you are using it entirely at your own risk, so if you are kidnapped and held hostage by Libyan terrorists, don't blame me! Important note The STACK SIZE requirements have increased again, slightly -15k or so should be adequate. This will be corrected in a future version. Conclusion So there you have it; Lhwarp is faster and more efficent than Warp, and Lhwarp is being updated; Warp isn't! All that's missing is the support for raw track reads/writes, which will be implemented as soon as I find out how. Changes: LHWARP 1.21 A disk tracker for the Amiga Written by Jonathan Forbes Copyright © Xenomiga Technology, 1990 Version 1.01 Lhwarp 1.0 has a tiny bug, in that it won't output all of the extended sector data. Lhwarp 1.01 has fixed this bug, but has caused itself to be compatible with Lhwarp 1.0. Lhwarp 1.01 will produce smaller files than Lhwarp 1.0, because it now stores the extended sector data as part of the track data, for compression purposes. The sudden update shouldn't be too much trouble, because Lhwarp 1.0 was released less than 6 hours ago. Please delete the original Lhwarp 1.0 if you have it, and use Lhwarp 1.01 in its place. Version 1.02 Lhwarp 1.02 has implemented a 32-bit checksum, so that corrupted tracks can be reported. Version 1.02 is fully backwards compatible with version 1.01. Version 1.03 Lhwarp 1.03 uses only one track's worth of CHIP RAM (11k), for all its reading and writing to disk. Data is copied from the CHIP RAM disk buffer to FAST RAM (or, if you don't have FAST RAM, to some more CHIP RAM.) All compression and decompression is now done in FAST RAM, if possible, so compression time might possibly be smaller. Versions 1.00, 1.01 and 1.02 crashed often, most probably due to lack of stack space. Since my stack is permanently set to 90,000 bytes, I never noticed, and neither did anyone else with a large stack. Version 1.03 now allocates almost memory from Exec's free list, rather than using large auto arrays (the latter being a very bad programming practice anyway.) Stack size requirements have dropped by about 50k or so, to hopefully around 3k, but you may wish to use more (say, 10k), just to be safe. Support for RAW unencoded MFM data will be implemented soon. An option to append MFM data to an existing file will be provided. If you have any suggestions, contact me soon, so that they will be implemented quickly. Version 1.10 - 1st January, 1990 Welcome to the 90's. Lhwarp 1.10 is a significant upgrade; many of the compression/decompression functions have now been rewritten in assembly language. Check the accompanying "Lhwarp.doc" file for a timed comparison between new and old versions (as well as to Lharc.) The 32-bit checksum has been destroyed. Instead, a 32-bit CRC now protects data integrity. As a result of having a large auto array containing the 32-bit CRC, as well as various other small additions, the required stack size may have increased slightly; 10k is quite safe, however. Steps will be taken to decrease stack size requirements. File i/o now uses a 16k buffer if you have enough memory; if you don't, the default buffer size is used (whatever it is; probably 512 bytes or so.) Lhwarp will no longer archive sectors which are not used on the disk; the disk's bit map is checked to see which sectors are allocated, and only those are archived. This is much more efficient than Warp! To see for yourself, try compressing a blank disk; it takes a matter of seconds. The NOMAP option overrides the above, and ensures that every single sector is compressed, regardless of whether or not it contains data. The NOMAP command is to be used in place of READ, as a parameter. Earlier versions of Lhwarp will be unable to decompress files produced by Lhwarp 1.10. This cannot be helped. However, Lhwarp 1.10 can decompress files produced by earlier versions. Whichever version of Lhwarp is used, Lhwarp will inform you of which version the file was compressed with, and will take appropriate action. For additional specifications, please refer to "Lhwarp.doc", which has been updated. Version 1.11 - 2nd January, 1990 Another upgrade, one day later! Lhwarp 1.11 is a not as significant an upgrade as 1.10. However, the large speed increase of 1.11 justified another release. In addition to the speed increase, Lhwarp now displays sectors as they are archived or decompressed (just in case you were worried that Lhwarp has died on you from its inactivity.) Sectors marked with an '.' will be archived, while sectors marked with a '_' will not. Sectors will be marked with an 'o' as they are archived. Please refer to the updated documentation for more specifics. Version 1.20 - 6th January, 1990 Lhwarp now supports two more compression algorithms; squeezing and vaporising (the latter is the 14 bit version of UNIX Compress.) Both are much faster than the LHARC Adapative Huffman Encoding algorithm (called "freezing.") However, neither of them comes close to the compression ratio of freezing. Even so, the huge speed increase and reasonable compression rates should appeal to those who are less concerned with compression efficiency, and more concerned with speed. Freezing remains the default compression mode. Using the -c switch will cause the disk to be vaporised (not literally), while the -s switch will cause the disk to be squeezed. The -b option will cause each individual track to be either vaporised or squeezed, depending on which produces the smallest output. The -q option will cause Lhwarp to use its fastest and most reasonable algorithm on the disk. Currently, this is squeezing. Admittedly, vaporising is faster, but vaporising often generates track output which is actually larger than the track itself, and squeezing is almost as fast (certainly it's faster than freezing.) The most recommended option for speed, is the -b option, to select both algorithms; compression time is only a few minutes longer than that of one of the algorithms, and different algorithms sometimes work better for different disks. You cannot currently combine freezing with any other algorithm; this is for your own benefit; I have yet to see freezing beaten by vaporising or squeezing for any one track, ever! However, if you find that vaporising and squeezing frequently do compress tracks more efficiently, please inform me. To compress the NewTek DYNAMIC HI-RES demo disk: Compression Size Time (approximate) ----------- -------- ------------------ Freezing 671630 20:00 minutes Vaporising/Squeezing 770722 10:30 minutes Squeezing 803714 07:30 minutes Vaporising 869515 06:30 minutes Warp program 796665 15:00 minutes At this point in time, Lhwarp does not check to see if the output for a track is larger than the input; this is why vaporising produced such a huge file; many tracks compressed from 11k to 13k. This will be corrected in a future version. Lhwarp also supports viewing; you may see how Lhwarp has compressed a disk (which tracks are contained in the file, which algorithm was used to compress them, the source and destination lengths of each track, the number of sectors compressed, and the sector map of each track.) The viewing option will also display any attached text. After any attached text is displayed, you must press return; this was implemented so that the displaying of the boot block won't scroll the text off the screen. So there you have it; Lhwarp is faster and more efficent than Warp, and Lhwarp is being updated; Warp isn't! All that's missing is the support for raw track reads/writes, which will be implemented as soon as I find out how. More compression algorithms would be greatly appreciated, however. I have the source to "ZOO", but Compress (vaporising) is very similar. I have the source to "ARC", but don't wish to be sued, so I won't use any algorithms from there ("squeezing" was taken from Fred Fish disk #51, not ARC.) I also have the source to "squash" and "splint", but am unable to get them to work. If you have the C source to any decent compression algorithms, I'd appreciate it greatly. The ZIP algorithms would have been a good choice, now that PKZIP 1.0 is here. However, not only do I not have the source to ZIP, ZIP is not free, either; the author would probably want a large fee, or at least a fee for each Lhwarp in use. So, ZIP has been thrown out of the window. LHARC 2.0 should crush ZIP, anyway, so I'll just wait for that. Thanks to the person in New York (?) who sent me PKZIP 1.0 (sorry, I can't remember your name.) Version 1.21 - 8th January, 1990 I've just corrected a small bug which appeared in 1.20; information regarding text was not saved to the file. Now it is.