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