[HECnet] native Dup sync line revisited --> preliminary tests reveals problems

[Paul Koning]

> On Dec 22, 2021, at 8:35 PM, Paul Koning <paulkoning at comcast.net> wrote:
> 
> 
> 
>> 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.

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