I'd like to hear from everyone who is trying to interface their own
-chess engine to xboard/WinBoard. Please email me,
-tim@tim-mann.org. Also, please join
-the mailing list for authors of xboard/WinBoard compatible chess
-engines. The list is now hosted by Yahoo Groups; you can join at http://www.egroups.com/group/chess-engines, or you can read the
+chess engine to xboard/WinBoard. Please join the mailing list for
+authors of xboard/WinBoard compatible chess engines and post a message
+about what you're doing. The list is now hosted by Yahoo Groups; you
+can join at http://groups.yahoo.com/group/chess-engines, or you can read the
list there without joining. The list is filtered to prevent spam.
| unknown | Unknown variant (not supported)
@@ -615,7 +617,20 @@ below.
sd DEPTH
The engine should limit its thinking to DEPTH ply.
The commands "level" or "st" and "sd" can be used together in an orthogonal way.
-If both are issued, the engine should observe both limitations.
+If both are issued, the engine should observe both limitations:
+In the protocol, the "sd" command isn't a time control. It doesn't
+say that your engine has unlimited time but must search to exactly the
+given depth. It says that you should pay attention to the time
+control as normal, but cut off the search at the specified depth even
+if you have time to search deeper. If you don't have time to search
+to the specified depth, given your normal time management algorithm,
+then you will want to stop sooner than the given depth.
+
+The "new" command should set the search depth back to unlimited. This
+is already stated in the spec. The "level" command should not affect
+the search depth. As it happens, xboard/WinBoard currently always
+sends sd (if needed) right after level, but that isn't part of the
+spec.
nps NODE_RATE
@@ -655,7 +670,7 @@ otim clock with the opposite color.
that many engines implement it wrong.
The clocks in fact always remain with the color.
Which clock reading is relayed with "time", and which by "otim", is determined by which side the engine plays.
-Not that the way the clocks operate and receive extra time (in accordance with the selected time control)
+Note that the way the clocks operate and receive extra time (in accordance with the selected time control)
is not affected in any way by which moves are made by the engine, which by the opponent, and which were forced.
@@ -818,9 +833,16 @@ The setboard command is the new way to set up positions, beginning
in protocol version 2. It is not used unless it has been selected
with the feature command. Here FEN is a position in Forsythe-Edwards
Notation, as defined in the PGN standard.
-In FRC or CRC, WinBoard will use Shredder-FEN or X-FEN standard,
-i.e. it can use the rook-file indicator letter to represent a castling right (like HAha)
-whenever it wants, but if it uses KQkq, this will always refer to the outermost rook on the given side
+Note that this PGN standard referred to here
+only applies to normal Chess;
+Obviously in variants that cannot be described by a FEN for normal Chess,
+e.g. because the board is not 8x8, other pieces then PNBRQK participate,
+there are holdings that need to be specified, etc.,
+xboard will use a FEN format that is standard or suitable for that varant.
+In particular, in FRC or CRC, WinBoard will use Shredder-FEN or X-FEN standard,
+i.e. it can use the rook-file indicator letter to represent a castling right
+(like HAha) whenever it wants, but if it uses KQkq, this will always refer
+to the outermost rook on the given side.
Illegal positions: Note that either setboard or edit can
@@ -1004,6 +1026,75 @@ paused thinking or pondering (if any) resumes from exactly where it
left off, and the clock of the player on move resumes running from
where it stopped.
+
+
+ memory N
+
+This command informs the engine on how much memory it is allowed to use maximally, in MegaBytes.
+On receipt of this command, the engine should adapt the size of its hash tables accordingly.
+This command does only fix the total memory use,
+the engine has to decide for itself
+(or be configured by the user by other means)
+how to divide up the available memory between the various tables it wants to use
+(e.g. main hash, pawn hash, tablebase cache, bitbases).
+This command will only be sent to engines that have requested it through the memory feature,
+and only at the start of a game,
+as the first of the commands to relay engine option settings just before each "new" command.
+
+
+
+ cores N
+
+This command informs the engine on how many CPU cores it is allowed to use maximally.
+This could be interpreted as the number of search threads for SMP engines.
+(Threads that do not consume significant amounts of CPU time, like I/O threads, need not be included in the count.)
+This command will only be sent to engines that have requested it through the smp feature.
+The engine should be able to respond to the "cores" command any time during a game,
+but it is allowed to finish a search in progress before procesing the command.
+(Obeying the command should take priority over finishing a ponder search, though.)
+In any case it will be sent at the start of every game
+as the last command to relay engine option settings before the "new" command.
+
+
+
+ egtpath TYPE PATH
+
+This command informs the engine in which directory (given by the PATH argument)
+it can find end-game tables of the specified TYPE.
+The TYPE argument can be any character string which does not contain spaces.
+Currently nalimov and scorpio are defined types,
+for Nalimov tablebases and Scorpio bitbases, respectively,
+but future developers of other formats are free to define their own format names.
+The GUI simply matches the TYPE names the engine says it supports
+with those that the user supplied when configuring xboard.
+For every match, it sends a separate "y" command.
+The PATH argument would normally (for Nalimov) be the pathname of the directory the EGT files are in,
+but could also be the name of a file, or in fact anything the particular EGT type requires.
+It is upto the developer of the EGT format to specify the syntax of this parameter.
+This command will only be sent to engines that have told the GUI they support EGTs of the given TYPE
+through the egt feature.
+It will be sent at the start of each game, before the "new" command.
+
+
+
+ option NAME [VALUE]
+
+This command changes the setting of the option NAME defined by the engine
+(through an earlier feature command)
+to the given VALUE.
+XBoard will in general have no idea what the option means,
+and will send the command only when a user changes the value of this option through a menu,
+or at startup of the engine
+(before the first 'cores' command or, if that is not sent, the first 'new' command)
+in reaction to command-line options.
+The NAME echoes back to the engine the string that was identified as an option NAME
+in the feature command defining the option.
+The VALUE is of the type (numeric or text or absent) that was implied by the option type
+specified in this feature command,
+i.e. with 'spin' and 'check' options VALUE will be a decimal integer (in the latter case 0 or 1),
+with 'combo' and 'string' options VALUE will be a text string,
+and with 'button' and 'save' options no VALUE will be sent at all.
+
Bughouse commands:
@@ -1252,9 +1343,9 @@ Zippy mode.) It is recommended that you set this feature to the
correct value for your engine (just "normal" in most cases) rather
than leaving the default in place, so that the user will get an
appropriate error message if he tries to play a variant that your
-engine does not support.
+engine does not support.
-If your engine can play variants on a deviating board size,
+If your engine can play variants on a deviating board size,
like capablanca on an 8x8 board, or capablanca crazyhouse,
it can list them amongst the variants with a prefix spcifying board size plus
holdings size, like 8x8+0_capablanca or 10x8+7_capablanca.
@@ -1328,6 +1419,63 @@ engines must refrain from sending the debug output,
or do so at their own risk.
+
+memory (boolean, default 0)
+
+
+If memory=1, the size of the total amount of memory available for the memory-consuming tables of the engine
+(e.g. hash, EGTB cache)
+will be set by the GUI through the "memory" command.
+
+
+
+smp (boolean, default 0)
+
+
+If smp=1, the GUI will send the "cores" command to the engine to inform it how many CPU cores it can use.
+Note that sending smp=1 does not imply the engine can use more than one CPU;
+just that it wants to receive the "cores" command.
+
+
+
+egt (string, see text below)
+
+
+This feature indicates which end-game table formats the engine supports.
+It should be a comma-separated list of format names.
+See under the "egtpath" command in section 8 above.
+If you do not set this feature, xboard will assume the engine does not support end-game tables,
+and will not send any "egtpath" commands to inform the engine about their whereabouts.
+
+
+
+option (string, see text below)
+
+
+This feature is used by the engine to define an option command to appear in a GUI menu,
+so that the user can change the corresponding setting of the engine through the GUI.
+The string describes the option by defining a name, type, current value and (sometimes) the acceptable value range.
+There are six different options types, each requiring a slighly different syntax of the defining string:
+
+feature option="NAME -button"
+
+feature option="NAME -save"
+
+feature option="NAME -check VALUE"
+
+feature option="NAME -string VALUE"
+
+feature option="NAME -spin VALUE MIN MAX"
+
+feature option="NAME -combo CHOICE1 /// CHOICE2 ..."
+
+NAME is an arbitrary alphanumeric string which can contain spaces;
+the oter words in capitals would be replaced by the current (default) setting of the option,
+the minimum or maximum value of numeric (-spin) options,
+or arbitrary text labels (for -combo option).
+In the latter cae, the current value will be preceded by an asterisk.
+
+
done (integer, no default)
@@ -1432,6 +1580,12 @@ This command should thus not be used to offer draws, accept draws,
or make draw-by-rule claims that might not be valid
(because it is not your move, and the opponent already moved without you knowing it yet).
For offering and claiming draws, "offer draw" should be used.
+
+Note to GUI programmers: RESULT commands that the engine sends immediately after its move
+might be detected by the GUI only after the opponent has moved, because of communication
+and scheduling delays, no matter how fast the engine sent it.
+Any judgement of the validity of RESULT claims based on te "current" board position
+will have to account for this uncertainty.
resign
@@ -1720,7 +1874,7 @@ can go negative and then become positive again because of the
increment.)
-
+
The number of moves given in the level command (when non-zero) should
be taken as the number of moves still to do before the specified time
will be added to the clock, if the "level" command is received after
@@ -1739,7 +1893,7 @@ and the engine receives "level 20 22 0" just before move 41,
it should understand that it should do the next 20 moves in 22 minutes
(pehaps because the secondary session was 20 moves per 15 minutes,
and it had 7 minutes left on its clock after the first 40 moves).
-
+
A special rule on some ICS implementations: if you ask for a game with
|
|---|