Samuel playing against the IBM 7090. Source: IBM

Arthur Samuel started out working on vacuum tubes at Bell Labs in the 1930s. In 1946 he became a professor at the University of Illinois. Wanting to get a computer for the university, he came up with a proposal to build one, and for it to run a program that could play checkers. He started planning for it on paper, but both it and the computer were not finished when he left in 1949 to work at IBM.

There his main role was on vacuum tubes and later transistors, but the problem of checkers still intrigued him. He worked on it using the IBM 70x series of machines - according to a letter to a computer magazine journalist in 1979, it was written initially in raw machine code as even an assembler was not available for the IBM machine yet. A first version was ready in 1952, but

It was not until 1954, with the advent of the IBM 704 that my program was able to play an interesting game. My contribution was to add learning to the program, and I believe that I can claim a first for this.

In 1956 the program was demonstrated on TV and caught the imagination of the public. Eventually it was able to play games at a level that could sometimes challenge a master player.

Using techniques such as minimax, alpha-beta pruning and rote learning, his work was influential in the early years of AI; Samuel was present at John McCarthy's 1956 Dartmouth workshop and his work was included in Feigenbaum and Feldman's seminal 1960s overview of AI, Computers and Thought.

He retired from IBM in 1966 and came to SAIL as a senior member of staff. Here he helped with many of the lab's projects, and also ported his IBM 7090 assembly program to PDP-10 assembly language. The version we have running today is from 1972.

Checkers running on WAITS. Source: Rupert Lane. License: CC0.

He picked it up again in 1976 due to interest from other researchers, and played against a team at Duke University who had a new program running on an IBM System/360. Two games were played, but not to completion due to the amount of CPU time needed. According to an account by Samuel:

it was believed that the Duke program had a possible win in both games. Subsequent analysis reveals that one of these games might still lead to a draw.

Also in 1977, he worked with the makers of the VideoBrain Family Console to develop a version of checkers for this early home computer. This was a cut-down version, as the system only had 1KB of RAM, but offered four different levels of difficulty. He also helped on the AI for the VideoBrain version of Reversi/Othello, Vice Versa.

VideoBrain checkers program and manual. Source (l) atariprotos.com (r) archive.org

The program can be run on any terminal type by typing R CHECKE. Type HELP (must be in upper case) to see a list of commands: you can enter initial board settings, adjust playing parameters and even have the computer play itself with the PS command.

By default, you are playing first (as black/red) and the computer second (as white/blue). You enter moves by typing the source and destination squares, using the standard notation where 1 is the bottom right position and 32 the top left.

Here I start the program and move from square 9 to square 13.

.R CHECKE

        26 JUL 74


1*      9 13

The program will then try to find the best move and print it, along with some statistics on the number of positions it searched, the best value of its evaluation function, and the time taken in milliseconds (so about 13s here, would have been much slower on real hardware)

        MOVE   # OF BDS    PIECE   EVAL   TIME

2       23-19    219956.       0     35  13567

so it has moved 23-19. You can type the instruction BD to display the board in ASCII:

3*     BD

* * * * * * * * * *
* + W + W + W + W *
* W + W + W + W + *
* + W +   + W + W *
*   + W +   +   + *
* +   +   +   + B *
* B + B + B +   + *
* + B + B + B + B *
* B + B + B + B + *
* * * * * * * * * *

But to make life easier, you can also use something like gametable in two player mode to record the moves; here's how the board would look like:

Playing checkers against CHECKE. Source: Rupert Lane. License: CC0.

If you type a nonsensical move it will print:

3*    99 66
SORRY CHARLIE!

I won't give a full account of the game, but by move 44 the program announced:

THE PDP-10 EXPECTS TO WIN IN 11 MOVES.
44      26-22     15171.   11 MOVE WIN.   1017

but my downfall occurred just three moves later. Here, FORCED is printed because by the game's rules if it can take an opposing piece it must.

45*    10 15
46      17-1          3.       FORCED        0
47*    15 18


        26 JUL 74


1*

The original IBM 7090 code is not publicly available as far as I am aware.

Samuel's directories on the WAITS system can be found on saildart.org. It's hard to tell what code matching the CHECKE binary from 1972, but CKP2.MAC[2,ALS] is the oldest file, dating back to 1971. Further enhancements - up to 1977 - can be found in [CH2,ALS] and sample game data in [CH3,ALS], [CH4,ALS] and [3,ALS].

The code shows evidence of it being a port of the IBM 7090 version, with translations into subroutines of some instruction where there was not an equivalent on the PDP-10 , eg CAQ.

The VideoBrain development directory is called F8. This includes several versions of the checkers source code along with a cross-assembler in Fortran, presumably written by Fairchild (who made the CPU in the VideoBrain). It's not clear how much was written by Samuel, and how much by his collaborators at VideoBrain. There is also some correspondence between Samuel and the makers of the Videobrain, with Samuel suggesting other games that could be produced and complaints about the unreliability pf the development hardware.

IBM's article The games that helped AI evolve is a first introduction to Samuel's work at the company on checkers and also discusses Tesauro's TD-Gammon program.

Samuel's original July 1959 paper, "Some Studies in Machine Learning Using the Game of Checkers", in IBM Journal of Research and Development, vol. 3, no. 3, pp. 210-229 is available for download at IEEExplore. The IEEE also has a memorial on Samuel's work.

Richard Sutton and Andrew Barto's book Reinforcement Learning: An Introduction is available in full online and has a case study on Samuel's checkers.

MAME has an emulator for the VideoBrain and copies of the game's cartridge ROM can be found online.

Another early checkers program was written by Christopher Strachey for the Ferranti Mark 1 in the early 1950s; there is an emulator that can run this.

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.

If you are looking to download files from the existing disk image, for example the manual for the COPY command in COPY.RPH[S,DOC], the easiest way is to get these from saildart.org. Simply prepend https://www.saildart.org/ to the file you want to get and open it in a browser or download via wget or curl. Note that the file you get is in HTML, so characters like < will be encoded as <.

If the file you want to get is a binary file rather than a text file, saildart will automatically output it in octal format. Each line of the file will be a 36-bit word encoded as octal digits.

To force a text file to be encoded as binary, add _octal to the end of the URL, eg https://www.saildart.org/COPY.RPH[S,DOC]_octal.

The file you get will be the most recent version in the DART archive. Sometimes you want an earlier version, eg to ensure you are viewing a manual from 1974. To check this, open the directory listing for the file you want, eg https://www.saildart.org/[S,DOC]. Here you can see there are several different versions, from 1972 to 1976:

File detector on saildart.org. Source: Rupert Lane. License: CC0.

Note the version number after the directory name, so here I've selected version 8 which is dated 1974-07-24. To get this file directly you would go to https://www.saildart.org/COPY.RPH[S,DOC]8.

There is one quirk - for the latest version of the file you should not provide the version number, so if you wanted version 11 from 1976 you should request https://www.saildart.org/COPY.RPH[S,DOC]. If you try to fetch https://www.saildart.org/COPY.RPH[S,DOC]11 it will fail.

Using the virtual line printer is a good way to get text files - either system files or your own files - out of the system.

First you need to attach a text file to the virtual printer so you can view the output on your PC. For the quckstart this is done for you already and the file used will be printer.txt. Otherwise you will need to press Control-E in the simh window and enter commands:

sim> at lpt -n printer.txt
%SIM-INFO: LPT: creating new file: printer.txt
sim> cont

The -n switch creates a new printer text file each time simh starts. If you want to keep previous output and append to the file, change this to -a.

Then in WAITS, use the LIST command to send files to the printer, eg

.list hworld.f4

This takes wildcards like other COPY-class commands.

If you then look at your printer file on your PC you will see the file (it may take several seconds) with a header like this:

26-JUL-74    0955            HWORLD.F4  1,REL            PAGE 1-1

LIST sends files directly to the printer. On the real system you would normally use the spooler by typing PRINT instead, but this is not running on the emulated system.

If you want to extract several files from WAITS, here is a method using emulated tapes and the WAITS DART program - the same program that produced the backup tapes on saildart.org.

You will first need to get the dart utility from Lars Brinkhoff's set of PDP-10 tools:

$ git clone https://github.com/larsbrinkhoff/pdp10-its-disassembler/
$ cd pdp10-its-disassembler/
$ make dart

Copy the dart executable file to somewhere on your PATH.

Next, on the simh console, we will create a blank tape file on your PC backup.tap and attach it to the emulated tape drive MTA0.

Press Control-E to enter simh command mode and then type the following. Note that MTC0 on simh maps to MTA0 on WAITS.

sim> at mtc0 backup.tap
%SIM-INFO: MTC0: creating new file
%SIM-INFO: MTC0: Tape Image 'backup.tap' scanned as SIMH format
sim> cont

Switch to your WAITS login and run R DART, then at the * prompt type dump and the files you want to save. Type exit when done.

.r dart

*dump *.f4
HWORLD F4      1,REL
SECOND F4      1,REL
*exit

EXIT
^C
.

On your host PC, use the dart command you compiled earlier with the -tf option to view what's on the tape.

$ dart -tf backup.tap 

DART VERSION 5  TAPE HEADER
RECORDED 1974-07-26 10:10,  BY [  1,REL] USER CLASS
   DSK:    HWORLD.F4 [  1,REL]        256   1974-07-26 19:02
   DSK:    SECOND.F4 [  1,REL]          3   1974-07-26 19:52
END OF TAPE (NO TRAILER)

Use the -xf option to extract files. It will create directories in reverse order to store the files, ie HWORLD.F4[1,REL] will go to rel/1/hworld.f4.

$ dart -xf backup.tap
$ ls rel/1/
hworld.f4  second.f4

To upload files from your PC to WAITS, we can use the same technique bur in reverse. First, use dart with the -cf option to create a upload tape file. Here we create the tape upload.tap containing two Lisp files one.lsp and two.lsp intended for [1,REL] by placing them in the reverse directory structure shown above.

$ ls rel/1/
one.lsp  two.lsp
$ dart -cf upload.tap rel/1/*

Switch back to the simh console, press Control-E and attach the new file.

sim> at mtc0 upload.tap
%SIM-INFO: MTC0: Tape Image 'upload.tap' scanned as SIMH format
sim> cont

Go to your WAITS login and use DART with the RESTORE command to get all the files in the archive. You can specify which files to restore but here we choose to restore everything:

.r dart

*restore *.*[*,*] _ *.*[*,*]
DART VERSION 5  TAPE HEADER
RECORDED  11:02 20-Jul-126,  BY [DMP,SYS] USER CLASS
ONE    LSP     1,REL
TWO    LSP     1,REL
DART VERSION 5  TAPE TRAILER
RECORDED  11:02 20-Jul-126,  BY [DMP,SYS] USER CLASS
MT READ ERROR. MT STATUS = 200610
MT READ ERROR. MT STATUS = 200610
...

When it reaches the end of the tape it will repeatedly say MT READ ERROR. MT STATUS = 200610; just press Control-C to quit and then verify your files have been transferred.

.dir *.lsp

26-JUL-74  1104
FILNAM  EXT   SIZE LAST WRITTEN

   [1,REL]
ONE     LSP      2  31-JUN-71
TWO     LSP      2  31-JUN-71
        TOTAL=     4

The WAITS DART tape backup command is described in DART.REG[UP,DOC].

Lars Brinkhoff is working on getting simh and the WAITS image to provide Arpanet functionality via emulation at sailing-on-arpanet; once this is fully running it may be possible to upload and download files via ftp.

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.

SOS - Son of Stopgap - was developed at Stanford and is a basic line orientated editor that can be run from any terminal type.

You can invoke it with CREATE file and it will create a file, start SOS and let you enter text immediately, or EDIT file to edit an existing file. The * prompt allows you to enter single letter commands: in the above we see P to print the file and E to exit. Each line has a line number prepended to it and you can give line numbers as arguments to commands, eg P 100,200.

The version we saw on TOPS-10 is similar to what we have running on WAITS, so see my earlier post for more information. There are a couple of differences:

• files are always saved with line numbers; there is no equivalent of the ES command
• on display terminals only, the Z command will allow you to edit a line with the standard line editing commands like Control-Space to move the cursor forwards and Control-Backspace to move it back. See the blog entry on terminals for more details.

Finally, on the console, SOS will represent non-standard characters that are in the Stanford ASCII character set by preceding each with the escape character ?, for example alpha α is shown as ?". This includes lower case letters, eg lower case a is ?A. A plain question mark is ??. See the SOS manual section 1.4 for details.

TECO - Text Editor and Corrector - is DEC's powerful but somewhat cryptic character orientated editor. Operating this is the same as on TOPS-10, so see my post there for more details. Type MAKE file to create a file and start editing it, type TECO file to edit an existing file.

A display editor allows full use of the screen and keyboard of a display terminal like the III or DD, so you can navigate around the file and make changes quickly. This is similar in concept to editors you use today like Emacs or Vim, but the execution, and especially the keystrokes used, are quite different. The WAITS display editors predate the above editors and the IBM PC so there was no convention for it to follow.

Stanford created the TV editor initially in the late 1960s, and then rewrote it as the E editor; the functionality is much the same.

However, at present neither editor works completely on simh. E will crash after a few commands, and both E and TV don't properly display the arrow that shows what line you are on, so it's hard to make changes to a file. Neither editor works on the saildart.otg emulator.

But to give a taste of how these worked, I'll show how to create, view, navigate and edit files using TV.

   α     means hold the "CONTROL" key down while typing a character.
   β     means hold the "META" key down while typing a character.
   αβ    means hold both "CONTROL" and "META" keys down while typing.
   ⊗     means use either α or αβ with the next character.

As of 1974, SOS is documented in SOS.LES and TV in TVED.DCS. See E.ALS for an idea of how much was available in the E editor as of 1989.

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.

The origins of SPELL are in work Les Earnest did at MIT to recognise cursive handwriting in the late 1960s/early 1960s. He put together a dictionary of around 10,000 English words (from ABANDON to ZOOLOGICAL) and wrote a subroutine in assembly to match against handwritten words, producing an output file of words not recognised. Les moved to SAIL in 1965 and took his dictionary with him (pictured below, on paper tape). In 1967 this was used by a grad student to write a program in LISP that would match words in a text file and print out anything it did not recognise.

10,000 words on paper tape. Source: Les Earnest via archive.org. License: CC BY-NC-ND 3.0

Finally, in 1971. Ralph Gorin (the REG whose login we have been using to access our emulated WAITS instance) wrote SPELL, using the same dictionary. This took a text file - and an optional user dictionary - as input, checked the words contained and if it did not recognise a word, offer the user several alternatives such as select a candidate replacement from the dictionary, ignore the word, add to personal dictionary etc. This became popular at SAIL and was also adopted by Tenex and other PDP-10 sites. Later versions could understand text files using document preparation languages like PUB and TeX.

Type R SPELL to start the program. On display terminals it will present a multi-pane-of-glass view like the above, but it also supports an interactive teletype session with * as the prompt.

First it asks if you want a personal directory and any switches to support dictionary maintenance. It will then ask for the input and output files (it can't edit a file in place). Here we'll use a file called blog.in that contains a single sentence "I make mnay mistakes.".

.r spell
Do you want to augment the dictionary? n
Mode switches (zero or more of T,Q,N,U,P,A, or ?):  
Name of the file to check and correct: blog.in
File name for correction output: blog.out
File for exceptions: 
No exception file.

When it detects a spelling mistake it will prompt you for what to do next

working...
Page 1:1
I make mnay mistakes.
mnay
Type S,A,I,R,X,D,W,L or ?

If you've ever run ispell on Unix (or its Emacs interface) the commands will look remarkably similar - a to accept, i to insert into personal directory, r to retype the word by hand etc. In fact ispell traces its origins back to SPELL, starting with a revised version on the PDP-10 and eventually being ported to C and Unix.

On the display terminal you can see a list of candidate words on the right which you can choose from. On teletypes, you need to press s and then use Return to see the options.

*s
Type C,^,<altmode>,<cr> or ?
MANY
*
MAY
*
Those are all the choices.  Type S,A,I,R,X,D,W,L or ?
*s
Type C,^,<altmode>,<cr> or ?
MANY
*c
Finished.

Before it exits it will prompt for some options to continue checking other files or manage core files. But the normal response is e to save the output file and exit.

Type E,S,C,A,D,I, or ? e

EXIT
^C

The 1974 source code for SPELL is on the WAITS disk as SPELL[S,REG] and the master dictionary in SLOVAR[S,REG] (unfortunately the [S,REG] directory is not accessible on saildart.org). The source file has around 5600 lines, 4700 of which are FAIL assembly source code and the rest is the manual. The header reads.

	TITLE	SPELL	I HAVE YOU UNDER MY SPELL
;		SPELLING CHECK  & CORRECTION.
;		R. E. Gorin 20 February, 1971
;		Revised July 23, 1972 III displays
;		TENEX version 1/12/74 Wiiliam W. Plummer, mod REG 11/19/74
;		Additional features, October 1974, Jerry Wolf, mod REG 11/23/74

Internally the program uses a form of hash coding, where words with the same first two characters and length are stored in a list so candidate replacements can be found quickly.

The program detects four types of mistakes; from the manual:

1. one wrong letter.
2. one missing letter.
3. one extra letter.
4. two transposed letters.

The executable program is built by assembling the code, starting it and giving it a master dictionary file name. It then builds its hash tables and stops, at which point the core image is saved for future use. This was a common technique for machines of this area. as the resulting core file starts up quickly as the master dictionary read and parse does not need to take place. The downside is that the master dictionary cannot be changed without rebuilding the program.

SPELL is documented in SPELL.REG[UP,DOC]

Here's a video of Ralph Gorin accepting an award for his work on SPELL at a SAIL reunion in 2009.

See Les Earnest's paper on the first spell checker at archive.org.

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.

In the previous post we talked about PPNs like [1,REG]; here REG is the ID that identifies which user you are.

To create a new user ID, simply choose a 3 letter ID and log in as that. This must be on a device internal to SAIL, ie the console or display terminal, not via the external communication lines that are modelled by a telnet connection on simh.

Here I choose REL as an ID and log on. It asks me if I am sure, as this is a new ID, and if I type Y I am logged in and can run programs or create files.

.l 1,rel
JOB 1    Stanford 6.17/K 08-16-74
Are you sure? y
Friday  26-JUL-74       0945
.

If I log out with an empty directory, it will be removed.

.k
Your empty file directory has been deleted.

But it is recreated the next time I log in.

If you had logged in as 1, FOO, you would get this message when you logged out:

You are not an authorized user. Your files have been deleted.

This turns out to be a simple check in the LOGOUT routine - if your user ID is one of FOO, BAR, BAZ, ABC, 100 it will say you are unauthorised, probably because these are common IDs used for testing.

You will note that no password was asked for at any stage. You can set a password by replacing the . with a % at the login stage, eg L 1%REL. You get the option to only ask for a password if you are logging in remotely so you don't need to supply it when logging in via the console or display terminals.

The password is set at the PPN level on the user file directory entry, so you could have a different password for say 1,REL and 2,REL. According to the UUO (system calls) manual it is stored in plain text, case insensitive with a maximum length of 6 characters.

Files and directories have a 3 octal digit protection code.

The default protection is 000, so anyone can do anything.

To set protection on files, you need to use COPY with the /PROTECTION flag to create a new file with the desired level, eg

.copy /protection=006 foo2 ← foo1

would create FOO2 from FOO1 but set protection so guest users can't access it at all.

Directory protections can only be set by logging in with the % delimiter

WAITS is quite similar to TOPS-10 here so reading the Jobs on TOPS-10 post will give more details. But in brief:

When you log in to WAITS, it gives you a job number which lasts throughout your session. Some simple commands (like DAYTIME) you type are built into the monitor. Others need to be loaded into memory from core files, which have the extension .DMP on WAITS.

If you have a core file FOO.DMP in your directory you can invoke it with RUN FOO. Common programs are stored in the SYS: area, which is equivalent to [1,2], and programs here can be run using R. RUN can also take a file name and directory, so R LISP is the same as RUN LISP.DMP[1,2].

Some common programs, like COPY, are recognised by the monitor but behind the scenes it will invoke RUN on the right core file.

You can create another job by logging in a second terminal. But you can also DETACH from a job, which will suspend it and log you out, and then log in elsewhere and resume execution using ATTACH. Jobs can also run in the background if they do not need interact with the user's console.

All that is pretty much the same as TOPS-10. WAITS adds some more conveniences. FORK works like DETACH, but rather than logging you out will create a new job as your current ID. KILL can be used to kill a job owned by you.

WAITS replaces TOPS-10's SYSTAT with WHO, along with the "who line" we saw earlier on interactive terminals.

TOPS-10 had a fairly sophisticated batch processing system, where jobs could be submitted from the terminal or via cards, and queues of jobs could be maintained and run in the background.

WAITS chose instead for a simple facility to run from the terminal, similar to a shell script file on a modern system. The concept is you create a file with a set of commands or data to input to those commands. The end of each line must be denoted by a ↔ rather then Return. There are a number of other metacharacters to allow you to enter the special keys on the Stanford keyboard, eg ≠ will emit an Altmode key

You run the file with DO and it basically pastes data it into your keyboard buffer as if you'd typed it directly, expanding any metachracters.

There is provision for variables via the question mark and a single letter, eg ?A. The first time this is seen it will prompt for input and store that in variable A; from then on using ?A will expand it to the value you entered.

There is no looping or branching available, however.

As an example, if you have the file foo.do:

hello↔dir [?D,DOC]↔

and type DO FOO.DO it will run the hello command, prompt you for a value for D then do a directory listing of that area under DOC.

See the Monitor Command Manual for more details on these topics.

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.