HP C1537A SCSI DAT over Firewire
Mike Neus
external DAT drive and two Windows 2000 (SP4) PCs. One has SCSI, the other
is Firewire. I acquired a Belkin Firewire/SCSI converter in the hopes that
I could adapt the DAT drive to the Firewire PC. The manual lists it as
compatible with some DAT drives and some HP drives (though no HP DAT models
are listed) so I had high hopes.
The drive works like a dream on the SCSI PC. Amazingly enough, the
Firewire/SCSI adapter works like a dream on the Firewire PC (successfully
installed a SCSI U/W external drive with it using the appropriate adapter).
Put the C1537A on the Firewire PC though and it's no go, but so close I can
taste it. Windows sees the C1537A drive on the Firewire bus just fine. It
identifies it with a yellow question mark as "Other Devices | HP C1537A L111
IEEE 1394 SBP2 Device". If I forcibly install SBP2 drivers Windows BSODs.
If I forcibly install either the Windows 4mm DAT driver or HP's DDS3 DAT
driver Windows seems happy (Tape drive moves under "Tape Drives | HP
C1537A"). NTBackup even acknowledges the drive, but waits forever on the
"insert new media" prompt, even though a tape is in the drive.
Any other ideas?
jt...@punk.net
: Any other ideas?
If you just need to get it working on that one machine, just buy
a cheap SCSI card.
Jamie
Dave Hau
want to try updating the ASPI driver if you haven't already done so.
See if it helps.
Cheers,
Dave
Eric Gisin
"Dave Hau" <davehau_nospam_123@nospam_netscape.net> wrote in message
news:3F3054E6.5060708@nospam_netscape.net...
Mike Tomlinson
writes
>Nope, ASPI is not supported or used by Windows 2000.
You can install the latest Adaptec ASPI (4.60 IIRC) on Win2k and it will
work okay, but it is not supported by Acraptec.
--
A. Top posters.
Q. What's the most annoying thing on Usenet?
Eric Gisin
Win 2K, and you should not expect it to work.
It was clear three years ago the proper way to issue SCSI commands is SPTI,
not APSI. Especially for Firewire.
There is an MS KB article that says the scsi() ARC path does not work for
Firewire because it lacks scsi IDs. I expect ASPI has the same problem.
"Mike Tomlinson" <mi...@nospam.jasper.org.uk> wrote in message
news:00dlaJANmQM$Ew...@nospam.jasper.org.uk...
Maxim S. Shatskih
> not APSI. Especially for Firewire.
SPTI has some limitations - no overlapped IO and the 64KB IO transfer limit.
Max
Mike Tomlinson
writes
>It was clear three years ago the proper way to issue SCSI commands is SPTI,
>not APSI.
Thanks. I don't know what SPTI is, but will have a google.
Don Matthews
misconceptions about ASPI and SPTI. I always hear people say things these days like "ASPI is dead" and "ASPI is not supported on
Win2K" and this is simply not true. What these people really mean to say is that a particular vendor's implementation of ASPI is no
longer supported, or it has bugs, or it does not work on Win2K, or whatever. And to be even more specific, they are usually
talking about the Adaptec implementation of ASPI. But the really important thing to remember here is that ASPI itself is merely an
API. ASPI stands for Advanced SCSI Programming Interface. Therefore, ASPI itself is really not some piece of code that you install
and run on your computer, it is just a *specification* of data structures and entry points. The code that you actually install and
run on your computer is an *implementation* of ASPI. And Adaptec is not the only company to have made an *implementation* of ASPI.
There are others. My company makes one, in fact, and it works great on Windows 95/98/ME and also on Windows NT/2K/XP. So again, my
point is simply that ASPI itself is merely an API, and any comments saying that ASPI does or does not work on a particular OS should
really be qualified to say that a particular vendor's implementation of ASPI does or does not work. Because someone else's ASPI
Manager may work just fine!
And to Maxim's comments below, there is no 64 KB I/O transfer limit on SPTI. I routinely make SPTI transfers of 1016 KB. This is
accomplished by adjusting an entry in the registry. And strictly speaking, he is right about overlapped I/O, since SPTI calls are
serialized in the SCSI port driver. However, my ASPI manager is multi-threaded and is able to make the calls look asynchronous to
the caller through the use of helper threads. So the calling app can proceed with work in parallel while the SCSI command is being
executed (some overlap).
NexiTech ASPI also works with USB and 1394 devices from non-Administrator accounts, something other ASPI implementations do not do.
But this was not intended to be a full-blown ad for NexiTech ASPI, so please do not flame me for that. I just wanted to interject
and point out what I view as misconceptions about ASPI. It is still very much a viable alternative for folks who have existing ASPI
apps that they do not want to re-write for SPTI. And if they still want a single app to work on the older Win9x platforms, as well
as the newer Windows platforms, there is no logical choice but ASPI for SCSI device control.
Thanks,
Don
Don Matthews
President
NexiTech, Inc.
719-687-3225
matt...@nexitech.com
www.nexitech.com
"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message news:bgspf4$12e8$1...@gavrilo.mtu.ru...
Malcolm Weir
<matt...@nexitech.com> wrote:
[ Snip ]
> ASPI stands for Advanced SCSI Programming Interface. Therefore, ASPI itself is really not some piece of code that you install
>and run on your computer, it is just a *specification* of data structures and entry points. The code that you actually install and
>run on your computer is an *implementation* of ASPI. And Adaptec is not the only company to have made an *implementation* of ASPI.
A long time ago (and I mean, a long time ago), that "A" really did
stand for "Adaptec", not "Advanced". This doesn't mean much, though,
given that SCSI evolved directly from SASI, and the meaning of the
"SA" was changed significantly to that for the "SC" for similar
reasons...
But Don's point is well taken...
>Don Matthews
>President
>NexiTech, Inc.
Malc.
Maxim S. Shatskih
multi-threaded and is able
Usual ASPI managers contain the filter driver on top of SCSIPORT in the kernel
and user mode DLL which sends some proprietary IOCTLs to it. The driver uses
the same path of talking to SCSIPORT as, say, the disk driver does.
This is to bypass the IOCTL_SCSI_PASS_THROUGH limitations.
Max
Maxim S. Shatskih
This is DeviceIoControl(IOCTL_SCSI_PASS_THROUGH)
Max
Mike Neus
test backup. Not sure what I'm more amazed at, that this little gizmo
worked at all or that it worked with what I wanted to do.
For the record, ASPI is the key. However, I read in several places that
Adaptec 4.71 does not support Firewire devices so I never tried it. I read
Nero's did so that is what I installed. Now the install instructions were a
bit strange, saying to copy the DLL to your Nero directory. My Nero Burning
ROM 5.5 directory did not have an WNASPI32.DLL in it already, so I dropped
it in WINNT/SYSTEM/SYSTEM32 instead. When the drive is plugged in Windows
still does not properly recognize it, but if you forcibly install Windows
2000's built in DAT driver (Might have to do this each time it's plugged in,
not sure), Windows accepts the drive just fine, and then NTBackup works just
as it should.
Special thanks to Dave for sending me down this path...I was skeptical but
proof is in the pudding.
Oh, BTW, Nero's website is a mess since they updated it for Nero 6.
Couldn't navigate it worth a darn, seems to fail basic user friendliness
with flying colors. Nero's ASPI layer can be downloaded from ftp.nero.com,
which I only found after googling for it.
"Mike Neus" <im_...@yahoo.com> wrote in message
news:wdHXa.871$Q63....@newsread2.prod.itd.earthlink.net...
Rod Speed
"Mike Neus" <im_...@yahoo.com> wrote in message news:yO_Ya.1833$Ew5.1...@newsread2.prod.itd.earthlink.net...
> Well, I managed to get it working. I don't believe my eye's, but just ran a
> test backup. Not sure what I'm more amazed at, that this little gizmo
> worked at all or that it worked with what I wanted to do.
>
> For the record, ASPI is the key. However, I read in several places that
> Adaptec 4.71 does not support Firewire devices so I never tried it. I read
> Nero's did so that is what I installed. Now the install instructions were a
> bit strange, saying to copy the DLL to your Nero directory. My Nero Burning
> ROM 5.5 directory did not have an WNASPI32.DLL in it already, so I dropped
> it in WINNT/SYSTEM/SYSTEM32 instead. When the drive is plugged in Windows
> still does not properly recognize it, but if you forcibly install Windows
> 2000's built in DAT driver (Might have to do this each time it's plugged in,
> not sure), Windows accepts the drive just fine, and then NTBackup works just
> as it should.
>
> Special thanks to Dave for sending me down this path...I was skeptical but
> proof is in the pudding.
> Oh, BTW, Nero's website is a mess since they updated
> it for Nero 6. Couldn't navigate it worth a darn, seems
> to fail basic user friendliness with flying colors.
True in spades of their piece of shit software as well.
Eric Gisin
Nero's ASPI cannot possibly affect ntbackup. You are just changing too many
thing and don't know what fixed your problem.
"Mike Neus" <im_...@yahoo.com> wrote in message
news:yO_Ya.1833$Ew5.1...@newsread2.prod.itd.earthlink.net...
Dave Hau
Veritas, not Microsoft.
Cheers,
Dave
"Eric Gisin" <er...@go.to> wrote in message
news:bh32e...@enews3.newsguy.com...
Mike Neus
week. Which do you think fixed the problem?
a) Moved the calendar on top of my monitor 3" to the right.
b) Installed the Nero ASPI layer
c) Rerouted the wiring behind the desk slightly
d) Posted a message to usenet to humbly seek assistance while popping a brew
and eating some popcorn to sit back and watch the resulting inevitable brawl
unfold. Meanwhile, somebody says the DAT drive needs ASLI (Advanced SCSI
Listening & Interpretation) to listen in on the conversation. Once
installed, the drive is immediately scared into full operation, taking upon
itself to emulate Firewire protocols, knowing full well that we are talking
about it and the alternative is the trash can. Elated the drive works, the
fix is posted for other future passer buyers in seek of a remedy. Finally,
somebody says ASLI can't possibly have an effect because SCSI devices don't
listen to NTBackup anyway, preferring instead to do their own thing in the
face of assimilation. The reason it really works is because apparently I
make changes to my system in my sleep, and it apparently was really one of
those changes that made everything work together. Perhaps it
was...control-alt-delete.
e) The moon is almost full and is pretty close to Mars creating immense
tidal forces on my CPU forcing NTBackup into suddenly work over Firewire.
It will all come to pass in a couple of days...
"Eric Gisin" <er...@go.to> wrote in message
news:bh32e...@enews3.newsguy.com...
Maxim S. Shatskih
tape driver which builds the CDBs.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
Folkert Rienstra
"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message news:bha6nr$125t$1...@gavrilo.mtu.ru...
> ASPI has no relation to NTBackup at all. NTBackup works
> via the kernel-mode tape driver which builds the CDBs.
So, that leaves a) and c). I'd go for a).
Mike Tomlinson
Rienstra <see_Re...@myweb.nl> writes
>So, that leaves a) and c). I'd go for a).
No, this is SCSI. To get it working, he must have lit some black
candles and sacrificed a virgin. He just didn't want to tell us about
it.