[Simh] KS10 and the DMR
Laziness doesn't pay .. For checking the DMR behavior I resorted to the 703 image distributed on the net. The fact that the DMR version V022 didn't line out with the monitor version 703, to search for all versions of D8RINT in the archives; a few were found. Since some distrust arose, I decided to stay at the safe side and to create a fresh 703 image with Decnet from the officially published distribution media. There then surfaces a version V016 of D8RINT which matches the 703 monitor; thus the published 703 medium (PaulAllen's) is somewhat spoiled with respect to version consistency. The D8RINT V016 compiles and links without flaw in a generated 703 monitor system, but it crashes in the same place in DEFCIR under the same conditions. Applying the same fix for it - insert a JCFL 0 noop before the status check nullifying the skip return - as with 704 leads to the same ultimate termination, in this case stopcode IME. At least here, there is no race condition with respect to Unibus mapping so that error in 704 is avoided. It is probably created when startup components were integrated in one SYSINI module in 704. If that problem is tentatively fixed in the SYSINI in version 704 there is the same kind of error as in 703. Further stepping back to Tops10-702 at the moment seems to be not possible as there currently are no 702 distribution media present. Best regards ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] KS10 and the DMR
Comparing the debugging results from Tops10 703 with 704 I decided to switch the test code base to D8RINT V016 and Tops10-703 since this version combination is closer to the original, of which Timothe reported it had run, and because with one code patch, of which one can be reasonably sure that it may be correct, the whole system gets more closer to the operational state and consequently more (register) DMR device interaction is seen. So it is also becoming closer to a case in which potentially wrong or unimplemented expected DMR behavior may start to influence a possible cause leading to the next perceived crash. At least on a preliminary glimpse, there seems to be some bits put in the DMR registers where there is no definition for in the Simh code base, but it still early in the debugging process an this can be seen wrongly. Needs a lot more of debugging and code tracing with venerable (E)DDT . ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
