M8264 No-SACK Timeout Module - Revision history

Jnc: Clarify

2025-08-05T17:37:43Z

Clarify

← Older revision		Revision as of 17:37, 5 August 2025
Line 25:		Line 25:
	The M9302 does a very similar thing to the M8264, 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?		The M9302 does a very similar thing to the M8264, 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).		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 (which has a separate answer, 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.)		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.)

Jnc: /* Functionality discussion */ An open grant line will freeze the machine

2024-08-25T11:28:39Z

Functionality discussion: An open grant line will freeze the machine

← Older revision		Revision as of 11:28, 25 August 2024
Line 31:		Line 31:
	The M8264 was apparently the first attempt to deal with this; later, the CPU was modified to put the grant timeout circuit back in.		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 [[transistor-transistor logic\|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.		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 (hanging the machine so that it will not run at all; this is fairly easy to recognize and fix). That is because the resulting 'open' input to the [[transistor-transistor logic\|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==		==External links==

Jnc: /* Functionality discussion */ clarify

2022-04-20T14:41:42Z

Functionality discussion: clarify

← Older revision		Revision as of 14:41, 20 April 2022
Line 23:		Line 23:
	"As a result of this [SACK turnaround] circuitry [on the [[M9302 UNIBUS terminator\|M9302]]], the SACK timeout feature found on other processors is not required"		"As a result of this [SACK turnaround] circuitry [on the [[M9302 UNIBUS terminator\|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?		The M9302 does a very similar thing to the M8264, 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).		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).

Jnc: another possible cause of unused grants

2022-04-20T14:39:42Z

another possible cause of unused grants

← Older revision		Revision as of 14:39, 20 April 2022
Line 15:		Line 15:
	==Functionality discussion==		==Functionality discussion==

	How can a [[bus grant]] go unused? 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.		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:		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:

Jnc: /* Functionality discussion */ Fix mistake in potential cause (broken grant line will jam SACK)

2022-04-02T08:34:48Z

Functionality discussion: Fix mistake in potential cause (broken grant line will jam SACK)

← Older revision		Revision as of 08:34, 2 April 2022
Line 23:		Line 23:
	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?		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?

	~~One possibility is that there are~~ circumstances in which the M9302 'solution' ~~doesn~~'t work; ~~for example~~, ~~if there's a break~~ in the ~~grant line (perhaps~~ a ~~missing [[~~grant ~~continuity card]]) down-stream from the device (so the system usually works)~~, ~~before~~ it ~~gets~~ to the M9302 (~~which can turn the grant around as a SACK~~)~~; then~~, ~~if an~~ '~~unused' grant happens, a CPU without~~ a grant ~~timeout circuit will hang!~~		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).

	~~The M8264 was apparently~~ the ~~first attempt~~ to ~~deal with this. It is timer based~~, ~~and~~ it ~~doesn't need~~ the ~~intact grant line to~~ the ~~terminator required for turnaround~~. So the ~~system won~~'~~t lock even if there is a broken~~ grant ~~chain~~ - or ~~a poorly behaved or hung device eating grants~~.		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.)

	~~(Another possible cause is a device which is malfunctioning: not passing a grant along, but eating it, but without doing~~ the ~~interrupt cycle~~ with the CPU~~. So either a hard-failed component in~~ the grant~~-passing~~ circuit~~, or some design flaw~~.)		The M8264 was apparently the first attempt to deal with this; later, the CPU was modified to put the grant timeout circuit back in.

	~~<!-- If~~ there's a ~~broken~~ grant ~~chain~~, ~~then~~ the M9302 will jam SACK on. ~~The M8264 could not even be there, and nothing would be any different. Same thing if~~ the ~~CPU asserts a~~ grant in ~~response to a now~~-~~removed interrupt request:~~ the M9302 will ~~jam SACK on~~, ~~etc~~, ~~etc~~.		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 [[transistor-transistor logic\|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.

	In trying to think up _any_ circumstance in which the M8264 will assert SACK, 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 (ditto). (It can't be a glitch; it has to be a permanent thing which prevents passing the grant.)
	~~-->~~
	==External links==		==External links==

Jnc: Cover this obscure thing

2022-04-01T21:15:33Z

Cover this obscure thing

New page

[[Image:M8264_No-SACK_Timeout_Module.jpg|300px|thumb|right|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 [[UNIBUS and QBUS termination#SACK turnaround|grant timeout circuit]] which is not included in those two [[Central Processing Unit|CPUs]].

It was a [[DEC card form factor|quad]] format card, which plugged into any available [[Small Peripheral Controller|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 line]]s 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 [[peripheral|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 [[Light Emitting Diode|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? 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 UNIBUS terminator|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?

One possibility is that there are circumstances in which the M9302 'solution' doesn't work; for example, if there's a break in the grant line (perhaps a missing [[grant continuity card]]) down-stream from the device (so the system usually works), before it gets to the M9302 (which can turn the grant around as a SACK); then, if an 'unused' grant happens, a CPU without a grant timeout circuit will hang!

The M8264 was apparently the first attempt to deal with this. It is timer based, and it doesn't need the intact grant line to the terminator required for turnaround. So the system won't lock even if there is a broken grant chain - or a poorly behaved or hung device eating grants.

(Another possible cause is a device which is malfunctioning: not passing a grant along, but eating it, but without doing the interrupt cycle with the CPU. So either a hard-failed component in the grant-passing circuit, or some design flaw.)


==External links==

* [http://www.bitsavers.org/pdf/dec/pdp11/1134/MP00082_1134_Vol2_Sep76.pdf 11/34 Vol. 2 Field Maintenance Print Set] - the M8264 is covered pg. 149 of the PDF

[[Category: PDP-11 UNIBUS Processors]]