M8264 No-SACK Timeout Module

M8264 Timeout Module card

The M8264 No-SACK Timeout Module is rare, little-known, poorly-documented optional UNIBUS board for the KD11-D CPU of the PDP-11/04 and the KD11-E CPU of the PDP-11/34.

It provides the grant timeout circuit which is not included in those two CPUs.

It was a quad format card, which plugged into any available SPC slot. The M8264 doesn't tie into the CPU, it just looks at UNIBUS lines, so it can be plugged into any UNIBUS machine (near the start of the bus, since the bus grant lines it monitors are wired sequentially).

EK-KD1EA-MM-001 Section 4.7.2.4, "No-SACK Timeout Circuitry", shows a very similar circuit to that of the M8264 (see link below), and says it "asserts BUS SACK ... [if the device] does not assert SACK within 22 usec after a grant line has been enabled." Presumably the M8264 does the same thing.

(The M8264 also has a synchronous 4-bit up/down counter, but that's apparently just there to count timeout events, and display the count in some LEDs - probably just to make sure it isn't happening too often.)

The M8264 was later dropped when the KD11-EA CPU, with a grant timeout circuit built in, came out.

Functionality discussion

How can a bus grant go unused? There are several possible causes for an unused grant. One possibility is that noise on a request line will look to the arbitrator (in the CPU) like a valid request.

Another possibility is that if a device requests a grant (i.e. posts an interrupt request), and then drops the request at just the right time (perhaps because the device is reset), a grant will be sent out when there's no device waiting to take it.

EK-11034-OP-PRE2 gives a clue as to how the problem with grant timeouts which the M8264 solved started. In 3.10.2, "End-of-Bus Terminator", it says:

"As a result of this [SACK turnaround] circuitry [on the M9302], the SACK timeout feature found on other processors is not required"

The M9302 does a very similar thing, at a high level - prevents unused bus grants from hanging the machine - albeit with a different mechanism (by turning an 'unused' bus grant into a SACK). However, therein lies a mystery: the M9302 appears in EK-11034-OP-PRE2 (above), and one can deduce that the M8264 was produced after that came out, and post-dates the M9302 - but it fixes the same potential CPU hang issue. The M8264 thus seems to exactly replicate the functionality of the M9302. So why was it produced?

There must be circumstances in which the M9302 'solution' will not 'work', but the M8264 will; scenarios in which the M8264 will assert SACK, but in which the M9302 wouldn't. There has to be a grant, but it can't get to the M9302 (because otherwise it would do its thing), but that failure to get there can't be simply a broken grant chain (below).

One example would be a poorly behaved or malfunctioning device: not passing a grant along (for the M9302 to turn around), but 'eating' it, but without doing the interrupt cycle with the CPU. So either a hard-failed component in the device's grant-passing circuit, or some design flaw. (If the system is using an old-style M930 UNIBUS terminator, without SACK turnaround, an unused grant could also hang the system; but switching to an M9302 would be easier than an M8264.)

The M8264 was apparently the first attempt to deal with this; later, the CPU was modified to put the grant timeout circuit back in.

Note that if there's any break in the grant line (perhaps a missing grant continuity card) at any point before it gets to the M9302, the M9302 will jam SACK on. That is because the resulting 'open' input to the TTL gate monitoring the grant line in the device immediately down-stream from the break (perhaps in the M9302) will float high, thereby looking like a permanent incoming grant, which will be turned around by the M9302 as a permanent assertion of SACK.

External links

• 11/34 Vol. 2 Field Maintenance Print Set - the M8264 is covered pg. 149 of the PDF