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 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 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 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 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 I think he is one of the real gurus of the european CBM scene, thanks for simply beeing there. Jens-Michael Gross 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 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 His DOS utility FDFORMAT was my first step into learning how to do direct floppy disk controller programming. Ciriaco Garca de Celis 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 , 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 One of my first testers. He owns a very sophisticated test platform, a 386DX running Windows 95. Pontus Berg 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 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 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 Mark Seelye , 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 , MagerValp aka Per Olofsson Frank Reichel 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 , 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 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 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 One of the many people asking me for more and better FD2000 support (BAM-Copy and listing directories) Wolfram Sang , GO64 magazine 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 Wolfgang Moser http://d81.de Wolfgang Moser http://wmsr.de Current workplace (up to July 2003): Wolfgang Moser http://www.gm.fh-koeln.de/~womo