[TUHS] RK overlapped seek emulation issue in Unix v4
Clem Cole via TUHS
tuhs at tuhs.org
Tue Jan 20 05:23:52 AEST 2026
Is the test just booting Unix v4 with the new code? Assuming your code is
in V3 of SIMH, I’ll need rebuild your tree with the code. But I’ll happy
to test it
Sent from a handheld expect more typos than usual
On Mon, Jan 19, 2026 at 2:09 PM Bob Supnik <bob at supnik.org> wrote:
> I have a new version of the RK emulator, which I think straightens out
> the overlapped seeks. I've run quick regressions on RT V4, Unix v5, and
> RSTS/E V10, to show that I didn't break any existing behavior. Before
> releasing it, though, I'd like to run a specific test on overlapped seek
> behavior, without having to debug in Unix v4. My PDP11 coding skills are
> rather rusty, so if anyone wants to take a crack at writing a specific
> test, feel free.
>
> The changes are in the V3 source, so they would have to be transposed to
> V4.
>
> On 1/16/2026 11:21 AM, Bob Supnik wrote:
> > Okay, I don't think the impact is as bad as I feared. The use of a
> > single word queue, rkintq, to maintain the controller and seek
> > interrupt flags, is probably okay. But in the current code, it is
> > cleared too aggressively and not set in some circumstances.
> >
> > I see four changes required.
> >
> > 1. rkcsr write
> >
> > - If clearing IE, clear the controller interrupt flag and the
> > interrupt request itself, but not the seek interrupt flags.
> > - If setting IE,
> > > If RDY = 1, and previous RDY = 0, then set the controller
> > interrupt flag.
> > > Regardless, if the interrupt queue is non-zero, set interrupt
> > request. This picks up any pending seek interrupts.
> >
> > 2. Operation initiation for any function that requires head motion
> > (that is, not control reset or set write lock)
> > - Clear the drive's seek interrupt flag and the controller interrupt
> > flag.
> > - Clear the interrupt request, because the controller will not
> > interrupt if it is busy.
> >
> > 3. Seek complete
> > - Set the drive's interrupt flag unconditionally, whether IE is set or
> > clear.
> > - If IE is set, and the controller is not busy (RDY = 1), set
> > interrupt request.
> >
> > 4. Set done
> > - Change the IE = 0 case to just clear the controller interrupt flag,
> > as well as the interrupt request. Do not change the seek interrupt flags.
> >
> > The interrupt acknowledge routine is okay. It acknowledges controller
> > interrupts first. If a seek interrupt, it knocks down the request and
> > sets the drive ID.
> >
> > So with these changes, if three drive seek interrupts get queued, they
> > will be serviced one at a time, after any controller interrupt. They
> > are not cleared, unless the controller is reset or a new operation is
> > initiated on that drive. As noted in the maintenance documentation,
> > the interrupt service routine must run at IPL 5 or higher; otherwise,
> > the seek interrupts will occur one right after another.
> >
> > There may be problems in the detailed status flags. It would be useful
> > to see the source code for the driver.
> >
> > Note that all this analysis has been done on the v3 source code. I
> > don't think v4 changed much except to add debug features.
> >
> > Bob Supnik
> >
> > On 1/16/2026 9:03 AM, Bob Supnik wrote:
> >> I don't think this logic has ever been tested before, because no DEC
> >> OS, and no previously available versions of Unix, used it.
> >>
> >> Going back to it after 30+(!) years, it certainly looks a suspect,
> >> primarily because the entire interrupt queue - controller plus seeks
> >> - is cleared whenever the simulator sees that RKCSR<IE> is clear.
> >> This would cause seek interrupts to be lost.
> >>
> >> The controller logic changed quite a bit between the original RK11C
> >> and the more common RK11D, but the descriptions are similar. The
> >> controller has eight MASK flops, one for each drive. These are set
> >> when the controller initiates a SEEK (or DRIVE RESET, in effect a
> >> seek) on a drive. The poll logic is active whenever RKCSR<RDY> is
> >> set, that is, the controller is idle. It monitors the MASK bits and
> >> the seek done signal from the drive. If both are set, RKCSR<IE> is
> >> set, and an interrupt is not already pending, it generates an
> >> interrupt request. If I look at the RK11D schematics, the mask flops
> >> are mass cleared only by a controller reset pulse; no other time.
> >>
> >> Tl;dr. The implementation of overlapped seeks is wrong, in several
> >> respects. Fixing it may require a significant rewrite. Ugh!
> >>
> >> Bob Supnik
> >>
> >>
> >>
> >
>
>
More information about the TUHS
mailing list