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

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