1 Jul
2026
1 Jul
'26
9:16 a.m.
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
1 Jul
1 Jul
9:17 p.m.
On Wed, 1 Jul 2026, Bill Degnan wrote:
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 conclusion is very simple: you cannot use dd for tapes with variable
block sizes! You must issue individual read calls and parse the result
length for each tape block.
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
Yes, it is. dd can only handle fixed block length. You may try dd with
'dd if=/dev/nst0 bs=32768 count=1' to read one single block.
Linux' st driver is issuing fixed-size read
internally and failing when the
drive returns a different record size than expected. There is no
No. The read system call returns the actual size. You issue a read(fd,
buffer, MAX_BLOCK_LENGTH) and look at the return value that tells you the
length of the actual block.
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.
Ehm, and you're sure that there is a second file on the tape? May it be a
backup with one single file that fills the entire tape?
Christian
2 Jul
2 Jul
4:47 a.m.
On Thu, Jul 2, 2026 at 1:33 AM Christian Corti via cctalk <
cctalk(a)classiccmp.org> wrote:
On Wed, 1 Jul 2026, Bill Degnan wrote:
I tried per your suggestion
dd if=/dev/nst0 bs=32768 count=1 (to read one single block)
I got the same results as before, the tape is attempted, not advanced. 0
bytes in/out, 0 bytes copied.
Thank you for your suggestion. I can repeat this test with all 4 tapes I
have on hand, they all have identical results. I have no issue reading
1600 pe tapes on this M4 tape unit. With 800 bpi tapes, regardless of the
bs values and other tricks, I would think I would read something before it
bombs.
Is there a way to force the tape to advance and try after a certain
distance of tape? Maybe the beginning of the tape is bad but I can recover
data from the inner parts?
I am open to suggestions, but I am wondering if there is a drive issue.
Alignment, etc.
Best
Bill
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 conclusion is very simple: you cannot use dd for tapes with variable
block sizes! You must issue individual read calls and parse the result
length for each tape block.
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
Yes, it is. dd can only handle fixed block length. You may try dd with
'dd if=/dev/nst0 bs=32768 count=1' to read one single block.
1 Jul
1 Jul
11:05 p.m.
Hi Bill,
Below is a small standard C program for Unix or Linux which will read your
tape and convert it into a TAP format tape. Under FreeBSD I use
"/dev/nrst0" which is the non-rewinding version of the tape device 0. Your
particular system may require a different device name. The program is bare
bones but will do the job. If an error is encountered it simply stops. You
are welcome to add error handling and reporting etc.
TAP format tape records look like this:
---
4 byte record length (little endian)
n bytes tape record
4 bytes record length (little endian)
---
A typical tape images contains many records as shown above.
The trailing record length allows emulators to read a tape image backwards.
A Tape-Mark looks like this:
---
4 bytes of zero
---
An End-Of-Tape looks like this:
---
4 bytes of zeroes
4 bytes of zeroes
---
The C program is below. It requires only the standard C library.
---
#include <stdio.h>
static unsigned char buf[100000];
int main(int argc, char **argv)
{
FILE *of;
int mt;
int ic;
int zero = 0;
if (argc != 2)
{
fprintf(stderr, "Usage: mag2tap <TAP image file>\n");
exit(1);
}
if ((mt = open("/dev/nrst0", 0)) < 0)
{
perror("open");
exit(1);
}
if ((of = fopen(argv[1], "w")) == NULL)
{
perror("open");
exit(1);
}
while ((ic = read(mt, buf, sizeof(buf))) >= 0)
{
fprintf(stdout, " %d", ic);
fflush(stdout);
if (ic == 0)
{
zero += 1;
if (zero >= 2)
{
break;
}
}
else
{
zero = 0;
}
if (fwrite(&ic, sizeof(ic), 1, of) != 1)
{
perror("fwrite1");
exit(1);
}
if (ic > 0)
{
if (fwrite(&buf, 1, ic, of) != ic)
{
perror("fwrite2");
exit(1);
}
if (fwrite(&ic, sizeof(ic), 1, of) != 1)
{
perror("fwrite3");
exit(1);
}
}
}
fclose(of);
close(mt);
}
---
Please email me directly if you have any trouble understanding, compiling
or running this.
Tom
On Thu, Jul 2, 2026 at 1:17 AM Bill Degnan via cctalk <cctalk(a)classiccmp.org>
wrote:
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.
...
2 Jul
2 Jul
2:19 a.m.
Tom Hunter wrote:
TAP format tape records look like this:
---
4 byte record length (little endian)
n bytes tape record
4 bytes record length (little endian)
---
In Bob Supnik's SIMH .tap format, if n is odd the record should be
padded with an extra byte. But unfortunately there are unpadded tape
images around. My tools write the padded format, but try to read both
ways.
If the record length has the sign bit set, it has a special meaning.
See this for details:
https://simh.trailing-edge.com/docs/simh_magtape.pdf
while ((ic = read(mt, buf, sizeof(buf))) >= 0)
{
fprintf(stdout, " %d", ic);
fflush(stdout);
if (ic == 0)
{
zero += 1;
if (zero >= 2)
{
break;
}
}
If I read this right, you break out of the loop if two tape marks are
read. Sometimes there is more data after the two tape marks. Sometimes
it's important data.
3 Jul
3 Jul
7:39 a.m.
On Thu, Jul 2, 2026 at 5:20 AM Lars Brinkhoff via cctalk
<cctalk(a)classiccmp.org> wrote:
Sometimes there is more data after the two tape marks.
Sometimes
it's important data.
Sometimes it's sneaky secret data. Towards the end of the Classic HP
3000 era, HP grew tired of making customized SUBSYS tapes (that only
included the set of subsystems the customer had purchased) to send to
every supported machine whenever there was an OS version update. So
they came up with a new HP UPDATE distribution mechanism that involved
sending the same tapes to everyone. These tapes secretly contained the
full set of updated subsystem products hidden after the first double
tape mark.
The customer would restore "everything" on the tape which appeared to
be only nine little files (from a two reel tape set lol) including the
update program. An obfuscated file contained signatures (like a
filename, or procedure name) of installed products so the program
could figure out which products were already on the system and which
it would then proceed to update by pulling files off the second :STORE
image hiding after the first one.
Old HP was always so cute when they tried to be sneaky.
They only got to use this distribution mechanism once, as part of the
last-ever Classic MPE/V release (Version 40).
8:26 a.m.
On Fri, 2026-07-03 at 10:39 -0500, Gavin Scott via cctalk wrote:
Old HP was always so cute when they tried to be
sneaky.
In about 1998 I got an HP inkjet printer for my 720. HP-UX 10 didn't
have a driver for it, and the CD only had drivers for Windoze and
MacOS. I called HP. The phone lady asked whether I was running Windoze
or MacOS. I told her I was running HP-UX. She asked "What's that?" I
explained "That's Hewlett-Packard Unix." She asked "What's
that?"
I eventually found a guy on a news group in Norway who knew about the
driver. It's free. It's on the HP-UX distribution CD. But you need HP
to fax you the code to unlock it. They'll send the fax for free. But
you have to know to ask for it.
Old HP was always so cute when they tried to be sneaky.
4 Jul
4 Jul
1:39 a.m.
New subject: Big brand software support (was: Trying to read 800 bpi NRZ 9-Track Tapes using an M4) 9914 drive
Van Snyder wrote:
In about 1998 I got an HP inkjet printer for my 720. HP-UX 10 didn't
have a driver for it, and the CD only had drivers for Windoze and
MacOS. I called HP. The phone lady asked whether I was running Windoze
or MacOS. I told her I was running HP-UX. She asked "What's that?" I
explained "That's Hewlett-Packard Unix." She asked "What's
that?"
This reminds me of calling IBM in the early 90s looking for software support
for VM/HPO ("Virtual Machine / High Performance Option", a virtualisation
operating system for System/370 mainframes).
Each time I got passed on to yet another person who had no idea what I was
talking about, their first question to me would be:
"What version of OS/2 are you running this on?"
Regards,
Peter Coghlan
2 Jul
2 Jul
6:18 a.m.
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
Two things:
1. If you `setblk 0` and use a large enough ibs= with dd, it'll read
variable block sizes just fine.
2. DON'T ARCHIVE VARIABLE BLOCKED TAPES WITH DD!!!! It throws away
information. Use a tool that preserves the block sizes. E.g.:
https://github.com/brouhaha/tapeutils
De
6:26 a.m.
On Thu, Jul 2, 2026 at 10:18 AM Dennis Boone via cctalk <
cctalk(a)classiccmp.org> wrote:
I totally agree with all of your thoughts here. My experiments were to try
to get some reads first then try tapeutils. setblk 0 does not work in
this case. If I can't even get out of the starting gate to read *anything*
then I think I need a new drive. I am happy to be proven wrong but I think
I will try another drive.
Bill
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
Two things:
1. If you `setblk 0` and use a large enough ibs= with dd, it'll read
variable block sizes just fine.
2. DON'T ARCHIVE VARIABLE BLOCKED TAPES WITH DD!!!! It throws away
information. Use a tool that preserves the block sizes. E.g.:
https://github.com/brouhaha/tapeutils
De
6:34 a.m.
setblk 0 does not work in this case. If I can't
even get out of the
starting gate to read *anything* then I think I need a new drive. I
am happy to be proven wrong but I think I will try another drive.
Your error messages indicate that the available buffer is too small for
the tape record, but they also seem to indicate that everything else
understands that the block size is variable. Have you tried just making
the bs= or ibs= large?
De
8:33 a.m.
On Thu, Jul 2, 2026 at 10:34 AM Dennis Boone via cctalk <
cctalk(a)classiccmp.org> wrote:
yes I have tried a wide range of sizes
Bill
setblk 0 does
not work in this case. If I can't even get out of the
starting gate to read *anything* then I think I need a new drive. I
am happy to be proven wrong but I think I will try another drive.
Your error messages indicate that the available buffer is too small for
the tape record, but they also seem to indicate that everything else
understands that the block size is variable. Have you tried just making
the bs= or ibs= large?
De
35
days inactive
38
days old
11 comments
8 participants
participants (8)
-
Bill Degnan -
Christian Corti -
Dennis Boone -
Gavin Scott -
Lars Brinkhoff -
Peter Coghlan -
Tom Hunter -
Van Snyder