Hi folks! Every year, the Large Scale Systems Museum asks our
community to help keep computer history alive. This year, we're doing it
with our POWER ON fundraiser.
Your support helps us preserve, maintain, and share our collection of
working historic computer systems and continue making the museum
available to the public.
We've also created some special supporter rewards this year,
including our limited-edition LSSM 11th Anniversary Coin.
There are several ways to support POWER ON 2026, from $32 all the way
up to $2,048, in nice civilized powers of two.
See all the supporter levels and rewards here:
https://lssmuseum.square.site/s/order?item=ZVRQRT72ES3KOZJKKAEWFSK6
Thanks,
-Dave McGuire, LSSM
--
Dave McGuire, AK4HZ
New Kensington, PA
It is my pleasure to announce the release of several software
packages from LSSM. These packages were developed over several years
for our internal use to support our work. We've recently spent some
time cleaning them up, writing documentation, and preparing them for
public release.
Some of these are useful in the DEC world, hence my announcing them here.
The list is here: https://www.lssmuseum.org/our_software
Each package has a page with a little demo (if appropriate for the
package) and a download link for the source code.
Some highlights:
- An extensive serial PDP-11 disk image transfer tool
- A block browser for RSP (DEC TU-58) drives
- MODCOMP diagnostic transfer utilities
- A TUI viewer/navigator for .tap and .tpc tape image files
- Emulator and cross-assembler for the Varian 620 family
- Emulator, cross-assembler, and BASIC for the Westinghouse P-50
- New programming documentation for the V620 and P-50
- Some new clients and servers for the CCSO Ph/Qi protocol
- A new, modern Gopher client
- Some other random tools
Bug reports are welcome; there's a link to the bug report form on the
page referenced above.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
But I've already had C81 V3.1 available for years, including as an RPM...
.dir du:[3,54]c81.tsk
Directory DU0:[3,54]
30-SEP-26 01:54
C81.TSK;1 749. C 18-JUN-18 19:39
Total of 749./749. blocks in 1. file
.c81 /ver
C81 -- V3.1-00
.
Johnny
On 2026-09-30 01:26, Mihai Cristescu wrote:
>
> COBOL-81 V3.1-00 for RSX-11M — Reconditioned Tape
>
> File : C81_V3_1_Reconditionned.tap
> Format : SIMH tape (.tap)
> Size : 1,792,480 bytes
> SHA-256 : 18e79835ef18a1294fd3986e7a759a7dfdc2860b9eaa89b0237ffd09d4f9d9db
>
> Tape contents, in order:
>
> AUT101.A
> AUTVER.BCK
> C81C81.BCK
> C81REL.BCK
> C81301.A
>
> The last BAC contains the repaired C81BLD.OLB library. All other components
> of the original kit have been preserved.
>
>
> Installation
>
> Prerequisites: RSX-11M with a TMSCP MU0: tape drive, BRU available, a
> privileged account, and the [367,367] directory. Replace DU0: below if the
> system disk has a different device name.
>
> 1.
>
> In SIMH, attach the tape read-only using SIMH format:
>
> sim> DETACH TQ0
> sim> SET TQ0 FORMAT=SIMH
> sim> ATTACH TQ0 -R /path/C81_V3_1_Reconditionned.tap
> sim> CONT
>
> 2.
>
> Under RSX, manually restore the first BAC to the mounted disk:
>
> BRU /MOU/REW/DENS:1600/BAC.A MU0: DU0:
>
> 3.
>
> Run Auto-Install from a privileged account:
>
> SET /UIC=[1,54]
> @DU0:[367,367]AUTOIN
>
> Select product C81 and MU0: when prompted by the procedure.
> Do not manually restore the other four BACs; AUTOIN handles them.
>
>
> Expected Validation
>
> |C81IC1 has passed. C81IC2 has passed. Installation of C81 (C81) successful.|
>
> This image was validated on 30-SEP-2026 by performing a complete
> installation
> on a freshly generated RSX-11M V4.8 BL70 system running under SIMH.
>
> Mihai CRISTESCU
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
When I set myself up on the HECnet mailing list it looks like I didn't
setup an account because the HECnet entry in my password manager does
not record a password, only details of the email I used.
How do I now change my subscription to use a different email address?
Thanks
Rob
To all area 27 neighbors:
My ISP has apparently negotiated new peer points and is now using a completely new set of IP addresses.
DECnet.theberrymans.com’s addresses are now:
38.40.4.12
2601:b081:5f0:4e10::1fde
Mark Berryman
Hey Björn!!
I think you nailed it; you're right, I had forgotten to reassemble
TTYSRV after I modified TTYDEF. Well, Oops... So it boots fine now
and passed some stress testing that I did.
@terminal vt102
@terminal length 44
@terminal width 144
@pop
*S*IAC,WILL,TRMTYP*
*S*IAC,SB,NAWS,0,144,0,44,IAC,SE*
*R*IAC,DONT,TRMTYP*
*S*IAC,WONT,TRMTYP*
So it's still rejecting what the Tops-20 TELNET client is sending. I
was thinking that the Tops-20 client was correct because I thought it
worked for Unix. On a lark, I tried PuTTY and got:
Event Log: Looking up host "venti2" (IPv4) for Telnet connection
Event Log: Connecting to 192.168.22.22 port 23
Event Log: client: WILL NAWS
*Event Log: client: WILL TSPEED*
Event Log: client: WILL TTYPE
Event Log: client: WILL NEW_ENVIRON
Event Log: client: DO ECHO
Event Log: client: WILL SGA
Event Log: client: DO SGA
Event Log: server: WILL ECHO
*Event Log: server: DO TTYPE <--!!*
Event Log: server: DO NAWS
Event Log: client: SB NAWS 76,30
Event Log: server: DONT TSPEED
*Event Log: server: SB TTYPE SEND
Event Log: client: SB TTYPE IS XTERM*
Event Log: server: DONT NEW_ENVIRON
Event Log: client: WILL OLD_ENVIRON
Event Log: server: DO SGA
Event Log: server: DONT OLD_ENVIRON
So it worked with PuTTY. I'll have a look at the Tops-20 TELNET client
to see what I might be doing that isn't quite right.
As an aside, I don't know how different my TELNET client is from yours,
but it does have a rather large number of enhancements over the
'standard' PANDA TELNET client, viz:
TOPS20:<TELNET>
TELNET.MAC.967;P777752 32 79863(7) 16-Nov-2002 00:39:27 MRC
STAR:<TELNET>
TELNET.MAC.2579;P777700 99 251401(7) 9-Sep-2026 18:35:30 SLOGIN
So 'slightly' isn't the first thing that came to my mind, although maybe
'vastly' doesn't sit right either. You can grab a copy from VENTI2::
via ANONYMOUS NFT.
TOMMYT:<OINKY.TELNET.TOPS-20>
TELNET.MAC.1;P424242 99 251233(7) 28-Feb-2026 18:11:32 SLOGIN
This is the edit log:
;[VENTI2]STAR:<TELNET>TELNET.MAC.2545, 26-Feb-2026 11:46:10, Edit by SLOGIN
;[T457] Shut off timer interrupts when hitting an unsolicited breakpoint
;[VENTI2]STAR:<TELNET>TELNET.MAC.2457, 22-Feb-2026 23:42:39, Edit by SLOGIN
;[T456] Have STATUS display DECnet object name
;[VENTI2]STAR:<TELNET>TELNET.MAC.2380, 20-Feb-2026 23:26:04, Edit by SLOGIN
;[T455] Have STATUS display transport domain for open connections, also
port name
;[VENTI2]STAR:<TELNET>TELNET.MAC.2276, 19-Feb-2026 13:53:33, Edit by SLOGIN
;[T454] Move some more text out of CODE
;[VENTI2]STAR:<TELNET>TELNET.MAC.2250, 18-Feb-2026 14:55:48, Edit by SLOGIN
;[T453] Do not locally redefine MONSYM .DCX* symbols, move text to PSECT
;[VENTI2]STAR:<TELNET>TELNET.MAC.2213, 17-Feb-2026 22:00:31, Edit by SLOGIN
;[T452] Update SYMOUT to understand modern symbol table vector (which
T450 broke)
;[VENTI2]STAR:<TELNET>TELNET.MAC.2025, 14-Feb-2026 12:51:38, Edit by SLOGIN
;[T451] Negotiate Remote Flow Control Option, RFC1080, RFC1372
;[VENTI2]STAR:<TELNET>TELNET.MAC.2000, 12-Feb-2026 14:25:37, Edit by SLOGIN
;[T450] Fix patching which T146 broke. Created TELNET.CCL
;[VENTI2]STAR:<TELNET>TELNET.MAC.1801, 8-Feb-2026 12:30:30, Edit by SLOGIN
;[T449] Override superior stolen interrupt character
;[VENTI2]STAR:<TELNET>TELNET.MAC.1724, 7-Feb-2026 17:39:57, Edit by SLOGIN
;[T448] Use ANNJE. Macsym finally has it
;[VENTI2]STAR:<TELNET>TELNET.MAC.1700, 7-Feb-2026 15:38:34, Edit by SLOGIN
;[T447] Negotiate client terminal type, RFC1091
;[VENTI2]STAR:<TELNET>TELNET.MAC.1600, 6-Feb-2026 13:16:31, Edit by SLOGIN
;[T446] Modernize DDT interface to properly use Program Data Vectors (PDV's)
;[VENTI2]STAR:<TELNET>TELNET.MAC.1581, 5-Feb-2026 13:47:18, Edit by SLOGIN
;[T445] Properly determine NRT transport compatibility (it's not OS based)
;[VENTI2]STAR:<SLOGIN>TELNET.MAC.1548, 4-Feb-2026 15:24:23, Edit by SLOGIN
;[T444] Properly handle terminal lengths and widths over decimal 127
(Octal 177)
;[VENTI2]STAR:<TELNET>TELNET.MAC.1473, 3-Feb-2026 16:58:22, Edit by SLOGIN
;[T443] Negotiate client NAWS (terminal dimensions), RFC1073
;[VENTI2]STAR:<TELNET>TELNET.MAC.1461, 3-Feb-2026 12:48:55, Edit by SLOGIN
;[T442] Update option printing for more options and cleaner numerics
;[VENTI2]STAR:<TELNET>TELNET.MAC.1433, 3-Feb-2026 11:35:25, Edit by SLOGIN
;[T441] It is wicked, evil and an offense against God to use SOUT% to
move strings
;[VENTI2]STAR:<TELNET>TELNET.MAC.1383, 1-Feb-2026 13:33:33, Edit by SLOGIN
;[T440] Better DECnet parsing and other DECnet related enhancements
;[VENTI2]STAR:<TELNET>TELNET.MAC.1363, 21-Sep-2023 22:01:49, Edit by SLOGIN
;[T293] Let them run without ^C if they insist on it by continuing after
blatting
;[VENTI2]STAR:<TELNET>TELNET.MAC.1317, 27-Mar-2021 17:49:46, Edit by SLOGIN
;[T147] Do not enable capabilities if already done for us
;[VENTI2]STAR:<TELNET>TELNET.MAC.1272, 27-Mar-2021 12:33:16, Edit by SLOGIN
;[T146] Write protect the code segment (with Link) & PDV
;[TOMMYT]STAR:<TELNET>TELNET.MAC.1164, 16-Jul-2017 19:48:06, Edit by SLOGIN
;[T71] Have TELNET be able to show the current escape character.
;[TOMMYT]STAR:<TELNET>TELNET.MAC.1114, 15-Jul-2017 20:01:29, Edit by SLOGIN
;[T70] Minor clean up of STKVAR scoping
;[TOMMYT]STAR:<TELNET>TELNET.MAC.970, 22-Oct-2016 12:14:18, Edit by SLOGIN
;[T63] Change TELNET not to require ^C (SC%CTC) capability in a Batch stream
; and to not allow ^C as an interrupt character when running batch.
;[TOMMYT]STAR:<TELNET>TELNET.MAC.968, 22-Jun-2007 10:28:31, Edit by SLOGIN
;[T46] Make TELNET check HOSTS.TXT first, like everything else on TOMMYT
> ------------------------------------------------------------------------
> On 9/10/26 10:04 AM, Björn Victor wrote:
>
> Your Telnet client is slightly different than mine, e.g. in how it
> handles NAWS after a push/pop to exec - I'll have a look. (And when
> testing now, I found a bug in my new NAWS code in the Panda Telnet
> client - will update my repo soon.)
>
> But the BUGINF/BUGINF/BUGHLT sequence is new to me, and looks really
> bad. Please double check the code. And check that you recompiled
> TTYDEF and TTYSRV after modifying TVTSRV - the issue might be that
> TVTLEN changed, being defined in TVTSRV but used in TTYDEF and TTYSRV,
> and the compile command has no way of detecting the dependency. (See
> doc/monitor-edits.md in my repo.)
>
> -- Björn
>
>
>> ------------------------------------------------------------------------
>>
>> On 2026-09-10 01:01, Thomas DeBellis wrote:
>>
>> I got something to link and boot, so I'm off to a great start. Using
>> the Tops-20 TELNET client on TOMMYT::, I connected to VENTI2:: and
>> noted the folllowing negotiations (*S means TOMMYT::, *R means VENTI2::)
>>
>> *S*IAC,DO,SUPRGA*
>> *S*IAC,WILL,TRMTYP*
>> *S*IAC,WILL,NAWS*
>> *S*IAC,WILL,TRFLWC*
>> *S*IAC,DO,ECHO*
>> *R*IAC,WILL,ECHO*
>> *R*IAC,WILL,SUPRGA*
>> *R*IAC,DONT,TRMTYP*
>> *S*IAC,WONT,TRMTYP*
>> *R*IAC,DO,TRMTYP*
>> *R*IAC,DO,NAWS*
>> *S*IAC,SB,NAWS,0,133,0,40,IAC,SE*
>> *R*IAC,DONT,TRFLWC*
>> *S*IAC,WONT,TRFLWC*
>>
>> So what's interesting is that VENTI2:: decided it wasn't going to
>> negotiate terminal type, which I thought was pretty anti-social,
>> particularly seeing as I had just put the code to do that in.
>> Obviously, I cut and mis-pasted something or some such. I'll get
>> that chased down.
>>
>> Anyway, NAWS works, which is awesome. I pushed to an EXEC on
>> TOMMYT::, changed my terminal dimensions and saw that it was updated
>> on VENTI2::, viz:
>>
>> PANDA TOPS-20 Command processor 7.2(4462)
>> End of COMAND.CMD.15
>> @terminal width 132
>> @teminal length 38
>> @pop
>> *S*IAC,SB,NAWS,0,132,0,38,IAC,SE*
>> @i ter
>> TERMINAL NVT
>> !Terminal speed indeterminate!
>> .
>> .
>> .
>> TERMINAL LENGTH 38
>> TERMINAL WIDTH 132
>> .
>> .
>> .
>> @
>>
>> So that's the good news, shortly afterwards, I got
>>
>> 9-Sep-2026 16:06:26 ***BUGINF NVTSBZ*** NVTSB buffer full Job:
>> 0, User: OPERATOR, Data: 1000011
>> 9-Sep-2026 16:06:26 ***BUGINF NVTSEX*** NVTSE option not enabled
>> Job: 0, User: OPERATOR, Data: 0, 240000000020
>>
>> **********
>> *BUGHLT "PITRAP" AT 9-Sep-2026 16:
>> *ADDITIONAL DATA: 001006777777
>> **********
>>
>> Well, .../Ouch/...
>>
>> But I probably fat fingered that too, so I expect it will be
>> straightforward to chase down. That's the theory anyway, if it works
>> for Björn and not for me, then it has to be me.
>>> ------------------------------------------------------------------------
>>>
>>> On 9/9/26 2:19 PM, Thomas DeBellis wrote:
>>>
>>> Yes, it's very much appreciated and I am still tickled by your neat
>>> idea of having a separate fork to do the sub-negotiations. It's
>>> really kind of great.
>>>
>>> Yes, I know about LNKNEW, which is produced by POSTLD. I reviewed
>>> that module yesterday after I sent the email and tweaked things
>>> until I got something that linked. So now I'll make some more
>>> changes and tweak things until I have an alpha candidate for
>>> terminal type and NAWS.
>>>
>>> If I recall correctly (this is over a year or so ago), the problem I
>>> had was that the documentation for the QUEUE% JSYS said it did
>>> something that no code existed to do. So I coded part of FAL/DAPLIB
>>> against that only to have a big surprise. In short, QUEUE% is
>>> simply a Quasar short create request. That's fine when everything
>>> goes to QSRQUE, which does the conversion to long format for batch
>>> and all spooling requests. However, there is no such thing as a
>>> short create request for mounting devices, I had to write the
>>> conversion code in Quasar.
>>>
>>> QUEUE% itself needed further finishing so that it could be debugged
>>> against a non-production galaxy and it also needed some defensive
>>> code to prevent illegal memory reference crashes. I also added some
>>> parameters that were left out. Since I was in the Galaxy group in
>>> Marlboro and was Columbia's Galaxy guru, I was nearly the ideal
>>> person to do all this. Until I tried to move QUEUE% into section 6,
>>> which produced a monitor that would not boot. I never determined why.
>>>
>>> Probably Chaos should get moved out of section 0, space there is
>>> really tight. As I recall, DECnet is in section 6, much of the
>>> Internet code is there, also.
>>>
>>>> ------------------------------------------------------------------------
>>>> On 9/9/26 1:51 AM, Björn Victor wrote:
>>>>
>>>> Nice to hear you're using my code!
>>>>
>>>> As I'm sure you know, the monitor PSECT settings are (in a Panda
>>>> setup) read from LNKNEW.CCL (and in the plain DEC setting, other
>>>> .CCL files). When starting the newly linked MON.EXE, if overlaps
>>>> are detected, (most often) a new version of LNKNEW.CCL is written
>>>> and you get to rerun the linking.
>>>>
>>>> Sometimes this doesn't work (I typically detect this by getting a
>>>> PDL overflow when starting MON.EXE), and I need to manually edit
>>>> LNKNEW.CCL to move things up. Your issue with the INCOD/RSCOD
>>>> overlap could come from added resident code for the new Telnet
>>>> functionality, but the ENCOD/XNCOD I don't recall seeing.
>>>>
>>>> I admit never taking a monitor training course, but changing PSECT
>>>> locations/sizes shouldn't give problems for shared data etc - as
>>>> long as the code uses symbolic references? But if you move things
>>>> between sections and make calls/references from other sections, of
>>>> course you need to make sure to use extended instructions (XMOVEI
>>>> rather then MOVEI, the CALLX macro instead of plain CALL, etc).
>>>>
>>>> At some point I'd like to move the Chaosnet code to a higher
>>>> section, to make section 1 less cramped (I currently have 14
>>>> (octal) free pages in section 0). But it's not very high on my TODO
>>>> list - until I really run out of space. :-)
>>>>
>>>> -- Björn
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> On 2026-09-09 01:54, Thomas DeBellis wrote:
>>>>>
>>>>> I finally took my first steps at merging the NAWS and terminal
>>>>> type code into my monitor sources. I suspected I was going to
>>>>> have address space conflict issues, so I didn't do anything with
>>>>> the Chaos code, nor the terminal location code. SUPDUP
>>>>> also obviously remains unmerged.
>>>>>
>>>>> The idea was to build some minimal set of features that I could
>>>>> then debug. I still ran out of space, so I have some .PSECT
>>>>> juggling to do.
>>>>>
>>>>> 19:31:20 USER %LNKPOV Psects ENCOD and XNCOD overlap from
>>>>> address 6646000 to 6646030
>>>>> 19:31:20 USER %LNKPOV Psects INCOD and RSCOD overlap from
>>>>> address 143000 to 143215
>>>>>
>>>>> Moving everything around has always been a bit of a dark art for
>>>>> me as there are some dependencies that aren't immediately
>>>>> obvious. One thing that comes to mind is shared data that is
>>>>> available in all sections. Or maybe it's not that, I just remember
>>>>> having to move some things into section 6 (XNCOD) when I added (a
>>>>> lot of) functionality to QUEUE% to support device mounting, which
>>>>> was breaking FAL ANONYMOUS mode.
>>>>>
>>>>> The monitor training courses that I have are quite out of date,
>>>>> and I've never come across serious documentation on monitor .PSECT
>>>>> lore. Of course, MRC probably had that all memorized.
>>>>>
>>>>> Anybody know of anything?
>>>>>
>>>>> Otherwise, it's just a lot of trial and error.
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> On 8/17/26 2:38 AM, Björn Victor wrote:
>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> On 2026-08-15 21:47, Thomas DeBellis wrote:
>>>>>>>
>>>>>>> Funny you should mention this, I have been thinking about it for
>>>>>>> years. The first part of parsing and actioning the NAWS option
>>>>>>> seemed straight forward enough (even though I didn't know how),
>>>>>>> and I did some work on understanding that (see below). The
>>>>>>> second part, that of signaling a fork that registers for NAWS
>>>>>>> seemed less straightforward and I have been wondering about
>>>>>>> that. In other words, Tops-20 would need the equivalent of
>>>>>>> SIGWIN, perhaps called TERMCH, for terminal changes (more on
>>>>>>> that, below).
>>>>>>>
>>>>>>> I decided to learn about TELNET option parsing by modifying the
>>>>>>> Tops-20 TELNET client to handle a number of options so I could
>>>>>>> Telnet into a local Unix host and run gnuemacs there without
>>>>>>> driving myself crazy. These were:
>>>>>>>
>>>>>>> * Negotiate client NAWS (terminal dimensions), RFC1093
>>>>>>> * Negotiate client terminal type, RFC1091
>>>>>>> * Negotiate Remote Flow Control Option, RFC1080, RFC1372
>>>>>>>
>>>>>> Interesting! My NAWS implementation in the monitor gets the
>>>>>> "signal" about window size change from the client, most often
>>>>>> some *nix-based thing. The NAWS implementation in TELNET (the T20
>>>>>> client program) only sends the values current when it starts; I
>>>>>> guess there should/could be some command to "re-send" the current
>>>>>> values (perhaps also for Terminal type).
>>>>>>
>>>>>> I actually never connect over Telnet from T20 to my *nix hosts,
>>>>>> only the other way around. Re TERMCH: I can see the point (for
>>>>>> EMACS etc), but I find it more acceptable to do C-x C-z followed
>>>>>> by "st"[art] when the size/type of terminal changes, than to type
>>>>>> "ter type vt100", "ter len nn", "ter wid nnn" followed by
>>>>>> "st"[art]. And going the TERMCH route would require changes to
>>>>>> all programs interested in terminal size? Life is too short.
>>>>>>
>>>>>> NAWS and TTYTYPE in the monitor were reasonably simple, but SEND
>>>>>> LOCATION turned out to be more interesting. Terminal locations
>>>>>> are stored in a file (FINGER:TTYLOC.BIN), so you need to open the
>>>>>> file, map it in, update, and close. However, the code handling
>>>>>> Telnet options runs in scheduler context, and it turns out GTJFN
>>>>>> needs to do some memory allocation which is not doable in
>>>>>> scheduler context. So I added another monitor-context fork, and a
>>>>>> queueing mechanism to send requests from the scheduler context to
>>>>>> be handled by the new fork.
>>>>>>
>>>>>>> Speaking of debugging, if you don't want to hang your terminal,
>>>>>>> then you have to be able to run the fork with control-C off, but
>>>>>>> this breaks a number of other things and you can see the amount
>>>>>>> of tinkering I had to do to get that right.
>>>>>> Debugging the TELNET client is indeed a challenge... I'll look
>>>>>> into your changes, later.
>>>>>>
>>>>>> -- Björn
>>>>>>
>>>>
>
Yes, it's very much appreciated and I am still tickled by your neat idea
of having a separate fork to do the sub-negotiations. It's really kind
of great.
Yes, I know about LNKNEW, which is produced by POSTLD. I reviewed that
module yesterday after I sent the email and tweaked things until I got
something that linked. So now I'll make some more changes and tweak
things until I have an alpha candidate for terminal type and NAWS.
If I recall correctly (this is over a year or so ago), the problem I had
was that the documentation for the QUEUE% JSYS said it did something
that no code existed to do. So I coded part of FAL/DAPLIB against that
only to have a big surprise. In short, QUEUE% is simply a Quasar short
create request. That's fine when everything goes to QSRQUE, which does
the conversion to long format for batch and all spooling requests.
However, there is no such thing as a short create request for mounting
devices, I had to write the conversion code in Quasar.
QUEUE% itself needed further finishing so that it could be debugged
against a non-production galaxy and it also needed some defensive code
to prevent illegal memory reference crashes. I also added some
parameters that were left out. Since I was in the Galaxy group in
Marlboro and was Columbia's Galaxy guru, I was nearly the ideal person
to do all this. Until I tried to move QUEUE% into section 6, which
produced a monitor that would not boot. I never determined why.
Probably Chaos should get moved out of section 0, space there is really
tight. As I recall, DECnet is in section 6, much of the Internet code
is there, also.
> ------------------------------------------------------------------------
> On 9/9/26 1:51 AM, Björn Victor wrote:
>
> Nice to hear you're using my code!
>
> As I'm sure you know, the monitor PSECT settings are (in a Panda
> setup) read from LNKNEW.CCL (and in the plain DEC setting, other .CCL
> files). When starting the newly linked MON.EXE, if overlaps are
> detected, (most often) a new version of LNKNEW.CCL is written and you
> get to rerun the linking.
>
> Sometimes this doesn't work (I typically detect this by getting a PDL
> overflow when starting MON.EXE), and I need to manually edit
> LNKNEW.CCL to move things up. Your issue with the INCOD/RSCOD overlap
> could come from added resident code for the new Telnet functionality,
> but the ENCOD/XNCOD I don't recall seeing.
>
> I admit never taking a monitor training course, but changing PSECT
> locations/sizes shouldn't give problems for shared data etc - as long
> as the code uses symbolic references? But if you move things between
> sections and make calls/references from other sections, of course you
> need to make sure to use extended instructions (XMOVEI rather then
> MOVEI, the CALLX macro instead of plain CALL, etc).
>
> At some point I'd like to move the Chaosnet code to a higher section,
> to make section 1 less cramped (I currently have 14 (octal) free pages
> in section 0). But it's not very high on my TODO list - until I really
> run out of space. :-)
>
> -- Björn
>> ------------------------------------------------------------------------
>>
>> On 2026-09-09 01:54, Thomas DeBellis wrote:
>>
>> I finally took my first steps at merging the NAWS and terminal type
>> code into my monitor sources. I suspected I was going to have
>> address space conflict issues, so I didn't do anything with the Chaos
>> code, nor the terminal location code. SUPDUP also obviously
>> remains unmerged.
>>
>> The idea was to build some minimal set of features that I could then
>> debug. I still ran out of space, so I have some .PSECT juggling to do.
>>
>> 19:31:20 USER %LNKPOV Psects ENCOD and XNCOD overlap from address
>> 6646000 to 6646030
>> 19:31:20 USER %LNKPOV Psects INCOD and RSCOD overlap from address
>> 143000 to 143215
>>
>> Moving everything around has always been a bit of a dark art for me
>> as there are some dependencies that aren't immediately obvious. One
>> thing that comes to mind is shared data that is available in all
>> sections. Or maybe it's not that, I just remember having to move
>> some things into section 6 (XNCOD) when I added (a lot of)
>> functionality to QUEUE% to support device mounting, which was
>> breaking FAL ANONYMOUS mode.
>>
>> The monitor training courses that I have are quite out of date, and
>> I've never come across serious documentation on monitor .PSECT lore.
>> Of course, MRC probably had that all memorized.
>>
>> Anybody know of anything?
>>
>> Otherwise, it's just a lot of trial and error.
>>> ------------------------------------------------------------------------
>>>
>>> On 8/17/26 2:38 AM, Björn Victor wrote:
>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> On 2026-08-15 21:47, Thomas DeBellis wrote:
>>>>
>>>> Funny you should mention this, I have been thinking about it for
>>>> years. The first part of parsing and actioning the NAWS option
>>>> seemed straight forward enough (even though I didn't know how), and
>>>> I did some work on understanding that (see below). The second
>>>> part, that of signaling a fork that registers for NAWS seemed less
>>>> straightforward and I have been wondering about that. In other
>>>> words, Tops-20 would need the equivalent of SIGWIN, perhaps called
>>>> TERMCH, for terminal changes (more on that, below).
>>>>
>>>> I decided to learn about TELNET option parsing by modifying the
>>>> Tops-20 TELNET client to handle a number of options so I could
>>>> Telnet into a local Unix host and run gnuemacs there without
>>>> driving myself crazy. These were:
>>>>
>>>> * Negotiate client NAWS (terminal dimensions), RFC1093
>>>> * Negotiate client terminal type, RFC1091
>>>> * Negotiate Remote Flow Control Option, RFC1080, RFC1372
>>>>
>>> Interesting! My NAWS implementation in the monitor gets the "signal"
>>> about window size change from the client, most often some *nix-based
>>> thing. The NAWS implementation in TELNET (the T20 client program)
>>> only sends the values current when it starts; I guess there
>>> should/could be some command to "re-send" the current values
>>> (perhaps also for Terminal type).
>>>
>>> I actually never connect over Telnet from T20 to my *nix hosts, only
>>> the other way around. Re TERMCH: I can see the point (for EMACS
>>> etc), but I find it more acceptable to do C-x C-z followed by
>>> "st"[art] when the size/type of terminal changes, than to type "ter
>>> type vt100", "ter len nn", "ter wid nnn" followed by "st"[art]. And
>>> going the TERMCH route would require changes to all programs
>>> interested in terminal size? Life is too short.
>>>
>>> NAWS and TTYTYPE in the monitor were reasonably simple, but SEND
>>> LOCATION turned out to be more interesting. Terminal locations are
>>> stored in a file (FINGER:TTYLOC.BIN), so you need to open the file,
>>> map it in, update, and close. However, the code handling Telnet
>>> options runs in scheduler context, and it turns out GTJFN needs to
>>> do some memory allocation which is not doable in scheduler context.
>>> So I added another monitor-context fork, and a queueing mechanism to
>>> send requests from the scheduler context to be handled by the new fork.
>>>
>>>> Speaking of debugging, if you don't want to hang your terminal,
>>>> then you have to be able to run the fork with control-C off, but
>>>> this breaks a number of other things and you can see the amount of
>>>> tinkering I had to do to get that right.
>>> Debugging the TELNET client is indeed a challenge... I'll look into
>>> your changes, later.
>>>
>>> -- Björn
>>>
>
I finally took my first steps at merging the NAWS and terminal type code
into my monitor sources. I suspected I was going to have address space
conflict issues, so I didn't do anything with the Chaos code, nor the
terminal location code. SUPDUP also obviously remains unmerged.
The idea was to build some minimal set of features that I could then
debug. I still ran out of space, so I have some .PSECT juggling to do.
19:31:20 USER %LNKPOV Psects ENCOD and XNCOD overlap from address
6646000 to 6646030
19:31:20 USER %LNKPOV Psects INCOD and RSCOD overlap from address
143000 to 143215
Moving everything around has always been a bit of a dark art for me as
there are some dependencies that aren't immediately obvious. One thing
that comes to mind is shared data that is available in all sections. Or
maybe it's not that, I just remember having to move some things into
section 6 (XNCOD) when I added (a lot of) functionality to QUEUE% to
support device mounting, which was breaking FAL ANONYMOUS mode.
The monitor training courses that I have are quite out of date, and I've
never come across serious documentation on monitor .PSECT lore. Of
course, MRC probably had that all memorized.
Anybody know of anything?
Otherwise, it's just a lot of trial and error.
> ------------------------------------------------------------------------
>
> On 8/17/26 2:38 AM, Björn Victor wrote:
>
>> ------------------------------------------------------------------------
>>
>> On 2026-08-15 21:47, Thomas DeBellis wrote:
>>
>> Funny you should mention this, I have been thinking about it for
>> years. The first part of parsing and actioning the NAWS option
>> seemed straight forward enough (even though I didn't know how), and I
>> did some work on understanding that (see below). The second part,
>> that of signaling a fork that registers for NAWS seemed less
>> straightforward and I have been wondering about that. In other
>> words, Tops-20 would need the equivalent of SIGWIN, perhaps called
>> TERMCH, for terminal changes (more on that, below).
>>
>> I decided to learn about TELNET option parsing by modifying the
>> Tops-20 TELNET client to handle a number of options so I could Telnet
>> into a local Unix host and run gnuemacs there without driving myself
>> crazy. These were:
>>
>> * Negotiate client NAWS (terminal dimensions), RFC1093
>> * Negotiate client terminal type, RFC1091
>> * Negotiate Remote Flow Control Option, RFC1080, RFC1372
>>
> Interesting! My NAWS implementation in the monitor gets the "signal"
> about window size change from the client, most often some *nix-based
> thing. The NAWS implementation in TELNET (the T20 client program) only
> sends the values current when it starts; I guess there should/could be
> some command to "re-send" the current values (perhaps also for
> Terminal type).
>
> I actually never connect over Telnet from T20 to my *nix hosts, only
> the other way around. Re TERMCH: I can see the point (for EMACS etc),
> but I find it more acceptable to do C-x C-z followed by "st"[art] when
> the size/type of terminal changes, than to type "ter type vt100", "ter
> len nn", "ter wid nnn" followed by "st"[art]. And going the TERMCH
> route would require changes to all programs interested in terminal
> size? Life is too short.
>
> NAWS and TTYTYPE in the monitor were reasonably simple, but SEND
> LOCATION turned out to be more interesting. Terminal locations are
> stored in a file (FINGER:TTYLOC.BIN), so you need to open the file,
> map it in, update, and close. However, the code handling Telnet
> options runs in scheduler context, and it turns out GTJFN needs to do
> some memory allocation which is not doable in scheduler context. So I
> added another monitor-context fork, and a queueing mechanism to send
> requests from the scheduler context to be handled by the new fork.
>
>> Speaking of debugging, if you don't want to hang your terminal, then
>> you have to be able to run the fork with control-C off, but this
>> breaks a number of other things and you can see the amount of
>> tinkering I had to do to get that right.
> Debugging the TELNET client is indeed a challenge... I'll look into
> your changes, later.
>
> -- Björn
>
