> From: Fritz Mueller
> It looks like the question boils down to either "how did that part of
> the binary get to that part of memory?", or "how did we end up
> executing out of that part of memory?"
More the former, I think.
UISA0 contains 001614, and physical memory at 0161400 does contain the first
few instructions of the command's binary, so that 01614 is probably correct
for the base address of segment (page) 0, which contains all the code for the
command. (Without looking through the OS's guts, I can't confirm, from interal
data structures, that that's where it decided to put the command's binary.)
The PC at fault time is 010210, which is correct for the frame setup
function, CSV; and looking at the contents of the stack, registers etc makes
it pretty certain it had just done the "JSR R5, CSV" to get there. And
0161400 + 010210 = 0171610, which contains something completely different
from what's in the command binary at 010210!
> Could still be a memory issue _elsewhere_ that lands us there, of
> course... Could also be a translation error lurking in the KT11, or a
> CPU bug not found by any of the DEC diagnostic suites.
Yup. Like I said, good news is we're down to one problem; bad news is it's
a Duesie!
Noel
