On Monday, January 4, 2016 at 11:38 AM, Paul Koning wrote:
> 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);
> }
> }
I vaguely remember that something else depends on how it is currently
implemented. The wait delay was added to accommodate the fact that something
didn't expect immediate response. A delay of 1 is essentially the same as no
delay.
It is hard to imagine that the OS driver would expect that the device would
complete some operation in one instruction time. This would tend to fail as
newer models of CPU were implemented which used the same peripheral hardware,
no?
> 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...
They absolutely should work as long as the both get turned on by software. The
wire protocol is the same. The wire protocol is also compatible to host based
DDCMP protocol implementations on the PDP10 and RSX since it can reliably talk
to KMC/DUP configurations.
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
