Conference hydra::amiga_v1

You must keep the mountlist as the original shows (startup = ) since that's 
how tape-handler figures out where the tape is (check the source!)

I've gotten it "ported" over to SAS/C. Had to hack up the standard C startup
code (hack to say the least. I'm not proud :-)

Here's some mail from the developer of tape:



From:	DECWRL::"[email protected]" "Markus Wandel" 16-AUG-1990 11:03:30.63
To:	distribution:;@decwrl.dec.com (see end of body) 
CC:	
Subj:	TAPE UPDATE 

Hello all,
 
When I first offered to send the TAPE: stuff, I warned that there might be
problems and incompatibilities, and that it might not work on everybody's
(or anybody's) system.  Well, here is one of them:
 
In my mountlist, I use a line of this form:
 
	StartUp = 512/scsi-disk.device/7/0
 
A couple of people have found that their "mount" command does not accept this,
and have translated it to this:
 
	Device = scsi-disk.device
	Buffers = 512
	Unit = 7
	Flags = 0
 
This is NOT the same thing!  What that does is set up a disk parameter table,
which the handler can't understand at all.  It then fails to start up, 
returning an error code ERROR_NO_FREE_STORE (because I couldn't find a suitable
one).
 
You have to use a mount that supports the "StartUp" syntax.  It appears that
only the ARP 1.3 mount command does.  If the keywords for the "mountlist"
were documented anywhere, we would not have this problem, but AmigaDOS
documentation being what it is, when I saw this syntax somewhere (in the
distribution of PLT: I think) I tried it myself, found out what it does, and
used it.  Sorry.
 
I'm going on vacation in a couple of days, and will be gone for two weeks
(my phone number there is in the README file I sent out, but my Amiga will not
be there).  When I get back at the start of September, I will try to help
a few people get this thing going.
 
Markus Wandel
 
 
 
%%% overflow headers %%%
To: [email protected], [email protected], [email protected],
        [email protected], [email protected],
        [email protected], [email protected],
        [email protected], [email protected],
        [email protected], [email protected],
        [email protected], [email protected], [email protected],
        [email protected], [email protected],
        [email protected], [email protected],
        [email protected], [email protected],
        [email protected]
%%% end overflow headers %%%
 
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
Received: by decpa.pa.dec.com; id AA19253; Thu, 16 Aug 90 07:36:39 -0700
Received: by decwrl.dec.com; id AA26602; Thu, 16 Aug 90 07:36:07 -0700
Received: from bnrgate.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA11448; Thu, 16 Aug 90 10:35:07 -0400
Received: from bnr-rsc.UUCP (carrsc) by bnrgate.BNR.CA (4.0/SMI-4.0)
	id AA27837; Thu, 16 Aug 90 09:40:31 EDT
Received: by bnr-rsc.UUCP (5.52/smail2.5/03-07-88)
	id AA09288; Thu, 16 Aug 90 09:49:05 EDT
Date: Thu, 16 Aug 90 09:49:05 EDT
From: [email protected] (Markus Wandel)
Message-Id: <[email protected]>
To: distribution:;@decwrl.dec.com (see end of body)
Subject: TAPE UPDATE

    Is the PD tape drive on the Digital Network ???
    
    If not could some kind soul please upload it.
    
    
    
    Thanks Shaun.
    

    
    
    Yes Please Could someone Please Upload this File as I have a HardFrame
    with a TEAC 50/60 meg Tapedrive which don't work at the moment with any
    of the S/W I've tried.........
    
    
    	Steve G

sure is. I posted it a few weeks back:

wjg::amiga:tape.zoo  and tape_tar.zoo

That tar will work with this tape handler.

This is kinda neat since it gives you a TAPE: device. You can
COPY to and from it as well as use tar.

1> copy john:src/*/*.* tape:
1> copy tape: scratch:

1> tar -cvf tape: john:src/

etc...


I've been hacking it lately since it doesn't properly deal with the SCSI ILI
bit (shorter/longer block that the request was for) and tar seems to do this 
now and then...

john

    What types(brands, format, etc)  of tape drives are you folks using?  

And what SCSI controllers will this work with?

    
    
    	re .5 .6
    
    	John and I have been working with tape software for awhile.
    John and I both have GVP controllers, but anything that supports
    "SCSI Direct" works. John has been using a Cipher ST105 and I'm
    using a DEC ??? ( to be announced .. ). I have also tried a TZK50,
    TLZ04, and Exabyte 8mm drive.
    	I also have software I've been writing. I hope to get something 
    working soon.
    
    			Steve Peters
    

Re: .*

I remember reading that AmigaDOS V2.0 comes with a tape backup program
that uses SCSI direct to control the tape drive.

Is this true?  Anyone with a 3000 care to comment?

The 3000 which I have access to, refers to 2 backup/restore utilities, HDBackup
and BRU (backup and restore utility). HDBackup is not yet ready for distribution 
which is why BRU is included.

To quote from the relevant manual pages:

HDBackup (Page 6-6)

"....HDBackup provides an easy way to backup your hard disk to floppy disk or
tape, and then, if necessary, restore them to your hard disk."

BRU (Appendix C)

"....BRU allows you to backup [archive] your hard disk by copying information
stored on the hard disk to floppy disks or magnetic tape (if you have a
magnetic tape drive)."

			Alan T

    
    I Have a HardFrame and a Teac MT2ST-45S and have tried several programs 
    including the tape.zoo from WJG but ot no avail...
    
    The HardFrame is at rev 1.5 (eeprom) and S/W at 1.58...
    
    When I use the tape driver I get the requester saying :-
    
    An Error has occured while trying to write/read to tape etc..
    
    The Tape drive does move the tape on power-up I have to remove the
    cassette so the system boots..
    READBLOCKS find the tape unit and sayes it at SCSI address 4 with
    8 logical unit attached all 0 Meg ...
    
    But if I select on the tape moves to eot then to bot and it said it
    lied about size ...
    
    Does anybody know the teac unit (it must work Xetec use it) or is 
    it likely to be the HARDFRAME..(REV)???
    	Steve G

probably hardframe? Although if your doing SCSI Direct the Hardframe should
not interfere at all (well, mayby it tries to "protect" itself).

Call Microbotics and ask. Hopefully this weekend I'll get some time to finish
adding better error reporting into the tape-handler. At least you'll know
*why* it got an "error during read/write"!

john

  Well, I replaced my mount command with "Arp's", and re-edited my mountlist
 to contain the correct command syntax.
  I then (with the tape cartridge ejected) typed "copy tape: to nil:" and 
recieved the proper requester saying "Tape unit not ready".
  I then placed the cartridge into the tape unit and repeated the command.
 It started reading the tape, and then came to a halt with "Error reading
 tape, Data probably corrupted" requestor.
  I also tried Tape:R and Tape:A (rewind & append) and got a "Unknown Packet"
 error.
   John, I'm also using a Cipher drive, perhaps I could get a copy of your
 working driver.

								Thanks;
									ED

    When will someone create a device and driver that will allow
    serial/parallel/scsi backup to a VHS VCR? Just get the recorder
    going, do the command, turn the recorder off. Might make some $$$
    for someone.

>  I then (with the tape cartridge ejected) typed "copy tape: to nil:" and 
>recieved the proper requester saying "Tape unit not ready".
 
ok.

> I then placed the cartridge into the tape unit and repeated the command.
> It started reading the tape, and then came to a halt with "Error reading
> tape, Data probably corrupted" requestor.

What was on the tape to begin with? If you "copy tape: to nil:" from a tape
with nothing on it, you get nothing!

Try this:

	copy *.* tape:r
	copy tape:r nil:

and see what you get...

john

PS My handler is the one you have, with a few *unfinished* changes to get
SCSI error (and other) info in the requestors. I should get more done this weekend 
(hope it rains! :-})

    
    re .13
    
    	A VCR is not a good device to do BACKUP to. The error rate of a
    VCR is very bad. You would have better luck with an old audio tape
    interface.
    
    		Steve Peters
    		Tape/Optical Eng.
    

    re: .15
    
    However, a VCR has a much higher data rate than an audio tape. 
    Couldn't you use lots of ECC to overcome the high error rate?
    Even if you only got 512 data bytes per frame, it might make a
    good backup device: that's 30 blocks per second, or just over
    a minute per megabyte.
        John Sauter

  re: .14
 

  Well I tried issueing a copy *.* tape:r command, and recieved an "error 
writing tape, data probably corrupt".
  I also did copy tape:r nil: and got a error reading tape, data probably 
corrupt.

  						Thanks; 
                                                	Ed

Re. .15,.16

Alpha Micro was using in time an interface to make VCRs backup devices.

Sorin

    I still think this would be a good idea. It's a common digital recording
    medium, you can fit about a gig or more on a tape, and the tapes
    are cheap. The drawbacks are the speed of the medium and lack of
    random access. Using that IR attachment product could help produce
    some flexibility in random access.
    

     I just recieved a SCSI test program from Eric Quackenbush at Lake
    Forrest Logic, It will let him know if my tape device will work
    with the tape-store software.
     I'll upload it to tape:: if anyone else is interested.
                                                              Ed
    (P.S. Lake Forrest Logic wrote the Tape-Store program that GVP sells)
    
    
                 

Please upload it.

john

    re -a couple.
    
    I recall a discussion on using VCRs for backups. I think it was in this
    conference a while back, and the end result was that some of the people
    from the storage labs indicated they had looked into it and it's not
    reliable enough ?
    
    Mike

    Re:-2
    
     Okay, 
      The file SCSItest.lzh is in the Tape::user2:[upload] directory.
      
    
    									Ed

I was in a seminar all weekend and didn't get to *anything*.

john

    Well GVP wants $149 for the tapestore software
    Looks like I'll be waiting for the PD version driver...
    
    							Ed
      
    

Yes, sorry I'm taking so long on this. With work and school, the weekends
are about the only time I get to "play".

I promise, no seminars this weekend :-)

    Sorry John,
    
    	I didn't mean for you too take it personal ;').
      
    							Ed
    
    
    

I didn't :-)

Well, I felt so guilty last night that I blew off my homework and finished up
work on the tape-handler (even fixed the tar problem!)

I have a debug copy at wjg::amiga:debug-tape.lzh

It's only the tape-handler itself. I even remembered to remove the -m3 (68030)
compile flag :-)

Copy this to L: and mount it using the default mountlist parameters that
came with the original archive (you can change the number of buffers)

When you mount tape: it will create a 250x200 window to which it will 
output lots of information as you use it. If you run an interlace workbench
you might want to resize the window so it captures as many output lines as
possible (ie size it from top to bottom of your wb screen.)

Then create and read a tape (using copy or tar) and see what you get. 

Let me know...

john

    Thanx!!!!, I'll go home tonight and try it out right away.
        
    								Ed
    

    What tape backup devices does this software work with. Any cheap 
    recommendations?
    

it *should* work with any SCSI tape drive on a SCSI adapter (ie gvp, hardframe,
 A2091 etc) which supports the *real* scsidirect protocol.

john

    Re: .32
    
    Does anyone know if the Supra WordSync controller/software supports the
    scsidirect protocol?
    
    I have V1.09f of the software.
    
    John

    According to the documentation I received with my 500XP it is supposed
    to implement CBM's RDB standard and support SCSI Direct.  I believe
    I am using V1.10d but V1.09f should be ok.
    
    md

    Thanks. Do you know what the difference is between V1.10d and V1.09f?
    
    I guess I could just call and attempt to get an upgrade - I'll go see
    my dealer first though...
    
    John

 I tried the new tape-handler, and it does give quite a bit of information.
 But it doesn't work on my system.
  Here's what I got.
 My command was "copy *.info Tape:"

	WAITING FOR DOS STARTUP
	PARSESTARTUP ()
	NOT_READY ()
	 	DO_SCSI()
		OPCODE=01, LEN=0
	INIT_WRITE ()
	        DO_SCSI()
		OPCODE=1A, LEN=3
		**UNKNOWN ERROR**
	TAPE_WRITE()
	FINNISH_WRITE()
		DO_SCSI()
		OPCODE=10, LEN=0	 

 I tried copying to Tape:R:, Tape:A: and various other forms and always recieved
an error, just before reading or writing, other (rewinding) stuff seemed to work
fine.
							Thanks for any help.
						
								Ed

    re: Supra v1.10 software
    
    I got v1.10-something in August and found a C coded example of using
    SCSI Direct.  However, the include file needed to compile the example
    was missing!  A call to Supra brought the explanation that a) they had
    personnel turnover and b) a more complete version of the SCSI Direct
    stuff would be out Real Soon Now.
    
    BTW, if you have the same version as mine, the SupraFormat program
    gives incorrect totals when partitioning a hard drive.  The partitions
    come out correct, it's just the display that's wrong.
    
    Wes

>	INIT_WRITE ()
>	        DO_SCSI()
>		OPCODE=1A, LEN=3
>		**UNKNOWN ERROR**

Interesting, the opcode 1A is a MODE_SENSE command. tape-handler is trying 
to see if your tape is write-protected. It appears your tape does not
like the command. What kind of tape drive do you have? Do you have
specs on it?

I can easily make that a non-fatal error, however, I hope your tape drive 
is smart enough to not allow writes to a write-protected drive...

john

    The drive is a Cipher QIC ST150.
    The tapes themselves have a write protect on them. Its a small round
    drum that rotates, I played with it a little, and when rotated to the
    Safe position, the handler returns a "Tape Unit not ready" error when
    accsessing the drive.
     I assume that this drive uses this physical switch to allow the drive
    to realize that there is a tape in the unit. When the drum is rotated
    to the normal position the switch in the unit rests against it wich
    allows writes and lets the unit know there is a Cartridge in the drive.
     When rotated to the safe position, this lets an opening in the drum
    to face the switch, which fools the drive into thinking there is no
    tape in the drive, and the unit won't write to the tape.
     Same switch serves 2 functions I guess. 
    
    								Ed
       

That's the same drive I'm using, let me check out the write-protect behaviour.

The write protect drum is definetly write protect only. If it were a ready
switch then you could not read a write-protected tape!

Steve Peters, does this make sense?

john

    re .39 .40
    
    	The drum is write protect only.
    
    	If John will print the error code I have detailed specification
    	for this drive. I can translate the error codes ( both major and
    	minor error codes ).
    
    
    		Steve Peters
    
    P.S. The Cipher ST150 follows SCSI I and fails on SCSI II commands.
    
    
    

I'll get more sense info in there tonight (it should have printed it!)
and post another version.

john

    Just something else I needed to add,
     Last night I played some more with it.
     The driver gives no error reading the tape.
     I did a "copy tape: to nil:" and it completed the command succesfully.
     I recieved no errors.
     I then tried some other stuff.
     I "ED tape:test" to see if I could write a text file to it.
     It started okay, but when I went to exit to save the file I recieved a
     "Disk Full" error. 
     Course this might be because the handler isn't set up for this type of
    operation (I don't know).
     But then I tried "copy tape:*.* to ram:", this worked without a flaw.
     I looked in ram: and found the file "test" in it, only it was empty.
     So, I guess it did write something to it, before the error bombed it
    out.
       I don't know if this stuff helps at all, but I thought I'd mention
    it.
       If you want me to try running different commands on it and write
    down the output from the debug window, let me know what you'd like me
    to try for commands.
       One other thing that might have nothing to do with it, but the
    line in the example mountlist looks something like this.
       startup=512/gvpscsi.device/2/0.
       I'm assuming this is correct, since it seems to work best.
       Running SCSItest program that I recieved from Lake Forrest logic,
    tells me that my unit has openflags=16.
       I've changed the 0 to 16 and back again in the mountlist with no
    difference as a result, (that I could see).
       Also using the example name given as my scsi.device
    (scsi-dev.device) gave me an error, I assume thats because it can't
    find it in the devs: directory. 
       P.S., trying to write to the unit with SAFE enabled gives me a bad
     mode sense error in the debug window, this is the same error I recieve
     if I accsess the drive without a tape in it.
    
    						Hope some of this helps.
    							Thanks ;
    								 Ed
    
     

I need to put more info collecting into tape-handler and I'm trying to get
it to create a file to dump all the info into (so you don't have to copy
the stuff in the debug window). Unfortunetly DOS gets angry when it's gets
a request while it's processing one (inside tape-handler!).

tape-handler only handles the DOS ACTION_OPEN, ACTION_READ, ACTION_WRITE and
ACTION_CLOSE packets. So file locks don't work and you can't create 
directories on a tape.

Remember that tapes are different than disks (very different!). A disk is 
random access, a tape is sequential. Files on a disk can be created
and deleted at will. [typically] you can't create and delete files in the 
middle of the tape. Things go on in one big stream and come off in a stream.

Data on tapes is laid out in records. A disk has 512 bytes (usually) per
"record" and these can be grouped into files. On a tape, you write
data in usually much larger chunks. When you read it back, you must
ask for the same amount of data that was written in the record. 

tape-handler will buffer up writes (and reads) until it hit's the buffer size 
(which is specifified in the mountlist). It will then write one big record
that may be 512K bytes long. When you read back data, tape-handler will read
512K bytes at a time off the tape since that's what it wrote. If the record
on the tape is not 512K bytes (or whatever size is in your mountlist), the tape
drive will complain that the request was for a different size than the record 
on the tape, and tape-handler will complain to you that LENGTH NOT EQUAL ACTUAL.


What's all this babbling about? Well, to use a tape drive, you have to observe 
some constraints. 

If you want to use the copy command on one particular tape cartridge, then you 
can only use the copy command on it (tar will not work, well - this is not 
*entirely* true, but for the sake of simplicity...). If you use tar, then 
only use tar.

To read from a tape, you have to have written that tape with tape-handler first
since tape-handler assumes the records are a fixed size (and are the size
specified in the mountlist).

If you create a tape with either tar or copy, you must not change the buffer 
size in the mountlist if you expect to be able to read that tape back. Writing
and reading of a particular tape must be done with the same mountlist parms.

You cannot EDIT files on tape (I'm surprised you got as far as you did with 
ED tape:test.file !)

does any of this make sense?

I will hopefully get time tonight to play (but I just recieved Minix so I'm
destined to be torn for awhile :-)

john

I've put a new copy of tape-handler at wjg::amiga:debug-tape.lzh

This one dumps more info, esp around DOS packets and scsi sense.

john

    Thanks John,
    
    	I'll bring it home tonight and copy down the results.
    
    								Ed
    

     Sorry John,
    
        But this version of the handler doesn't seem to work at all.
       If my tape unit is on, and I mount tape:, it opens the debug window,
       and prints "parsestartup" and stops, My cli just hangs in an open
    state.
    	If my tape unit is off, and I mount tape:, it does the same, except
    the whole system locks up.
    
    								Ed
    

That's weird! I copied it directly from my system.

I'll check it and upload another copy...

john

    
    Well I copied the tape-handler via PCSA and it works for me EXCEPT my 
    tape drive still don't work....I'm still trying/waiting...
    
    	Steve G

     I'll try recopying it.
    
    						Ed
    

    
    Just to confuse things I've upload another tape-handler from the net to 
    TAPE::USER2:[UPLOAD]TAPE-DRIVER2.LZH
    
    
    This one has a built in TAPEMON program BUT still doesn't work wit my
    TEAC , HARDFRAME (V1.5) System...
    
    Steve G

     John, 
           I re-copied your driver, and got the same results as with the
    first copy, debug-window opens, prints parsestartup() and hangs.
    
    								Ed
    
    

Is there anything funny in your mountlist?

john

    In my mountlist, I've 2 entrys for my hard-drive, (although I believe
    they aren't used.. the documentation says that the RDB has a copy and 
    that is the one used.)
     Then also the usual entrys that come with the standard mount list.
    
    This is my entry for Tape:
    
    	TAPE:	Handler= l:tape-handler
    		Startup= 2/512/gvpscsi.device/0
                Stacksize= 4000
                Priority = 5
                Globvec = -1
#
							
    							Ed
    
       

does the previous version still work?

I'm at a loss since I didn't really change anything. I just added more
output.

     I'll replace the previous version tonight, and let you know.
       
    								Ed
    

    John,
       Did you  take you're old version down?
    	Could you put it back up on the net?
    
    							Thanks 
    								Ed
    

    
    I took a TK50 home for use with my A3000 and the CBM supplied
    BRU worked flawlessly under 2.0!  I haven't managed to get the
    tape-handler working, but I'm impressed with how easy it was to
    get BRU working.  All I did was attach the drive and edit the
    file s:BRUtab to specify SCSI unit 0 for tape:.
    
    Since this works so well I don't think I'll be needing the tape
    handler.  The only oddity I'm seeing is that I need to power the
    TK50 up first and let it settle down.  Otherwise it must interfere
    with the scsi bus somehow, because I get a software error if I try
    to turn on/boot the system at the same time.
    
    -steve

>    handler.  The only oddity I'm seeing is that I need to power the
>    TK50 up first and let it settle down.  Otherwise it must interfere
>    with the scsi bus somehow, because I get a software error if I try
>    to turn on/boot the system at the same time.
 
The TZK50 takes over 1 minute to come ready after powerup or bus RESET. 
The A3000 driver probably times out waiting for it.

I'd recommend using bru if it's available. It's supported by CBM...

    HI Guys,
    	Just a few thoughts on this..
    
    Re .13,15,16  Alpha got around the error rate on VHS recorders in an
    ingenious way...
    They knew that the media was poor so they recorded every block( ore was
    that 
    record ) 6 times, that way recovery stood a fairly good chance..
    
    
    	Re the new version with the debug etc... Do both you guys have the
    same amount / type of fast memory.. ie with all this extra
    functionality your not blowing stack or something ?
    
    		- Pete -

    
    I have been able to borrow a TZK50 just try this out, but I am using a
    2090A for SCSI.  Now it seems to me an earlier discussion touched on
    the 2090A not being able to do direct SCSI.  This recollection and the
    fact that I cannot seem to be able to find any form of a SCSI .device
    leads me to believe that the 2090A is not capable of driving a tape
    device.
    
    Can anybody confirm or deny or even give a clue what needs to be done
    to get a tape drive to work with the 2090A controller.
    
    wayne
    

 re: .51

  I downloaded TAPE-DRIVER2.LZH, but had even less luck running it.
  It seemed to mount okay, but wouldn't operate the drive at all.
   
  John,

  I found an your older version on my Hard-Drive, and it worked as before.
  I recieved an OPCODE=1a, LEN=3 **UNKNOWN ERROR** trying to write.
  Now, because it is a sequential device - I was curious... Uh, I don't
  need to format this tape, do I (I'm gonna feel real dumb if this is my
  problem.)?

  re: .60

   I'm using a stack size of 4000 on the newest Tape-Handler, I've got 3
 meg of ram on my machine 512k Chip, 512k Slow, 2meg Fast

						Thanks
							Ed

    Just to see if the thing is out there.  Pick up the file SCSITEST.LZH
    mentioned in a previous reply.  I think I got it off wjg::amiga:.
    
    I put my tape at LUN 0 and on the 3000 the scsi device driver is
    scsi.device.  So I can use this test command as:
    
    1> scsi 0 scsi.device
    
    This returns some information about the device.  Mainly for me the
    one I look at is a message which comes out when the device is
    not ready yet.  Handy because I don't have any other way to tell
    when it is ready.  The lights on the drive seem to come up fairly
    quickly, but don't really seem to indicate it's ready to talk.
    
    -steve

    re:-1
    
    I've already run this program on mine and it outputs all the
    information onto my screen correctly.
    
     I used scsi 2 gvpscsi.device, and it came back with the drive make,
    and some other miscellaneous data.
    
    							Ed
    

Oops!  Didn't realize you were the one who posted it :-).

Since I know that the BRU which came with 2.0 works 
without a handler or mount command, etc, why don't you 
go back and find the fish disk with BRU on it and see
if that supports Tapes in that version?  Couldn't hurt...

-steve

     Sounds good, I'll give it a try.
    
    				Thanks ;
    					Ed
    

I've been pretty busy lately and haven't even booted up amy for a few days!

I'll try to recompile the tape-handler and repost it.

john

    
    
   John, I my third download of your program was a success, below is the
    output from a "copy *.info tape:" command.
    (nice debug output!).
    
    
    
==========================
DOS pkt: 8 = UNHANDLED PACK
ET!
==========================
DOS pkt: 1006 = ACTION_FIND
OUTPUT
not_ready()
  do_scsi()
    opcode=00, len=0
==========================
DOS pkt: 87 = ACTION_WRITE
init_write()
  do_scsi()
    opcode=1A, len=3
** Unknown Error **
** IOSTAT = $d
tape_write()
===========================
DOS pkt:  1007 = ACTION_END
finish_write()
  do_scsi()
    opcode=10, len=0

    
    Any idea whats wrong ?
    							Thanks;
    								Ed
    

> ==========================
> DOS pkt: 87 = ACTION_WRITE
> init_write()
>   do_scsi()
>     opcode=1A, len=3
> ** Unknown Error **
> ** IOSTAT = $d
> tape_write()
> ===========================

this looks suspicious. The opcode=1A, len=3 part is sending a MODE_SENSE
command to see if the tape is write protected. I'll have to look back at the
handler source to see what's going on after that. It looks like the tape is 
returning a strange sense key to the MODE_SENSE command (the unknown error part
is just a SCSI sense key that is not dealt with in the handler) IOSTAT = $d
looks wierd. I never use the '$' to indicate hex format, I use 0x as a
prefix. This might be a bug in the printout routine of some sort...

john

    
    
    Hi you all,
    	      I would like some more info on all the different
    tape-streamers.. mailed to me
    
    	IE the SCSI codes (00H test tape) and on the sense code the
    meanings...if the bits set
    Here is my sense data for TEAC MT-2ST/45S
    

Teac Sense data
+-----------------------------------------------------------------------+
|			BITS						|	
+---+-------------------------------------------------------------------+
|Byte|	7	6	5	4	3	2	1	0	|
+----+------------------------------------------------------------------+
| 0  |valid     1	1	1	0	0	0	0	|
| 1  |  0	0	0	0	0	0	0	0	|
| 2  | FMK     EOM     	0	0	{    Sense key  	}	|
| 3  |  {       info byte (MSB)                         	}	|
| 4  |  {       info byte                               	}	|
| 5  |  {       info byte                               	}	|
|�6  |  {       info byte (LSB)					}	|
| 7  |	0	0	0	0      0	0	0	1      	|
| 8  | RES     RES     RES     RES    RES     STALL    HOLE   PARITY  	|
+----+------------------------------------------------------------------+

VALID		=	VALID/INVALID INFO BYTE 1/0
FMK		= 	FILEMAKER
EOM		=	END OF MEDIA
SENSE KEY 	=	as per your sense key!



AUX SENSE

+-----------------------------------------------------------------------+
|			BITS						|	
+---+-------------------------------------------------------------------+
|Byte|	7	6	5	4	3	2	1	0	|
+----+------------------------------------------------------------------+
| 0  |	0	1	1	1	1	1	1	1	|
| 1  | CLD     WPT     BOM     RUN     STRM     {    ID CODE    }	|
| 2  |  {		DATA ERROR COUNTER (MSB)		}	|
| 3  |  {		DATA ERROR COUNTER (LSB)		}       |
| 4  |  {		REPOSITION COUNTER (MSB)		}	|
| 5  |  {		REPOSITION COUNTER (LSB			}	|
| 6  |  {   CURRENT TRACK NO   }	{ CURRENT BLOCK ADDRESS }	|
| 7  |	{		CURRENT BLOCK ADDRESS (MSB)		}	|
| 8  |  {		CURRENT BLOCK ADDRESS (LSB)		}	|
+----+------------------------------------------------------------------+

CLD	=	cassette load (loaded =1 , unloaded =0)
WPT	=	Write Protected
BOM	=	Beginning of media
RUN	=	Running
STRM	=	Streaming

ID CODE

	BIT2	BIT1	BIT0 
	 1	 0	 0	MT-2ST/20S (90 ips) 20 Meg Tape Drive
	 1	 0	 1	MT-2ST/20S (30 ips) 20 Meg Tape Drive
	 1	 1	 0	MT-2St/45S (90 ips) 50/60 Meg Tape Drive

Data error count  = 16 bit binary counter for total no of retries

Reposition counter = total no of repositions (16 bits)

Current Track No. = which track the head is on

Current Block No. = Block address of the block to be processed next in 
		    binary 20 bit
 
    
    
    
    Thanks 
    Steve G

    
    I've been in touch with Robert Rethemeyer (BTNTape) and he sent me a
    new version of the driver ..Its in Tape::user2:[Upload]tape.lzh
    (Tape-Handler.)
    This has the read drive capacity command (25H) remove and a few thing
    sorted out ...
    I now don't get the i/o error 45
    
    It said it was coping the file to tape BUT the drive didn't move except
    for REWINDING...
    
    	How about some one else trying it out with there setup and let me
    know the results...
    
    	Steve G

    I'm trying out several tape drives on a GVP and an ICD controller.
    
    I have a Cypher ST150s-II, a TZ30 and a TK50Z to experiment with.
    
    A couple of questions:
    
    It seems the norm is to ship the drives without any technical
    documentation.  I need the simple stuff, like what are the jumpers
    on each of the drives.  I'm at a standstill without this info.
    
    Also, anyone have the docs on what the TZ30 lights are supposed to
    indicate when they all blink at once.  I assume it's upset about
    something.  I have two units, and can't even get it to load tape.
    I'm assuming it's a jumper/interface/operator problem.
    
    In return, I'll post the results, as well as whether any of these
    drives are usable with the GVP TapeStore software as well as the
    PD drivers out there....
    
    Thanks,
    John
    

    I didn't see this on TAPE:: 
    
----------------------------------------------------------------------------

 Tabu - Quarter inch cartridge (QIC) tape backup utility.
   Copyright 1990 Roy C. Sigsbey - all rights reserved.
   This software may be publicly distributed at no charge.

   usage: tabu [-ddsk] [-sscsi] [-ttap] -b|c|l|r|x [name]
        -b = backup by blocks to tape
        -c = create backup to tape (name required)
        -d = dsk is scsi address for disk (default: 000)
        -l = list tape contents
        -r = restore by blocks from tape
        -s = scsi is scsi device name (default: HardFrame.device)
        -t = tap is scsi address for tape (default: 001)
        -x = extract from tape (name required)
      name = reference name (required for c or x)

   tabu.info ToolTypes may be set as follows:

      OPER=B      backup
      OPER=C      create (NAME required)
      OPER=L      list
      OPER=R      restore
      OPER=X      extract (NAME required)
      NAME=name   reference name (required for C or X)

      LIST=name   list to file or printer
      SCSI=name   scsi device name (default: HardFrame.device)
      DISK=nnn    disk scsi address (default: 000)
      TAPE=nnn    tape scsi address (default: 001)

      Tabu defaults to using HardFrame.device to access a SCSI bus. The SCSI
   address of 000 (as described in devices/scsidisk.h) is the default for
   the disk and the tape is defaulted to the address 001.  Options -d, -s,
   and -t for command line; DISK, SCSI, and TAPE for tooltypes may be used
   to specify other configurations.

      Options b and r (Tooltype OPER = B and R) utilize a block by block
   transfer between devices.  For the b (B) function, the disk is copied
   block by block until the last block on the disk has been read and written
   to tape.  This is a disk image backup.  For the r (R) function, the tape
   is copied block by block to disk until an end of file mark is encountered.
   This is a disk image restore.   Both functions use a block size of 512
   bytes (industry standard size for both devices).

      Options c and x (Tooltype OPER = C and X) utilize AmigaDOS functions
   to access the disk.  The name option (Tooltype NAME) is required for
   these options.  For the c (C) option, the name (NAME) is the directory
   or disk or file to be backed up to tape.  If the name is a disk, the
   subdirectories and files therein will be copied to tape and their names
   will be listed to stdout.  If the name is a directory, it and all its
   contents will be backed up to tape and their names listed to stdout.  If
   the name is a file, then only it will be backed up to tape and listed
   to stdout.  Stdout may be redirected on the command line to any printer
   or file using AmigaDOS redirection.  Stdout may be redirected in Tooltypes
   using the LIST option.  Setting LIST=PRT: for instance will redirect the
   listing to a printer.  For the x (X) option, the name must be a disk or
   directory.  The contents of the tape are written to the disk or directory
   using AmigaDOS commands.  The date/time, protect bits, and comments are
   also restored for the files and directories on the tape.

      The c (C) and x (X) options can be used to backup and restore any
   AmigaDOS file system (yes, including floppies).  Although this seems a
   little like information that isn't real useful, it does give insight as
   to how these options access the disk.

      The two tape formats are not interchangeable.  Attempting to restore
   with option r (R) from a tape created with option c (C) will result in
   a tabu error message indicating improper tape format.  Attempting to
   restore with option x (X) from tape created with option b (B) will also
   result in a tabu error message.

      The last option l (Tooltype OPER = L) is used to list the contents of
   a tape created with option c (C) or to give the backup date for a tape
   created with option b (B).  It lists the protect bits, date and time,
   size in bytes, and the heirarchical structure and names of the files
   and directories for option c (C) tapes.

      Note that a copy of tabu must exist on some floppy or other media than
   the disk being backed up.  If for some reason that disk gets damaged
   (which is why we back them up) the tabu software won't be available to
   restore the disk data.  A copy of tabu on the hard disk being backed up
   is OK and makes doing the backup easier.  There is no copy protection of
   this software except by the user's trustworthiness.

      You may convey your opinions and recommendations to me.

      Address:  Roy C. Sigsbey
                13370 Peregrine Way
                Black Forest, CO 80908

      I hope you find this useful.

--- End of Text ------------------------------------------------------------
    

     Hmmm, sounds like the driver is biult into the program...?
    
    								Ed
    

    I got the program from People Link.  I read several messages saying
    that they just bought SCSI tape drives, plugged them in and used tabu
    with no problems.  I am still looking for a tape drive.(cheap)  I have
    another tape backup demo from Progressive Peripherals.  It looks pretty
    but I do not know if it is functional.  I will upload that if there is
    interest.
    
    md
    

Re: .74

>     Hmmm, sounds like the driver is biult into the program...?

Not strictly true:  The program uses the normal device driver for your
SCSI controller (really "host adapter") board.

In the hierarchy of Amiga system software:

	Device drivers know how to manipulate device registers in order
	to read blocks from physical devices.

	File systems know how to talk to device drivers in order to
	read and write files.

	AmigaDOS knows how to talk to file systems so that programmers
	can use function calls instead of message passing to manipulate
	files.

If you want to write a program that reads and writes blocks at absolute
block numbers from physical devices, you can just pass messages to the
device driver to cause it to happen.

The usual interface to an Amiga device driver contains commands like
"Read block n".  The device driver does whatever is needed to make this
happen.  The trackdisk.device, which controls the floppies, will translate
this request into a read of an entire track of a floppy, use the blitter
to decode the raw MFM data, and then extract the proper block from
the decoded data in memory.  In contrast, the device driver for a SCSI
controller will issue a SCSI protocol command on the SCSI bus to cause
the physical device to send back the block of data.  If you use a
device driver at this high level, then a program is completely independent
of how the hardware works.  Not only is it independent of what device
registers need to be manipulated, but it doesn't even need to know the
overall details of what needs to be done.

In the last year or so, device drivers for SCSI controllers have added
a lower level interface.  The "SCSI direct" protocol works, I believe,
by allowing a program to construct a raw SCSI command (a sequence
of bytes not unlike in principal to a machine instruction) and send a
message to the device driver asking it to issue the SCSI command.  The
device driver doesn't care what the SCSI command is; it just manipulates
the device registers on the controller board to cause the bytes on the
command to be sent out on the SCSI bus.  A program can use this feature
to control unusual SCSI devices.  Such a program is independent of the
hardware registers (since the device driver takes care of that), but
is dependent on the physical device being a SCSI device capable of
responding to particular SCSI commands.

I don't know enough about SCSI devices to know if the program mentioned
a few notes back is having to use the SCSI direct "low level" protocol
or it is able to use the higher level device driver protocol.  I suspect
that it is has to use SCSI direct in order to issue at least a few
special purpose SCSI commands specific to tape drives.

Note that not all SCSI device drivers support SCSI direct.  I believe
that the Commodore A2091 was the first Commodore board to come with
a device driver that supports SCSI direct.  I seem to remember that
the Microbiotics Hardframe and the GVP controllers got this feature
first, just as they added full autoboot "rigid disk block" support
first.

   I tried using tabu on my cipher drive last night and it worked (sort of).
  One problem I encountered was with the -c/-x command.
        It read my hard-drive fine, but restoring the files from tape didn't
  work correctly. Some file types were changed, and some would get an error
  trying to write back onto the hard-drive.

  Perhaps the -b/-r command is more reliable?
  Anyone else have experience with this program?

							Ed

    Nice program, I used it successfully last night on my Tanberg drive.
    Since I'm using an A2091 to control the drive, I NewZapped the program
    and replaced "hardframe.device" with "scsi.device". I no longer have to
    specify the -s switch in the command line. 
    
    One question, can an individual file be restored(-x) by supplying its
    filename or will the -x option always restore the entire tape contents?
    

    Bye the way, I downloaded the Progressive Peripherials Qic_tape backup
    demo last night. Nice! I called PP and asked if this program would work
    on any drive setup, they said NO, only with their controller. My impression
    was that this software could be purchased for any (almost any) tape 
    configuration.
    
    Roger

    FWIW - The progressive Peripherals QIC-Tape backup system is intended
    to be plugged into the FLOPPY expansion port.  It IS NOT a SCSI device.
    
    John
    

    Which tape-handler are most of you using?  I may be able to borrow
    a tkz50 for a couple of weeks and would like to get a head start
    on setting up a minimal system for testing it.  Is anyone successfully
    using a tkz50?
    
    md

  Now that I've worked out my other hardware problems, I'm back at work trying
     to find a workable Tape program for my Cypher 150.
  The demo programs on the recent Fish Disks for backing up haven't been much
 help.
  One doesn't do tape, another only works with Dos 2.0.. (if I had 2.0, I don't
 think I'd need a backup program :')), and the last one "Fastback" expects
 you to have a tape-handler already installed.
  The other assorted handlers for tape on these disks have already been in the
 Public Directories online here for some time.
  From whats been stated earlier my tape drive doesn't handle SCSI II protocol.
 Perhaps this is why the various programs don't work with my setup.
  Unfortunately, I know nothing about SCSI protocol let alone the differences
 between 1 & 2.
  The closest I've come to haveing it operate correctly is with TABU.
  Here are some results.
  
	Tabu using File backup - The first time I'd get about a third into
				 the file By file backup and it'd choke
				 on a particular file.
				 After further investigation this file was
				 protected against RWED. After altering the
				 protection the program backed up about 2
				 thirds of my drive and then came back with
				 Tape_write do_io error:45
	
	Tabu using block backup - This also runs for a while then kicks back
				 an identical error to the one above.
 
  Can someone report back thier Expierences with this program. What does the
 error message mean?
  I'm running.... an A500/Bodega-Bay/GVPseries II/Quantum 80/Cypher st150/3meg
  system.
								Thanks;
									Ed

 

    I'm attempting to use the BTNV2 tape system on my CBM SCSI tape drive
    on my 3000. It mounts, a copy starts to work, but then the SCSI bus
    hangs. Has anyone gotten this to work on the 3000? What were the
    startup settings? Is QIC-xxx better?
    
    
    Thanks!
    
    Keith

I've got it almost working. The CBM SCSI tape drive is really a
CPS150, sequential drive. I'm trying to get BTNV2 working on my 3000/2.0
system so that I can use TAR with my tape drive.

MOUNT works, TAPEMON works, WRITES appear to work, but when reading back I
get occassional SELECT errors. I've tried several combinations of
startup parameters, and there's no tech documentation with the drive itself.

Does anyone know what I'm doing wrong, or what I should use for my
startup parameters? 

Thanks!!!

Keith 

>Does anyone know what I'm doing wrong, or what I should use for my
>startup parameters? 

I have BTN working with a TK50, and ICD controller (ADSCSI 2080) on my 2000.
I'm able to read/write tapes on a DECstation using tar and read/write them
at home using tar on the amiga.

BTN is definately the fastest handler I've tried, due to the number 
of buffers you can use, and the asycn io.

Heres my mountlist:

TAPE:   Handler   = L:tape-handler
        Startup   = "icddisk.device/UN-2/BS-10240/NB-32/OV-1"
        Stacksize = 8000
        Priority  = 5      /* use 11 for Supra 4x4 */
        GlobVec   = -1
        Mount     = 1
#


The only problem I have is that with my GVP030 enabled I get intermittent
SCSI Phase errors (error code 42), this is not anything do with BTN, I
can reproduce this with a small code fragment. I've found that booting up
without my 030 it all works fine. I'm trying to determine if it is a timeing
prob in the ICD driver or GVP. (It works fine with Wayne Oakleys GVP & ICD
controller, so I am expecting it to be my older GVP board).

Thanks for ther reply. I've emailed to the author of BTN (and got as response
within 60 minutes). The response was basically:

	1) It DOES work with the CBM drive

	2) Try a BS of 512 (this is what most drives require)

	3) The next version only addresses the SCSI error that occurs from
	   the new @B 2.0 CBM programs. It doesn't affect TAR


I've tried BS-512/NB-8 and this seems to work; but I have to beat on it
some for before I'm sure. I'll try raising NB also.


BTW -- Are all you fellow 2.0 people using TAR, or BRU? Which is preferred?
       They seem to have the same functionality and restrictions.



Thanks!

Keith

Where can I get BTN and what's the mail address of the author so I can
see if it works with my Dataflyer!

Cheers,

Greg

    1) BTNV2.lzh is in TAPE::AMIGA:[UPLOAD]
    
    2) The docs contain the address of the author
    
    
    My experience is that this driver is "better-than-most" rather than
    better-than-nothing.
    
    For those interested; the author told me the next release will support
    accessing TAPE:app as a method of APPENDING to the end of a tape
    without error.
    
    Keith

 Well, I'm in a bit of a dilemma.
 Originally I purchased 2 tape backup units. 
 A Cipher Drive and a Wangtek.
 At first it was to allow me to back up my hard-drive on my Ami, with the 
 secondary hope of being able to pull stuff off the net by tape ie:Fred Fish
 disks and then taking the tape home and transferring it to my hard-drive or 
 (in the case of Fred Fish) leaving it on tape which would be much more 
 manageable then 500+ disks (lot less expensive too!).
 Now that I'm able to back up my hard drive, I've found that that although I
 can use Tar on my Ami. The only Tar for my Decstation 333c that I can find
 Doesn't access the cipher tape drive.
 Does anyone else know of a MSDOS tape backup program that has an AMIGA 
 equivalent.
 
 Right now I'm doing it this way.

 NFT the PD stuff to my MSDOS Decstation, copying it onto 720K floppies
 using Crossdos on my Ami to put the files on my hard drive, then archiving
 the files onto a tape.

 What I'd like to do...

 NFT Files to MSDOS Decstation, TAR or Equivalent to Tape. Then bring the Tape
 Home... Much quicker Much simpler.

							Any Ideas Welcome
									Ed

    
    Ed,
    
    	I'm using a DEC TZK10 on my VAXstation here are work. I use VMS
    backup to write the tapes and have written Vback to read the tapes on
    the Amiga at home. I'm in the process of writing a full read/write
    version of VBACK for the Amiga.
    	My work at DEC may result in a version of VBACK for MSDOS.
    
    		Steve Peters
    		Tape Eng.
    

	Steve,

	any chance for us, poor A2090-A users, to be able to use
	your TK50Z driver?

	I'm really happy with this controller (ST-506 is important to me)
	and I'd prefere not to buy another one just for the tape.

		roberto.
    

    re: .89
    
     That'd be great Steve!!!
     If You need a Beta Tester let me know!
    
    								Ed
    

Actually, I'd like a copy of VBACK for the amiga. Is it available?

    
    	The Read only version of VBACK is in
    
    		EOT::AMIGA:[AMIGA.HARDWARE]VBACK.LZH
    
    	This will read VMS savesets from a tapedrive and put the files 
    in your current Amiga directory. I have tested it with TZK10 and TK50Z
    on a GVP controller and a Amiga 3000 internal controller.
    
    	As for 2090A, I may have found a way to make it work but don't
    count on it yet.
    
    
    			Steve P.
    
    

    

>    	This will read VMS savesets from a tapedrive and put the files 
>    in your current Amiga directory. I have tested it with TZK10 and TK50Z
>    on a GVP controller and a Amiga 3000 internal controller.
    
Thsi program works GREAT. Just be sure to LHARC any TEXT files you try to
use. Upon unpacking the files on Amiga side, RMS attributes seem to get
lost :-)

john

    I've been having intermittent scsi bus lockup on my A3000 for as long
    as I can remember.  Doesn't happen very often.  I've been wondering
    if I have the termination right.  I left the terminators on the
    internal quantum and put a standard dec terminator pack on the TK50Z.
    Is this what everyone else is using?
    
    Does anyone else ever get lockups using V2.03 or earlier?
    
    2.04 alledgedly fixes a scsi bus lockup problem with reselection,
    but my warranty is running out.  It doesn't look like 2.04 will be
    available soon to non-developers so I'm debating taking the system in.
    I have turned off reselection on the quantum, but do I need to also
    do this for the tape drive?  and how?
    
    The thing is they usually only crop up during a backup to the tape.
    I have had a few when I wasn't using the tape, but it was connected
    to the system.
    
    thanks,
    
    steve

    re .95
    
    	You have a termination problem.  The SCSI bus should be terminated
    at each end. The A3000 controller has terminators on it. Only one
    other device should be terminated. Because of the A3000 cabling the
    controller is in the middle and should not be terminated, but this is
    not possible. The second best is to have controller termination and
    then terminate the device that is physically far away. I would guess
    the tape drive. This means pull the termination on the internal hard
    drive.
    
    	As for Amigados 2.xx , You still get free updates until the ROMS
    and official kits are released.
    
    		Steve P.