> On Nov 15, 2016, at 5:40 PM, Josh Dersch <[email protected]> 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
