An Interview with Charles Wetherell
and Tom Buckholtz
(September 14, 1999)
CW = Charles Wetherell
TJB = Thomas J. ("Tom")
GAM = George Michael
GAM: We are trying a new approach for remembering things that happened
at Livermore. Today we will be talking with Charles Wetherell and Tom Buckholtz
who are, together, going to reminisce about their development of a very
interesting piece of software that was first used on the SIGMA 7 system which
was set up at Livermore for graphics research. Along the way, you guys, just try
to remember to say where you came from, when did you get to the Lab, and what
was your interest there. Are you a physicist, or a programmer, or a
mathematician, and so on?
TJB: For me, this history starts in Palos Verdes, the Southern
California peninsula where I grew up, with two people - Mark Dawson and Kelly
Booth - who lived there and were friends of mine.
Mark moved to Palos Verdes in 1960. We became friends and were classmates for
the three years until we graduated from Palos Verdes High School in 1963 .
During that time, he introduced me to Kriegspiel, a game played in the Southern
California aerospace community. Other players I remember include Mark's father
Reed, who had worked as a mathematician for the National Security Agency and was
then employed by Control Data Corporation, and some of my contemporaries
including Kelly Booth.
I played Kriegspiel during those three years and, apparently, later
introduced it at the California Institute of Technology from which I graduated
as a math major in 1967. I recall playing the game occasionally at Caltech and
at some of the aerospace companies with which I had summer jobs from 1963
through 1967. Those employers were Douglas Aircraft ,
Hughes Aircraft ,
and A. C. Electronics Division of General Motors . I
probably introduced the game to my groups at Hughes and GM.
CW: I've just finished reading the John Nash biography  and Kriegspiel was very popular in the late 40's to very early 50's in the
Princeton math room. Then many Princeton mathematicians, particularly the game
theorists, immigrated to RAND.
TJB: Is that how Kriegspiel arrived in Southern California?
CW: Well, I have a strong suspicion that that's how it got to southern
California and to the high school students in Palos Verdes. Obviously we're
pretty close, at least physically.
TJB: Mark Dawson's father  and some of his colleagues at Control Data and elsewhere played this game,
sometimes at lunch and sometimes during evenings. Kriegspiel was a good game for
a lunch break. Three people could play a round robin - three games - with each
person playing once against each of the other two and serving once as referee.
Games progressed adequately quickly, if the people did not take things too
Another thread that I should describe features my learning to program
computers. When I was in the seventh grade, at Malaga Cove School  in
my hometown of Palos Verdes Estates, my father Joel ("Joe") Buckholtz formed the
Palos Verdes Peninsula Science Club [8, 9, 10].
Before I completed high school I had learned some electronics ,
ham radio, mathematics, physics,  and computer programming .
During my eleventh grade (1961-1962), Jim Ziegler, National Cash Register's
manager for its El Segundo plant, served as the Club's first counselor in
computing. Three other students and I spent Friday evenings programming an NCR
The NCR 304 was considered a medium scale business computer. At that time, it
came with no software. We programmed in absolute code .
During the summer of 1962, I took a course at UCLA in programming IBM 7090s
using FAP, Fortran Assembly Program. During the twelfth grade, Carl Balke of
Computer Sciences Corporation  served as a Science Club counselor and I learned to program a Univac computer,
possibly an 1106. I do not recall the programming language.
Based on my summer jobs starting in 1963, computing changed for me from a
hobby to a tool .
During the three summers, 1968 to 1970, between my three and three-quarters
years at the University of California, Berkeley, earning my PhD in physics ,
I worked as a Summer Research Appointee in Q Division  at the Livermore Laboratory .
My first day of Lab employment included a "welcome aboard" orientation. While
I waited for that meeting to begin, Kelly Booth entered the room. He had come
through the Palos Verdes Schools, one year behind me, and became the fourth
Palos Verdes person  in four years to enter Caltech as a freshman .
He was about to continue to follow me for one more step, having been admitted to
So, after a year apart, we, in effect, got reacquainted.
During the summer of 1968 Kelly introduced me to you, George Michael ,
and the two of you introduced me to Charles Wetherell. All three of you worked
in Computations Division.
I had had a dream to develop a computerized Kriegspiel referee. When I
learned that Kelly and Charles were working with a computer that was destined to
support at least three graphics terminals, I proposed that we develop such a
Do you think we should describe the game now, describe it later, or just cite
the relevant papers ?
GAM: As you wish!
CW: Perhaps I can answer the personal history question first. I didn't
know any of these people before I came to LLL for the first time. I went to
Harvard as a mathematician but came out a computer type and had gone on to
Cornell as a graduate student. A friend from Harvard called me up and said,
"Gee, if you want a summer job, there are these great jobs at Livermore". It was
in the period during which Livermore was hiring interns by the bushel basket for
the summer. I had missed the application deadline, but I sent one anyway. After
a rather strange telephone interview with Lowell Wood, I got an offer, packed up
the car, and drove across country to a new adventure.
And so I came out to Livermore in the summer of 1968 for internship, met
Kelly during that summer, and was assigned to work on the Gordo  system, which was then in its beginnings. I don't recall that it was very useful
system then because the time sharing software wasn't fully working yet. I went
back to grad school, the Vietnam draft became severe, and I came back as a
summer intern in 1969 and converted to a full time position in Computations
which I held at Livermore until 1972. During that time, I was assigned a number
of projects, but eventually got back on the Gordo Project. Kelly was also there
and during that time I met Tom. I was doing a great deal of various kinds of
systems programming on the Gordo system and I've always been interested in the
issue of computer games and games in general. So when Tom and Kelly talked about
doing this it was easy to be sucked right into the project. In fact, I think I
was the one that found the previous paper on Kriegspiel that we cite in our
TJB: While we are on the subject of papers, permit me to note that
Charles found the references and led the way in developing the two papers, which
we published in The Computer Journal .
CW: So that's how I got into this.
GAM: Great, so at some point the three of you just decided let's do
this on the Sigma-7 system? How did you do it?
TJB: I treated this as an "off hours" project. During the summer of
1968, I produced a working referee that I tested and verified using the
operator's console which was a Teletype ASR-35 .
At the time, I was living in an apartment in Berkeley .
From one Friday evening through the end of that weekend, I designed and coded on
paper a Kriegspiel referee. My only other activities for that weekend were
sleeping, exercising, and eating. The result was approximately 500 lines of
FORTRAN code. I believe that shortly thereafter I spent a week in Livermore and
Pleasanton sleeping in the detached room behind Kelly's home on Vineyard Road.
During the evenings I keypunched the program and tested the code.
The code compiled successfully on the first try. I used the operator's
console to enter moves for a brief game of Kriegspiel. The referee worked well
including detecting and reporting some illegal moves. On the fourth move, I had
White checkmate Black. The program reported the check but not the checkmate. I
had discovered a programming error. The program assumed that Black could escape
check by having its king capture its own queen. There were a few other minor
errors which I found and corrected.
Did we do anything else that first summer?
CW: I don't recall much of that except helping Tom maybe get on and
off the machine and showing him how to use the basic system. The machine was
pretty primitive at that time. The Gordo OS wasn't complete yet. To do
interesting graphics things with FORTRAN, you had to drive the graphics
workstations through the operator's console. I did a project around that time
which involved drawing pretty pictures, but to do it I had to sit at the
operator's console and run the program from the operator's console although the
graphics would come out on the graphics consoles. We didn't have the timesharing
system hooked up well enough so we could use those as full work stations yet. So
outside of seeing Tom when I got there in the morning there wasn't much
interaction at that point. We certainly weren't at the stage of writing the
GAM: Did you get anyone else to, shall we say, battle test it?
CW: No, not at that stage. Because there wasn't anything to battle
test in some sense. At that point, what Tom has described is really a chess
playing referee, because chess and Kriegspiel are so close together that the
Kriegspiel part only comes together when you can hide one player from the other.
At the stage when you are driving from the operator's console you really
couldn't do that. So you had to use your imagination to think it was Kriegspiel
at that stage.
TJB: I believe that, after each successful move, the computer printed
the two players' positions via the operator's console. The printout showed both
the official White and Black pieces, as digits or characters (e.g., "K" for
white's king or "k" for Black's king) on one board. Although all the rules of
Kriegspiel that were be included in later versions were present, the program
lacked the abilities to show White's and Black's boards separately and to track
each players' use of opposing pieces (for example, White's positioning of black
pieces on White's board).
CW: In any case, Tom should continue the narrative because at that
point Tom had a code for the logic of the referee function, but we didn't have
anything to use it on yet.
TJB: Actually, my part of the story can be told rather quickly at this
point and you, Charles, can fill in considerable information about the overall
As far as I recall, no progress was made between summers. Eventually -
certainly by the summer of 1970 - we had a complete system. Three graphics
terminals were used. For each game, the person or persons at one terminal could
play against those at another terminal, while the "kibitzers" at the third
terminal saw a chess board with the official White and Black pieces but not the
unofficial pieces (White's placement of black chessmen on White's screen and
Black's placement of white pieces on Black's screen).
One or only a very few games were ever played using the system. An actual
game played on the system is reported in one of the papers we published in The
CW: There were certainly many test efforts, but only a few complete
TJB: Let me say a little more. Then Charles and Kelly can fill in the
rest, because you know best what you did. In particular, let me discuss the
I was one of five or six people who entered graduate school in September 1967
in the Physics Department at Berkeley after graduating that June from Caltech [30, 31].
At least three of these people worked at the Lab .
We drafted Doug Eardley to play White for this game. I am not certain whether
he had played Kriegspiel before. I assisted him. According to the transcript of
that game ,
Black's first name is "David." David's last name contains four or five letters,
the first four of which are "Book."
In any event, the game turned out to be suitable for publishing as part of
the 1972 The Computer Journal article. Black moved his king into the middle of
the board. I recall that, on move 9, Doug and I had enough information to
believe we had a choice between capturing Black's queen and checkmating Black.
CW: Yes, it's very hard to read in the paper because of a silly
mistake the publishers made, but in move 9 the comment is "White thinks I could
possibly take his queen, but I think there's a mate". Then White moved and made
TJB: A photograph of a computer screen, reproduced in the article,
shows the final position. When you, Charles, arranged for the cameraman, you
replayed the game based on the printout from the actual game.
It was wonderful that this game had such a good ending and was short. The
game definitely was suitable for publication in that paper. We owe much to David
for moving his king toward the middle of the board.
CW: I also remember at the time that it struck us all that this was a
particularly fortuitous game and it was nice to be able to publish it as is, no
editing of the game. I think that two or three other games were played, but in
fact the system was still so clunky in some ways, partly because of the early
stage of the hardware and it was an awkward game to play. We must remember the
hardware on which the program ran had an instruction cycle rate of 1.2
microseconds per instruction and a memory rate of 0.85 microseconds per word
fetch. We are sitting in a room that has an Apple IMac in it that has roughly
300 to 400 times the speed of the Sigma-7 instruction cycle and certainly 50
times the speed on the memory cycle.
GAM: Well, it's been thirty years Charles.
CW: I don't disagree that it was a long time ago, but still it made
actual play awkward. It was a calligraphic display with light pens rather than a
pixel- based display with mice.
TJB: Much could be accomplished using just a light pen. To move, a
player poked "Move", a chessman, the destination square, and then "Complete" .
I thought that was reasonably easy.
CW: If you look at the pictures you'll see there are little white dots
in the centers of the squares and the little white dots are where you had to
poke the light pen to tell which square to move to.
TJB: Yes. I am not certain that those pokes were much more difficult
to accomplish than are specifying a point or selecting a small icon using a
touch-pad mouse with some of today's laptops .
CW: As I recall, the hardware was slow.
TJB: Perhaps. I do not recall that. Players were happy.
CW: Tom hasn't actually told all of his part of the narrative because
for publication, we published the director in two papers. One paper was called
the director of Kriegspiel and it covers the program which manages the whole
process, so one should think of it like a chess tournament director who manages
the players and the play of the game, not just the individual moves. The other
paper was published as an algorithm and it's the referee, the part of the
program that actually knows the rules. Tom mostly worked on that. Tom had
written the FORTRAN. To prepare it for publication, he and I spent something
like a week of nights spread over two or three weeks putting comments in, very
carefully aligning the code, and on. We would have liked to use an modern text
editor, but we did all our work on paper and coding sheets and then keypunched
We also simplified the code in the sense that any code anybody has ever
written always has things that in retrospect you wish you hadn't done. We spent
a lot of time organizing the logic, time where I primarily was editor and critic
for Tom and Tom provided the entire original program and most of the thinking
about it. It's interesting to look at it now. We also did a little formatting
and structuring. I realized the other day that it might be interesting to go
back as an exercise and both understand how good we were at that in 1969 and
also rewrite it in a more modern language and see if it really needed a lot of
The one thing I noticed we did when I was looking at it was we put all the
argument passage in equivalence blocks because passing many arguments was (a)
not the style in FORTRAN and (b) very expensive. But nowadays we would probably
encapsulate some of this stuff in objects and it would work better. But actually
it's a fairly tight routine and I've looked at a lot of the games literature and
I've never seen a chess referee that catches all the rules that's any better
GAM: That would be an interesting to invent something like that, I'll
grant you that.
CW: Maybe there's no interest in such an algorithm. Apparently
everybody who writes chess programs always writes their own and my suspicion is
there are some that don't get all the rules right. I think Tom did get all the
rules right actually.
So the other part of the story is that we had to have a director and the
director is a family of programs, actually more than one, which had to be used
to run this. If two players wanted to sit down, how would they actually be able
to play the game.? The director had to do things like put boards up on the
screen, record the moves, transmit the moves to the other player, transmit the
move to the referee for legality checking, and we decided in our humorous way
that there ought to be a kibitzer as well. So there was a third console active
where somebody could sit and watch both sides of the game and who, we presume,
would want to make sarcastic comments to both of the players.
We also put in a facility with which you could make comments directly to the
file, which nobody else could see, so in the record of the game you could record
your thinking about what you were doing without the other player knowing and it
would be there for later. I think that was my idea. DeGroot had published a book
about the psychology of chess players and I thought we might have a publication
about the psychology of Kriegspiel players. Unfortunately, there was only one
game published so it would have been a very short book. But that was the idea.
TJB: Is ours the only published Kriegspiel game?
CW: That's an interesting question, I actually have been reading
several places lately about Kriegspiel and I don't recall having seen another
game right off hand.
TJB: Is Kriegspiel still played?
CW: Oh, Kriegspiel is still played. It's still an interesting game .
TJB: No one of the three of us had reason to continue to use the
automated referee we had built.
CW: There was no community of Kriegspiel players there at the Lab. It
was always available, I think we would occasionally demo it to people.
GAM: Well, let's just jog then a little bit here. I think you
speculated once before about the other uses of this technology.
CW: What I'm seeing when I go back and reread the paper is we
cooperating sequential processes although I'm not sure that any of us knew them
formally by that name at the time. I know we knew about semaphores because we
explicitly coded semaphores in the communication mechanism. We also used the
term "monitor" in there but its not in the sense of C. A. R. Hoare monitors. But
we very definitely thought of this as a network of cooperating programs that
signaled each other through message passing bumpers and semaphores. This is a
very early instance of a network of that sort and it was in principle
indefinitely expandable. Although in practice, because we had to write almost
entirely in FORTRAN for convenience, it was difficult to code and the
limitations of FORTRAN were such that it was not a particularly nice
implementation in terms of its character.
GAM: I think it is not correct to call it early FORTRAN. By 1969,
FORTRAN had been in use for about 13 years. It's probably more accurate to call
it Primitive FORTRAN.
CW: Well, it was the FORTRAN on that system. We intentionally
restricted ourselves to what is now called FORTRAN 66. We might have
inadvertently used some extensions, but that was not our intention.
GAM: Was it the Digitech FORTRAN?
CW: I think that the Sigma-7 compiler may have been the Digitech
CW: FORTRAN in general is not the language one would choose to do this
kind of implementation, even nowadays. So, for example, message-passing buffers
were basically in fixed locations. Whereas they ought to be in allocated
locations in the modern terms so you could allocate as many of them as you
needed. That, however, I see as unessential to the logic of the problem. We had
the logic of a cooperating network of programs. Indeed, you actually started a
master program which, in turn, started the slave programs to run the thing and
then put itself away in the background and, sort of like a spider on its web,
managed the network from the background.
TJB: As I mentioned before you (George) turned on the tape recorder, I
recommend you discuss the overall impact of the Kriegspiel project with Kelly. A
few years ago, when I was discussing the project with Kelly, he suggested that
what Charles and he learned from this project became the key ingredients for
many, if not most, of the war games that were developed at Livermore.
CW: I should say Kelly and I did all of the director, Tom didn't do
much with the director outside of maybe sit there and throw stones at us when it
didn't work. Kelly did most of the implementation of the cooperating processes
and I did most of the implementation of the game board, the user interface, and
connecting to the referee. I also did most of the testing. Then Kelly and I
probably shared equally in the logic and design of the message passage system
and whether particular functionality was going to belong to a user interface, to
the message passing system, or to the central director master program. We
thought explicitly about things like race conditions and so on. We were aware of
that kind of logic. I recall very clearly that we solved some race condition
problems. I don't know that we solved them all and since the code has long since
been lost, as far as I know, it would be unlikely we'd be able to find out. But
we definitely thought about all the problems that people think about in modern
multi-processing. The other interesting thing about this was these were
independent programs. Although they ran on one machine, there was no logical
reason they couldn't have been run across a network. They didn't, but we were
actually treating them as if they had.
GAM: You can assume certain scenarios in which the behavior of the
referee will reveal more to the players than it should. So how did you
communicate to the referee a possible move? Just let him see it or tell him
about it or what?
TJB: The referee was designed not to provide more information than the
conventions of Kriegspiel dictated. And, it was a program, not a person. So, it
did not do something unintended.
GAM: I understand that, but you've still got to indicate your proposed
TJB: A player specified an intended move through light pen pokes.
Charles' and Kelly's code conveyed that information to the coding that served as
the referee. Neither the other player nor the kibitzer knew, at this instant,
that a move had been attempted. If the referee decided that the move was
acceptable within the rules of chess, the kibitzer would see an updated board
and the opposing player would receive information dictated by the conventions of
Kriegspiel. All this is true until the end of the game, when anyone could
request and receive a complete printout of all moves attempted.
GAM: And what if it comes back and says "That's illegal?"
CW: This is probably the appropriate time to define the essential
features of the game Kriegspiel.
TJB: You are right. We have discussed some aspects so far. You,
Charles, did a wonderful job on this when you wrote the papers. That explanation
is doubtless more concise that what I say here.
A Kriegspiel game features two people playing chess against each other. All
the rules of chess (with the exception of conventions about forced draws) apply,
but each player has his own board and cannot see the opponent's position on the
Indeed, a player can place chessmen of the opponent's color, coins, or other
objects on the board to indicate the player's guesses about the opponent's
position. Such memory aids are not part of the official game.
With our Kriegspiel monitor, a player was allowed to put any number of
opponent's pieces of any type on his own board, subject to two limitations. One
could not put an opponent's man on a square occupied by one's own chessman. One
could not put more than one opponent's piece on any one square. Also, I should
note that we did not provide an analog of "coins."
As I had seen the game played, only two boards were used, with the White
pieces being official on one board and the Black pieces on the other. Usually,
the players sat facing each other with their boards between them and an
adequately tall, wide, and opaque "divider" standing between the two boards .
The referee positioned himself at one end of the divider and mentally
superimposed the official positions of the two players. (I recall rumors that
some referees used third boards, maintaining the actual chess positions thereon
as aids to themselves.)
I was proficient at refereeing two games simultaneously. This required four
chess boards and one long divider. I stood at one end of the divider. The two
players nearest me faced and played against each other. The other two players
faced and played against each other. My main challenge was to maintain a normal
degree of referee-generated "banter" and convey the required information without
slowing down either the "near board" or "far board" game. Accuracy in refereeing
did not prove a challenge.
Because all the rules of chess (except conventions about forced draws) apply,
the two opponents know each others starting positions. Such "complete knowledge"
usually dissipates starting with the first or second pair of moves.
Let's say it is now White's turn to move. White attempts a move.
If the move is legal, based on the rules of chess as applied to the situation
defined by White's chessmen on White's board and Black's chessmen on Black's
board, the moved man remains at its destination square on White's board. The
referee removes from Black's board any pawn or piece that was captured (without
showing that chessman to White), may make some announcements I will discuss
later, and announces that it is now Black's move.
Instead, had the move proven illegal for reasons White could not have known,
the referee would have announced "No" to both players, White returns the
chessman to the square on which it resided just prior to the attempted move.
White has the opportunity and obligation (unless, for example, White chooses to
resign) to attempt another move.
Typical reasons for receiving a "No" include moving through an opponent's
chessman or moving into check.
So as to be fair to Black, the referee has the discretion of announcing a
different type of "No," sometimes stated as "Heck-No," if White attempts an
obviously illegal move. Referees use the "alternative No" in situations such as
White's attempting to move a bishop like a knight, making a move that cannot
possibly (under any possible configuration of Black pieces) get White out of a
known check, or repeating a "No" move on the same turn. These "alternative no's"
were included in our automated Kriegspiel monitor.
More subtle forms of potential Heck-No's exist. This type of announcement can
be used for attempted moves that a player could have deduced, from his knowledge
of the opponent's position, to be illegal. Our automated Kriegspiel monitor was
not programmed to do this.
Having explored the realm of No's and Heck-No's, I need to return to the
realm of a legal move by White and the topic of the announcements a referee
might make before announcing "Black," meaning "it is now Black's move."
These announcements depend on the Kriegspiel rule set being used. I know of
two rule sets, "Western Rules" and "Eastern Rules." Under Western Rules, these
referee announcements contain more information than under Eastern Rules. Both
rule sets are described in the 1972 paper in The Computer Journal. Charles,
Kelly, and I built our system so that the players could choose which rule set
they wanted to use .
The Southern California aerospace Kriegspiel community used Western Rules, so
let me describe them.
For a capture, the referee announces that the captured chessman is either a
"pawn" or a "piece," but in the latter case does not specify the type of piece.
If the move leaves the other player in check, the referee announces the
number of checks - "single check" or "double check" - and specifies the nature
of each check - "horizontal," "vertical," "long diagonal," "short diagonal," or
"by a knight." The directions and lengths of the diagonals are determined with
respect to square on which the now-in-check king resides.
If the move leaves the other player with the opportunity to make a capture by
moving a pawn, the referee points on both boards to the square to which the pawn
would move to make the capture and announces "pawn try." When either of two
pawns can make a capture on one square the referee points as previously
described and, instead, announces "double try." For situations in which there is
a potential for an en passant capture, the referee points to the empty square
over which the pawn that can be captured passed during its just-completed move.
Under either rule set, a player may resign at any time. The players can
confer and agree to declare a draw. We implemented these features in our
automated Kriegspiel referee.
Human referees have discretion to encourage a resignation or a draw. We did
not implement automation for this.
Charles, is there anything else to Western Rules?
CW: I don't recall. The comment I would make that isn't so obvious.
Kriegspiel was originally developed as a variation of chess for the purpose of
adding the fog of war to what is otherwise a game of complete information and it
is a way to remove information from the game. Unfortunately, I don't think it's
a very successful game of incomplete information in some ways, but it is
GAM: I have a memory of playing it as an amateur and I would move a
piece and the referee would say "no good" and I'd take it back and try another
one and was able to build up via a number of moves before I got done, a fairly
good idea of where my opponent was located.
CW: That's right and that's the point in the military sense. You sent
out a patrol and if they didn't come back, "well, there was somebody there".
It's sort of the image you're supposed to have. Unfortunately, it's one of the
reasons it's not been as popular as it could be, not only does it take three
people but because it's clearly not as good as some other games of incomplete
TJB: But Kriegspiel does have some nice features.
There is no external element of chance such as occurs in games that use dice.
While a group of players do, over time, find out which players are generally
better than other players, there is still potential for meaningful games between
players of unequal skill and experience. A lesser player can have a reasonable
opportunity to win against or tie a more experienced player. It is my obviously
unverified opinion that the "breadth of reasonable competition" spans a wider
range of skills than is found for chess or tennis.
CW: Now, lets go back and answer George's question of how does the
referee in the Kriegspiel system know what's going on and how do we keep the
information separated from the users.
In a real game, the way is to imagine how the opponent sees it. I always
imagine it as the two players separated by the screen. In human terms the same
person is both the director and the referee, sitting in a tennis umpires chair
with the full board laid out in front of him where neither of the players can
see it and saying no, or yes, or capture, or foot-fault, or whatever the
appropriate ruling is to the players. Tom actually describes something fairly
similar to that when he was an active player.
In the case of the computer version, again there is a master program
controlling all the user interface programs. The user interface programs are
either the players or kibitzers. Now the kibitzers always get to see the whole
board and everybody gets to see the public log. The players and kibitzers both
get to see a private log of their own as well. The master program merges all of
these logs together in the final game record. If you look at the photographs in
the paper you can see that each player and the kibitzers have a variety of
things they can do at any moment.
Now let's consider how a move is made. When a player moves, that becomes a
communication request to the master. The master receives the communication and,
without doing anything to the other players and kibitzers, examines it and
passes it on to the referee's subsystem and then gets back a response from the
referee. Notice the referee could be thought of as either another part of the
psyche of the master, if you would, or as a subordinate wholly controlled by the
master and locked in a closet where nobody else can see. You can think of it
In any case, the referee passes on the legality of the move. In Tom's
implementation, the referee passes back a great deal of information about the
move such as long or short diagonal for a check, whether the move was legal, and
if it was illegal, how it was illegal. The director takes that information and
makes up a response to the moving player, for example, "no you can't" and also,
if appropriate, makes up a response to the other player and to the kibitzers.
That's how we isolate the director's chore of processing a move and make sure
the other players see only what is appropriate. The director mediates all
communications. By the way, the other player and the kibitzers might be making
simultaneous requests and the director knows that. Tom might be making a move
while I simultaneously am hitting my resign button and in fact what will happen
is he might be allowed to make his move or I may manage to resign before he gets
it made. In any case, I will certainly be allowed to resign after he gets it
made and one way or the other both of these things will get done. But he won't
know that I am resigning while he is making his move and I won't know whether he
is actually making his move or if he's gone out for a drink while he's thinking
about his move, because the director will mediate the communication between us.
GAM: That's somewhat extreme but, all right, I understand what you
CW: That was the whole reason for separating the two papers. One is
about the director and one is about the referee because they solve different
problems. One solves the problem of "what's a legal move" and the other solves
the problem of "how do we mediate communication?" where there are different
patterns in communication between different people and the messages may need to
be filtered and transformed as they go from one person to another. You may not
get the message that was sent; instead, you might get a transformed message.
TJB: Do you think we can claim we built the first, or at least an
early, "chat room?" Perhaps we cannot claim to have facilitated the first
e-mail-like messages, but we did provide for communications between the parties.
CW: Exactly right, this is very similar to a chat room. Because of the
kibitzers and the messages between players,
TJB: We facilitated up to  three parties' communicating with each other. And they had a topic of mutual
interest - a Kriegspiel game - to discuss.
CW: That's right. This is exactly chat room software. Whether it's the
first or not, it certainly is very early. But the issue of the design was very
conscious of these issues of mediation and serialization and appropriate
forwarding of messages. There was real development and ideas there. Whether or
not we were the first in the world, I don't know.
TJB: Well, let's leave these thoughts in this oral history. Perhaps
some day someone will provide us feedback. How do you feel about similarities to
CW: This is not really an e-mail system. The intention was to provide
conversation, not memos. I think that we did succeed, if clumsily, in our
CW: But what I'm pointing out is that I think it might have been
before the Plato chat rooms. So I think it might conceivably be the first ever
chat room. That is a possibility.
GAM: Beyond that, without much effort, one can think of an enormous
number of applications for such a capability, in an ordinary human situation.
CW: Absolutely, one can and we thought of it this way. We actually say
in the conclusion that there are a few of the applications. We weren't inspired
enough to push it further than that unfortunately. We did mention a
business-oriented game and access to a database, which was interesting. But you
are absolutely right in saying what you say and I think it's exactly the
sociology of Livermore and of the computing environment there that kept this
from having more influence. Before I go much further, it isn't that the ideas
weren't sound and that there wasn't a sound implementation. On the contrary, I
think it was.
GAM: If there hadn't been sound commentary, you wouldn't have been
able to do what you did if you were working today.
CW: At Livermore?
CW: No, but I could do it at home. Actually, this is a side comment,
but I think it is important to the history. The Gordo terminals which were full
graphic terminals, although their full implementation was much different from
modern workstations, the effect of using one once we got it entirely working,
was very similar to what we do nowadays. It was very similar to the UNIX system
in some ways in terms of being a binary command system. It had a good editor, it
had compilers, it had graphics, you could run independent programs, we could run
sets of background programs. In practice, I think this was the only case where
we ran a background program, but the capability existed. Actually, except for
the fact that the monitors were themselves physically gigantic, it really wasn't
much different from using a workstation nowadays. I was always very unhappy
there were only four of them and they were all down in the computer room and we
had to hike down there; they should have been in our offices on our desks. But
that was physically impossible. Simply the size of the cables that connected it
in those days was huge.
GAM: Yes, I remember there was some consideration about using storage
tubes for this game. I don't know if it ever happened or not. You know the
Tektronix storage tubes.
CW: I remember the Tektronix tubes.
GAM: It saved the refresh bandwidth of the main computer.
CW: Yes, but there actually was none available for Gordo. It's
interesting; if you were sitting quiescent there was nothing going on. The
programs didn't sit and poll; they waited for an event from the graphics
terminals or from the keyboard. It was a very modern implementation.
You were not sitting there polling. Most systems in those days did sit and
poll. For example, CMTS had a lot of polling in it. Gordo had no polling The
systems were not interchangeable. So to have tried it out elsewhere would have
required us to completely redo the graphics, the user interfaces. And, indeed,
we would have had to largely redo the director's I/O communication because that
also had some special characteristics like that were not available on other
systems. So no, we did not imagine doing that.
Later on, Livermore provided an early graphics facility with TV monitors to
most users. We might have been able to move Kriegspiel then to other systems,
but by that time Tom was a physicist and the rest of us were off doing other
things. This was not very portable code for a variety of reasons, except for the
Kriegspiel referee itself, which could have been easily ported.
GAM: Well, I can't testify to that, but I think it's a fascinating
idea and I must admit that I look beyond tests for some of its inspiration.
CW: We should have, too.
GAM: So, not in summary, but to pick up loose ends, the implementation
language here was FORTRAN?
CW: The referee was FORTRAN and almost all the rest of it was FORTRAN.
We had to do a little assembly language for the semaphores in the communications
interface. It wasn't much.
GAM: If you can remember, when you were running, was it powerful
enough for other people to be using the machine for their purposes?
CW: Absolutely. It was a full time-sharing implementation.
GAM: So it was a good time-sharing implementation?
CW: The whole point was, as a matter of fact, the kibitzer could log
on and log off while the game was going on. That's an excellent question. The
way you started it was one person started and the other person came along and
hooked in and then the kibitzer could hook in later. When you hooked in you
chose your role, you said what kind of person you wanted to be. Now, again, we
only implemented one kibitzer, The system only had four terminals so more than
two kibitzers would have been sort of irrelevant. But in theory, you could have
as many as you want. In practice, you could have one or not and they could come
into and leave the system as the game is going on; there is no reason why
somebody couldn't have been on the other consoles doing whatever they wanted at
the same time. I suppose, in theory, there could have been two Kriegspiel's
running simultaneously, but I don't recall that ever happened.
GAM: Well that's very good. I can't think of any other questions to
CW: I have two more comments to make. This is just a comment about
Kriegspiel. I had noticed this before, in our bibliography and I'll bet we got
this from Tom. We have, J. D. Williams, "Kriegspiel rules at Rand" from 1950,
and is just about exactly the time that Nash showed up and when Williams was
running the Math Department and, in particular, was importing all the game
TJB: Someone other than me must have found that document. I cannot
recall having had knowledge of any literature about Kriegspiel. Nor can I recall
meeting any of those people.
CW: All right, that means I probably have it someplace, I wish I knew
where it was. It's interesting that J.D.Williams is the author also of The
Complete Strategist. One of the funniest books about mathematics, anyway.
GAM: I think I have that book at home.
CW: Yes, it's the one in which they study the probability that a
Prussian officer will kick a cavalry horse to death knowing the probability of
cavalry officers being kicked to death by Prussian army horses.
Anyway, perhaps a few words about the Gordo operating system that made this
possible. The operating system was implemented on the SDS Sigma-7, which
eventually became the Xerox Sigma-7 System. The Sigma-7 was a 32-bit
general-purpose computer similar to, but not identical with, the IBM 360. The
things that it carried across were the 32-bit memory and EBCDIC numbers. That
was long before the IEEE thought about floating point. It carried across very
useful character smashing instructions. What it didn't carry across was the
rather complicated addressing and variable length instruction formats of the 360
and that made it a much simpler machine to compile for and to program. It was
quite a nice machine in some of its architectural details, but unfortunately
they've been lost.
It also had built in hardware support for virtual memory. Just to prove that
people should remember what all that means, the virtual memory could be no
larger than the physical memory, but the provision for virtual memory allowed
you to have different memory spaces easily for different users so that you could
memory protect one running user from another. This was a feature that was not
available on most hardware systems and, for example, which bedeviled the CTSS
time-sharing systems at MIT for a long time because the earlier IBM systems
hadn't supported that. It was hard to do, although possible, on the 360's; on
the Sigma-7 it was very easy.
So the two designers, Ken Bertram and Gary Anderson with the help of Dick
Conn and a consultant, Butler Lampson, came up with a paged time- shared, fully
protected operating system and, since it was to be used for graphics, we
developed a graphics subsystem that also was, interestingly hardware time-shared
itself. In fact, there was only one display list for all the consoles, so we had
to figure out a way that your graphics didn't appear on my screen and vice
versa. That was done actually by the support hardware and device controllers; it
had essentially a tiny little resource sharing implementation of its own. It was
rather clever. The whole system was rather slow hardware by modern standards,
but relatively quick by the standards of its day. It was quite fast actually for
things like floating point.
GAM: It was comfortably fast. I attributed that to the fact that there
weren't very many users.
CW: Well, it wasn't just that, it actually was a quite a comfortable
machine. Because the O/S was easy to program. The innovative O/S that was
similar to the O/S's in some ways that had been done for Manchester for the
ATLAS machines made it very easy to program lots of things. In particular, for
example, we had shared libraries for FORTRAN long before that was common. That
was something I implemented actually. We had shared system calls for all
programs. Again, that was long before most systems had things like that. We had
no I/O subsystem because memory and disks were made all one system and it meant
that I/O was just writing the memory. A very straightforward operation, very
pleasant. It also allowed many sub- processes, again, a modern idea. All that
meant the implementation of the director was much easier than it might have
GAM: See, I attributed all that good stuff to the fact that people had
learned from the 940 system at Berkeley. They had the advice of Butler Lampson
and their own good sense and there were just a few of them instead of the
CW: I think there are a number of useful issues there. I think the 940
is probably right and I think that Butler Lampson helped with basic ideas a lot
(although that was before my time on the project). I think part of it was the
hardware. The hardware made a couple of these things, like the virtual memory
system, very easy to do. It made the process swapping very easy to do compared
to a lot of other systems of its day or maybe even of today.
GAM: I certainly don't wish to start an argument but I'm not convinced
you need virtual memory systems.
CW: The virtual memory sharing between users �
GAM: made it very useful.
CW: Yes, what's interesting is the feature of the virtual memory that
we used primarily was the fact that it could memory map pages. In fact, a
particular user's memory space was mapped into different files. Files included
ordinary data files, but they also included the system software and the dynamic
memory for a particular process. So, for example, the system resided at the
upper end of every process (that is, it was mapped there), but there was only
one copy of it and it was memory protected from the user under normal operating
conditions. It meant, for example, interrupt switching was very straight
forward; all you did was swap the memory map and suddenly the program could
actually execute instructions when previously it couldn't. The instructions were
suddenly mapped them in supervisor mode; those instructions were already in your
memory space. That aspect of the hardware made life much easier compared to the
contortions you'd have to go through on the 360 to provide the same level of
security and speed of switching simultaneously.
GAM: All these features you're talking about were available on all the
CW: PDP 10's were later.
CW: Certainly not earlier.
GAM: PDP 6's then if you will.
CW: Perhaps, but they certainly were not made use of in as elegant a
manner. This was a very elegant system; elegance and simplicity was a big deal
GAM: That's right but that's because you were few in number and you
knew what you were doing.
CW: I think it did have something to do with the fact that we were few
in number; I don't necessarily think it was because we knew what we were doing.
Because some of the things we developed were definitely serendipitous. There was
no question about that. There were some things that came along because we didn't
know what somebody said or they said "what if we?" There were certainly a few
bright people working hard. I think a comparable operating system of all the
ones that were around at the time and the one that had actually more, Gordo
should have had an equal influence with this one, but didn't, and that's the
Burroughs 5000/5500 operating systems. These were comparable in simplicity and
style and had much more influence even if they weren't commercially successful.
People learned from them and applied the ideas in many other places.
GAM: Burroughs made the mistake of having some really smart guys
running their computer planning stuff initially. They were very good.
CW: So those are my comments on Gordo and the elegance and simplicity
that made this project possible. I would not have been willing to attempt this
on the Laboratories main computer systems. I don't think it would have been
possible; the mechanism would have just been too cumbersome.
GAM: That's a very good point, a very good point.
CW: And actually I would not have been willing to attempt this
probably on a UNIX system until at least the mid-80's for similar reasons.
Because, in particular, the process communications and graphics controls were
not really available until somewhere around the mid-80's on most UNIX systems.
I'd have been ready to do a text-oriented version of it, but not one with a
graphic user interface. It would have been very difficult, unless I could have
had my friend the wizard Emacs programmer do the user interface.
TJB: Speaking of graphics, I was looking at our first article's
pictures of screens. I find the screens useful, simple, and well designed from a
player's perspective. Did you learn anything in terms of graphics techniques
while building the Kriegspiel referee?
CW: No, I don't think that we did.
TJB: The underlying system was based on vector graphics, as I recall.
CW: Yes, the displays on the Gordo system were calligraphic and
required subroutines to do things; standardized subroutines were available in a
standard library that everybody used to put text at a particular point, to
change it, to draw lines. So it is quite simple, notice we do not try to draw
chess characters. One of the problems with the calligraphic system was when you
started to overload the calligraphic display, it slowed down and also had a
tendency to overshoot on tight curves. But it did have hardware to do characters
that was more accurate and so everything was sort of a chessboard with letters
for the pieces rather than little drawn chess pieces. It was natural and easy.
The rest of it was just sort of a natural layout on the screen. I recall
thinking, and this is the part where Tom was a help, about what kind actions we
needed, trying out this and that and then coming down to the set we had. For
example, over to the right on the screen, one of the actions allows you to
create an opponent's piece. The idea is you might want to say, "Oh, he has
another queen now, I better put that on the board. I've just figured that out."
So you could click on the Kriegspiel opponent and then there was a list of the
kinds of pieces he could have. It's interesting that your pieces were always in
capital letters and his were always in lower case, so you could click on one of
them and put a queen or something someplace on the board. You could also kill
them and so on. At the end of the game it shows the real positions of everybody,
the real board.
GAM: One board?
TJB: At the end of the game, the position of both players was
displayed on all three screens, whereas before then only the kibitzer saw the
combined official positions of the two players.
At no time were one player's estimates about his opponent visible on a screen
used by the other player or the kibitzer.
The printout - available to anyone after the end of the game - documented all
attempted moves, all changes recorded by players of their estimates of their
opponents' positions ,
all messages sent by the participants to each other, all attempts to ask an
opponent to agree to a draw, all "thoughts" sent by participants to the "game
summary" (that is, the file that would become the basis for the printout), and
any voluntary resignation ending the game.
Participants typed their "messages" and "thoughts." Messages were delivered
immediately to all parties, paralleling the concept that they would have been
spoken aloud if the referee were human. Thoughts were sent only to the
CW: That's right. And all this is where Tom helped us understand what
needed to be in the commands.
GAM: Thanks for a most interesting chat.
 Mark went to college at UC Berkeley. I
took over his half of an apartment when I arrived at Berkeley for graduate
school. Later, he received a law degree from Hastings, served 20 years as a
lawyer in the U.S. Navy (retiring as a Commander), and subsequently became an
administrative law judge and supervising judge for the Social Security
 During the summer of 1963, I was Douglas Aircraft's
second-ever employee ever under the age of 18. I wrote payroll programs in SPS
assembly language for use on the IBM 1401 and project management software in
COBOL for use on the IBM 7094.
 During three summers with Hughes, I did a variety of
work within one department. In 1964, I helped pioneer downward-looking radar by
writing programs for the guidance and control computer in F-106 aircraft. The
computer was the Hughes MA-1, an early 1950's drum-based computer with a total
of 13 magnetic cores. In 1965, I programmed the replacement for the MA-1 and
helped design the instruction set for a proposed airborne computer. In 1967, I
developed routing algorithms and graphical plotting techniques for circuits on
printed circuit boards.
 I improved a satellite re-entry trajectory
simulation software system and added, for example, graphical output. General
Motors delivered the new system to NASA during 1966.
 A Beautiful Mind. Sylvia Nasar, Touchstone, 1998.
 I recall later writing a program for him to use on a
CDC 160-A which he used for some of his work.
 Malaga Cove included grades one through eight.
 The first meeting to explore the concept was held in
my family's living room and included Peninsula parents and at least one Malaga
Cove teacher. At the beginning of each school year (for about a decade), the
Club held a meeting in a school auditorium. Students met the adults who would
serve as counselors for that school year. Students signed up the counselor or
counselors of their choice. Each counselor represented an area of science or
technology. Then, each counselor (occasionally, two adults teamed up to teach
one subject) and the counselor's group of students would meet as frequently as
they chose. The main function of the Club itself, after each year's initial
meeting, was to carry insurance in case of an accident.
 The Science Club proved to be the model for the
founding and operations of the Palos Verdes Peninsula Arts and Humanities Club.
To the best of my knowledge, neither organization made much use of school
facilities, other than for their annual kick-off meetings and � at least in the
case of the Arts and Humanities Club � for end-of-the-school-year meetings at
which people demonstrated to each other what they had accomplished.
 My home, at 2729 Palos Verdes Drive North, proved
a creative place. When I was about 12 years old, I proposed to my father the
concept that was later implemented as the Palos Verdes Estates Shoreline
Preserve. At the time, he and his colleagues were defensively countering
proposals to develop Palos Verdes Estates' four miles of virtually untouched
coastline and 700 acres of parkland. Proposals included marinas for Malaga Cove
and Lunada Bay, a building for an "oceanographic society," tennis clubs, parking
for the Malaga Cove plaza, a city hall, and a city yard. I suggested proactively
developing and implementing a different agenda, namely a wildlife preserve. My
idea was eventually implemented as the Palos Verdes Estates Shoreline Preserve
(before the creation of the California Coastal Commission) and remains alive and
 The counselor was Milton Clauser, who was then or
had been Vice President for Research and Development of Space Technology
Laboratories (later a part of TRW). After his work at STL, he founded a company
that made atomic clocks, led MIT's Lincoln Laboratories, and served as Academic
Dean for the Naval Postgraduate School in Monterey, California. Milton and his
family had been next-to-next-door neighbors of my family (my parents Joe and
Sylvia Buckholtz and myself) around 1954 and then moved to Rolling Hills,
another city on the Palos Verdes Peninsula. In the early 1970's, I recall
spending one or two nights in Milton's and Virginia's home, which was the Naval
Postgraduate School's Dean's on-campus residence. They later built a home in the
hills above Monterey. My wife Helen and I spent at least one night there and
visited them at least one other time. Milton and his twin brother Francis were
Caltech PhD's. Helen and I met Francis first in the 1970's or 1980's in the
course of his being a faculty member at Caltech.
 Work I did with guidance from an industrial
physicist, Art Wannlund, became the science fair project, "The Effects of
Temperature and Concentration on the Electrical Conductivity of Chloride Salt
Solutions," with which I won first prize in Physical Sciences for the Junior
Division (seventh through ninth grade) of the 1960 Southern California Science
 Few pre-college students had access to computers
 Jim drove us to and from the plant.
 I wrote a software program for factoring numbers.
Jim typed 9876543211 into my program, which determined it to be prime. The
numbers 2 greater and 2 less proved to have very few factors.
 The computer was located in CSC's headquarters
building on Pacific Coast Highway in a city (possibly El Segundo) north of Palos
Verdes. I recall that previously, CSC's entire corporate office space had
consisted of two suites in the Malaga Cove plaza.
 In the mid 1970's, computing would become a focus
for my work.
 The theoretical research and the computational
proof that the results of my theory meshed well with existing theories at the
limits of their applicability were done at the Lawrence Radiation Laboratory,
Livermore. My thesis, "Statistical Mechanics of Two-Species Plasmas, with
Applications to White Dwarf Stars and Metallic Hydrogen," was reprinted as Lab
report UCRL 51055.
 Q Division emphasized theoretical laser physics. I
worked with Hugh DeWitt, a theoretical statistical mechanician who was employed
in that division and guided several Berkeley students to their doctorates. Many
of those students had no relationship with the Lab. I did not work on laser
 Toward the end of the second summer, I returned
home and worked for 6 weeks at TRW.
 Lee Neidengard, John Tucker, I, and Kelly Booth
graduated from Caltech in 1965, 1966, 1967, and 1968, respectively. We probably
had one teacher in common � Francis Lowery � who taught calculus, first at
Narbonne High School and then at Palos Verdes High School. Narbonne is a Los
Angeles School System school to which the Palos Verdes School District sent its
tenth through twelfth graders for a few years. (I attended Los Angeles
district's Alexander Fleming Junior High School for my ninth grade and Narbonne
for my tenth grade.) Then, Palos Verdes "unified" under the name Palos Verdes
Peninsula Unified School District. The facility that became Palos Verdes High
School was built by the Los Angeles district to be a junior high school. It was
not so used. In 1961 Palos Verdes opened the facility as Palos Verdes High
School. Francis Lowery's teaching allowed me to qualify for and take sophomore
calculus as a freshman at Caltech. I took junior year analysis in my sophomore
year. The professor was Don Knuth. We published two papers � "Computation of
Tangent, Euler, and Bernoulli Numbers" and "Tables of Tangent, Euler, and
Bernoulli Numbers" in Mathematics of Computation (1967) based on a term paper I
did for that class. Later, Kelly and I attended seminars in Don's home on the
 K. Martin Stevenson III lived in Palos Verdes and
graduated in Caltech's class of 1969. I do not know whether he had been
associated with Francis Lowery. K. Martin Stevenson Jr., a 1945 graduate of
Caltech, was the manager of the A.C. Electronics plant, on Pacific Coast Highway
just south of the Los Angeles Airport, at which I worked during the summer of
 He earned his PhD from the Electrical
Engineering/Computer Science Department.
 Meeting George Michael was fortunate for me for
more than just my launching the Kriegspiel project and our doing this oral
A. In 1976, George introduced me to Tom Follett. That year, I left my
employment as a Physicist in T Division at the Lab to join Tom at Insurance
Technology Company (a Teknekron company) in Berkeley. Actually, I worked at both
jobs for some time and then served as a consultant to the Lab through January 1,
1977. Some of my Lab work produced what may have been the first paper announcing
the observation of neutrons from a controlled fusion experiment ("Simulation of
Neutron-producing Plasma Focus Targets", co-authored with H.L. Sahlin and R.H.
White, UCRL 77707, 1976). Together, Tom Follett and I had key roles in building
Teknekron's (and probably the world's) first automated document library that
stored document images for more than a few days. That system is discussed in my
paper "Large-Scale, Real-Time Document Distribution", in 3rd USA-JAPAN Computer
Conference Proceedings, AFIPS and IPSJ, 1978. Technologies created for that
project carried over into Teknekron's later company Integration Automation
(which was eventually acquired by Litton) and, I suppose, the company that is
now TIBCO. I left Teknekron to become the only other person in Tom's own
company, Berkeley Technical Associates.
B. While I was with Insurance Technology, George introduced me to Henry
Laxen. I hired Henry. Later, Henry offered me the opportunity to replace himself
in his position as Software Manager at Friends Amis near Fisherman's Wharf in
San Francisco. I accepted. Henry's and my work there contributed to one of the
first general-purpose hand-held computers. After buying Friends Amis, Matsushita
sold (I was later told) 70,000 of these computers, under the name Panasonic HHC.
C. Sometime around 1969, George recommended that, if I ever visited the
Pentagon, I should meet his in-law David O. ("Doc") Cooke. In September 1989,
between my job interviews with the Administrator of the General Services
Administration and a staff member in Presidential Personnel, I went to the
Pentagon and met Doc. He provided much appreciated advice while I served
(1989�1993) as GSA's Commissioner for its Information Resources Management
Service. My wife Helen and I enjoyed 1998 Thanksgiving dinner in Doc's home,
with many members of his family. Subsequently, Doc arranged for General Colin
Powell to autograph a picture, taken in 1991, of Gen. and Mrs. Powell and Helen
and me. Gen. Powell also autographed my copy of his book My American Journey,
and Doc placed his own initials near mention of himself on page 300.
 "A Director for Kriegspiel, A Variant of Chess",
by C.S. Wetherell, T.J. Buckholtz, and K.S. Booth, The Computer Journal, vol.
15, No. 1 (1972); "A Program to Referee Kriegspiel and Chess', by T.J. Buckholtz
and C.S. Wetherell, The Computer Journal, 1975.
 Gordo was the time sharing operating system,
developed at the Laboratory for use on the Sigma-7 Graphics Research Computer
 I recall working evenings (and probably sleeping
some nights on a sofa) in Charles' apartment. He took the lead in writing the
papers and preparing a version of the core software of the referee for
publication. I assisted.
 The Sigma-7 could be operated either under the
Gordo system or under a system supplied by the manufacturer. The manufacturer's
system was a kind of single-user setup a lot like running a PC under a simple
 This was the apartment in which Mark Dawson had
lived. I lived there at 2206 Dwight Way, Apartment 5, for 3 years, including
those first three summers during which I worked at the Lab and co-developed the
 The others, undergraduate physics majors, included
Doug Eardley, Andy Mackay, Mike Robel, and Duke Sun. Permit me to mention
aspects of the careers of two other 1967 Caltech physics graduates. Doug
Osheroff (a housemate of mine in Lloyd House) is now a physics professor at
Stanford and has won a Nobel Prize. Ron Peterson (a roommate of mine) served as
Chief Technology Officer for Honeywell.
 Permit me also to mention two other people I met
in the Physics Department at Berkeley. Helen Chu entered the graduate program at
the same time as did I. She had graduated from Berkeley and had been admitted
(as had I) for graduate study at Caltech. We married in my family home in Palos
Verdes Estates on November 22, 1973. We chose the day because it was
Thanksgiving and because of the numbers 11-22-73. Kelly Booth suggested to us
the judge who officiated at our wedding. Steve Chu (not related to Helen)
entered Berkeley a few years after Helen and me. He and I met in 1970 when we
both played on the department's intramural tennis team. We were housemates after
I received my doctorate � from 1971 to 1973. He is now a physics professor at
Stanford and won a Nobel Prize the year after Doug Osheroff.
 Doug Eardley, Andy Mackay, and myself. Andy
provided the link to my first job after I received my doctorate. He brought me
into a startup company that wanted to perfect controlled fusion via confinement
and heating of plasma using a dynamic electromagnetic field inside a torus. He
had met the founder of the company at the Lab. The two of them invited me to
join. My main contribution was raising enough venture capital to sustain the
company for a year although I did not stay there much after the money was
secured. That amount turned out to be one-half of one percent of the total 1972
U.S. venture capital pool.
 The transcript was reprinted in the 1972 paper.
 When promoting a pawn, the player poked the type
of piece to be added, before poking "Complete." At any time before poking
"Complete," the player could poke "Abort" and then choose another move.
 CW: The user interface had most of the features
expected in modern user interfaces. Although we had neither drop down menus nor
windows, the program did display its output graphically. There were buttons to
select actions, there were clear state indicators (such as "It is White's
move"), there was a separate area which showed the conversation flowing between
the parties (including the director), and there was the board, of course.
There were, however, two difficulties. First, none of the hardware was very
fast. Delays were common as the programs managed the communication and the
graphics. Of course, this still happens in multi-threaded graphics programs, but
the hesitations sometimes led to confusion when a player thought that a move or
other command had not been noticed by the system. We might have been more clever
about installing some mechanism to respond quickly that an input had been
Second, the calligraphic display made the board display and the movement of
pieces less nice than they would be in a more modern system. If we had tried to
draw real chess pieces, the drawings themselves would have been muddy, there
very likely would have been noticeable overshoot, and there probably would have
been noticeable flicker as the display units tried to draw all the tiny lines.
Similarly, the board squares are all the same color (not even light and dark)
because light colored squares would have been difficult for the display
Because the light pen could sense movement only where there was light, we
were forced to the expedient of putting little dots in the middle of the
unoccupied squares. On modern equipment, a mouse always "knows" where it is in
the display geometry; however, the light pen had to sense the pulse of the
display beam actually going under the light pen's sensor. Whether one prefers
using a pen-like device to a mouse-like device is a kind of physiological (and
psychological!) choice; however, there is no question that the technology behind
the bitmap graphics of modern computers makes it easier to program natural
graphics controls without artifacts like the dots.
There is one more point to be made. Modern bitmap displays with full color
allow graphics which are more attractive, more realistic, and more satisfying to
the user. It is hard to measure this exactly, but even when we were programming
Kriegspiel, I wished that we could make the whole display much more natural. Of
course, we were using state of the art equipment at the time. Still, a modern
display would have made Kriegspiel a lot flashier.
 While revising this section, I was out shopping
and ran across a game called Stealth Chess, a combination of Kriegspiel and
Stratego � a patented board game. Stealth Chess is played with pieces which have
two sides. A player can see his own pieces from his side of the board, but the
opponent's pieces show only blank faces. Of course, this is just an easy kind of
blindfold chess so far; in effect, you have to remember where every (to you,
blank) opponent's piece came from. If you can remember that, then you can play
the game as if it were ordinary chess.
Stratego adds another dimension to this idea. A player starts all the pieces
in a particular area of the board (like chess), but a player can put his pieces
in any order in that area. If Stealth Chess allowed a player to set up his
pieces in some order other than the ordinary chess order, then the opponent
would have to observe movement to deduce which piece was which. In other words,
Stealth Chess could have some of the mystery of Kriegspiel without the necessity
for a referee (although it's not clear how the en passant rule could reasonably
 If a divider was not available, the players sat
back-to-back. The boards were separated considerably adding some challenge for
 The players could also choose colors � White or
Black. If both players chose the same color or if one player requested a random
assignment of colors, the system made a random assignment.
 There was no requirement to have a "kibitzers'
terminal." The system worked if only two terminals were used � one for each
 At the beginning of each game, the system put a
set of opponents' pieces on each board, in their then-correct starting
positions, as dictated by the rules of chess.
For information about this page, contact us at: firstname.lastname@example.org