On Wed, Nov 9, 2016 at 1:05 PM, Paul Koning <paulkon...@comcast.net> wrote:
> > > On Nov 9, 2016, at 3:32 PM, Josh Dersch <dersc...@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 > > paul > > >
