The program actually ran on a PDP-6 computer (and later, a PDP-10). This was a large "mainframe" computer, which could not possibly be moved to the tournament location. Actually, the teletype wasn't all that easy to lug down there either - it weighed about 34 kg (75 pounds), including its stand. It was linked to the computer over a telephone line, using a 110 baud modem, for a communications rate of ten characters per second. I recall at least one person at a tournament who thought the teletype terminal was the actual chess-playing computer, and he asked where he could buy one. The teletype could not actually move the chess pieces on the board, of course. A representative at the tournament read the moves that the program sent to the teletype, and moved the pieces on the chess board. When the opponent made his move, the representative typed them on the teletype. Tournaments were generally played at the Boylston YMCU ("Young Man's Christian Union") in Boston (Massachusetts, USA). The program was able to play in tournaments because the Massachusetts State Chess Federation decided to make it an honorary member, which I think also made it a member of the United States Chess Federation ("USCF"). It was allowed to play in tournaments in order to establish a "rating", which is, essentially, a numerical measure of how good a player is. Ratings are established in tournament play based on complex numerical formulas that take into account the ratings of other tournament players you have played, and the outcomes of these games. Your numerical rating puts you into different "classes", from Class A to Class J, the top five of which are: National Class A (USCF 1800- 1999), the top amateur class
For the most part, tournament players are ranked in Class D or above. Mac Hack VI was probably a Class E player when it first started tournament play, but it improved rapidly as Greenblatt refined the program. I recall seeing the U. S. Chess Federation certificate of honorary membership for Mac Hack VI, which gave it permission to play in tournaments. A line on the certificate noted that the membership was valid "Until superseded by Mac Hack VII". This reflected a misunderstanding on the part of the Chess Federation, since the "VI" in "Mac Hack VI" was not a program version number. It was rather a number derived from the PDP-6 computer that the program initially ran on. The program was never actually exactly the same in any two tournaments, as Greenblatt kept improving it, particularly once the programmers saw how it behaved in tournament play. In fact, I think that sometimes improvements were added from one day to the next, so the program playing the last game of a tournament could be different from the program playing the first game. Although we entered our first five-game tournament with high hopes, the program lost its first four games. In the fifth, though, it arrived at the endgame in decent shape, and the programmers decided to offer the opponent a draw. The opponent, an elderly man who perhaps imagined that the computer would be very strong in the endgame, accepted. In fact, the program was rather bad in its endgame play at the time, and the opponent might well have prevailed had he persisted. Richard Greenblatt noted, in a recent e-mail message, "The opponent was an older guy who was a local chess legend and rated about 1400. He was also a bit of a promoter, so although the game appeared legit, we were a bit leery about 'counting' it too much." It was the programmers, not the program, who decided to offer a draw in the game I described above. Initially, if an opponent offered a draw, it was the programmers who accepted or declined. If the program was running out of time on the clock, the programmers might alter its look-ahead parameters to speed it up. Eventually, the Chess Federation objected to the fact that people were still making decisions for the program during tournament games, and insisted that these decisions be made by the program itself. Greenblatt added the necessary code.
For those who have never seen one, the picture to the right shows a typical tournament chess clock, which was placed alongside the chess board. When a player makes a move, he pushes the button on his side. That stops his clock, and starts the opponent's clock (and causes the opposite button to pop up). Tournament rules typically give each player a fixed amount of total time in which to make a specified number of moves. If that time expires, that player has lost. Our lab's machinist, Bill Bennett, made a device that clamped over a standard chess clock. A plunger on the device pressed down on one of the buttons on the clock, and a cam on the plunger operated a switch that reported the position of the plunger, up or down, to the computer. This allowed the program to tell how much time it had left on the actual tournament clock with reasonable accuracy, since the time between button pushes included the time needed to type in the opponent's moves, and to make the computer's moves on the board. Note 2 I'll now describe a couple of early games that I found particularly interesting. I should note that these games were played over forty years ago, and I can't be sure how accurate my memory is. The opponent for the first of these was a Class D ranked player, so the program had a chance. He was also known as an unorthodox player, prone to making unusual moves. We thought that this might be an advantage for the computer, since to the program, there's no such thing as an "odd" move - all moves are evaluated in exactly the same way. We thought that unorthodox moves would be apt to confuse a human player more than a computer program - unusual moves are apt to be fundamentally bad moves, even if they might confuse an opponent. And in that sense, the player didn't disappoint us - he indeed made an unorthodox move. He fed the computer a piece that could only be captured by the king, and the computer took it. The opponent gained very little advantage from his move. Having once moved its king, the computer could no longer castle, but that hardly made up for the loss of a piece on the other side. But the opponent continued his bizarre approach, feeding the king another piece, and then a pawn, both of which the computer took. This left the program's king standing out in the middle of the board, on the fourth rank. You can be sure that the resulting position was very well analyzed by all our experts in the post-mortem that occurred after the game. And they decided that up to that point, the computer had done everything right. All the computer had to do was to retreat the king to safety as rapidly as possible, which it could have done with the loss of only a pawn or two, and it would have been in a good position to go on to win the game. The trouble was, the program at the time had no concept that there was anything wrong with having your king standing out in the center of the board. Ahead by two pieces and a pawn, the program sat there, as someone later said, "with a big smile on its face" (that is, with a high positive board evaluation), and proceeded to develop its other pieces, as is usually done early in a game. And the opponent set up a mating combination, and checkmated in short order. I don't think we'd ever seen the program's numerical evaluation of its position plummet quite so rapidly, as the mate came into view of the look-ahead. Back at Tech Square, Greenblatt opened his listing, and started coding the concept of "king safety". I recall another interesting game that occurred some time later, when the program had improved considerably. Other than our representatives physically moving the pieces at the Boylston YMCU, few people traveled to the tournament site. Most of us stayed in the lab, although we often followed the game on a chess board there. This gave us much more information than we would have had down at the actual tournament site, since our line printer chattered after each move, spewing out information about the computer's decision making. Note 3 The first thing printed was a list of all possible moves, in order of "plausibility", printed by the program's "Plausible Move Generator" module. This was eventually followed by an in-depth evaluation of each of the moves considered, printed by the look-ahead logic (the program typically considered only the top six or so potential moves, as ranked by the Plausible Move Generator). In the particular game I'm describing, the computer was doing quite well, and it looked as if it would win. On the other hand, it could be weak in the endgame, so we knew that it might not pull it off. A master-level player working with the team was observing the game with us. I think it may have been Larry Kaufman, a student at MIT who was a national master, but I'm not sure of that. Suddenly, he said something like, "Wow, look at this!", and he pointed out a mating combination for the program - the game was won! Except, of course, there was the question of whether or not the program would "see" the same possibility he had spotted. After all, of all the people following the game, only he had seen it. We ran over to the line printer, and looked at the plausible move list, which had already been printed. The initial move of the mating combination was on the list, of course, since all moves are on the list. But it was ranked dead last - the Plausible Move Generator module of the program considered it to be absolutely the least-likely move for the computer to choose. This was not surprising, since it was a queen sacrifice. We knew that if the computer looked ahead a few ply (that is, looked at the opponent's response, its own next move, and so on), it would have been likely to see the mating combination. But of course, you can't see it if you don't look, and why waste time looking at a move that will result in the immediate capture of your queen? Oh, well. How could we expect the program to find a tricky mating combination that only one observer had noticed, and he was a master-level player? We waited for the program's move, but the program seemed to be taking longer than usual to do its analysis. Finally, the line printer chattered, and we knew that at the same time, the move was being typed out at the tournament site. It was the queen sacrifice, and the program's board evaluation, the large positive number that we considered to be "plus infinity", indicated that the program had seen the forced mate, and thus "knew" that the game was definitely won. That, in fact, accounted for the extra time the program had taken to announce its move. Upon seeing what looked like a mating combination, the program had evaluated all possible responses of the opponent at each level of the look-ahead, to be certain that the checkmate could not possibly be avoided. We were all delighted, of course, but Greenblatt's delight was tempered by puzzlement. We could understand how the program had seen the mate once it had looked in depth at the queen sacrifice, but why had it evaluated that move at all, the lowest of the low in terms of its likelihood of success? If I'm recalling correctly, Greenblatt actually pulled out the thick source code listing, and started looking through the program to figure out what might have happened. And then it hit him. There's an old chess adage, "When in doubt, check". The queen sacrifice was a checking move, and the program had been written to evaluate ALL checking moves, no matter how dubious they seemed. Nobody had particularly noticed that the queen move was a check. I mean, we saw it, obviously, but it's hardly important that the queen checks the opponent when the queen is going to be immediately captured. But it was that incidental attribute of the move that had caused it to be evaluated by the look-ahead module, which had exposed the mate. The phone rang. It was one of our representatives at the tournament, all upset. The computer had been winning, he wailed, and now it's throwing away the game by giving up its queen! I was glad to know that I wasn't the only one who hadn't seen the mating combination. Watch and learn, we told him, watch and learn.   Note 1: Richard Greenblatt recalls that the model 33 ASR ("Automatic Send/Receive") teletype that came with the PDP-6 wore out quickly, and was replaced with a model 35 KSR ("Keyboard Send/Receive"). The KSR models had only a keyboard and a printer, while the ASR models added a paper tape reader and punch. Communication with the teletype was via an RS-232 serial data link, and the way the teletype interpreted these signals is an indication of the technology of the time. The characters were not interpreted electronically but rather mechanically! In serial transmission, the bits of the binary code for each character are sent sequentially. Actually, they are preceded by a "start bit", followed by the eight bits of the character itself, followed by a double length "stop" interval to allow the receiver to ready itself for the next character. These eleven bit times account for the data rate of 110 "baud" (essentially, "bits per second") in order for the teletype to print at 10 characters per second. The teletype contained a motor that spun a continuously rotating shaft. When a start bit came in, it caused the release of a high-speed clutch that connected the shaft to a commutator. As the commutator spun around, it distributed each successive bit to its own relay, which it either closed or left open. These physically rotated the type cylinder used to impress the character on the paper, through an inked ribbon. In the ASR teletypes, the holes in the paper tape were sensed by actually pushing small pins through the holes! Today, an integrated circuit to decode serial signals is called a UART ("Universal Asynchronous Receiver-Transmitter"), and they cost less than a dollar in quantity (although they're not used much any more). It seems rather astounding to recall that in the late sixties, the cost of decoding these signals electronically would have been so prohibitive that instead the job was done mechanically. [return to text] Note 2: I asked Greenblatt how this worked, and he reported that, "Early teletypes provided for something called 'restrain tone' which was intended to 'restrain' paper tape readers in case delays were encountered down the line. We used a frequency allocated for this (a 700 Hz tone, I believe) to relay the state of the switch on the clock at the tournament." [return to text] Note 3: What the heck is a "line printer", I hear some of you youngsters ask, and why did it "chatter"? The teletype terminal printed one character at a time, at a blazing ten characters a second. But in the sixties, if you wanted to print faster, you used a "line printer", which printed an entire line at a time before advancing the paper (which was typically wide, and sprocket-fed). There were various different line printer technologies. Ours used a flexible steel band (sort of like the saw blade of a band saw) with raised characters on it. It spun continuously across the print line, in front of a row of electromagnet-actuated hammers, one for each print position on the line. As the proper character for a given print position passed by, the hammer would rapidly strike and withdraw, impressing the character onto the paper through an inked ribbon (all without stopping the motion of the band). The banging of the hammers made a kind of chattering sound. The first time I ever saw a laser printer (I think it was at MIT's Lincoln Laboratory), my jaw dropped. If you'd told me I would one day have one sitting on my desk near a home computer that would be substantially more powerful than the multi-million dollar PDP-10, I wouldn't have believed you. [return to text]  |
The picture shows what the computer program Mac Hack VI looked like to its opponents when it played in chess tournaments. 