Update on zero UNIBUS interrupt vector problem

[Howard Hull]

doned bus requests, since an
	    interface that has been reset (probably by internal microcode)
	    will thereafter allow bus grants to pass freely.  The active
	    terminator will assert BUS SACK if it sees any request.  The
	    processor/arbitrator *will not* interpret this as a zero
	    interrupt vector *unless* somebody (anybody) asserts BUS INTR,
	    places a vector on the bus, and then drops away just after
	    negation of BUS SACK by the M9303.

	2. The "Grant Blocking"/"Grant Stealing"/"Passive Release" action
	    of controllers is not a common feature of all DMA interfaces.
	    they have to be deliberately jumpered to obtain it.  The event
	    occurs when the interface in question receives a *priority*
	    grant (not an NPG) at the level of its status reporting unit
	    and simultaneously sees NPR on the bus.  In order to reduce
	    the latency in behalf of the DMA interface requesting the bus
	    (whichever interface that might be) the priority interrupt
	    controller on the interface in question blocks the priority
	    grant from interfaces installed further down the bus, and
	    asserts BUS SACK.  When the arbitrator sees the SACK, it then
	    negates the priority grant.  The interface in question then
	    negates the SACK, and the arbitrator, seeing SACK negated in
	    absence of an assertion of BUS BBSY, BUS INTR or MSYN, asserts
	    NPG for the DMA device.  Obviously, the behavior of the bus will
	    depend on how close to the front of the bus (more in terms of the
	    number of interfaces than in terms of distance) the interface
	    in question has been installed.  Also, double obviously, this
	    is a supreme moment for another microcoded (and thus confused)
	    interface to assert (erroneously) BUS BBSY and BUS INTR without
	    even knowing what vector it wants to put on the data lines
	    (so *no vector*).

	3. A DMA interface can work EVEN IF THE NPG LINK HAS NOT BEEN CUT
	    provided that it is the last DMA device on the Unibus prior to
	    the terminator.  The only problem that may occur is a due to
	    possible differences in timing between the interface's SACK
	    assertion, and the "me too" SACK of the active terminator.
	    The fun begins when an unsuspecting (thus foolish) installer
	    adds a new DMA interface to the bus behind the one with the
	    uncut link.  The poor fellow goes crazy trying to figure out
	    what is wrong with *his* installation that causes both DMA 
	    interfaces (whose data, addresses and vectors are going to be
	    "wire or'd") to fail all of the diagnostics.

	4. The best method I know of to "scope" a Unibus is to first check
	   all 56 of the Unibus levels with the computer in halt mode (this
	   will reduce the amount of bus activity to either none or nearly
	   none, depending on the processor and DMA devices installed).
	   Look for +3.4 to +3.7 volts for zeros, +0.3 volts for ones.
	   Anything "resting at 1.5 volts" is suspect.  ACLO and DCLO are
	   usually less than 3 volts, though.  Then start the system and
	   put the scope on BRx, BGx, BBSY, SACK, INTR, MSYN, SSYN one at
	   a time with the scope set up to see glitches of about 100 ns.
	   Detect these using AC sync, either + or - slope, and slowly
	   rotating the Trigger Level control through its range.  Turn
	   the trace brightness up far enough that you can see the faint
	   stuff near the trigger edge against the brighter regular cycles.
	   Normal Unibus activity will not have high-low-high or low-high-
	   low control signal transitions shorter than around 275 ns.
	   A Tek 475A scope is ideal for this sort of work because of
	   its fast write.
So.
You're welcome in advance!     YT,  Howard Hull
 {ucbvax!hplabs | allegra!nbires | decvax!brl-bmd | harpo!seismo | menlo70}
       		        !hao!hull