How can one test a DEC M9313 "Unibus Exerciser and Terminator" (UET)?
ethan.dicks at gmail.com
Wed Apr 1 23:13:37 CDT 2009
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
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).
More information about the cctech