It's taken me over a month to put some data together, both tabulating from various sources and observing what is actually going over the wire.

The basic problem was that some changes that I had previously made to DAP, NFT, FAL and friends to write protect the code space silently left things in such a fragile state that trying to link the relocatable binaries (I.E., .REL files) into  an NFT execute either outright blew LINK up or hung it in an endless loop.  That's right: Boom...  I don't think I've ever seen that.

Fixing LINK didn't seem to be obvious and I didn't want to get into pile of code as I judged this to be a one to two year rabbit hole because it would turn into a rewrite to use extended mode and support long symbols.

Briefly, the problem turned out to be that if you are using Read-Only .PSECT's (a relatively late MACRO feature) in a GLXLIB program, you must name your code segment .HIGH. and your data area DATA.  I got the data part correct, but committed the unforgivable sin of naming the code segment "CODE"...  Go figure.

So MIM:: is sending an OS Type of 12, just like it's supposed to, and Tops-20 doesn't recognize this.  The recovery works well enough, it seems, Tops-20 DAP merely whining, but carrying on.  So I'll fix that.  It seems the best way to go is to simply mimic the RSX naming paradigm; that is, RSX OS$XXX would go to .OSXXX.

I'm wondering whether I should double check the FILESYS byte.  Probably.

--T

On 10/22/22 6:03 AM, Johnny Billquist wrote:

On 2022-10-22 04:59, Thomas DeBellis wrote:

As we've noted earlier, the operating system numbers are not consistent between terminal transport and DAP.  Your numbers correspond to the DAP 5.6 specification as far as it goes, viz:

                           Value     OS Type

                             0       Illegal
                             1       RT-11
                             2       RSTS/E
                             3       RSX-11S
                             4       RSX-11M
                             5       RSX-11D
                             6       IAS
                             7       VAX/VMS
                             8       TOPS-20
                             9       TOPS-10
                            10       RTS-8
                            11       OS-8
                            12       RSX-11M+
                            13       COPOS/11 (TOPS-20 front-end)

Right.

I wish I hadn't sent out my last email because P/OS was staring me right in the face...  I don't recall there being any COPOS/11 on any Tops-20 front end.  The master DTE ran RSX20F, the RJE ran DN60 code and the Phase III DN20's ran what I thought was called "MCB".

The "TOPS-20 front-end" was a bit of news to me. Makes me more curious...

And yeah, P/OS was in my list. Right after COPOS/11. You should have read one more line. :-)

The Tops-20 DAP library has the following operating system numbers which partly correspond to yours.  By this, I mean they are table offsets which are used to pick the default mode. Assuming the following:

         .OSRT==1        ;RT-11
         .OSRST==2       ;RSTS/E
         .OSRXS==3       ;RSX-11S
         .OSRXM==4       ;RSX-11M
         .OSRXD==5       ;RSX-11D
         .OSIAS==6       ;IAS
         .OSVAX==7       ;VAX/VMS
         .OSTP20==10     ;TOPS-20 (^D8)
         .OSTP10==11     ;TOPS-10 (^D9)
         .OSOS8==12      ;OS-8 (^D10)
         .OSRXP==13      ;RSX11-M PLUS (^D11)

It would appear that there is a conflict in the list in the PDP-8 entries and RSX-11M+.  If MIM:: is reporting decimal 11 (octal 13), the right thing from my list, then it is reporting itself as a PDP-8 running OS-8 according DAP 5.6.

So... go with what MIM:: says, not what is documented?

I don't get this. The documentation says RSX-11M-PLUS is 12, the code in RSX itself says it's 12. The only thing disagreeing is your list in TOPS-20.

  Johnny