11 Jan
2011
11 Jan
'11
7:28 p.m.
On 12/01/2011 02:50, Charles Morris wrote:
Thanks to Pete Turnbull's FindCSR (entering it
once by hand was
enough)
Yes, that I believe!
and reading another manufacturer's DHV11/16
documentation
dug up on Bitsavers, I now know my CSR.
Well done!
Actually, two of them, 160140 and 160160, since I have
learned that a
DHV11/16 appears to the 11/23+ as two DHV11 8-line cards with
consecutive address spaces modulo 20 octal.
Actually, I should have remembered that myself :-(
Then I could run the various DHV11 diagnostics from my
XXDP pack, and
the first time through on VDHAE0, it found the card but stopped on an
ILL INT 430 error. So I took the hint and entered 430 instead of the
default 300 for the vector interrupt address. Then Unit 1 passed the
tests, but Unit 2 had an ILL INT 440 error. Another clue :) With 440
for the 2nd vector it passed all tests.
Unusual vectors. BTW, if you ever need to find out what vector
something is using, and can make it interrupt, you can set up a "trap
catcher". This is also used to identify what device is causing
interrupts or traps if you're getting rogue ones. Basically you fill
the vector space (or floating vector space) with pairs of words, where
the first word for each vector is the address of the next word, and the
next word contains a zero. This has the effect that, when the CPU uses
the vector, it sets the program counter to the address indicated by the
forst word in the vector, and then executes the code there -- and as
zero is a HALT instruction, that's what it does. And if it's using
console ODT, it also prints out the address it halted at, so you can
identify the vector it used. To use the trap catcher, set up the
vectors, set up a short loop somewhere else in memory (1000 is a common
place), set the CPU executing the loop, and wait for an interrupt.
--
Pete Peter Turnbull
Network Manager
University of York