19 Nov
2021
19 Nov
'21
10:15 p.m.
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.