[cctalk] Trying to read 800 bpi NRZ 9-Track Tapes using an M4 9914 drive

I wanted to share some results I got when attempting to read 800 bli NRZI 9-track tapes: I have not been able to read any of the 800 NRZi Tapes. I tried a number of things using four computers. My analysis is detailed below. The 800 bpi-related calibration on the M4 drive on hand may be off. Just a guess. Sources https://web.geo.uib.no/eworkshop/uploads/Main/123477_23_9914_User_Diagnosti… Followed suggestions from web search and AI prompts where applicable There is a set of programs embedded on an eProm on the M4 drive. Program 41 sets the data encoding circuits to handle 800 bpi. I activated this program before attempting a read. When I put in a 800 NRZI tape into the drive it analyzes the tape and reports the tape type to be 800 bpi, but I thought maybe running program 41 to explicitly force 800 bpi mode would be useful/necessary just in case. As a general rule, I always reset the drive using these commands before trying another read: mt -f /dev/nst0 status - OK (reports 800 NRZ ONLINE) mt -f /dev/nst0 rewind - OK (rewinds tape) 2. I started with an Ubuntu 18 system. I was successfully able to attach the drive, etc. Next I broke down the testing - the simple stuff: mt -f /dev/nst0 status - OK (reports 800 NRZ ONLINE) mt -f /dev/nst0 rewind - OK (rewinds tape) mt -f /dev/nst0 offline - OK (takes the drive offline) mt -f /dev/nst0 setblk 0 - OK (sets to variable block mode) mt -f /dev/nst0 fsf 1 - NOT OK (never finds a start of file, runs through entire tape.) But when I try to actually read a tape I get errors Here are examples of the tape read commands, there are many variations one can try: dd if=/dev/nst0 of=block1.bin dd if=dev/nst0 of /dev/null bs=1024 etc I would open a 2nd window and run the following command to view the system messages while the dd program is running dmesg | tail -50 result example: [ 1802.404408] st0: Failed to read 1326 byte block with 1024 byte transfer. [ 1813.881884] st0: Failed to read 3846 byte block with 1024 byte transfer The drive can see data on tape and start reading it but the host computer is applying the wrong transfer size assumptions. I think. I don't think setblk 0 is being implemented (use variable block size), but I don't think this is a fixed-block vs variable block issue. I think that Linux' st driver is issuing fixed-size read internally and failing when the drive returns a different record size than expected. There is no indication that I have bad media or can't read tape or nrz failure at least. No errors like that. It appeared to me that the Ubuntu 18 linux version of the st driver cannot properly stream variable-block 800 bpi tapes, but it's not a SCSI issue. 3. I then built an older style Pentium III with Debian linux (version 7) with an Adaptec 2950 SCSI controller. The hope was that I'd be closer to a system that has native ability to read 800 bpi tapes. I used an older version of linux etc. all to try to avoid emulation issues. I ran the same tests as above plus other tests, nothing worked. raw streaming: mt -f /dev/nst0 setblk 0 dd if=/dev/nst0 of=tape_dump.bin bs=256k conv=noerror,sync mt -f /dev/nst0 of=dump.bin bs-32k conv=noerror, sync if tapes are structured then the following would work, but it does not: mt -f /dev/nst0 fsf 1 dd if=/dev/nst0 of=record1.bin (and repeat per record ) Result - The fsf command runs and rolls the entire tape, never finds a file marker to indicate beginning of file. This indicates variable-block, filemark-less (or nonstandard filemark) 9-track dump tapes, like you find in IBM systems. To just avoid buffer failures and bad records and keep going to the end of the tape I tried this: dd if=/dev/nst0 of=tape_dump.bin bs=64k conv=noerror,sync iflag=fullblock Result - it tried endlessly but never advanced the tape. I also tried cat, which is probably not as good as mt, but worth a shot: cat /dev/nst0 > dump.bin also tried dd if=/dev/nst0 of=tape_dump.bin bs=256k conv=noerror,sync status=progress repeats endlessly showing the output to the screen... *Conclusions* The drive is not successfully completing a forward-read operation. I observed no forward motion, repeated zero-length reads. *So I think the situation is ...* SCSI is OK - I can issue commands that do not involve reading. The tape transport (the physical movement of tape) is ok, NRZ 800 bpi selection seems to work, and the mechanism appears to be able to at least detect that there are blocks of data that can be read. What does not work is when we attempt to perform sequential streaming through variable block tapes like the NRZ's I have. The tapes appear to be non-filemarked, variable-block 9-track tape where forward streaming is error-sensitive. It could be that the M4 9914’s NRZ (800 BPI) read path is marginal or out of calibration. I believe the M4 mechanics for 800 dpi tapes are separate from the 1600 dpi. 4. DEC 3000 and DEC 4000 servers with native centronics SCSI ports Unfortunately neither even detected the M4 drive so I was not able to test further. I asked AI and it suggested that the DEC firmware sometimes had trouble with older SCSI-1 devices like the M4. Interesting that the PCs with SCSI card were better able to detect the drive, but they were. Note that I played around with termination of the SCSI ports to see if there was a difference, none detected. I opened the M4 rear panel to see if I could change the SCSI ID number to try a different number to avoid possible conflicts but there was nothing available. The drive number appears to be set by the eProm, but I did not want to open up the entire drive. The Adaptec controller reports the M4 to be: Vendor: M4 DATA Product: OPEN REEL TAPE Revision: 138P --------------------------- I am not sure bypassing SCSI and using the Pertec interface would work, I don't have a computer that uses Pertec for data like that, or I'd have to figure it out from scratch. Bill