General TC11 DECtape diagnostic/formatter questions

[Josh Dersch]

On Wed, Nov 9, 2016 at 1:05 PM, Paul Koning <paulkoning at comcast.net> wrote:

>
> > On Nov 9, 2016, at 3:32 PM, Josh Dersch <derschjo at gmail.com> wrote:
> >
> > ...
> >
> > Now that I've gotten the full suite of diagnostics to run, the problem
> > seems to be that the TC11 isn't reading properly in reverse -- Tests
> > 15,16,21,22,26,27 and 34 of ZTCD fail, all others pass (modulo a marginal
> > block on the tape causing a failure here and there).  This would probably
> > explain why DTF fails immediately after writing T&M, since it works in
> > reverse from that point...
>
> Not necessarily.  I thought that reading direction simply changes the bit
> patterns seen by the electronics because the waveforms are reversed.  This
> is the famous "obverse complement".
>
> In the Mark track, reversing the direction means that you see the bits in
> the opposite order and complemented.  As I recall, the encoding takes
> advantage of this: the start of block code is the obverse complement of the
> end of block code (so that reversing means the "end" code now reads like
> "start").
>
> In the data, you have 3 bits parallel.  So there, reversing means that you
> get the 3 bits at a time reverse (think of octal digits reversed),
> complemented.  For 16-bit data, look at it as 18 bits with 2 bits unused.
>
> In Read-All and Write-All, the controller doesn't do anything for
> direction, so if you write in one direction data meant to be read in the
> opposite direction, the software has to supply obverse-complement format
> data.
>
> For regular Read and Write, the controller does handle direction change:
> the reverse commands do an obverse-complement on the supplied data words,
> so your data ends up word-wise reversed but the bits are in the expected
> spot and of the expected polarity.
>
> The second pass (after the WRTM) in the formatting program is a reverse
> direction WALL, so my comment that the hardware doesn't do anything special
> for direction applies there.
>
> A possibility is that the motor has a problem causing an excessive speed
> difference between forward and reverse.  But in any case, yes, scope and
> schematics seem needed here.
>

Those are good points.  It's clear from running the diagnostics (ZTCC, not
ZTCD, sorry for the important typo) that a Read in a reverse direction
fails (but writes seem to be OK in either direction -- the tests that do
forward reads, regardless of the write direction of the data universally
pass). So there's definitely a fault there, but as you point out it may be
a separate issue from the formatter problem.  Read-All and Write-All tests
(ZTCD) seem to be OK, but I'm going to re-run them just to be doubly-sure.
If those pass, I'm going to start with scoping out the OBVERSE ENB H
signals and the logic associated with them and see if there's anything
fishy there.

- Josh



>
>         paul
>
>
>