It looks like the problems RSTS is having with DMC/DMR is due to unexpected
behavior of the master clear bit. It's documented as self-clearing, so the
driver sets it and then subsequently assumes it will read as cleared. That
isn't actually happening correctly, at least not if two accesses are close
together:
DBG(4466384761)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, SEL0, newdata=0x4000,
olddata=0x8200
DBG(4466384761)> DMC REG: DMC0: Setting SEL0 (0x4000) MCLR
DBG(4466384764)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, BSEL0, newdata=23,
olddata=0x00
DBG(4466384764)> DMC REG: DMC0: Setting SEL0 (0x4023) MCLR RQI
This is the driver doing a master clear, quickly followed by a Request In
asking to set the Base address. That second operation is a byte write to
BSEL0, and it relies on MCLR being either write-only, or at least self-clearing
fast enough. In this case, clearly that is not working; MCLR is still set so
the byte write sets not just RQI and BASEI, but also MCLR -- so RDYI is never
set, the driver times out, and the cycle repeats.
This patch (hack?) fixes the issue, and now my two cross-connected DMCs
successfully start:
diff --git a/PDP11/pdp11_dmc.c b/PDP11/pdp11_dmc.c
index e0e0111..6034683 100644
--- a/PDP11/pdp11_dmc.c
+++ b/PDP11/pdp11_dmc.c
@@ -3592,7 +3592,7 @@ else {
if ((dmc_getsel(reg) == 0) || (dmc_getsel(reg) == 1)) {/* writes to SEL0 and
SEL2 are actionable */
if (0 == controller->dmc_wr_delay) { /* Not waiting? */
- controller->dmc_wr_delay = 10; /* Wait a bit before acting on the
changed register */
+ controller->dmc_wr_delay = 1; /* Wait a bit before acting on the
changed register */
sim_activate_abs (controller->unit, controller->dmc_wr_delay);
}
}
By the way, if I connect a DMC to a DMR, it doesn't come up. Is that expected?
I thought DMC and DMR were sufficiently compatible that it would work...
paul
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
