home *** CD-ROM | disk | FTP | other *** search
/ The Fred Fish Collection 1.5 / ffcollection-1-5-1992-11.iso / ff_disks / 200-299 / ff295.lzh / Lhwarp / Changes.doc < prev    next >
Text File  |  1989-12-27  |  2KB  |  51 lines
  1.                                    LHWARP 1.03
  2.  
  3.                            A disk tracker for the Amiga
  4.  
  5.                             Written by Jonathan Forbes
  6.                        Copyright © Xenomiga Technology, 1990
  7.  
  8.    Version 1.01
  9.  
  10.    Lhwarp 1.0 has a tiny bug, in that it won't output all of the extended
  11. sector data.  Lhwarp 1.01 has fixed this bug, but has caused itself to be
  12. compatible with Lhwarp 1.0.  Lhwarp 1.01 will produce smaller files than
  13. Lhwarp 1.0, because it now stores the extended sector data as part of the
  14. track data, for compression purposes.
  15.  
  16.    The sudden update shouldn't be too much trouble, because Lhwarp 1.0 was
  17. released less than 6 hours ago.  Please delete the original Lhwarp 1.0 if
  18. you have it, and use Lhwarp 1.01 in its place.
  19.  
  20.  
  21.    Version 1.02
  22.  
  23.    Lhwarp 1.02 has implemented a checksum, so that corrupted tracks can be
  24. reported.  Version 1.02 is fully backwards compatible with version 1.01.
  25.  
  26.  
  27.    Version 1.03
  28.  
  29.    Lhwarp 1.03 uses only one track's worth of CHIP RAM (11k), for all its
  30. reading and writing to disk.  Data is copied from the CHIP RAM disk buffer
  31. to FAST RAM (or, if you don't have FAST RAM, some more CHIP RAM.)  All
  32. compression and decompression is now done in FAST RAM, if possible, so
  33. compression time might possibly be smaller.
  34.  
  35.    Versions 1.00, 1.01 and 1.02 crashed often, most probably due to lack of
  36. stack space.  Since my stack is permanently set to 90,000 bytes, I never
  37. noticed, and neither did anyone else with a large stack.
  38.  
  39.    Version 1.03 now allocates almost memory from Exec's free list, rather
  40. than using large auto arrays (the latter being a very bad programming
  41. practice anyway.)  Stack size requirements have dropped by about 50k or so,
  42. to hopefully around 3k, but you may wish to use more (say, 10k), just to be
  43. safe.
  44.  
  45.    Support for RAW unencoded MFM data will be implemented soon.  An option to
  46. append MFM data to an existing file will be provided.
  47.  
  48.    If you have any suggestions, contact me soon, so that they will be
  49. implemented quickly.
  50.  
  51.