27 Jan
2019
27 Jan
'19
1:34 p.m.
On Jan 26, 2019, at 4:22 PM, Fritz Mueller via cctalk
<cctalk at 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