General TC11 DECtape diagnostic/formatter questions
derschjo at gmail.com
Tue Nov 15 16:40:36 CST 2016
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:
>>> 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
>>> 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?
>> It's actually word 4 (transcription error on my half) and it reports
> 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:
; 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 :).
More information about the cctalk