paper tape archiving

[Eric Moore]

That is all solid advice.

Here is a pic of my setup (I stopped running it through the old reader as
bypassing it turned out to work fine)

https://i.imgur.com/26pfKhv.jpg

Most of my focus is on ensuring there is no damage to the tape when it is
read. You can see the paper tape catch (hopper) to the left of the PDP.

First I set up my reader and get it aligned with the paper tape roll
holder. I use the one on the front of my SEL 810A as it is purpose made and
handles paper tapes that are very thick or very tightly wound.

I feed it into the reader, and ensure I have at least 10 bytes or so of
nulls prior to my first bytes of data. Ideally there is a foot or more of
nulls so I can get it fed into the hopper. If the null header is too short,
I have to be very careful to get the tape fed into the hopper as it starts
so it does not end up on the floor.

Next I will run a command like:

bash> python3 ./papertape/tapein.py --baud 4800 /dev/ttyUSB0
TAPE_CAPS/testread.bin

That file comes from:

https://gitlab.com/NF6X_Retrocomputing/papertape/-/blob/master/tapein.py

Then I will hit read on my reader, read enough data to feel comfortable
everything is working, and stop the read.

Next I will reset the tape, stop the program on my laptop with ctrl-c, and
re-start the program with the name of the tape I am capturing. I capture
everything on the label in the name, usually catalog #, name, and date.

The entire time I am capturing I will generally have one hand on the reader
so I can stop it if something goes wrong, and one hand free to either guide
the tape back into the hopper if it starts spooling out or to correct the
tape roll if it starts to leave the standoff.

The tricky part is to stop the reader after the last bytes of data but
before the tape rolls through the reader into the hopper. This helps ensure
you do not end up with 0-3 extraneous garbage bytes on the end of the file
depending on how the end of the tape is torn. I remove these manually if I
miss the end.

Finally, for my captures I will run an independent checksum verification if
possible (this is platform dependent). If not, and it is a tape I have to
return, I will do 2 reads and strip the header and trailer and compare. The
likelihood of the same error twice is vanishingly small, and any error with
the sprocket hole throws an alarm with my reader.

A couple notes:

1) My reader when set to lower baud rates physically stops and starts the
reader. This jerks the tape and causes vibrations that can be severe at
some speeds.

2) getting the spool/standoff, reader, and basket/hopper lined up is
critical. Be ready to make small adjustments as you are reading to keep
things running well.

3) a good rewinder is essential, here is a shot of my heavy duty one. I
have a smaller handheld rewinder which is great for short tapes.
https://i.imgur.com/ezKrvn6.jpg

4) xdd -b will dump binary and a visual inspection can be handy when
starting off just to reassure yourself no funny business with the RS232
encoding is afoot

5) The ASR33 always set the MSB high, so only the lower 7 bits are used.
Handy tidbit to know when you are looking for CRLF ar the start of the tape
and the value is b10000000 higher than it should be.

6) repairing a tear is pretty easy, just use some clear tape cut to the
right width since all holes tape is not generally available.

7) If you happen to be reading SEL 810 relocatable tapes, you can use this
program to verify them:

https://github.com/phar/sel810asm/blob/master/rs227.py

-Eric

On Wed, Jul 29, 2020, 16:31 Paul Koning via cctalk <cctalk at classiccmp.org>
wrote:

>
>
> > On Jul 29, 2020, at 5:14 PM, Bill Degnan via cctech <
> cctech at classiccmp.org> wrote:
> >
> > Hi all.
> > I was wondering if there are any good online resources on reading for the
> > purpose of archiving 8-bit papertapes of unknown origin.  I have been
> > reading tapes as text and also as binary, 8/n/1 thinking that's going to
> > capture everything.  I load into a hex editor, and if necessary convert
> to
> > octal.
> >
> > I am wondering if there any persons who have a systematic process they'd
> > like to share for this kind of work. I will share the tapes I have with
> the
> > community, but there is no point if I am not doing it right.
>
> The starting point is what you described: capture all 8 bits in every
> frame.  That includes any embedded 0 (blank tape) frames in the middle.  If
> the tape starts and ends with 0 frames, it's reasonable to omit those, but
> 0 in the middle is often actual data.
>
> The other thing, of course, is to capture as accurately as possible any
> writing or labels on the tape and/or any container it comes in.
>
>         paul
>
>