15 Nov
2016
15 Nov
'16
10:40 p.m.
On Wed, Nov 9, 2016 at 7:20 PM, Josh Dersch <derschjo at gmail.com> wrote:
On 11/9/16 6:18 PM, Paul Koning wrote:
On Nov 9, 2016, at 5:57 PM, Josh Dersch <derschjo at gmail.com> wrote:
errors
for all words in the block (though the reported word number doesn't
actually correspond in any meaningful way to the word on tape, per the
documentation); i just singled that one out for an example. They all show
the read data being the obverse complement of the expected data. I'll be
doing some serious debugging tomorrow...
- Josh
So a small update:
I spent some time probing various signals and I couldn't find anything
obviously wrong; while the failing diagnostic was running, the obverse
complement logic in the hardware was behaving as I'd expect (i.e. it wasn't
being used, since an RALL was in effect). I went so far as to write my own
little test program that does basically what the ZTCD diagnostic Test 0
does -- a WDATA (forward) followed by a RALL (forward) and a comparison of
the data, and everything came back clean.
But I gained a better understanding of how the TC11 hardware works and how
it's programmed, so that's always a good thing.
And that knowledge helped me when I went back to the RT-11 formatter to see
if I could work out what was going wrong there. As you recall, the
formatter was failing after writing the T&M tracks with a Data Miss (DATM)
error. Data Miss in this case would indicate the software not responding
in time to the READY signal during a RALL command, which is interesting --
this would seem to indicate more of a software problem than a hardware one.
I noticed the following commented-out line at the beginning of the program:
START:
; RESET ;CLEAR THE WORLD
; MOV #P7,PS ;LOCKOUT P1 BY RAISING CPU PRIORITY <<----
Uncommenting the MOV #P7,PS line allows the formatter to run properly.
It appears that interrupts (I'd guess the LTC interrupt) were taking
enough time away from the program to cause it to miss data; I'm
guessing it's because I'm running the FB monitor rather than the SJ
monitor, but I'm not familiar enough with RT-11 yet to know exactly
where to place the blame.
At any rate, at this point I'm able to format a tape, initialize it in
RT-11, and copy/verify files onto it without any issues. The failing
diagnostics are still puzzling, but I'm almost ready to throw in the
towel on them :).
- 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...
Yes, those two patterns are indeed obverse complement. Word 0054?
That's odd, if it's doing this wrong for a word in the middle of the
buffer. Can you have it halt on fail so you can examine the buffer?
paul
It's actually word 4 (transcription error on my half) and it reports