The IBM 7094 was big, taking up a large room at the MIT computer centre for its CPU and peripherals.

It was one pf the fastest computers available in the early 1960s.

It was also very expensive: a typical system sold for $2.9 million (equivalent to $23 million in 2023) or could be rented for $63,500 a month (equivalent to $501,000 in 2023) (from Wikipedia).

All this meant that very few sites could afford one - mostly universities and large corporations with extensive need for scientific computation facilities.

From 1952 IBM had developed a range of computers, first using vacuum tubes and later transistors. The table below shows how their scientific range evolved - there were also commercial application versions that were not completely compatible with the scientific models.

MIT had a 704, then a 709 which was the first machine to get CTSS. They upgraded through 7090 - 7094 - 7094 II and had a second machine to support Project MAC.

The 7094 had a 36 bit word size and could directly address up to 32kw of core memory (so around 144kB - bytes as a standard measure of memory had not yet been standardised).

It has a single main accumulator and a multiplier/quotient register for multiplication and division. It has four index registers allowing indirect addressing. Numbers were stored in sign/magnitude form, with the top bit the sign and the remaining 35 bits the number.

At the time there was no standard for text encoding like ASCII; the 7094 used 6-bit BCD encoding, allowing only numbers, capital letters and some punctuation symbols.

For CTSS, MIT requested an additional 32kw of memory used in a bank-switched manner, so one bank was for the supervisor and the other bank could be fully utilised by the client program.

The primary storage mechanism for computers at the time was magnetic tape. This offered fast sequential read/write but due to the linear nature of tape could be slow for random-access. Installations would often have multiple tape drives: for a batch Fortran compile run for example, there could be one tape for the compiler, one for the input program, one for scratch storage and one for the output object, all being used at the same time. CTSS used tapes for user file storage on early versions before the disk was available; after that it was used for bulk file input and backup. Each tape could store around 3MB and could be read at several hundred bytes per second.

Random-access storage was done by what IBM called DASDs (direct access storage devices) and what we'd now call drums and hard disks. The 7320 drum was a cylinder with one head per track that could store 174,000 36 bit words. CTSS used this for swapping and some file storage.

The 1301 hard disk was one of the first commercially available hard disks and could store 28MB of data. It spun at 1800 rpm and could transfer around 90,000 bytes per second. CTSS used this for file storage. If you wanted to buy one, it would cost over $100,000 in 1963 dollars.

The console had switches and lights for the operator to toggle in values, view the state of the computer and start operations. There was also a line printer for logging.

User data could be fed into and out of the machine by punched card. Each card holds 80 characters. In practice this was not used for regular user input as it was too costly in CPU cycles; the user would instead punch data to cards using an off-line punch; the cards would be transferred to tape via a smaller computer and finally the tape loaded into the 7094.

What is missing here is interactive input/output. MIT purchased from IBM a data concentrator to handle multiple serial lines and used this to attach terminals such as the IBM 1050, 2741 and later the TTY37. It was also possible to connect over the telephone wires using an acoustic coupler.

IBM 1052 Printer-Keyboard, part of a IBM 1050 terminal. Source: Wikipedia/ComputerGeek7066. License: CC BY-SA 4.0

There was also an experimental graphical display connected to the IBM via a PDP-7, but this is not supported by the emulator.

There were also a number of other items requested from IBM by MIT to support CTSS:

• Trapping I/O operations to interrupts so they could be handled by the supervisor
• Memory protection and relocation
• A real time clock and interval timer

Much of the information on this page came from Wikipedia. Another great source is Tom Van Vleck's page on multicians.org about CTSS.

May 2025: Tom Van Vleck noted that the data concentrator was purchased from IBM rather than a special creation for MIT, and pointed out that IBM 1050/2741 terminals were used initially, followed later by the TTY33.

I welcome any questions or comments, and also especially any corrections if I have got something wrong. Please email me at rupert@timereshared.com and I will add it here and update the main text.

We'll use my eliza-ctss repo to get set up as this automates several of the steps involved. You can also get the components directly from the s709 page and set it up following the instructions there - both methods will yield the same system.

You will need a Unix like environment that can compile C code, run shell scripts etc. You will also need a telnet CLI or GUI client.

Start by cloning the repo and changing into its directory. All commands will be run from there.

  $ git clone https://github.com/rupertl/eliza-ctss
  $ cd eliza-ctss

(Numbers in square brackets refer to notes below, do not enter these on your terminal.)

  $ source env.sh                    [1]
  $ make-binaries                    [2]
  $ make-disks                       [3]
  $ format-disks                     [4]
  $ install-disk-loader              [5]
  $ installctss                      [6]

1. Set up the path and environment variables needed. Run this before any other commands.
2. Compile the s709 and utility binaries, and place them into ctss/bin.
3. Create files in dasd/ representing the disk and drums needed for CTSS.
4. Format the disks and drums. You will be prompted to press Enter a few times and type q and Enter when done. This may take 60s.
5. Install a basic disk loader on the disks to prepare for the full CTSS install.
6. Install the base CTSS components on the disks.

  $ source env.sh
  $ runctss

This will start CTSS and begin accepting logins. The simulator window will show log in/out activity.

In another window, telnet to port 7094 on your local machine. Type login guest and at the password prompt type system.

$ telnet 0 7094
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
s709 2.4.1 COMM tty0 (KSR-37) from 127.0.0.1

MIT8C0: 1 USER AT 12/30/14  852.7, MAX = 30
READY.                                     
      
login guest
W 852.8
Password
 M1416     5 LOGGED IN  12/30/14  852.8 FROM 700000
 LAST LOGOUT WAS  12/25/14 1626.0 FROM 700000      
 HOME FILE DIRECTORY IS M1416 GUEST          
                                   
THIS IS A RECONSTRUCTED CTSS SYSTEM.
IT IS A DEBUG AND NOT FULLY FUNCTIONAL VERSION.
                                               
 CTSS BEING USED IS: MIT8C0
R .050+.000

Your two windows should now look like the image at the top of this post.

• CTSS communicates in upper case, but you can type in lower case and it will be translated to upper automatically.
• There is no prompt, but you will know CTSS is ready for input when it prints R followed by 2 numbers (which represent the CPU time and swapping time for the last command run).
• Delete will delete the last character and Control-U will kill a whole line. This is an affordance of the emulator; on a a real teletype you'd type # to delete and @ to kill; these keys still work as such on the emulator.
• Control-C will interrupt a program and Control-\ (backslash) will quit it.
• Commands are in the familiar format of the program name followed by parameters. Optional arguments are enclosed in brackets.
• When you enter a command, CTSS will first type something like W 1724.3. The W means you are waiting for the command to load and the numbers are the time of day the command started (using tenths of minutes after the decimal point).

CTSS has the concept of a Master File Directory containing several User File Directories, one for each user. It is not possible to make further sub-directories. There is the concept of a shared directory which we will look at in a later post.

To view the contents of your directory, type listf.

listf 
W 1305.9
        
     9 FILES    90 RECORDS
 NAME1  NAME2 MOD NOREC   USED
  CQA1    MAD 000     3 12/30/14
 HELLO    MAD 000     1         
PRIMES MADTRN 000     2
MYLISP  SAVED 000    77 12/26/14
  FACT   LISP 000     1         
DEFINE   LISP 000     2
 FFACT   LISP 000     1 12/13/14
PROCAL   LISP 000     2         
BOTTLE    MAD 000     1
                       

R .016+.016

You can give parameters to change the display order and select which files are printed. For example, to show MAD source code files in alphabetic order:

listf (sna1) * mad
W 1328.5
        
     3 FILES     5 RECORDS
 NAME1  NAME2 MOD NOREC   USED
BOTTLE    MAD 000     1 12/13/14
  CQA1    MAD 000     3 12/30/14
 HELLO    MAD 000     1         
                       

R .016+.016

File names have two parts, called name1 and name2, each up to six characters long. Note the first and second parts are not separated by a dot, so what we'd call "hello.mad" would be "HELLO MAD" on CTSS. The first part of the name is called name1, hence the parameter to sort by name1 is (sna1). As shown, you can use * as a wildcard.

You can print a file to the console with P. This will include some blank lines at the end so you will need to scroll up your terminal to see it.

p hello mad
W 1332.4
        

	 VECTOR VALUES HELLO = $12H HELLO WORLD*$
	 PRINT FORMAT HELLO                      
	 END OF PROGRAM    


         
R .000+.033

Let's compile and run the above file.

mad hello (list)
W 1333.7
LENGTH 00020.  TV SIZE 00003.  ENTRY 00011
R .016+.033

As the name2 of the file was MAD, we don't need to give it. If the file had been called hello mymad we'd have entered mad hello mymad.

The compile did not produce any errors. If you do a listf for files you will see two new ones.

listf hello *
W 855.3
       
     3 FILES     3 RECORDS
 NAME1  NAME2 MOD NOREC   USED
 HELLO    MAD 000     1 01/05/14
 HELLO    BSS 000     1         
 HELLO    BCD 000     1
                       

R .016+.016

The BCD file contains a listing of the compilation. The BSS file contains object code.

There is no separate linker step required to get this in a runnable state. Instead, the loader will bring this into memory and find any called routines. By typing LOADGO you can then run ut immediately.

loadgo hello
W 1335.0
EXECUTION.
 HELLO WORLD
  EXIT CALLED. PM MAY BE TAKEN.
R .166+.016

Type logout. The system will also log you off after a period of inactivity. You can start the telnet session again if you want to login again.

CTSS will support up to 30 simultaneous users, but note if you are already logged in with a certain user ID, you cannot start a second session.

It's important to shut down CTSS cleanly when finished to avoid corrupting its disks.

You will need to switch back to the main emulator window you started earlier - this cannot be done from the telnet session.

Execute the following, pressing Enter after each non Control-C line.

• Press Control-C
• Type ek 40017
• Type st
• Press Control-C
• Type ek 0
• Type st
• Press Control-C
• Type ek 40032
• Type st
• Type q and Enter to exit.

What is going on here? On the real IBM 7094 the operator would initiate shutdown by toggling in a value on the front panel (ek, for enter keys, in the emulator)

You can start CTSS again by running runctss as before.

If you forget to do the above, or your machine crashes, or if there are any problems starting CTSS again, all is not lost. Run this command to do the equivalent of a fsck or chkdsk.

  $ source env.sh
  $ salvagectss

You will need to type st a couple of times to start the machine. When the output says QUIT, type q.

The CTSS Programmer's Guide section AA.2 has a contemporary "Time-sharing Primer" showing nee users how to perform simple tasks.

There is a good amount of documentation at bitsavers.org covering the machine and the operating system. Probably the best reference is the 1969 Programmer's Guide.

The original source code for CTSS was found on a backup tape 20 years ago and has been reconstructed into a version runnable on two emulators

• s709, by David Pitts
• simh, by Richard Cornwell

We will use s709 for most of the work on this site as it is slightly easier to use.

May 2025: Tom Van Vleck suggested using "remote keybaors/printer devices" instead of "teletypwriters", making changes to the bullet points and noted:

MIT having two 7094s was a height of affluence. Having a big mainframe computer was sort of like owning an ocean liner: cost to run, skilled staff required, etc.

I welcome any questions or comments, and also especially any corrections if I have got something wrong. Please email me at rupert@timereshared.com and I will add it here and update the main text.