3 Apr
2006
3 Apr
'06
11:18 a.m.
Tony wrote....
In one sense that's a step forward in that all DL11-Ws now behave in the
same way. It's likely (but not certain) that the fault is now elsewhere.
The 7414 is a pretty cheap chip, and not hard to
find (I think you want
to keep the same family as the original here, though -- that is don't use
a 74LS14). I would change it on the card where you know there's a problem
ansd see what happens.
Did that today. LTC is going through the schmitt trigger
just fine. The diag
no longer fails on "bit 7 stuck in LTC". Instead, it now locks up at the
same spot in the DL11-W diag as the other two DL11-W cards. Right after "01
devices under test", the machine just halts with the cursor still at the end
of that line. Here's where I'm trying to start. I was
looking at some of the code on this
website, hints for troubleshooting a dead PDP11. It's at:
http://www.psych.usyd.edu.au/pdp-11/hints.html
I enter and run the Line Time Clock Interrupt test from that webpage, and
the system halts at location 4. How on earth? Does the 11/45 have some
interrupts to specific locations for things like power fail or something?
It does. There are hardware traps for power failure, illegal address and
so on.
Others have pointed out that if it halt with the PC containing 4, it
really halted one location earlier (at address 2), and that means that
the most likely thing was a trap to location 0 (location 0 would contain
2, that would be loaded into the PC, and location 2 contains a halt
instruction. The '.+2 , HALT' is a common pair of words for unused
vectors for obvious reasons.
Vector 0 is not normally used, but AFAIK there's no _hardware_ reason why
it can't be used. In other words, if an interrupting device sends 0 onto
the data lines along with the INTR signal when asked to provide a vector,
then the processor will indeed vector via location 0.
OK, the correct interrupt vector, which should be supplied onto the
Unibus by the DL11-W card, is 100. Now that's just one bit different from
0.
So I would suggest 3 possibilites :
1) All your DL11Ws are providing the wrong vector. Unlikely, but possible.
2) For some reason the 100's bit (if you see what I mean) is getting lost
somewhere. Bad wireing on the backplane, a defective buffer on one of the
processor boards, etc
3) The processor is ignoring _all_ vectors and loading the address
register with 0.
I'll llook in the prints (but probably not tonight :-)) to see just how
the vector should be transfered round the processor. Then I can suggest
signals to check, etc.