A bunch of chess-related papers.HEADmaster

5 files changed, 4110 insertions, 0 deletions

diff --git a/rules and standards/FideLawsOfChess b/rules and standards/FideLawsOfChess
new file mode 100755
index 0000000..64bd75d
--- /dev/null
+++ b/rules and standards/FideLawsOfChess
@@ -0,0 +1,791 @@
+From: [email protected] (Steven Rix)
+Newsgroups: rec.games.chess
+Subject: 1993 FIDE Laws of Chess
+Date: 16 Apr 93
+
+
+                        The F.I.D.E. Laws Of Chess 
+                        ==========================
+ 
+Preface   
+-------
+
+   The Laws of Chess cannot cover all possible situations that may 
+arise during a game, nor can they regulate all administrative questions. 
+Where cases are not precisely regulated by an Article of the Laws, it 
+should be possible to reach a correct decision by studying analogous
+situations which are discussed in the Laws.
+
+   The Laws assume arbiters have the necessary competence, sound
+judgment and absolute objectivity. Too detailed a rule might deprive
+the arbiter of his freedom of judgment and thus prevent him from finding
+the solution to a problem dictated by fairness, logic and special factors.
+
+   F.I.D.E. appeals to all chess players and federations to accept 
+this view. Any chess federation that already operates, or wants to 
+introduce, more detailed rules is free to do so, provided:
+
+ (a)  they do not conflict in any way with the official 
+F.I.D.E. Laws of Chess;
+
+ (b)  they are limited to the territory of the federation in
+question; and
+
+ (c)  they are not valid for any F.I.D.E. match, championship,
+or qualifying event, or to a F.I.D.E. title or rating tournament.
+                 
+   In the Articles of these Laws, "he", "him" and "his" can refer to 
+"she", "her" and "hers".
+
+ 
+
+Article 1:    The Chessboard 
+----------    --------------      
+
+      The game of chess is played between two opponents by moving pieces
+      on a square board called a  "chessboard".
+  
+ 1.1  The chessboard is composed of 64 equal squares, alternately light 
+      (the  "white" squares) and dark (the  "black" squares).
+
+ 1.2  The chessboard is placed between the players in such a way that 
+      the near corner to the right of each player is white.
+
+ 1.3  The eight vertical rows of squares are called  "files".
+
+ 1.4  The eight horizontal rows of squares are called  "ranks".
+
+ 1.5  The lines of squares of the same colour, touching corner to corner, 
+       are called  "diagonals".
+
+ 
+
+Article 2:    The Pieces   
+----------    ----------    
+
+ 2.1  At the beginning of the game, one player has 16 light-coloured 
+      pieces (the  "white" pieces), the other has 16 dark-coloured 
+      pieces (the  "black"  pieces.
+
+ 2.2  These pieces are as follows: 
+      A white king:          K            A black king:        k  
+      A white queen:         Q            A black queen:       q  
+      Two white rooks:       R            Two black rooks:     r  
+      Two white knights:     N            Two black knights:   n  
+      Two white bishops:     B            Two black bishops:   b  
+      Eight white pawns:     P            Eight black pawns:   p  
+
+ 2.3  The initial position of the pieces on the chessboard is as follows:
+
+      |---|---|---|---|---|---|---|---|
+      | r | n | b | q | k | b | n | r |   -- this square is "black"
+      |---|---|---|---|---|---|---|---|
+      | p | p | p | p | p | p | p | p |
+      |---|---|---|---|---|---|---|---|
+      |   | . |   | . |   | . |   | . |
+      |---|---|---|---|---|---|---|---|
+      | . |   | . |   | . |   | . |   |
+      |---|---|---|---|---|---|---|---|
+      |   | . |   | . |   | . |   | . |
+      |---|---|---|---|---|---|---|---|
+      | . |   | . |   | . |   | . |   |
+      |---|---|---|---|---|---|---|---|
+      | P | P | P | P | P | P | P | P |
+      |---|---|---|---|---|---|---|---|
+      | R | N | B | Q | K | B | N | R |   -- this square is "white"
+      |---|---|---|---|---|---|---|---|
+ 
+ 
+
+Article 3:    The Right To Move 
+----------    -----------------    
+
+ 3.1  The player with the white pieces commences the game. The players
+      alternate in making one move at a time until the game is completed. 
+      
+ 3.2  A player is said to  "have the move" when his opponent's move 
+      has been completed.
+
+ 
+
+Article 4:    The General Definition Of The Move    
+----------    ----------------------------------
+ 
+ 4.1  With the exception of castling (Article 5.1(b)), a move is the
+      transfer by a player of one of his pieces from one square to 
+      another square, which is either vacant or occupied by an opponent's 
+      piece. 
+      [A capture is, therefore, merely a certain type of move.] 
+
+ 4.2  No piece, except the rook when castling (Article 5.1(b)) and the
+      knight (Article 5.5), may cross a square occupied by another piece.
+
+ 4.3  A piece played to a square occupied by an opponent's piece captures 
+      it as part of the same move. The captured piece must be removed
+      immediately from the chessboard by the player making the capture 
+      (see Article 5.6(c) for capturing "en passant").
+
+ 
+
+Article 5:    The Moves Of The Pieces     
+----------    -----------------------
+ 
+ 5.1  The King:
+      (a)  Except when castling, the king moves to any adjoining square 
+           that is not attacked by an opponent's piece.
+      (b)  Castling is a move of the king and either rook, counting as a
+           single move of the king and executed as follows: the king is
+           transferred from its original square two squares toward either 
+           rook on the same rank; then that rook is transferred over the 
+           king to the square the king has just crossed.
+      (c)  If a player touches a rook and then his king, he may not castle 
+           with that rook and the situation will by governed by Articles 
+           7.2 and 7.3 [Touched Piece rules].
+      (d)  If a player, intending to castle, touches the king first, or
+           king and rook at the same time, and it then appears that castling 
+           is illegal, the player may choose either to move his king or to 
+           castle on the other side, provided that castling on that side is 
+           legal. If the king has no legal move, the player is free to make 
+           any legal move.
+      (e)  Castling is [permanently] illegal:
+           (i)  if the king has already been moved; or
+          (ii)  with a rook that has already been moved.
+      (f)  Castling is prevented for the time being:
+           (i)  if the king's original square, or the square which the king 
+                must pass over, or that which it is to occupy, is attacked 
+                by an  opponent's piece; or
+          (ii)  if there is any piece between the king and the rook with
+                which castling is to be effected [i.e. castling may still 
+                be legal even if the rook is attacked or, when castling 
+                queenside, passes over an attacked square] .
+
+ 5.2  The Queen.
+      The queen moves to any square (except as limited by Article 4.2)
+      [No leapfrogging]  on the file, rank, or diagonals on which it stands.
+
+ 5.3  The Rook.
+      The rook moves to any square (except as limited by Article 4.2) on the 
+      file or rank on which it stands.
+
+ 5.4  The Bishop.
+      The bishop moves to any square (except as limited by Article 4.2) on 
+      the diagonals on which it stands.
+
+ 5.5  The Knight.
+      The knight's move is composed of two different steps; first, it makes
+      one step of one single square along its rank or file, and then, still
+      moving away from the square of departure, one step of one single
+      square on a diagonal. It does not matter if the square of the first
+      step is occupied.
+
+ 5.6  The Pawn.
+      (a)  The pawn may move only forward [except as limited by Article 4.2].
+      (b)  Except when making a capture, it advances from its original 
+           square either one or two vacant squares along the file on which 
+           it is placed, and on subsequent moves it advances one vacant 
+           square along the file. When capturing, it advances one square 
+           along either of the diagonals on which it stands.
+      (c)  A pawn, attacking a square crossed by an opponent's pawn which
+           has  [just]  been advanced two squares in one move from its 
+           original square, may capture this opponent's pawn as though the 
+           latter had been moved only one square. This capture may only be 
+           made in [immediate] reply to such an advance, and is called an     
+           "en passant"  capture.
+      (d)  On reaching the last rank, a pawn must immediately be exchanged, 
+           as part of the same move, for [either] a queen, a rook, a bishop, 
+           or a knight, of the same colour as the pawn, at the player's 
+           choice and without taking into account the other pieces still 
+           remaining on the chessboard. This exchange of a pawn for another 
+           piece is called  "promotion", and the effect of the promoted 
+           piece is immediate [and permanent!].
+      (e)  In a competition, if a new piece required for the promotion is 
+           not immediately available, the player may stop his clock to ask 
+           for the assistance of the arbiter. The player must complete his 
+           move correctly, in the manner specified in Article 5.6(d).
+
+ 
+
+Article 6:    The Completion Of The Move    
+----------    --------------------------
+ 
+      A move is completed:
+
+ 6.1  in the case of the transfer of a piece to a vacant square, when 
+      the player's hand has released the piece;
+
+ 6.2  in the case of a capture, when the captured piece has been removed
+      from the chessboard and the player, having placed his own piece on 
+      its new square, has released this [capturing] piece from his hand;
+
+ 6.3  in the case of castling, when the player's hand has released the 
+      rook on the square [previously] crossed by the king. When the player 
+      has released the king from his hand, the move is not yet completed, 
+      but the player no longer has the right to make any move other than 
+      castling on that side, if this is legal;
+
+ 6.4  in the case of the promotion of a pawn, when the pawn has been
+      removed from the chessboard and the player's hand has released the 
+      new piece after placing it on the promotion square. If the player 
+      has released from his hand the pawn that has reached the promotion 
+      square, the move is not yet completed, but the player no longer has 
+      the right to play the pawn to another square.
+
+ 6.5  When determining whether the prescribed number of moves has been made 
+      in the allotted time, the last move is not considered complete until 
+      after the player has stopped his clock. This applies to all situations 
+      except those governed by Articles 10.1, 10.2, 10.3, 10.4 and 10.6. 
+      [i.e. when the move has been completed in the sense of Articles 6.1-6.4, 
+      and the game ends immediately after the move in question, which may, 
+      for example, put the player's opponent into checkmate. This Law was 
+      introduced to prevent the situation where a player returns to the board 
+      to claim a win on time, possibly an hour after being checkmated!] .
+
+ 
+
+Article 7:    The Touched Piece 
+----------    ----------------- 
+
+ 7.1  Provided that he first expresses his intention (e.g. by saying
+      "j'adoube"), the player having the move may adjust one or more pieces 
+      on their squares.    
+      [If a player's opponent is absent from the chessboard, it is best to 
+      inform one of his team-mates, or some other witness.] 
+
+ 7.2  Except for the above case, if the player having the move deliberately 
+      touches on the board:
+      (a)  one or more pieces of the same colour, he must move or capture
+           the first piece he touched that can be moved or captured; or
+      (b)  one of his own pieces and one of his opponent's pieces, he must
+           capture his opponent's piece with his own piece; or, if this is 
+           illegal, move or capture the first piece he touched that can be 
+           moved or captured. If it is impossible to establish which piece 
+           was touched first, the player's piece shall be considered the 
+           touched piece.
+
+ 7.3  If none of the touched pieces has a legal move (or if none of the
+      opponent's pieces which were touched can be captured legally), the 
+      player is free to make any legal move.
+
+ 7.4  If a player wishes to claim that his opponent has violated Article
+      7.2, he must do so before he himself touches a piece.
+      [Note that the clause "deliberately touches" protects a player from 
+      having to move a piece accidentally touched by his elbow/wrist etc] 
+
+ 
+
+Article 8:    Illegal Positions 
+----------    -----------------
+
+ 8.1  If, during a game, it is found that an illegal move was made, the
+      position shall be reinstated to what it was before the illegal move 
+      was made. The game shall then continue by applying the rules of 
+      Article 7 to the move replacing the illegal move. If the position 
+      cannot be reinstated, the game shall be annulled and a new game 
+      played. This applies to all sessions of play, and to a game awaiting 
+      a decision by adjudication.    
+      [Note that this discovery of an illegal move must be made while the 
+      game is still in progress, before resignation or the agreement of a 
+      draw. The only possible exception can be if the illegal move itself 
+      would theoretically end the game: anyone trying the trick 1. e2-e4 
+      e7-e5; 2. Bf1-c4 Ng8-f6; 3. Qd1xf7 "mate" may be penalised under 
+      Article 10.17! Note that the act of playing an illegal move, at ANY 
+      stage of the game, does not IN ITSELF forfeit the game.] 
+
+ 8.2  If, during a game, one or more pieces have been accidentally
+      displaced and incorrectly replaced, the position before the 
+      displacement occurred shall be reinstated, and the game shall 
+      continue. If the position cannot be reinstated, the game shall be 
+      annulled and a new game played.
+
+ 8.3  If a player moves and in the course of this inadvertently knocks 
+      over a piece, or several pieces, he must re-establish the position 
+      in his own time. 
+
+ 8.4  If, after an adjournment, the position is incorrectly set up, the 
+      position as it was on adjournment must be set up again and the game 
+      continued. 
+
+ 8.5  If, during a game, it is found that the initial position of the 
+      pieces was incorrect, the game shall be annulled and a new game played.
+
+ 8.6  If a game has begun with colours incorrectly reversed, then it shall 
+      continue if more than one quarter of the time allocated to both 
+      players to the first time control has elapsed. Earlier, the arbiter 
+      can arrange for a new game to start with the correct colours, if the 
+      event's timetable is not excessively disrupted. 
+
+ 8.7  If, during a game, it is found that the board has been placed contrary 
+      to Article 1.2, the position reached should be transferred to a
+      correctly-placed board, and the game continued. 
+      [In the situations covered by Articles 8.5-8.7, a spectator is 
+      justified in pointing out to the arbiter the error he has noticed. 
+      In Article 8.7, the implicit assumption is that the relative 
+      positions of the pieces relative to one another were correct] .
+
+ 
+
+Article 9:    Check   
+----------    -----   
+
+ 9.1  The king is in "check" when the square it occupies is attacked by 
+      one or more of the opponent's pieces; in this case, the latter is/are 
+      said to be  "checking" the king. A player may not make a move which 
+      leaves his king on a square attacked by any of his opponent's pieces.
+
+ 9.2  Check must be parried by the move immediately following. If any check 
+      cannot be parried, the king is said to be "checkmated" ("mated").
+ 9.3  Declaring a check is not obligatory. 
+      [Merely polite! Playing an illegal move does not imply the loss of 
+      the game: see Article 8.1.] 
+
+ 
+ 
+Article 10:    The Completed Game  
+-----------    ------------------
+ 
+10.1  The game is won by the player who has checkmated his opponent's 
+      king. This immediately ends the game.
+
+10.2  The game is won by the player whose opponent declares he resigns.
+      This immediately ends the game.
+
+10.3  The game is drawn when the king of the player who has the move is 
+      not in check, and this player cannot make any legal move. The player's 
+      king is then said to be "stalemated". This immediately ends the game. 
+      [If the stalemating move was actually legal!] .
+
+10.4  The game is drawn when one of the following endings arises:
+      (a)  king against king;
+      (b)  king against king with only bishop or knight;
+      (c)  king and bishop against king and bishop, with both bishops 
+           on diagonals of the same colour.
+      This immediately ends the game.
+
+10.5  A player having a bare king cannot win the game. A draw shall be 
+      declared if the opponent of a player with a bare king oversteps the 
+      time limit (Articles 10.13 and 10.14) or seals an illegal move 
+      (Articles 10.16).
+
+10.6  The game is drawn upon agreement between the two players. This 
+      immediately ends the game.
+
+10.7  A proposal of a draw under the provisions of Article 10.6 may be
+      made by a player only at the moment when he has just moved a piece. 
+      On then proposing a draw, he starts the clock of his opponent. The 
+      latter may accept the proposal, which is always to be taken as 
+      unconditional, or he may reject it either orally or by completing a 
+      move. A draw offer is valid until the opponent has accepted or 
+      rejected it.
+      [The gamesmanship question "Are you playing for a win?" can be 
+      considered as an offer of a draw] .
+
+10.8  If a player proposes a draw while his opponent's clock is running 
+      and his opponent is contemplating his move, the opponent may still 
+      agree to the draw or reject the offer. A player who offers a draw 
+      in this manner may be penalised by the arbiter.
+
+10.9  If a player proposes a draw while his own clock is running or after 
+      his move has been sealed, the opponent may postpone his decision 
+      until after he has seen the first player's move. 
+
+10.10 The game is drawn, upon a claim by the player having the move, when 
+      the same position, for the third time:
+      (a)  is about to appear, if he first writes the move on his scoresheet 
+           and declares to the arbiter his intention of making this move; or 
+      (b)  has just appeared, the same player having the move each time. 
+      The position is considered the same if pieces of the same kind and 
+      colour occupy the same squares, and if all the possible moves of all 
+      the pieces are the same, including the rights to castle [at some 
+      future time] or to capture a pawn "en passant".
+
+10.11 If a player executes a move without having claimed a draw for one 
+      of the reasons stated in Article 10.10, he loses the right to claim 
+      a draw. This right is restored to him, however, if the same position    
+      [later] appears again, the same player having the move.
+
+10.12 The game is drawn when a player having the move claims a draw and 
+      demonstrates that at least [the last?] 50 consecutive moves have been 
+      made by each side without the capture of any piece and without the 
+      movement of any pawn. This number of 50 moves can be increased for 
+      certain positions, provided that this increase in number and these 
+      positions have been clearly announced by the organisers before the 
+      event starts.
+      [The claim then proceeds according to 10.13. The most extreme case 
+      yet known of a position which might take more than 50 moves to win is
+      king, rook and bishop against king and two knights, which can run for 
+      223 moves between captures!] 
+
+10.13 If a player claims a draw under the provisions of Articles 10.10 
+      and/or 10.12, the arbiter must first stop the clocks while the claim 
+      is being investigated. In the absence of the arbiter, a player may
+      stop both clocks to seek the arbiter's assistance.
+      (a)  If the claim is found to be correct, the game is drawn.
+      (b)  If the claim is found to be incorrect, the arbiter shall then 
+           add five minutes to the claimant's used time. If this means that 
+           the claimant has [now] overstepped the time limit, his game will 
+           be declared lost. Otherwise, the game will be continued, and a 
+           player who has indicated a move according to Article 10.10(a) is 
+           obliged to execute this move on the chessboard.
+      (c)  A player who has made a claim under these Articles cannot 
+           withdraw the claim.
+
+10.14 The game is lost by a player who has not completed the prescribed
+      number of moves in the allotted time, unless his opponent has only 
+      the king remaining, in which case the game is drawn. (See Articles 6.5 
+      and 10.5.)
+      [Situations when Articles 10.1-10.4 or 10.6 apply are the only other 
+      exceptions.] 
+
+10.15 The game is lost by a player who arrives at the chessboard more than 
+      one hour late, for the beginning of the game or for the resumption of
+      an adjourned game. The time of delay is counted from the [scheduled]  
+      start of the playing session. However, in the case of an adjourned 
+      game, if the player who made the sealed move is the late player, the 
+      game is decided otherwise if:
+      (a)  the absent player has won the game by virtue of the fact that 
+           the  sealed move is checkmate; or
+      (b)  the absent player has produced a drawn game by virtue of the
+           fact that the sealed move is stalemate, or if one of the 
+           positions in Article 10.4 has arisen as a consequence of the 
+           sealed move; or
+      (c)  the player present at the chessboard has lost the game according 
+           to Article 10.14 by exceeding his time limit.
+
+10.16 At the resumption, the game is lost by a player whose recording
+      of his sealed move:
+      (a)  is ambiguous; or
+      (b)  would result in a false move the true significance of which is 
+           impossible to establish; or 
+      (c)  would result in an illegal move.
+
+10.17 The game is lost by a player who, during the game, refuses to comply 
+      with the Laws. If both players refuse to comply with the Laws, or if 
+      both players arrive at the chessboard more than one hour late, the 
+      game shall be declared lost by both players.
+
+ 
+
+Article 11:    The Recording Of Games    
+-----------    ----------------------
+ 
+11.1  In the course of play, each player is required to record the game
+      (his own moves and those of his opponent), move after move, as 
+      clearly and legibly as possible in the Algebraic Notation, on the 
+      scoresheet prescribed for the competition. It is irrelevant whether 
+      the player first makes his move and then records it, or vice versa.
+      [The use of Descriptive Notation or foreign versions of Algebraic 
+      Notation is tolerated in internal tournaments, e.g. weekend
+      congresses.] 
+
+11.2  If a player has less than five minutes on his clock until the time
+      control, he is not obliged to meet the requirements of Article 11.1. 
+      As soon as the special device (e.g. the flag) on the clock indicates 
+      the end of his allotted time, the player must immediately complete 
+      his record of the game by filling in the moves omitted from his 
+      scoresheet. 
+      [A player may be justified in restarting his opponent's clock, 
+      without having to make a move, if his opponent has more than 5 minutes 
+      left and is not fulfilling the requirements of Article 11.1. A player 
+      cannot stop his clock unless he has recorded at least his opponent's
+      last move and all previous moves of the game.] 
+
+11.3  If both players cannot keep score, the arbiter, or his deputy, must 
+      endeavour to be present and keep score. The arbiter must not intervene 
+      unless one flag falls, and until then he should not indicate in any 
+      manner to the players how many moves have been made.
+
+11.4  If Article 11.2 does not apply, and a player refuses to record the
+      game according to Article 11.1, then Article 10.17 should be applied
+      [Failure to comply with the Laws of Chess]. 
+
+11.5  If a player does not refuse to comply with the arbiter's request for 
+      a completed scoresheet, but declares that he cannot complete his 
+      scoresheet without consulting his opponent's, the request for this 
+      scoresheet must be made to the arbiter, who will determine whether 
+      the scoresheet can be completed before the time-control without 
+      inconveniencing the other player. The latter cannot refuse his 
+      scoresheet, because the scoresheet belongs to the organisers and the 
+      reconstruction will be made in his opponent's time. In all other 
+      cases, the scoresheets can be completed only after the time-control.
+
+11.6  If, after the time-control, one player alone has to complete his
+      scoresheet, he will do so before making another move, and with his 
+      clock running if his opponent has moved.
+
+11.7  If, after the time-control, both players need to complete their
+      scoresheets, both clocks will be stopped until the two scoresheets 
+      are completed, if necessary with the help of the arbiter's scoresheet 
+      and/or a chessboard under the control of the arbiter, who should have 
+      recorded the actual game position beforehand. 
+      [In case this position gets disturbed!] 
+
+11.8  If, in Article 11.6, the arbiter sees that the scoresheets alone cannot 
+      help in the reconstruction of the game, he will act as in Article 11.7.
+
+11.9  If it proves impossible to reconstruct the moves as prescribed under 
+      Article 11.7, the game shall continue. In this case, the next move
+      played will be considered to be the first one of the following 
+      time-control.
+
+ 
+
+Article 12:    The Chess Clock
+-----------    ---------------    
+
+12.1  Each player must make a certain number of moves in an allotted period 
+      of time, these two factors being specified in advance. The time saved 
+      by a player during one period is added to his time available for the 
+      next period.
+
+12.2  Control of each player's time is effected by means of a clock
+      equipped with a flag (or other special device) for this purpose. 
+      The flag is considered to have fallen when the arbiter observes 
+      the fact, or when the arbiter determines that the allotted time 
+      has been exceeded, even though the flag, because of a defect, 
+      has not fallen when the end of the minute hand has passed the 
+      end of the flag. In cases where no arbiter is present, the flag 
+      is considered to have fallen when a claim to that effect has been 
+      made by a player.
+
+12.3  At the time determined for the start of the game, the clock of the 
+      player who has the white pieces is started. During the game, each 
+      of the players, having completed his move, stops his own clock and 
+      starts his opponent's clock.
+
+12.4  Every indication given by a clock is considered to be conclusive
+      in the absence of evident defects. A player who wishes to claim 
+      any such defect must do so as soon as he himself has become aware 
+      of it, but not later than immediately after his flag has fallen 
+      at the time-control. A clock with an obvious defect should be 
+      replaced, and the time used by each player up to the time the 
+      game was interrupted should be indicated on the new clock as 
+      accurately as possible. The arbiter shall use his best judgment 
+      in determining what times shall be shown on the new clock. If 
+      the arbiter decides to add time used to the clock of one or both 
+      of the players, he shall under no circumstances (except as provided 
+      for in Article 10.13(b)) leave a player with:
+      (a)  less than five minutes to the time-control; or
+      (b)  less than one minute for every move to the time-control.
+
+12.5  If the game needs to be interrupted for some reason which requires
+      action by the arbiter, the clocks shall be stopped by the arbiter. 
+      This should be done, for example, in the case of an illegal position 
+      being corrected, in the case of a defective clock being changed, or 
+      if the piece which a player has declared he wishes to exchange for 
+      a promoted pawn is not immediately available, or to claim a draw by 
+      repetitions of position or under the 50 moves rule. If the arbiter 
+      is not present, a player may stop both clocks in order to seek the 
+      arbiter's assistance.
+
+12.6  In the case of Articles 8.1 and 8.2 [Illegal Positions], when it is 
+      not possible to determine the exact time used by each player up to 
+      the moment when the irregularity occurred, each player shall be 
+      allotted up to that moment a time proportional to that indicated by 
+      the clock when the irregularity was ascertained. 
+      For example, after Black's 30th move it is found that an irregularity 
+      took place at the 20th move. For these 30 moves, the clock shows 90 
+      minutes for White and 60 minutes for Black, so it is assumed that the 
+      times used by the two players for the first 20 moves were as follows:  
+      for White:   90 x 20/30 = 60 minutes
+      for Black:   60 x 20/30 = 40 minutes  
+      This rule must not be used to leave a player with less than five
+      minutes to the time control, or less than one minute for every move 
+      to the time control. (The most common occasion when this problem 
+      arises is immediately after an adjournment, when the clock times can 
+      be most easily adjusted using the times on the sealed move envelope.)
+
+12.7  A resignation or an agreement to draw (Articles 10.2 and 10.4) 
+      remains valid even if it is found later that a flag had fallen.
+
+12.8  If both flags have fallen at virtually the same time [or if both 
+      have fallen before a claim is made by either player] and the arbiter 
+      is unable to establish clearly which flag fell first, the game shall 
+      continue. In this case, if the scoresheets cannot be brought up to 
+      date showing that the time control has been passed, the next move 
+      played will be considered to be the first one of the following 
+      time-control.
+
+12.9  The arbiter [and everyone else, for that matter] shall refrain from 
+      calling a player's attention to the fact that his opponent has made a 
+      move or that the player has forgotten to stop his clock after he has 
+      made a move, or informing the player how many moves he has made, etc.
+
+ 
+
+Article 13:    The Adjournment Of The Game    
+-----------    ---------------------------
+ 
+13.1  (a)  If a game is not finished at the end of the time prescribed 
+           for play, the player having the move must write his move in 
+           unambiguous notation on his scoresheet, put his scoresheet and 
+           that of his opponent in an envelope, seal the envelope, and 
+           only then stop his clock without starting his opponent's clock. 
+           Until he has stopped the clocks, the player retains the right 
+           to change his sealed move. If, after being told by the arbiter 
+           to seal his move, the player makes a move on the chessboard, he 
+           must write that same move on his scoresheet as his sealed move.
+      (b)  A player having the move who adjourns the game before the end 
+           of the playing session will have added to the used time on his 
+           clock the whole of the remaining time to the end of the session.
+
+13.2  Upon the envelope shall be indicated:
+      (a)  the names of the players;
+      (b)  the position immediately before the sealed move;
+      (c)  the time used by each player;
+      (d)  the name of the player who has sealed the move; and
+      (e)  the number of the sealed move.
+
+13.3  The arbiter is responsible for the safekeeping of the envelope
+      and should check the accuracy of the information on it.
+
+ 
+
+Article 14:    The Resumption of the Adjourned Game   
+-----------    ------------------------------------
+ 
+14.1  When the game is resumed, the position immediately before the sealed 
+      move shall be set up on the chessboard, and the time used by each 
+      player when the game was adjourned shall be indicated on the clocks.
+
+
+14.2  The envelope shall be opened only when the player who must reply to 
+      the sealed move is present. This player's clock shall be started 
+      after the sealed move has been made on the chessboard.
+      (a)  If two players have agreed to a draw and announce their decision 
+           to the arbiter; or
+      (b)  if one of the players in an adjourned game notifies the arbiter 
+           that he resigns and it is found, when the envelope has been
+           opened, that the sealed move is invalid according to Article 
+           10.16, then in (a) the draw stands and in (b) the resignation 
+           is still valid.
+
+14.3  If the player having to respond to the sealed move is absent, his 
+      clock shall be started but the envelope containing the sealed move 
+      shall be opened only when he arrives. The player's clock shall then 
+      be stopped and restarted after the sealed move has been played on 
+      the chessboard.
+
+14.4  If the player who has sealed the move is absent, the player having 
+      the move is not obliged to reply to the sealed move on the chessboard.
+      He has the right to record his move in reply on his scoresheet, to 
+      seal the scoresheet in an envelope, to stop his clock and start his 
+      opponent's clock. The envelope should then be put into safekeeping 
+      and opened on the opponent's arrival.
+
+14.5  If the envelope containing the move recorded in accordance with 
+      Article 13 has disappeared:
+      (a)  the game shall be resumed from the position at the time of 
+           adjournment and with the clock times recorded at the time of 
+           adjournment;
+      (b)  if it is impossible to re-establish the position, the game is 
+           annulled and a new game must be played;
+      (c)  if the time used at the time of the adjournment cannot be
+           re-established, this question is decided by the arbiter. The 
+           player who sealed the move makes it on the board.  
+
+14.6  If, upon resumption of the game, the time used has been incorrectly 
+      indicated on either clock, and if either player points this out 
+      before making his first move, the error must be corrected. If the 
+      error is not so established, the game continues without correction, 
+      unless the arbiter feels that the consequences will be too severe.
+
+14.7  The duration of each resumption session shall be controlled by the 
+      wall clock, with the starting time and the finishing time announced 
+      in advance.
+
+ 
+
+Article 15:    The Conduct Of The Players   
+-----------    --------------------------
+ 
+15.1  Prohibitions:
+      (a)  During play, the players are forbidden to make use of 
+           hand-written, printed or otherwise recorded matter, or to 
+           analyse the game on another chessboard. They are also forbidden 
+           to have recourse to the advice of a third party, whether 
+           solicited or not. 
+           [The only possible exception is that a player in a team
+           competition may be allowed to ask his captain  "Should I accept 
+           his offer of a draw?" or  "Does the team need me to play for a 
+           win?". The captain or acting-captain must limit his reply to an 
+           immediate  "Yes",  "No", or  "It's up to you", without supplying 
+           his answer after a detailed analysis of the position, and without 
+           making his answer emphatic in any way. This captain, like all his 
+           players, is not allowed to receive opinions, from any source, on 
+           the states of play of any games still in progress] .
+      (b)  The use of notes made during the game as an aid to memory is 
+           also forbidden, aside from the actual recording of the moves 
+           and the times on the clocks.
+      (c)  No analysis is permitted in the playing rooms during play or 
+           during resumption sessions.
+      (d)  It is forbidden to distract or annoy the opponent in any manner 
+           whatsoever. This includes the persistent offering of a draw.
+
+15.2  Infractions of the rules indicated in Article 15.1 may incur penalties 
+      even to the extent of the loss of the game (see Article 16.5).
+
+ 
+
+Article 16:    The Arbiter 
+-----------    -----------
+
+      An arbiter should be designated to control the competition. His 
+      duties are:
+
+16.1  to see that the Laws are strictly observed;
+
+16.2  to supervise the progress of the competition, to establish that the 
+      prescribed time-limit has not been exceeded by the players, to arrange
+      the order of resumption of play of adjourned games, to see that the 
+      arrangements contained in Article 13 are observed (i.e. to see that 
+      the information on the envelope is correct), to keep the sealed-move 
+      envelope until the resumption of the adjourned game, etc;
+      
+16.3  to enforce the decisions he may make in disputes that have arisen 
+      during the course of the competition;
+
+16.4  to act in the best interests of the competition to ensure that a good 
+      playing environment is maintained and that the players are not 
+      disturbed by each other or by the audience;
+
+16.5  to impose penalties on the players for any fault or infraction of 
+      the Laws. These penalties may include a warning, a time penalty 
+      (by adding to the player's used time or to his opponent's unused time) 
+      or even the loss of the game.
+
+ 
+
+Article 17:    Scoring   
+-----------    -------  
+
+      For a won game, the winner gets 1 (one) point and the loser 0 (zero).
+      For a draw, each player gets   (half) a point.
+
+ 
+
+Article 18:    The Interpretation of the Laws    
+-----------    ------------------------------
+ 
+      In case of doubts as to the application or interpretation of the Laws, 
+      F.I.D.E. will examine the evidence and render official decisions. 
+      Rulings published are binding on all affiliated federations. All 
+      proposals and questions about interpretations should be submitted by 
+      member federations, with complete data.
+
+ 
+
+Article 19:    Validity   
+-----------    --------
+
+      This English text is slightly modified from the authentic version 
+      of the Laws of chess, as adopted by the 1984 F.I.D.E. Congress, and  
+      subsequently amended by the 1988 and 1992 F.I.D.E. Congresses. These 
+      Laws took effect from 1 January 1993.
+
+ 
+
+
+-- 
+Steve Rix,
+Department of Chemical Engineering, University of Edinburgh. 
+E-mail: [email protected],   phone: +44 (31) 650 8565.
diff --git a/rules and standards/FiftyMoveRule b/rules and standards/FiftyMoveRule
new file mode 100755
index 0000000..cbc465e
--- /dev/null
+++ b/rules and standards/FiftyMoveRule
@@ -0,0 +1,39 @@
+From: [email protected] (Hanon W. Russell)
+Newsgroups: rec.games.chess
+Subject: History of the 50-move rule
+Date: Wed, 25 Nov 1992
+
+
+A reader has inquired about the history of the 50-move rule,
+wondering if the move was put into effect in response to a
+"proof" in the 1930's that allegedly demonstrated that without
+the rule, infinitely long games were possible (we assume that
+this implied the best possible moves by both sides). Although
+we are decidedly non-mathematical (we are known to break out
+with severe cravings for ice cream and and hot fudge when
+subjected even to the threat of exposure to math books) we
+undertook a bit of historical research. The source, the newly
+released second edition of Whyld and Hooper's magnificent
+tome "The Oxford Companion to Chess" (which by the way, shall
+be duly reviewed here, possible when we finish this hot fudge
+sundae...)
+
+>From OCC: "The law existed in shatranj [whose golden age was
+the 8th-9th centuries, A.D.- HWR] as a 70-move version, and
+since then the intention has always been the same, that is, to
+counter the obstinacy of one who continues playing in an unwinnable
+position. In 1561 Ruy Lopez said that 50 moves was enough, but 
+Carrera thought this too generous and that 24 moves was right. On
+the other hand LaBourdonnais argued for 60 moves. By the 19th
+century a request for a count could be made only in specific
+endgames (not always the same in the various sets of laws). The
+count began only when the claim was made and was not annulled
+by a capture or a pawn move. Anomalies could arise such as if
+the queen were captured near the end of a 50-move count in an
+endgame K+Q v. K+R the result would still be a draw if mate was
+not effected in the remainder of the fifty moves. The laws used
+at London 1883 tournament stated that a pawn move or a capture
+annulled the count, but did not offer retrospective counting when
+the claim was first made."
+
+HWR
diff --git a/rules and standards/PGN-Standard b/rules and standards/PGN-Standard
new file mode 100644
index 0000000..07149fd
--- /dev/null
+++ b/rules and standards/PGN-Standard
@@ -0,0 +1,2921 @@
+Standard: Portable Game Notation Specification and Implementation Guide
+
+Revised: 1994.03.12
+
+Authors: Interested readers of the Internet newsgroup rec.games.chess
+
+Coordinator: Steven J. Edwards (send comments to [email protected])
+
+
+0: Preface
+
+From the Tower of Babel story:
+
+"If now, while they are one people, all speaking the same language, they have
+started to do this, nothing will later stop them from doing whatever they
+propose to do."
+
+Genesis XI, v.6, _New American Bible_
+
+
+1: Introduction
+
+PGN is "Portable Game Notation", a standard designed for the representation of
+chess game data using ASCII text files.  PGN is structured for easy reading and
+writing by human users and for easy parsing and generation by computer
+programs.  The intent of the definition and propagation of PGN is to facilitate
+the sharing of public domain chess game data among chessplayers (both organic
+and otherwise), publishers, and computer chess researchers throughout the
+world.
+
+PGN is not intended to be a general purpose standard that is suitable for every
+possible use; no such standard could fill all conceivable requirements.
+Instead, PGN is proposed as a universal portable representation for data
+interchange.  The idea is to allow the construction of a family of chess
+applications that can quickly and easily process chess game data using PGN for
+import and export among themselves.
+
+
+2: Chess data representation
+
+Computer usage among chessplayers has become quite common in recent years and a
+variety of different programs, both commercial and public domain, are used to
+generate, access, and propagate chess game data.  Some of these programs are
+rather impressive; most are now well behaved in that they correctly follow the
+Laws of Chess and handle users' data with reasonable care.  Unfortunately, many
+programs have had serious problems with several aspects of the external
+representation of chess game data.  Sometimes these problems become more
+visible when a user attempts to move significant quantities of data from one
+program to another; if there has been no real effort to ensure portability of
+data, then the chances for a successful transfer are small at best.
+
+
+2.1: Data interchange incompatibility
+
+The reasons for format incompatibility are easy to understand.  In fact, most
+of them are correlated with the same problems that have already been seen with
+commercial software offerings for other domains such as word processing,
+spreadsheets, fonts, and graphics.  Sometimes a manufacturer deliberately
+designs a data format using encryption or some other secret, proprietary
+technique to "lock in" a customer.  Sometimes a designer may produce a format
+that can be deciphered without too much difficulty, but at the same time
+publicly discourage third party software by claiming trade secret protection.
+Another software producer may develop a non-proprietary system, but it may work
+well only within the scope of a single program or application because it is not
+easily expandable.  Finally, some other software may work very well for many
+purposes, but it uses symbols and language not easily understood by people or
+computers available to those outside the country of its development.
+
+
+2.2: Specification goals
+
+A specification for a portable game notation must observe the lessons of
+history and be able to handle probable needs of the future.  The design
+criteria for PGN were selected to meet these needs.  These criteria include:
+
+1) The details of the system must be publicly available and free of unnecessary
+complexity.  Ideally, if the documentation is not available for some reason,
+typical chess software developers and users should be able to understand most
+of the data without the need for third party assistance.
+
+2) The details of the system must be non-proprietary so that users and software
+developers are unrestricted by concerns about infringing on intellectual
+property rights.  The idea is to let chess programmers compete in a free market
+where customers may choose software based on their real needs and not based on
+artificial requirements created by a secret data format.
+
+3) The system must work for a variety of programs.  The format should be such
+that it can be used by chess database programs, chess publishing programs,
+chess server programs, and chessplaying programs without being unnecessarily
+specific to any particular application class.
+
+4) The system must be easily expandable and scalable.  The expansion ability
+must include handling data items that may not exist currently but could be
+expected to emerge in the future.  (Examples: new opening classifications and
+new country names.)  The system should be scalable in that it must not have any
+arbitrary restrictions concerning the quantity of stored data.  Also, planned
+modes of expansion should either preserve earlier databases or at least allow
+for their automatic conversion.
+
+5) The system must be international.  Chess software users are found in many
+countries and the system should be free of difficulties caused by conventions
+local to a given region.
+
+6) Finally, the system should handle the same kinds and amounts of data that
+are already handled by existing chess software and by print media.
+
+
+2.3: A sample PGN game
+
+Although its description may seem rather lengthy, PGN is actually fairly
+simple.  A sample PGN game follows; it has most of the important features
+described in later sections of this document.
+
+[Event "F/S Return Match"]
+[Site "Belgrade, Serbia JUG"]
+[Date "1992.11.04"]
+[Round "29"]
+[White "Fischer, Robert J."]
+[Black "Spassky, Boris V."]
+[Result "1/2-1/2"]
+
+1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3
+O-O 9. h3 Nb8 10. d4 Nbd7 11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15.
+Nb1 h6 16. Bh4 c5 17. dxe5 Nxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21.
+Nc4 Nxc4 22. Bxc4 Nb6 23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7
+27. Qe3 Qg5 28. Qxg5 hxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33.
+f3 Bc8 34. Kf2 Bf5 35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5
+40. Rd6 Kc5 41. Ra6 Nf2 42. g4 Bd3 43. Re6 1/2-1/2
+
+
+3: Formats: import and export
+
+There are two formats in the PGN specification.  These are the "import" format
+and the "export" format.  These are the two different ways of formatting the
+same PGN data according to its source.  The details of the two formats are
+described throughout the following sections of this document.
+
+Other than formats, there is the additional topic of PGN presentation.  While
+both PGN import and export formats are designed to be readable by humans, there
+is no recommendation that either of these be an ultimate mode of chess data
+presentation.  Rather, software developers are urged to consider all of the
+various techniques at their disposal to enhance the display of chess data at
+the presentation level (i.e., highest level) of their programs.  This means
+that the use of different fonts, character sizes, color, and other tools of
+computer aided interaction and publishing should be explored to provide a high
+quality presentation appropriate to the function of the particular program.
+
+
+3.1: Import format allows for manually prepared data
+
+The import format is rather flexible and is used to describe data that may have
+been prepared by hand, much like a source file for a high level programming
+language.  A program that can read PGN data should be able to handle the
+somewhat lax import format.
+
+
+3.2: Export format used for program generated output
+
+The export format is rather strict and is used to describe data that is usually
+prepared under program control, something like a pretty printed source program
+reformatted by a compiler.
+
+
+3.2.1: Byte equivalence
+
+For a given PGN data file, export format representations generated by different
+PGN programs on the same computing system should be exactly equivalent, byte
+for byte.
+
+
+3.2.2: Archival storage and the newline character
+
+Export format should also be used for archival storage.  Here, "archival"
+storage is defined as storage that may be accessed by a variety of computing
+systems.  The only extra requirement for archival storage is that the newline
+character have a specific representation that is independent of its value for a
+particular computing system's text file usage.  The archival representation of
+a newline is the ASCII control character LF (line feed, decimal value 10,
+hexadecimal value 0x0a).
+
+Sadly, there are some accidents of history that survive to this day that have
+baroque representations for a newline: multicharacter sequences, end-of-line
+record markers, start-of-line byte counts, fixed length records, and so forth.
+It is well beyond the scope of the PGN project to reconcile all of these to the
+unified world of ANSI C and the those enjoying the bliss of a single '\n'
+convention.  Some systems may just not be able to handle an archival PGN text
+file with native text editors.  In these cases, an indulgence of sorts is
+granted to use the local newline convention in non-archival PGN files for those
+text editors.
+
+
+3.2.3: Speed of processing
+
+Several parts of the export format deal with exact descriptions of line and
+field justification that are absent from the import format details.  The main
+reason for these restrictions on the export format are to allow the
+construction of simple data translation programs that can easily scan PGN data
+without having to have a full chess engine or other complex parsing routines.
+The idea is to encourage chess software authors to always allow for at least a
+limited PGN reading capability.  Even when a full chess engine parsing
+capability is available, it is likely to be at least two orders of magnitude
+slower than a simple text scanner.
+
+
+3.2.4: Reduced export format
+
+A PGN game represented using export format is said to be in "reduced export
+format" if all of the following hold: 1) it has no commentary, 2) it has only
+the standard seven tag roster identification information ("STR", see below), 3)
+it has no recursive annotation variations ("RAV", see below), and 4) it has no
+numeric annotation glyphs ("NAG", see below).  Reduced export format is used
+for bulk storage of unannotated games.  It represents a minimum level of
+standard conformance for a PGN exporting application.
+
+
+4: Lexicographical issues
+
+PGN data is composed of characters; non-overlapping contiguous sequences of
+characters form lexical tokens.
+
+
+4.1: Character codes
+
+PGN data is represented using a subset of the eight bit ISO 8859/1 (Latin 1)
+character set.  ("ISO" is an acronym for the International Standards
+Organization.)  This set is also known as ECMA-94 and is similar to other ISO
+Latin character sets.  ISO 8859/1 includes the standard seven bit ASCII
+character set for the 32 control character code values from zero to 31.  The 95
+printing character code values from 32 to 126 are also equivalent to seven bit
+ASCII usage.  (Code value 127, the ASCII DEL control character, is a graphic
+character in ISO 8859/1; it is not used for PGN data representation.)
+
+The 32 ISO 8859/1 code values from 128 to 159 are non-printing control
+characters.  They are not used for PGN data representation.  The 32 code values
+from 160 to 191 are mostly non-alphabetic printing characters and their use for
+PGN data is discouraged as their graphic representation varies considerably
+among other ISO Latin sets.  Finally, the 64 code values from 192 to 255 are
+mostly alphabetic printing characters with various diacritical marks; their use
+is encouraged for those languages that require such characters.  The graphic
+representations of this last set of 64 characters is fairly constant for the
+ISO Latin family.
+
+Printing character codes outside of the seven bit ASCII range may only appear
+in string data and in commentary.  They are not permitted for use in symbol
+construction.
+
+Because some PGN users' environments may not support presentation of non-ASCII
+characters, PGN game authors should refrain from using such characters in
+critical commentary or string values in game data that may be referenced in
+such environments.  PGN software authors should have their programs handle such
+environments by displaying a question mark ("?") for non-ASCII character codes.
+This is an important point because there are many computing systems that can
+display eight bit character data, but the display graphics may differ among
+machines and operating systems from different manufacturers.
+
+Only four of the ASCII control characters are permitted in PGN import format;
+these are the horizontal and vertical tabs along with the linefeed and carriage
+return codes.
+
+The external representation of the newline character may differ among
+platforms; this is an acceptable variation as long as the details of the
+implementation are hidden from software implementors and users.  When a choice
+is practical, the Unix "newline is linefeed" convention is preferred.
+
+
+4.2: Tab characters
+
+Tab characters, both horizontal and vertical, are not permitted in the export
+format.  This is because the treatment of tab characters is highly dependent
+upon the particular software in use on the host computing system.  Also, tab
+characters may not appear inside of string data.
+
+
+4.3: Line lengths
+
+PGN data are organized as simple text lines without any special bytes or
+markers for secondary record structure imposed by specific operating systems.
+Import format PGN text lines are limited to having a maximum of 255 characters
+per line including the newline character.  Lines with 80 or more printing
+characters are strongly discouraged because of the difficulties experienced by
+common text editors with long lines.
+
+In some cases, very long tag values will require 80 or more columns, but these
+are relatively rare.  An example of this is the "FEN" tag pair; it may have a
+long tag value, but this particular tag pair is only used to represent a game
+that doesn't start from the usual initial position.
+
+
+5: Commentary
+
+Comment text may appear in PGN data.  There are two kinds of comments.  The
+first kind is the "rest of line" comment; this comment type starts with a
+semicolon character and continues to the end of the line.  The second kind
+starts with a left brace character and continues to the next right brace
+character.  Comments cannot appear inside any token.
+
+Brace comments do not nest; a left brace character appearing in a brace comment
+loses its special meaning and is ignored.  A semicolon appearing inside of a
+brace comment loses its special meaning and is ignored.  Braces appearing
+inside of a semicolon comments lose their special meaning and are ignored.
+
+*** Export format representation of comments needs definition work.
+
+
+6: Escape mechanism
+
+There is a special escape mechanism for PGN data.  This mechanism is triggered
+by a percent sign character ("%") appearing in the first column of a line; the
+data on the rest of the line is ignored by publicly available PGN scanning
+software.  This escape convention is intended for the private use of software
+developers and researchers to embed non-PGN commands and data in PGN streams.
+
+A percent sign appearing in any other place other than the first position in a
+line does not trigger the escape mechanism.
+
+
+7: Tokens
+
+PGN character data is organized as tokens.  A token is a contiguous sequence of
+characters that represents a basic semantic unit.  Tokens may be separated from
+adjacent tokens by white space characters.  (White space characters include
+space, newline, and tab characters.)  Some tokens are self delimiting and do
+not require white space characters.
+
+A string token is a sequence of zero or more printing characters delimited by a
+pair of quote characters (ASCII decimal value 34, hexadecimal value 0x22).  An
+empty string is represented by two adjacent quotes.  (Note: an apostrophe is
+not a quote.)  A quote inside a string is represented by the backslash
+immediately followed by a quote.  A backslash inside a string is represented by
+two adjacent backslashes.  Strings are commonly used as tag pair values (see
+below).  Non-printing characters like newline and tab are not permitted inside
+of strings.  A string token is terminated by its closing quote.  Currently, a
+string is limited to a maximum of 255 characters of data.
+
+An integer token is a sequence of one or more decimal digit characters.  It is
+a special case of the more general "symbol" token class described below.
+Integer tokens are used to help represent move number indications (see below).
+An integer token is terminated just prior to the first non-symbol character
+following the integer digit sequence.
+
+A period character (".") is a token by itself.  It is used for move number
+indications (see below).  It is self terminating.
+
+An asterisk character ("*") is a token by itself.  It is used as one of the
+possible game termination markers (see below); it indicates an incomplete game
+or a game with an unknown or otherwise unavailable result.  It is self
+terminating.
+
+The left and right bracket characters ("[" and "]") are tokens.  They are used
+to delimit tag pairs (see below).  Both are self terminating.
+
+The left and right parenthesis characters ("(" and ")") are tokens.  They are
+used to delimit Recursive Annotation Variations (see below).  Both are self
+terminating.
+
+The left and right angle bracket characters ("<" and ">") are tokens.  They are
+reserved for future expansion.  Both are self terminating.
+
+A Numeric Annotation Glyph ("NAG", see below) is a token; it is composed of a
+dollar sign character ("$") immediately followed by one or more digit
+characters.  It is terminated just prior to the first non-digit character
+following the digit sequence.
+
+A symbol token starts with a letter or digit character and is immediately
+followed by a sequence of zero or more symbol continuation characters.  These
+continuation characters are letter characters ("A-Za-z"), digit characters
+("0-9"), the underscore ("_"), the plus sign ("+"), the octothorpe sign ("#"),
+the equal sign ("="), the colon (":"),  and the hyphen ("-").  Symbols are used
+for a variety of purposes.  All characters in a symbol are significant.  A
+symbol token is terminated just prior to the first non-symbol character
+following the symbol character sequence.  Currently, a symbol is limited to a
+maximum of 255 characters in length.
+
+
+8: Parsing games
+
+A PGN database file is a sequential collection of zero or more PGN games.  An
+empty file is a valid, although somewhat uninformative, PGN database.
+
+A PGN game is composed of two sections.  The first is the tag pair section and
+the second is the movetext section.  The tag pair section provides information
+that identifies the game by defining the values associated with a set of
+standard parameters.  The movetext section gives the usually enumerated and
+possibly annotated moves of the game along with the concluding game termination
+marker.  The chess moves themselves are represented using SAN (Standard
+Algebraic Notation), also described later in this document.
+
+
+8.1: Tag pair section
+
+The tag pair section is composed of a series of zero or more tag pairs.
+
+A tag pair is composed of four consecutive tokens: a left bracket token, a
+symbol token, a string token, and a right bracket token.  The symbol token is
+the tag name and the string token is the tag value associated with the tag
+name.  (There is a standard set of tag names and semantics described below.)
+The same tag name should not appear more than once in a tag pair section.
+
+A further restriction on tag names is that they are composed exclusively of
+letters, digits, and the underscore character.  This is done to facilitate
+mapping of tag names into key and attribute names for use with general purpose
+database programs.
+
+For PGN import format, there may be zero or more white space characters between
+any adjacent pair of tokens in a tag pair.
+
+For PGN export format, there are no white space characters between the left
+bracket and the tag name, there are no white space characters between the tag
+value and the right bracket, and there is a single space character between the
+tag name and the tag value.
+
+Tag names, like all symbols, are case sensitive.  All tag names used for
+archival storage begin with an upper case letter.
+
+PGN import format may have multiple tag pairs on the same line and may even
+have a tag pair spanning more than a single line.  Export format requires each
+tag pair to appear left justified on a line by itself; a single empty line
+follows the last tag pair.
+
+Some tag values may be composed of a sequence of items.  For example, a
+consultation game may have more than one player for a given side.  When this
+occurs, the single character ":" (colon) appears between adjacent items.
+Because of this use as an internal separator in strings, the colon should not
+otherwise appear in a string.
+
+The tag pair format is designed for expansion; initially only strings are
+allowed as tag pair values.  Tag value formats associated with the STR (Seven
+Tag Roster, see below) will not change; they will always be string values.
+However, there are long term plans to allow general list structures as tag
+values for non-STR tag pairs.  Use of these expanded tag values will likely be
+restricted to special research programs.  In all events, the top level
+structure of a tag pair remains the same: left bracket, tag name, tag value,
+and right bracket.
+
+
+8.1.1: Seven Tag Roster
+
+There is a set of tags defined for mandatory use for archival storage of PGN
+data.  This is the STR (Seven Tag Roster).  The interpretation of these tags is
+fixed as is the order in which they appear.  Although the definition and use of
+additional tag names and semantics is permitted and encouraged when needed, the
+STR is the common ground that all programs should follow for public data
+interchange.
+
+For import format, the order of tag pairs is not important.  For export format,
+the STR tag pairs appear before any other tag pairs.  (The STR tag pairs must
+also appear in order; this order is described below).  Also for export format,
+any additional tag pairs appear in ASCII order by tag name.
+
+The seven tag names of the STR are (in order):
+
+1) Event (the name of the tournament or match event)
+
+2) Site (the location of the event)
+
+3) Date (the starting date of the game)
+
+4) Round (the playing round ordinal of the game)
+
+5) White (the player of the white pieces)
+
+6) Black (the player of the black pieces)
+
+7) Result (the result of the game)
+
+A set of supplemental tag names is given later in this document.
+
+For PGN export format, a single blank line appears after the last of the tag
+pairs to conclude the tag pair section.  This helps simple scanning programs to
+quickly determine the end of the tag pair section and the beginning of the
+movetext section.
+
+
+8.1.1.1: The Event tag
+
+The Event tag value should be reasonably descriptive.  Abbreviations are to be
+avoided unless absolutely necessary.  A consistent event naming should be used
+to help facilitate database scanning.  If the name of the event is unknown, a
+single question mark should appear as the tag value.
+
+Examples:
+
+[Event "FIDE World Championship"]
+
+[Event "Moscow City Championship"]
+
+[Event "ACM North American Computer Championship"]
+
+[Event "Casual Game"]
+
+
+8.1.1.2: The Site tag
+
+The Site tag value should include city and region names along with a standard
+name for the country.  The use of the IOC (International Olympic Committee)
+three letter names is suggested for those countries where such codes are
+available.  If the site of the event is unknown, a single question mark should
+appear as the tag value.  A comma may be used to separate a city from a region.
+No comma is needed to separate a city or region from the IOC country code.  A
+later section of this document gives a list of three letter nation codes along
+with a few additions for "locations" not covered by the IOC.
+
+Examples:
+
+[Site "New York City, NY USA"]
+
+[Site "St. Petersburg RUS"]
+
+[Site "Riga LAT"]
+
+
+8.1.1.3: The Date tag
+
+The Date tag value gives the starting date for the game.  (Note: this is not
+necessarily the same as the starting date for the event.)  The date is given
+with respect to the local time of the site given in the Event tag.  The Date
+tag value field always uses a standard ten character format: "YYYY.MM.DD".  The
+first four characters are digits that give the year, the next character is a
+period, the next two characters are digits that give the month, the next
+character is a period, and the final two characters are digits that give the
+day of the month.  If the any of the digit fields are not known, then question
+marks are used in place of the digits.
+
+Examples:
+
+[Date "1992.08.31"]
+
+[Date "1993.??.??"]
+
+[Date "2001.01.01"]
+
+
+8.1.1.4: The Round tag
+
+The Round tag value gives the playing round for the game.  In a match
+competition, this value is the number of the game played.  If the use of a
+round number is inappropriate, then the field should be a single hyphen
+character.  If the round is unknown, a single question mark should appear as
+the tag value.
+
+Some organizers employ unusual round designations and have multipart playing
+rounds and sometimes even have conditional rounds.  In these cases, a multipart
+round identifier can be made from a sequence of integer round numbers separated
+by periods.  The leftmost integer represents the most significant round and
+succeeding integers represent round numbers in descending hierarchical order.
+
+Examples:
+
+[Round "1"]
+
+[Round "3.1"]
+
+[Round "4.1.2"]
+
+
+8.1.1.5: The White tag
+
+The White tag value is the name of the player or players of the white pieces.
+The names are given as they would appear in a telephone directory.  The family
+or last name appears first.  If a first name or first initial is available, it
+is separated from the family name by a comma and a space.  Finally, one or more
+middle initials may appear.  (Wherever a comma appears, the very next character
+should be a space.  Wherever an initial appears, the very next character should
+be a period.)  If the name is unknown, a single question mark should appear as
+the tag value.
+
+The intent is to allow meaningful ASCII sorting of the tag value that is
+independent of regional name formation customs.  If more than one person is
+playing the white pieces, the names are listed in alphabetical order and are
+separated by the colon character between adjacent entries.  A player who is
+also a computer program should have appropriate version information listed
+after the name of the program.
+
+The format used in the FIDE Rating Lists is appropriate for use for player name
+tags.
+
+Examples:
+
+[White "Tal, Mikhail N."]
+
+[White "van der Wiel, Johan"]
+
+[White "Acme Pawngrabber v.3.2"]
+
+[White "Fine, R."]
+
+
+8.1.1.6: The Black tag
+
+The Black tag value is the name of the player or players of the black pieces.
+The names are given here as they are for the White tag value.
+
+Examples:
+
+[Black "Lasker, Emmanuel"]
+
+[Black "Smyslov, Vasily V."]
+
+[Black "Smith, John Q.:Woodpusher 2000"]
+
+[Black "Morphy"]
+
+
+8.1.1.7: The Result tag
+
+The Result field value is the result of the game.  It is always exactly the
+same as the game termination marker that concludes the associated movetext.  It
+is always one of four possible values: "1-0" (White wins), "0-1" (Black wins),
+"1/2-1/2" (drawn game), and "*" (game still in progress, game abandoned, or
+result otherwise unknown).  Note that the digit zero is used in both of the
+first two cases; not the letter "O".
+
+All possible examples:
+
+[Result "0-1"]
+
+[Result "1-0"]
+
+[Result "1/2-1/2"]
+
+[Result "*"]
+
+
+8.2: Movetext section
+
+The movetext section is composed of chess moves, move number indications,
+optional annotations, and a single concluding game termination marker.
+
+Because illegal moves are not real chess moves, they are not permitted in PGN
+movetext.  They may appear in commentary, however.  One would hope that illegal
+moves are relatively rare in games worthy of recording.
+
+
+8.2.1: Movetext line justification
+
+In PGN import format, tokens in the movetext do not require any specific line
+justification.
+
+In PGN export format, tokens in the movetext are placed left justified on
+successive text lines each of which has less than 80 printing characters.  As
+many tokens as possible are placed on a line with the remainder appearing on
+successive lines.  A single space character appears between any two adjacent
+symbol tokens on the same line in the movetext.  As with the tag pair section,
+a single empty line follows the last line of data to conclude the movetext
+section.
+
+Neither the first or the last character on an export format PGN line is a
+space.  (This may change in the case of commentary; this area is currently
+under development.)
+
+
+8.2.2: Movetext move number indications
+
+A move number indication is composed of one or more adjacent digits (an integer
+token) followed by zero or more periods.  The integer portion of the indication
+gives the move number of the immediately following white move (if present) and
+also the immediately following black move (if present).
+
+
+8.2.2.1: Import format move number indications
+
+PGN import format does not require move number indications.  It does not
+prohibit superfluous move number indications anywhere in the movetext as long
+as the move numbers are correct.
+
+PGN import format move number indications may have zero or more period
+characters following the digit sequence that gives the move number; one or more
+white space characters may appear between the digit sequence and the period(s).
+
+
+8.2.2.2: Export format move number indications
+
+There are two export format move number indication formats, one for use
+appearing immediately before a white move element and one for use appearing
+immediately before a black move element.  A white move number indication is
+formed from the integer giving the fullmove number with a single period
+character appended.  A black move number indication is formed from the integer
+giving the fullmove number with three period characters appended.
+
+All white move elements have a preceding move number indication.  A black move
+element has a preceding move number indication only in two cases: first, if
+there is intervening annotation or commentary between the black move and the
+previous white move; and second, if there is no previous white move in the
+special case where a game starts from a position where Black is the active
+player.
+
+There are no other cases where move number indications appear in PGN export
+format.
+
+
+8.2.3: Movetext SAN (Standard Algebraic Notation)
+
+SAN (Standard Algebraic Notation) is a representation standard for chess moves
+using the ASCII Latin alphabet.
+
+Examples of SAN recorded games are found throughout most modern chess
+publications.  SAN as presented in this document uses English language single
+character abbreviations for chess pieces, although this is easily changed in
+the source.  English is chosen over other languages because it appears to be
+the most widely recognized.
+
+An alternative to SAN is FAN (Figurine Algebraic Notation).  FAN uses miniature
+piece icons instead of single letter piece abbreviations.  The two notations
+are otherwise identical.
+
+
+8.2.3.1: Square identification
+
+SAN identifies each of the sixty four squares on the chessboard with a unique
+two character name.  The first character of a square identifier is the file of
+the square; a file is a column of eight squares designated by a single lower
+case letter from "a" (leftmost or queenside) up to and including "h" (rightmost
+or kingside).  The second character of a square identifier is the rank of the
+square; a rank is a row of eight squares designated by a single digit from "1"
+(bottom side [White's first rank]) up to and including "8" (top side [Black's
+first rank]).  The initial squares of some pieces are: white queen rook at a1,
+white king at e1, black queen knight pawn at b7, and black king rook at h8.
+
+
+8.2.3.2: Piece identification
+
+SAN identifies each piece by a single upper case letter.  The standard English
+values: pawn = "P", knight = "N", bishop = "B", rook = "R", queen = "Q", and
+king = "K".
+
+The letter code for a pawn is not used for SAN moves in PGN export format
+movetext.  However, some PGN import software disambiguation code may allow for
+the appearance of pawn letter codes.  Also, pawn and other piece letter codes
+are needed for use in some tag pair and annotation constructs.
+
+It is admittedly a bit chauvinistic to select English piece letters over those
+from other languages.  There is a slight justification in that English is a de
+facto universal second language among most chessplayers and program users.  It
+is probably the best that can be done for now.  A later section of this
+document gives alternative piece letters, but these should be used only for
+local presentation software and not for archival storage or for dynamic
+interchange among programs.
+
+
+8.2.3.3: Basic SAN move construction
+
+A basic SAN move is given by listing the moving piece letter (omitted for
+pawns) followed by the destination square.  Capture moves are denoted by the
+lower case letter "x" immediately prior to the destination square; pawn
+captures include the file letter of the originating square of the capturing
+pawn immediately prior to the "x" character.
+
+SAN kingside castling is indicated by the sequence "O-O"; queenside castling is
+indicated by the sequence "O-O-O".  Note that the upper case letter "O" is
+used, not the digit zero.  The use of a zero character is not only incompatible
+with traditional text practices, but it can also confuse parsing algorithms
+which also have to understand about move numbers and game termination markers.
+Also note that the use of the letter "O" is consistent with the practice of
+having all chess move symbols start with a letter; also, it follows the
+convention that all non-pwn move symbols start with an upper case letter.
+
+En passant captures do not have any special notation; they are formed as if the
+captured pawn were on the capturing pawn's destination square.  Pawn promotions
+are denoted by the equal sign "=" immediately following the destination square
+with a promoted piece letter (indicating one of knight, bishop, rook, or queen)
+immediately following the equal sign.  As above, the piece letter is in upper
+case.
+
+
+8.2.3.4: Disambiguation
+
+In the case of ambiguities (multiple pieces of the same type moving to the same
+square), the first appropriate disambiguating step of the three following steps
+is taken:
+
+First, if the moving pieces can be distinguished by their originating files,
+the originating file letter of the moving piece is inserted immediately after
+the moving piece letter.
+
+Second (when the first step fails), if the moving pieces can be distinguished
+by their originating ranks, the originating rank digit of the moving piece is
+inserted immediately after the moving piece letter.
+
+Third (when both the first and the second steps fail), the two character square
+coordinate of the originating square of the moving piece is inserted
+immediately after the moving piece letter.
+
+Note that the above disambiguation is needed only to distinguish among moves of
+the same piece type to the same square; it is not used to distinguish among
+attacks of the same piece type to the same square.  An example of this would be
+a position with two white knights, one on square c3 and one on square g1 and a
+vacant square e2 with White to move.  Both knights attack square e2, and if
+both could legally move there, then a file disambiguation is needed; the
+(nonchecking) knight moves would be "Nce2" and "Nge2".  However, if the white
+king were at square e1 and a black bishop were at square b4 with a vacant
+square d2 (thus an absolute pin of the white knight at square c3), then only
+one white knight (the one at square g1) could move to square e2: "Ne2".
+
+
+8.2.3.5: Check and checkmate indication characters
+
+If the move is a checking move, the plus sign "+" is appended as a suffix to
+the basic SAN move notation; if the move is a checkmating move, the octothorpe
+sign "#" is appended instead.
+
+Neither the appearance nor the absence of either a check or checkmating
+indicator is used for disambiguation purposes.  This means that if two (or
+more) pieces of the same type can move to the same square the differences in
+checking status of the moves does not allieviate the need for the standard rank
+and file disabiguation described above.  (Note that a difference in checking
+status for the above may occur only in the case of a discovered check.)
+
+Neither the checking or checkmating indicators are considered annotation as
+they do not communicate subjective information.  Therefore, they are
+qualitatively different from move suffix annotations like "!" and "?".
+Subjective move annotations are handled using Numeric Annotation Glyphs as
+described in a later section of this document.
+
+There are no special markings used for double checks or discovered checks.
+
+There are no special markings used for drawing moves.
+
+
+8.2.3.6: SAN move length
+
+SAN moves can be as short as two characters (e.g., "d4"), or as long as seven
+characters (e.g., "Qa6xb7#", "fxg1=Q+").  The average SAN move length seen in
+realistic games is probably just fractionally longer than three characters.  If
+the SAN rules seem complicated, be assured that the earlier notation systems of
+LEN (Long English Notation) and EDN (English Descriptive Notation) are much
+more complex, and that LAN (Long Algebraic Notation, the predecessor of SAN) is
+unnecessarily bulky.
+
+
+8.2.3.7: Import and export SAN
+
+PGN export format always uses the above canonical SAN to represent moves in the
+movetext section of a PGN game.  Import format is somewhat more relaxed and it
+makes allowances for moves that do not conform exactly to the canonical format.
+However, these allowances may differ among different PGN reader programs.  Only
+data appearing in export format is in all cases guaranteed to be importable
+into all PGN readers.
+
+There are a number of suggested guidelines for use with implementing PGN reader
+software for permitting non-canonical SAN move representation.  The idea is to
+have a PGN reader apply various transformations to attempt to discover the move
+that is represented by non-canonical input.  Some suggested transformations
+include: letter case remapping, capture indicator insertion, check indicator
+insertion, and checkmate indicator insertion.
+
+
+8.2.3.8: SAN move suffix annotations
+
+Import format PGN allows for the use of traditional suffix annotations for
+moves.  There are exactly six such annotations available: "!", "?", "!!", "!?",
+"?!", and "??".  At most one such suffix annotation may appear per move, and if
+present, it is always the last part of the move symbol.
+
+When exported, a move suffix annotation is translated into the corresponding
+Numeric Annotation Glyph as described in a later section of this document.  For
+example, if the single move symbol "Qxa8?" appears in an import format PGN
+movetext, it would be replaced with the two adjacent symbols "Qxa8 $2".
+
+
+8.2.4: Movetext NAG (Numeric Annotation Glyph)
+
+An NAG (Numeric Annotation Glyph) is a movetext element that is used to
+indicate a simple annotation in a language independent manner.  An NAG is
+formed from a dollar sign ("$") with a non-negative decimal integer suffix.
+The non-negative integer must be from zero to 255 in value.
+
+
+8.2.5: Movetext RAV (Recursive Annotation Variation)
+
+An RAV (Recursive Annotation Variation) is a sequence of movetext containing
+one or more moves enclosed in parentheses.  An RAV is used to represent an
+alternative variation.  The alternate move sequence given by an RAV is one that
+may be legally played by first unplaying the move that appears immediately
+prior to the RAV.  Because the RAV is a recursive construct, it may be nested.
+
+*** The specification for import/export representation of RAV elements needs
+further development.
+
+
+8.2.6: Game Termination Markers
+
+Each movetext section has exactly one game termination marker; the marker
+always occurs as the last element in the movetext.  The game termination marker
+is a symbol that is one of the following four values: "1-0" (White wins), "0-1"
+(Black wins), "1/2-1/2" (drawn game), and "*" (game in progress, result
+unknown, or game abandoned).  Note that the digit zero is used in the above;
+not the upper case letter "O".  The game termination marker appearing in the
+movetext of a game must match the value of the game's Result tag pair.  (While
+the marker appears as a string in the Result tag, it appears as a symbol
+without quotes in the movetext.)
+
+
+9: Supplemental tag names
+
+The following tag names and their associated semantics are recommended for use
+for information not contained in the Seven Tag Roster.
+
+
+9.1: Player related information
+
+Note that if there is more than one player field in an instance of a player
+(White or Black) tag, then there will be corresponding multiple fields in any
+of the following tags.  For example, if the White tag has the three field value
+"Jones:Smith:Zacharias" (a consultation game), then the WhiteTitle tag could
+have a value of "IM:-:GM" if Jones was an International Master, Smith was
+untitled, and Zacharias was a Grandmaster.
+
+
+9.1.1: Tags: WhiteTitle, BlackTitle
+
+These use string values such as "FM", "IM", and "GM"; these tags are used only
+for the standard abbreviations for FIDE titles.  A value of "-" is used for an
+untitled player.
+
+
+9.1.2: Tags: WhiteElo, BlackElo
+
+These tags use integer values; these are used for FIDE Elo ratings.  A value of
+"-" is used for an unrated player.
+
+
+9.1.3: Tags: WhiteUSCF, BlackUSCF
+
+These tags use integer values; these are used for USCF (United States Chess
+Federation) ratings.  Similar tag names can be constructed for other rating
+agencies.
+
+
+9.1.4: Tags: WhiteNA, BlackNA
+
+These tags use string values; these are the e-mail or network addresses of the
+players.  A value of "-" is used for a player without an electronic address.
+
+
+9.1.5: Tags: WhiteType, BlackType
+
+These tags use string values; these describe the player types.  The value
+"human" should be used for a person while the value "program" should be used
+for algorithmic (computer) players.
+
+
+9.2: Event related information
+
+The following tags are used for providing additional information about the
+event.
+
+
+9.2.1: Tag: EventDate
+
+This uses a date value, similar to the Date tag field, that gives the starting
+date of the Event.
+
+
+9.2.2: Tag: EventSponsor
+
+This uses a string value giving the name of the sponsor of the event.
+
+
+9.2.3: Tag: Section
+
+This uses a string; this is used for the playing section of a tournament (e.g.,
+"Open" or "Reserve").
+
+
+9.2.4: Tag: Stage
+
+This uses a string; this is used for the stage of a multistage event (e.g.,
+"Preliminary" or "Semifinal").
+
+
+9.2.5: Tag: Board
+
+This uses an integer; this identifies the board number in a team event and also
+in a simultaneous exhibition.
+
+
+9.3: Opening information (locale specific)
+
+The following tag pairs are used for traditional opening names.  The associated
+tag values will vary according to the local language in use.
+
+
+9.3.1: Tag: Opening
+
+This uses a string; this is used for the traditional opening name.  This will
+vary by locale.  This tag pair is associated with the use of the EPD opcode
+"v0" described in a later section of this document.
+
+
+9.3.2: Tag: Variation
+
+This uses a string; this is used to further refine the Opening tag.  This will
+vary by locale.  This tag pair is associated with the use of the EPD opcode
+"v1" described in a later section of this document.
+
+
+9.3.3: Tag: SubVariation
+
+This uses a string; this is used to further refine the Variation tag.  This
+will vary by locale.  This tag pair is associated with the use of the EPD
+opcode "v2" described in a later section of this document.
+
+
+9.4: Opening information (third party vendors)
+
+The following tag pairs are used for representing opening identification
+according to various third party vendors and organizations.  References to
+these organizations does not imply any endorsement of them or any endorsement
+by them.
+
+
+9.4.1: Tag: ECO
+
+This uses a string of either the form "XDD" or the form "XDD/DD" where the "X"
+is a letter from "A" to "E" and the "D" positions are digits; this is used for
+an opening designation from the five volume _Encyclopedia of Chess Openings_.
+This tag pair is associated with the use of the EPD opcode "eco" described in a
+later section of this document.
+
+
+9.4.2: Tag: NIC
+
+This uses a string; this is used for an opening designation from the _New in
+Chess_ database.  This tag pair is associated with the use of the EPD opcode
+"nic" described in a later section of this document.
+
+
+9.5: Time and date related information
+
+The following tags assist with further refinement of the time and data
+information associated with a game.
+
+
+9.5.1: Tag: Time
+
+This uses a time-of-day value in the form "HH:MM:SS"; similar to the Date tag
+except that it denotes the local clock time (hours, minutes, and seconds) of
+the start of the game.  Note that colons, not periods, are used for field
+separators for the Time tag value.  The value is taken from the local time
+corresponding to the location given in the Site tag pair.
+
+
+9.5.2: Tag: UTCTime
+
+This tag is similar to the Time tag except that the time is given according to
+the Universal Coordinated Time standard.
+
+
+9.5.3: Tag:; UTCDate
+
+This tag is similar to the Date tag except that the date is given according to
+the Universal Coordinated Time standard.
+
+
+9.6: Time control
+
+The follwing tag is used to help describe the time control used with the game.
+
+
+9.6.1: Tag: TimeControl
+
+This uses a list of one or more time control fields.  Each field contains a
+descriptor for each time control period; if more than one descriptor is present
+then they are separated by the colon character (":").  The descriptors appear
+in the order in which they are used in the game.  The last field appearing is
+considered to be implicitly repeated for further control periods as needed.
+
+There are six kinds of TimeControl fields.
+
+The first kind is a single question mark ("?") which means that the time
+control mode is unknown.  When used, it is usually the only descriptor present.
+
+The second kind is a single hyphen ("-") which means that there was no time
+control mode in use.  When used, it is usually the only descriptor present.
+
+The third Time control field kind is formed as two positive integers separated
+by a solidus ("/") character.  The first integer is the number of moves in the
+period and the second is the number of seconds in the period.  Thus, a time
+control period of 40 moves in 2 1/2 hours would be represented as "40/9000".
+
+The fourth TimeControl field kind is used for a "sudden death" control period.
+It should only be used for the last descriptor in a TimeControl tag value.  It
+is sometimes the only descriptor present.  The format consists of a single
+integer that gives the number of seconds in the period.  Thus, a blitz game
+would be represented with a TimeControl tag value of "300".
+
+The fifth TimeControl field kind is used for an "incremental" control period.
+It should only be used for the last descriptor in a TimeControl tag value and
+is usually the only descriptor in the value.  The format consists of two
+positive integers separated by a plus sign ("+") character.  The first integer
+gives the minimum number of seconds allocated for the period and the second
+integer gives the number of extra seconds added after each move is made.  So,
+an incremental time control of 90 minutes plus one extra minute per move would
+be given by "4500+60" in the TimeControl tag value.
+
+The sixth TimeControl field kind is used for a "sandclock" or "hourglass"
+control period.  It should only be used for the last descriptor in a
+TimeControl tag value and is usually the only descriptor in the value.  The
+format consists of an asterisk ("*") immediately followed by a positive
+integer.  The integer gives the total number of seconds in the sandclock
+period.  The time control is implemented as if a sandclock were set at the
+start of the period with an equal amount of sand in each of the two chambers
+and the players invert the sandclock after each move with a time forfeit
+indicated by an empty upper chamber.  Electronic implementation of a physical
+sandclock may be used.  An example sandclock specification for a common three
+minute egg timer sandclock would have a tag value of "*180".
+
+Additional TimeControl field kinds will be defined as necessary.
+
+
+9.7: Alternative starting positions
+
+There are two tags defined for assistance with describing games that did not
+start from the usual initial array.
+
+
+9.7.1: Tag: SetUp
+
+This tag takes an integer that denotes the "set-up" status of the game.  A
+value of "0" indicates that the game has started from the usual initial array.
+A value of "1" indicates that the game started from a set-up position; this
+position is given in the "FEN" tag pair.  This tag must appear for a game
+starting with a set-up position.  If it appears with a tag value of "1", a FEN
+tag pair must also appear.
+
+
+9.7.2: Tag: FEN
+
+This tag uses a string that gives the Forsyth-Edwards Notation for the starting
+position used in the game.  FEN is described in a later section of this
+document.  If a SetUp tag appears with a tag value of "1", the FEN tag pair is
+also required.
+
+
+9.8: Game conclusion
+
+There is a single tag that discusses the conclusion of the game.
+
+
+9.8.1: Tag: Termination
+
+This takes a string that describes the reason for the conclusion of the game.
+While the Result tag gives the result of the game, it does not provide any
+extra information and so the Termination tag is defined for this purpose.
+
+Strings that may appear as Termination tag values:
+
+* "abandoned": abandoned game.
+
+* "adjudication": result due to third party adjudication process.
+
+* "death": losing player called to greater things, one hopes.
+
+* "emergency": game concluded due to unforeseen circumstances.
+
+* "normal": game terminated in a normal fashion.
+
+* "rules infraction": administrative forfeit due to losing player's failure to
+observe either the Laws of Chess or the event regulations.
+
+* "time forfeit": loss due to losing player's failure to meet time control
+requirements.
+
+* "unterminated": game not terminated.
+
+
+9.9: Miscellaneous
+
+These are tags that can be briefly described and that doon't fit well inother
+sections.
+
+
+9.9.1: Tag: Annotator
+
+This tag uses a name or names in the format of the player name tags; this
+identifies the annotator or annotators of the game.
+
+
+9.9.2: Tag: Mode
+
+This uses a string that gives the playing mode of the game.  Examples: "OTB"
+(over the board), "PM" (paper mail), "EM" (electronic mail), "ICS" (Internet
+Chess Server), and "TC" (general telecommunication).
+
+
+9.9.3: Tag: PlyCount
+
+This tag takes a single integer that gives the number of ply (moves) in the
+game.
+
+
+10: Numeric Annotation Glyphs
+
+NAG zero is used for a null annotation; it is provided for the convenience of
+software designers as a placeholder value and should probably not be used in
+external PGN data.
+
+NAGs with values from 1 to 9 annotate the move just played.
+
+NAGs with values from 10 to 135 modify the current position.
+
+NAGs with values from 136 to 139 describe time pressure.
+
+Other NAG values are reserved for future definition.
+
+Note: the number assignments listed below should be considered preliminary in
+nature; they are likely to be changed as a result of reviewer feedback.
+
+NAG    Interpretation
+---    --------------
+  0    null annotation
+  1    good move (traditional "!")
+  2    poor move (traditional "?")
+  3    very good move (traditional "!!")
+  4    very poor move (traditional "??")
+  5    speculative move (traditional "!?")
+  6    questionable move (traditional "?!")
+  7    forced move (all others lose quickly)
+  8    singular move (no reasonable alternatives)
+  9    worst move
+ 10    drawish position
+ 11    equal chances, quiet position
+ 12    equal chances, active position
+ 13    unclear position
+ 14    White has a slight advantage
+ 15    Black has a slight advantage
+ 16    White has a moderate advantage
+ 17    Black has a moderate advantage
+ 18    White has a decisive advantage
+ 19    Black has a decisive advantage
+ 20    White has a crushing advantage (Black should resign)
+ 21    Black has a crushing advantage (White should resign)
+ 22    White is in zugzwang
+ 23    Black is in zugzwang
+ 24    White has a slight space advantage
+ 25    Black has a slight space advantage
+ 26    White has a moderate space advantage
+ 27    Black has a moderate space advantage
+ 28    White has a decisive space advantage
+ 29    Black has a decisive space advantage
+ 30    White has a slight time (development) advantage
+ 31    Black has a slight time (development) advantage
+ 32    White has a moderate time (development) advantage
+ 33    Black has a moderate time (development) advantage
+ 34    White has a decisive time (development) advantage
+ 35    Black has a decisive time (development) advantage
+ 36    White has the initiative
+ 37    Black has the initiative
+ 38    White has a lasting initiative
+ 39    Black has a lasting initiative
+ 40    White has the attack
+ 41    Black has the attack
+ 42    White has insufficient compensation for material deficit
+ 43    Black has insufficient compensation for material deficit
+ 44    White has sufficient compensation for material deficit
+ 45    Black has sufficient compensation for material deficit
+ 46    White has more than adequate compensation for material deficit
+ 47    Black has more than adequate compensation for material deficit
+ 48    White has a slight center control advantage
+ 49    Black has a slight center control advantage
+ 50    White has a moderate center control advantage
+ 51    Black has a moderate center control advantage
+ 52    White has a decisive center control advantage
+ 53    Black has a decisive center control advantage
+ 54    White has a slight kingside control advantage
+ 55    Black has a slight kingside control advantage
+ 56    White has a moderate kingside control advantage
+ 57    Black has a moderate kingside control advantage
+ 58    White has a decisive kingside control advantage
+ 59    Black has a decisive kingside control advantage
+ 60    White has a slight queenside control advantage
+ 61    Black has a slight queenside control advantage
+ 62    White has a moderate queenside control advantage
+ 63    Black has a moderate queenside control advantage
+ 64    White has a decisive queenside control advantage
+ 65    Black has a decisive queenside control advantage
+ 66    White has a vulnerable first rank
+ 67    Black has a vulnerable first rank
+ 68    White has a well protected first rank
+ 69    Black has a well protected first rank
+ 70    White has a poorly protected king
+ 71    Black has a poorly protected king
+ 72    White has a well protected king
+ 73    Black has a well protected king
+ 74    White has a poorly placed king
+ 75    Black has a poorly placed king
+ 76    White has a well placed king
+ 77    Black has a well placed king
+ 78    White has a very weak pawn structure
+ 79    Black has a very weak pawn structure
+ 80    White has a moderately weak pawn structure
+ 81    Black has a moderately weak pawn structure
+ 82    White has a moderately strong pawn structure
+ 83    Black has a moderately strong pawn structure
+ 84    White has a very strong pawn structure
+ 85    Black has a very strong pawn structure
+ 86    White has poor knight placement
+ 87    Black has poor knight placement
+ 88    White has good knight placement
+ 89    Black has good knight placement
+ 90    White has poor bishop placement
+ 91    Black has poor bishop placement
+ 92    White has good bishop placement
+ 93    Black has good bishop placement
+ 84    White has poor rook placement
+ 85    Black has poor rook placement
+ 86    White has good rook placement
+ 87    Black has good rook placement
+ 98    White has poor queen placement
+ 99    Black has poor queen placement
+100    White has good queen placement
+101    Black has good queen placement
+102    White has poor piece coordination
+103    Black has poor piece coordination
+104    White has good piece coordination
+105    Black has good piece coordination
+106    White has played the opening very poorly
+107    Black has played the opening very poorly
+108    White has played the opening poorly
+109    Black has played the opening poorly
+110    White has played the opening well
+111    Black has played the opening well
+112    White has played the opening very well
+113    Black has played the opening very well
+114    White has played the middlegame very poorly
+115    Black has played the middlegame very poorly
+116    White has played the middlegame poorly
+117    Black has played the middlegame poorly
+118    White has played the middlegame well
+119    Black has played the middlegame well
+120    White has played the middlegame very well
+121    Black has played the middlegame very well
+122    White has played the ending very poorly
+123    Black has played the ending very poorly
+124    White has played the ending poorly
+125    Black has played the ending poorly
+126    White has played the ending well
+127    Black has played the ending well
+128    White has played the ending very well
+129    Black has played the ending very well
+130    White has slight counterplay
+131    Black has slight counterplay
+132    White has moderate counterplay
+133    Black has moderate counterplay
+134    White has decisive counterplay
+135    Black has decisive counterplay
+136    White has moderate time control pressure
+137    Black has moderate time control pressure
+138    White has severe time control pressure
+139    Black has severe time control pressure
+
+
+11: File names and directories
+
+File names chosen for PGN data should be both informative and portable.  The
+directory names and arrangements should also be chosen for the same reasons and
+also for ease of navigation.
+
+Some of suggested file and directory names may be difficult or impossible to
+represent on certain computing systems.  Use of appropriate conversion customs
+is encouraged.
+
+
+11.1: File name suffix for PGN data
+
+The use of the file suffix ".pgn" is encouraged for ASCII text files containing
+PGN data.
+
+
+11.2: File name formation for PGN data for a specific player
+
+PGN games for a specific player should have a file name consisting of the
+player's last name followed by the ".pgn" suffix.
+
+
+11.3: File name formation for PGN data for a specific event
+
+PGN games for a specific event should have a file name consisting of the
+event's name followed by the ".pgn" suffix.
+
+
+11.4: File name formation for PGN data for chronologically ordered games
+
+PGN data files used for chronologically ordered (oldest first) archives use
+date information as file name root strings.  A file containing all the PGN
+games for a given year would have an eight character name in the format
+"YYYY.pgn".  A file containing PGN data for a given month would have a ten
+character name in the format "YYYYMM.pgn".  Finally, a file for PGN games for a
+single day would have a twelve character name in the format "YYYYMMDD.pgn".
+Large files are split into smaller files as needed.
+
+As game files are commonly arranged by chronological order, games with missing
+or incomplete Date tag pair data are to be avoided.  Any question mark
+characters in a Date tag value will be treated as zero digits for collation
+within a file and also for file naming.
+
+Large quantities of PGN data arranged by chronological order should be
+organized into hierarchical directories.  A directory containing all PGN data
+for a given year would have a four character name in the format "YYYY";
+directories containing PGN files for a given month would have a six character
+name in the format "YYYYMM".
+
+
+11.5: Suggested directory tree organization
+
+A suggested directory arrangement for ftp sites and CD-ROM distributions:
+
+* PGN: master directory of the PGN subtree (pub/chess/Game-Databases/PGN)
+
+* PGN/Events: directory of PGN files, each for a specific event
+
+* PGN/Events/News: news and status of the event collection
+
+* PGN/Events/ReadMe: brief description of the local directory contents
+
+* PGN/MGR: directory of the Master Games Repository subtree
+
+* PGN/MGR/News: news and status of the entire PGN/MGR subtree
+
+* PGN/MGR/ReadMe: brief description of the local directory contents
+
+* PGN/MGR/YYYY: directory of games or subtrees for the year YYYY
+
+* PGN/MGR/YYYY/ReadMe: description of local directory for year YYYY
+
+* PGN/MGR/YYYY/News: news and status for year YYYY data
+
+* PGN/News: news and status of the entire PGN subtree
+
+* PGN/Players: directory of PGN files, each for a specific player
+
+* PGN/Players/News: news and status of the player collection
+
+* PGN/Players/ReadMe: brief description of the local directory contents
+
+* PGN/ReadMe: brief description of the local directory contents
+
+* PGN/Standard: the PGN standard (this document)
+
+* PGN/Tools: software utilities that access PGN data
+
+
+12: PGN collating sequence
+
+There is a standard sorting order for PGN games within a file.  This collation
+is based on eight keys; these are the seven tag values of the STR and also the
+movetext itself.
+
+The first (most important, primary key) is the Date tag.  Earlier dated games
+appear prior to games played at a later date.  This field is sorted by
+ascending numeric value first with the year, then the month, and finally the
+day of the month.  Query characters used for unknown date digit values will be
+treated as zero digit characters for ordering comparison.
+
+The second key is the Event tag.  This is sorted in ascending ASCII order.
+
+The third key is the Site tag.  This is sorted in ascending ASCII order.
+
+The fourth key is the Round tag.  This is sorted in ascending numeric order
+based on the value of the integer used to denote the playing round.  A query or
+hyphen used for the round is ordered before any integer value.  A query
+character is ordered before a hyphen character.
+
+The fifth key is the White tag.  This is sorted in ascending ASCII order.
+
+The sixth key is the Black tag.  This is sorted in ascending ASCII order.
+
+The seventh key is the Result tag.  This is sorted in ascending ASCII order.
+
+The eighth key is the movetext itself.  This is sorted in ascending ASCII order
+with the entire text including spaces and newline characters.
+
+
+13: PGN software
+
+This section describes some PGN software that is either currently available or
+expected to be available in the near future.  The entries are presented in
+rough chronological order of their being made known to the PGN standard
+coordinator.  Authors of PGN capable software are encouraged to contact the
+coordinator (e-mail address listed near the start of this document) so that the
+information may be included here in this section.
+
+In addition to the PGN standard, there are two more chess standards of interest
+to the chess software community.  These are the FEN standard (Forsyth-Edwards
+Notation) for position notation and the EPD standard (Extended Position
+Description) for comprehensive position description for automated interprogram
+processing.  These are described in a later section of this document.
+
+Some PGN software is freeware and can be gotten from ftp sites and other
+sources.  Other PGN software is payware and appears as part of commercial
+chessplaying programs and chess database managers.  Those who are interested in
+the propagation of the PGN standard are encouraged to support manufacturers of
+chess software that use the standard.  If a particular vendor does not offer
+PGN compatibility, it is likely that a few letters to them along with a copy of
+this specification may help them decide to include PGN support in their next
+release.
+
+The staff at the University of Oklahoma at Norman (USA) have graciously
+provided an ftp site (chess.uoknor.edu) for the storage of chess related data
+and programs.  Because file names change over time, those accessing the site
+are encouraged to first retrieve the file "pub/chess/ls-lR.gz" for a current
+listing.  A scan of this listing will also help locate versions of PGN programs
+for machine types and operating systems other than those listed below.  Further
+information about this archive can be gotten from its administrator, Chris
+Petroff ([email protected]).
+
+For European users, the kind staff at the University of Hamburg (Germany) have
+provided the ftp site ftp.math.uni-hamburg.de; this carries a daily mirror of
+the pub/chess directory at the chess.uoknor.edu site.
+
+
+13.1: The SAN Kit
+
+The "SAN Kit" is an ANSI C source chess programming toolkit available for free
+from the ftp site chess.uoknor.edu in the directory pub/chess/Unix as the file
+"SAN.tar.gz" (a gzip tar archive).  This kit contains code for PGN import and
+export and can be used to "regularize" PGN data into reduced export format by
+use of its "tfgg" command.  The SAN Kit also supports FEN I/O.  Code from this
+kit is freely redistributable for anyone as long as future distribution is
+unhindered for everyone.  The SAN Kit is undergoing continuous development,
+although dates of future deliveries are quite difficult to predict and releases
+sometimes appear months apart.  Suggestions and comments should be directed to
+its author, Steven J. Edwards ([email protected]).
+
+
+13.2: pgnRead
+
+The program "pgnRead" runs under MS Windows 3.1 and provides an interactive
+graphical user interface for scanning PGN data files.  This program includes a
+colorful figurine chessboard display and scrolling controls for game and game
+text selection.  It is available from the chess.uoknor.edu ftp site in the
+pub/chess/DOS directory; several versions are available with names of the form
+"pgnrd**.exe"; the latest at this writing is "PGNRD130.EXE".  Suggestions and
+comments should be directed to its author, Keith Fuller ([email protected]).
+
+
+13.3: mail2pgn/GIICS
+
+The program "mail2pgn" produces a PGN version of chess game data generated by
+the ICS (Internet Chess Server).  It can be found at the chess.uoknor.edu ftp
+site in the pub/chess/DOS directory as the file "mail2pgn.zip"  A C language
+version is in the directory pub/chess/Unix as the file "mail2pgn.c".
+Suggestions and comments should be directed to its author, John Aronson
+([email protected]).  This code has been reportedly incorporated
+into the GIICS (Graphical Interface for the ICS); suggestions and comments
+should be directed to its author, Tony Acero ([email protected]).
+
+There is a report that mail2pgn has been superseded by the newer program
+"MV2PGN" described below.
+
+
+13.4: XBoard
+
+"XBoard" is a comprehensive chess utility running under the X Window System
+that provides a graphical user interface in a portable manner.  A new version
+now handles PGN data.  It is available from the chess.uoknor.edu ftp site in
+the pub/chess/X directory as the file "xboard-3.0.pl9.tar.gz".  Suggestions and
+comments should be directed to its author, Tim Mann ([email protected]).
+
+
+13.5: cupgn
+
+The program "cupgn" converts game data stored in the ChessBase format into PGN.
+It is available from the chess.uoknor.edu ftp site in the
+pub/chess/Game-Databases/CBUFF directory as the file "cupgn.tar.gz".  Another
+version is in the directory pub/chess/DOS as the file "cupgn120.exe".
+Suggestions and comments should be directed to its author, Anjo Anjewierden
+([email protected]).
+
+
+13.6: Zarkov
+
+The current version (3.0) of the commercial chessplaying program "Zarkov" can
+read and write games using PGN.  This program can also use the EPD standard for
+communication with other EPD capable programs.  Historically, Zarkov is the
+very first program to use EPD.  Suggestions and comments should be directed to
+its author, John Stanback ([email protected]).
+
+A vendor for North America is:
+
+    International Chess Enterprises
+    P.O. Box 19457
+    Seattle, WA 98109
+    USA
+    (800) 262-4277
+
+A vendor for Europe is:
+
+    Gambit-Soft
+    Feckenhauser Strasse 27
+    D-78628 Rottweil
+    GERMANY
+    49-741-21573
+
+
+13.7: Chess Assistant
+
+The upcoming version of the multifunction commercial database program "Chess
+Assistant" will be able to use the PGN standard as an import and export option.
+There is a report of a freeware program, "PGN2CA", that will convert PGN
+databases into Chess Assistant format.  For more information, the contact is
+Victor Zakharov, one of the members of the Chess Assistant development team
+([email protected]).
+
+A vendor for North America is:
+
+    International Chess Enterprises
+    P.O. Box 19457
+    Seattle, WA 98109
+    USA
+    (800) 262-4277
+
+
+13.8: BOOKUP
+
+The MS-DOS edition of the multifunction commercial program BOOKUP, version 8.1,
+is able to use the EPD standard for communication with other EPD capable
+programs.  It may also be PGN capable as well.
+
+The BOOKUP 8.1.1 Addenda notes dated 1993.12.17 provide comprehensive
+information on how to use EPD in conjunction with "analyst" programs such as
+Zarkov and HIARCS.  Specifically, the search and evaluation abilities of an
+analyst program are combined with the information organization abilities of the
+BOOKUP database program to provide position scoring.  This is done by first
+having BOOKUP export a database in EPD format, then having an analyst program
+annotate each EPD record with a numeric score, and then having BOOKUP import
+the changed EPD file.  BOOKUP can then apply minimaxing to the imported
+database; this results in scores from terminal positions being propagated back
+to earlier positions and even back to moves from the starting array.
+
+For some reason, BOOKUP calls this process "backsolving", but it's really just
+standard minimaxing.  In any case, it's a good example of how different
+programs from different authors performing different types of tasks can be
+integrated by use of a common, non-proprietary standard.  This allows for a new
+set of powerful features that are beyond the capabilities of any one of the
+individual component programs.
+
+BOOKUP allows for some customizing of EPD actions.  One such customization is
+to require the positional evaluations to follow the EPD standard; this means
+that the score is always given from the viewpoint of the active player.  This
+is explained more fully in the section on the "ce" (centipawn evaluation)
+opcode in the EPD description in a later section of this document.  To ensure
+that BOOKUP handles the centipawn evaluations in the "right" way, the EPD
+setting "Positive for White" must be set to "N".  This makes BOOKUP work
+correctly with Zarkov and with all other programs that use the "right"
+centipawn evaluation convention.  There is an apparent problem with HIARCS that
+requires this option to be set to "Y"; but this really means that, if true,
+HIARCS needs to be adjusted to use the "right" centipawn evaluation convention.
+
+A vendor in North America is:
+
+    BOOKUP
+    2763 Kensington Place West
+    Columbus, OH 43202
+    USA
+    (800) 949-5445
+    (614) 263-7219
+
+
+13.9: HIARCS
+
+The current version (2.1) of the commercial chessplaying program "HIARCS" is
+able to use the EPD standard for communication with other EPD capable programs.
+It may also be PGN capable as well.  More details will appear here as they
+become available.
+
+A vendor in North America is:
+
+    HIARCS
+    c/o BOOKUP
+    2763 Kensington Place West
+    Columbus, OH 43202
+    USA
+    (800) 949-5445
+    (614) 263-7219
+
+
+13.10: Deja Vu
+
+The chess database "Deja Vu" from ChessWorks is a PGN compatible collection of
+over 300,000 games.  It is available only on CD-ROM and is scheduled for
+release in 1994.05 with periodic revisions thereafter.  The introductory price
+is US$329.  For further information, the authors are John Crayton and Eric
+Schiller and they can be contacted via e-mail ([email protected]).
+
+
+13.11: MV2PGN
+
+The program "MV2PGN" can be used to convert game data generated by both current
+and older versions of the GIICS (Graphical Interface - Internet Chess Server).
+The program is included in the self extracting archive available from
+chess.uoknor.edu in the directory pub/chess/DOS as the file "ics2pgn.exe".
+Source code is also included.  This program is reported to supersede the older
+"mail2pgn" and was needed due to a change in ICS recording format in late 1993.
+For further information about MV2PGN, the contact person is Gary Bastin
+([email protected]).
+
+
+13.12: The Hansen utilities (cb2pgn, nic2pgn, pgn2cb, pgn2nic)
+
+The Hansen utilities are used to convert among various chess data
+representation formats.  The PGN related programs include: "cb2pgn.exe"
+(convert ChessBase to PGN), "nic2pgn.exe" (convert NIC to PGN), "pgn2cb.exe"
+(convert PGN to ChessBase), and "pgn2nic.exe" (convert PGN to NIC).
+
+The ChessBase related utilities (cb2pgn/pgn2cb) are found at chess.uoknor.edu
+in the pub/chess/Game-Databases/ChessBase directory.
+
+The NIC related utilities (nic2pgn/pgn2nic) are found at chess.uoknor.edu in
+the pub/chess/Game-Databases/NIC directory.
+
+For further information about the Hansen utilities, the contact person is the
+author, Carsten Hansen ([email protected]).
+
+
+13.13: Slappy the Database
+
+"Slappy the Database" is a commercial chess database and translation program
+scheduled for release no sooner than late 1994.  It is a low cost utility with
+a simple character interface intended for those who want a supported product
+but who do not need (or cannot afford) a comprehensive, feature-laden program
+with a graphical user interface.  Slappy's two most important features are its
+batch processing ability and its full implementation of each and every standard
+described in this document.  Versions of Slappy the Database will be provided
+for various platforms including: Intel 386/486 Unix, Apple Macintosh, and
+MS-DOS.
+
+Slappy may also be useful to those who have a full feature program who also
+need to run time consuming chess database tasks on a spare computer.
+
+Suggestions and comments should be directed to its author, Steven J. Edwards
+([email protected]).  More details will appear here as they become available.
+
+
+13.14: CBASCII
+
+"CBASCII" is a general utility for converting chess data between ChessBase
+format and ASCII representations.  It has PGN capability, and it is available
+from the chess.uoknor.edu ftp site in the pub/chess/DOS directory as the file
+"cba1_2.zip".  The contact person is the program's author, Andy Duplain
+([email protected]).
+
+
+13.15: ZZZZZZ
+
+"ZZZZZZ" is a chessplaying program, complete with source, that also includes
+some database functions.  A recent version is reported to have both PGN and EPD
+capabilities.  It is available from the chess.uoknor.edu ftp site in the
+pub/chess/Unix directory as the file "zzzzzz-3.2b1.tar.gz".  The contact person
+is its author, Gijsbert Wiesenecker ([email protected]).
+
+
+13.16: icsconv
+
+The program "icsconv" can be used to convert Internet Chess Server games, both
+old and new format, to PGN.  It is available from the chess.uoknor.edu site in
+the pub/chess/Game-Databases/PGN/Tools directory as the file "icsconv.exe".
+The contact person is the author, Kevin Nomura ([email protected]).
+
+
+13.17: CHESSOP (CHESSOPN/CHESSOPG)
+
+CHESSOP is an openings database and viewing tool with support for reading PGN
+games.  It runs under MS-DOS and displays positions rather than games.  For
+each position, both good and bad moves are listed with appropriate annotation.
+Transpositions are handled as well.  The distributed database contains over
+100,000 positions covering all the common openings.  Users can feed in their
+own PGN data as well.  CHESSOP takes 3 Mbyte of hard disk, costs US$39 and can
+be obtained from:
+
+    CHESSX Software
+    12 Bluebell Close
+    Glenmore Park
+    AUSTRALIA 2745.
+
+The ideas behind CHESSOP can be seen in CHESSOPN (alias CHESSOPG), a free
+version on the ICS server which has a reduced openings database (25,000
+positions) and no PGN or transposition support but is otherwise the same as
+CHESSOP.  (These are the files "chessopg.zip" in the directory pub/chess/DOS at
+the chess.uoknor.edu ftp site.)
+
+
+13.18: CAT2PGN
+
+The program "CAT2PGN" is a utility that translates data from the format used by
+Chess Assistant into PGN.  It is available from the chess.uoknor.edu ftp site.
+The contact person for CAT2PGN is its author, David Myers
+([email protected]).
+
+
+13.19: pgn2opg
+
+The utility "pgn2opg" can be used to convert PGN files into a text format used
+by the "CHESSOPG" program mentioned above.  Although it does not perform any
+semantic analysis on PGN input, it has been demonstrated to handle known
+correct PGN input properly.  The file can be found in the pub/chess/PGN/Tools
+directory at the chess.uoknor.edu ftp site.  For more information, the author
+is David Barnes ([email protected]).
+
+
+14: PGN data archives
+
+The primary PGN data archive repository is located at the ftp site
+chess.uoknor.edu as the directory "pub/chess/Game-Databases/PGN".  It is
+organized according to the description given in section C.5 of this document.
+The European site ftp.math.uni-hamburg.de is also reported to carry a regularly
+updated copy of the repository.
+
+
+15: International Olympic Committee country codes
+
+International Olympic Committee country codes are employed for Site nation
+information because of their traditional use with the reporting of
+international sporting events.  Due to changes in geography and linguistic
+custom, some of the following may be incorrect or outdated.  Corrections and
+extensions should be sent via e-mail to the PGN coordinator whose address
+listed near the start of this document.
+
+AFG: Afghanistan
+AIR: Aboard aircraft
+ALB: Albania
+ALG: Algeria
+AND: Andorra
+ANG: Angola
+ANT: Antigua
+ARG: Argentina
+ARM: Armenia
+ATA: Antarctica
+AUS: Australia
+AZB: Azerbaijan
+BAN: Bangladesh
+BAR: Bahrain
+BHM: Bahamas
+BEL: Belgium
+BER: Bermuda
+BIH: Bosnia and Herzegovina
+BLA: Belarus
+BLG: Bulgaria
+BLZ: Belize
+BOL: Bolivia
+BRB: Barbados
+BRS: Brazil
+BRU: Brunei
+BSW: Botswana
+CAN: Canada
+CHI: Chile
+COL: Columbia
+CRA: Costa Rica
+CRO: Croatia
+CSR: Czechoslovakia
+CUB: Cuba
+CYP: Cyprus
+DEN: Denmark
+DOM: Dominican Republic
+ECU: Ecuador
+EGY: Egypt
+ENG: England
+ESP: Spain
+EST: Estonia
+FAI: Faroe Islands
+FIJ: Fiji
+FIN: Finland
+FRA: France
+GAM: Gambia
+GCI: Guernsey-Jersey
+GEO: Georgia
+GER: Germany
+GHA: Ghana
+GRC: Greece
+GUA: Guatemala
+GUY: Guyana
+HAI: Haiti
+HKG: Hong Kong
+HON: Honduras
+HUN: Hungary
+IND: India
+IRL: Ireland
+IRN: Iran
+IRQ: Iraq
+ISD: Iceland
+ISR: Israel
+ITA: Italy
+IVO: Ivory Coast
+JAM: Jamaica
+JAP: Japan
+JRD: Jordan
+JUG: Yugoslavia
+KAZ: Kazakhstan
+KEN: Kenya
+KIR: Kyrgyzstan
+KUW: Kuwait
+LAT: Latvia
+LEB: Lebanon
+LIB: Libya
+LIC: Liechtenstein
+LTU: Lithuania
+LUX: Luxembourg
+MAL: Malaysia
+MAU: Mauritania
+MEX: Mexico
+MLI: Mali
+MLT: Malta
+MNC: Monaco
+MOL: Moldova
+MON: Mongolia
+MOZ: Mozambique
+MRC: Morocco
+MRT: Mauritius
+MYN: Myanmar
+NCG: Nicaragua
+NET: The Internet
+NIG: Nigeria
+NLA: Netherlands Antilles
+NLD: Netherlands
+NOR: Norway
+NZD: New Zealand
+OST: Austria
+PAK: Pakistan
+PAL: Palestine
+PAN: Panama
+PAR: Paraguay
+PER: Peru
+PHI: Philippines
+PNG: Papua New Guinea
+POL: Poland
+POR: Portugal
+PRC: People's Republic of China
+PRO: Puerto Rico
+QTR: Qatar
+RIN: Indonesia
+ROM: Romania
+RUS: Russia
+SAF: South Africa
+SAL: El Salvador
+SCO: Scotland
+SEA: At Sea
+SEN: Senegal
+SEY: Seychelles
+SIP: Singapore
+SLV: Slovenia
+SMA: San Marino
+SPC: Aboard spacecraft
+SRI: Sri Lanka
+SUD: Sudan
+SUR: Surinam
+SVE: Sweden
+SWZ: Switzerland
+SYR: Syria
+TAI: Thailand
+TMT: Turkmenistan
+TRK: Turkey
+TTO: Trinidad and Tobago
+TUN: Tunisia
+UAE: United Arab Emirates
+UGA: Uganda
+UKR: Ukraine
+UNK: Unknown
+URU: Uruguay
+USA: United States of America
+UZB: Uzbekistan
+VEN: Venezuela
+VGB: British Virgin Islands
+VIE: Vietnam
+VUS: U.S. Virgin Islands
+WLS: Wales
+YEM: Yemen
+YUG: Yugoslavia
+ZAM: Zambia
+ZIM: Zimbabwe
+ZRE: Zaire
+
+
+16: Additional chess data standards
+
+While PGN is used for game storage, there are other data representation
+standards for other chess related purposes.  Two important standards are FEN
+and EPD, both described in this section.
+
+
+16.1: FEN
+
+FEN is "Forsyth-Edwards Notation"; it is a standard for describing chess
+positions using the ASCII character set.
+
+A single FEN record uses one text line of variable length composed of six data
+fields.  The first four fields of the FEN specification are the same as the
+first four fields of the EPD specification.
+
+A text file composed exclusively of FEN data records should have a file name
+with the suffix ".fen".
+
+
+16.1.1: History
+
+FEN is based on a 19th century standard for position recording designed by the
+Scotsman David Forsyth, a newspaper journalist.  The original Forsyth standard
+has been slightly extended for use with chess software by Steven Edwards with
+assistance from commentators on the Internet.  This new standard, FEN, was
+first implemented in Edwards' SAN Kit.
+
+
+16.1.2: Uses for a position notation
+
+Having a standard position notation is particularly important for chess
+programmers as it allows them to share position databases.  For example, there
+exist standard position notation databases with many of the classical benchmark
+tests for chessplaying programs, and by using a common position notation format
+many hours of tedious data entry can be saved.  Additionally, a position
+notation can be useful for page layout programs and for confirming position
+status for e-mail competition.
+
+Many interesting chess problem sets represented using FEN can be found at the
+chess.uoknor.edu ftp site in the directory pub/chess/SAN_testsuites.
+
+
+16.1.3: Data fields
+
+FEN specifies the piece placement, the active color, the castling availability,
+the en passant target square, the halfmove clock, and the fullmove number.
+These can all fit on a single text line in an easily read format.  The length
+of a FEN position description varies somewhat according to the position. In
+some cases, the description could be eighty or more characters in length and so
+may not fit conveniently on some displays.  However, these positions aren't too
+common.
+
+A FEN description has six fields.  Each field is composed only of non-blank
+printing ASCII characters.  Adjacent fields are separated by a single ASCII
+space character.
+
+
+16.1.3.1: Piece placement data
+
+The first field represents the placement of the pieces on the board.  The board
+contents are specified starting with the eighth rank and ending with the first
+rank.  For each rank, the squares are specified from file a to file h.  White
+pieces are identified by uppercase SAN piece letters ("PNBRQK") and black
+pieces are identified by lowercase SAN piece letters ("pnbrqk").  Empty squares
+are represented by the digits one through eight; the digit used represents the
+count of contiguous empty squares along a rank.  A solidus character "/" is
+used to separate data of adjacent ranks.
+
+
+16.1.3.2: Active color
+
+The second field represents the active color.  A lower case "w" is used if
+White is to move; a lower case "b" is used if Black is the active player.
+
+
+16.1.3.3: Castling availability
+
+The third field represents castling availability.  This indicates potential
+future castling that may of may not be possible at the moment due to blocking
+pieces or enemy attacks.  If there is no castling availability for either side,
+the single character symbol "-" is used.  Otherwise, a combination of from one
+to four characters are present.  If White has kingside castling availability,
+the uppercase letter "K" appears.  If White has queenside castling
+availability, the uppercase letter "Q" appears.  If Black has kingside castling
+availability, the lowercase letter "k" appears.  If Black has queenside
+castling availability, then the lowercase letter "q" appears.  Those letters
+which appear will be ordered first uppercase before lowercase and second
+kingside before queenside.  There is no white space between the letters.
+
+
+16.1.3.4: En passant target square
+
+The fourth field is the en passant target square.  If there is no en passant
+target square then the single character symbol "-" appears.  If there is an en
+passant target square then is represented by a lowercase file character
+immediately followed by a rank digit.  Obviously, the rank digit will be "3"
+following a white pawn double advance (Black is the active color) or else be
+the digit "6" after a black pawn double advance (White being the active color).
+
+An en passant target square is given if and only if the last move was a pawn
+advance of two squares.  Therefore, an en passant target square field may have
+a square name even if there is no pawn of the opposing side that may
+immediately execute the en passant capture.
+
+
+16.1.3.5: Halfmove clock
+
+The fifth field is a nonnegative integer representing the halfmove clock.  This
+number is the count of halfmoves (or ply) since the last pawn advance or
+capturing move.  This value is used for the fifty move draw rule.
+
+
+16.1.3.6: Fullmove number
+
+The sixth and last field is a positive integer that gives the fullmove number.
+This will have the value "1" for the first move of a game for both White and
+Black.  It is incremented by one immediately after each move by Black.
+
+
+16.1.4: Examples
+
+Here's the FEN for the starting position:
+
+rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
+
+And after the move 1. e4:
+
+rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1
+
+And then after 1. ... c5:
+
+rnbqkbnr/pp1ppppp/8/2p5/4P3/8/PPPP1PPP/RNBQKBNR w KQkq c6 0 2
+
+And then after 2. Nf3:
+
+rnbqkbnr/pp1ppppp/8/2p5/4P3/5N2/PPPP1PPP/RNBQKB1R b KQkq - 1 2
+
+For two kings on their home squares and a white pawn on e2 (White to move) with
+thirty eight full moves played with five halfmoves since the last pawn move or
+capture:
+
+4k3/8/8/8/8/8/4P3/4K3 w - - 5 39
+
+
+16.2: EPD
+
+EPD is "Extended Position Description"; it is a standard for describing chess
+positions along with an extended set of structured attribute values using the
+ASCII character set.  It is intended for data and command interchange among
+chessplaying programs.  It is also intended for the representation of portable
+opening library repositories.
+
+A single EPD uses one text line of variable length composed of four data field
+followed by zero or more operations.  The four fields of the EPD specification
+are the same as the first four fields of the FEN specification.
+
+A text file composed exclusively of EPD data records should have a file name
+with the suffix ".epd".
+
+
+16.2.1: History
+
+EPD is based in part on the earlier FEN standard; it has added extensions for
+use with opening library preparation and also for general data and command
+interchange among advanced chess programs.  EPD was developed by John Stanback
+and Steven Edwards; its first implementation is in Stanback's master strength
+chessplaying program Zarkov.
+
+
+16.2.2: Uses for an extended position notation
+
+Like FEN, EPD can also be used for general position description.  However,
+unlike FEN, EPD is designed to be expandable by the addition of new operations
+that provide new functionality as needs arise.
+
+Many interesting chess problem sets represented using EPD can be found at the
+chess.uoknor.edu ftp site in the directory pub/chess/SAN_testsuites.
+
+
+16.2.3: Data fields
+
+EPD specifies the piece placement, the active color, the castling availability,
+and the en passant target square of a position.  These can all fit on a single
+text line in an easily read format.  The length of an EPD position description
+varies somewhat according to the position and any associated operations. In
+some cases, the description could be eighty or more characters in length and so
+may not fit conveniently on some displays.  However, most EPD descriptions pass
+among programs only and these are not usually seen by program users.
+
+(Note: due to the likelihood of future expansion of EPD, implementors are
+encouraged to have their programs handle EPD text lines of up to 1024
+characters long.)
+
+Each EPD data field is composed only of non-blank printing ASCII characters.
+Adjacent data fields are separated by a single ASCII space character.
+
+
+16.2.3.1: Piece placement data
+
+The first field represents the placement of the pieces on the board.  The board
+contents are specified starting with the eighth rank and ending with the first
+rank.  For each rank, the squares are specified from file a to file h.  White
+pieces are identified by uppercase SAN piece letters ("PNBRQK") and black
+pieces are identified by lowercase SAN piece letters ("pnbrqk").  Empty squares
+are represented by the digits one through eight; the digit used represents the
+count of contiguous empty squares along a rank.  A solidus character "/" is
+used to separate data of adjacent ranks.
+
+
+16.2.3.2: Active color
+
+The second field represents the active color.  A lower case "w" is used if
+White is to move; a lower case "b" is used if Black is the active player.
+
+
+16.2.3.3: Castling availability
+
+The third field represents castling availability.  This indicates potential
+future castling that may or may not be possible at the moment due to blocking
+pieces or enemy attacks.  If there is no castling availability for either side,
+the single character symbol "-" is used.  Otherwise, a combination of from one
+to four characters are present.  If White has kingside castling availability,
+the uppercase letter "K" appears.  If White has queenside castling
+availability, the uppercase letter "Q" appears.  If Black has kingside castling
+availability, the lowercase letter "k" appears.  If Black has queenside
+castling availability, then the lowercase letter "q" appears.  Those letters
+which appear will be ordered first uppercase before lowercase and second
+kingside before queenside.  There is no white space between the letters.
+
+
+16.2.3.4: En passant target square
+
+The fourth field is the en passant target square.  If there is no en passant
+target square then the single character symbol "-" appears.  If there is an en
+passant target square then is represented by a lowercase file character
+immediately followed by a rank digit.  Obviously, the rank digit will be "3"
+following a white pawn double advance (Black is the active color) or else be
+the digit "6" after a black pawn double advance (White being the active color).
+
+An en passant target square is given if and only if the last move was a pawn
+advance of two squares.  Therefore, an en passant target square field may have
+a square name even if there is no pawn of the opposing side that may
+immediately execute the en passant capture.
+
+
+16.2.4: Operations
+
+An EPD operation is composed of an opcode followed by zero or more operands and
+is concluded by a semicolon.
+
+Multiple operations are separated by a single space character.  If there is at
+least one operation present in an EPD line, it is separated from the last
+(fourth) data field by a single space character.
+
+
+16.2.4.1: General format
+
+An opcode is an identifier that starts with a letter character and may be
+followed by up to fourteen more characters.  Each additional character may be a
+letter or a digit or the underscore character.
+
+An operand is either a set of contiguous non-white space printing characters or
+a string.  A string is a set of contiguous printing characters delimited by a
+quote character at each end.  A string value must have less than 256 bytes of
+data.
+
+If at least one operand is present in an operation, there is a single space
+between the opcode and the first operand.  If more than one operand is present
+in an operation, there is a single blank character between every two adjacent
+operands.  If there are no operands, a semicolon character is appended to the
+opcode to mark the end of the operation.  If any operands appear, the last
+operand has an appended semicolon that marks the end of the operation.
+
+Any given opcode appears at most once per EPD record.  Multiple operations in a
+single EPD record should appear in ASCII order of their opcode names
+(mnemonics).  However, a program reading EPD records may allow for operations
+not in ASCII order by opcode mnemonics; the semantics are the same in either
+case.
+
+Some opcodes that allow for more than one operand may have special ordering
+requirements for the operands.  For example, the "pv" (predicted variation)
+opcode requires its operands (moves) to appear in the order in which they would
+be played.  All other opcodes that allow for more than one operand should have
+operands appearing in ASCII order.  An example of the latter set is the "bm"
+(best move[s]) opcode; its operands are moves that are all immediately playable
+from the current position.
+
+Some opcodes require one or more operands that are chess moves.  These moves
+should be represented using SAN.  If a different representation is used, there
+is no guarantee that the EPD will be read correctly during subsequent
+processing.
+
+Some opcodes require one or more operands that are integers.  Some opcodes may
+require that an integer operand must be within a given range; the details are
+described in the opcode list given below.  A negative integer is formed with a
+hyphen (minus sign) preceding the integer digit sequence.  An optional plus
+sign may be used for indicating a non-negative value, but such use is not
+required and is indeed discouraged.
+
+Some opcodes require one or more operands that are floating point numbers.
+Some opcodes may require that a floating point operand must be within a given
+range; the details are described in the opcode list given below.  A floating
+point operand is constructed from an optional sign character ("+" or "-"), a
+digit sequence (with at least one digit), a radix point (always "."), and a
+final digit sequence (with at least one digit).
+
+
+16.2.4.2: Opcode mnemonics
+
+An opcode mnemonic used for archival storage and for interprogram communication
+starts with a lower case letter and is composed of only lower case letters,
+digits, and the underscore character (i.e., no upper case letters).  These
+mnemonics will also all be at least two characters in length.
+
+Opcode mnemonics used only by a single program or an experimental suite of
+programs should start with an upper case letter.  This is so they may be easily
+distinguished should they be inadvertently be encountered by other programs.
+When a such a "private" opcode be demonstrated to be widely useful, it should
+be brought into the official list (appearing below) in a lower case form.
+
+If a given program does not recognize a particular opcode, that operation is
+simply ignored; it is not signaled as an error.
+
+
+16.2.5: Opcode list
+
+The opcodes are listed here in ASCII order of their mnemonics.  Suggestions for
+new opcodes should be sent to the PGN standard coordinator listed near the
+start of this document.
+
+
+16.2.5.1: Opcode "acn": analysis count: nodes
+
+The opcode "acn" takes a single non-negative integer operand.  It is used to
+represent the number of nodes examined in an analysis.  Note that the value may
+be quite large for some extended searches and so use of (at least) a long (four
+byte) representation is suggested.
+
+
+16.2.5.2: Opcode "acs": analysis count: seconds
+
+The opcode "acs" takes a single non-negative integer operand.  It is used to
+represent the number of seconds used for an analysis.  Note that the value may
+be quite large for some extended searches and so use of (at least) a long (four
+byte) representation is suggested.
+
+
+16.2.5.3: Opcode "am": avoid move(s)
+
+The opcode "am" indicates a set of zero or more moves, all immediately playable
+from the current position, that are to be avoided in the opinion of the EPD
+writer.  Each operand is a SAN move; they appear in ASCII order.
+
+
+16.2.5.4: Opcode "bm": best move(s)
+
+The opcode "bm" indicates a set of zero or more moves, all immediately playable
+from the current position, that are judged to the best available by the EPD
+writer.  Each operand is a SAN move; they appear in ASCII order.
+
+
+16.2.5.5: Opcode "c0": comment (primary, also "c1" though "c9")
+
+The opcode "c0" (lower case letter "c", digit character zero) indicates a top
+level comment that applies to the given position.  It is the first of ten
+ranked comments, each of which has a mnemonic formed from the lower case letter
+"c" followed by a single decimal digit.  Each of these opcodes takes either a
+single string operand or no operand at all.
+
+This ten member comment family of opcodes is intended for use as descriptive
+commentary for a complete game or game fragment.  The usual processing of these
+opcodes are as follows:
+
+1) At the beginning of a game (or game fragment), a move sequence scanning
+program initializes each element of its set of ten comment string registers to
+be null.
+
+2) As the EPD record for each position in the game is processed, the comment
+operations are interpreted from left to right.  (Actually, all operations in n
+EPD record are interpreted from left to right.)  Because operations appear in
+ASCII order according to their opcode mnemonics, opcode "c0" (if present) will
+be handled prior to all other opcodes, then opcode "c1" (if present), and so
+forth until opcode "c9" (if present).
+
+3) The processing of opcode "cN" (0 <= N <= 9) involves two steps.  First, all
+comment string registers with an index equal to or greater than N are set to
+null.  (This is the set "cN" though "c9".)  Second, and only if a string
+operand is present, the value of the corresponding comment string register is
+set equal to the string operand.
+
+
+16.2.5.6: Opcode "ce": centipawn evaluation
+
+The opcode "ce" indicates the evaluation of the indicated position in centipawn
+units.  It takes a single operand, an optionally signed integer that gives an
+evaluation of the position from the viewpoint of the active player; i.e., the
+player with the move.  Positive values indicate a position favorable to the
+moving player while negative values indicate a position favorable to the
+passive player; i.e., the player without the move.  A centipawn evaluation
+value close to zero indicates a neutral positional evaluation.
+
+Values are restricted to integers that are equal to or greater than -32767 and
+are less than or equal to 32766.
+
+A value greater than 32000 indicates the availability of a forced mate to the
+active player.  The number of plies until mate is given by subtracting the
+evaluation from the value 32767.  Thus, a winning mate in N fullmoves is a mate
+in ((2 * N) - 1) halfmoves (or ply) and has a corresponding centipawn
+evaluation of (32767 - ((2 * N) - 1)).  For example, a mate on the move (mate
+in one) has a centipawn evaluation of 32766 while a mate in five has a
+centipawn evaluation of 32758.
+
+A value less than -32000 indicates the availability of a forced mate to the
+passive player.  The number of plies until mate is given by subtracting the
+evaluation from the value -32767 and then negating the result.  Thus, a losing
+mate in N fullmoves is a mate in (2 * N) halfmoves (or ply) and has a
+corresponding centipawn evaluation of (-32767 + (2 * N)).  For example, a mate
+after the move (losing mate in one) has a centipawn evaluation of -32765 while
+a losing mate in five has a centipawn evaluation of -32757.
+
+A value of -32767 indicates an illegal position.  A stalemate position has a
+centipawn evaluation of zero as does a position drawn due to insufficient
+mating material.  Any other position known to be a certain forced draw also has
+a centipawn evaluation of zero.
+
+
+16.2.5.7: Opcode "dm": direct mate fullmove count
+
+The "dm" opcode is used to indicate the number of fullmoves until checkmate is
+to be delivered by the active color for the indicated position.  It always
+takes a single operand which is a positive integer giving the fullmove count.
+For example, a position known to be a "mate in three" would have an operation
+of "dm 3;" to indicate this.
+
+This opcode is intended for use with problem sets composed of positions
+requiring direct mate answers as solutions.
+
+
+16.2.5.8: Opcode "draw_accept": accept a draw offer
+
+The opcode "draw_accept" is used to indicate that a draw offer made after the
+move that lead to the indicated position is accepted by the active player.
+This opcode takes no operands.
+
+
+16.2.5.9: Opcode "draw_claim": claim a draw
+
+The opcode "draw_claim" is used to indicate claim by the active player that a
+draw exists.  The draw is claimed because of a third time repetition or because
+of the fifty move rule or because of insufficient mating material.  A supplied
+move (see the opcode "sm") is also required to appear as part of the same EPD
+record.  The draw_claim opcode takes no operands.
+
+
+16.2.5.10: Opcode "draw_offer": offer a draw
+
+The opcode "draw_offer" is used to indicate that a draw is offered by the
+active player.  A supplied move (see the opcode "sm") is also required to
+appear as part of the same EPD record; this move is considered played from the
+indicated position.  The draw_offer opcode takes no operands.
+
+
+16.2.5.11: Opcode "draw_reject": reject a draw offer
+
+The opcode "draw_reject" is used to indicate that a draw offer made after the
+move that lead to the indicated position is rejected by the active player.
+This opcode takes no operands.
+
+
+16.2.5.12: Opcode "eco": _Encyclopedia of Chess Openings_ opening code
+
+The opcode "eco" is used to associate an opening designation from the
+_Encyclopedia of Chess Openings_ taxonomy with the indicated position.  The
+opcode takes either a single string operand (the ECO opening name) or no
+operand at all.  If an operand is present, its value is associated with an
+"ECO" string register of the scanning program.  If there is no operand, the ECO
+string register of the scanning program is set to null.
+
+The usage is similar to that of the "ECO" tag pair of the PGN standard.
+
+
+16.2.5.13: Opcode "fmvn": fullmove number
+
+The opcode "fmvn" represents the fullmove n umber associated with the position.
+It always takes a single operand that is the positive integer value of the move
+number.
+
+This opcode is used to explicitly represent the fullmove number in EPD that is
+present by default in FEN as the sixth field.  Fullmove number information is
+usually omitted from EPD because it does not affect move generation (commonly
+needed for EPD-using tasks) but it does affect game notation (commonly needed
+for FEN-using tasks).  Because of the desire for space optimization for large
+EPD files, fullmove numbers were dropped from EPD's parent FEN.  The halfmove
+clock information was similarly dropped.
+
+
+16.2.5.14: Opcode "hmvc": halfmove clock
+
+The opcode "hmvc" represents the halfmove clock associated with the position.
+The halfmove clock of a position is equal to the number of plies since the last
+pawn move or capture.  This information is used to implement the fifty move
+draw rule.  It always takes a single operand that is the non-negative integer
+value of the halfmove clock.
+
+This opcode is used to explicitly represent the halfmove clock in EPD that is
+present by default in FEN as the fifth field.  Halfmove clock information is
+usually omitted from EPD because it does not affect move generation (commonly
+needed for EPD-using tasks) but it does affect game termination issues
+(commonly needed for FEN-using tasks).  Because of the desire for space
+optimization for large EPD files, halfmove clock values were dropped from EPD's
+parent FEN.  The fullmove number information was similarly dropped.
+
+
+16.2.5.15: Opcode "id": position identification
+
+The opcode "id" is used to provide a simple identifying label for the indicated
+position.  It takes a single string operand.
+
+This opcode is intended for use with test suites used for measuring
+chessplaying program strength.  An example "id" operand for the seven hundred
+fifty seventh position of the one thousand one problems in Reinfeld's _1001
+Winning Chess Sacrifices and Combinations_ would be "WCSAC.0757" while the
+fifteenth position in the twenty four problem Bratko-Kopec test suite would
+have an "id" operand of "BK.15".
+
+
+16.2.5.16: Opcode "nic": _New In Chess_ opening code
+
+The opcode "nic" is used to associate an opening designation from the _New In
+Chess_ taxonomy with the indicated position.  The opcode takes either a single
+string operand (the NIC opening name) or no operand at all.  If an operand is
+present, its value is associated with an "NIC" string register of the scanning
+program.  If there is no operand, the NIC string register of the scanning
+program is set to null.
+
+The usage is similar to that of the "NIC" tag pair of the PGN standard.
+
+
+16.2.5.17: Opcode "noop": no operation
+
+The "noop" opcode is used to indicate no operation.  It takes zero or more
+operands, each of which may be of any type.  The operation involves no
+processing.  It is intended for use by developers for program testing purposes.
+
+
+16.2.5.18: Opcode "pm": predicted move
+
+The "pm" opcode is used to provide a single predicted move for the indicated
+position.  It has exactly one operand, a move playable from the position.  This
+move is judged by the EPD writer to represent the best move available to the
+active player.
+
+If a non-empty "pv" (predicted variation) line of play is also present in the
+same EPD record, the first move of the predicted variation is the same as the
+predicted move.
+
+The "pm" opcode is intended for use as a general "display hint" mechanism.
+
+
+16.2.5.19: Opcode "pv": predicted variation
+
+The "pv" opcode is used to provide a predicted variation for the indicated
+position.  It has zero or more operands which represent a sequence of moves
+playable from the position.  This sequence is judged by the EPD writer to
+represent the best play available.
+
+If a "pm" (predicted move) operation is also present in the same EPD record,
+the predicted move is the same as the first move of the predicted variation.
+
+
+16.2.5.20: Opcode "rc": repetition count
+
+The "rc" opcode is used to indicate the number of occurrences of the indicated
+position.  It takes a single, positive integer operand.  Any position,
+including the initial starting position, is considered to have an "rc" value of
+at least one.  A value of three indicates a candidate for a draw claim by the
+position repetition rule.
+
+
+16.2.5.21: Opcode "resign": game resignation
+
+The opcode "resign" is used to indicate that the active player has resigned the
+game.  This opcode takes no operands.
+
+
+16.2.5.22: Opcode "sm": supplied move
+
+The "sm" opcode is used to provide a single supplied move for the indicated
+position.  It has exactly one operand, a move playable from the position.  This
+move is the move to be played from the position.
+
+The "sm" opcode is intended for use to communicate the most recent played move
+in an active game.  It is used to communicate moves between programs in
+automatic play via a network.  This includes correspondence play using e-mail
+and also programs acting as network front ends to human players.
+
+
+16.2.5.23: Opcode "tcgs": telecommunication: game selector
+
+The "tcgs" opcode is one of the telecommunication family of opcodes used for
+games conducted via e-mail and similar means.  This opcode takes a single
+operand that is a positive integer.  It is used to select among various games
+in progress between the same sender and receiver.
+
+
+16.2.5.24: Opcode "tcri": telecommunication: receiver identification
+
+The "tcri" opcode is one of the telecommunication family of opcodes used for
+games conducted via e-mail and similar means.  This opcode takes two order
+dependent string operands.  The first operand is the e-mail address of the
+receiver of the EPD record.  The second operand is the name of the player
+(program or human) at the address who is the actual receiver of the EPD record.
+
+
+16.2.5.25: Opcode "tcsi": telecommunication: sender identification
+
+The "tcsi" opcode is one of the telecommunication family of opcodes used for
+games conducted via e-mail and similar means.  This opcode takes two order
+dependent string operands.  The first operand is the e-mail address of the
+sender of the EPD record.  The second operand is the name of the player
+(program or human) at the address who is the actual sender of the EPD record.
+
+
+16.2.5.26: Opcode "v0": variation name (primary, also "v1" though "v9")
+
+The opcode "v0" (lower case letter "v", digit character zero) indicates a top
+level variation name that applies to the given position.  It is the first of
+ten ranked variation names, each of which has a mnemonic formed from the lower
+case letter "v" followed by a single decimal digit.  Each of these opcodes
+takes either a single string operand or no operand at all.
+
+This ten member variation name family of opcodes is intended for use as
+traditional variation names for a complete game or game fragment.  The usual
+processing of these opcodes are as follows:
+
+1) At the beginning of a game (or game fragment), a move sequence scanning
+program initializes each element of its set of ten variation name string
+registers to be null.
+
+2) As the EPD record for each position in the game is processed, the variation
+name operations are interpreted from left to right.  (Actually, all operations
+in n EPD record are interpreted from left to right.)  Because operations appear
+in ASCII order according to their opcode mnemonics, opcode "v0" (if present)
+will be handled prior to all other opcodes, then opcode "v1" (if present), and
+so forth until opcode "v9" (if present).
+
+3) The processing of opcode "vN" (0 <= N <= 9) involves two steps.  First, all
+variation name string registers with an index equal to or greater than N are
+set to null.  (This is the set "vN" though "v9".)  Second, and only if a string
+operand is present, the value of the corresponding variation name string
+register is set equal to the string operand.
+
+
+17: Alternative chesspiece identifier letters
+
+English language piece names are used to define the letter set for identifying
+chesspieces in PGN movetext.  However, authors of programs which are used only
+for local presentation or scanning of chess move data may find it convenient to
+use piece letter codes common in their locales.  This is not a problem as long
+as PGN data that resides in archival storage or that is exchanged among
+programs still uses the SAN (English) piece letter codes: "PNBRQK".
+
+For the above authors only, a list of alternative piece letter codes are
+provided:
+
+Language     Piece letters (pawn knight bishop rook queen king)
+----------   --------------------------------------------------
+Czech        P J S V D K
+Danish       B S L T D K
+Dutch        O P L T D K
+English      P N B R Q K
+Estonian     P R O V L K
+Finnish      P R L T D K
+French       P C F T D R
+German       B S L T D K
+Hungarian    G H F B V K
+Icelandic    P R B H D K
+Italian      P C A T D R
+Norwegian    B S L T D K
+Polish       P S G W H K
+Portuguese   P C B T D R
+Romanian     P C N T D R
+Spanish      P C A T D R
+Swedish      B S L T D K
+
+
+18: Formal syntax
+
+<PGN-database> ::= <PGN-game> <PGN-database>
+                   <empty>
+
+<PGN-game> ::= <tag-section> <movetext-section>
+
+<tag-section> ::= <tag-pair> <tag-section>
+                  <empty>
+
+<tag-pair> ::= [ <tag-name> <tag-value> ]
+
+<tag-name> ::= <identifier>
+
+<tag-value> ::= <string>
+
+<movetext-section> ::= <element-sequence> <game-termination>
+
+<element-sequence> ::= <element> <element-sequence>
+                       <recursive-variation> <element-sequence>
+                       <empty>
+
+<element> ::= <move-number-indication>
+              <SAN-move>
+              <numeric-annotation-glyph>
+
+<recursive-variation> ::= ( <element-sequence> )
+
+<game-termination> ::= 1-0
+                       0-1
+                       1/2-1/2
+                       *
+<empty> ::=
+
+
+19: Canonical chess position hash coding
+
+*** This section is under development.
+
+
+20: Binary representation (PGC)
+
+*** This section is under development.
+
+The binary coded version of PGN is PGC (PGN Game Coding).  PGC is a binary
+representation standard of PGN data designed for the dual goals of storage
+efficiency and program I/O.  A file containing PGC data should have a name with
+a suffix of ".pgc".
+
+Unlike PGN text files that may have locale dependent representations for
+newlines, PGC files have data that does not vary due to local processing
+environment.  This means that PGC files may be transferred among systems using
+general binary file methods.
+
+PGC files should be used only when the use of PGN is impractical due to time
+and space resource constraints.  As the general level of processing
+capabilities increases, the need for PGC over PGN will decrease.  Therefore,
+implementors are encouraged not to use PGC as the default representation
+because it is much more difficult (than PGN) to understand without proper
+software.
+
+PGC data is composed of a sequence of PGC records.  Each record is composed of
+a sequence of one or more bytes.  The first byte is the PGN record marker and
+it specifies the interpretation of the remaining portion of the record.  This
+remaining portion is composed of zero or more PGN record items.  Item types
+include move sequences, move sets, and character strings.
+
+
+20.1: Bytes, words, and doublewords
+
+At the lowest level, PGC binary data is organized as bytes, words (two
+contiguous bytes), and doublewords (four contiguous bytes).  All eight bits of
+a byte are used.  Longwords (eight contiguous bytes) are not used.  Integer
+values are stored using two's complement representation.  Integers may be
+signed or unsigned depending on context.  Multibyte integers are stored in
+low-endian format with the least significant byte appearing first.
+
+A one byte integer item is called "int-1".  A two byte integer item is called
+"int-2".  A four byte integer item is called "int-4".
+
+Characters are stored as bytes using the ISO 8859/1 Latin-1 (ECMA-94) code set.
+There is no provision for other characters sets or representations.
+
+
+20.2: Move ordinals
+
+A chess move is represented using a move ordinal.  This is a single unsigned
+byte quantity with values from zero to 255.  A move ordinal is interpreted as
+an index into the list of legal moves from the current position.  This list is
+constructed by generating the legal moves from the current position, assigning
+SAN ASCII strings to each move, and then sorting these strings in ascending
+order.  Note that a seven bit ordinal, as used by some inferior representation
+systems, is insufficient as there are some positions that have more than 128
+moves available.
+
+Examples:  From the initial position, there are twenty moves.  Move ordinal 0
+corresponds to the SAN move string "Na3"; move ordinal 1 corresponds to "Nc3",
+move ordinal 4 corresponds to "a3", and move ordinal 19 corresponds to "h4".
+
+Moves can be organized into sequences and sets.  A move sequence is an ordered
+list of moves that are played, one after another from first to last.  A move
+set is a list of moves that are all playable from the current position.
+
+Move sequence data is represented using a length header followed by move
+ordinal data.  The length header is an unsigned integer that may be a byte or a
+word.  The integer gives the number, possibly zero, of following move ordinal
+bytes.  Most move sequences can be represented using just a byte header; these
+are called "mvseq-1" items.  Move sequence data using a word header are called
+"mvseq-2" items.
+
+Move set data is represented using a length header followed by move ordinal
+data.  The length header is an unsigned integer that is a byte.  The integer
+gives the number, possibly zero, of following move ordinal bytes.  All move
+sets are be represented using just a byte header; these are called "mvset-1"
+items.  (Note the implied restriction that a move set can only have a maximum
+of 255 of the possible 256 ordinals present at one time.)
+
+
+20.3: String data
+
+PGC string data is represented using a length header followed by bytes of
+character data.  The length header is an unsigned integer that may be a byte, a
+word, or a doubleword.  The integer gives the number, possibly zero, of
+following character bytes.  Most strings can be represented using just a byte
+header; these are called "string-1" items.  String data using a word header are
+called "string-2" items and string data using a doubleword header are called
+"string-4" items.  No special ASCII NUL termination byte is required for PGC
+storage of a string as the length is explicitly given in the item header.
+
+
+20.4: Marker codes
+
+PGC marker codes are given in hexadecimal format.  PGC marker code zero (marker
+0x00) is the "noop" marker and carries no meaning.  Each additional marker code
+defined appears in its own subsection below.
+
+
+20.4.1: Marker 0x01: reduced export format single game
+
+Marker 0x01 is used to indicate a single complete game in reduced export
+format.  This refers to a game that has only the Seven Tag Roster data, played
+moves, and no annotations or comments.  This record type is used as an
+alternative to the general game data begin/end record pairs described below.
+The general marker pair (0x05/0x06) is used to help represent game data that
+can't be adequately represented in reduced export format.  There are eight
+items that follow marker 0x01 to form the "reduced export format single game"
+record.  In order, these are:
+
+1) string-1 (Event tag value)
+
+2) string-1 (Site tag value)
+
+3) string-1 (Date tag value)
+
+4) string-1 (Round tag value)
+
+5) string-1 (White tag value)
+
+6) string-1 (Black tag value)
+
+7) string-1 (Result tag value)
+
+8) mvseq-2 (played moves)
+
+
+20.4.2: Marker 0x02: tag pair
+
+Marker 0x02 is used to indicate a single tag pair.  There are two items that
+follow marker 0x02 to form the "tag pair" record; in order these are:
+
+1) string-1 (tag pair name)
+
+2) string-1 (tag pair value)
+
+
+20.4.3: Marker 0x03: short move sequence
+
+Marker 0x03 is used to indicate a short move sequence.  There is one item that
+follows marker 0x03 to form the "short move sequence" record; this is:
+
+1) mvseq-1 (played moves)
+
+
+20.4.4: Marker 0x04: long move sequence
+
+Marker 0x04 is used to indicate a long move sequence.  There is one item that
+follows marker 0x04 to form the "long move sequence" record; this is:
+
+1) mvseq-2 (played moves)
+
+
+20.4.5: Marker 0x05: general game data begin
+
+Marker 0x05 is used to indicate the beginning of data for a game.  It has no
+associated items; it is a complete record by itself.  Instead, it marks the
+beginning of PGC records used to describe a game.  All records up to the
+corresponding "general game data end" record are considered to be part of the
+same game.  (PGC record type 0x01, "reduced export format single game", is not
+permitted to appear within a general game begin/end record pair.  The general
+game construct is to be used as an alternative to record type 0x01 in those
+cases where the latter is too restrictive to contain the data for a game.)
+
+
+20.4.6: Marker 0x06: general game data end
+
+Marker 0x06 is used to indicate the end of data for a game.  It has no
+associated items; it is a complete record by itself.  Instead, it marks the end
+of PGC records used to describe a game.  All records after the corresponding
+(and earlier appearing) "general game data begin" record are considered to be
+part of the same game.
+
+
+20.4.7: Marker 0x07: simple-nag
+
+Marker 0x07 is used to indicate the presence of a simple NAG (Numeric
+Annotation Glyph).  This is an annotation marker that has only a short type
+identification and no operands.  There is one item that follows marker 0x07 to
+form the "simple-nag" record; this is:
+
+1) int-1 (unsigned NAG value, from 0 to 255)
+
+
+20.4.8: Marker 0x08: rav-begin
+
+Marker 0x08 is used to indicate the beginning of an RAV (Recursive Annotation
+Variation).  It has no associated items; it is a complete record by itself.
+Instead, it marks the beginning of PGC records used to describe a recursive
+annotation.  It is considered an opening bracket for a later rav-end record;
+the recursive annotation is completely described between the bracket pair.  The
+rav-begin/data/rav-end structures can be nested.
+
+
+20.4.9: Marker 0x09: rav-end
+
+Marker 0x09 is used to indicate the end of an RAV (Recursive Annotation
+Variation).  It has no associated items; it is a complete record by itself.
+Instead, it marks the end of PGC records used to describe a recursive
+annotation.  It is considered a closing bracket for an earlier rav-begin
+record; the recursive annotation is completely described between the bracket
+pair.  The rav-begin/data/rav-end structures can be nested.
+
+
+20.4.10: Marker 0x0a: escape-string
+
+Marker 0x0a is used to indicate the presence of an escape string.  This is a
+string represented by the use of the percent sign ("%") escape mechanism in
+PGN.  The data that is escaped is the sequence of characters immediately
+follwoing the percent sign up to but not including the terminating newline.  As
+is the case with the PGN percent sign escape, the use of a PGC escape-string
+record is limited to use for non-archival data.  There is one item that follows
+marker 0x0a to form the "escape-string" record; this is the string data being
+escaped:
+
+1) string-2 (escaped string data)
+
+
+21: E-mail correspondence usage
+
+*** This section is under development.
+
+
+Standard: EOF
diff --git a/rules and standards/WBCA_Blitz_Rules.txt b/rules and standards/WBCA_Blitz_Rules.txt
new file mode 100755
index 0000000..34f84c8
--- /dev/null
+++ b/rules and standards/WBCA_Blitz_Rules.txt
@@ -0,0 +1,229 @@
+
+        The following is the current (December 15, 1993) complete offi-
+cial rules of the World Blitz Chess Association (WBCA) for Blitz
+(SD Game/5) chess.  It is reprinted with permission for non-commercial
+use only.  All other rights reserved.
+
+        The WBCA does not license tournament directors for its sanc-
+tioned events, but accepts the licensing of other organizations such as
+the U.S. Chess Federation and FIDE for tournament directors or arbiters
+as evidence of qualification.  For additional information on holding of-
+ficial WBCA tournaments, club affiliation or WBCA  membership, see the
+contact information at the end of these rules.
+
+        The U. S. Chess Federation sanctions and rates Quick Chess tour-
+naments with time controls from SD Game/10 to SD Game/29, but true Blitz
+(SD Game/5) is sanctioned and rated by the WBCA.
+
+        Every effort has been made to transcribe these rules exactly as
+distributed by the WBCA except for the minor reformatting required to
+allow for differences in fonts, line widths, etc.  As distributed by the
+WBCA, the rules are on two sheets, but can easily be copied on one sheet
+front and back with an inch left at the bottom of the second page for
+your personal tournament notes!
+
+Mike Burger, UH Chess Club
[email protected]
+
+   ______________________Begin Official Rules___________________________
+
+                       Rerevised WBCA Blitz Rules
+                           November 12, 1992
+
+    Approved by the ProChess committee of Nick Defirmian, Max Dlugy,
+                   Yasser Seirawan and Walter Browne
+
+1)      Each player must make all his moves in the five minutes allotted
+on his clock.  This is the standard international Blitz time limit for
+all WBCA events.  It is the only time limit which will be WBCA rated.
+
+2)      All the clocks must have a special device, usually called a
+"flag" marking the end for the time control period.  Either player may
+object to using a computer clock provided they produce a clock with a
+standard face.  In the event that both players prefer their own standard
+face clock, the player with Black will have the choice each game.
+
+3)      Before play begins both players should inspect the position of
+the pieces and the setting of the clock, since once each side has made a
+move all claims are null and void.
+
+4)      Each player must push the clock with the same hand he uses to
+move his pieces. Exception: only during castling may a player use both
+hands.  Also when capturing, may only one hand be used.  The first in-
+fraction will get a warning, the second a one minute penalty and the
+third will result in the loss of the game.
+
+5)      The arbiter should state at the start of the event the direction
+the clocks are to face, and the player with the Black pieces then de-
+cides which side he will play with that opponent.
+
+6)      Except for pushing the clock neither player should touch the
+clock except:
+
+        a) to straighten it.
+
+        b) If either player knocks over the clock his opponent gets one
+minute added to his clock.
+
+        c) If your opponent's clock does not tick you may push his side
+down and repunch your side; however, if this procedure is unsatisfacto-
+ry, please call for a director.
+
+        d) Each player must always be allowed to push the clock after
+their move is made.  Also neither player should keep his hand on or
+hover over the clock.
+
+7)      Defining a win
+
+        A game is won by the player:
+
+        a) who has mated his opponent's king.
+
+        b) whose opponent resigns.
+
+        c) whose opponent's flag falls first, at any time before the
+game is otherwise ended, provided he points it out and neutralizes the
+clock while his own flag is still up and that he still has mating ma-
+terial.
+
+                1.) Either two minor pieces (except K v K+N+N), a pawn
+or a rook will be sufficient mating material.  No trick mates are al-
+lowed which means a lone knight or bishop is insufficient unless a
+forced win can be demonstrated.
+
+8)      Defining a draw
+
+        A game is a draw:
+
+        a) If one of the kings is stalemated even if a fallen flag is
+claimed simultaneously.
+
+        b) By agreement between the players during a game only.
+
+        c) If the flag of one player falls after the flag of the other
+player has already fallen and a win has not been claimed.
+
+        d) To claim a draw by perpetual check, a four-time repetition is
+necessary with the player counting 1,2,3,4 etc. out loud so as to make
+it quite clear and easier for arbiters to assist.  Claimant should stop
+the clock after the 4th repetition.
+
+        e) If both players each have just one identical piece either may
+claim a draw by stopping the clock if neither side can show a forced
+win.
+
+        f) If one player has insufficient mating material when his
+opponent's flag falls or makes an illegal move.
+
+        g) In K+bishop vs K+bishop of opposite colors with only 1 pawn
+on the board, or in 2 vs 1 in a clearly blockaded position, a draw can
+be claimed by stopping the clocks and summoning an arbiter if necessary
+provided there is no forced win.
+
+        h) K+rook pawn vs K can be claimed as a draw once the defender
+is on the rook file in front of the pawn. K+pawn vs K can be claimed as
+a draw once the defender is immediately on the square directly in front
+of the pawn as long as it's not on the 7th rank.
+
+                             Miscellaneous
+
+9)      If a player accidentally displaces one or more pieces, he shall
+replace them on his own time.  If it is necessary, his opponent may
+start the opponent's clock without making a move in order to make sure
+that the culprit uses his own time while replacing the pieces.  If a
+player first touches one piece, then moves another; his opponent can
+restart the player's clock and make him move the first piece touched.
+Finally, it is unsportsmanly to knock over any pieces then punch the
+clock.  For a first offense the player will get a warning (unless he
+causes his opponent's flag to fall, in which case the offended shall get
+1 minute extra on his clock); for a second offense a 1 minute add on
+will be imposed; for a third offense he shall forfeit the game.
+Thereafter the arbiter may use other penalties or expel a player from
+the event for repeated offenses.
+
+10)     In case of a dispute either player may stop the clock while the
+arbiter is being summoned.  In any unclear situation the arbiter will
+consider the testimony of both players and any reliable witnesses before
+rendering his decision, which in all cases will be final.
+
+11)     The arbiter shall not pick up the clock except in the case of a
+dispute when both players allow him to do so.
+
+12)     Spectators and players in another game are not to speak or oth-
+erwise interfere in another game.  If a spectator interferes in any way
+such as by calling attention to a flag fall or an illegal move, the ar-
+biter may cancel the game and rule that a new game be played in its
+stead.  and he may also expel the offending party from the playing room.
+The arbiter should also be silent about illegal moves or flag falls (un-
+less there are sufficient arbiters and they have agreed with the players
+to call them before the event started) as this is entirely the responsi-
+bility of the players.
+
+13)     When a clear drawn position is reached either player may stop
+the clocks and appeal to the arbiter for a draw.
+
+        a) If the arbiter allows a draw the game is over.
+
+        b) If the appeal is rejected then 1 minute penalty is imposed on
+the player who stopped the clock.
+
+14)     A player who has played an illegal move must retract it and make
+a legal move on his own time.  If no legal move exists with that piece
+then he may make any legal move.  Illegal moves unoticed by both players
+cannot be corrected afterwards, nor can they become the basis for making
+a claim, although a piece once touched must be moved.  An illegal move
+is completed when the player neutralizes the clock, whereupon the op-
+ponent may claim a win provided he has mating material.
+
+15)     A legal move is completed when the hand leaves the piece.
+
+16)     Moving the King next to another King is illegal, however neither
+player can play King takes King! This cheap shot will not be tolerated!
+In that case you can claim a win because of an illegal move.
+
+17)     If a player promotes a pawn and leaves the pawn on the board the
+opponent only has the option of stopping the clocks while a replacement
+piece is found.
+
+18)     An arbiter may determine that a clock is defective and may
+change clocks at his discretion.
+
+19)     Before a tournament the organizers should post at least 2 copies
+of the complete Blitz rules in the tournament area unless there are
+fewer than 25 players, in which case 1 list will suffice.  Posting one
+hour before play would be advisable.
+
+20)     If the king and queen are set up incorrectly then you may castle
+short on the queenside and long on the kingside!
+
+21)     Finally, in all World Blitz Chess Association tournaments the
+decision of the arbiter is final.
+
+        However, for future consideration the WBCA will listen to any
+grievances or wrongdoings on the part of any arbiter or players.
+
+        Eventually the WBCA will publish a list of the best Blitz
+clocks.
+
+        With the rules being clarified in this way, Blitz events will
+run more smoothly because people will enjoy the game more with less ar-
+guments.  Many retired players will return to the game and new players
+will become involved.
+
+   _____________________End Official Rules___________________________
+
+For further World Blitz Chess Association information contact:
+
+W. B. C. A.
+8 Parnassus Road
+Berkeley, CA 94708
+
+Phone (US) 1-510-549-1169
+FAX   (US) 1-510-486-8078
+
+BLITZ CHESS is published quarterly by the W. B. C. A.
+GM Walter Browne, Editor in Chief
+Sam Parazette, Database & Ratings Director
+Kelly Clarke, Assistant Editor
+ISSN #1053-3087
+
diff --git a/rules and standards/fen.doc b/rules and standards/fen.doc
new file mode 100755
index 0000000..da5570c
--- /dev/null
+++ b/rules and standards/fen.doc
@@ -0,0 +1,130 @@
+
+Opening classification uses modified FEN notation, i.e. the halfmove and
+fullmove numbers are dropped since these are irrelvant for opening positions.
+
+---
+
+16.1.1: History
+
+FEN is based on a 19th century standard for position recording designed by the
+Scotsman David Forsyth, a newspaper journalist.  The original Forsyth standard
+has been slightly extended for use with chess software by Steven Edwards with
+assistance from commentators on the Internet.  This new standard, FEN, was
+first implemented in Edwards' SAN Kit.
+
+16.1.2: Uses for a position notation
+
+Having a standard position notation is particularly important for chess
+programmers as it allows them to share position databases.  For example,
+there exist standard position notation databases with many of the classical
+benchmark tests for chessplaying programs, and by using a common position
+notation format many hours of tedious data entry can be saved.  Additionally,
+a position notation can be useful for page layout programs and for confirming
+position status for e-mail competition.
+
+Many interesting chess problem sets represented using FEN can be found at the
+chess.uoknor.edu ftp site in the directory pub/chess/SAN_testsuites.
+
+
+16.1.3: Data fields
+
+FEN specifies the piece placement, the active color, the castling
+availability, the en passant target square, the halfmove clock, and the
+fullmove number.  These can all fit on a single text line in an easily
+read format.  The length of a FEN position description varies somewhat
+according to the position. In some cases, the description could be eighty
+or more characters in length and so may not fit conveniently on some
+displays.  However, these positions aren't too common.
+
+A FEN description has six fields.  Each field is composed only of non-blank
+printing ASCII characters.  Adjacent fields are separated by a single ASCII
+space character.
+
+
+16.1.3.1: Piece placement data
+
+The first field represents the placement of the pieces on the board.  The
+board contents are specified starting with the eighth rank and ending with
+the first rank.  For each rank, the squares are specified from file a to
+file h.  White pieces are identified by uppercase SAN piece letters
+("PNBRQK") and black pieces are identified by lowercase SAN piece letters
+("pnbrqk").  Empty squares are represented by the digits one through eight;
+the digit used represents the count of contiguous empty squares along a
+rank.  A solidus character "/" is used to separate data of adjacent ranks.
+
+
+16.1.3.2: Active color
+
+The second field represents the active color.  A lower case "w" is used if
+White is to move; a lower case "b" is used if Black is the active player.
+
+
+16.1.3.3: Castling availability
+
+The third field represents castling availability.  This indicates potential
+future castling that may of may not be possible at the moment due to blocking
+pieces or enemy attacks.  If there is no castling availability for either
+side, the single character symbol "-" is used.  Otherwise, a combination of
+from one to four characters are present.  If White has kingside castling
+availability, the uppercase letter "K" appears.  If White has queenside
+castling availability, the uppercase letter "Q" appears.  If Black has
+kingside castling availability, the lowercase letter "k" appears.  If
+Black has queenside castling availability, then the lowercase letter "q"
+appears.  Those letters which appear will be ordered first uppercase before
+lowercase and second kingside before queenside.  There is no white space
+between the letters.
+
+
+16.1.3.4: En passant target square
+
+The fourth field is the en passant target square.  If there is no en passant
+target square then the single character symbol "-" appears.  If there is an
+en passant target square then is represented by a lowercase file character
+immediately followed by a rank digit.  Obviously, the rank digit will be "3"
+following a white pawn double advance (Black is the active color) or else be
+the digit "6" after a black pawn double advance (White being the active
+color).
+
+An en passant target square is given if and only if the last move was a pawn
+advance of two squares.  Therefore, an en passant target square field may have
+a square name even if there is no pawn of the opposing side that may
+immediately execute the en passant capture.
+
+
+16.1.3.5: Halfmove clock
+
+The fifth field is a nonnegative integer representing the halfmove clock.
+This number is the count of halfmoves (or ply) since the last pawn advance
+or capturing move.  This value is used for the fifty move draw rule.
+
+
+16.1.3.6: Fullmove number
+
+The sixth and last field is a positive integer that gives the fullmove number.
+This will have the value "1" for the first move of a game for both White and
+Black.  It is incremented by one immediately after each move by Black.
+
+
+16.1.4: Examples
+
+Here's the FEN for the starting position:
+
+rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
+
+And after the move 1. e4:
+
+rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1
+
+And then after 1. ... c5:
+
+rnbqkbnr/pp1ppppp/8/2p5/4P3/8/PPPP1PPP/RNBQKBNR w KQkq c6 0 2
+
+And then after 2. Nf3:
+
+rnbqkbnr/pp1ppppp/8/2p5/4P3/5N2/PPPP1PPP/RNBQKB1R b KQkq - 1 2
+
+For two kings on their home squares and a white pawn on e2 (White to move)
+with thirty eight full moves played with five halfmoves since the last pawn
+move or capture:
+
+4k3/8/8/8/8/8/4P3/4K3 w - - 5 39