16 Nov
2016
16 Nov
'16
7:47 p.m.
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