Oh, I could certainly get bit 4 if I didn't do the decode properly (likely) or bumped into a bug (less likely). You know, got it ...wrong...
Meanwhile, I just wanted to make absolutely certain
that I have my RSX bits straight. IF reserved bit 4 were
defined as, say, HF.RSV, would it be
like the below? Is this table correct?
DAP
BitRSX
SymbolPDP-11
OctalComment 0 HF.STR 1 Stream ID bit in DAP header menu 1 HF.LEN 2 Length bit in DAP header menu 2 HF.XLN 4 Extended length bit in DAP header menu 3 HF.BIT 10 BITCNT bit in DAP header menu 4 HF.RSV 20 Reserved 5 HF.SYS 40 System specific field bit in DAP header menu 6 HF.SEG 100 Segmented msg bit in DAP header menu
I think what RSX is doing sounds completely straightforward and
proper. I don't suppose there is anything that could decide to
play with the flags byte downstream?
DAP messages can be truncated up to the point
of leaving only the TYPE field provided the
fields truncated are not needed or can be
defaulted. This is particularly useful with
the Acknowledge Message which reduces the ACK
to a one byte message.
On 11/29/22 7:42 PM, Johnny Billquist wrote:I was reading through the code that creates the DAP message, and it starts off with clearing the byte, then it checks if the system supports multiple streams, and if so sets bit 0. Then it checks if a length should be included, and if so, bit 1 is set, and if the length is >255, then bit 2 is also set.
And that is literally all that is done to the flags byte. So I can't see how you would get a message from MIM where bit 4 is set.
Johnny
On 2022-11-30 01:37, Thomas DeBellis wrote:Hum... Let me noodle over that for a bit.
I think it's a completely reasonable position to assume that I've a mistake, wrong assumption or am using something in such a way that it does not want to be used... After all, the code is brand new; just written, Etc.
I'll have to put some more instrumentation in, Etc, Etc.
I don't imagine there is anything clever about MIM::DU1:[DECNET]TEST.DIS;1? Don't see why there would be...
------------------------------------------------------------------------
On 11/29/22 7:09 PM, Johnny Billquist wrote:
What I can tell is what I can see in the sources. And there I have this:
HF.STR=001 ; Stream ID bit in DAP header menu
HF.LEN=002 ; Length bit in DAP header menu
HF.XLN=004 ; Extended length bit in DAP header menu
HF.BIT=010 ; BITCNT bit in DAP header menu
HF.SYS=040 ; System specific field bit in DAP header menu
HF.SEG=100 ; Segmented msg bit in DAP header menu
HT.BIT is the thing you are seeing which is not there in the DAP 5.6 spec. I don't really know what it is about, but it's something the RSX DAP have defined anyway.
I can't find any use of it. Looking in the code, I don't even see that it would ever be set. So I wonder if you made some mistake in your decoding?
Johnny
------------------------------------------------------------------------
On 2022-11-29 18:41, Thomas DeBellis wrote:
I fixed the bit definition for Not Last Message of Segmented Message from bit 4 to 6 as per DAP V5.6 and properly defined bit 4 as the Reserved field. In other words, I am following Tops-10, which I believe to have the correct definitions. Then I finished the flag breakout logic and tested again some systems. The MIM:: result is of note, viz.:
[Parsing Name message] [Parsing Attributes message] [Allocated Receive buffer (Words=531. Len=2086.)] [Trimmed 381. words from receive buffer] [Received Date/time Attributes message (Flg=*RESV*,SYSPEC UFlg=1000 Cnt=560.)] [Parsing Date/time Attributes message] [Parsing File Protection Attributes message] [Parsing Name message] TEST.DIS;1;P775656 2 2560(8) 18-Nov-2013 01:18:27
So what's up with *RESV*? Is (reserved) bit 4 being used for something new (I.E., post DAP 5.6) now? If so, what? The UFlg is an octal field for bits that I don't know about. In this case, MIM:: is sending bit 9 high, which the PDP-10 (which is the opposite endian) sees as bit 26. What's that?
Just wondering if I'm seeing what I'm seeing here...
------------------------------------------------------------------------
On 11/27/22 12:34 AM, Thomas DeBellis wrote:
Whoops, I mistyped the PDP-10 bit definition for bit six; it's 1B*29* and not 1B/28/. Sigh...
DAP
Bit Bit Meaning PDP-10
Bit Tops-20
DAP Symbol
0 Stream Identification Field Present 1B35 HD$SID
1 Length Field Present 1B34 HD$LEN
2 Extended Length Field Present 1B33 HD$LN2
3 Bit Count Field Present 1B32 HD$BCT
4 Reserved 1B31 HD$SEG
5 System Specific Field Present 1B30
6 Not last message of segmented message 1B29
I looked the Tops-10 DAP flags definitions (in SWIL.MAC); it looks like Tops-10 has it right and Tops-20 has it wrong, viz:
DAP
Bit Bit Meaning PDP-10
Bit Tops-20
DAP Symbol
0 Stream ID field present 1B35 DF$SID
1 LENGTH field present 1B34 DF$HLN
2 LEN256 field present 1B33 DF$HL2
3 BITCNT field present 1B32 DF$BCT
*4* *Reserved* *1B31* *DF$XX1*
5 SYSPEC field present 1B30 DF$SHX
*6* *More data coming* *1B29* *DF$MOR*
Johnny, can you send me the RSX DAP flag definitions when you get a minute?
------------------------------------------------------------------------
On 11/26/22 11:58 PM, Thomas DeBellis wrote:
I was writing a routine to break out DAP flag bits to aid debugging when I noticed a possible discrepancy between DAP V5.6 and Tops-20, viz:
DAP
Bit Bit Meaning PDP-10
Bit Tops-20
DAP Symbol
0 Stream Identification Field Present 1B35 HD$SID
1 Length Field Present 1B34 HD$LEN
2 Extended Length Field Present 1B33 HD$LN2
3 Bit Count Field Present 1B32 HD$BCT
4 Reserved 1B31 HD$SEG
5 System Specific Field Present 1B30
6 Not last message of segmented message 1B28
DAP V5.6 reserves bit 4 and defines bit 6 to flag that a segmented message is being sent and that this is not the last message. In other words, that there will be another message. Tops-20 is using bit 4 for this purpose and by rights it would appear that it should be using bit 6.
I will go see if I can't scare up what Tops-10 is doing, but I was wondering if anyone knew what other OS's are doing.