21 Nov
2022
21 Nov
'22
5:09 a.m.
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.
RSX
Symbol RSX
Value RSX
OS Type DAP V5.6
Value DAP V5.6
OS Type Tops-20 DAP
Symbol Tops-20 DAP
Value Tops-20 DAP
OS Type
OS$RT 1 RT-11 1 RT-11 .OSRT 1 RT-11
OS$RST 2 RSTS 2 RSTS/E .OSRST 2 RSTS/E
OS$11S 3 RSX-11S 3 RSX-11S .OSRXS 3 RSX-11S
OS$11M 4 RSX-11M 4 RSX-11M .OSRXM 4 RSX-11M
OS$11D 5 RSX-11D 5 RSX-11D .OSRXD 5 RSX-11D
OS$IAS 6 IAS 6 IAS .OSIAS 6 IAS
OS$VMS 7 VAX/VMS 7 VAX/VMS .OSVAX 7 VAX/VMS
OS$T20 8 TOPS-20 8 TOPS-20 .OSTP20 8 TOPS-20
OS$T10 9 TOPS-10 9 TOPS-10 .OSTP10 9 TOPS-10
OS$RTS 10 RTS-8 10 RTS-8 .OSOS8 *10* *OS-8*
OS$OS8 11 OS-8 11 OS-8 .OSRXP *11* *RSX11-M+*
OS$MPL 12 RSX-11M+ 12 RSX-11M+
OS$COP 13 COPOS/11 13 COPOS/11
OS$POS 14 P/OS
OS$ELN 15 ELAN
OS$CPM 16 CP/M
OS$MSD 17 MS-DOS
OS$U32 18 Ultrix-32
OS$U16 19 Ultrix-11
--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