General TC11 DECtape diagnostic/formatter questions

[Paul Koning]

> On Nov 15, 2016, at 5:40 PM, Josh Dersch <derschjo at gmail.com> wrote:
> 
> ...
> 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.

Yes, commenting out that code is clearly a bug.  The RALL/WALL/WRTM functions are used in program I/O mode, so the CPU has to be ready with each new word as the tape finishes with the previous one.  Interrupts are most definitely supposed to be disabled.  DECtape formatting is a standalone activity, not something run under any OS.

RT-11 FB is likely to do a bit more stuff per clock interrupt, but either way, you're entirely correct that interrupts -- clock or otherwise -- need to be disabled.  The consequence of spurious interrupts might be a corrupt mark track, or wrong data written by the WALL pass, or verify errors during the RALL pass.

BTW, on RALL, it's actually possible to use DMA for the lower 16 bits of the 18 bit data.  The RT11 utility FILEX does that when reading PDP10 format tapes.  (I suppose the same might be true for WALL, I haven't heard of that being done.)  But the conventional way is to ignore the DMA and handle the data via the Data register plus the two extended data bits in the status register.

	paul