On Wed, Nov 9, 2016 at 7:20 PM, Josh Dersch <dersc...@gmail.com> wrote:
> On 11/9/16 6:18 PM, Paul Koning wrote: > > On Nov 9, 2016, at 5:57 PM, Josh Dersch <dersc...@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
