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

Ok, I can believe they had a SA-10 clone. But SA-10 was a KA10 IOBus device, and the SC-xx did not have this type of interface.
> 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.

I am looking for documentation on the SC line of machine. Specifically how they did paging. It does not appear to be the same as Dec KI or KL paging. Device docs would also be helpful.

Rich

Richard C <rcorn10@gmail.com> writes:

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

> Ok, I can believe they had a SA-10 clone. But SA-10 was a KA10 IOBus device,
> and the SC-xx did not have this type of interface.

Point taken.

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

> I am looking for documentation on the SC line of machine. Specifically how
> they did paging. It does not appear to be the same as Dec KI or KL
> paging. Device docs would also be helpful.

I don't have docs, unfortunately. I can say that the TOPS-20 monitor internals
did not differ between the KL-10 and the SC-30M.

The house internal development system was a KI-10. Stu told me that he had
made the SC-30M microcode do 8MW rather than 4MW of real memory, but that a
disk crash on the KI lost all his work before it could be shipped to the
customer (us). Mike fired him shortly after that, for unrelated reasons.

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

> Richard C wrote:
>> I am looking for documentation on the SC line of machine. Specifically how
>> they did paging. It does not appear to be the same as Dec KI or KL
>> paging.

the SC-40 can address more memory than a KL10, which would presumably
affect the paging tables. Per the message below, it would seem to have
been made in a backwards compatible manner. But if you have some
particular monitor (say, from CompuServe) maybe it has been built to use
that extended capability.

Rich Alderson wrote:
> I can say that the TOPS-20 monitor internals did not differ between
> the KL-10 and the SC-30M.

That's what I heard too: it was more or less bug-compatible with the
KL10 model B and could run unmodified TOPS-10 and TOPS-20 monitors.

Stu wrote me 23 years ago:

"In User Mode, our machines are essentially identical to the extended
KL-10. [...] In Executive Mode, there are many differences, which
allow for larger virtual and physical address spaces, and which
provide access to new devices, e.g. SCSI. However, these enhancements
are implemented by making additional operand formats available to
existing I/O operations for paging, device control, etc. Again, the
opcode set is identical to that of the KL-10B. If equipped with
appropriate ancient DEC I/O devices, our machines can run unmodified
binaries for both TOPS-10 and TOPS-20."

I read the HOM block checks in CHKHOM in PHYDAT.MAC[S,SYS] and made an
RP07 disk image which pass those. This is acceptable to WAITS 9.18/B
from 1988. Of course, this is a very very far cry from a working file
structure. The disk fails to mount shortly after returning from CHKHOM.

Lars Brinkhoff <lars.spam@nocrew.org> writes:

> I read the HOM block checks in CHKHOM in PHYDAT.MAC[S,SYS] and made an
> RP07 disk image which pass those. This is acceptable to WAITS 9.18/B
> from 1988. Of course, this is a very very far cry from a working file
> structure. The disk fails to mount shortly after returning from CHKHOM.

Did you read the very detailed description of the HOM block, SAT blocks, etc.,
in RSKINI.FAI? Did you read the code there?

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

Rich Alderson wrote:
> Did you read the very detailed description of the HOM block, SAT
> blocks, etc., in RSKINI.FAI? Did you read the code there?

I didn't, but now I see it's a gold mine. Thanks!

Lars Brinkhoff wrote:
> Rich Alderson wrote:
>> Did you read the very detailed description of the HOM block, SAT
>> blocks, etc., in RSKINI.FAI? Did you read the code there?
> I didn't, but now I see it's a gold mine. Thanks!

Having read RSKINI I have now been able to create a disk image for to
WAITS 9.18/B. (Apparently this particular 1988 monitor expects the file
structure to be a single RP06.) Although I haven't created any
directories or files, it finds the information in the HOM and SAT blocks
agreable and proceeds to enter the NULJOB idle loop.

I have checked the [S,SYS] sources (especialy HEAD and OUTER) to try to
get a more clear picture of how WAITS evolved with regards to hardware.
So I'd like to ask about some of the points you raised.

Rich Alderson wrote:
> The SAIL KL-10 was a stock 1080

I see the CPU was updated to a KL10 model B around 1983, and also
starting to use RH20 disk roughly the same time. Do you know if the
1080 was replaced with orange boxes, or just upgrading the internals?

> There were only 3 machines that ever ran WAITS: SAIL, on a
> triprocessor 6+KA+KL; CCRMA, on a Foonly F-1; and LLNL, on a KL-10
> used to run SUDS for the S-1 supercomputer project.

I'm especially curious about the S-1 project KL10. In the sources I
only find information about it running on a Foonly F2. I have grepped
for FTF2 and FTLLL, and other things. Where can I learn more about the
KL10?

CCRMA upgraded to a Foonly F4 at some point (see e.g.
https://ccrma.stanford.edu/~aj/archives/docs/all/646.pdf pp 3-4), but I
don't see this in the files so I suppose the hardware worked the same.

Lars Brinkhoff <lars.spam@nocrew.org> writes:

> I have checked the [S,SYS] sources (especialy HEAD and OUTER) to try to
> get a more clear picture of how WAITS evolved with regards to hardware.
> So I'd like to ask about some of the points you raised.

> Rich Alderson wrote:

>> The SAIL KL-10 was a stock 1080

> I see the CPU was updated to a KL10 model B around 1983, and also
> starting to use RH20 disk roughly the same time. Do you know if the
> 1080 was replaced with orange boxes, or just upgrading the internals?

"Model B" does not equate to "orange box", nor even to blue corporate cabinets.
In fact, "Model B" is a misnomer.

I've lost track of the document which outlined the DEC internal designations,
but the so-called "Model A" was an orignal 1080 or 2040 board set and
backplane, but had nothing to do with what Manufacturing called an A or B.
Most 1080s in the field were D type CPUs, that is, so-called "Model B" systems.

1080s were always highboy blue cabinetry. LCM+L had one (never shown in the
post opening computer room) which still had the switches labeled for a DECTAPE
drive on the 11/40, but with an RX-01 floppy drive substituted.

The only orange cabinetry in the same room with SU-AI was the DEC-20 called
SCORE.

I think the upgrade you are referring to was an update to a PV backplane, as
was present in 1090 and 2060 systems. (The PW was when MG20 memory and the
doubled cache came along, in the 1095 and 2065.)

>> There were only 3 machines that ever ran WAITS: SAIL, on a
>> triprocessor 6+KA+KL; CCRMA, on a Foonly F-1; and LLNL, on a KL-10
>> used to run SUDS for the S-1 supercomputer project.

> I'm especially curious about the S-1 project KL10. In the sources I
> only find information about it running on a Foonly F2. I have grepped
> for FTF2 and FTLLL, and other things. Where can I learn more about the
> KL10?

The only things I know about the system at LLNL was that it ran WAITS in order
to run SUDS in order to design the S-1 supercomputer. There were feature
switches in WAITS sources to discard features which were lacking in that KL.

> CCRMA upgraded to a Foonly F4 at some point (see e.g.
> https://ccrma.stanford.edu/~aj/archives/docs/all/646.pdf pp 3-4), but I
> don't see this in the files so I suppose the hardware worked the same.

I think it must have, because all the internal documentation refers to the
"CCRMA F2".

NB: I was not a WAITS systems programmer when I was at Stanford (1984-1991),
nor even a Tops-10 programmer at that time. I knew the systems folks at SAIL
because they were on the list of technical backups for potential disasters at
all the other PDP-10 sites on the Stanford campus (approximately a dozen), just
as I was. I only learned Tops-10 after going to work for Paul Allen in 2003,
and WAITS after Ralph, Martin, Len, and I got the monitor to boot on the
Tops-10 box at LCM (not yet "+L") the afternoon of our grand opening event in
April 2013 and PGA said to get it running.

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

Rich Alderson wrote:
> I think the upgrade you are referring to was an update to a PV
> backplane, as was present in 1090 and 2060 systems.

Thanks. Yes, that makes sense.

> The only things I know about the system at LLNL was that it ran WAITS
> in order to run SUDS in order to design the S-1 supercomputer. There
> were feature switches in WAITS sources to discard features which were
> lacking in that KL.

Sorry if I'm a pest about this, but if at some point you would to check
on this I would like to learn what exactly those feature switches those
are, and whether it's a KL or an F2. No urgency, of course.

I have snooped around myself, and what I see is e.g.

IFN FTLLL,< ;LLL WAITS assembly switches, where different from SU-AI's.
[...]
XD FTKL10,0 ;F2 ISN'T A KL
XD PRCONF,0 ;BUT IT IS SORT OF A KA

I'm documenting what I learn about the WAITS disk format here:

https://gunkies.org/wiki/WAITS_on-disk_file_structure

It's a work in progress.

On Wednesday, June 14, 2023 at 10:43:31 PM UTC-7, Lars Brinkhoff wrote:
> I'm documenting what I learn about the WAITS disk format here:
> https://gunkies.org/wiki/WAITS_on-disk_file_structure
> It's a work in progress.

Just wondering, how was this supposed to be done?

Are the original sysgen files lost now, so the only way is to restore
an already generated and running system?

gah4 wrote:
> Just wondering, how was this supposed to be done? Are the original
> sysgen files lost now, so the only way is to restore an already
> generated and running system?

Rich Alderson already touched on this:

"There was never such a thing as an installation tape for WAITS. It
grew organically from the PDP-6 monitor, and officially diverged from
the DEC monitor ("Tops-10") at the 4S72 release ("Level 4 monitor,
Swapping, 1972"). There were only 3 machines that ever ran WAITS:
SAIL, on a triprocessor 6+KA+KL; CCRMA, on a Foonly F-1; and LLNL, on
a KL-10 used to run SUDS for the S-1 supercomputer project. If a new
release was created, it was loaded onto a bootable disk and carried to
the other sites."

I don't think any sysgen was lost, exactly. For a long time there was
just a single site, so there was no need to have any installation media.
I'm guessing there was a set of backup disk packs in case the file
system crashed.

Yes, this does create a bootstrap problem in that it was not intended to
build a new system without already having a running system. But this
has been solved twice, which goes to show it's possible to do.

On Thursday, June 15, 2023 at 11:09:29 AM UTC-7, Lars Brinkhoff wrote:
> gah4 wrote:
> > Just wondering, how was this supposed to be done? Are the original
> > sysgen files lost now, so the only way is to restore an already
> > generated and running system?

> Rich Alderson already touched on this:

> "There was never such a thing as an installation tape for WAITS. It
> grew organically from the PDP-6 monitor, and officially diverged from
> the DEC monitor ("Tops-10") at the 4S72 release ("Level 4 monitor,
> Swapping, 1972"). There were only 3 machines that ever ran WAITS:
> SAIL, on a triprocessor 6+KA+KL; CCRMA, on a Foonly F-1; and LLNL, on
> a KL-10 used to run SUDS for the S-1 supercomputer project. If a new
> release was created, it was loaded onto a bootable disk and carried to
> the other sites."
> I don't think any sysgen was lost, exactly. For a long time there was
> just a single site, so there was no need to have any installation media.
> I'm guessing there was a set of backup disk packs in case the file
> system crashed.

> Yes, this does create a bootstrap problem in that it was not intended to
> build a new system without already having a running system. But this
> has been solved twice, which goes to show it's possible to do.

So, at least at the beginning, and maybe later, the sysgens were
done on TOPS-10? I am not sure how conditional assembler works,
if any, in MACRO-10.

But okay, any system should be able to be generated from source.
Many sysgens use mostly object programs, partly to avoid distributing
source for business reasons. Also, it is faster.

On 2023-06-17 06:30, gah4 wrote:
> On Thursday, June 15, 2023 at 11:09:29 AM UTC-7, Lars Brinkhoff wrote:
>> gah4 wrote:
>>> Just wondering, how was this supposed to be done? Are the original
>>> sysgen files lost now, so the only way is to restore an already
>>> generated and running system?
>
>> Rich Alderson already touched on this:
>
>> "There was never such a thing as an installation tape for WAITS. It
>> grew organically from the PDP-6 monitor, and officially diverged from
>> the DEC monitor ("Tops-10") at the 4S72 release ("Level 4 monitor,
>> Swapping, 1972"). There were only 3 machines that ever ran WAITS:
>> SAIL, on a triprocessor 6+KA+KL; CCRMA, on a Foonly F-1; and LLNL, on
>> a KL-10 used to run SUDS for the S-1 supercomputer project. If a new
>> release was created, it was loaded onto a bootable disk and carried to
>> the other sites."
>
>> I don't think any sysgen was lost, exactly. For a long time there was
>> just a single site, so there was no need to have any installation media.
>> I'm guessing there was a set of backup disk packs in case the file
>> system crashed.
>
>> Yes, this does create a bootstrap problem in that it was not intended to
>> build a new system without already having a running system. But this
>> has been solved twice, which goes to show it's possible to do.
>
> So, at least at the beginning, and maybe later, the sysgens were
> done on TOPS-10? I am not sure how conditional assembler works,
> if any, in MACRO-10.
>
> But okay, any system should be able to be generated from source.
> Many sysgens use mostly object programs, partly to avoid distributing
> source for business reasons. Also, it is faster.

I wonder if you are expecting too much. I sortof understand it as there
is no such thing as a sysgen, and never was.

You basically just had a running system. Yes, you could change sources
and recompile the kernel, and boot the new one. But that's pretty much
how it was. It was self-hosting, and was running, and that's about it.
It just evolved organically on the host(s) it existed on.

The few times a new system was brought up, it was done by cloning an
existing system. Copy the disk, move the copied disk over to the new
machine and boot. And off you go.

But I never actually used WAITS, only read about it. So I might have
misunderstood things...

Johnny

gah4 wrote:
> So, at least at the beginning, and maybe later, the sysgens were done
> on TOPS-10?

WAITS (but not it was not even called that until 1977 or so) evolved
from the PDP-6 Monitor, so I guess it did whatever Monitor did in the
beginning. As far as I can tell (and maybe Alderson knows more),
building a new WAITS monitor isn't done with any "sysgen" (I don't know
exactly what that is) but just something like "LOAD @SYS" in the [S,SYS]
directory.

On Saturday, June 17, 2023 at 12:18:40 AM UTC-7, Johnny Billquist wrote:

(snip, I wrote)
> >>> Just wondering, how was this supposed to be done? Are the original
> >>> sysgen files lost now, so the only way is to restore an already
> >>> generated and running system?

(snip)

> I wonder if you are expecting too much. I sortof understand it as there
> is no such thing as a sysgen, and never was.
I was trying to be a little generic, as every system is different, but
mostly the generating of the new kernel.

For many, at least for those years, that was selecting the available
I/O devices, and assembling in the code for them.

For Unix, there is somewhere a big struct array with one element
for each I/O device. There is a generic kernel with all the usual
devices, which one can run, and then generate a more specific
version. And one can add in new I/O devices, and compile
them into the kernel.

> You basically just had a running system. Yes, you could change sources
> and recompile the kernel, and boot the new one. But that's pretty much
> how it was. It was self-hosting, and was running, and that's about it.
> It just evolved organically on the host(s) it existed on.

Some systems have a more organized system, and some less.
The OS/360 sysgen uses the assembler to generate JCL to do
various different things. A strange use of an assembler, but that
is what they do. But you can also do it all manually.

> The few times a new system was brought up, it was done by cloning an
> existing system. Copy the disk, move the copied disk over to the new
> machine and boot. And off you go.
Some years ago, I had three DEC/Ultrix systems to bring up new.
It took so long to do the first one, that I ended up duplicating the
disk after the first one. I also did that for an HP-UX system.

> But I never actually used WAITS, only read about it. So I might have
> misunderstood things...
So I guess that the question is the assembler source that is different
from the previous system.

I presume that there is still assembler source to generate TOPS-10
and TOPS-20, if one wants to do that. I am not sure what ran on
the PDP-6.

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

> On Saturday, June 17, 2023 at 12:18:40=E2=80=AFAM UTC-7, Johnny Billquist wrote:

> (snip, I wrote)

>>>>> Just wondering, how was this supposed to be done? Are the original
>>>>> sysgen files lost now, so the only way is to restore an already
>>>>> generated and running system?

> (snip)

>> I wonder if you are expecting too much. I sortof understand it as there
>> is no such thing as a sysgen, and never was.

> I was trying to be a little generic, as every system is different, but
> mostly the generating of the new kernel.

It's called the monitor.

> For many, at least for those years, that was selecting the available
> I/O devices, and assembling in the code for them.

True, but it's more complicated than that. I'll explain why below, but first
some history.

For many years, each customer's initial monitor was assembled BY DEC, because
the records of exactly how many of each kind of device installed on each system
resided in the customer database in Marlboro. That's the PDP-6 and PDP-10
era.

Later, a program called MONGEN was provided, along with a generic monitor which
had a few requirements (1 disk, a hardcopy console, a DECtape drive), which was
booted in order to run MONGEN. This was how Tops-10 was provided all the way
to the end, with a very large library file of all the assembled monitor sources
in addition to the assembler sources (so that unless a customer made a change,
they did not have to assemble the entire monitor).

TOPS-20 was even simpler. There was a generic monitor, a library file, and a
single monitor source file called STG.MAC, which described all the memory
requirements for supported devices. The customer modified STG to describe
their local system, assembled it, and loaded the resulting STG.REL with the
library file to create a local monitor.

Also, please note that the PDP-6 and PDP-10 monitors from DEC, as well as ITS
and WAITS, include a command processor. (TOPS-20, which originated as TENEX
from BBN, instead provided a user mode command processor called the EXEC.)

In DEC parlance, the monitor IS NOT "the operating system". Instead, user mode
programs like the batch processor, the spoolers, and interprocess communication
modules, were referred to as the operating system.

> For Unix, there is somewhere a big struct array with one element
> for each I/O device. There is a generic kernel with all the usual
> devices, which one can run, and then generate a more specific
> version. And one can add in new I/O devices, and compile
> them into the kernel.

The PDP-6/-10 monitors equivalent of that struct array was the written
description of the system, and either a run of MONGEN or an editing session on
STG.MAC.

>> You basically just had a running system. Yes, you could change sources
>> and recompile the kernel, and boot the new one. But that's pretty much
>> how it was. It was self-hosting, and was running, and that's about it.
>> It just evolved organically on the host(s) it existed on.

And that's essentially what you had with WAITS.

> Some systems have a more organized system, and some less.
> The OS/360 sysgen uses the assembler to generate JCL to do
> various different things. A strange use of an assembler, but that
> is what they do. But you can also do it all manually.

Manually is precisely how it was done on PDP-10 monitors.

>> The few times a new system was brought up, it was done by cloning an
>> existing system. Copy the disk, move the copied disk over to the new
>> machine and boot. And off you go.

Not even a clone: Assemble the sources for any changed elements, run LINK
against those plus the .REL files that had not changed, and write out the
new monitor for the new system.

> Some years ago, I had three DEC/Ultrix systems to bring up new.
> It took so long to do the first one, that I ended up duplicating the
> disk after the first one. I also did that for an HP-UX system.

But that's not what happened with the WAITS systems. Instead, as noted just
above, assembly of ONLY THE CHANGED PIECES, followed by a link step.

>> But I never actually used WAITS, only read about it. So I might have
>> misunderstood things...

No, you got it right.

> So I guess that the question is the assembler source that is different
> from the previous system.

Of course.

> I presume that there is still assembler source to generate TOPS-10
> and TOPS-20, if one wants to do that. I am not sure what ran on
> the PDP-6.

There is, but those sources assume that you have a working system to run the
assembler and linker. These days, PDP-10 hardware is so fast that rather than
futz around with STG, TOPS-20 is built from scratch. (No one, for small values
of "no one", builds Tops-10 these days.)

What ran on the PDP-6 was the timesharing monitor. You can read the monitor
sources at http://pdp-6.trailing-edge.com/4.x.tar.gz if you wish.

Lars Brinkhoff <lars.spam@nocrew.org> writes:

> Date: Sat, 17 Jun 2023 12:54:17 +0000

> gah4 wrote:
>> So, at least at the beginning, and maybe later, the sysgens were done
>> on TOPS-10?

> WAITS (but not it was not even called that until 1977 or so) evolved
> from the PDP-6 Monitor, so I guess it did whatever Monitor did in the
> beginning. As far as I can tell (and maybe Alderson knows more),
> building a new WAITS monitor isn't done with any "sysgen" (I don't know
> exactly what that is) but just something like "LOAD @SYS" in the [S,SYS]
> directory.

That's fairly close.

Now for the things which make WAITS different from most other PDP-6/-10
monitors:

1. There are no privileged instructions, in the sense than any user program
can execute I/O instructions; they are treated as monitor calls, just like
opcodes 040-077 in Tops-10 and ITS, or opcode 104 ("JSYS") in TENEX/TOPS-20.

2. WAITS was intended for experimentation in the design of operating systems,
so all of the nifty devices attached to the systems as various times were
programmed IN USER MODE, because there were no privileged instructions.

3. NB: There were privileged OPERATIONS of certain monitor calls, but they
were only made slightly more difficult to use, in that a password would be
added to the otherwise perfectly ordinary user mode call. This is referred
to as GODMODE in the WAITS UUO manual.

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

Rich Alderson wrote:
> the PDP-6 and PDP-10 monitors from DEC, as well as ITS and WAITS,
> include a command processor.

Minor nit pick: ITS doesn't have any command processor. When a user
wants to log in, ITS starts SYS: ATSIGN HACTRN which would normally be
the user mode DDT. (If that fails, a very early version falls back to
UT2: ATSIGN HACTRN, supposedly a trace from when ITS ran off DECtape.)

> TOPS-20, which originated as TENEX from BBN, instead provided a user
> mode command processor called the EXEC.

Parenthetically, for those who might not know, TENEX (and, I believe,
TOPS-20) has something called Mini-Exec. It's a kind of a built-in
command processor, but not for users. It only has a few single-letter
command for system maintenance.

On Saturday, June 17, 2023 at 6:56:27 PM UTC-7, Rich Alderson wrote:
> gah4 <ga...@u.washington.edu> writes:

(snip)

> > I was trying to be a little generic, as every system is different, but
> > mostly the generating of the new kernel.

> It's called the monitor.

I was trying to be generic, and that seems to be the usual generic
term. OS/360 calls it the nucleus. But that doesn't include much
non-resident parts.

As well as I know it, OS/360 is the first with "operating system"
in its name, though it might be that some earlier should also count.

> > For many, at least for those years, that was selecting the available
> > I/O devices, and assembling in the code for them.

> True, but it's more complicated than that. I'll explain why below, but first
> some history.
> For many years, each customer's initial monitor was assembled BY DEC, because
> the records of exactly how many of each kind of device installed on each system
> resided in the customer database in Marlboro. That's the PDP-6 and PDP-10
> era.
(snip)

> Also, please note that the PDP-6 and PDP-10 monitors from DEC, as well as ITS
> and WAITS, include a command processor. (TOPS-20, which originated as TENEX
> from BBN, instead provided a user mode command processor called the EXEC.)
> In DEC parlance, the monitor IS NOT "the operating system". Instead, user mode
> programs like the batch processor, the spoolers, and interprocess communication
> modules, were referred to as the operating system.

I think that is usual for everything except MS-DOS.

But okay, for OS/360 there is the resident nucleus, and then some
non-resident parts, especially for SVCs. Non-resident SVC (supervisor call)
routines are in 2K byte pieces, copied into a special buffer when
needed. So, not user mode, but also not nucleus.

As S/360 and PDP-10 were about the same time, and when memory
was still pretty expensive, lots of tricks were needed to fit everything
into available memory.

> > For Unix, there is somewhere a big struct array with one element
> > for each I/O device. There is a generic kernel with all the usual
> > devices, which one can run, and then generate a more specific
> > version. And one can add in new I/O devices, and compile
> > them into the kernel.

> The PDP-6/-10 monitors equivalent of that struct array was the written
> description of the system, and either a run of MONGEN or an editing session on
> STG.MAC.

(snip)
>> But you can also do it all manually.

> Manually is precisely how it was done on PDP-10 monitors.

Can it still be done manually?

(snip, I wrote)

> > I presume that there is still assembler source to generate TOPS-10
> > and TOPS-20, if one wants to do that. I am not sure what ran on
> > the PDP-6.

> There is, but those sources assume that you have a working system to run the
> assembler and linker. These days, PDP-10 hardware is so fast that rather than
> futz around with STG, TOPS-20 is built from scratch. (No one, for small values
> of "no one", builds Tops-10 these days.)
OK, so back to the original question. Is enough WAITS source around
to generate one from source?

> That's fairly close.
> Now for the things which make WAITS different from most other PDP-6/-10
> monitors:
> 1. There are no privileged instructions, in the sense than any user program
> can execute I/O instructions; they are treated as monitor calls, just like
> opcodes 040-077 in Tops-10 and ITS, or opcode 104 ("JSYS") in TENEX/TOPS-20.
So emulated like VM/370?

There are some fun parts of OS/360, which VM/370 has to know about,
like self-modifying channel programs.

> 2. WAITS was intended for experimentation in the design of operating systems,
> so all of the nifty devices attached to the systems as various times were
> programmed IN USER MODE, because there were no privileged instructions.
I am not completely sure by now, but I think that was also a reason
for creating VM/370. Well, CP/67 before that.

> 3. NB: There were privileged OPERATIONS of certain monitor calls, but they
> were only made slightly more difficult to use, in that a password would be
> added to the otherwise perfectly ordinary user mode call. This is referred
> to as GODMODE in the WAITS UUO manual.

gah4 wrote:
> Can it still be done manually?
> Is enough WAITS source around to generate one from source?

Yes. I have manually assembled a WAITS monitor from ~1974 sources.

gah4 <gah4@u.washington.edu> writes:
>On Saturday, June 17, 2023 at 12:18:40=E2=80=AFAM UTC-7, Johnny Billquist w=
>rote:
>
>(snip, I wrote)
>> >>> Just wondering, how was this supposed to be done? Are the original=20
>> >>> sysgen files lost now, so the only way is to restore an already=20
>> >>> generated and running system?=20
>
>(snip)
>
>> I wonder if you are expecting too much. I sortof understand it as there=
>=20
>> is no such thing as a sysgen, and never was.=20
>=20
>I was trying to be a little generic, as every system is different, but
>mostly the generating of the new kernel.
>
>For many, at least for those years, that was selecting the available
>I/O devices, and assembling in the code for them.
>
>For Unix, there is somewhere a big struct array with one element
>for each I/O device. There is a generic kernel with all the usual
>devices, which one can run, and then generate a more specific
>version. And one can add in new I/O devices, and compile
>them into the kernel.=20
>
>> You basically just had a running system. Yes, you could change sources=20
>> and recompile the kernel, and boot the new one. But that's pretty much=20
>> how it was. It was self-hosting, and was running, and that's about it.=20
>> It just evolved organically on the host(s) it existed on.=20
>
>Some systems have a more organized system, and some less.
>The OS/360 sysgen uses the assembler to generate JCL to do
>various different things. A strange use of an assembler, but that
>is what they do. But you can also do it all manually.

The Burroughs systems automatically configured the MCP to match
the hardware on boot, based on a set of configuration cards
read during the initial coldstart. Later systems had ID bytes
in each I/O controller so the configuration cards were only
technically needed for legacy devices.

There was no need to recompile or relink the MCP, it would
bring in whatever segments were necessary to support the
current hardware at boot or runtime. An example coldstart deck:

------ coldstart_206s.crd ---------------
HOSTNAME SYSTEML
DLP 3 TPR
UNIT 3/0 FUL96 TPR
DLP 5 DISK
DISK 5/0 ID 01 SUBSYSTEM 1 0 221183
DLP 6 GCR
UNIT 6/0 GCR SHARED
UNIT 6/1 GCR SHARED
UNIT 6/5 GCR SHARED
DLP 1 CRD
UNIT 1/0 CRD SAVED
DLP 10 CONSOLE
UNIT 10/4 PRISPO ODT LEVEL 9 HLSPO AD DEF
DLP 16 PACK HSTLAD
PACK 16/0
PACK 16/1
DISK 16/2 ID 02 SUBSYSTEM 2 DEFAULT
CONTROL DEBUG MCP
USE BOJ
USE EOJ
USE STOQ
USE DUMP DISK
USE PBD
USE SLOG AUTO 10000 WRAP
USE ZIPM
STOP
--------- end --------------

The DLP (Data Link Processor) (or CHANNEL) card specified
the channel and associated hardware type (which was matched
against the ID byte in the DLP). The UNIT card specified one
or more units on the channel (including Operator Display
Terminals (ODT), printers, tapes, card readers/punches).

(DISK was 100-byte sectors, PACK was 180-byte sectors).

The USE cards selected optional MCP features, e.g.

STOQ (Storage Queues for inter application communications),
SLOG (System Log)
PBD (Printer Backup to disk)
CRCR (Core-to-Core IPC)
DCP (Data Communications Processor support)

etc.

Most of these could be also specified dynamically at runtime
to add/remove hardware or change the set of supported features.

On Monday, June 19, 2023 at 8:36:03 AM UTC-7, Scott Lurndal wrote:

(snip)

> The Burroughs systems automatically configured the MCP to match
> the hardware on boot, based on a set of configuration cards
> read during the initial coldstart. Later systems had ID bytes
> in each I/O controller so the configuration cards were only
> technically needed for legacy devices.
> There was no need to recompile or relink the MCP, it would
> bring in whatever segments were necessary to support the
> current hardware at boot or runtime.
(snip)

Static configuration is nice for keeping things small, important
in the earlier days.

The smallest OS/360 fits in 20K, allowing 44K on a 64K machine
for user programs. The PL/I (F) compiler is supposed to fit
in 44K. It is made up of a large number of tiny modules,
all loaded dynamically when needed. At the end of every run,
it tells how much memory was used, and how much was needed
to keep the symbol table off disk.

The first one I remember doing all this for is SunOS.
I/O device configuration assigns the major and minor numbers
for I/O devices that go into /dev.

Solaris does it dynamically, and rewrites /dev each time.
(Or maybe only if it finds that something changed.)

gah4 <gah4@u.washington.edu> writes:
>On Monday, June 19, 2023 at 8:36:03=E2=80=AFAM UTC-7, Scott Lurndal wrote:
>
>(snip)
>
>> The Burroughs systems automatically configured the MCP to match=20
>> the hardware on boot, based on a set of configuration cards=20
>> read during the initial coldstart. Later systems had ID bytes=20
>> in each I/O controller so the configuration cards were only=20
>> technically needed for legacy devices.=20
>=20
>> There was no need to recompile or relink the MCP, it would=20
>> bring in whatever segments were necessary to support the=20
>> current hardware at boot or runtime.=20
>(snip)
>
>Static configuration is nice for keeping things small, important
>in the earlier days.

I'll point out that the burroughs systems were designed in the early
1960's and first customer ship was 1966. Their ease of installation
and use was a definite benefit when comparing with the contemporaneous
IBM 360 systems they were competing with.

>
>The smallest OS/360 fits in 20K, allowing 44K on a 64K machine
>for user programs. The PL/I (F) compiler is supposed to fit
>in 44K. It is made up of a large number of tiny modules,
>all loaded dynamically when needed. At the end of every run,
>it tells how much memory was used, and how much was needed
>to keep the symbol table off disk.

The Burrough B2500/B3500 supported 10K to 500K byte systems
using the same MCP binary. See 1025475_B2500_B3500_RefMan_Oct69.pdf
on bitsavers.

>
>The first one I remember doing all this for is SunOS.
>I/O device configuration assigns the major and minor numbers
>for I/O devices that go into /dev.
>
>Solaris does it dynamically, and rewrites /dev each time.
>(Or maybe only if it finds that something changed.)

The SVRx derivatives (and Solaris) weren't good examples
of ease of installation, although later SVR4 and Solaris
systems eventually supported dynamic loading of drivers.