Conference hydra::amiga_v1

    Thanks Steve!!!!
     Hope is rekindled!!!!!
    								Ed
    

    
    
    	I more thing, I have included the tape handler of QIC drives
    in the TK50z archive. This will support TZK10 and cipher st-150.
    
    		Steve Peters
    

    
    Thanks from here as well Steve.
    
    I gave it a try over lunch and had some problems.  I tried three
    controllers on two different machines.
    
    Here are the results:
    
    Machine - 2000 w/33mhz GVP 4mb 32bit, ICD Advantage 2000, CBM 2090A
    
    1- TK50 connect to ICD controller
    	Tried three times with command 'tar cvf tape: "."' each time the
    system would hang (hd light on solid).  The debug window showed the
    following:
    		dos pkt: 87 = Action_Write
    		tape_write()
    		 do_scsi()
    
    		 opcode = 0A, len = 10240
    
    Each test would write a varying amount of data, from one file to three
    files, in all cases the hang occured within about 10 sec.
    
    2- TK50 connected to CBM 2090A
    	In this test the system would hang before writing to tape and a
    requestor indicating tape: was not ready.  Messages in debug window as
    follows:
    
    	dos pkt: 8=unhandled packet:
    	reply port
    	message sent
    ========================================
    	dos pkt: 1006 = Action_find output
    	not_ready()
    	do_scsi
    	 opcode = 00, len = 0
    	 stat 2A length 0
    	** Unknown Error **
    	** IOSTAT = $d
    
    
    Machine 2500 with 4mb 32bit & 2mb 16bit, 2090A, GVP-II, 2xASDG dual
    serial.
    3- TK50 connected to GVP-II
    	This was tested twice with the same results however different
    amounts of data was written to tape.  Each of the tests were
    accompanied by a requestor with the message 'An error has occured while
    trying to write to the tape.  Tape data is probably invalid'.  The tar
    program ended with 'tar: tape:: write failed, short 10240 bytes'.
    
    The information from the debug window is a follows:
    
    	dos pkt: 87 = Action_write
    	tape write()
    	 do_scsi()
    	 opcode = 0A, len = 10240
    	 stat 2A length 0
    	**Unknown Error **
    	**IOSTAT = $d
    	reply port
    	message sent
    ==================================
    	dos pkt: 1007 = Action_end
    	do_scsi()
    	opcode = 10, len = 0
    
    

    
    re .3
    
    problem 1
    
    	I don't know why the ICD controller will not work. I suggest you
    try setting TAR to write smaller records.
    
    problem 2
    
    	Yes, I know about the CBM 2090(a) SCSI direct problem. I forgot
    to add the code that fixes the problem.
    
    problem 3
    
    	The GVP controller is what I use, so I would expect it to work.
    The trace you posted said the drive was reporting the error. I'll
    add some more debugging code tonight.
    
    		Steve Peters
    

    
    	I have uploaded a new tk50-handler with sources. The archive
    includes everything to build the handler using SAS C. 
    
    	I have fixed one little thing, but I don't think I fixed any
    problems. The problem I did fix should give me a little more info.
    
    	I'm still looking for the fix for the CBM 2090(a).
    
    	One last thing, do you boot the system and load the driver with
    a tape in the drive ? If not, try it this way.  There maybe a bug
    in the new media handling. I'll work on this section Tuesday night.
    
    		Steve Peters
    

    this is my experience with the previous version...  I booted with and
    without the tape loaded.
    I will give the new version a try.  md
    ----------------------------------------------------------------------
    
Steve,

I tried the tk50-handler last night.  Whenever I tried to mount the 
tape I got an immediate exception.  I removed the tape drive from the
SCSI bus and tried mounting with the same results except
this time there was no debug window.

Here is my hardware setup:

A2000 with GVP A3001(28Mhz) 4Mb 32bit ram  4Mb 16bit ram, GVP Series
II SCSI controller.  I have the last LUN/DISK bits set on SCSI addr 0.
If I do not set these bits I am unable to boot because the GVP II hangs
when it "touches" the tape drive during "polling".  I normally startup 
with "SETCPU FASTROM CACHE"(instruction and data caches on).  I disabled 
the A3001 and got the same exception(s).  I also booted the A3001 with 
no SETCPU command and that GURU'd too.  

I use SRT so I am able to continue using the system after an exception.
If I "suspend" the task that caused the exception and try the mount
command again the system replies with "device is already mounted".
If I do not suspend the task and try a "tar cvf..." I get the "task
held" requestor and the file I tried to tar got corrupted.  I chose
to reboot after that.

Here is the exception:

EXCEPTION=4  TASK=0029F8C8  PC=C OR 8  SP=002A091C(varies) SSP=0000FFB8
EXCEPTION=32 TASK=002A7688  PC=083400FC
  the task is "TAPE"
  the fields labeled "a:" and "d:" are usually filled with 0's although
  on a couple of occasions there was data.  I took a snapshot of the 
  exception requestor if you want to see it.
  
System info: 

             Kickstart v34.5  I use most ARP commands and the ARP library
             Workbench v34.2
    Executive Library  v34.2
    Intuition Library  v34.3
    Graphics  Library  v34.1
    DOS       Library  v34.3
    
Debug window information:

    waiting for DOS startup
    found task
    parsestartup()
    intuition open
    create port
    createstdio
      device gvpscsi.device unit 1
    reply port
    message sent (no messages after this)
    
The tape drive I used was a TK50Z-FA.  One of the ones without the external
switches, but its SCSI module is fairly new.(I checked when I verified its
SCSI address.) 

mark

    
    Did some testing last night with the new version (it was the same size
    as the first one???).
    
    I found that the TK50 will read and write as long as the total number
    of bytes is small enough.  After a lot of reboots I found that the
    magic number seems to be somewhere around 15360 bytes.  If the total
    bytes to be written is less than that it works and can be read back. 
    If the number of bytes is greater then it hangs the controller/system.
    
    In testing I tried block counts from 1 through 10 and 20(default) the
    results are as follows:
    
    	block count	# of blocks written	total bytes
    	     1			30		15360
    	     2			5		5120
    	     3			10		15360
    	     4			3		6144
    	     5			6		15360
    	     6			5		15360
    	     7			2		7168
    	     8			2		8192
    	     9			4		18432
    
    Every now and then it would go beyond the 15360 point but appeared to
    be a mulitple of the above byte count dependant upon the block count
    (ie using -b2 it wrote 70 blocks which is an even multiple of the
    above).
    
    The testing was done with the tape loaded at boot time and also
    unloaded at boot time.  Two different cartridges were used as well.
    
    Hope this helps.
    
    wayne
    

    I downloaded the latest version of tk50, booted a vanilla system(no
    A3001, no background tasks, no WB, just a shell) and I continue to get
    the exception. Hmmm... 
    
    mark
    

    
    re .3
    
    Wayne,
    	In both the 2090A and GVP cases the log is pointing to the same
    thing. An IO status error 2A.  This error is a SCSI phase error. This
    type of error is caused by a bad SCSI bus ( length, termination, two
    devices at the same ID ) or a firmware bug. I'm going to check the
    current TK50Z revision. I seem to remember a ECO about a month ago.
    
    re all
    
    	The TAR program and drive seem to use a lot of stack. Please post
    the stack size you are using. I have been using 40,000. I just finished
    saving and listing 30 MB of data without a problem.
    
    		Steve Peters
    
    P.S. I'm using a AMIGA 3000 with a ( old ) GVP controller for the tape
         to test on. The GVP controller has 2 disks and the tape.
    

    
    Steve,
    	The TK50 has one of those termination blocks on the 50 pin
    centronics connector.
    	In each of the cases first reported the tk50 was the only device on
    the controller (ICD 2000, GVP-II & 2090A.
    	I use a stack of 100000 all the time (btw the stack in the
    mountlist is 4000 is that important).
    	As mentioned in a previous note the write works fine as long as the
    total amout of data is less than 15360 bytes.  One thing I forgot to
    mention was the sound, as the writing was taking place the sound was
    that of advancing the tape a small amount (writing?) followed by a
    rewind then a longer write, rewind, longer write,.... until it failed. 
    With each iteration of write the tape advance period got longer and
    longer.
    	I shall remove the bus termination and see what happens.
    
    wayne
    

    
    Late night update.
    
    I removed the terminator block and was able to write to the tape
    without any hanging problem.  I test -b20 (default), -b10, -b1, -b40
    and even -b63.
    However reading is another matter, at -b10, -b20, -b63 the drive hangs
    on the first read command (rewind works great).
    When set to -b1 (writing takes forever) the read just kept repeating
    the first file over and over (the file is 180 bytes long), after 6
    times I ^C'd it.
    I will take the tape into work to see if it is readable.
    
    wayne
    

    
    
    re .11
    
    	I think I understand the termination problem you are having.
    You should look at the TK50z SCSI board to see if it has internal
    termination ( I use the internal terminators ). The external
    ( block ) termination requires that the drive or enclosure supply
    termination power. Your box may not supply it.
    
    	As for the -b?? switch, I don't use it and I have not tested
    it.
    
    	As for read problems, are you extracting files or listing the
    TAR set ( x or t ) ?  Can you post the log information when the read
    fails ?
    
    		Steve Peters
    P.S. sounds like we are making some progress ...
    

    
 Okay, here's my report on the Cypher used with the GVP series II card
    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

I get the same thing writing to tape except the Unhandled Packet is "16"
then.
    With Tar I recieve "error reading/writing tape, data probably corrupt"
    requestors.
  						   Ed
               

    
    Steve,
    	I had removed the internal resistor to allow chaining and moved to
    the external terminating pack.  After last nights testing I had kind of
    come to the conclusion that the external pack was not doing the same
    job as the internal termination.  The next test is to replace the
    internal termination and try it all again (now to find those darn
    little things).
    
    	I have read the tar created last night on my mvII.  However about
    halfway through the tar file it gets an error which makes tar go nuts. 
    Perhaps this is a write error due to improper termination.  I shall try
    again after the internal resistors are in place.
    
    	On the read hang, I do not have the info at hand, however I was
    using 'tar -tftape:' to list the tarfile and also tried 
    'tar -xftape: filename' to extract a file in both cases a read was
    issued the tape moved and the hd lite went solid and the system was
    hung.  The read command did not complete.
    
    	I tried the TK50 on the 2090A again and upon issuing a tar command
    received a requestor indicating that tape: was not online.  The debug
    window indicated a status of 2A (I think).  I will retest and write
    down the information.
    
    wayne
    

re .13
Ed,
	The QIC seems to have the same error reporting bug the TK50-handler
did. I'll fix the bug and upload a new QIC handler tonight.

		Steve Peters

Dealer told me both the internal and external chains needed to be terminated.

-steve

>                       <<< Note 4577.13 by SHARE::DOYLE >>>
>                                 -< QIC_handler >-
> 
>     
>  Okay, here's my report on the Cypher used with the GVP series II card
>     debug output.
> 
> 
>     

[stuff deleted]

> init_write()
>   do_scsi()
>     opcode=1A, len=3
> ** Unknown Error **
> ** IOSTAT = $d

Looks like the "$d" is a C bug - should be "%d" for decimal translation of
IOSTAT...

john

    
    Steve,
    	I put the internal termination back on the TK50 and returned to the
    problem of hanging on writing.  Something else I have found is that
    sometimes when the TK50/system have hung that I cannot reboot until I
    power cycle the TK50.
    
    	I also readdressed the TK50 to Unit 0 and tried the read/write
    stuff, got hanging on both read and write when connected to the ICD
    2000.  Connected to the 2090A I now get a 'SOFTWARE TASK HELD' error on
    mounting the drive.  As I recall from other documentation is not the
    2090A unit addressing different from real world (ie: if the drive is
    unit 0 you should tell the 2090A that it is to use unit 3 - or
    something like that?).
    
    	wayne
    

    
    re .13 , .17
    
    	Yes, John the $d needs to be a %d. That is the fix I was talking
    about. I need that error code to tell whats going on.
    
    re .18
    
    	The CBM 2090(a) requires you to add 3 to the SCSI ID. It assumes
    unit 1 and 2 are the ST506 drives. The SCSI drives start from 3 up.
    The controller is SCSI ID 7.
    
    
    		Steve Peters
    

    I broke my system down to just the A2000, the GVP series II with
    my HD and TK50.  I am still getting an exception (illegal instruction)
    upon issuing the mount command.  John, are you able to mount the TK
    with your Series II?  Any suggestions, anyone???????
    
    md
    

    
    With the TK50 addressed at unit 0 and the mountlist specifying unit 0 I
    was receiving the Software Task Held requester.  I changed the
    mountlist to specify unit 3 while the TK50 was addressed at 0.  This
    time the mount did not crash however it did not complete.  The tape
    moved a little during the mount command and that was all.  The system
    was still running but the tmount was stuck.
    
    I put the TK50 back on the ICD 2000 and tried a larger stack in the
    mountlist, made no difference.
    
    I tried various -b sizes in tar and found that it hangs on all but -b1
    (single block), which is extremely slow.  All the other block sizes
    cause a complete system hang when reading, but work just fine for
    writing.
    
    wayne
    

Steve,

I tried this last night on my A3000 using CBM's scsi.device and it wouldn't
even mount.  "tmount tape: from mountlist" hung the system.  I'm not sure
if arp mount even works with 2.0 on the A3000.  Does anyone know for sure?

I didn't try it under 1.3, but I will tonight...

-steve

BTW BRU continues to work great...

re .20,.21,.22

	The Tmount command I incuded is the latest ARP mount command.
I use it with Amigados 1.3 on my 3000 and have never had it gruru. I have
had it hang when things were set-up wrong.

	As for the 2090(a), I still think I'm missing a special work
around that is required to make SCSI commands work on these controllers.

	As you may have guessed, I didn't work on this last night. The
AMIGA meeting when a little late. ( It was a great demo ).

		Steve P.

Steve,

It worked fine on my A3000 under 1.3, but arp mount seems to be hosed under
2.0.  Wouldn't work properly for any device I tried.

Any idea where I can find documentation on what mount does?  I've got the
1.2 RKM's and a 1.2 AmigaDOS manual, but I can't find anything at all in
these...

-steve

Re: .24

>Any idea where I can find documentation on what mount does?  I've got the
>1.2 RKM's and a 1.2 AmigaDOS manual...

In the last third of the Bantam AmigaDOS manual there are descriptions
of all the AmigaDOS data structures.  In particular, there are descriptions
of what device node entries look like in the system's device list.

Mount creates those entries for devices not built into the system.  In
fact, if you write a program to read those entries, you can recreate
the mountlist entry from them.

See the program TLE""::UPORT$:[RMEYERS.TRADE.AMIGA]MOUNTLIST.ZOO
for details.

I believe that the expansion.library contains some special routines
used by Mount to create the device nodes.  If you are planing to
write your own Mount command, you should investigate such stuff.

    I have access to a TK50Z, that I would like to try to use to backup my
    Amiga.  My initial problem is where to get a cable to go from a DB25 to
    the 50-pin centronics on the TK50Z.  Is this a standard cable?  Could
    someone give me a pointer where I can get one, and a price if possible?
    
    			Thanks.
    

    Hi Dave!
    
    I haven't found one yet, but I was told that any MAC store should have
    one for about $30. Now to find a MAC store...
    
    John

    Yes, that's a standard MAC SCSI cable.  Memory Location also carries
    them.

MAC stores tend to want more like $50.  I got mine at the Amiga store
System Eyes in Nashua for $35.

-steve

re                <<< Note 4577.29 by BARD::mcafee "Steve McAfee" >>>

> MAC stores tend to want more like $50.  I got mine at the Amiga store
> System Eyes in Nashua for $35.

	I paid $20 (+ $1 sales tax) at NEET in Lowell

	New England Electronics Technology, they advertise in  
Computer Happenings, or some such - the free tabloid thing that toutes 
PC compatibles & Macs (don't they ALL ?).

	Reg

    Thanks for the info that the cable was a standard MAC cable.  When I
    initially checked out MicroCenter, I looked in the general accessories
    area and couldn't find any cable with a 50-pin centronics connector. 
    So today I checked out the MAC specific area and found the required
    cable.  It is only a 2 foot cable, and I got it for $12.00.
    
    In a day of 2 I will be giving it a try.  I need open up the system to
    attach an external SCSI cable to the Hardframe 2000.

	Hi,
	   I also have borrowed a tape drive from work.  The cable I need is
	a 25 pin ribbon (to connect to the 26 pin header of the HardFrame)
	to a MAC style DB25 female connector (hopefully mounted on a plate).

	Anyone know where I can get one of these?

						Thanks,
						Gail

    re .32	Cable for Hardframe
    
    I also have a Hardframe 2000.  I could not find the cable anywhere, but
    the doc file with the Hardframe software did a resonable job of
    describing how to make one.  I do not consider myself a hardware
    wizzard, but I did make one that does work.
    
    I bought the 25-line ribbon cable and DB-25F that can be crimped onto a
    ribbon cable from Radio Shack. I had more difficulty locating the
    26-pin connector.  I bought it from a computer parts supplier called
    "Hughes Peters" located here in Columbus, Ohio. They charged me $8.00
    for it, which I thought was kind of high.
    
    The only non-obviuos thing to note is that when attaching the 26-pin
    connector to the 25-line ribbon is to make certain that pin 1 on the
    connector is attached and pin 26 is NOT connected. Then attach the
    DB-25F making sure pin 1 on the DB-25F maps to pin 1 on the 26 pin
    connector.
    
    When attaching the 26-pin connector to the Hardframe pin 1 for the
    26-pin connection is in the same orientation as pin 1 for the 50-pin
    connector.  Don't forget to remove the 3 resistor blocks from the
    Hardframe, before using an external device.
    
    I just hooked mine up last night.  And the DB-25F is currently just
    hanging out the back of my 2000.  So if anyone knows how I can get a
    back plate that has, or can attach, a DB25 connector, please let me
    know.

    Wow, I actually got it to work for me on the second try.  Yesterday, I
    cabled up a TK50 to my A2000 with a Hardframe 2000 SCSI controller, and
    was able to use TAR to save the entire 15MB of files from a 40MB
    partition.  I also successfully restored a single file (I used bdiff)to
    make sure the restored file matched the original.
    
    The reason it did not work on the first try was that I had the SCSI ID
    DIP switches on the TK50 set incorrectly.  There is nothing on the
    diagram to indicate whether dark means down or up.
    
    I have a small test partition, I will try a full backup and restore of
    about 7MB, in the next couple of days and report the results.
    
    Are there any specific tests that I should try?
    
    The TAR program is new to me. Is there a way to do wildcarding of
    filenames and directories?  Also, how can I restore files to somewhere
    other than the orginal partition and directory?

	David,

	   Thanks for informative response!  Could you tell me what
	version of the HardFrame ROMs are you using?  I'm currently
	at 1.5 and have been considering whether I need to upgrade
	to the new 1.9 ROMs.

	   I would also be interested if anyone knows where to get a
	mounting plate for the DB25.

						Thanks All,
						Gail

    still considering eh?  I recently got mail from them announcing
    the upgrade.
    
    The next computer fleamarket isn't too far off, I think it's April 6th.
    
    Dave

    I am not sure which version of ROM I have, but it is definitely not the
    latest 1.9 ROMs.  My board is over 2 years old, and has the original
    ROM.
    
    I am not sure if I will upgrade or switch controllers.  I am a bit
    concerned if what the new ROMs offer is worth $50 to me.  I don't
    like the fact that AMAX II cannot use a Hardframe disk.  And why
    didn't Microbotics provide the external connector like many others do.
    For the most part I think that the Hardframe has served me reliably,
    and when I got it, it was one of the first controllers to support
    autoboot from a FFS.  So even though I like the Hardframe this $50
    upgrade may mark my switch.  I have noticed that Commodore has reduced
    the list price on the A2091 to $199.

    I ran a test for a backup and restore of approx. 5MB.  First I backed
    up the partition, I then reformatted the partition, and finally
    restored from the TK50.  All the files were compared and matched copies
    I had in another partition.
    
    One observation, it definetly took much longer to write the TK50 than
    to read it.  Does the debug window slow things down?  Are there ways to
    increase the speed?
    
    If I attempt to use the INFO command on TAPE: I get the following
    display in the debug window.
    ================================
    DOS pkt:  25 = UNHANDLED PACKET!
    reply port
    message sent
    
    My ASHELL window just displays the heading line, with no additional
    data or error message.
    
    Should the INFO command be legal?
    
    Steve, are you planning any modifications?  Can I turn off the debug
    window?
    
    I will make a test with additional disk buffers and check the time.
    

    This run I put the clock to it.  The partition had about 4.7MB in 15
    files.  The backup took about 20 minutes.  Listing the file from tape
    takes about 3 minutes.  And the restore to an empty partition takes
    about 5 minutes.
    
    Using addbuffers seemed to have no significant effect on the backup. 
    But it really gave me trouble on the restore.  With more than 20
    buffers the restore would start normally, but the entire system would
    freeze.  No error messages, no guru, just hang.
    
    I have a PD utility called DEVS that shows info for each mounted
    filesystem.  If I run this utility after the mount of TAPE, I get some
    garbage in the CLI window, some normal output, then the "Software error
    task held" requestor.
    
    That's it for now.

    
    I note from earlier replies a reference to "switches" on the TK50Z.
    
    I have a TK50Z that doesn't have switches (borrowed).
    
    In the TZK50 manual it refers to W8-12, but the drawing of the 
    board shows P1-P5.  It also says that the default SCSI id= 0.
    Anyone know how to set the SCSI id without the switches?
    
    I assume jumpers, are they on the TZK50 or the TK50?
    
    Thanks for any help, so far I somehow managed to rice DH0:.
    Oh by the way, anyone else use Abackup?
    
    Dennis

Re .38:

Disk-to-tape backups typically do take significantly longer than the subsequent
restore operations, since in the first case the files are fragmented and
require multiple seeks per file, and in the second, all files are by definition
sequential. That doesn't rule out additional *abnormal* delays, of course. If
you want to check it out, you could always try another backup immediately after
restoring from tape; the difference in the speeds of the backup and restore
operations should then be significantly decreased (but nonexistent).

Cheers,
	Bob

    
    re .38 and others
    
    
    	The Unhandled DOS packet is due to the fact that the handler
    only supports the minimum DOS packets to work. I also would 
    guess that that is why info doesn't work or your other program
    that displays handlers.
    
    	I will be working on the tape support software as long as the
    need and requests continue.
    
    	1. I'll create a version that allows you to close the debug
    	   window.
    
    	2. I'll look into DOS Packet 25 and see what can be done.
    
    	3. Write performance increase - I think I know the cause.
    
    
    
    		Steve Peters
    

>     
>     
>     	The Unhandled DOS packet is due to the fact that the handler
>     only supports the minimum DOS packets to work. I also would 
>     guess that that is why info doesn't work or your other program
>     that displays handlers.

When you use the DOS INFO command, it sends an ACTION_INFO (or something
like that) to each device's handler to get info like total blocks, free 
blocks etc. tape-handler does not deal with those packets.

john

    re: .42
    
    Thanks to John and Steve for the updates to the tape-handler to allow
    use with the TK50Z. 
    
    If I ever get a cable (soon I hope) I'll get a chance to try it with a
    Supra WordSync interface and let everyone know whether it works...
    
    John

    
    I got lucky on the SCSI ID #, I tried 1, that's it. (verified by
    supraformat, it sees it, as a seagate st225).
    
    My tale:
    
    When I try 'tar cvf tape: dh1:, it prints out about three files,
    (have tried with one specified file, same) and then a requestor
    pops up.  The famous, "An error has occurred while trying to write
    to the tape.  Tape data is probably invalid."
    
    On the debug screen, I see the rewind packet suceed, see:
    
         DOS pkt 87   ACTION_WRITE
         tape_write()
         do_scsi()
         opcode - 0A,  len=10240
         stat 0  length 2273048
         * length != actual **
         reply post
         message sent
    
         DOS pkt 1007 = ACTION_END
         do_scsi()
         opcode = 10, len = 0
         stat  0    length  0
         reply post 
         message sent
    
    On the shell, the message, 
    
         "tar:  tape::  write failed, short -2287472 bytes"
    
    If I use DHx:, and then try a tar tf tape:, no files are listed,
    although the drive looks and sounds like its reading.
    
    I've tried Stacksize's of 40000 and 100000.
    
    I've tried various -b n.
    
    I even set the 1024 in mountlist to 512 once.
    
    Config:
    
    A500 + A501 + SupraDrive SCSI interface with 2M ram + 20M Miniscribe.
    
    It doesn't seem to be able to write.  Curiously the Supra driver is
    called Supradirect.device.  I also tried a 'copy' command, same thing.
    
    Version of Supra is 1.09f, by the way.
    
    ????
    
    Any ideas?
    
    Is there any particular way that tapes should be initialized?  Or does
    tar do that itself?  Both of the tapes I have, are from VMS systems.
    Problem?
    
    Oooh, I just remembered, I have a TK50 tar tape, written on an Ultrix
    system, I'll try to read that.  Meanwhile, any help greatly
    appreciated!
    
    Last but not least, let me add my thanks to you, Steve, for all your
    hard work.
    
    Dennis
    

    
    
    	Well I've tried both the TK50 and the QIC handlers with my
    Hardframe and Teac MT2-ST45S and both crash the Machine with 
    8700004.xxxxxx or something like that...
    
    This crash happens when the debug-window opens...
    
    I didn't get this problem with the debug window from the modified
    version that John had worked on BUT all I got was a IO error 45
    (SCSI Phase Err)
    
    Has any one tried the MT-handler I upload sometime ago...
    
    This is now the only handler that works with my setup and also give
    you a working INFO command...
    
    I've done a complete backup and read the tape after a reboot...This was 
    my problem with the BTNtape handler that it would do the backup but
    after a reboot the handler couldn't re-read the tape....
    I've tried the very latest BTNtape from DrBob and I've now got back to
    the IO error 45 SCSI Phase Error
    
    Tabu also seems to work for me...
    
    
    As of yet I haven't tried to restore But tonight I'll try and see if it
    works..(MT-handler)
    
    The way i got MT to work was to change the Flags = 0 to Flags = 1 in
    the MountList....
    
    
    	Steve...

    I am still unble to get the TK50 handler to mount without a guru.  Even
    booting a vanilla a2000, no accelerator, basic WB1.3.  The GVP
    controller hangs on polling or if it manages to boot up the hard drive
    the arp mount command produces the guru.  GVP tech support is no help. 
    They say, "it should work".  I'll figure it out when I have more time.
    
    md

	My setup:

	B2000, supraRAM 2000 as first auto-conf board, a2090A with two st506
	drives (booting from one of them) and bridgeboard.
	
	I've tried different tape drivers from the net (BTN, MT, TABU
	and Steve's tk50-handler) with no luck!

	All drivers claims an I/O error 42 when DoIO a SENSE UNIT READY command
	only Steve's handler looks different, its DoIO() never returns, and the 
	only way to regain control is C-A-A!

	I've tried the TK50 here in office and it works fine on a 3100.

	I'm quite sure now that a2090(A) isn't good for SCSI-direct drivers :-((

	Let's hope in the future !!

	Roberto.

I can't  get  the  handler to work with my Hardframe. I have an A2000 with a
Quantum and a Seagate attached via the 50 pin connector internally. The last
drive  is  terminated.  I made a straight thru 25 conductor cable, attaching
one  end to the hardframe's 26 pin connector and the other to a DB25 out the
back. Then I use a 25->50 pin centronics style cable to the TK50.

Here's where  it  gets  interesting:  With  the  terminators  still  on  the
Hardframe, I can mount the tape, but when I try accessing it, I get a 
"Tape not ready" error, also the $d.  When I remove the Hardframe's
terminators, the TMOUNT command hangs the system. BTW, I had to copy the
HardFrame driver from it's normal Expansion drawer into Devs AND rename
it to HardFrame.device. If I didn't rename it, I got the GURU!

I took the case off the TK50-FA, to check the terminators. I didn't see
any empty sockets, but I don't know exactly where to check. I'm not sure
there is a problem with the tape drive though. I bought a NEXUS controller
and got it to work with it's disk ".device".  The tape seemed to come out
fine.  However, the controller uses the CPU, and brings it to a standstill
when accessing the tape.  It causes noticeable lag and character jumbling
on  disk  accesses.  Thus, I'll be returning it.

Does anyone have any suggestions???  I noted that one or two replies were
from HardFrame owners, any insights?

I would like to resolve if it will work with the HardFrame soon, as I'm
planning on returning the NEXUS this weekend, and It would be nice to 
know if I need to get the GVP while I'm down there.

Thanks for any help.
Gail

    
    Well my saga still continues....
    
    I though that I had a working tape handler (MT-Handler) But now after
    leaving the tape for a couple of days I find I can't read it...
    
    I've ordered 2 new tape cassesse and see if this helps...
    
    Next I try TABU and leave the tape for a couple of days and see if I
    have any problems ....
    
    I also try with MT-Handler and leave this tape for a couple of days and
    see if I can read the tape....
    
    My HardFrame is at REV 1.9 and is in an UNBUFFERED MonAMI 3-slot box...
    
    I might just give a ring to Microbotics and see if they have their tape
    handler software ready..YET..
    
    	Steve G

I just got a TK50Z to try on a stock Amiga 3000. No GVP controller. I run only
2.0 at this point.

What I really want is to create tar files on it (I already have a couple
of tar programs). What I need is a tape: handler. Does anyone have one
of the numerous ones that appear to be available working in the above
confinguration?

Could someone post a summary of available tape handlers?

	<mike

    re: .49
    
    I don't quite understand your statement about copying and renaming the
    Hardframe driver. On my system the Expansion drawer is 100% empty. And
    the file Hardframe.device does not exist in any normal AmigaDos
    directory.  I assumed that it was either in the controller ROM or the
    Ridgid disk blocks.
    
    As I indicated in my previous reply, the TK50 handler and the tar
    utility has worked for me.  I did remove the 3 termination resistor
    packs from the Hardframe.  I also have 2 internal drives UNIT 0 is a
    Maxtor LXT-200 200MB 3 1/2" mounted on the Hardframe, UNIT 1 is a Seagate
    ST-296N 80MB 5 1/4" half height.  The TK50 is set to UNIT 4.
    
    While the TK50 handler has worked for me writing the tape seems to be
    very slow, and if I have over 20 disk buffers the tar restore operation
    seems to hang after partially restoring the data.
    
    I have also tried using the MT handler.  The mount seems to work fine,
    I can even use the CLI info command. I like the fact that the CLI
    diskchange command can be used to rewind the TK50.  But when I use tar
    to write the tape, it seem to write some data then stops with a tar
    write error message, and I cannot read any data from the tape. A
    previous reply stated that they got the MT handler to work with the
    Hardframe, would that individual please indicate what software they
    were using to achieve success?
    
    My report card so far with the Hardframe to TK50 connection
    
    	TK50		Some success
    
    	MT		Not useable with tar
    
    	BTN		Yet to be tested
    
    We Hardframe users must unite to solve this backup problem.  I would
    defintely be willing to talk with others over the phone.  I am
    currently at a customer site during the day so I cannot be reached
    by DTN, but my work number is (614)293-3494 in Columbus Ohio.  My
    home number is (614)864-3125 and if I am using the modem try
    (614)864-0975.

re: .50

Mike,

Steve Peters version seems to work on my A3000 under 1.3.  However the
mountlist only works with Arp mount which doesn't work under 2.0.  I
don't have enough documentation about mount to make the changes myself
or I would.

I haven't wanted to bring anything significant home from work yet and
BRU works great for backups under 2.0, so I haven't pursued it any further.

If you find one (or alter Steve's to work) under 2.0 please post it!

regards,

steve

Steve Peter's driver is in TK50.LZH, right? From looking through that, it
seems to expect a GVP scsi controller. Are you doing something that's
not obvious (to me, anyway)?

HDBackup just seemed to hang. Haven't tried BRU yet. If you could post the
command line you use, I'd appreciate it. However, moving data is the real
reason for the tk50 being on the 3000.

	thanx,
	<mike

    re .54
    
    	The TK50Z driver I worked on uses the mountlist to find the
    name of the SCSI controller driver. For a A3000 just change the
    mount list entry.
    
    		Steve Peters
    

re .55

Ah, so I did identify the driver correctly.

Doesn't it also expect the arp mount,which is reported as not working
under 2.0?

	<mike

    re: .49
    
    I'm a little curious about your comments on the Nexus controller.
    I just replaced my HardFrame with a Nexus.  I don't have any tape
    drive to test on it at the moment, but I certainly have not noticed
    any CPU stalls while accessing my disk drives.  Do you have any RAM
    on the Nexus?  Did you try the NexusTape driver?  I am running a
    68020, I'll try some experiments running the system in normal 68000
    mode...

>    I'm a little curious about your comments on the Nexus controller.
>    I just replaced my HardFrame with a Nexus.  I don't have any tape
>    drive to test on it at the moment, but I certainly have not noticed
>    any CPU stalls while accessing my disk drives.  Do you have any RAM
>    on the Nexus?  Did you try the NexusTape driver?  I am running a
>    68020, I'll try some experiments running the system in normal 68000
>    mode...

My setup is a stock A2000 (68000 cpu) with a Microbotics 8up DIP memory
board (populated to 6 meg).  When I had the Nexus board in, that was the
only other internal board. Oh, forgot my flicker fixer. I think I have an
older Nexus board (it only has room for 4 meg of Simms).  Anyway, maybe
I was doing something wrong. If you have any suggestions I would appreciate
them.  What I noticed was the following. I had one screen/window running
Atalk3 dialed into work, another running Diskmaster, and in the third
an AmigaDOS shell. From the shell I invoked Quarterback tools and told
it  to  scan  one  of  my  disks  (I forget which now) for bad files. Then I
switched to my window to work.  Whenever I issued a command or even hit
return, the response was dismal. If I did issue a command, the output
came back garbled (I remember doing a $show terminal command on the VAX).
If I just hit a few returns with no command, it could keep up and would
string them on random spots on the screen.

Now I'll admit that QB Tools was pounding the disk, (diskmaster was idle),
but it seemed the disk activity was getting all the computes. Maybe it's
because I don't have the horsepower you do?  I guess what concerns me is
that this might indicate an inability to multitask effectively. I regularly
have a download from work going in the background, while playing a game, etc.  
BTW, I'm one of those who has had very good luck with QB Tools. I have nothing
but praise for it, but I guess it could be compute intensive.

I did get the TK50 handler of Steve's to work with it, but I had to use
the standard NEXUS device, NOT NexusTape.device.  I could not get either
the handler or the included Flashback to work with my TK50 and the 
NexusTape.device.

I am guessing that one of the following is my problem:

	1.   I didn't give it enough of a test to get a good feel for
	     its response, or

	2.   I should have set something (maybe changetaskpri, but it
	     doesn't seem I should have to) differently, or

	3.   I have an older version of the board, or

	4.   I noticed it because I don't have enough CPU.

I would be VERY interested in the results of your tests. I DO like the
controller and software package, so if you have any suggestions, please
let me know.

Gail

    If you do not have RAM on your disk controller, you should try to place
    a memory card into a slot in *front* (to right) of the Nexus (or
    HardFrame).  Otherwise the disk buffers will be allocated from CHIP
    RAM, and performance will suffer.  I think this is mentioned in the
    HardFrame's ReadMe file.  I have 2MB installed on my Nexus, so its
    buffers go there.
    
    The built-in serial device has no hardware character buffering, so it
    can easily drop characters under load, particularly at high speeds.
    I've noticed occasional missed characters (@19,200 baud) during I/O
    on my HardFrame, which is also documented by Microbotics.  Seems about
    the same, perhaps slightly less frequent, with the Nexus.
    
    As a quick experiment, I've started DiskPerf and DiskSpeed programs
    running in the background as I enter this reply.  With both speed tests
    hammering on my Nexus disk, I did a series of screen refreshes with
    *no* apparent loss of characters, etc.  I'll have to reboot to test
    while running in 68000 mode, and report back later...
    

    Well, even running the standard 68000 processor, my system seems to
    be quite happy with Nexus.  Disk performance is down about 25%, but
    VLT keeps up with output just fine during disk I/O.
    
    Some of the symptoms you describe really sound like a task priority
    problem to me.  According to Xoper, my VLT task is running at priority
    0, along with the rest of my "normal" tasks, shells, etc.  I do notice
    that the file system processes run at priority *10*!  Perhaps QBtools
    puts a lot of work via the file system process, and THAT was swamping
    your system...?  Did you try a similar test using the HardFrame?

re arp mount:

The tape-handler requires the ARP mount which recognizes the STARTUP parameter
in the mountlist. Since STARTUP is how tape-handler gets it's vital information,
it's kinda dependant.

Now the source toi tape-handler is included so you could always modify it to
get the info from other CBM supported mountlist keywords. I never did like
the code to get the STARTUP stuff anyway - UUUUgly!

john

re:.55

Yes tk50.lzh needs arp mount.  Under 1.3 though it works fine.

As far as getting bru to work, all I did was:

1. edit s:.brutab to move tape: to the top of the file, change the scsi id
   the correct one (0 in my case), and set the size (90000*512?).

2. set the stack to at least 40000

3. There is a scsi query command someone posted to usenet which I use to
   make sure the drive is ready.  I think this is in

	tape::amiga:[amiga.hardware]scsitest.lzh

   For some reason executing this twice before running bru makes everything
   go smoothly :-).

My backup script looks something like:

-----------------------------------------------
.KEY dev
.BRA {
.KET }

stack 40000
scsitest >nil: scsi.device 0
scsitest >t:bru_{dev}.log scsi.device 0
date >t:bru_{dev}.log
bru >t:bru_{dev}.log -ec {dev}:
date >t:bru_{dev}.log
------------------------------------------------

This is totally from memory so every line could be wrong :-).

I don't think I have HDbackup.  I don't believe it was ready yet when
I purchased my A3000.  Can one get this from the dealer now?  It just
uses bru right?

regards,

steve

    
    RE:.59
    
    I have my HardFrame in the first slot and then an 8-UP with 2-megs
    (this is a MonAMI 3-slot box attached to an A500)
    
    With the RDPrep soft you can set up a small buffer size (Mine set to 5)
    and the have Addbuffers DHX: YY after the FastMemFirst to give you 
    fast mem buffers
    
    
    Or am I doing Something wrong here...???!!!
     
    

First, I found a copy of BTN 2 last night. It mounts and runs just fine.
The one problem is that the WB software I'm running is sending
ACTION_IS_FILESYSTEM packets to the handler, then returning errors when
it bounces them as unknown packets. Just an annoyance, which has been
reported to the author, and will be reported to CBM.

The 2.0 mount command understands "Startup" in a mountlist. That's how the
BTN2 handler gets information. When I try using that with the tk50 handler,
it dies immediately.

Thanx for the information on BRU; I'll give it a try over the weekend,
but expect that it will work fine. HDBackup has come and gone from
various releases of the WB. I'm running an as-yet-unreleased version
of 2.0 KS & WB.That's mostly why I don't use 1.3 any more.

	<mike

	Steve,

	In an effort to get the TK50 handler working, I'm trying
	one of the new GVP SCSI/HARD Card/RAM boards. I set everything
	up as per the instructions in the archive. (I also took the
	ARP.library from the CLOCKDJ archive since the handler needed
	it.)

	When I do a TMOUNT TAPE:, the debug window comes up ok. A couple of
	seconds after it comes up, I get a popup system requestor with the
	following:
			gvpscsi.device: unit 005
			Unexpected Status  $4E/$20

	If I click the requestor away and try for instance, TAR TF TAPE:
	my CPU maxes out and the system hangs.

	Any idea what's wrong?  I do have the tape set to id #5.

	Thanks a lot, 
	Gail

    
    
    	For all of you with a TK50Z on the AMIGA I have the first
    prototype of a new Backup/Restore program. The program can
    read VMS backup savesets. The files are restored to the current
    directory. If the VMS file are in stream_lf format the data is
    usable on the AMIGA. A readme file is included in the LZH file.
    
    	This is only a prototype. Many of the features are disabled.
    If you try the program PLEASE send me mail on how well it worked.
    Source will be available then the program is complete.
    
    		TAPE::AMIGA:[amiga.hardware]vback.lzh
    
    	This is a new version that was uploaded today.
    
    		Steve Peters
    
    

    re: VMS Backup for Amiga
    
       I gave it an intial try.  The requester to provide the setup info
    does not provide enough space to specify HardFrame.device.  I did
    locate the file s:Vbackup.setup, so I used EMACS to correct it.
    I restarted vback and tried a restore.  It did access the tape and it
    correctly identified the volume name. But it then failed with the
    error:
    	OPEN error 113
    
       Does this indicate what the problem may be?
    

    
    Well, I didn't have a lot of last night.  I put a tar file from a
    DECstation on a tk50 tape and brought that home.  btnv2 wouldn't
    read the tape at all.  Not sure what the problem was but it said
    something about invalid length.
    
    Then I tried to use Steve Peters version and that seemed to be
    working but hung in the middle so I rebooted.  Got the dreaded
    CHECKSUM error on my work: partition and couldn't write to the
    disk to fix it.  Anyone know what the commodore supported way
    of fixing this is?
    
    Anyhow, I could still read the disk so I BRU'd the whole thing to
    a tape, reformatted and restored everything from the tape.  Only
    problem I had there was that bru wouldn't restore some files.  I
    suspect it might be due to the file protection on the files when they
    were archived.  Mostly directories or things in the root of the
    partition.  I wrote down which directories it was failing
    to create and then created them by hand and ran it again and it
    filled those dirs.  After two passes I got most everything back.
    If anyone knows how to make bru work easier please let me know.
    
    -steve

    
    re .67
    
    	Open error 113 does mean a lot. I'll have to double check it
    tonight, but I think the saveset name was too long. What was the
    saveset name ?
    
    	P.S. this error is pointing to my code not the tape drive.
    
    		Steve Peters
    

re .68

You have to set BTN's block size (BS=) to 10K to read the tapes that Ultrix
creates by default.

I'm in the midst of a discussion with the author about this. The view he
implemented is that a tape is a fixed block device. The driver enforces
this on writes, and hides it from the application on reads. Unix thinks
a tape has variable block sizes, and leaves it up to the application to
get it right.

Net result - Ultrix writes 10K blocks on the tape, and BTN can't read
them back. Unless you set BS as above.

There are also problems using some of the 2.0 applications on BTN:. I think
I know the fix, and will try and get to it this week/tonight.

	<mike

    re .69
    
    The volume label is NEWSTF and the saveset name is NEWSTF.BCK.  Seems
    pretty reasonable.

    re .69
    
    I don't think it's the saveset name. After the trouble I was having with
    the HardFrame and the TK50 tape handler, I bought a GVP controller to
    try.  Anyway, last night I tried VBACK with both the HardFrame and the
    GVP.  I had the same problem with the requestor not accepting the name
    due to length. I edited the startup file and got the same error (113)
    as the previous reply indicated.  Then I tried the GVP on the same
    tape. It worked fine.

    re a few back...

    I finally found the problem with the TK50 handler and my HardFrame. It
    was the TAPE!  I had gotten not one, but 4 bad TK50 tapes. I tried it
    with another tape and it works fine!

    Current status is my GVP controller works with both the TK50 handler
    and VBACK.  My HardFrame works with the TK50 handler, but gets the
    above error with VBACK.

    Gail

    re .71 , .72
    
    	The problem with VBACK seems to be the detection of Tape Marks.
    I use the auto-sense flag on all operations. It seems that the
    hardframe doesn't support this feature.
    	I'll fix the name so it accepts longer device names.
    	I'll create a new switch that gets around the auto-sense problem.
    	I also have code to support the 2090A.
    
    Most of this work will have to wait till I get back from DECUS.
    
    		Steve P.
    

	Steve, you'll  make me the happiest guy in town!! :-)

	Really, I was going to get rid of this controller 
	(but I would miss the two ST506 cheap drives!) just to get TK50 
	working with a GVP or some other controller.

	But now I'm hoping again!!!


	Roberto.

    re: .70
    
    Thanks Mike I'll try setting BS to 10K tonight.  I thought it might
    be something to do with that size, but I tried smaller sizes rather
    than larger.
    
    -steve

    
    	Having now changed my harddrive controller to a 2091 I've tried to
    use BTN , TK50 programs (I haven't had time to try MT yet) and I get an
    error Can't open scsi.device
    
    	All I did was to change the mountlist from nexus (HardFrame)
    .device to scsi.device...
    
    	Any Ideas , amybody using a 2091 and a tape handler ?
    
    	Steve G