PDP-11/45 RSTS/E boot problem

Noel Chiappa jnc at mercury.lcs.mit.edu
Tue Feb 5 07:36:05 CST 2019

    > From: Paul Koning

    > Another possibility occurs to me: bad bits in the MMU (UISAR0 register
    > ... if UISAR0 has a stuck bit so the "plain" case maps incorrectly
    > you'd expect to come up with execution that looks nothing at all like
    > what was intended.

One would hope that the DEC KT11 diagnostic would check for this... but just
to be thorough, we have in fact written a short diagnostic which stores every
possible value in each UISA register and checks that it's correct. So unless
there is some sort of pattern sensitivity (e.g. when A is in UISAm and B is in
UISAn), that's not it. Also, and perhaps more significantly, when checked
after the trap happens, all the UISA registers and all the KISA registers
contain correct data. So, unless it's something where _sometimes_ one reads
UISAn and gets X when it actually contains Y, I'm not sure the SARs (PARs) are

    > From: Jon Elson

    > OK, here's a really complicated thing to try. If you know the physical
    > memory address of ls when it has the problem

We do (see above), and we've also looked at what's in memory at that
location, and the low part of the text segment seems to be correct, but there
was junk at the top, around the target of the JSR (i.e. at 'csv'). Not just
one word, but everything around that location was wrong, which would suggest
to me that the cause is not a simple memory failure there.

I've suggested to Fritz that we look at that again, to see if what was
recorded before is accurate (i.e. if we see the same wrong contents), to make
sure we didn't make a mistake somehow.

    > write a machine language program that loads a copy of ls into that
    > location and then tries to read it back.

Yeah, it may come to that. One issue we've been having is doing specialized
test programmes; trying to run the C compiler fails. I don't know about the
assembler, though. And as Fritz mentioned, it takes hours to load a new disk
image. I think we've come up with a way around that, though; produce binary
of stand-alone tests elsewhere (I've often/always got a v6 running on
Ersatz-11 here), and load them into the /45's main memory with PDP11GUI.


More information about the cctalk mailing list