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

bilegeek wrote:
> 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

The information on that page was mostly guesstimated by me.
Corrections welcome.

Rich Cornwell alerted me to the use of the "Foonly channel" device in
KL10 WAITS. Looking into this, I see it was some kind of "NEWDSK" disk
controller that replaced the older PMP/IBM 3330 controller. According
to HEAD[S,SYS] it was in use between September 1977 and January 1980.

So it looks like there would be three options with regards to disk:

- Early on, there was the old PMP controller. This is supported in
the emulator, at least for running on KA10.

- Next, there was a new controller from Foonly. This is not supported.

- From 1983 on, RH20 was used. This is also in the emulator.

It would seem the best options would be either, pick a 1976/early 77
monitor and pray the changes from KA10 to KL10 are not too bad, or
pick one from 1983 or later and hope the RH20 stuff works.

On Friday, 26 May 2023 at 14:15:56 UTC+1, Lars Brinkhoff wrote:
> Rich Cornwell alerted me to the use of the "Foonly channel" device in
> KL10 WAITS. Looking into this, I see it was some kind of "NEWDSK" disk
> controller that replaced the older PMP/IBM 3330 controller. According
> to HEAD[S,SYS] it was in use between September 1977 and January 1980.
>
> So it looks like there would be three options with regards to disk:
>
> - Early on, there was the old PMP controller. This is supported in
> the emulator, at least for running on KA10.
>
> - Next, there was a new controller from Foonly. This is not supported.
>
> - From 1983 on, RH20 was used. This is also in the emulator.
>
> It would seem the best options would be either, pick a 1976/early 77
> monitor and pray the changes from KA10 to KL10 are not too bad, or
> pick one from 1983 or later and hope the RH20 stuff works.

I recently (last week) watched some videos on toobnix, showing an "SC-40" cold starting TOPS-20 and TOPS-10.

https://toobnix.org/w/nuQq4PdAydasGz6pCikzij
https://toobnix.org/w/4cpVieLiSdjP4LBMNcPapW

So, googling "System Concepts SC-40", I find this:

https://en.wikipedia.org/wiki/Systems_Concepts

"Systems Concepts, Inc. (now the SC Group), was a company co-founded by Stewart Nelson and Mike Levitt focused on making hardware products related to the DEC PDP-10 series of computers. One of its major products was the SA-10, an interface which allowed PDP-10s to be connected to disk and tape drives designed for use with the channel interfaces of IBM mainframes."

Hop over to bitsavers:

http://bitsavers.org/pdf/systemsConcepts/SA10/

David.

David Wijnants wrote:
>> It would seem the best options would be either, pick a 1976/early 77
>> monitor and pray the changes from KA10 to KL10 are not too bad, or
>> pick one from 1983 or later and hope the RH20 stuff works.
>
> "Systems Concepts, Inc. (now the SC Group), was a company co-founded
> by Stewart Nelson and Mike Levitt focused on making hardware products
> related to the DEC PDP-10 series of computers. One of its major
> products was the SA-10, an interface which allowed PDP-10s to be
> connected to disk and tape drives designed for use with the channel
> interfaces of IBM mainframes."

Systems Concepts was another company making PDP-10 peripherals and
eventually full computers, just like Foony. The SA-10 is most likely
a different disk controller, not related to the Foonly device.

David,

The SA10 was an interface that allowed you to hook up IBM style devices to your PDP10. This is similar to the PMP device.
Waits did not use a SA10, nor did the SC line of computers.

Rich

Richard C <rcorn10@gmail.com> writes:

> David,

> The SA10 was an interface that allowed you to hook up IBM style devices
> to your PDP10. This is similar to the PMP device. Waits did not use a
> SA10, nor did the SC line of computers.

> Rich

Rich, I hate to disagree with you, but when we (Stanford LOTS) took delivery of
the first SC-30M, it came with 3 I/O channels: The CI (a CI-20 clone), the
EI (an NIA-20 clone), and an SA (an SA-10 clone). We attached the system to
some IBM 3380A disks (from our pair of 4381 systems, which also had 3380B,
3380D, and 3380K drives so did not need the single density A's).

Stu Grossman (of KX-10 and Cygwin fame) was working for Mike at the time, and
got the MI channel working, so that we could hook up an RP07 to the drive and
get rid of the IBM drives. At the time, our mode of operation was to have an
RP06 boot drive and an RP07 system drive on each KL, and the user filesystem on
3 RA81s, so we wanted to duplicate that setup as far as possible on the SC-30M.

I don't have any idea whether they retired the SA channel with the release of
the SC-25, or the SC-40, or if it was an available option (that no one bought)
on all of them.

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