How can one test a DEC M9313 "Unibus Exerciser and Terminator" (UET)?

Hi, all, Also in the same box with the DELQA was an M9313 UET module. It reminds me that I have a loooongstanding problem with my VAX8300... the Unibus interface (DWBUA) has been a problem since I moved the 8300 to my house 15 years ago. The machine works perfectly sans Unibus. It worked in its former location with Unibus. When I first got it home, I fried the DWBUA module - literally. There was a cracked IC and a burned trace. Some sort of cabling problem. I have replaced the cables, replaced the module (so except for the paddle card, pretty much a new system), and the last time I fired it up, I didn't get smoke, but it didn't come up as a Unibus. I have all the standard install docs and such. The normal arrangement is to have either some sort of DD-11 Unibus backplane in your BA32 CPU chassis *or* have long cables off the back of the VAXBI backplane to an external BA-11 with a standard DD-11DK or DD-11CK. I have the external BA11, the same one that was used with the 8300 in its former home. The "Unibus in" spot is filled with a paddle card that accepts the 4 cables from the user-defined area under the DWBUA module. The Unibus terminator *must* be a UET. The firmware on the DWBUA looks for it. I can tell from inspecting the BIIC registers on the DWBUA that my module is unhappy somehow with the UET. I have, now, 4 UETs. I think the last time I tested things, one or two gave me different BIIC-register results than the rest, suggesting that there are actual hardware problems with one or more of my UETs. The one I found tonight has probably not ever been plugged into a backplane by me, given what else I found in the box (*nothing* in the box has been plugged in since the box came home). What would help me increase my confidence about my testing procedure is how to actually *test* a UET. I have enough different sorts of hardware that I don't think I would have to get anything new to set up any sort of software test. I have close at hand an 11/04 and an 11/750, and can lay hands on various Unibus PDP-11s and an 11/750 without leaving town. The piece of the puzzle that I'm missing (and always have) is how to test it. AFAIK, it's a terminator and several loopback registers, but the specific nature of them is unknown to me. I presume that the termination is likely to be robust and probably not faulty - it's probably a problem with a bus driver/receiver or perhaps with some sort of internal register that the DWBUA firmware is writing to or reading back. There are a number of DEC-specific ICs, a lot of 74LS parts, some Nat'l Semi and AMD parts, and a few DIP resistor packs. There's one empty 24-pin 0.6" socket (which is empty on all the UETs I've seen, so it's either some sort of option or a test plug for some other use), and no jumpers what so ever. There are nine 8641 Unibus interface chips, but fortunately, I have a stack of those from COMBOARD spares. There are five DC013s, but I have those from COMBOARDs, too (two per board, socketed, thankfully). Before anyone suggests grant jumpers, I used to make dual-height grant modules. I always populate every slot with one so I don't have to worry about NPR (and because they are easier to remove than genuine G727 knucklebusters). I could probably figure out whatever I needed to from the UET maintenance printset (which I don't have handy, unfortunately), but I'm hoping that someone on the list has some experience that goes beyond just plugging one in and seeing no errors from the system. Perhaps someone has read a Field Service bulletin that talks about this module and perhaps they remember some useful fragment of the title or has a copy of it handy. I don't *think* either the primary or secondary Unibus adapters for the 11/750 care if there's a UET or even if they can directly tell there's a UET, and that's the system I have the most experience with. There may be some simple sort of ODT sequence that I could tickle the Unibus with and see clearly that "bit 4 is stuck" or something like that. If not, reading diagnostic source could be revealing about how it interacts with the UET registers. Thanks for any helpful tips and pointers. I miss having the Unibus on the 8300 - I can run and test COMBOARDs on it, which is one of the reasons I want to get it working - so I can go through the pile of stuff in the basement and scrap out the boards that didn't work then and aren't likely to work now. I have a few VAXBI COMBOARDs still, so one "fun" thing one can do is hook any two boards back-to-back through a (synchronous) modem eliminator (one board is told to be the "central", the other is the "remote") and move files around and exercise the software by pumping bytes from one process to another - you don't "need" a second machine to demonstrate HASP or 3780 (though it can be easier to explain when data are actually *moving* from one CPU to another). -ethan