• Please review our updated Terms and Rules here

TSZ07 under Windows?

MattCarp

Experienced Member
Joined
Sep 5, 2003
Messages
279
Location
Atlanta, Georgia (USA)
I think I'd like to get my DEC TSZ07 9-track drive working under Windows. There really isn't but a couple expensive commercial software packages that may be able to support it, so I think I'd like to program my own control of the drive.

The drive itself is OEM'd by Cipher (955-S). It uses a SCSI interface.

I'm looking for a programmer's manual or command reference.

If anyone has something like this....
 
If it's SCSI it's likely it will pop up like any other tape drive and be able to run with the backup tools included with Windows.
I have one myself but the power supply is having problems.
 
If it's SCSI, it handles standard SCSI codes for tape devices (isn't it nice when there's a standard?). Cipher may have added a few code extensions, but you probably won't ever use them. Interface in Windows is via normal SPTI, or, alternately ASPI32 if you're running XP and earlier.

Windows generally considers most SCSI tape drives to be the same logically, regardless of their actual physical manifestation.

Programming is mostly a matter of writing CDBs and handing them off to the driver (SPTI or ASPI). SCSI codes are documented in many places all over the web. Here's a list from ANSI T10.

Most Linuces and or Unices readily discover a SCSI tape drive as such. No particular special drivers needed, other than those for your SCSI host adapter.
 
Windows Vista, 7, and 8 have a revised backup program that does not handle tape. XP and earlier NTBACKUP should handle tape drives correctly.

For all versions, SCSI tape drives should work with Cygwin though running Linux tools may not give the results you want.

Do a search for SCSI command programming. You would be creating a wrapper around that.

Unfortunately, the companies I worked with during my forays into reading 9-track from a normal computer are all out of business leaving me with no good leads to offer.
 
Windows Vista, 7, and 8 have a revised backup program that does not handle tape. XP and earlier NTBACKUP should handle tape drives correctly.

For all versions, SCSI tape drives should work with Cygwin though running Linux tools may not give the results you want.

Do a search for SCSI command programming. You would be creating a wrapper around that.

Vista and later, still supports SPTI programming. I don't know why a third-party backup program that supports SCSI tape also wouldn't do what you'd like. There's also a SourceForge ASPI-to-SPTI interface if you need it--it's basically a recreation of the old WINASPI DLL.
 
Vista and later, still supports SPTI programming. I don't know why a third-party backup program that supports SCSI tape also wouldn't do what you'd like. There's also a SourceForge ASPI-to-SPTI interface if you need it--it's basically a recreation of the old WINASPI DLL.
I can't find any code in that project. (or at akrip.sourceforge.net it refers to)

I'd like to have a look at it if anyone finds it.

UPDATE:

The SPTI link goes to an MSDN page and C++ example code, but of course these are Copyright to Microsoft.
 
Last edited:
The Hercules Mainframe Emulator www.hercules-390.eu supports SCSI 9-track drives and includes utilities to copy to/from "real tapes" and ".aws" emulated drives. There is also a test program here:-

http://www.softdevlabs.com/Hercules/hercgui-index.html

towards the bottom that will check out tapes with Windows. All this is Native Windows code, no CYGWIN. If you want to try backup you can copy the "ntbackup.exe" from an XP system and it will work on Vista/7. Microsofts licence to include it expired. (I believe its adapted from Backup Exec)
 
The SPTI link goes to an MSDN page and C++ example code, but of course these are Copyright to Microsoft.

All of the MSDN code is sample code, meaning that it's akin to a reference design. Feel free to borrow.

Looks like the Sourceforge ASPI-to-SPTI layer project disappeared. It used to be there, but someone apparently didn't like it. If you want a simple ASPI conversion layer, you can use FrogASPI, which is available from multiple places.

Or you can write your own ASPI-to-SPTI converter; it's not difficult; it's pretty trivial actually.

If you're interested, I can pass along the code I wrote back in the Win2K days for handling tapes and converting ASPI to SPTI; it's a pile of C++, handing tape is something that really works well in OOP. I can't vouch for current correctness, as the code was written back in 1999.

One reason for coding the interface for ASPI has probably disappeared. Win9x didn't implement SPTI, but there were several ASPI drivers for it. So if you wanted a 32-bit app that ran on both 9x and NT/2K..., you used the ASPI interface and translated to SPTI.
 
Great discussion and I definitely appreciate the comments!

There are a couple third party backup programs that I believe would work - like NovaStor, but, I don't wanna peel out the cash for some reason. I really will do this just to amuse myself, and $80+ for a tape backup utility that I use once won't amuse the MRS. (I need to take up flying or gambling, so my computer vice is minor in comparison!)

I think the MSDN SPTI sample code is my best bet to roll my own.

Dave, the Hercules ftape utility seems like it'll do the trick, but it appears to require a tape drive device driver to be installed. I don't have anything like this, of course, so I don't know if it'll work. I suppose I just need to give it a try.

-Matt
 
Well, you could always boot a LiveCD of a Linux distro and use tar to handle the backup. Might even be better, as there are no open Windows files when you've got Linux booted.
 
Hmm, why would you want to use a 9-track tape drive as a backup storage device on a modern system? I have a Fujitsu M2444AC 9-track tape drive connected to a PC and I have never even considered storing any PC backup data on 9-track tapes. The only thing I use the PC connection for is to write tapes which are then read by the tape drive when connected to a vintage PDP-11 system, for example if I want to go through the exercise of installing 2.11BSD from tape on real hardware as it was done in the day.
 
I didn't bother to ask that one--maybe Matt wants to watch the reels spin. Even at 6250 density, a reel of tape doesn't store all that much compared to, say, a MicroSD card. Given that all of the 9-track tape stock out there has quite a few years under its belt, I wouldn't even consider the 9-track route to be more reliable than a MicroSD card...
 
Hmm, why would you want to use a 9-track tape drive as a backup storage device on a modern system?

No, I just want to do this to amuse myself. I have the drive, I have tapes, but I've never successfully run it.

Besides, from the 1960s well into the 1980s, 9-track seemed to be the big boys' storage medium.

Since Windows systems are ubiquitous and it's easy to get my Win7 laptop near the drive, I thought it would be most useful to write to a tape from Windows.
 
My 9-track 1/2-inch tape drive has a Pertec interface and when I connect that to a PC I use a PCTD-16 ISA controller card and real mode DOS software to talk to that. When I connect that drive to a Q-Bus PDP-11 I use an Emulex QT13 controller, which is compatible with later versions of PDP-11 operating systems.

I also use Exabyte 8200 8mm SCSI tape drives. On the PDP-11 I use something like a CMD CQD-220/TM SCSI controller. On the PC side I ended up setting up a Linux system to write the tapes. It looked like it was more work to figure out how to write tapes when running Windows than on Linux, where I found it fairly simple to modify the 2.11BSD maketape program to be able to write a .TAP tape image out to a physical tape on the SCSI tape drive.

For me it was interesting to use the tape drive on a vintage system as it would have been used back in the day for OS installation. The PC side was just a tool for getting the OS installation images onto the tapes. But I suppose if you don't have a vintage system to interface to the tape drive just connecting it to a PC to read and write data and see the reels spinning on a 9-track 1/2-inch drive is interesting just for the exercise of doing it. In comparison the 8mm tape drive is completely boring.
 
My back greatly preferred the small portable version I had to work with, only weighed about twice what the AT did. Made enough noises that I could track my code based on the tape drive sound and had a nice window on the top to watch the vacuum autoload the tape.
 
I also have some Qualstar 1052 9-track tape drives which are very portable at 27 pounds compared to the 200 pound Fujitsu M2444AC. Unfortunately the tradeoff is performance with the Qualstar 1052 being uncached. It is not so bad when interfaced to the PCTD-16 ISA bus controller which has onboard tape block buffers, but when interfaced to the Emulex QT13 in the PDP-11 it spends most of its time shoe shining back and forth when doing something like installing RSTS/E from tape.

I should find a new home for the Qualstar 1052 tape drives. I haven't used them in a while and the novelty of using them wore off a long time ago.

-Glen
 
The Qualstar 1260S has the distinction that the SCSI interface appears to be much slower than the drive itself. Even at 1600, it's not possible to keep the drive from shoeshining. At 6250, it's pretty much a lost cause. This is on a dual 1GHz P3 system with an Adaptec 2940--plenty of badwidth until it gets to the drive.

I miss the big 200 IPS vacuum-column drives.
 
getting ready to take on the programming project

getting ready to take on the programming project

If it's SCSI, it handles standard SCSI codes for tape devices (isn't it nice when there's a standard?). Cipher may have added a few code extensions, but you probably won't ever use them. Interface in Windows is via normal SPTI, or, alternately ASPI32 if you're running XP and earlier.

Windows generally considers most SCSI tape drives to be the same logically, regardless of their actual physical manifestation.

Programming is mostly a matter of writing CDBs and handing them off to the driver (SPTI or ASPI). SCSI codes are documented in many places all over the web.

Well, I still want to see this tape drive spin (read/write) data from Windows.

I'm using an older USB-to-SCSI adapter from Ratoc Systems (Japanese peripheral company) with a recent commodity Dell laptop. I was able to get a Windows 7 driver for the host adapter. Next, I used Robin Miller's SCSI Utilities and was able to issue some basic SCSI commands and successfully communicate with the tape drive! Also, I was able to get the Windows SPTI example program and compile that with Visual Studio Express 2013.

So, I've confirmed the drive works, my host adapter works, and that I can compile a Windows program with calls to Windows SCSI Pass Through Interface (SPTI)..

Now I need to write a simple program to read and write to tape.

DEC's TSZ07 Technical Manual lists the SCSI commands supported, but it looks like the primary commands are:

READ
WRITE
READ BLOCK LIMITS - to determine the block size
SPACE - to skip over logical blocks
REWIND
WRITE FILEMARKS

and MODE SELECT / MODE SENSE to set parameters

However, the technical manual provides no detail and instead refers you to another DEC manual "SCSI: A Developer's Guide" (part #EK-SCSIS-DK).

So, while I could start hacking away, I'd like to find this manual first. I'm hoping for some examples, or more details on DEC's support. I can't find this manual online.

My concern is that, after reading the SCSI standard, there are descriptions of partitions and I'm not exactly sure how to put logical blocks and file marks together. Plus there are at least four different variants of the READ command.

I could be overcomplicating it. The tape drive is from 1992, so it could be that the layout is super simple:

Each tape is a volume with one partition. The partition consists of logical blocks, with filemarks being a separator between files.

If this is the case, I'm wondering if you start to read a tape, how do you know how much to read?

So, I guess if anyone has some experience in this area, I'd love to hear about how I can approach this. Just as well, I'd love to get the DEC EK-SCSIS-DK manual !!

-Matt
 
Last edited:
Back
Top