home *** CD-ROM | disk | FTP | other *** search
/ Acorn User 3 / AUCD3.iso / funland / emulators / c64 / d64imagefs / !D64FS / !Help < prev    next >
Text File  |  1997-08-03  |  9KB  |  228 lines
  1. D64FS - An Image Filing System for C64 disc images (V0.10)
  2. ==========================================================
  3.  
  4.  
  5. This program is NOT Freeware. For more see below.
  6.  
  7. (Changes in version 0.10 see below)
  8.  
  9. Now with a native RISC OS C64-Emulator available there's the question
  10. of how to get software for the emulator. The most common source data
  11. are files in T64 and D64 format. The former are tape archive files
  12. with a very simple structure, used mainly for programs that don't
  13. load any additional files after startup. The later are byte-for-byte
  14. copies of VC1541 disc images used mostly for programs that do load
  15. additional files. In contrast to T64 archives extracting files from
  16. a D64 disc image is considerably more complicated than 10 seconds
  17. worth of editing. Therefore I chose to write this image filing system
  18. which does the job for you and also shows why a modular OS is a
  19. really good idea.
  20.  
  21. All you have to do is start the module (type "help d64fs" at the
  22. command line to see if it's active) and give the disc images the
  23. file type &164 (D64Image). This filetype, the module name and its star
  24. commands are all registered at Acorn, therefore this release is
  25. official.
  26. That done you merely have to double-click on the image to open a
  27. filer window with its contents. Accessing files is considerably
  28. slower than with native RISC OS files. One reason for this is that
  29. the data blocks contained in a file can be spread over a large area of
  30. the image file. The other one is that C64 disc images don't give the
  31. _exact_ size of a file with its directory entry (only the number of
  32. blocks which doesn't even have to be correct). RISC OS has to know
  33. the exact size of a file _before_ loading, however, so when loading
  34. a file it has to be scanned first; that means the file will have to
  35. be traversed twice, hence the delay.
  36. Of course I might have claimed lots of RMA space for buffering but I
  37. decided against this on the grounds that D64FS is not supposed to be
  38. a high performance FS for everyday use but a convenient and RISC OS
  39. compliant way of accessing this type of data. If you're doing lots
  40. of operations on a disc image you can always speed things up a lot
  41. by copying it into a RAM disc.
  42.  
  43. D64FS is read _and write_ so you can also copy stuff into disc images
  44. or create new ones. The disc image size is not fixed to the standard
  45. 35 tracks but may be any value between 18 and 40 (or 70 in V0.10). If
  46. the number of tracks lies between 36 and 40 the format used for the BAM
  47. will be that of Dolphin DOS (that means essentially that the BAM entries
  48. for tracks 36-40 start in Block 18,0 at offset &ac).
  49.  
  50. Discs aren't recognized if the image is less than 18 "tracks" long
  51. (no directory track) or the first two bytes in block 18,0 are not 18,1.
  52. I used to check for the full 18,1,65,0 as given in the VC1541 manual
  53. but discarded that again when I came across disc images that didn't
  54. conform with this.
  55.  
  56.  
  57. Name conversions:
  58. -----------------
  59.  
  60. This is a bit tricky since the character sets used by RISC OS and by
  61. the C64 are rather different. You shouldn't experience any trouble if
  62. you stick to non-accented (top bit clear) characters (with the exception
  63. of char #152 (—) and char #156 (†) which are OK), best to keep them lower
  64. case as well. Some CBM-characters are translated to the same RISC OS
  65. characters, however, so there might be name clashes (for instance `.' and
  66. <arrow left> are both translated to `_'). So far I haven't experienced any
  67. trouble but be warned that there may be.
  68.  
  69.  
  70. Filetype conversions:
  71. ---------------------
  72.  
  73. This is even trickier. The C64 knows 5 different filetypes, namely DEL,
  74. SEQ, PRG, USR and REL. I don't think using up 5 RISC OS filetypes just
  75. for this is a good idea and besides hardly anything but PRG is used
  76. anyway (with the exception of DEL which is only used on empty files,
  77. though). So I chose the following mappings (changed in V0.10):
  78.  
  79. DEL <--> &ffe    Command
  80. SEQ <--> &ffd    Data
  81. PRG <--> &064    (the filetype used by !Breadbox)
  82. USR <--> &ffc    Utility
  83. REL <--> &feb    Obey
  84.  
  85. If you copy a RISC OS file with a different filetype into a disc image
  86. its type will default to PRG (&064).
  87. Warning: D64FS can only write sequential files in the broader sense (everything
  88. but REL, AFAIK). It'll still write REL files but those will be unusable on a
  89. C64. Also reading existing ones will probably not yield the desired results.
  90. I don't feel like changing this ATM since I never used REL files even when I
  91. was still using a C64...
  92.  
  93.  
  94.  
  95.  
  96. Command Line options:
  97. =====================
  98.  
  99. D64FS offers two commands:
  100.  
  101. D64create [-t x] <filename> <discname,id>
  102.     This command creates a disc image file named <filename> with
  103.     x tracks (x between 18 and 40 or 70, default 35). The disc name (up
  104.     to 18 chars) and id (2 chars) are stored in the image; everyone
  105.     who ever worked with a C64 will know what they are.
  106.  
  107. D64tidy [-v -r -c] <filename>
  108.     This does various operations on a C64 image file. Be warned
  109.     that these operations might take some time (very much dependent
  110.     on what kind of device the image is stored on - this should be
  111.     a harddisc or a RAM disc). The aim of these operations is mostly
  112.     to discard any unused space and thus make the image file compress
  113.     better. Be warned that if the disc contains information not stored
  114.     in files this data will be lost irretrievably (-c,-r) or exposed
  115.     to overwriting (-v). Neither problem can arise with images created
  116.     by D64FS. When in doubt don't tidy up the disc!
  117.  
  118.     -v    Validate disc. That means update the BAM (block allocation
  119.         map), i.e. scan all files to determine which blocks are
  120.         used and which are not and write the result on the image.
  121.         This operation may be used if the BAM has been corrupted
  122.         for some reason. If the disc image contains data not stored
  123.         in files a following write-operation might overwrite it!
  124.  
  125.     -r    Clear unused rest of partially filled blocks. The last
  126.         block of a file is usually not filled to the end. The data
  127.         contained in the rest of the block has no purpose whatsoever
  128.         if the disc image contains only files and thus may be deleted
  129.         (i.e. overwritten with 0s).
  130.  
  131.     -c    Clear unused blocks. The most dangerous operation which will
  132.         fill entire blocks with 0s if they're marked unused in the
  133.         BAM. If the disc image contains data not stored in files
  134.         or a corrupt BAM data will be lost permanently so handle
  135.         with care!
  136.  
  137.     If you specify more than one switch the operations will be executed
  138.     in the following order: first -v and/or -r in parallel, then -c.
  139.     E.g. -v -c will first update the BAM and then clear unused blocks.
  140.  
  141.  
  142.  
  143.  
  144.  
  145. LIMITATIONS:
  146. ------------
  147.  
  148. To keep down the workspace size the maximum number of open D64Image files is
  149. currently set to 32. If the module complains about there being too many open
  150. images you'll have to close some of them, for instance by typing *close at
  151. the CLI (which closes all open files on the current FS).
  152. The number of open files within D64 images is limited to 32 as well. This
  153. should usually not be a problem, though, since there's hardly ever more than
  154. one open (unless some program messed up).
  155.  
  156.  
  157.  
  158.  
  159.  
  160. CHANGES IN VERSION 0.10
  161. =======================
  162.  
  163. 1) Fixed some bugs concerning full discs: the correct error message is passed
  164.    back and a file that didn't fit entirely will be deleted automatically.
  165.  
  166. 2) D64FS now can handle 1571 images as well. Those are double-sided disc-images
  167.    with a length of 349696 bytes, corresponding to 70 tracks. Unlike with the
  168.    single-sided discs there is no variation allowed here, it has to be exactly
  169.    this size. Double-sided discs can also be created with D64create and cleaned
  170.    up with D64tidy.
  171.  
  172. 3) Changed the filetype-mappings a little.
  173.  
  174. 4) Fixed "bug" in the directory-code that could lead to certain files not being
  175.    displayed in some cases.
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182. KNOWN BUGS:
  183. -----------
  184.  
  185. 1) Files with zero length will take up one data block nonetheless. But that's
  186.    not really a bug since files like these are pretty senseless anyway.
  187.  
  188. 2) None I found so far (...and are still present...)
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195. LEGAL ISSUES and CONTACT:
  196. =========================
  197.  
  198. Since Videoware failed this program's status is hereby changed to SHAREWARE.
  199. That includes all previous versions, you can't avoid registering by not
  200. upgrading.
  201. You may use D64FS for a trial period of two weeks. After that time you must
  202. either delete it or register. The registration fee is 5 UK Pounds or 15 German
  203. Marks (if neither currency is native to you I prefer Marks). Cash or Eurocheques
  204. are fine with me. My snail mail address is
  205.  
  206.  
  207. Andreas Dehmel
  208. Am Schorn 18
  209. 82327 Tutzing
  210. Germany
  211. email:    dehmel@informatik.tu-muenchen.de
  212.     (for now...)
  213.  
  214.  
  215. I refuse any responsibility for any kind of damages resulting from the use of
  216. this program. So far nobody has reported anything serious to me but bear in mind
  217. that usage is entirely at your own risk.
  218.  
  219.  
  220.  
  221.  
  222.  
  223. Happy nostalgia,
  224.  
  225.  
  226.  
  227. Andreas Dehmel, August 97.
  228.