[Simh] Physical tapes to SIMH virtual tapes

[Sergey Oboguev]

I put together a small utility to read physical tape into SIMH virtual magtape 
container file.

The purpose was to read my old personal tape(s), but I thought I'd share the 
utility and experience to possibly save the effort for someone who might need to 
do the same.

The utility (M2V hereafter) is derived from open-source SCSITAPE utility by Eric 
Lee Green (distribued under GPL terms); for original SCSITAPE utility see:
http://sourceforge.net/projects/mtx/
http://linux.die.net/man/1/scsitape

M2V runs under Windows (and possibly other environments) and reads SCSI tape as 
a whole into SIMH container.
The source code and compiled executables are here (you may use it as you want, 
standard disclaimers apply):
http://oboguev.net/misc/m2v.zip

Original SCSITAPE runs under a number of systems 
(Windows/Linux/SunOS/FreeBSD/HP-UX/SGI/AIX)... theoretically, that is. When I 
tried to use it on Windows, it was able to perform some operations fine but was 
unable to read the tape at all, so I fixed some bugs that prevented SCSITAPE 
running under Windows (primarily, querying and taking into account adapter 
limitations on scatter/gather map size and then properly aligning the buffer).

I also added the code that dumps the whole tape into SIMH format. The code is 
implemented as an additional command (m2v) in SCSITAPE utility.
The arguments for the command are: 

scsitape -f tapeid m2v outfile

Under Windows, tapeid has structure pci-bus-id:xxx:tape-drive-scsi-id:lun, for 
example 2:0:5:0.
Values can be found by checking device properties in Windows Device Manager.
Note: you may need to execute "Scan for changes" in Device Manager to cause tape 
drive to appear there after the drive is powered.

I used M2V under Windows. You might be able to use it under other systems that 
SCSITAPE supports, but you may need to adjust the code, perhaps by providing a 
dummy implementation for routine SCSI_adapter_info.

There is also an auxiliary associated command "m2v_test" that is used for 
testing basic functions. M2V_TEST writes a simple data set to the drive and then 
reads it back from the drive into SIMH file. When something basic seems not to 
work, it is a handy code for debugging.

M2V will read blocks with parity errors and write them to SIMH container, 
marking those blocks as having parity errors, so when VMS BACKUP (or whatever 
system/application virtualized by SIMH) reads them later, it will get a parity 
error signal.

I used QualStar 9-track drive connected to Windows 7/x64 machine with Adaptec 
2940UW SCSI adapter. It was a challenge to find adapter's driver since Windows 7 
no longer comes with drivers for older Adaptec boards, and Adaptec never 
implemented 64-bit drivers for these older boards. However it is possible to use 
64-bit Microsoft drivers borrowed from Windows 2008 server (if you do not have 
it on hand, google for AdaptecAic78xx.zip) or Vista (google djsvs.inf_6451fbc2) 
under Windows 7/x64. Driver file name is djsvs.sys, displayable name is "Adaptec 
AIC-78XX PCI SCSI Controller (Emulated)". I used driver for Windows 2008 Server 
(as it was released later than Vista) and it worked fine under Windows 7. To 
install the driver under Windows 7, do not use "Search in directory" option, as 
Win7 will tell it does not find any driver in the directory; instead use "Have 
Disk" option. Win7 will display warnings several times, but will install the 
driver and it will work, at least it did for me. You may want to create System 
Restore point before installing the driver (or take a backup of system drive); I 
did. Alternative approach is to buy one of the current Adaptec SCSI boards.

The tape I read had been recorded almost exactly 25 years ago. I will skip the 
part about personal emotions one may feel when finding a stack of old tapes with 
content stickers made out with his own hand and marked recording dates ranging 
from 1986 to 1991 ;-)

Anyway, I had doubts the tape would read at all, but the surprizingly it read 
just fine the very first time. There were some parity errors, but all errors 
were recovered in the drive firmware and by autonomous read retries, not a 
single non-recoverable error was signalled to the host computer. VMS BACKUP was 
able to read produced virtual tape file just fine, without a single complaint. 
Data set size on that tape was about 85 MB, i.e. 50% of 2400 ft tape. 


However when I tried to read the same tape second time, just immediately after 
rewinding the tape, parity error rate peaked and the tape went basically 
semi-unreadable. Apparently just one pass of the tape (and then only to the 
middle of it, since the tape was only half-full) left enough residue on the 
drive head and in the tape path to require drive cleaning. I tried putting the 
drive into slow-speed mode (the particular drive has selectable reading speed 
for 6250 BPI density) and it worked noticeably better for a while, but still the 
reading process eventually reached a point when virtually every block was coming 
off with the parity error (at which point I aborted reading), and VMS BACKUP 
complained about excessive error rate and quit.

Thus, on a statistical base of N=1, even old tapes appear to be readable 
(sometimes, anyway -- perhaps I was just lucky), but might likely require 
cleaning the drive after each tape.

- Sergey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20111105/175c88ed/attachment-0002.html>