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
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
