19 Nov
2021
19 Nov
'21
9:33 p.m.
I updated the remark by Bob with this in my update and could not find that
back in your copy of the mail transcript:
Before I get a storm this from Pdp11_dup.c should accompany it:
The wire protocol implemented is native DDCMP WITHOUT the DDCMP SYNC
characters both initially and between DDCMP packets.
Reindert
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Mark Pizzolato - Info Comm
Sent: Friday, 19 November, 2021 21:18
To: R. Voorhorst <R.Voorhorst at swabhawat.com>; hecnet at Update.UU.SE
Subject: RE: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should be
Ddcmp --> Re:4 --> Cryptic -->Dup11 simh only for Ddcmp --> update
On Friday, 19 November, 2021 at 20:42, Reindert wrote:
Yes, that is how Pdp10 KS10 and Vax and Rsx and Rsts
all interface to
the Dmc/Dmr offered layer and for Anf10 on Pdp10 as well.
But trying Decnet on bare Dup11 will reveal all.
However this will fail on simh: look at the comment in Pdp11_dup.c
from
Bob:
dup DUP11 Unibus/DPV11 Qbus bit synchronous interface
This module implements a bit synchronous interface to support DDCMP.
Other
synchronous protocols which may have been supported on the
DUP11/DPV11
bit
synchronous interface are explicitly not supported.
So the 0,01 % rises to 100% that it will not work as bare sync device
I don't see what you're saying will fail. The comments very explicitly say
that DDCMP will work. Other possible uses of the DUP11/DPV11 will not work.
The reason they wouldn't work when this pdp11_dup.c was written was due to
the lack of software on the PDP11 side and something on the other end of a
conversation to talk to. If such a useful test case existed the
functionality in the pdp11_dup.c code could be extended to support it.
- Mark
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On
Behalf Of Paul Koning
Sent: Friday, 19 November, 2021 17:23
To: hecnet at update.uu.se
Subject: Re: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should
be Ddcmp --> Re:4 --> Cryptic
I assume it means that RSX (and RSTS too) lets you use a DMC directly
from an application as an I/O device you can open. If so, you get a
packet service that lets you transmit whatever packets you want, which
will be sent encapsulated in DDCMP protocol. In the RSX case I'd
assume that includes support for maintenance mode (in RSTS that isn't
supported).
paul
On Nov 19, 2021, at 11:14 AM, R. Voorhorst
<R.Voorhorst at swabhawat.com>
wrote:
Please can you explain your second sentence somewhat? I read: "...
the
Ddcmp layer ... it does present it as a device ...". I do not perceive
the connotation.
Reindert
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Friday, 19 November, 2021 14:46
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] ANF10 network --> DN200 (RJE, Decnet) -->
should
be
Ddcmp --> Re:4
RSX definitely can use a DUP11 standalone through DECnet. In which
case
it's software side DDCMP.
Heck, you can also use the DDCMP layer yourself, without involving
DECnet.
It does present it as a device to the system on which you can
send/receive packets.
>
> Johnny 
19 Nov
19 Nov
9:52 p.m.
New subject: ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --> MarkP
On Friday, November 19, 2021 at 12:33 PM, Reindert wrote:
I updated the remark by Bob with this in my update and
could not find that
back in your copy of the mail transcript:
Before I get a storm this from Pdp11_dup.c should accompany it:
The wire protocol implemented is native DDCMP WITHOUT the DDCMP
SYNC
characters both initially and between DDCMP packets.
I still don't understand your problem. The wire protocol is PACKETS, NOT bytes.
The packets are transported over either UDP (as UDP packets) OR via TCP with
a 2 byte packet header indicating the data length. Any packet length is NOT
presented across the simulator<->pdp11_dup device, just the data. On transmit
any interpacket bytes that are the DDCMP_SYNC character are stripped BEFORE
the packet data is presented to UDP or TCP for outbound delivery.
- Mark
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf
Of Mark Pizzolato - Info Comm
Sent: Friday, 19 November, 2021 21:18
To: R. Voorhorst <R.Voorhorst at swabhawat.com>; hecnet at Update.UU.SE
Subject: RE: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should be
Ddcmp --> Re:4 --> Cryptic -->Dup11 simh only for Ddcmp --> update
On Friday, 19 November, 2021 at 20:42, Reindert wrote:
Yes, that is how Pdp10 KS10 and Vax and Rsx and
Rsts all interface to
the Dmc/Dmr offered layer and for Anf10 on Pdp10 as well.
But trying Decnet on bare Dup11 will reveal all.
However this will fail on simh: look at the comment in Pdp11_dup.c
from
Bob:
dup DUP11 Unibus/DPV11 Qbus bit synchronous interface
This module implements a bit synchronous interface to support DDCMP.
Other
synchronous protocols which may have been supported on the
DUP11/DPV11
bit
synchronous interface are explicitly not supported.
So the 0,01 % rises to 100% that it will not work as bare sync device
I don't see what you're saying will fail. The comments very explicitly say
that DDCMP will work. Other possible uses of the DUP11/DPV11 will not
work.
The reason they wouldn't work when this pdp11_dup.c was written was due
to
the lack of software on the PDP11 side and something on the other end of a
conversation to talk to. If such a useful test case existed the
functionality in the pdp11_dup.c code could be extended to support it.
- Mark
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On
Behalf Of Paul Koning
Sent: Friday, 19 November, 2021 17:23
To: hecnet at update.uu.se
Subject: Re: [HECnet] ANF10 network --> DN200 (RJE, Decnet) --> should
be Ddcmp --> Re:4 --> Cryptic
I assume it means that RSX (and RSTS too) lets you use a DMC directly
from an application as an I/O device you can open. If so, you get a
packet service that lets you transmit whatever packets you want, which
will be sent encapsulated in DDCMP protocol. In the RSX case I'd
assume that includes support for maintenance mode (in RSTS that isn't
supported).
>
> paul
>
> > On Nov 19, 2021, at 11:14 AM, R. Voorhorst
> <R.Voorhorst at swabhawat.com>
> wrote:
> >
> > Please can you explain your second sentence somewhat? I read: "...
> > the
> Ddcmp layer ... it does present it as a device ...". I do not perceive
> the connotation.
> >
> >
> > Reindert
> >
> > -----Original Message-----
> > From: owner-hecnet at Update.UU.SE [mailto:owner-
> hecnet at Update.UU.SE] On
> Behalf Of Johnny Billquist
> > Sent: Friday, 19 November, 2021 14:46
> > To: hecnet at Update.UU.SE
> > Subject: Re: [HECnet] ANF10 network --> DN200 (RJE, Decnet) -->
> > should
> be
> Ddcmp --> Re:4
> >
> > RSX definitely can use a DUP11 standalone through DECnet. In which
> > case
> it's software side DDCMP.
> >
> > Heck, you can also use the DDCMP layer yourself, without involving
> DECnet.
> It does present it as a device to the system on which you can
> send/receive packets.
> >
> > Johnny 
10:01 p.m.
New subject: ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --> MarkP
On Nov 19, 2021, at 3:52 PM, Mark Pizzolato - Info
Comm <Mark at infocomm.com> wrote:
On Friday, November 19, 2021 at 12:33 PM, Reindert wrote:
But how does that process know how to turn a sequence of bytes written to the DUP transmit
register into a packet? To do so, it must know what the particular packet format is. If
a driver is sending BISYNC data, your packet framing algorithm is entirely different from
what it is for DDCMP.
paul
I updated the remark by Bob with this in my
update and could not find that
back in your copy of the mail transcript:
Before I get a storm this from Pdp11_dup.c should accompany it:
The wire protocol implemented is native DDCMP WITHOUT the DDCMP
SYNC
characters both initially and between DDCMP packets.
I still don't understand your problem. The wire protocol is PACKETS, NOT bytes.
The packets are transported over either UDP (as UDP packets) OR via TCP with
a 2 byte packet header indicating the data length. Any packet length is NOT
presented across the simulator<->pdp11_dup device, just the data. On transmit
any interpacket bytes that are the DDCMP_SYNC character are stripped BEFORE
the packet data is presented to UDP or TCP for outbound delivery.
- Mark
10:15 p.m.
New subject: ANF10 network --> DN200 (RJE, Decnet) --> should be Ddcmp --> MarkP
On Friday, November 19, 2021 at 1:02 PM, Paul Koning wrote:
bytes.
There is a DUP parameter Control/Status register bit (bit 15) which is defined
as DECMODE. The pdp11_dup uses this to presume DDCMP packet behavior.
The DUP transmit data buffer has a bit (9) which says that this is the end of a
transmitted message. This triggers an outbound packet send.
As I said previously, if the DUP were to be used for other protocols (which it
doesn't currently know about), then the logic could be extended as needed.
I would hope that useful - not just theoretic test cases would exist to drive
such extensions.
- Mark
On Nov 19,
2021, at 3:52 PM, Mark Pizzolato - Info Comm
<Mark at infocomm.com> wrote:
On Friday, November 19, 2021 at 12:33 PM, Reindert wrote:
> I updated the remark by Bob with this in my update and could not find
that
back in
your copy of the mail transcript:
Before I get a storm this from Pdp11_dup.c should accompany it:
The wire protocol implemented is native DDCMP WITHOUT the DDCMP
SYNC
characters both initially and between DDCMP packets.
I still don't understand your problem. The wire protocol is PACKETS, NOT The packets are transported over either UDP (as
UDP packets) OR via TCP
with
a 2 byte packet header indicating the data
length. Any packet length is NOT
presented across the simulator<->pdp11_dup device, just the data. On
transmit
any interpacket bytes that are the DDCMP_SYNC
character are stripped
BEFORE
the packet data is presented to UDP or TCP for
outbound delivery.
- Mark
But how does that process know how to turn a sequence of bytes written to
the DUP transmit register into a packet? To do so, it must know what the
particular packet format is. If a driver is sending BISYNC data, your packet
framing algorithm is entirely different from what it is for DDCMP.
891
days inactive
891
days old
3 comments
3 participants
participants (3)
-
Mark＠infocomm.com -
paulkoning＠comcast.net -
R.Voorhorst＠swabhawat.com