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@classiccmp.org> wrote: > > > > On Jul 29, 2020, at 5:14 PM, Bill Degnan via cctech < > cct...@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 > >
