home *** CD-ROM | disk | FTP | other *** search
/ Gold Fish 2 / goldfish_vol2_cd1.bin / files / disk / misc / devblocks / devblocks.doc < prev    next >
Encoding:
Text File  |  1993-12-21  |  8.3 KB  |  203 lines
  1. Programs:           GetDevBlocks, PutDevBlocks
  2. Author:             Christian Wasner
  3. Last changed:       Oct 13, 1993
  4.  
  5.  
  6. i) Disclaimer
  7.  
  8. The author cannot be held liable for the suitability or accuracy of this
  9. manual and/or the program(s) it describes.  Any damage directly or
  10. indirectly caused by the use or misuse of this manual and/or the program
  11. it describes is the sole responsibility of the user her/him self.
  12.  
  13.  
  14. ii) Copyright/Distribution
  15.  
  16. GetDevBlocks, (c) Copyright 1993 Christian Wasner. All rights reserved.
  17. PutDevBlocks, (c) Copyright 1993 Christian Wasner. All rights reserved.
  18.  
  19. These programs are FREEWARE, so no financial donations are required (but
  20. welcome).They may be freely distributed as long as all documentation and
  21. executable(s) remain unchanged and are included with the distribution. Also
  22. no profit is to be made by selling this program.
  23. They must not be added to other PD-libraries than AmigaLibDisks from Fred
  24. Fish without my written permission. The price must not exceed the costs of
  25. disk, package and mailing.
  26.  
  27.  
  28. iii) Files
  29.  
  30. The following files should come along:
  31.  
  32. DevBlocks.doc
  33. GetDevBlocks
  34. PutDevBlocks
  35.  
  36. Anything that does not contain these three files is an ILLEGAL COPY !
  37.  
  38.  
  39. iv) Documentation
  40.  
  41. WARNING ! THIS TOOLS ARE FOR EXPERT USERS ONLY !
  42. USE OF THESE PROGRAMS, ESPECIALLY PUTDEVBLOCKS, CAN CAUSE SEVERE DAMAGE TO YOUR
  43. FLOPPY DISKS OR HARD DISK ! USE WITH CARE !
  44.  
  45. General note: There is a difference between sectors and blocks. A block can
  46.               have more than one sector. Since my program only supports
  47.               devices with one sector par block, both means the same.
  48.  
  49. GetDevBlocks and PutDevBlocks can be used only from CLI, it will abort when
  50. started from WB. For this reason it is described like a CLI command.
  51.  
  52.  
  53. Program:       GetDevBlocks
  54.  
  55. Format:        GetDevBlocks <diskdevice> <track> <head> <block> <numblocks>|ALL
  56.                  <filename> [LAB] [DUMP]
  57.  
  58. Template:      DISKDEV/A,TRACK/A,HEAD/A,BLOCK/A,NUMBLOCKS/A,FILENAME/A,LAD/S,
  59.                DUMP/S
  60.  
  61. Purpose:       To read blocks from any disk device (i.e. any DOS device with
  62.                tracks, heads and blocks like DF0:)
  63.  
  64. Specification: This program reads blocks from a disk-type DOS device (e.g. DF0:
  65.    or DH0:). Such a device is organized by accessing it by tracks, surfaces and
  66.    blocks. Only devices that have one sector per block are supported. The block
  67.    length may be something other than the usual 512 bytes. The data to be read
  68.    is specified by the the first track/head/block and the number of blocks. If
  69.    the keyword ALL is given for the number of blocks the device all blocks
  70.    after the start position are read. The data is written into a file. If the
  71.    keyword DUMP is set a hex dump is written into the file, in a format like
  72.    TYPE OPT H. A hex dump line looks like this:
  73.  
  74.    000A4520: 4E55FCF8 48E73032 307C0004 2650204B   NUüøHç020|..&P K     
  75.       ^         ^                                        ^
  76.       |         |                                        |
  77.       |         |                                 ASCII dump (non-printable
  78.       |         |                                 characters are displayed
  79.       |         |                                 with a '.')
  80.       |         |
  81.       |     Hexadecimal dump (4 longwords separated by spaces)
  82.       |
  83.    Hexadecimal offset from device start
  84.  
  85.    If the keyword LAB is set the label buffers are saved into 'foo.lab'
  86.    (assuming the filename of the other data is 'foo').
  87.    If you specify '*' as filename the data is written to the standard output,
  88.    not to the standard error output (which is normally specified by '*'). If
  89.    DUMP is not set an ASCII dump (i.e. 64 characters per line, '.' for non-
  90.     printable characters) is sent to the standard output then. Each two blocks
  91.     you are asked to press RETURN. If DUMP is set a hex dump is written (see
  92.     above) and each 256 bytes you are asked to press RETURN.
  93.  
  94. Examples:
  95.    Reading the boot block and the label buffers of the disk in df0: to a
  96.    hex dump named 'bb'. The label buffer file is 'bb.lab':
  97.  
  98.    1> GetDevBlocks DF0: 0 0 0 2 bb lab dump
  99.  
  100.    Reading df0: from track 60, head 1, block 4 to its end without label
  101.    buffers into '40_1_4_all':
  102.  
  103.    1> GetDevBlocks DF0: 40 1 4 all 40_1_4_all
  104.  
  105.  
  106.  
  107. PutDevBlocks
  108.  
  109. Format:        PutDevBlocks <diskdevice> <track> <head> <block> <numblocks>|ALL
  110.                  <filename> [LAB] [DUMP] [FORMAT]
  111.  
  112. Template:      DISKDEV/A,TRACK/A,HEAD/A,BLOCK/A,NUMBLOCKS/A,FILENAME/A,LAD/S,
  113.                DUMP/S,FORMAT/S
  114.  
  115. Purpose:       To write blocks to any disk device (i.e. any DOS device with
  116.                tracks, heads and blocks like DF0:)
  117.  
  118. Specification: This program writes blocks to a disk-type DOS device (e.g. DF0:
  119.    or DH0:). Such a device is organized by accessing it by tracks, surfaces and
  120.    blocks. Only devices that have one sector per block are supported. The block
  121.    length may be something other than the usual 512 bytes. The blocks to be
  122.    written to are specified by the the first track/head/block and the number of
  123.    blocks. If the keyword ALL is given for the number of blocks the device will
  124.    be written until the file ends or the end of the device is reached.If the
  125.    source file ends before all specified tracks are written the program writes
  126.    the last incomplete block to disk and stops. If the keyword DUMP is set
  127.    the source file is treated like a hex dump with exactly the same format as
  128.    the one used by GetDevBlocks, i.e. a hex dump line must look like this:
  129.  
  130.    xxxxxxxxxx4E55FCF8 48E73032 307C0004 2650204Bxxxxxxxxxxxxxxxxxxx
  131.       ^         ^                                        ^         ^
  132.       |         |                                        |         |
  133.       |         |                                        |   RETURN ($0A)
  134.       |         |                                        |
  135.       |         |                                 Any 19 characters
  136.       |         |
  137.       |       Hexadecimal dump (4 longwords separated by one space each)
  138.       |
  139.    Any 10 characters
  140.  
  141.    If the keyword LAB is not set then zeroes will be written into the label
  142.    buffers. If LAB is set the label buffer data is read from <file>.lab in
  143.    the same way as from <file>. If <file>.lab is not long enough to fill all
  144.    label buffers, the program writes the last incomplete block to disk and
  145.    stops.
  146.    The keyword FORMAT specifies that any track which data is written to will
  147.    be formatted. This means that all other blocks of the track are erased.
  148.    Use this keyword for unfomatted disks only. Note that using FORMAT along
  149.    with LABEL may fail because label buffers will only be written when for-
  150.    matting with ETD_FORMAT. ETD_FORMAT may not be implemented to some disk
  151.    devices (e.g. with my hard disk controller device, oktagon.device, doesn't
  152.    support ETD commands fully) while with DFx: it works. Typical types of
  153.    failure are a command-not-implemented error or a verify error. To circumvent
  154.    this problem you have to format your disk device before using PutDevBlocks
  155.    (without FORMAT keyword of course). See autodocs, trackdisk.doc, TD_FORMAT
  156.     for more.
  157.  
  158.  
  159. Examples:
  160.    Writing the contents of a hexdump 'bb' to the boot block of df0: along with
  161.    the label buffers (from a hex dump 'bb.lab'):
  162.  
  163.    1> PutDevBlocks DF0: 0 0 0 2 bb lab dump
  164.  
  165.    Writing file '40_1_4_all' to df0: from track 60, head 1, block 4 to its end
  166.     with cleared label buffers (the track to be written to are formatted):
  167.  
  168.    1> PutDevBlocks DF0: 40 1 4 all 40_1_4_all format
  169.  
  170.  
  171. v) Compatibility
  172.  
  173.    These programs should run with Kickstart V1.3 and up. They may run with
  174.     lower Kickstart but this isn't tested (I haven't plugged in ye olde ROMs).
  175.  
  176.  
  177. vi) Bugs
  178.  
  179. No bugs are known to me but I don't believe that there aren't. If you should
  180. detect a bug, please tell me (email or phone). Be as specific as you can.
  181.  
  182.  
  183. vii) Sourcecodes
  184.  
  185. The sourcecodes are not for free and may not be distributed in any way. They
  186. may be obtained in exchange with other sourcecodes that interest me (only C
  187. and Assembler, please). See my address below.
  188.  
  189.  
  190. ix) Address
  191.  
  192. I will not give my address to the public because of bad experiences I have
  193. heard of ("We know that you are a pirate. Send us $1000 or we...", getting
  194. into computers of address dealers etc.). Use the telephone or email (the
  195. latter is preferred). Persons I know a little can get my address, of course.
  196.  
  197. Christian Wasner
  198.  
  199. Phone - from out of Germany: <number for Germany>40/7235533
  200.        -from within Germany: 040/7235533
  201.  
  202. Email: wasner@ifm.uni-hamburg.de
  203.