On Mon, Nov 03, 2025 at 02:04:36PM -0500, Paul Koning wrote: > > On Nov 2, 2025, at 8:25 PM, David Gesswein <[email protected]> wrote: > > > > Looks like this > > https://www.ricomputermuseum.org/collections-gallery/interesting_computer_items/computer-operations-inc-linc-tape > > Which one? There are two pictures which look like mirror images. The one on > the left (part of the ad) would be compatible with the way DECtape reels are > normally spooled. > The LINC version, top picture.
> I'm puzzled how you would read a tape without having the mark track. Or do > you mean that the two copies of the data tracks are available as separate > signals but the mark track is a single signal (presumably summing the two > mark tracks)? What about the timing track? > Correct both copies of the redundant tracks are brought out separately except mark. Correct mark is sum of both tracks. DEC DECtape drives bring out both timing tracks for skew test. This drive does the same. Haven't tried but Manchester encoding doesn't need a clock to decode so in theory you can decode each track and then align to recover data. > > Current project is LINCtapes. Need to do some code changes to merge in my > > DECtape decoder. Bottom links are recent stuff. > > https://www.pdp8online.com/images/index.shtml > > > > Interesting. Well, we know DECtape was pretty robust, though it *is* > possible to wear it out, I saw id done repeatedly at my college where DECtape > was (in 1973) used as the public file system for RSTS-11. On the other hand, > a former DEC guy told about a DECtape reel that accidentally was run through > the laundry (it was in a pocket) and worked just fine afterwards. :-) > This decoded fine. https://www.pdp8online.com/ftp/images/GJohns/GCJ-seq1.png This is going to be tougher to recover. https://www.pdp8online.com/ftp/images/GJohns/dropout.pdf
