9 Nov
2016
9 Nov
'16
10:57 p.m.
On Wed, Nov 9, 2016 at 1:43 PM, Josh Dersch <derschjo at gmail.com> wrote:
On Wed, Nov 9, 2016 at 1:05 PM, Paul Koning <paulkoning at comcast.net>
wrote:
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
A quick update -- I ran the ZTCD diagnostics and they do fail, despite my
recollection (this is what I get for not taking notes at the end of
yesterday, and yesterday seems so far away now...). The first test (a
forward WALL, followed by an RALL of a single block) fails with the
following spew (for example):
BLKRQ 000310 DATA ERR WORD 00054. S/B 176376 WAS 104106
Based on a reading of the fiche listing (which is a slightly newer revision
of the binary I have) I believe S/B is the expected data and "WAS" is the
read-back data for a given word. Since one appears to be the obverse
complement of the other, it looks like the obverse complement logic is
running when it shouldn't be...
- Josh
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.
paul