An Interview with Charles Wetherell
and Tom Buckholtz

(September 14, 1999)

Tom Buckholtz Charles Wetherell
Tom Buckholtz Charles Wetherell




CW = Charles Wetherell
TJB = Thomas J. ("Tom") Buckholtz
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 [1]. 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 [2], Hughes Aircraft [3], and A. C. Electronics Division of General Motors [4]. I probably introduced the game to my groups at Hughes and GM.

CW: I've just finished reading the John Nash biography [5] 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 [6] 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 seriously.

Another thread that I should describe features my learning to program computers. When I was in the seventh grade, at Malaga Cove School [7] 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 [11], ham radio, mathematics, physics, [12] and computer programming [13].

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 304 [14]. The NCR 304 was considered a medium scale business computer. At that time, it came with no software. We programmed in absolute code [15].

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 [16] 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 [17].

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 [18], I worked as a Summer Research Appointee in Q Division [19] at the Livermore Laboratory [20].

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 [21] in four years to enter Caltech as a freshman [22]. He was about to continue to follow me for one more step, having been admitted to Berkeley [23]. So, after a year apart, we, in effect, got reacquainted.

During the summer of 1968 Kelly introduced me to you, George Michael [24], 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 referee.

Do you think we should describe the game now, describe it later, or just cite the relevant papers [25]?

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 [26] 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 paper.

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 [27].

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 [28].

At the time, I was living in an apartment in Berkeley [29]. 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 referee.

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

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

CW: There were certainly many test efforts, but only a few complete games.

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

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 [32].

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 [33], 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 a checkmate.

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" [34]. 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 [35].

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

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

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

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 [36].

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

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

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

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 [37]. 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 [38].

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

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

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

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

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 [39] 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 e-mail?

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

TJB: OK.

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?

GAM: Yes.

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

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

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

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

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 PDP 10's.

CW: PDP 10's were later.

GAM: No.

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

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 [40], 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 transcript file.

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.


[1] 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 Administration.

[2] 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.

[3] 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.

[4] 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.

[5] A Beautiful Mind. Sylvia Nasar, Touchstone, 1998.

[6] I recall later writing a program for him to use on a CDC 160-A which he used for some of his work.

[7] Malaga Cove included grades one through eight.

[8] 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.

[9] 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.

[10] 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 natural today.

[11] 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.

[12] 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 Fair.

[13] Few pre-college students had access to computers in 1961.

[14] Jim drove us to and from the plant.

[15] 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.

[16] 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.

[17] In the mid 1970's, computing would become a focus for my work.

[18] 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.

[19] 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 physics.

[20] Toward the end of the second summer, I returned home and worked for 6 weeks at TRW.

[21] 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 Stanford campus.

[22] 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 1966.

[23] He earned his PhD from the Electrical Engineering/Computer Science Department.

[24] Meeting George Michael was fortunate for me for more than just my launching the Kriegspiel project and our doing this oral history.

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.

[25] "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.

[26] Gordo was the time sharing operating system, developed at the Laboratory for use on the Sigma-7 Graphics Research Computer System.

[27] 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.

[28] 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 DOS system.

[29] 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 Kriegspiel referee.

[30] 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.

[31] 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.

[32] 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.

[33] The transcript was reprinted in the 1972 paper.

[34] 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.

[35] 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 received.

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

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.

[36] 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 be enforced).

[37] If a divider was not available, the players sat back-to-back. The boards were separated considerably adding some challenge for the referee.

[38] 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.

[39] There was no requirement to have a "kibitzers' terminal." The system worked if only two terminals were used � one for each player.

[40] 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.