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 involved. 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. 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. Noel