General TC11 DECtape diagnostic/formatter questions
derschjo at gmail.com
Wed Nov 9 15:43:53 CST 2016
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
> 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
> 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
More information about the cctech