General TC11 DECtape diagnostic/formatter questions

[Josh Dersch]

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