General TC11 DECtape diagnostic/formatter questions
derschjo at gmail.com
Wed Nov 9 16:57:54 CST 2016
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>
>> > 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
>> > block on the tape causing a failure here and there). This would
>> > 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
> 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...
More information about the cctalk