> From: Mattis Lind >> 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
> Would it be possible to insert a breakpoint or halt and run the > program, insert original instruction and single step? I'm not sure that's going to tell us much: the latest development is that Fritz looked at the actual memory contents again, and it is once again trash; _almost_ identical to what was there before: PA:171600: 016162 004767 000224 000414 006700 006152 006702 006144 but with some extra 010000 bits: PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144 (It's not clear if this represents a real difference, or if that front panel issue Fritz mentioned caused the contents to be displayed incorrectly.) The exciting thing is that if the latter really is what's in main memory, that '16700 16152' at the PC of the MM trap could indeed generate the MM trap we're seeing: it's "MOV 26364, R0", and that address is in segment (page) 1, which is only 03500 long.... If so, i) we're down to one problem (good news), and our problem turns into finding out how that section of the code got trashed (bad news). Which is not going to be simple, alas, I suspect. I don't think it's the RK11, because Unix reads the program image into system buffers in low memory, and that's clearly working OK in the 'sleep;ls' case. (It may not use the exact same buffers, though...) It then copies it out to the memory where it's going to execute from, using an MTPI loop. So maybe the memory still has issues, or maybe the MTPI isn't working with some main memory locations or or or... Noel