23 Dec
2021
23 Dec
'21
8:56 p.m.
On Dec 22, 2021, at 8:35 PM, Paul Koning
<paulkoning at comcast.net> wrote:
I think the answer is as follows:
1. sim_tmxr has a get_packet and put_packet API, which inserts packet lengths ahead of the
data when in TCP mode.
2. That API is NOT used by any DEC sync device emulation. Instead, both DUP and DMC
buffer a packet within that device emulation, and use the get or put a character API of
sim_tmxr do deal with the actual data transfer. Those functions don't use length
fields.
3. The only place I see the packet API used are the CH11 (ChaosNet) device emulation for
PDP10 and PDP11, and in the H316 emulator. I haven't looked to see if that is
appropriate since it doesn't relate to the immediate subject under discussion.
So, Reindert, I'm wondering how you got it to send those length fields because there
isn't any way I can see in pdp11_dup.c for that to happen. A SIMH trace of the device
when it's not doing what you want would be interesting.
paul
On Dec 13, 2021, at 9:15 AM, Paul Koning
<paulkoning at comcast.net> wrote:
...
So if the plain sync device emulation were to do the above, that would give us an
emulation that interoperates with the DMC emulation if the software controlling the device
is running DDCMP.
More on this...
I built an M+ system with DUP lines, and unlike what was reported in this thread, I did
NOT see problems talking to other things (like PyDECnet or DMC emulation) that expect
plain data without frame length fields. I don't see frame lengths in the trace.
I don't understand this because the code is clearly there in the emulator, so
apparently it's not being hit. Not by DECnet/RSX anyway. More to be studied.