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.
A tach signal is useful for adjusting the width of the "window" when
deskewing.
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.
--Chuck