General TC11 DECtape diagnostic/formatter questions

[Josh Dersch]

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:
>
>>
>> > 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
>

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



>
>
>
>>
>>         paul
>>
>>
>>
>