If I remember correctly, on ancient tops-10, if you deposited nonzero in location 30, the console was logged in.
Maybe there's a similar trapdoor.

Dave Dyer <davedyer829@gmail.com> writes:

> If I remember correctly, on ancient tops-10, if you deposited nonzero in
> location 30, the console was logged in. Maybe there's a similar trapdoor.

Nonzero in location 30 is the SHUTDOWN condition, indicating that a system HALT
condition is safe.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

More info:

~~~~~

Starting with how to login remotely from page 54 of https://www.saildart.org/AIM/228/pdf ; "login net,gue" works, Baumgart probably enabled that when he made the image (NETGUE←←1 in LOGIN). Terminal is like 300 baud though; tried appending "speed=1200" to "at dcs -U 2040" in the config file, but unfortunately it doesn't register key inputs unless I'm ALSO typing on the III; some sort of interrupt thing it seems.

Looking at the code at https://www.saildart.org/LOGIN[P,SYS] is interesting in this regard. Ctrl-F "Table of remote TTYs for remote only passwords.", I might've found that table Lars was speaking of. Not sure how to apply this to SimH setup tho.

The comments and humor in the assembly is certainly interesting; it's almost self-documenting!

~~~~~

https://www.saildart.org/MONCOM.BH[S,DOC] has some good info about logins; including instructions on changing passwords (Ctrl-F "change your password").

Manually copied from III, double square brackets are my input:

<snip>

..[[l 1%reg]]
JOB 1 Stanford 7.01/C 04-22-75
New Password = [[abc]]
Old Directory Protection = 0
If you want your password to be used for remote logins only,
turn on the 400 bit in your directory protection.
New Protection (<cr> to keep old value, ? for help) = [[<cr>]]
Old Default File Protection = 0
New Protection (<cr> to keep old value, ? for help) = [[<cr>]]
Friday 26-JUL-74 0233

EXIT
↑C
..

</snip>

Lo and behold, I can now login remotely into "1,reg" with "abc". Removing passwords from remote logins entirely would probably require patching out the check in LOGIN, from the "PASSGO" or "LGN3A" subroutines.

~~~~~

Finally, I tried loading the 9.18/M dump from https://www.saildart.org/WAITS.DMP[S,SYS]_octal for funsies; as Rich said would happen, it complained about a missing disk, but hey, it got that far!

<snip>

KL-10 simulator Open SIMH V4.1-0 Current git commit id: 7be9f2f3+uncommitted-changes
sim> load -d WAITS.DMP[S,SYS]_octal
sim> go 200

SAIL.Stanford.EDU WAITS 9.18/M Assembled 04/26/90
Cache enables = 0

Type today's date as mm-dd-yy: 05-13-91

Enter local time in 24-hour format: 0216

02:16 Fatal: Primary Structure not Found
Find a WIZARD! You're in DDT

Simulation stopped, PC: 300504 (SOJG 0,300503)
sim> quit
Goodbye

</snip>

Can't format a new disk on the existing 1974 system as it uses IBM-3330 disks instead of RP06/RP07, but it seems much more achievable now. Also still trying to wrap my head around the whole [project,programmer] filesystem structure and navigate it.

bilegeek wrote:
> Looking at the code at https://www.saildart.org/LOGIN[P,SYS] is
> interesting in this regard. Ctrl-F "Table of remote TTYs for remote
> only passwords.", I might've found that table Lars was speaking
> of. Not sure how to apply this to SimH setup tho.

Ah, yes, that's where it is! I was searching the monitor sources
forwards and backwards without luck.

Looking at the LOGIN[ACT,REG] source code from 1974, I gather lines 0-5
10-11, and 16 are remote. The SIMH configuration for getting a
dedicated port for e.g. line 6 is: AT DCS -U LINE=6,2041
However, when I tried this it wouldn't echo anything back.

> The comments and humor in the assembly is certainly interesting; it's
> almost self-documenting!

Indeed! You might think that 50 year old code would be arcane and
difficult to understand; I find it's the exact opposite. It's code
from *today* that is difficult.

> Finally, I tried loading the 9.18/M dump from
> https://www.saildart.org/WAITS.DMP[S,SYS]_octal for funsies; as Rich
> said would happen, it complained about a missing disk, but hey, it got
> that far!

That's very interesting! I only tried a KL10 monitor from 1976 or
thereabouts, but I didn't get as far so I dropped it at that point.
Your progress seem much more encouraging. I believe WAITS used an RH20
controller at that point, so the waits.ini disk stuff is not appropriate
at all. Of course, we don't have any RP06 or RP07 disk images to attach
either.

There are two things, and probably more, that make me interested in
progressing from the KA10 into the KL10 era:

1. Support for text terminals like the Datamedia 2500. I made a
terminal emulator for those with an eye towards WAITS.

2. The sailboat graphics on the Data Disc displays.

> That's very interesting! I only tried a KL10 monitor from 1976 or
> thereabouts, but I didn't get as far so I dropped it at that point.
> Your progress seem much more encouraging.

Seems the KL images up to 9.13/Z (Assembled 01/10/82) don't make it to DDT, but 9.14/D (Assembled 03/17/83) onwards does.

But that could just as well be a bug in Open-SimH; I can't get klh10 to load the dumps, so I can't test there.

9.13/Z: https://saildart.org/WAITS.DMP[S,SYS]51_octal
9.14/D: https://saildart.org/WAITS.DMP[S,SYS]52_octal

Whoops, submitted too early.

The crashing might revolve around the disk controller, as a source[1] puts the move to the RH20 controller and RP07 disk drives in 1983.

[1]https://gunkies.org/wiki/WAITS

On Monday, May 15, 2023 at 9:35:15 PM UTC-4, bilegeek wrote:
> Whoops, submitted too early.
>
> The crashing might revolve around the disk controller, as a source[1] puts the move to the RH20 controller and RP07 disk drives in 1983.
>
> [1]https://gunkies.org/wiki/WAITS

If you can make the disk images for KL10 Waits, I can see why they crash on pdp10-KL. There might need to be some changes to the FE to support WAITS.

Rich

> If you can make the disk images for KL10 Waits, I can see why they crash on pdp10-KL. There might need to be some changes to the FE to support WAITS.

Unfortunately I haven't gotten that far yet; I've just been loading the dumps and running them, no other config done. I've tried attaching a blank image before, but "set rp enable" says "Non-existent device".

But the pre-83 dumps crashing before even getting to DDT seems to be from the lack of the IBM controller on the KL.

Not sure how difficult it would be to attach the IBM disks to the KL to see if the existing disk images would work; I tried adding "ka10_pmp.c" to the KL10 section of the makefile just to see, but it doesn't seem to have added the controller.

> > If you can make the disk images for KL10 Waits, I can see why they crash on pdp10-KL. There might need to be some changes to the FE to support WAITS.
> Unfortunately I haven't gotten that far yet; I've just been loading the dumps and running them, no other config done. I've tried attaching a blank image before, but "set rp enable" says "Non-existent device".

Ok can you email me privately which monitor you are trying to load? Please use my normal email and not my gmail :-). Or contact me on Discord or IRC.

>
> But the pre-83 dumps crashing before even getting to DDT seems to be from the lack of the IBM controller on the KL.
>
> Not sure how difficult it would be to attach the IBM disks to the KL to see if the existing disk images would work; I tried adding "ka10_pmp.c" to the KL10 section of the makefile just to see, but it doesn't seem to have added the controller.

You might want to set FE to ITS. Also it would be set rpa enable, KL supports up to 4 rp controllers.

To add a device you will need to edit kx10_defs.h and within one of the KL sections add in (around line 760)

#define NUM_DEVS_PMP 1

Then add it to the makefile and rebuild.

bilegeek <bilegeek2@gmail.com> writes:

>> If you can make the disk images for KL10 Waits, I can see why they crash on
>> pdp10-KL. There might need to be some changes to the FE to support WAITS.

> Unfortunately I haven't gotten that far yet; I've just been loading the dumps
> and running them, no other config done. I've tried attaching a blank image
> before, but "set rp enable" says "Non-existent device".

> But the pre-83 dumps crashing before even getting to DDT seems to be from the
> lack of the IBM controller on the KL.

> Not sure how difficult it would be to attach the IBM disks to the KL to see
> if the existing disk images would work; I tried adding "ka10_pmp.c" to the
> KL10 section of the makefile just to see, but it doesn't seem to have added
> the controller.

Before you go to a lot of trouble trying to do this, allow me to point out that
the "IBM" controller never resided on the KL-10.

SU-AI ("SAIL") was a multiprocessor machine, using shared memory between the
original PDP-6, the newer KA-10, and eventually the KL-10.

The KA-10 was the primary machine for the development of the KL-10 version of
the monitor, and the T300 disks were attached to the KA-10. Code would be
loaded into the KL-10 from the T300 disks by the KA-10.

The RH20 code from TOPS-20 was ported into WAITS by Joe Weening (JJW), so that
the KL-10's RP06 and RP07 disks could be used.

The 11/40 was handled by modifying the diagnostic loader KLDCP--running from
DECtape--extensively, so that it could load the monitor from the RP0x drives.

In addition, a hack was added to the monitor so that it could talk to the front
end running RSX-20F instead of KLDCP, but that was a hack.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

> allow me to point out that the "IBM" controller never resided on the KL-10

That doesn't seem to be the case from the docs[1] I've read (at least after the porting process was done). The earliest FACIL.TED doc I could find that references the tri-proc setup was from 1977, and it has the IBM disks on the KL.

[1]https://www.saildart.org/FACIL.TED[H,DOC]27 under "KL10 I/O BUS"

> SU-AI ("SAIL") was a multiprocessor machine, using shared memory between the
original PDP-6, the newer KA-10, and eventually the KL-10.

Do you remember why they quasi- separated out[2] the PDP-6, instead of keeping it as a tertiary processor? Was is just the unreliability, or did they need all the processing grunt for the music system?

[2]http://forum-old.stanford.edu/wiki/index.php/Early_Computers_at_Stanford#DEC_PDP-10_2

> The RH20 code from TOPS-20 was ported into WAITS by Joe Weening (JJW)

I wonder why he didn't use the TOPS-10 code, what with it's shared lineage and them porting both Prolog[3] and the TCP/IP stack[4] from there.

[3]https://www.saildart.org/[PRO,SYS]/
[4]https://www.saildart.org/[IP,SYS]/

> You might want to set FE to ITS.

With "set fe its"? If so, doesn't seem to work.

> To add a device you will need to edit kx10_defs.h and within one of the KL sections add in (around line 760)
> #define NUM_DEVS_PMP 1
> Then add it to the makefile and rebuild.

The PMP interface now works, but unfortunately 9.13/Z still crashes, so it must be something else that's locking it. Strange.

Rich,

I’m pretty sure that MIT-MC, when it was a KL-10, supported T300 disks. The current config file for ITS, in use today with the various pdp10 simulator shows T300 disks for that machine.

— Eric

On Wednesday, May 17, 2023 at 12:14:29 PM UTC-7, Rich Alderson wrote:

> Before you go to a lot of trouble trying to do this, allow me to point out that
> the "IBM" controller never resided on the KL-10.
>
> SU-AI ("SAIL") was a multiprocessor machine, using shared memory between the
> original PDP-6, the newer KA-10, and eventually the KL-10.
>
> The KA-10 was the primary machine for the development of the KL-10 version of
> the monitor, and the T300 disks were attached to the KA-10. Code would be
> loaded into the KL-10 from the T300 disks by the KA-10.

Eric,

We are talking about WAITS not ITS. :-)

Rich
> I’m pretty sure that MIT-MC, when it was a KL-10, supported T300 disks. The current config file for ITS, in use today with the various pdp10 simulator shows T300 disks for that machine.
>

Yes, I realize that. But Rich said that the KL10 didn't support T300. I'm just saying that it must have, because MIT-MC (running ITS) was running on an KL10, and it had T300 disks.

So perhaps what Rich meant is that WAITS (running on a KL10) didn't support Trident 300 disks.

-- Eric

On Thursday, May 18, 2023 at 1:44:53 PM UTC-7, Richard C wrote:
> Eric,
>
> We are talking about WAITS not ITS. :-)

Alderson: is https://www.saildart.org/RSKINI.FAI[P,SYS] or https://www.saildart.org/RALPH.FAI[S,SYS] the head crash recovery program?

Others: While we're on the subject, I think ITS could help here. It has the FAIL assembler and the DECUUO syscall translator, compatible enough for SUDS; maybe some heavy patching to the head crash program could allow a direct formatting of a SAIL RP07 disk?

Eric,

Note WAITS used a custom interface to IBM disks, call a PMP. There is question whether this device ever existed on the KL10 or not. It is hard to tell because WAITS never had any "releases", and only ran on a few machines..

Rich

> Yes, I realize that. But Rich said that the KL10 didn't support T300. I'm just saying that it must have, because MIT-MC (running ITS) was running on an KL10, and it had T300 disks.
>
> So perhaps what Rich meant is that WAITS (running on a KL10) didn't support Trident 300 disks.
>
> -- Eric
> On Thursday, May 18, 2023 at 1:44:53 PM UTC-7, Richard C wrote:
> > Eric,
> >
> > We are talking about WAITS not ITS. :-)

bilegeek <bilegeek2@gmail.com> writes:

> Alderson: is https://www.saildart.org/RSKINI.FAI[P,SYS] or
> https://www.saildart.org/RALPH.FAI[S,SYS] the head crash recovery program?

That would be RSKINI.FAI, written by Ralph Gorin (REG).

> Others: While we're on the subject, I think ITS could help here. It has the
> FAIL assembler and the DECUUO syscall translator, compatible enough for SUDS;
> maybe some heavy patching to the head crash program could allow a direct
> formatting of a SAIL RP07 disk?

Note that RSKINI makes a lot of use of WAITS specific UUOs, both negative
CALLIs and repurposed I/O instructions, so DECUUO (which AIUI is specifically
DEC oriented) is unlikely to help much.

Read the UUO manual for WAITS before proceeding.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Eric Swenson <eric@swenson.org> writes:

Rich,

I’m pretty sure that MIT-MC, when it was a KL-10, supported T300 disks. The
current config file for ITS, in use today with the various pdp10 simulator
shows T300 disks for that machine.

Yes it had T300s, but they weren't connected directly to the KL. They
were connected to the IO/11 (not the console 11). the IO/11, provided
the T300s, ChaosNet, and some other random devices.

The KL passed disk commands to the IO/11 (via DL10), which just wrote
them into the right unibus registers to tell the T300 what to do. For
reads and writes the IO/11 copied data between it's memory and the KL's
memory (via DL10). This wasn't super fast, but if you wanted speed you
used the RP04s.

I'm not sure that any of this would be very useful for WAITS, since in
effect this was a one-of-a-kind disk controller.

- Alan

On Friday, May 19, 2023 at 6:07:22 PM UTC-7, Alan Bawden wrote:

(snip)

> Yes it had T300s, but they weren't connected directly to the KL. They
> were connected to the IO/11 (not the console 11). the IO/11, provided
> the T300s, ChaosNet, and some other random devices.
> The KL passed disk commands to the IO/11 (via DL10), which just wrote
> them into the right unibus registers to tell the T300 what to do. For
> reads and writes the IO/11 copied data between it's memory and the KL's
> memory (via DL10). This wasn't super fast, but if you wanted speed you
> used the RP04s.
> I'm not sure that any of this would be very useful for WAITS, since in
> effect this was a one-of-a-kind disk controller.
If you are doing it in emulation, you can do strange things.
Some are easy, some not.

Ah, right. Thanks Alan. I was going to check the code to see how they were connected, but I do seem to recall it was as you've said. Thanks for the clarification.

-- Eric (KC6EJS)

On Friday, May 19, 2023 at 6:07:22 PM UTC-7, Alan Bawden wrote:
> Eric Swenson <er...@swenson.org> writes:
>
> Rich,
>
> I’m pretty sure that MIT-MC, when it was a KL-10, supported T300 disks. The
> current config file for ITS, in use today with the various pdp10 simulator
> shows T300 disks for that machine.
> Yes it had T300s, but they weren't connected directly to the KL. They
> were connected to the IO/11 (not the console 11). the IO/11, provided
> the T300s, ChaosNet, and some other random devices.
>
> The KL passed disk commands to the IO/11 (via DL10), which just wrote
> them into the right unibus registers to tell the T300 what to do. For
> reads and writes the IO/11 copied data between it's memory and the KL's
> memory (via DL10). This wasn't super fast, but if you wanted speed you
> used the RP04s.
>
> I'm not sure that any of this would be very useful for WAITS, since in
> effect this was a one-of-a-kind disk controller.
>
> - Alan

gah4 <gah4@u.washington.edu> writes:

> On Friday, May 19, 2023 at 6:07:22=E2=80=AFPM UTC-7, Alan Bawden wrote:

>> I'm not sure that any of this would be very useful for WAITS, since in
>> effect this was a one-of-a-kind disk controller.

> If you are doing it in emulation, you can do strange things.
> Some are easy, some not.

Sometimes you're doing emulation, sometimes you're engaging in science fiction...

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

bilegeek wrote:
>> allow me to point out that the "IBM" controller never resided on the KL-10
> That doesn't seem to be the case from the docs[1] I've read (at least
> after the porting process was done). The earliest FACIL.TED doc I
> could find that references the tri-proc setup was from 1977, and it
> has the IBM disks on the KL.

Assing to this, I see the FTRH feature switch "to enable code for RH-20
devices" was introduced in 1983. Also other references to RH20 or RH-20
appear this year, with nothing before.

This is not to say the earlier disk controller must have been attached
to the KL10 pre-1983. It could have been arranged to have the KA10
control the disks. But FACIL.TED does seem to indicate that was not the
case. It also says other I/O devices like III and DD controllers were
moved to the KL10.

> Do you remember why they quasi- separated out[2] the PDP-6, instead of
> keeping it as a tertiary processor? Was is just the unreliability, or
> did they need all the processing grunt for the music system?

I'm not sure about this, but from reading monitor sources it seems to me
the software is set up for a primary and a optional secondary processor.
Maybe it was decided to let the PDP-6 sit mostly on the side rather than
update the system to manage three processors. Also, yes, I seem to
recall reading something about CCRMA more or less taking over the PDP-6.
Previously they had been constrained to generate audio during off hours.
Note how FACIL.TED has the Samson Box attached to the PDP-6 I/O bus.

Richard C wrote:
> Note WAITS used a custom interface to IBM disks, call a PMP. There is
> question whether this device ever existed on the KL10 or not. It is
> hard to tell because WAITS never had any "releases", and only ran on a
> few machines.

It's not easy, but certainly we can look at monitor souces from various
time periods and make an informed theory. For example, the file
HEAD[S,SYS] lists all feature switches which tells us a lot about which
hardware was in use at some point in time. Of course, you have to be
careful to also check the code in case there's a device for which there
isn't a feature switch. For the disk device, we should check DSKSER,
DSKINT, etc. Picking some files from 1977, I see plenty of IOT
instructions using the IBM and PMP devices. Was this code running on
the KL10 or KA10 at that point? I'm not sure, but I believe it would
have been the primary processor.

Here's another question: When did the primary processor move from KA10
to KL10? Based on FTKL10, we would guess sometime between May and
August of 1976. The monitor version was bumped from 7.05/I to 8.00
on 1976-06-06, so maybe around that very day.

bilegeek wrote:
>> If you can make the disk images for KL10 Waits, I can see why they
>> crash on pdp10-KL. There might need to be some changes to the FE to
>> support WAITS.
>
> Unfortunately I haven't gotten that far yet; I've just been loading
> the dumps and running them, no other config done. I've tried attaching
> a blank image before, but "set rp enable" says "Non-existent device".

I think it's SET RPA ENABLE.

> But the pre-83 dumps crashing before even getting to DDT seems to be
> from the lack of the IBM controller on the KL.

I agree it's worth a shot with the IBM controller. Or focus on the RH20
configuration instead.

Also, it may be instructive to check the microcode, e.g.
https://www.saildart.org/DEFINE.MIC[KLM,SYS]
From what I see, there may be a few other updates needed for the
emulator. For example, the microcode emulates a BBN pager.

I guess the ongoing thread is fine for alt.sys.pdp10. But if ever there
should be a need to move off Usenet, I'd like to point out there is a
mailing list for WAITS hacking:

http://its.victor.se/mailman/listinfo/waits-hackers_its.victor.se