[HECnet] DMC11 in next simh version... looks nice, and question about TOPS-10

[Paul_Koning at Dell.com]

On Jan 5, 2013, at 4:15 PM, Rob Jarratt wrote:

...
Actually I meant the code you added to the pdp11_dmc.c file, but the above
is still useful

diff --git a/PDP11/pdp11_dmc.c b/PDP11/pdp11_dmc.c
index dae4db0..c367e4c 100644
--- a/PDP11/pdp11_dmc.c
+++ b/PDP11/pdp11_dmc.c
@@ -809,12 +809,13 @@ void dmc_dumpregsel0(CTLR *controller, int trace_level, char * prefix, uint16 da
                sim_debug(
                        trace_level,
                        controller->device,
-                       "%s SEL0 (0x%04x) %s%s%s%s%s%s%s%s\n",
+                       "%s SEL0 (0x%04x) %s%s%s%s%s%s%s%s%s\n",
                        prefix,
                        data,
                        dmc_bitfld(data, SEL0_RUN_BIT, 1) ? "RUN " : "",
                        dmc_bitfld(data, SEL0_MCLR_BIT, 1) ? "MCLR " : "",
                        dmc_bitfld(data, SEL0_LU_LOOP_BIT, 1) ? "LU LOOP " : "",
+                       dmc_bitfld(data, SEL0_ROMI_BIT, 1) ? "ROMI " : "",
                        dmc_bitfld(data, SEL0_RDI_BIT, 1) ? "RDI " : "",
                        dmc_bitfld(data, SEL0_DMC_IEI_BIT, 1) ? "IEI " : "",
                        dmc_bitfld(data, SEL0_DMC_RQI_BIT, 1) ? "RQI " : "",
@@ -2105,6 +2101,14 @@ void dmc_process_command(CTLR *controller)
                {
                        dmc_start_input_transfer(controller);
                }
+               else if (dmc_is_dmc (controller) &&
+                                 controller->csrs->sel0 & ROMI_MASK &&
+                                 controller->csrs->sel6 == DSPDSR)
+                       /* DMC-11 or DMR-11, see if ROMI bit is set.   If so, if SEL6 is
+                             0x22b3 (read line status instruction), set the DTR bit in SEL2.   */
+               {
+                       dmc_setreg (controller, 2, 0x800, 0);
+               }
        }
}

diff --git a/PDP11/pdp11_dmc.h b/PDP11/pdp11_dmc.h
index bfa9104..cfacc5b 100644
--- a/PDP11/pdp11_dmc.h
+++ b/PDP11/pdp11_dmc.h
@@ -90,6 +90,7 @@ extern int32 int_req[IPL_HLVL];
#define DMC_RDYI_MASK 0x0080
#define DMC_IEI_MASK 0x0040
#define DMP_IEI_MASK 0x0001
+#define ROMI_MASK 0x0200
#define LU_LOOP_MASK 0x0800
#define MASTER_CLEAR_MASK 0x4000
#define RUN_MASK 0x8000
@@ -107,9 +108,12 @@ extern int32 int_req[IPL_HLVL];
#define LOST_DATA_MASK 0x0010
#define DISCONNECT_MASK 0x0040

+#define DSPDSR 0x22b3             /* KMC opcode to move line unit status to SEL2 */
+
#define SEL0_RUN_BIT 15
#define SEL0_MCLR_BIT 14
#define SEL0_LU_LOOP_BIT 11
+#define SEL0_ROMI_BIT 9
#define SEL0_RDI_BIT 7
#define SEL0_DMC_IEI_BIT 6
#define SEL0_DMP_IEI_BIT 0




By the way, the background for this can be found in the KMC-11 manual.
Next, once DSR has been seen on for 2 seconds, it does another master
clear, then the Base In operation.

Since Master Clear needs to drop the connection, I don't think that tying
DSR
to the connection being alive will work.   It does seem like an obvious
thing to
do, but that second master clear suggests it isn't the way to go.


Not sure I follow. It seems to be that the driver is using DSR just to tell
it that the line is up. Of course if we use Master Clear to close the
connection then that would not work, but if we didn't close the connection
then it would work. Wouldn't it?

Yes.   But since drivers use MCLR to kill the DDCMP connection, you need to close the connection on MCLR, otherwise the cleanup on DDCMP restart isn't emulated.

...
Ok, but then why did I see a "Discarding received data while controller is
not
running" message?   That's the problem, I believe.



I don't often set the level of tracing that would give this message, but
even when I have, I have not seen this message. It happens if the receiving
end has not made any buffers available yet. There is not enough protocol
between the two ends to do it correctly, we would probably have to implement
DDCMP. I would argue that in practice it does not have a significant effect,
circuits do get established and DECnet can operate over the link without
seeing any errors, at least on VMS, not sure about other OSs which may
implement their drivers differently. I would have to test a bit more to be
fully sure of all this though as I usually start both ends more or less at
the same time, it might happen if there is a significant delay between
starting DECnet at each end.

DDCMP links aren't supposed to lose packets.   As it happens, it looks like the DECnet machinery does recover from such a packet loss, but still, it's not expected behavior.

	paul