Frozen Fish 1: Amiga

home *** CD-ROM | disk | FTP | other *** search

/ Frozen Fish 1: Amiga / FrozenFish-Apr94.iso / bbs / alib / d5xx / d558 / btntape.lha / BTNtape / tape.doc < prev next >

Wrap

Text File | 1991-10-28 | 36KB | 761 lines

**** BTNtape: an AmigaDOS handler for SCSI tape drives **** Version 2.1 10/22/91 **** Freeware by Bob Rethemeyer (DrBob@cup.portal.com) **** **** (c) Copyright 1990, 1991 Robert Rethemeyer. **** This software may be freely distributed and redistributed, **** for non-commercial purposes, provided this notice is included. **** All original files must be included in the distribution. BTNtape is a "Better Than Nothing" SCSI tape device handler. It provides flat-file access to a SCSI tape drive from application programs using simple DOS calls to Read() and Write(). It can also be used with the Amiga TAR utility for disk backups. It requires a "SCSI-direct" compatible SCSI bus adapter. This is version 2.1, update to version 2.0. It fixes a number of bugs, and includes a few new features, including the ability to append files to a tape. Some advantages of BTN over other handlers and dedicated tape backup programs: * Includes a monitor program that keeps you informed of what's happening * Supports many standard SCSI tape drives and Amiga SCSI bus adapters * Supports the 3M MCD-40, a non-standard SCSI tape drive * Supports any size of tape block, and multiple-block operations * Supports tape files that span multiple tape volumes (sometimes) * Double buffering improves streaming performance * Includes an interface to send SCSI control commands to the drive * Includes an interface to set drive-specific Mode Select parameters * TAR tapes can be exchanged with Un*x systems * DOS compatibility for use with any program. e.g. data logging applications =================== ******> R E A D T H I S <****** ====================== DISCLAIMER: "This software is provided 'as-is', without warranty of any kind, either expressed or implied. In no event will I, Robert Rethemeyer, be liable for direct, indirect, incidental or consequential damages or data loss resulting from the use or application of this software. The entire risk as to the results and performance of this software is assumed by you." I cannot guarantee that this software is compatible with any combinations of drives or adapters other than those I have specifically tested. If you do not agree with this disclaimer, I recommend you not use this software; buy commercial tape software instead. ============================================================================ Because commercial tape backup software is now available, the only reasons you might still want to use BTNtape would be: * Compatibility with TAR for transporting tapes between Amiga and Un*x * Compatibility with AmigaDOS for data logging or special applications * You don't want to spend any money. I claim only that this handler works with the Amiga TAR program ported by Jonathan Hue. It might work with some recent backup programs that allow backup to a DOS file, but won't work with any that backup to Exec devices. If you don't want to use commercial tape software, you might find this handler to be "better than nothing". I will try to provide support for this handler, especially for bug fixes, as my time and resources allow. But I cannot commit to adding all the enhancements or special features requested by users. If you have something in mind, ask, but I can't guarantee anything. If you modify BTN, please do not publicly distribute the modified version without contacting the author. Although the documentation refers to alleged problems with some manufacturers' software/hardware, that should not be construed as a statement about the quality of their products. In fact, there is still a possibility that the problems may be in my handler software or the equipment I used. ============================================================================== DISTRIBUTION: The distribution should contain the following files: btn-handler handler binary tapemon monitor binary tape.doc you're reading it tapemon.doc documentation for the monitor program changes.doc a brief history of BTNtape mess.doc explanations of handler messages usernotes.doc information about certain hardware mountlist example mountlist entry tape.rexx an ARexx script to issue tape control commands src directory tape.c source for main handler tapeio.c source for interface to SCSI-direct pktstuff.c source for packet handling, by Phillip Lindsay tape.h local include file tplink.h local include file for handler/monitor structure lmkfile SAS/Lattice make file for handler makefile Manx make file for handler tapemon.c monitor source tapemon.lmk SAS/Lattice make file for tapemon COMPATIBILITY: You must have a SCSI adapter and software that honors the SCSI-direct protocol as defined in the "devices/scsidisk.h" include file. The list below shows the manufacturers I know about that support SCSI-direct (but this list I'm sure is incomplete). This handler has been tested on the following equipment (but not in all the combinations): SCSI adapters: * Commodore A2091 * Commodore A590 * Commodore A3000 (built-in), including AmigaDOS 2.0 * GVP Series II * HardFrame * Nexus * Commodore 2090A- see usernotes.doc file. * Supra (all types) see usernotes.doc file. * Original Trumpcard- with 2.0F software, 4.0 ROMs, Interrupt 2 jumper. * Trumpcard Pro * Xetec Tape drives: * Commodore A3070 (Caliper CP150) * Archive 2150S (Viper) * Wangtek 5150ES * Teac MT-2ST Cassette * Emulex MT-02 SCSI/QIC-36 tape adapter * Exabyte EXB-8200/8500 8mm Cartridge Tape Subsystem * DEC TK50 * 3M MCD-40 direct access 40MB cartridge tape drive * Jasmine DT40 direct access drive (Braemar, 3M derivative?) * TallGrass direct access drive (model unknown, 3M derivative?) Even if your hardware is not listed here, there is a good chance it will still work if it adheres to the standards (SCSI-direct and SCSI). The handler treats a drive as one of two types: sequential or direct access. The most common type is sequential. The handler will adjust itself for either type. If you get it to work with some drive model I haven't mentioned here, I would like to hear about it. THE MONITOR PROGRAM Included in with the handler is the TAPEMON program. TAPEMON is a program that runs under a separate CLI and prints one-liner messages from the handler. The messages include the current tape operation and block number, and error and sense codes. The handler will run with or without TAPEMON; i.e. TAPEMON is optional. TAPEMON must be started up AFTER the handler is mounted and activated. Read TAPEMON.DOC for more information. INSTALLATION: 1. Copy the BTN-HANDLER file to L:BTN-HANDLER. Copy the TAPEMON program to C: or a directory appropriate for you. 2. Create an entry in DEVS:MOUNTLIST something like this: TAPE: Handler = L:btn-handler Priority = 5 /* use 11 for Supra 1.10 */ Stacksize = 4000 Mount = 1 /* optional */ GlobVec = -1 Startup = "yourscsi.device/AA-x/BB-x/..." /* EXPLAINED BELOW */ # There is nothing magic about the name TAPE: You may use some other valid device name if you like. 3. Install the handler in DOS using the CLI command "MOUNT TAPE:" *WARNING* Do not use the ARP version of MOUNT !! ARP's MOUNT inexplicably truncates the Startup string to 40 bytes. You MUST use the Commodore version of MOUNT. To tell the difference, ARP 1.3 MOUNT is 2372 bytes long, and CBM MOUNT (1.3.2) is 5604 bytes. No need to completely abandon ARP- you can still use the CBM MOUNT. Just give the two MOUNT commands different names in your C: directory. If you get a write-protected or replace-volume requester, click cancel. If there is a problem during mounting, BTN will put up a requester with one of the following brief explanatory messages: "Insufficient memory" - severe memory shortage "Can't open SCSI-direct" - OpenDevice("yourscsi.device") failed "Can't select tape drive" - drive, SCSI bus, or adapter problem "UNit is not a tape drive" - UN is wrong; probably your disk drive Once you click the requester, BTN will terminate. You can then remedy the problem, use the ASSIGN command with REMOVE or DISMOUNT to get rid of the dead device, and try again. THE STARTUP PARAMETER The mountlist Startup parameter is used by the handler to determine how to access your drive. FAILURE TO ENTER PROPER INFORMATION IN STARTUP MAY RESULT IN PROBLEMS INCLUDING HANGS, VISITS FROM THE GURU, OR DATA LOSS. This is the messiest part of setting up. Pay attention. The Startup string must be in the form: Startup = "devicename/keyword-number/keyword-number/..." It must not have any embedded blanks and must be enclosed in quotes. The pieces must be separated by slashes. The first parameter must be the name of the device driver which provides the SCSI-direct command interface. Do not include any path information. This name is defined by the manufacturer of your SCSI adapter. If you don't know what it is, use a utility like XOPER, TASKX, or ARTM to look at the list of running tasks, and make a guess. You must use the exact same upper and lower case letters (this is a DOS restriction). The names for the adapters I know about are: A3000,A2091,A590 -> scsi.device A2090A -> hddisk.device Supra -> supradirect.device (driver Series II v1.10 only) or -> suprascsi.device (Series III v3.0 and above) GVP -> gvpscsi.device HardFrame -> HardFrame.device Nexus -> Nexus.device (NOT NexusTape.device!) Trumpcard -> IVS_SCSI.device Trumpcard Pro -> IVS_SCSIpro.device ICD Advantage -> icddisk.device Xetec -> harddisk.device The name parameter MUST be the first item in the string. All other parameters may be in any order, but the name must be first. The remaining items consist of pairs of two-letter keywords and a number separated by a dash (minus sign). The keywords are explained below. You may omit any of them (except UNit), and a default value will be assumed. The numbers may be decimal, or hex in the "0xNN" format. UNIT Keyword: UN Default: none ------------------------------------- The unit number of your tape drive, as it will be addressed by your hard disk driver. Usually you can just specify the SCSI bus ID, example: "UN-0" for 0. More complex setups may require the form "UN-0xBLI", where B=board#, L=logical unit#, I=SCSI bus ID. Be sure you have set the drive ID switches or jumpers to a value that is unique on the SCSI bus. (2090A owners- add 3 to the ID number.) (LOGICAL UNIT Keyword: LU DELETED!!) ------------------------------------------- The old LU parameter has been DELETED from BTN 2.1. You now specify the logical unit in the middle hex digit of the UN parameter. Most drives are hardwired for 0, so it won't matter to most users. BLOCK SIZE Keyword: BS Default: BS-512 --------------------------------------------- The number of bytes in a SCSI logical block for your tape drive. Consult your drive documentation. If you don't know this info, try 512, the most common value. (See the 3m.doc file for the values to use with 3M drives.) Some drives (but not many) allow you to specify different block sizes, within a legal range; the handler will command the drive to use the size you specify. Others can use only one fixed size. If you can vary the block size, you must use the same size when reading a tape as you did when writing it. NUMBER OF BLOCKS Keyword: NB Default: NB-1 ---------------------------------------------- The number of SCSI logical blocks to write or read in each tape operation. This is a performance adjustment only. Use what works best for you. See more below. BUFMEMTYPE Keyword: BT Default: BT-0 ----------------------------------------- The type of memory to allocate for the tape buffers, same as BufMemType for mountlists. Use 0 or 1 for "any", 2 or 3 for "chip", 4 or 5 for "fast". FILEMARKS Keyword: FM Default: FM-1 ----------------------------------------- Specifies number of file marks to write when closing at the end of a write, or the number to skip for each file when opening for read. FM-1 recommended. FM-0 means no file marks are written, and read references to TAPE:num become the equivalent to TAPE:R. Allowed range is 0-255. Sequential drives only. RETENSION Keyword: RT Default: RT-0 ----------------------------------------- If RT-1 is specified, the handler will retension the tape (run to the end of the tape and back) on the first access after a new tape is inserted (indicated by Unit Attention status). Specify RT-0 (or omit it) if your drive already does this automatically, or does not support the necessary SCSI command, or if you don't want it. *Note* Some SCSI adapters, such as GVP and IVS, will periodically poll the drive for readiness, which has the effect of losing the the Unit Attention status. A clue: the light on the drive may blink every few seconds. For such adapters, the RT function will not work. Ask the adapter manufacturer for a software update to fix this problem, or manually issue the retension command (see tape.rexx). VARIABLE BLOCK FLAG Keyword: VB Default: VB-0 --------------------------------------------------- The handler normally operates sequential drives in fixed block mode. Specifying VB-1 will force operation in variable block mode instead. Use this if your drive does not support fixed block mode or you for some reason need variable block mode. (warning: this function is untested, and may change in a future version) RESERVED BLOCKS Keyword: RB Default: RB-0 ---------------------------------------------- For direct access drives only. Specifies how many blocks to skip at the beginning of the tape. OVERLAPPED I/O FLAG Keyword: OV Default: OV-1 --------------------------------------------------- The handler normally (OV-1) attempts to overlap tape drive I/O and DOS I/O to maximize throughput. Specifying OV-0 disables overlapping and double buffering, for systems that can't walk and chew gum at the same time. DEVICE FLAGS Keyword: DF Default: DF-0 ------------------------------------------- Equivalent to the Flags parameter in mountlists. It is passed in the OpenDevice() call to open the SCSI- direct driver. If you don't already know what you would use this parameter for, then you probably don't need it. NO-REWIND FLAG Keyword: NR Default: NR-0 --------------------------------------------- Controls rewinding behavior when referencing TAPE: . Set this parameter according to your personal preference. If NR-0, TAPE: is equivalent to TAPE:R (same as v2.0). If NR-1, TAPE: is equivalent to TAPE:NR. See below. SUPRA FLAG Keyword: SU Default: SU-0 ----------------------------------------- Activates the circumvention for Supra Series II v1.10 driver problem. Specify SU-1 to activate this. See "usernotes". Do NOT use this with the Series III driver. CBM 2090A FLAG Keyword: C9 Default: C9-0 --------------------------------------------- Activates the circumvention for the Commodore 2090A problem. Specify C9-1 to activate this. See "usernotes". Here are some examples of valid Startup strings: Startup = "scsi.device/UN-7" /* the minimum info required */ Startup = "gvpscsi.device/BS-0x400/NB-16/UN-0x102/RT-1" Startup = "supradirect.device/un-4/bs-8192/nb-8/bt-1/su-1" A note about the NB parameter: Most drives will be mechanically more efficient writing multiple blocks. You may want to tweak this parameter to find out. The handler will wait until NB blocks have been accumulated before starting a write. Buffered drives may also have a limit on the number of blocks they can hold at once, so the size of NB relative to that number may have an effect. Consult your drive docs. This parameter also determines how much memory is needed for buffers. The handler uses double buffering, so it will need 2 * BS * NB bytes when you Open() it. For example, if BS=8192 and NB=8, then 8192*8 = 64K, for a total of 128K. TAPE FILE NAMES BTN is compatible with AmigaDOS because you can use the name "TAPE:" in most instances where a file or path name is required. You CANNOT refer to files on the tape as "TAPE:filename", because BTN does not support a file system. But BTN does use some characters to the right of the colon to determine access modes. Refer to the tape with one of the following file name forms: TAPE:R Rewinds and opens the tape at the first available block. TAPE:NR Opens the tape at the current position, without rewinding. TAPE:* Same as TAPE:NR (but doesn't work with some shells or commands) TAPE: Same as TAPE:R or TAPE:NR, depending on NR startup parameter. TAPE:APP Opens the tape after the end of the last-written file, to allow you to append a file to a tape with existing files. This mode is allowed only for writes on sequential drives. Some drives do not support this function; in that case, BTN will resort to a slower method which searches for a blank spot. TAPE:num Opens the tape at the position specified by the number. For sequential drives, the number indicates the file position, and may be used only for reading data from the tape (no writes). The 0th file is at the beginning of the tape, file 1 follows it, etc. You can only read files that have been previously written. Files are separated by one or more filemarks (automatically written at the end of a write). For direct access drives, the number specifies an absolute SCSI block number on the tape. You should remember (write down) the first and last block number of each file on the tape, as reported by TAPEMON. TAPE:RAWCMD A special mode for issuing a raw SCSI command, not for accessing the tape medium. See "RAW COMMAND INTERFACE" below. TAPE:MODESEL A special mode for writing mode-select data, not for accessing the tape medium. See "USER-SPECIFIED MODE SELECT" below. HOW TO ACCESS TAPE DATA Now that the handler is installed, how do you talk to it? You can use TAR, or your own application program, including ARexx. You can write data to the tape and later read it back in a manner similar to other files, using DOS calls to Open, Read, Write, Seek, and Close. You may even copy single files to and from the tape using a CLI COPY command: "COPY filename TAPE:" and "COPY TAPE: filename" The handler makes the tape data look like a sequential AmigaDOS file. THERE IS NO FILE SYSTEM on the tape, but you may place multiple files on a tape by appending new files after the last-written file. The handler does not support mixed reads and writes. That is, you may do only Reads or only Writes, but not both. BTN 2.1 now supports Seek(), with the following restrictions: * Must be in fixed block mode (VB-0) * Must be opened for Read()s, * Seeks relative to end-of-file are not allowed * Seeks relative to current-position or beginning-of-file are allowed provided that the net position change is: - forward from the current position - backward to the exact beginning of the file only, except if opened as TAPE:NR Tape data is written in quantities of "NB*BS" bytes. No information about the exact length of the file is written. If a tape file ends before filling a block, the remainder of the block is filled with zeroes. Therefore, any program reading the tape must know when to stop reading data, otherwise it will read extraneous zeroes past the true end of the file. This is especially true of the CLI "COPY" command. TAR works because it essentially writes and interprets the tape data as its own little file system that includes the length of each file. When a tape file is closed in write mode, one or more filemarks (as determined by "FM") are written at the end of the file to delineate the file from subsequent files. (Sequential drives only). If there is no tape in the drive at the time TAPE: is opened, DOS will put up a requester asking for volume "TAPE" "in any drive". Insert the tape (in the tape drive, not a floppy drive :-) and click on retry after tape motion stops. A QUICK FUNCTIONALITY TEST Before jumping into disk backups and restores, try the following simple test to see if your setup is basically working. Write a large ASCII text file, such as TAPE.DOC, to the tape and see if you can read it back intact. This can be done with the CLI TYPE command: TYPE tape.doc TO TAPE: ; writes the file to tape then... TYPE TAPE: ; reads the file back The second TYPE should legibly print the ASCII file on your screen. (If using a direct access drive, there is no filemark to signify the end of the file, so use control-C to abort the second TYPE). USING TAR FOR BACKUPS AND RESTORES For backups, I recommend the version of TAR ported by Jonathan Hue. It is available on Fish Disk 445 or various online sources. It is 33860 bytes long. Each TAR archive is written to the tape as a single file, terminated by a file mark (on sequential drives). NOTE: the version of TAR distributed with Amiga UUCP apparently does NOT work with BTNtape. I don't know why. Other similar programs, like PAX, may also work, but I haven't tried them. TAR will backup all directories, files, and subdirectories in the directory you specify, including the date, protection, and filenote attributes. The easiest way to do a backup is to CD to the desired directory or partition (e.g. "cd DH0:"), then... To make a backup archive with TAR : tar -cvf tape: "" (note the null string) To add another at current position : tar -cvf tape:* "" To add another after last archive : tar -cvf tape:app "" To restore files from archive : tar -xvf tape: * To restore a specific file : tar -xvf tape: path/filename To restore from archive at file 6 : tar -xvf tape:6 * To list the archive on the tape : tar -tvf tape: (this also tests archive integrity) To make an archive log : tar >logfile -tvf tape: To look at raw tape data : type tape: opt h ... cntl-C TAR can also make backups using a list of files from another file. When you restore an individual file from an archive, provide the exact path and file name; these names are case sensitive. Refer to the TAR documentation for more information. END-OF-TAPE HANDLING If the application reaches the end of the tape, the handler will put up a requester asking you to insert the next tape and click "Continue", or click "Abort". The continue option allows the application program to access a file across multiple tape volumes without interruption. WAIT FOR TAPE MOTION TO STOP on the new tape before clicking Continue. If you click Abort, end-of-file is returned to the application, and any unused data in the buffers is discarded. *IMPORTANT NOTES* * EOT handling may not work correctly on all drives. Test it before trusting your data to it. Read the archive back using the -t option of TAR. If TAR hiccups on a file after the tape swap, it doesn't work. You can backup partitions or directories smaller than the tape capacity to avoid this situation. * EOT handling is invoked when any of the blocks in the group of "NB" blocks gets an EOM or Volume Overflow error. When you click Continue, the entire group of blocks is rewritten/reread on the new tape. Therefore, to use the multiple-volume capability of the handler, you must use the same blocking factor (value of NB) when reading the tape as when it was written. * EOT handling for the 3M drives will work only if the ROM version supports the READ_CAPACITY SCSI command. If you see no "Capacity" message from TAPEMON, then EOT handling is unavailable. * There was a bug in BTN v2.0 which miscalculated the last block for handling EOT on 3M drives. The bug has been fixed in v2.1, but a side effect will be that EOT may not be detected correctly when using v2.1 to read a tape written by v2.0. If you have multi-volume tapes written by v2.0 on a 3M, either rewrite your tapes using v2.1, or keep a copy of v2.0 around. ERROR HANDLING This tape handler does not deal with tape errors. If the drive detects a medium error, the current operation will be aborted by returning -1 for Read() or Write(). Some drives insulate the user from bad blocks by automatically correcting them or remapping to a good block, but other drives may not do this. HELPFUL HINTS: Label your tapes. Include the file number or block number of each file on a multi-file tape. Try backing up and restoring a floppy before doing the same with your hard drive, to make sure the process works for you. For the same reason, make a HD backup to floppies first. Then if the tape restore fails, you have something to fall back on. This is obvious, right? Make sure you have a copy of the handler and TAR on an easily-accessible floppy. If the only copy you have is on your hard drive, you might find it difficult to restore from a tape backup after a disk wipe-out. RAW COMMAND INTERFACE This handler provides a means to send your own SCSI control commands to the tape drive, without the need for a special program. Some control commands you might want to send it would be REWIND, UNLOAD, ERASE, FORMAT, LOCK, etc. Only control commands may be sent- there is no provision for any data transfer; don't try it. (As you might guess, raw commands can be dangerous.) The raw command mode is invoked by writing data to the file name "TAPE:RAWCMD". This magic word is how the handler knows you want to do a raw command. You send a command via RAWCMD using the CLI "ECHO" command: ECHO >TAPE:RAWCMD "hex command bytes..." You can put the ECHO command in a script or make a shell alias with it. The exact value of the data bytes is determined by the byte format of the SCSI command you want to send. (Refer to your drive documentation.) The data must contain only hex digits and spaces, terminated by a newline. Each byte of the raw command should be specified as a pair of hex digits; separate bytes by spaces. Up to 12 bytes may be specified. Trailing omitted bytes are assumed to be zeroes. Command examples: Rewind: "01" Erase: "19" (seq. drives only) Retension: "1B 00 00 00 03" I have included in the distribution a small ARexx script named TAPE.REXX . It will issue some of the common control commands for you. Refer to the script for more information. USER-SPECIFIED MODE SELECT In recognition of the fact that it will never be able to provide switches for all possible modes of all tape drives, BTNtape allows you to set the modes of the drive directly. These modes might include: buffering, speed, auto-loading, disconnect/reconnect, medium type, etc. *NOTE* Do not use this feature unless you know what you are doing. This feature is provided for the convenience of "power users". Most drives can get by with defaults if you do not set the modes, so it is unlikely that not setting a mode will cause problems. Drive modes are set using the SCSI command MODE_SELECT (0x15). BTNtape will send its own MODE_SELECT to the drive if necessary to set the drive to fixed block mode and set the block length. But you may also send this command to the drive at other times, using any data you wish. The command is sent in a manner very similar to the RAWCMD method described above, but the magic word MODESEL is used instead. The handler provides the SCSI command, and you provide the data. The data is specified in an ECHO command as pairs of hex digits separated by spaces: ECHO >TAPE:MODESEL "hex data bytes..." Since each drive has different things that are affected by MODE_SELECT, you MUST refer to the programming documentation for your drive. But in general, the mode select data consists of a parameter list, a block descriptor, and vendor unique parameters. *NOTE* If you specify a block descriptor, it will behoove you to specify the same block length as found in the mountlist entry when using fixed block mode, or zero if using variable block mode. The handler counts the number of bytes you enter (up to 64), and uses that for the SCSI command data length. The drive may be fussy about the length, so enter exactly the number of bytes as described in your docs. Mode Select data example: --parmlist- ----block-descriptor--- vendorparms 00 10 00 08 03 00 00 00 00 00 04 00 11 22 33 44 | | | || || Buff_mode BD_Len Density Blk_Len FINE TUNING There are a few factors you can tweak to get good performance on your particular system. Good performance means the tape tends to run continuously for long periods of time and seldom has to stop and back up to get a running start at the next block. (On some drives, poor performance also results in a reduction of the amount of data you can write on the tape.) The tape may have to stop while TAR gets more data from the hard disk, but you can minimize it. The handler's NB parameter can be increased from 1 to some larger number as your memory allows. With more handler blocks, a larger quantity of data is available to dump to the tape. But beyond a certain number of blocks, there is no further advantage. The TAR program also has a block parameter. It controls how much DOS data TAR collects before sending it to the handler. If you use many TAR blocks, it makes no sense to also use many handler blocks, since the data has to go through both buffers anyway. You can increase the TAR blocks if your SCSI- direct driver does not support multi-block operations. Other activities going on in other tasks may slow down the tape. Shut down non-essential programs that take CPU time or make lots of disk accesses. Using the TAPEMON program may slow down the handler slightly when it prints messages, but it's not really a problem. If you absolutely need maximum throughput, shut down TAPEMON. HOW IT WORKS Two buffers are maintained so that one buffer can be used by DOS while the other is exchanging data with the drive. With the multitasking nature of the Amiga, this should help keep the tape in motion, but it may not help much with non-DMA SCSI adapters. In write mode, the handler collects DOS data in one buffer while the previously filled buffer is being written to tape. In read mode, the handler reads ahead on the tape to fill one buffer while DOS gets data from the previously read buffer. Seeks are implemented as a special form of read which does not return any data. The handler does not write (or expect) anything special on the tape for itself. That is to say, the data written on the tape is your raw data, nothing else. If I were to use parts of the tape for file system information, I would be creating an incompatible standard. Raw data provides a lowest common denominator which should help compatibility with other things. For instance, a TAR tape created on a non-Amiga system is readable using this handler and Amiga TAR. BUGS Avoid using the INFO command from another CLI while a tape operation is in progress. It may cause BTN to crash the machine. This may also happen with any program that causes a packet to be sent to BTN. The variable block mode of operation (VB-1) has not been tested, and is not very useful in its present form. The handler has not been tested with AmigaDOS 1.2. If you use the Xoper or ARTM utilities, and display the device list, the entry for TAPE: will show garbage, and the Amiga may crash. I believe this to be a bug in those programs, but this will be little consolation to you after your machine crashes. The handler gurus when compiled with Manx 5.0d. This may be a Manx problem, because it works fine with 5.0a. CONTACTING THE AUTHOR: Email: DrBob@cup.portal.com OR ...!sun!portal!cup.portal.com!DrBob USmail: Robert Rethemeyer 979-4 Belmont Terrace Sunnyvale, CA 94086 USA IMPORTANT!! If you want to contact me about a problem, you need to include with your mail the following information: * your configuration: model of Amiga, SCSI adapter, and tape drive * the version of BTN you are using * a copy of your mountlist entry for TAPE: * a capture of the output from TAPEMON. Just redirect its output to a file: TAPEMON >filename * a verbal description of what happens to the drive and/or Amiga (e.g. tape doesn't move, smoke issues from Amiga, etc.) * any other info that may help me figure out what's going on. Remember, I'm not there to see what is happening, and I probably don't have your hardware setup available to recreate the problem. I have only your description to go by. MANY THANKS GO TO: Beta testers Bill Seymour, Don Phillips, Steve Goldstein, Loren Rittle, Keith Barrett, Mike Meyer, Serenella Ciongoli, Dan Moore, Cal Delaney, Dan Griffin, Thad Floryan. (Sorry if I forgot someone.) Loren Rittle, Stephen Kelley, and Michael van Elst for enhancement suggestions, code examples, and general advice. Dennis Brueni for example code for Seek() handling. Scott Blackledge for loaning me his machine and tape drive. Bob Mitchell for the SCSI-direct programs I used to get started, and the 2090A circumvention. Phillip Lindsay for the my.handler example code. Rene' Vega for advice and Manxification.