On Wed, Nov 9, 2016 at 1:43 PM, Josh Dersch <dersc...@gmail.com> wrote:
> > > 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 > 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 >> >> >> >
