>> (I have yet to check and see if the KY11-LB asserts SACK if the CPU
>> halts on its own accord - probably 'yes', but that's a project for
tomorrow.)
Yes, it does. I toggled in the following program:
5000
5200
776
0
(what, you all can't program a PDP-11 in octal? :-) and hit 'start' and the
SACK light on the UA11 flashed out and came back on when the machine finally
halted.
So then I looked at CPU tech manual for the KD11-E, and the HALT instruction
seems to act exactly like the console has requested a processor halt; it just
sets the HLT RQST signal (see Section 4.5.5 "Operate Instructions").
So, either (console halt, or a HALT instruction) will cause the identical
response in the processor; see Section 4.10.3 "Halt Grant Requests": the CPU
sends HLT GRANT to the console, which returns SACK. As long as SACK is
asserted, the processor waits with its clock inhibited:
"The user can maintain the processor in this inactive state (Halted)
indefinitely. When the HALT switch is released, the user's console releases
BUS SACK L, and the processor continues operation"
This text is obviously for the KY11-LA; the KY11-LB will operate identically:
when the console releases SACK, the processor resumes operation.
> From: Fritz Mueller
>> when I powered the machine on, it turned out that something was
>> asserting SACK when the machine was halted
> That is quite interesting, and not what I would have expected!
Yes, I was quite surprised; I didn't expect that either. Now that I know that
the KY11-LB uses it to talk to the KD11, I can work around it, though.
I'll have to write all this up to warn others about it.
>> The thing that's puzzling me is that the M8264 seems to exactly
>> replicate the functionality of the M9302, with an 'unused' bus grant
>> being turned into a SACK. So I don't understand the point of the M8264.
> I think the only difference would be that since the M8264 is timer
> based, it doesn't need the intact end-to-end path required for
> turnaround. So your bus won't lock even if you have a broken grant
> chain or a poorly behaved or hung device eating grants.
You are right about it being timer-based, but I'm not sure the conclusion
follows, at least exactly as stated.
If there's a broken grant chain, then as you originally pointed out, 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.
I'm racking my brain to think up _any_ circumstance in which the M8264 will
assert SACK. in which the M9302 wouldn't. Thinking it through, 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). So some device has to be malfunctioning: not passing a grant along,
but eating it. So either a hard-failed component in the grant-passing
circuit, or some design flaw. (It can't be a glitch; it has to be a permanent
thing which prevents passing the grant.)
I suppose that's possible, but I can't see any othey way.
Noel
