home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 340.lha / Lhwarp_v1.21 / Changes.doc.pp / Changes.doc
Encoding:
Text File  |  1990-02-11  |  8.4 KB  |  190 lines
  1.  
  2.                                    LHWARP 1.21
  3.  
  4.                            A disk tracker for the Amiga
  5.  
  6.                             Written by Jonathan Forbes
  7.                        Copyright © Xenomiga Technology, 1990
  8.  
  9.    Version 1.01
  10.  
  11.    Lhwarp 1.0 has a tiny bug, in that it won't output all of the extended
  12. sector data.  Lhwarp 1.01 has fixed this bug, but has caused itself to be
  13. compatible with Lhwarp 1.0.  Lhwarp 1.01 will produce smaller files than
  14. Lhwarp 1.0, because it now stores the extended sector data as part of the
  15. track data, for compression purposes.
  16.  
  17.    The sudden update shouldn't be too much trouble, because Lhwarp 1.0 was
  18. released less than 6 hours ago.  Please delete the original Lhwarp 1.0 if
  19. you have it, and use Lhwarp 1.01 in its place.
  20.  
  21.  
  22.    Version 1.02
  23.  
  24.    Lhwarp 1.02 has implemented a 32-bit checksum, so that corrupted tracks can
  25. be reported.  Version 1.02 is fully backwards compatible with version 1.01.
  26.  
  27.  
  28.    Version 1.03
  29.  
  30.    Lhwarp 1.03 uses only one track's worth of CHIP RAM (11k), for all its
  31. reading and writing to disk.  Data is copied from the CHIP RAM disk buffer
  32. to FAST RAM (or, if you don't have FAST RAM, to some more CHIP RAM.)  All
  33. compression and decompression is now done in FAST RAM, if possible, so
  34. compression time might possibly be smaller.
  35.  
  36.    Versions 1.00, 1.01 and 1.02 crashed often, most probably due to lack of
  37. stack space.  Since my stack is permanently set to 90,000 bytes, I never
  38. noticed, and neither did anyone else with a large stack.
  39.  
  40.    Version 1.03 now allocates almost memory from Exec's free list, rather
  41. than using large auto arrays (the latter being a very bad programming
  42. practice anyway.)  Stack size requirements have dropped by about 50k or so,
  43. to hopefully around 3k, but you may wish to use more (say, 10k), just to be
  44. safe.
  45.  
  46.    Support for RAW unencoded MFM data will be implemented soon.  An option to
  47. append MFM data to an existing file will be provided.
  48.  
  49.    If you have any suggestions, contact me soon, so that they will be
  50. implemented quickly.
  51.  
  52.  
  53.  
  54.    Version 1.10 - 1st January, 1990
  55.  
  56.    Welcome to the 90's.
  57.  
  58.    Lhwarp 1.10 is a significant upgrade; many of the compression/decompression
  59. functions have now been rewritten in assembly language.  Check the
  60. accompanying "Lhwarp.doc" file for a timed comparison between new and old
  61. versions (as well as to Lharc.)
  62.  
  63.    The 32-bit checksum has been destroyed.  Instead, a 32-bit CRC now protects
  64. data integrity.  As a result of having a large auto array containing the
  65. 32-bit CRC, as well as various other small additions, the required stack size
  66. may have increased slightly; 10k is quite safe, however.  Steps will be taken
  67. to decrease stack size requirements.
  68.  
  69.    File i/o now uses a 16k buffer if you have enough memory; if you don't, the
  70. default buffer size is used (whatever it is; probably 512 bytes or so.)
  71.  
  72.    Lhwarp will no longer archive sectors which are not used on the disk; the
  73. disk's bit map is checked to see which sectors are allocated, and only those
  74. are archived.  This is much more efficient than Warp!  To see for yourself,
  75. try compressing a blank disk; it takes a matter of seconds.
  76.  
  77.    The NOMAP option overrides the above, and ensures that every single sector
  78. is compressed, regardless of whether or not it contains data.  The NOMAP
  79. command is to be used in place of READ, as a parameter.
  80.  
  81.    Earlier versions of Lhwarp will be unable to decompress files produced by
  82. Lhwarp 1.10.  This cannot be helped.  However, Lhwarp 1.10 can decompress
  83. files produced by earlier versions.  Whichever version of Lhwarp is used,
  84. Lhwarp will inform you of which version the file was compressed with, and will
  85. take appropriate action.
  86.  
  87.    For additional specifications, please refer to "Lhwarp.doc", which has been
  88. updated.
  89.  
  90.  
  91.    Version 1.11 - 2nd January, 1990
  92.  
  93.    Another upgrade, one day later!  Lhwarp 1.11 is a not as significant an
  94. upgrade as 1.10.  However, the large speed increase of 1.11 justified another
  95. release.
  96.  
  97.    In addition to the speed increase, Lhwarp now displays sectors as they are
  98. archived or decompressed (just in case you were worried that Lhwarp has died
  99. on you from its inactivity.)  Sectors marked with an '.' will be archived,
  100. while sectors marked with a '_' will not.  Sectors will be marked with an 'o'
  101. as they are archived.
  102.  
  103.    Please refer to the updated documentation for more specifics.
  104.  
  105.  
  106.    Version 1.20 - 6th January, 1990
  107.  
  108.    Lhwarp now supports two more compression algorithms; squeezing and
  109. vaporising (the latter is the 14 bit version of UNIX Compress.)  Both are much
  110. faster than the LHARC Adapative Huffman Encoding algorithm (called
  111. "freezing.")  However, neither of them comes close to the compression ratio of
  112. freezing.
  113.  
  114.    Even so, the huge speed increase and reasonable compression rates should
  115. appeal to those who are less concerned with compression efficiency, and more
  116. concerned with speed.
  117.  
  118.    Freezing remains the default compression mode.  Using the -c switch will
  119. cause the disk to be vaporised (not literally), while the -s switch will cause
  120. the disk to be squeezed.  The -b option will cause each individual track to be
  121. either vaporised or squeezed, depending on which produces the smallest output.
  122.  
  123.    The -q option will cause Lhwarp to use its fastest and most reasonable
  124. algorithm on the disk.  Currently, this is squeezing.  Admittedly, vaporising
  125. is faster, but vaporising often generates track output which is actually
  126. larger than the track itself, and squeezing is almost as fast (certainly it's
  127. faster than freezing.)
  128.  
  129.    The most recommended option for speed, is the -b option, to select both
  130. algorithms; compression time is only a few minutes longer than that of one of
  131. the algorithms, and different algorithms sometimes work better for different
  132. disks.
  133.  
  134.    You cannot currently combine freezing with any other algorithm; this is for
  135. your own benefit; I have yet to see freezing beaten by vaporising or squeezing
  136. for any one track, ever!  However, if you find that vaporising and squeezing
  137. frequently do compress tracks more efficiently, please inform me.
  138.  
  139.    To compress the NewTek DYNAMIC HI-RES demo disk:
  140.  
  141.    Compression               Size     Time (approximate)
  142.    -----------             --------   ------------------
  143.    Freezing                 671630    20:00 minutes
  144.    Vaporising/Squeezing     770722    10:30 minutes
  145.    Squeezing                803714    07:30 minutes
  146.    Vaporising               869515    06:30 minutes
  147.    Warp program             796665    15:00 minutes
  148.  
  149.    At this point in time, Lhwarp does not check to see if the output for a
  150. track is larger than the input; this is why vaporising produced such a huge
  151. file; many tracks compressed from 11k to 13k.  This will be corrected in a
  152. future version.
  153.  
  154.    Lhwarp also supports viewing; you may see how Lhwarp has compressed a disk
  155. (which tracks are contained in the file, which algorithm was used to compress
  156. them, the source and destination lengths of each track, the number of sectors
  157. compressed, and the sector map of each track.)  The viewing option will also
  158. display any attached text.
  159.  
  160.    After any attached text is displayed, you must press return; this was
  161. implemented so that the displaying of the boot block won't scroll the text off
  162. the screen.
  163.  
  164.    So there you have it; Lhwarp is faster and more efficent than Warp, and
  165. Lhwarp is being updated; Warp isn't!  All that's missing is the support for
  166. raw track reads/writes, which will be implemented as soon as I find out how.
  167.  
  168.    More compression algorithms would be greatly appreciated, however.  I have
  169. the source to "ZOO", but Compress (vaporising) is very similar.  I have the
  170. source to "ARC", but don't wish to be sued, so I won't use any algorithms from
  171. there ("squeezing" was taken from Fred Fish disk #51, not ARC.)  I also have
  172. the source to "squash" and "splint", but am unable to get them to work.  If
  173. you have the C source to any decent compression algorithms, I'd appreciate it
  174. greatly.
  175.  
  176.    The ZIP algorithms would have been a good choice, now that PKZIP 1.0 is
  177. here.  However, not only do I not have the source to ZIP, ZIP is not free,
  178. either; the author would probably want a large fee, or at least a fee for each
  179. Lhwarp in use.  So, ZIP has been thrown out of the window.  LHARC 2.0 should
  180. crush ZIP, anyway, so I'll just wait for that.
  181.  
  182.   Thanks to the person in New York (?) who sent me PKZIP 1.0 (sorry, I can't
  183. remember your name.)
  184.  
  185.  
  186.    Version 1.21 - 8th January, 1990
  187.  
  188.    I've just corrected a small bug which appeared in 1.20; information
  189. regarding text was not saved to the file.  Now it is.
  190.