[HECnet] Re: What are your DAP flag bit definitions?

------------------------------------------------------------------------ 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.