> On Jan 26, 2019, at 4:22 PM, Fritz Mueller via cctalk <cctalk@classiccmp.org>
> wrote:
>
> ...
> I don't think this is directly related to the parity abort issue, since Noel
> informs me that V6 Unix doesn't care at all, and I can also see under both
> OS's that after the recent repairs no parity faults are occurring on the MS11
> (it has an LED for that). The KT11 seems really solid now, too. But I
> suppose it could be some other early-CPU incompato?
I admit that I didn't read in depth, but I have the impression that RSTS tries
to identify the parity CSRs by forcing wrong parity and seeing which CSR
reports the issue. So if you have a CPU ECO issue that causes trap to 114 not
to work, I don't see how you could get RSTS to start at all.
Can you query the parity information (in defaults->memory->parity) and post the
result?
> I think this means I have to go back to working the problem from the other
> end -- analyze the core/crash files for clues on exactly what it going wrong.
> Paul: I'll see about retrieving a crash file from RSTS, now that I've
> cleaned up the memory system issues.
Great. You can feed it to a matching system in SIMH and run ANALYS on it. Did
I mentioned I looked at SDA, the interactive analyzer I wrote in Forth? It
won't work with that, since it's dependent on the data structures of a
particular release. I started that work long after RSTS V6C, so it looks like
ANALYS is all you get.
paul
