Rob Storey has been posting in alt.folklore.computers about
the 7094 emulator he's writing. It has progressed to the
point where it can run IBSYS and FORTRAN IV. Some folks
suggested that he try CTSS next. Sounds like a great
For those of us who know nothing about CTSS, can anyone give
a brief description of it, for example, what were the main
ideas behind it, what the user environment was like, what it
was like to use, its strengths, weaknesses and so forth?
melinda has some amount of discussion of ctss in her vm history paper
... somewhat tracing common heritage of vm & multics back to ctss.
copies of the paper can be found in various formsts (ps, pdf, listing,
i had previously referenced an early version of the paper, posting to
vmshare and not available in the vmshare archives, recent ref:
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
> For those of us who know nothing about CTSS, can anyone give
> a brief description of it, for example, what were the main
> ideas behind it, what the user environment was like, what it
> was like to use, its strengths, weaknesses and so forth?
Main idea: time-sharing
Time frame: 1961-1973
User environment: command line.
Hardware base: Modified IBM 7094, 2x32K 36-bit words.
Strengths: early, multi language, efficient
Weaknesses: maxed out about 35 users, 0.35 MIP CPU,
datacomm on esoteric 7750 comm controller.
*He* suggests that some other folks try CTSS next ;-)
I would be happy to add the hardware RPQ's to the emulator, but trying
to get CTSS happening would best be done by someone who knows what to
expect, and willing to put in the time and effort.
BTW: Is there anywhere a definitive description and precise details of
the 7094 extensions required by CTSS?
> BTW: Is there anywhere a definitive description and precise details of
> the 7094 extensions required by CTSS?
I mentioned that it would be nice to have this info in
mail to CTSS colleagues, and Jerry Saltzer responded
- It's not clear there was ever a precise written spec.
MIT sent a letter to IBM asking for features, and
the IBM engineers may not have done it just the way
the letter said. Jerry remembers that Bob Daley and
others had do to a lot of trial and error at the
- We could figure out a lot of the RPQ features by
reverse engineering, by looking at CMEXIT. See
RTRN0159 ff in MIT8C0.
TIB is Transfer Instruction Execution to Core B
SEA is Set Execution to A core
SEB is Set Execution to B core
LRI is Load Relocation Indicator
LPI is .. I forget
TIA is Transfer Instruction Execution to Core A
.. used all over B-core programs to cause a trap
into the supervisor.
Looking a little more closely, this is actually a *huge* job.
CTSS requires not only the CPU and storage extensions, but several new
1414 and 7750 controllers for these
1301 disk and/or 7320 drum
7631 controller for these
Which is a lot of work, but doable. For the most part they are
distinct extensions to the existing implementation.
The killer is that all of these devices require the 7909 data channel,
which is considerably more complex than the standard 7607 channel.
Channel operations are intimately tied into many parts of the
emulator, and because they operate asynchrounously with the CPU, they
(and their associated I/O operations) have been *by far* the greatest
debugging headache to date.
> Looking a little more closely, this is actually a *huge* job.
> CTSS requires not only the CPU and storage extensions, but several new
> I/O devices:-
> 1014 consoles
> 1414 and 7750 controllers for these
> 1301 disk and/or 7320 drum
> 7631 controller for these
> Which is a lot of work, but doable. For the most part they are
> distinct extensions to the existing implementation.
> The killer is that all of these devices require the 7909 data channel,
> which is considerably more complex than the standard 7607 channel.
> Channel operations are intimately tied into many parts of the
> emulator, and because they operate asynchrounously with the CPU, they
> (and their associated I/O operations) have been *by far* the greatest
> debugging headache to date.
The disk and drum is the most important part.
CTSS did not support 1014 consoles or 1414 controllers.
The 7750 was a very idiosyncratic machine and I don't
know if we even have the 7750 program, so any simulation
of teletypes, 1050s, 2741s, etc would have to be
done less faithfully.
Why not consider not emulating some of these devices directly, but changing
the source code to access the native facilities on the OS where the emulator
is running? This might ease the job, improve the emulated performance, and
actually make the "use" of the system more reasonable.
It is a lot of work mainly because often the hardware manuals are no
longer available, or features are underdocumented. Often operating
sources can be used to reverse engineer the expected behaviour.
It can be done - living proof is the very complete Control Data
Corporation 6600 and CYBER 7x emulation (know as Desktop CYBER
emulator) which supports console, extended core storage, tapes, disks,
printers, card readers, card punches and terminal muxes. The terminal
muxes actually work as Telnet servers and you can remotely login in
the various supported OSs (COS, NOS 1, NOS 2, SCOPE and NOS/BE).
It took about 2 months to emulate the CPU, PP subsystem, console and
memory. It took a further 18 months to do the rest.
I'll second this one. While a lot of work has gone into the CPU emulation in
Hercules, more has gone into the various I/O device emulations, and more
bugs have lurked there.