Tape reel data recovery from MERA-400 polish computer

[Paul Koning]

> On Mar 10, 2017, at 2:25 PM, Chuck Guzis via cctalk <cctalk at classiccmp.org> wrote:
> 
> On 03/10/2017 10:58 AM, Paul Koning via cctalk wrote:
>> 
>>> On Mar 10, 2017, at 1:39 PM, Al Kossow via cctalk
>>> <cctalk at classiccmp.org> wrote:
>>> 
>>> 
>>> The next extension is to track the tachometer values so that you
>>> can detect and compensate for tape stick/drag which is absolutely
>>> critical for formats that don't self-clock, like NRZI.
>> 
>> NRZI is not self clocking if you consider an individual track in
>> isolation.  But it IS if you consider all the tracks at the same
>> time, provided either (a) the data is recorded with odd parity, or
>> (b) the all-zeroes data character isn't used.  (a) is the case for
>> 9-track tapes.  7 track tapes may be even parity, but that case seems
>> to apply by convention only to text data (not binary data) and there,
>> (b) applies.  You do have to correct for track skew in this process,
>> but that applies in any case even if you have an independent
>> authoritative bit clock.
>> 
>> It clearly can help to have tach signals as a way to improve bit
>> framing, but I don't see that it's mandatory.
> 
> I think I mentioned that a couple of years ago.  Even parity 7 track
> tapes were used on very old systems for reasons that escape me.  One of
> the problems, then was how to represent an all-zero character, since
> there would be no transitions in that particular frame.

Sure.  One tape document I looked at mentions the use of odd parity on the 7-track tapes when writing binary data, even parity when writing "IBM BCD" character coded data, with one of the 6-bit values forbidden in that case (the value encoded on tape as 6 zero bits). 

A stretch with no transitions occurs of course at the block boundary (the gap).  It also apparently occurs in other spots, for a few bit times: tape marks seem to consist of two frames separated by a few clocks worth of blank space.  Ditto between data and block check frame(s), if I remember right.

> A tach signal is useful for adjusting the width of the "window" when
> deskewing.

Yes, that was my point: useful to make the process easier or to improve the quality of the result if the inputs are marginal, but you can make it work without a tach signal.

> I wonder if there's not a better way to attack the problem with some
> simple hardware.   The original posters mentioned an AVR Arduino as
> their initial platform, but cheap SBCs are available that run much, much
> faster.  Consider, for example, the RPi zero or the Orange Pi zero or a
> host other sub-$10 hosts running at a GHz or more.
> 
> You'd need level-shifting for a modern MCU/CPU anyway, as logic levels
> are most commonly 3.3V, not 5V.

Al's mention of that Saleae device fits there: you could plug that into any suitable fast enough computer, and it deals with analog data so you can do the threshold in software.  (Thanks Al, those look like nice devices.)

	paul