[Simh] An update on the UC15

[Bob Supnik]

I haven't forgotten about the project. I've just been busy on other 
things, like 35 years of neglected house repairs. ;)

The UC15 is another example of minimization of gates, a consequence of 
how expensive gates were at the opening of the TTL era. The DR15C, which 
was implemented in Flip Chips, has very little state, and it depends on 
the pair of DR11Cs, which were implemented in 74H series ICs, at the 
other end for quite a lot. You can't really speak of the DR15C as an 
independent device separate from the DR11Cs and vice-versa.

The DR15C has the following state:

TCBP_ACK (called DONE in the schematics) - TCBP read acknowledge - set 
by the PDP11 when it reads the TCB pointer register or by INIT. Cleared 
by IOT 706002 and friends. Tested by IOT 706001.

XFER_REQ - set by IOT 706004 and friends. Cleared by read of DR11C#2 
TCBP register. Shows up as DR11C#2 CS<7>. Cleared by INIT.

API_FLAG[0:3] - set by writes to DR11C#1 or #2 output buffers. Cleared 
by INIT or CAPI0..3. Tested by SAPI0..3. Masked with IE to create API 
interrupts requests. Readable on the PDP11 side in DR11C#1 input buffer. 
Negated logical OR (all API clear) is DR11C#1 CS<7>.

IE - masks API_FLAG[0:3] for generating interrupt requests. Readable by 
IOT 706102. Written by IOT 706122. Set by INIT.

BUF<0:17> - the output buffer (TCB pointer). Written by IOT 706004. Not 
touched by INIT; initial state is unpredictable. Readable in DR11C#1 and 
#2 input buffer. Not readable on the PDP15 side.

API_VEC[0:3]<0:6> - API vectors for levels 0..3. Written on PDP11 side 
via DR11C#1 and #2 output buffers. Not stored in the DR15C or the PDP15.

The master/slave communications protocol is interrupt driven on both sides.

1. PDP15 writes TCBP and clears TCBP_ACK. It must poll for TCBP_ACK 
first, because that flag is not wired to interrupt.

2. DR11C#2 CS<7> is set. If IE is set, the PDP11 is interrupted.

3. PDP11 reads TCBP. This clears DR11C#2 CS<7> and sets TCBP_ACK.

4. PDP11 uses address in TCBP to pick up a control block address and 
executes it. Control block specifies which API level and vector to use.

5. When execution is done, PDP11 writes API vector into the appropriate 
API level register.

6. If interrupts are enabled, PDP15 is interrupted. It now knows that 
the device operation has completed.

The availability of four API levels means that the PDP11 can easily 
process four IO requests in parallel. In fact, it can do more, by 
multiplexing multiple devices onto a single API level, but in practice 
there weren't that many devices on the PDP11.

The TCBP_ACK flag is only used to prevent overwriting of the PDP11s TCBP 
register if multiple requests are getting queued. It should be set only 
for the amount of time needed for the PDP11 to be interrupted and then 
read the TCBP. The all API done flag is not used by software; in fact, 
DR11C#1 CS isn't even defined in the PDP11 PIREX exec.

The UC15 supported a variety of PDP11 peripherals, but the only ones 
that matter are thethe RK11/18b, and the LP11. A console port was 
available for debugging, and sometimes a paper tape reader was added for 
the same purpose, but they weren't visible on the PDP15 side. The 
PDP11's clock was used for timing IO events but did not keep track of 
daytime.

/Bob