Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 6/7/83; site hao.UUCP Path: utzoo!linus!philabs!seismo!hao!hull From: hull@hao.UUCP (Howard Hull) Newsgroups: net.unix-wizards Subject: Re: Update on zero UNIBUS interrupt vector problem Message-ID: <654@hao.UUCP> Date: Sat, 1-Oct-83 19:47:49 EDT Article-I.D.: hao.654 Posted: Sat Oct 1 19:47:49 1983 Date-Received: Sun, 2-Oct-83 11:00:16 EDT References: <12062@sri-arpa.UUCP> Organization: High Altitude Obs./NCAR, Boulder CO Lines: 73 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