9 Nov
2016
9 Nov
'16
3:43 p.m.
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
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