1581CP54.ZIP             1581-Copy, version 0.54               2002-07-14


 ************************** IMPORTANT  notice **************************
 *                                                                     *
 * Older versions of 1581-Copy (0.4, 0.4x, 0.50, 0.51, 0.52) are       *
 * affected by a   VERY  CRITICAL  BUG  , don't use any versions older *
 * than 1581-Copy 0.53. Please remove any of these older versions from *
 * your web pages or FTP servers. If you see older versions somewhere  *
 * in the web, in mail boxes or on other sharing places, please inform *
 * these people to remove the old versions and to replace it with at   *
 * least version 0.53.                                                 *
 *                                                                     *
 ************************** IMPORTANT  notice **************************



(C) Copyright 1998-2002 Wolfgang Moser <womo_(at)_d81_(dot)_de>
    published under the GNU public license

    1581-Copy is an official FairLight tools release,
    visit FairLight at http://www.fairlight.to


1. Introduction
2. Troubleshooting
3. Parameter description and return codes
4. Some details about the sector layout of MFM encoded Commodore disks
   and the internals of 1581-Copy
5. Something about the image file formats used by 1581-Copy
6. Linux and Commodore MFM encoded disks
7. The Credits
8. Additional and distribution info
9. Contact


1. Introduction

   This is version 0.54 of the CBM 1581 floppy disk copy util for DOS. It
   should be able to im- or export a CBM 1581 disk within 39 seconds on a
   PC based 3.5" floppy drive and disk controller. There are also some
   informations about Linux and Commodore disks included.


   If you don't have some 3.5" DD (double density) disks anymore, but
   want to test this tool you can do the following: Get a normal 1,44 MB
   3,5" HD disk and close the second detection whole (it's on the other
   side of the write protection switch) on the floppy disk by putting
   some adhesive tape over it. Take notice, that writing won't work with
   this method on drives that contain a DD mechanic only (720 KB).
   But some CBM 1581 disk drives and most of the PC floppy drives contain
   HD mechanics (1,44 MB), that are able to write "taped" HD disks. I
   don't know, what happens, if you replace your CBM 1581 drive mechanic
   by a PC based HD drive mechanic (1,44 MB disk drive), because I never
   tested it, I do own only some CBM 1541 disk drives myself. Don't ask,
   how I was able to write this utility without having a CBM 1581,
   otherwise you may think, that I'm very crazy or simply mindless!

   Included within this package is a user menu configuration file for
   The Star Commander. It supplies the Commander with some very simple
   methods for importing and exporting disk images from and to drive A:
   (press F2, when browsing the standard file system). Importing disks
   without overwrite takes only the first part of the filename (without
   extension) and generates a new filename with the appropriate extension
   (D81 or D2M). Be sure to select a file with the correct extension, if
   you want to use importing with overwrite. If you want to import into
   a completely new generated file, you have to create a new empty image
   first (Shift-F1) followed by renaming it to the correct extension. It
   doesn't matter, if the file has the wrong file size, 1581-Copy
   corrects this, if overwrite importing is selected.

   There's a modified floppy disk parameter table for Linux included into
   this package. This way you should be able to do image file transfers
   under Linux, too. First the GAP sizes for the CBM1581 parameter have
   been adjusted to a better working value, secondly a parameter for CMD
   FD2000 support has been added. Try it out, if you are Linux'ed.


2. Troubleshooting

   You may encounter some problems, if your floppy disc controller is of
   some unusual type or if you run this tool under multitasking
   environments. 1581-Copy has some parameters that control, how the
   tracks of the floppy are accessed. Please try out the following
   sequence, if your drive doesn't reach an im-/export speed of less than
   40 seconds per disc:

     1. If the multiple sector feature doesn't work on your system (some
        systems may hangup), you should preselect single sector copying
        (/S), but this may slow down the transfer a little.

     2. If the transfer is much too slow you should try out higher
        interleaves starting with two (/I:2). If you had to preselect
        single sector copying (/S), the transfer will slow down to about
        70 seconds.

     3. Try out higher interleaves, but be warned, this will decrease
        the transfer performance heavily. Nevertheless, it may be higher
        than without any parameter.

     4. If you can't optimize the performance on your system and want to
        transfer only a single file (along with it's image), you should
        delete all unused files from the disk (with your C64) or the disk
        image (with The Star Commander or another tool). Then try out the
        BAM copy switch (/B), that transfers only tracks which are
        allocated by the file.

     5. If disks aren't recognized by 1581-Copy ("CBM incompatible disk
        media detected"), but you are sure, that this is a disk
        recognized from your CBM 1581 floppy, disable the "swapped side
        ID" media check (/D). This prevents 1581-Copy from doing too much
        consistency checks.


3. Parameter description and return codes

   1581COPY [/F[:x] /V /B /M /S /D /N /R:nnn /I:n /T:nnn /H:s] [SRC] DST

     SRC - This is the source disk or image file. If you read a disk, it
           must be a filename. If you write or format and write a disk,
           this must be a disk drive (A: or B:). When you want to format
           disks only, this parameter must not be specified.

     DST - This is the destination disk or image file. If you read a
           disk, it has to be the disk drive (A: or B:). If you write or
           format and write a disk, it must be a filename. When you want
           to format disks only, this parameter selects the disk drive,
           which does the formatting.


     /F[:x]
         - This switch enables formatting. If you are in the write mode,
           the disk is formatted before writing any contents to it. If
           the disk is not in write mode, this switch selects formatting
           only; you mustn't specify the SRC parameter then. If
           formatting only is selected, an empty default BAM is written
           to the disk and a system partition on CMD FD2000 disks, too.
           With the additional parameter 'x' you are able to specify the
           destination format; 2 selects the CMD FD2000 disk format, 1
           selects the CBM 1581 format. If this parameter is not
           specified and you aren't writing an image to the disk, always
           the CBM 1581 is selected.

     /F:W
         - This switch let's 1581-Copy use a very special floppy disk
           controller command, that is available on intel's 82078
           controller. It makes it possible to format and write a track
           at once. If you think you own such an intel controller, please
           (PLEASE !!! :-) send me a report with the FDC type (ranges
           0x9001...0x901F and 0x9041...0x905F), the command line
           switches and something else you did.
           Because this routine couldn't be tested much, it is
           recommended to use it in combination with verify (/V).

     /V  - This switch enables the verify mode. It can be used, if you
           write and/or format disks. It doesn't compare the disk
           contents written with the source buffer again, but does a CRC
           check of the written data only.


     /B  - Enables _simple_ BAM copying. Only tracks with allocated
           blocks on it are transferred. Be careful with this option,
           because if the BAM or the directory of the desired disk or
           image file are _not_ allocated correctly, 1581-Copy may not
           copy the BAM and/or directory of this disk/image; this can
           produce effects you may not expect.

     /M  - Enables mass importing or formatting with least user
           interaction. You can read or only format multiple disks, if
           you enable this switch. After a disk has been processed,
           1581-Copy proceeds automatically after a disk change has been
           detected. If reading is selected, new filenames are generated
           automatically with Joe Forster's indexing algorithm. Multiple
           disk writing is not possible.

     /S  - Preselects the single sector copy and disables the "read/write
           multiple sectors" FDC feature, if this feature produces
           hangups on your system. On some special controllers (e.g.
           Adaptec 2842) or under multitasking OSes, disabling multiple
           sector copying will slow down the transfer a lot.

     /D  - Disables the "swapped side ID" CBM format check. If 1581-Copy
           complains about a "CBM incompatible disk media detected" but
           you are very sure, that you created and/or used this disk on a
           CBM 1581 (CMD FD2000) disk drive, you should try out this
           parameter. But be warned, the data read may be incomplete,
           wrong or corrupted. If you want to write to such a disk, it
           would be much better to reformat the disk while writing.

     /N  - You can tell 1581-Copy to not hang in the diskchange loop, if
           you set this switch. It doesn't wait for the first disk then,
           but aborts, if there's no disk in the drive or if the media is
           not compatible to the CBM formats (except for formatting).

     /R:nnn
         - You can select a nonstandard step rate time for the following
           transfer actions. Because some (extended) controllers scale
           the real step rate time by the selected bit rate, the really
           used step rate time may not match the selected one. The range
           of selectable step rate times (1=0.25ms ... 255=63.75ms) is
           much bigger than the average disk parameter set (bitrate and
           more) allows. If a selected rate is less or bigger than the
           least or biggest allowed step rate time, then the least or
           biggest rate is selected. For most modern 1,44 MB drives a
           step rate time of 1.50ms (/R:6) should be the highest value,
           that works reliably with all the image types.

     /I:n
         - Specify an interleave factor for higher transfer speed on very
           slow FDCs. If your system is not able to read sectors
           continously from the disk, you should specify an interleave
           factor of 2. The transfer will need about 70 seconds then, but
           this may be faster than without specifying an interleave.
           Values from 0 to 9 are possible, 1 is the default.

     /T:nnn
         - Specifies the number of retries to do, if an error occurs. The
           default are 3 retries on every access.

     /H:s
         - If you own the very special FDC intel 82078-1 in a 64 pin
           package and get bored by the autodetection for a possibly
           mounted external 48 MHz oscillator (for some high speed tape
           controllers), then you can disable the autodetection by
           telling 1581-Copy what to do instead; f forces 1581-Copy to
           fix for 48 MHz operation in any case, n means, that there is
           no detection done and so no fix.
           It's up to you to find out, which option works for your
           controller (version information returns 0x9001...0x901F).


     Some parameter examples:
           1581COPY A: 1581IMG.D81 /T:999  - read an errornous 1581 disk
           1581COPY A: /F:2 /M             - format multiple FD2000 disks
           1581COPY TESTDISK.D81 B: /B     - BAM copy an image to A:
           1581COPY NEWDISK.D2M A: /F /V   - format, write and verify
           1581COPY /F A:                  - format a D81 in drive A:
           1581COPY A: NEWDISK /M /S       - read multiple disks from A:


   The return codes of 1581-Copy are as follows:

        0 -  operation completed successfully, or the multiple disks copy
             loop has been exited by user request

        1 -  command line parameter error or help called
        2 -  operation has been aborted by user request

       10 -  configuration error, wrong drive type (no 3,5" drive)
       11 -  disk write protect error (format protect error, too)
       12 -  unrecoverable disk transfer error on at least 1 track
             (read, write, format or verify errors)
       13 -  no or CBM incompatible disk found with switch /N

       20 -  image file open error
       21 -  image file read error
       22 -  image file write error
       23 -  no CBM compatible image file(s) found

       30 -  automatic filename (index) generation error
       31 -  automatic extension generation error

       40 -  buffer access is out of range

      1xx -  special debug return codes


4. Some details about the sector layout of MFM encoded Commodore disks
   and the internals of 1581-Copy

   Each sector of a MFM encoded disk contains a sector header like the
   GCR encoded disks, too. Each sector header contains a cylinder number
   and a disk side descriptor byte that normally corresponds to the
   mechanically selected track and head number. The third byte holds the
   sector number and the forth byte describes how many bytes are stored
   within this sector.
   But there is a little difference between IBM-PC formatted disks and
   CBM related formatted disks. On IBM-PC disk layouts, sectors of the
   logical side 0 are stored to the physical side 0 (accessed by head 0),
   sectors of the logical side 1 are stored to the physical side 1.
   On CBM related disk formats (e.g. CBM 1581, FD2000 native) the both
   sides are swapped. Sectors of the logical disk side 0 are stored onto
   the physical disk side 1 (head 1), sectors of the logical side 1 are
   stored onto the physical disk side 0 (head 0). This implies, that the
   sector header disk side descriptor bytes are "wrong", too. A physical
   disk side 0 contains only sector headers, where all the disk side
   descriptors contain the value 1.
   After serveral reports, I assume, that the CBM 1581 disk drive doesn't
   recognize these disk side descriptors, so that there may exist floppy
   disks where the disk side descriptors on both sides are marked with 0.
   I tried to implement 1581-Copy in a way, so that it is also able to
   ignore the disk side descriptors, but as you may know, this cannot be
   done perfectly, because the FDC always wants to know the correct disk
   side descriptor for the sector to read/write/verify. So 1581-Copy does
   the following: For each track to copy, 1581-Copy determines the side
   descriptor value of the first sector the FDC is able to read. Then it
   uses this value as the side descriptor for the whole track operation.
   Along with the side descriptor value, 1581-Copy gets the sector number
   to determine the sector number to start the track operation with.


    The CBM 1581 disk sector layout:

      Number of cylinders:          80, physically numbered from 0 to 79,
                                        logically numbered from 1 to 80
      Number of sides per cylinder:  2, physically stored on side 1 and 0
      (also described as tracks)        logically numbered 0 and 1
      Number of sectors per track:  10, physically and logically numbered
                                        from 1 to 10 (sector headers!!!)
      Number of bytes per sector:  512


    The CMD FD 2000 disk sector layout:

      Number of cylinders:          81, physically numbered from 0 to 80,
                                        logically numbered from 1 to 81
      Number of sides per cylinder:  2, physically stored on side 1 and 0
      (also described as tracks)        logically numbered 0 and 1
      Number of sectors per track:  10, physically and logically numbered
                                        from 1 to 10 (sector headers!!!)
      Number of bytes per sector: 1024

      Note: The logical numbering of the cylinders may not be correct.
            But at least _I_ will do number the cylinders from 1 to 81,
            because the analysis of an image I got showed me, that the
            logical sector chaining uses the same numbering mechanism.
            Because I don't know enough about CMD partitions, that may
            be wrong.


   Whenever the disk sector size contains more than 256 bytes, CBM drives
   divide such big physical sectors into several logical sectors, that
   all contain 256 bytes. Therefore the physical sector size must be a
   multiple of 256.

   Currently I don't know any utility, that can handle other disk images
   than CBM 1581 ones (D81). When I add disk image transfer support for
   other CBM related MFM disk formats, it may be of no use for you,
   because you can't handle the file contents of these images. It's up
   to you to find out how the file contents of these images can be
   handled, because I don't want and never will implement file based
   support into 1581-Copy.


5. Something about the image file formats used by 1581-Copy

   D81 image file format
   
     Because the D81 image file is already well documented in Peter
     Scheper's FORMATS.ZIP I want to provide only a simple offset
     relation table here.

     file offset       | CBM logical  |  drive physical   |   specials
     decimal sedecimal | track/sector | cyl head sec offs |
     ------------------+--------------+-------------------+--------------
           0 0x000000  |    01;00     |   00;01;01        | first block
         256 0x000100  |    01;01     |   00;01;01   +256 |
           .     .     |      .       |     .  .          |
        4864 0x001300  |    01;19     |   00;01;10   +256 |
        5120 0x001400  |    01;20     |   00;00;01        |
           .     .     |      .       |     .  .          |
        9984 0x002700  |    01;39     |   00;00;10   +256 |
       10240 0x002800  |    02;00     |   01;01;01        |
           .     .     |      .       |     .  .          |
       15360 0x003C00  |    02;20     |   01;00;01        |
           .     .     |      .       |     .  .          |
       20480 0x005000  |    03;00     |   02;01;01        |
           .     .     |      .       |     .  .          |
           .     .     |      .       |     .  .          |
       30729 0x007800  |    04;00     |   03;01;01        |
           .     .     |      .       |     .  .          |
           .     .     |      .       |     .  .          |
           .     .     |      .       |     .  .          |
      399360 0x061800  |    40;00     |   39;01;01        | disk header
      399616 0x061900  |    40;01     |   39;01;01   +256 | 1st BAM block
      399872 0x061A00  |    40;02     |   39;01;02        | 2nd BAM block
      400128 0x061B00  |    40;03     |   39;01;02   +256 | 1st dir block
           .     .     |      .       |     .  .          |
      409600 0x064000  |    41;00     |   40;01;01        |
           .     .     |      .       |     .  .          |
           .     .     |      .       |     .  .          |
           .     .     |      .       |     .  .          |
      808960 0x0C5800  |    80;00     |   79;01;01        |
           .     .     |      .       |     .  .          |
      813824 0x0C6B00  |    80;19     |   79;01;10   +256 |
      814080 0x0C6C00  |    80;20     |   79;00;01        |
           .     .     |      .       |     .  .          |
      818688 0x0C7E00  |    80;38     |   79;00;10        |
      818944 0x0C7F00  |    80;39     |   79;00;10   +256 | last block

     Please get http://www.fairlight.to/docs/text/formats.zip for further
     informations about the inner workings (you may find more interesting
     documents at http://www.fairlight.to/docs/index.html).

   D2M image file format

     The following table is only a very simple one. As you may know, the
     CMD FD2000 drive uses partitioned disk medias and a partition with
     its own logical track/sector scheme can start at any 512-byte block
     boundary. The file systems in these partitions calculate their track
     and sector destinations relatively to the starting offset of the
     partition they are stored in. The table below shows a FD2000 image
     file with one big native CMD partition on it. Take notice, that the
     physical track 80 (offset 1638400/0x190000) is reserved for the
     system partition, that holds all informations about all the created
     partitions of the disk, it cannot be used for data storage.

     file offset       | CBM logical  |  drive physical   |   specials
     decimal sedecimal | track/sector | cyl head sec offs |
     ------------------+--------------+-------------------+--------------
           0 0x000000  |    01;00     |   00;01;01        | 1st partition
         256 0x000100  |    01;01     |   00;01;01   +256 |  \_ block
         512 0x000200  |    01;02     |   00;01;01   +512 | 2nd partition
         768 0x000300  |    01;03     |   00;01;01   +768 |  \_ block
           .     .     |      .       |     .  .          |
        9984 0x002700  |    01;39     |   00;01;10   +768 |
       10240 0x002800  |    01;40     |   00;00;01        |
           .     .     |      .       |     .  .          |
       20224 0x004F00  |    01;79     |   00;00;10   +768 |
       20480 0x005000  |    02;00     |   01;01;01        |
           .     .     |      .       |     .  .          |
       30720 0x007800  |    02;40     |   01;00;01        |
           .     .     |      .       |     .  .          |
       40960 0x00A000  |    03;00     |   02;01;01        |
           .     .     |      .       |     .  .          |
           .     .     |      .       |     .  .          |
       61440 0x00F000  |    04;00     |   03;01;01        |
           .     .     |      .       |     .  .          |
           .     .     |      .       |     .  .          |
           .     .     |      .       |     .  .          |
     1638400 0x190000  |    81;00     |   80;01;01        | SysPartition
     1638656 0x190100  |    81;01     |   80;01;01   +256 |  unused block
     1638912 0x190200  |    81;02     |   80;01;01   +512 |  unused block
     1639168 0x190300  |    81;03     |   80;01;01   +768 |  unused block
     1639424 0x190400  |    81;04     |   80;01;02        |  unused block
     1639680 0x190500  |    81;05     |   80;01;02   +256 | devType block
     1639936 0x190600  |    81;06     |   80;01;02   +512 |  unused block
     1640192 0x190700  |    81;07     |   80;01;02   +768 |  unused block
     1640448 0x190800  |    81;08     |   80;01;03        | \\
     1640704 0x190900  |    81;09     |   80;01;03   +256 | SysPart-Table 
     1640960 0x190A00  |    81;10     |   80;01;03   +512 |  (1024 bytes)
     1641216 0x190B00  |    81;11     |   80;01;03   +768 | //
     1641472 0x190C00  |    81;12     |   80;01;04        |  unused block
           .     .     |      .       |     .  .          |   .  .
     1648384 0x192700  |    81;39     |   80;01;10   +768 |  unused block
     1648640 0x192800  |    81;40     |   80;00;01        |  unused block
           .     .     |      .       |     .  .          |
     1658368 0x194E00  |    81;78     |   80;00;10   +512 |  unused block
     1658624 0x194F00  |    81;79     |   80;00;10   +768 | last block

	D2M system partition

     The system partition, which is stored at the physical track 80 holds
     informations about the current media (devType block) and the
     partition table. 1581-Copy doesn't use the device type block and I
     currently don't know, what it is really used for; perhaps there can
     be emulated several virtual devices with one media but that seems to
     be more useful for CMD's hard drives.
     The system partition table stores the informations about up to 31
     partitions that can be stored to different locations into the disk.
     Each entry holds informations about the partition type (native CMD
     partition, 1541/1571/1581 emulation partition), the name of the
     partition, its starting offset and length (counted in 512-byte
     blocks). In the case of emulated partitions, the size of the
     partition is already known, because an emulated partition must hold
     a complete image. Only native mode partitions can have variable
     partition sizes.
     If you want to access blocks (track/sector descriptors) of a desired
     partition you always need the information of the system partition,
     so that you know the type of the virtual disk you are handling and
     its start offset. Because all "inner" track/sector pointers of the
     partitions describe locations relatively to the partition start
     address, you have to do some calculations to determine the correct
     read address (absolute file offset or physical disk
     cylinder/side/sector number) and you have to take into account the
     layout of the partition (variable number of sectors for 1541 and
     1571 emulations).

   1541, 1571 and 1581 emulation partitions
     These are simple sector dumps just like the D41, D71 and D81 image
     files, please refer to the FORMATS.ZIP document for further
     information.

	D2M native mode partitions
	  Native mode partitions use an independent logical layout of 256
	  sectors (0...255) at up to 255 tracks (1...255), each sector
	  contains 256 bytes (logical CBM standard). Track 1, sector 1
	  contains some header informations like the pointer to the first
	  directory block, the disk name and id and some CMD default IDs.

	D2M BAM
	  The first block of the BAM of a native mode partition is stored at
	  sector 2 of track 1 (relative to the beginning of the partition and
	  counting in CBM logical 256-byte blocks). It contains the disk ID
	  again and the CMD default IDs as well as a descriptor for the last
	  track number (1...255 containing 256 sectors each) that is used
	  within this partition. This descriptor is needed for parsing the
	  allocation entries following. Because each native mode partition
	  contains allocation entries for _all_ possible 255 tracks you need
	  to know where to stop parsing the allocation map to avoid using
	  illegal informations. T/S 01;02 also stores the allocation entries
	  for the first 7 tracks (track 1 to 7). The allocation info for all
	  the other tracks is stored in the following blocks 01;03 (BAM for
	  tracks 8...15) up to 01;33 (BAM for tracks 248...255).

   Error information blocks:

     D81 and D2M disk images with error info attached are recognized by
     1581-Copy now. It doesn't use any informations from the error block,
     neither does it create image files with error info attached itself.
     That is because I don't know, which _real_ error codes (job codes)
     the 1581 or FD2000 drive could create for which scenario (protection
     schemes). The calculation of the size of the D81's error block
     should be known because of Peter Schepers FORMATS file (get 64Copy
     3.3 or refer to http://www.fairlight.to/docs/text/formats.zip)
     although I don't understand, why there's one error byte attached to
     each logical 256-byte CBM sector; the drive does physically store
     512-byte sectors (or 1024-byte sectors for FD2000 drives) and I
     can't think of any case, where one half of a physical sector could
     have an error, but not the other one. Never mind, I decided to do
     the same for the D2M image files, because CMD FD2000 drives are able
     to emulate 1541(-II), 1571 and 1581 drives by storing so called
     partitions to the disks. Because a D2M image consists of 81 tracks
     (including the system track), 2 sides, 10 sectors and 1024 bytes per
     sector the number of logical 256-byte sectors is 6480 and therefore
     6480 bytes have to be added to an image, if error codes should be
     attached to a D2M image.

   D81 and D2M file sizes:

      D81 native image          :   819.200 aka 0x0C8000 Bytes
      D81 with error info block :   822.400 aka 0x0C8C80 Bytes
      D2M native image          : 1.658.880 aka 0x195000 Bytes
      D2M with error info block : 1.665.360 aka 0x196950 Bytes


6. Linux and Commodore MFM encoded disks

   As you may have noticed, there's a Linux floppy disk parameter table
   included in this distribution. This is done, because I learned much
   from the Linux floppy driver about supporting MFM encoded Commodore
   disks. But I recognized, that the parameters for the CBM1581 format
   normally stored in /etc/fdprm were not optimally. The GAP size of this
   parameter was too big, as I figured out with 1581-Copy. So I created a
   possibly better working entry, that should be much more compatible to
   Commodore's format. Later, after I started implementing support for
   CMD FD2000 disks, I created an entry for Linux, too.
   If you are a Commodore and Linux power user, you should get Alain
   Knaff's fdutils, it can be downloaded from Alain's pages:

        http://alain.knaff.linux.lu/
        http://alain.knaff.linux.lu/fdutils/index.html
        http://alain.knaff.linux.lu/fdutils/fdutils-5.4.tar.gz
        http://fdutils.linux.lu/index.html
	  or simply ftpsearch for: fdutils-5.4.tar.gz

   The package is the most massive attack against floppy disk drives,
   that I've seen ever. You should be able to read/write nearly any FM
   and MFM encoded disks. The distribution contains a README file, that
   describes, how to integrate autodetection support for the CBM 1581
   format into Linux, here's a shorted description:

        mknod /dev/fd0cbm1581 b 2 124
        setfdprm /dev/fd0cmb1581 1600 10 2 80 2 0x0C 0x02 0xDF 0x23
        floppycontrol --autodetect /dev/fd0 31,7,8,4,25,28,22,21

   The second and third entry have to be issued after each reboot, so you
   have to integrate the command into your startup scripts (e.g. init.d).
   Take notice, that I haven't tested this configuration with the changed
   parameters (gap sizes) for setfdprm, I don't know, if the
   floppycontrol parameters have also to be changed. And there's no such
   configuration available for CMD FD2000 disks; if I find some fun in
   experimenting with this I'll tell you about.


7. The Credits

   This list is created in more or less cronological order to describe
   the history of 1581-Copy (you should also check SRC\HISTORY.TXT).

	Greets go to... (am I writing an intro or demo??? :)

     Womo aka Wolfgang Moser <womo_(at)_d81_(dot)_de>
       If he wouldn't have born 1969-07-27-22:03, I would neither know
       what or who I am, nor why I like such sophisticated things like
       programming calculators.
       
     Nicolas Welte <welte_(at)_chemie_(dot)_uni-konstanz_(dot)_de>
       A man like me, very hardware interested. After I joined The Star
       Commander beta testing crew, we had hundreds of email discussions
       about all these hardware based design questions. Our greatest work
       was the design of the XE1541 cable, I think. Don't think, that
       only 4 diodes can impossibly cause any trouble.

     Joe Forster/STA aka Balzs Kovcs <sta_(at)_c64_(dot)_org>
       If I wouldn't have had so many discussions with Joe about so many
       different C64 related things, this project would have never been
       started. It was the The Star Commander, that has let me start
       thinking about such a smart technology, like direct CBM 1581 disk
       access.

     Marko Mkel <Marko.Makela_(at)_hut_(dot)_fi>
       I think he is one of the real gurus of the european CBM scene,
       thanks for simply beeing there.

     Jens-Michael Gross <grossibaer_(at)_grossibaer_(dot)_de>
       He wrote READ81, the first IBM-PC/DOS transfer utility, that was
       and is able to read CBM 1581 formatted disks. He showed me, that
       it must be possible to do the same myself. The difference is, that
       his util is shareware and he doesn't distribute the sources of it.
       So there was no possibility to integrate his routines into The
       Star Commander. His util is able to do direct file accesses on CBM
       1581 disks. To protect his work and to prevent me from
       implementing too much uninteresting stuff, I decided, that
       1581-Copy should be a disk image transfer utility only without any
       file handling support.

     Zenith Data System
       Their Technical Reference Manual teached me in accessing and
       programming different hardware components of the IBM-PCs (like
       the LPT ports, the IRQ and the DMA controller).

     Dan Fandrich <dan_(at)_coneharvesters_(dot)_com>
       He wrote a CBM 1581 disk driver and filesystem access utility for
       Linux and some wonderful documentation, that could explain me,
       why it is so difficult (is it really?) to access CBM 1581 disks
       with IBM-PC based operating systems (the disk side swap).

     Christoph H. Hochsttter <Christoph_(at)_Hochstaetter_(dot)_org>
       His DOS utility FDFORMAT was my first step into learning how to
       do direct floppy disk controller programming.

     Ciriaco Garca de Celis <ciri_(at)_gui_(dot)_uva_(dot)_es>
       The "son" of Christof Hochsttter, he wrote the tools 2M, 2MGUI
       and 765DEBUG. Without the sources of 765DEBUG, I wouldn't have
       been able to implement the low level FDC routines. If you compare
       the sources, you will see, that I derived the whole low level FDC
       accessing routines from the sources of 765DEBUG. Well, in the
       meantime I did so many restructures, that you won't see anything
       anymore :-)

     Ralf Brown <ralf+_(at)_cs_(dot)_cmu_(dot)_edu>,
        <ralf_(at)_pobox_(dot)_com>
       His interrupt list at http://www.cs.cmu.edu/~ralf/files.html is
       the greatest resource for IBM-PC based low level programming
       people, that helped me very much in improving different routines
       and especially in learning how to program the DMA controller.

     Sorex/WOW aka Geert Verschueren <Sorex_(at)_skynet_(dot)_be>
       One of my first testers. He owns a very sophisticated test
       platform, a 386DX running Windows 95.

     Pontus Berg <Bacchus_(at)_FairLight_(dot)_Org>
       The maintainer of the best sorted and commented CBM related tools
       page. Thanks for publishing 1581-Copy on your page and the
       invitation for letting 1581-Copy become a FairLight tools release.

     Andreas Boose <boose_(at)_linux_(dot)_rz_(dot)_fh-hannover_(dot)_de>
       He supported me with informations from the IBM PC/AT technical
       reference manual and just informed me, that he plans to integrate
       direct CBM disk access support into a future version of VICE for
       DOS, this is really a great idea, isn't it.

     Near Letter Quantity aka Jochen Adler <NLQ_(at)_gmx_(dot)_de>
       This is the author of several floppy speeder improvements, like
       SupraDOS, SuperJiffyDOS and SuperJiffyDOS for the 1541. He
       provided me with several informations about the CBM 1581 and
       espcially some analyses about the exact track format. Without him,
       I wouldn't have been able to solve the problem with the different
       (wrong) GAP sizes of the earlier versions.

     Dr. med. Johannes Schulze-Oechtering
        <st0159_(at)_aixrs1_(dot)_hrz_(dot)_uni-essen_(dot)_de>
     Mark Seelye <mseelye_(at)_yahoo_(dot)_com>,
        <BurningHorizon_(at)_BurningHorizon_(dot)_com>
       These both people were pushing me for integrating CMD FD2000
       support into 1581-Copy. The rough FD2000 support of 1581-Copy is
       mainly their merit. Mark did some special tests, so that I was
       able to identify the low level disk layout for the first time.
       Johannes did send me some native CBM 1581 formatted disks as a
       thanks, so that I could test the new adjusted GAP sizes.

     Credo/SCS*TRC aka Ray Nemes <credo_(at)_bigfoot_(dot)_com>,
        <credo_(at)_scs-trc_(dot)_net>
     MagerValp aka Per Olofsson <MagerValp_(at)_cling_(dot)_gu_(dot)_se>
     Frank Reichel <Frank.Reichel_(at)_forchheim_(dot)_baynet_(dot)_de>
       These people are also in the 1581-Copy test crew and helped me
       debugging 1581-Copy by writing test reports from time to time.

     Ingo Korb <unseen_(at)_gmx_(dot)_net>,
        <unseen_(at)_uni-duisburg_(dot)_de>
       He reported some problems in combination with the C64 copy suite
       Maverick. It seems, that Maverick creates 1581 disks, where the
       SideIDs on both sides of a 1581 disk are set to 0. This brought me
       to a good idea how to make 1581-Copy independent from the SideIDs.

     Alain Knaff <Alain_(at)_linux_(dot)_lu>
       A little bit late, I discovered Alain Knaff's fdutils for Linux,
       the most massive attack against floppy disks I have seen ever.
       He's also the man behind the Linux floppy driver. Nice to see,
       that a tool like 1581-Copy is not needed under Linux, except for
       the new introduced feature of ignoring SideIDs, like the CBM 1581
       floppy does.

     Nicholas Coplin <ncoplin_(at)_orbeng_(dot)_com_(dot)_au>
       Because he wants to call 1581-Copy from his own image handling
       tool(s) (64HDD, http://www.64hdd.com), I fulfilled his wish for
       some better exit codes.

     White Flame aka David Holz <white-flame_(at)_geocities_(dot)_com>
       One of the many people asking me for more and better FD2000
       support (BAM-Copy and listing directories)

     Wolfram Sang <ninja_(at)_the-dreams_(dot)_de>,
     GO64 magazine <go64_(at)_c64_(dot)_org>
       He wrote a test report about 1581-Copy in the magazine GO64, issue
       09/2000 and reported system crash problems with PTS-DOS and
       1581-Copy. That was the initial reason, why I was finally able to
       find the biggest bug of 1581-Copy until now. It is Wolfram's
       merit, that I decided to give all the readers of GO64 and all the
       other users of 1581-Copy a little present for this. I finally
       integrated the BAM copy support for FD2000 disks into 1581-Copy
       (my "payment" for this valuable bug report).

     Hans-Peter Messmer
       His book "PC-Hardwarebuch: Aufbau, Funktionsweise, Programmierung;
       ein Handbuch nicht nur fr Profis" pointed out the DMA transfer
       page overflow, when the transfer buffer crosses a page boundary.
       Messmer, Hans-Peter
       PC-Hardwarebuch: Aufbau, Funktionsweise, Programmierung; ein
       Handbuch nicht nur fr Profis / Hans-Peter Messmer. -
       Bonn; Paris; Reading, Mass. [u.a.]: Addison-Wesley, 1995
       ISBN 3-89319-528-9
       (C) 1995 Addison-Wesley (Deutschland) GmbH
       3. erweiterte Auflage 1995
       


8. Additional and distribution info

   Please read the history (SRC\HISTORY.TXT) for further version
   informations and much of the implementation background. And you should
   check the sources of course, perhaps you want to derive your own
   project from the sources of 1581-Copy.


   If you are an owner or maintainer of a CBM related site please do
   place the util onto your site, if you find it useful.


   This or newer versions of 1581-Copy may be found on the following
   sites:

   - The "FairLight tools" page of Bacchus/FLT
       http://www.fairlight.to/tools/pc.html

   - The author's developer and mirror sites
       http://d81.de
       http://wmsr.de
       http://www.gm.fh-koeln.de/~womo/sourcen/sources.html
   
   - The Star Commander site of Joe Forster/STA, section: MS-DOS tools
       http://sta.c64.org/scextprg.html
       http://sta.c64.org/dosprg.html


   - Marko Mkel's FTP site
       http://www.funet.fi/pub/cbm/transfer/misc
       ftp://ftp.funet.fi/pub/cbm/transfer/misc/


9. Contact

   Please send me bug reports, so that I can fix as most bugs as
   possible. Perhaps I should define this software as Anti-Shareware,
   where I pay _you_ for every _new_ bug you find and report to me :-)

   Redirected contact addresses:
      Wolfgang Moser <womo_(at)_fairlight_(dot)_to>
      Wolfgang Moser <womo_(at)_d81_(dot)_de>
       http://d81.de
      Wolfgang Moser <womo_(at)_wmsr_(dot)_de>
       http://wmsr.de
  
   Current workplace (up to July 2003):
      Wolfgang Moser <womo_(at)_gm_(dot)_fh-koeln_(dot)_de>
       http://www.gm.fh-koeln.de/~womo
