HP C1537A SCSI DAT over Firewire

  • Thread starter Thread starter Mike Neus
  • Start date Start date
M

Mike Neus

Just wondering if anyone tried and got it to work? I have one HP C1537A
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?
 
: Any other ideas?

If you just need to get it working on that one machine, just buy
a cheap SCSI card.

Jamie
 
The latest ASPI is 4.71 and it works fine under Win 2K/XP. ASPI 4.60 predates
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.

|
| You can install the latest Adaptec ASPI (4.60 IIRC) on Win2k and it will
| work okay, but it is not supported by Acraptec.
|
 
At the risk of starting a flamefest, which I really do not want to do, I would like to jump in here and clear up a few
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
(e-mail address removed)
www.nexitech.com
 
serialized in the SCSI port driver. However, my ASPI manager is
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
 
Thanks. I don't know what SPTI is, but will have a google.

This is DeviceIoControl(IOCTL_SCSI_PASS_THROUGH)

Max
 
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. Nero's ASPI layer can be downloaded from ftp.nero.com,
which I only found after googling for it.
 
Mike Neus said:
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.
Click to expand...
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.
Click to expand...

True in spades of their piece of shit software as well.
 
You are saying ASPI fixed your ntbackup problem? No way!

Nero's ASPI cannot possibly affect ntbackup. You are just changing too many
thing and don't know what fixed your problem.

| 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. Nero's ASPI layer can be downloaded from ftp.nero.com,
| which I only found after googling for it.
|
| | > Just wondering if anyone tried and got it to work? I have one HP C1537A
| > 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?
| >
| >
| >
|
|
 
I think this might have to do with the fact that NTBackup was written by
Veritas, not Microsoft.

Cheers,
Dave
 
Here is a list of all the changes that transpired to my system over the past
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...
 
ASPI has no relation to NTBackup at all. NTBackup works via the kernel-mode
tape driver which builds the CDBs.
 
Maxim S. Shatskih said:
ASPI has no relation to NTBackup at all. NTBackup works
via the kernel-mode tape driver which builds the CDBs.
Click to expand...

So, that leaves a) and c). I'd go for a).
 
Folkert said:
So, that leaves a) and c). I'd go for a).
Click to expand...

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.
 
Back
Top