engine-intf.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
   2 <html>
   3 <head>
   4 <title>Chess Engine Communication Protocol</title>
   5 </head>
   6
   7 <body>
   8 <hr noshade size="2">
   9 <h1>Chess Engine Communication Protocol</h1>
  10 <h2><a href="http://www.tim-mann.org/">Tim Mann</a></h2>
  11 <p>
  12 Last modified on Mon Feb  5 23:23:16 PST 2001 by mann<br>
  13 Version 2; implemented in xboard/WinBoard 4.2.1 and later.<br>
  14 Changes since version 1 are indicated in <font color=red>red</font>.
  15 <hr noshade size="2">
  16
  17 <ul>
  18 <li><a href="#1">1. Introduction</a>
  19 <li><a href="#2">2. Connection</a>
  20 <li><a href="#3">3. Debugging</a>
  21 <li><a href="#4">4. How it got this way</a>
  22 <li><a href="#5">5. WinBoard requires Win32 engines</a>
  23 <li><a href="#6">6. Hints on input/output</a>
  24 <li><a href="#7">7. Interrupts</a>
  25 <li><a href="#8">8. Commands from xboard to the engine</a>
  26 <li><a href="#9">9. Commands from the engine to xboard</a>
  27 <li><a href="#10">10. Thinking Output</a>
  28 <li><a href="#11">11. Time control</a>
  29 <li><a href="#12">12. Analyze Mode</a>
  30 <li><a href="#13">13. Idioms and backward compatibility features</a>
  31 </ul>
  32
  33 <hr noshade size="2">
  34
  35 <h2><a name="1">1. Introduction</a></h2>
  36
  37 <p>
  38 This document is a set of rough notes on the protocol that xboard and
  39 WinBoard use to communicate with gnuchessx and other chess engines.
  40 These notes may be useful if you want to connect a different chess
  41 engine to xboard.  Throughout the notes, "xboard" means both xboard
  42 and WinBoard except where they are specifically contrasted.
  43 </p>
  44
  45 <p>
  46 There are two reasons I can imagine someone wanting to do this:
  47 </p>
  48 <ol>
  49 <li>You have, or are developing, a chess engine but you don't want to
  50 write your own graphical interface.
  51 <li>You have, or are developing,a chess engine, and you want to
  52 interface it to the Internet Chess Server.
  53 </ol>
  54
  55 <p>
  56 In case (2), if you are using xboard, you will need to configure the
  57 "Zippy" code into it, but WinBoard includes this code already.  See
  58 the file <a
  59 href="http://www.tim-mann.org/xboard/zippy.README">zippy.README</a>
  60 in the xboard or WinBoard distribution for more information.
  61
  62 </p>
  63
  64 <p>
  65 These notes are unpolished, but I've attempted to make them complete
  66 in this release.  If you notice any errors, omissions, or misleading
  67 statements, let me know.
  68 </p>
  69
  70 <p>
  71 I'd like to hear from everyone who is trying to interface their own
  72 chess engine to xboard/WinBoard.  Please email me, <a
  73 href="mailto:tim.mann@compaq.com">tim.mann@compaq.com</a>.  Also, please join
  74 the mailing list for authors of xboard/WinBoard compatible chess
  75 engines.  The list is now hosted by egroups.com; you can join at <a
  76 href="http://www.egroups.com/group/chess-engines"
  77 >http://www.egroups.com/group/chess-engines</a>, or you can read the
  78 list there without joining.  The list is filtered to prevent spam.
  79 </p>
  80
  81 <h2><a name="2">2. Connection</a></h2>
  82
  83 <p>
  84 An xboard chess engine runs as a separate process from xboard itself,
  85 connected to xboard through a pair of anonymous pipes.  The engine
  86 does not have to do anything special to set up these pipes.  xboard
  87 sets up the pipes itself and starts the engine with one pipe as its
  88 standard input and the other as its standard output.  The engine then
  89 reads commands from its standard input and writes responses to its
  90 standard output.  This is, unfortunately, a little more complicated to
  91 do right than it sounds; see <a href="#6">section 6</a> below.
  92 </p>
  93
  94 <p>
  95 And yes, contrary to some people's expectations, exactly the same
  96 thing is true for WinBoard.  Pipes and standard input/output are
  97 implemented in Win32 and work fine.  You don't have to use DDE, COM,
  98 DLLs, BSOD, or any of the other infinite complexity that
  99 Microsoft has created just to talk between two programs.  A WinBoard
 100 chess engine is a Win32 console program that simply reads from its
 101 standard input and writes to its standard output.  See sections
 102 <a href="#5">5</a> and <a href="#6">6</a> below for additional details.
 103 </p>
 104
 105 <h2><a name="3">3. Debugging</a></h2>
 106
 107 <p>
 108 To diagnose problems in your engine's interaction with xboard, use the
 109 -debug flag on xboard's command line to see the messages that are
 110 being exchanged.  In WinBoard, these messages are written to the file
 111 WinBoard.debug instead of going to the screen.
 112 </p>
 113
 114 <p>
 115 You can turn debug mode on or off while WinBoard is running by
 116 pressing Ctrl+Alt+F12.  You can turn debug mode on or off while xboard
 117 is running by binding DebugProc to a shortcut key (and pressing the
 118 key!); see the instructions on shortcut keys in the xboard man page.
 119 </p>
 120
 121 <p>
 122 While your engine is running under xboard/WinBoard, you can send a
 123 command directly to the engine by pressing Shift+1 (xboard) or Alt+1
 124 (WinBoard 4.0.3 and later).  This brings up a dialog that you can type
 125 your command into.  Press Shift+2 (Alt+2) instead to send to the
 126 second chess engine in Two Machines mode.  On WinBoard 4.0.2 and earlier,
 127 Ctrl+Alt is used in place of Alt; this had to be changed due to a conflict
 128 with typing the @-sign on some European keyboards.
 129 </p>
 130
 131 <h2><a name="4">4. How it got this way</a></h2>
 132
 133 <p>
 134 Originally, xboard was just trying to talk to the existing
 135 command-line interface of GNU Chess 3.1+ and 4, which was designed
 136 for people to type commands to.  So the communication protocol is very
 137 ad-hoc.  It might have been good to redesign it early on, but because
 138 xboard and GNU Chess are separate programs, I didn't want to force
 139 people to upgrade them together to versions that matched.  I
 140 particularly wanted to keep new versions of xboard working with old
 141 versions of GNU Chess, to make it easier to compare the play of old
 142 and new gnuchess versions.  I didn't foresee the need for a clean
 143 protocol to be used with other chess engines in the future.
 144 </p>
 145
 146 <p>
 147 Circumstances have changed over the years, and now there are many more
 148 engines that work with xboard.  I've had to make the protocol
 149 description more precise, I've added some features that GNU Chess
 150 does not support, and I've specified the standard semantics of a few
 151 features to be slightly different from what GNU Chess 4 does.
 152 </p>
 153
 154 <p>
 155 <font color=red>
 156 This release of the protocol specification is the first to carry a
 157 version number of its own -- version 2.  Previous releases simply
 158 carried a last-modified date and were loosely tied to specific
 159 releases of xboard and WinBoard.  The version number "1" applies
 160 generally to all those older versions of the protocol.
 161 </font>
 162
 163 <font color=red>
 164 <p>Protocol version 2 remains compatible with older engines but has
 165 several new capabilities.  In particular, it adds the
 166 "feature" command, a new mechanism for making backward-compatible
 167 changes and extensions to the protocol.  Engines that do not support a
 168 particular new feature do not have to use it; new features are not
 169 enabled unless the engine specifically requests them using the feature
 170 command.  If an engine does not send the feature command at all, the
 171 protocol behavior is nearly identical to version 1.  Several new
 172 features can be selected by the feature command in version 2,
 173 including the "ping" command (recommended for all engines), the
 174 "setboard" command, and many optional parameters.  Additional features
 175 will probably be added in future versions.
 176 </font>
 177 </p>
 178
 179 <h2><a name="5">5. WinBoard requires Win32 engines</a></h2>
 180
 181 <p>
 182 Due to some Microsoft brain damage that I don't understand, WinBoard
 183 does not work with chess engines that were compiled to use a DOS
 184 extender for 32-bit addressing.  (Probably not with 16-bit DOS or
 185 Windows programs either.)  WinBoard works only with engines that are
 186 compiled for the Win32 API.  You can get a free compiler that targets
 187 the Win32 API from <a href="http://sources.redhat.com/cygwin/"
 188 >http://sources.redhat.com/cygwin/</a>.  I think DJGPP 2.x should also
 189 work if you use the RSXNTDJ extension, but I haven't tried it.  Of
 190 course, Microsoft Visual C++ will work.  Most likely the other
 191 commercial products that support Win32 will work too (Borland, etc.),
 192 but I have not tried them.  Delphi has been successfully used to write
 193 engines for WinBoard; if you want to do this, Tony Werten has donated
 194 some <a href="http://www.tim-mann.org/winboard/delphi.txt" >sample
 195 code</a> that should help you get started.
 196 </p>
 197
 198 <h2><a name="6">6. Hints on input/output</a></h2>
 199
 200 <p>
 201 Beware of using buffered I/O in your chess engine.  The C stdio
 202 library, C++ streams, and the I/O packages in most other languages use
 203 buffering both on input and output.  That means two things.  First,
 204 when your engine tries to write some characters to xboard, the library
 205 stashes them in an internal buffer and does not actually write them to
 206 the pipe connected to xboard until either the buffer fills up or you
 207 call a special library routine asking for it to be flushed.  (In C
 208 stdio, this routine is named <tt>fflush</tt>.)  Second, when your engine tries
 209 to read some characters from xboard, the library does not read just
 210 the characters you asked for -- it reads all the characters that are
 211 currently available (up to some limit) and stashes any characters you
 212 are not yet ready for in an internal buffer.  The next time you ask to
 213 read, you get the characters from the buffer (if any) before the
 214 library tries to read more data from the actual pipe.
 215 </p>
 216
 217 <p>
 218 Why does this cause problems?  First, on the output side, remember
 219 that your engine produces output in small quantities (say, a few
 220 characters for a move, or a line or two giving the current analysis),
 221 and that data always needs to be delivered to xboard/WinBoard for
 222 display immediately.  If you use buffered output, the data you print
 223 will sit in a buffer in your own address space instead of being
 224 delivered.
 225 </p>
 226
 227 <p>
 228 You can usually fix the output buffering problem by asking for the
 229 buffering to be turned off.  In C stdio, you do this by calling
 230 <tt>setbuf(stdout, NULL)</tt>.  A more laborious and error-prone
 231 method is to carefully call <tt>fflush(stdout)</tt> after every line
 232 you output; I don't recommend this.  In C++, you can try
 233 <tt>cout.setf(ios::unitbuf)</tt>, which is documented in current
 234 editions of "The C++ Programming Language," but not older ones.
 235 Another C++ method that might work is
 236 <tt>cout.rdbuf()-&gt;setbuf(NULL, 0)</tt>.  Alternatively, you can
 237 carefully call <tt>cout.flush()</tt> after every line you output;
 238 again, I don't recommend this.
 239 </p>
 240
 241 <p>
 242 Another way to fix the problem is to use unbuffered operating system
 243 calls to write directly to the file descriptor for standard output.
 244 On Unix, this means <tt>write(1, ...)</tt> -- see the man page for write(2).
 245 On Win32, you can use either the Unix-like <tt>_write(1, ...)</tt> or Win32
 246 native routines like <tt>WriteFile</tt>.
 247 </p>
 248
 249 <p>
 250 Second, on the input side, you are likely to want to poll during your
 251 search and stop it if new input has come in.  If you implement
 252 pondering, you'll need this so that pondering stops when the user
 253 makes a move.  You should also poll during normal thinking on your
 254 move, so that you can implement the "?" (move now) command, and so
 255 that you can respond promptly to a "result", "force", or "quit"
 256 command if xboard wants to end the game or terminate your engine.
 257 Buffered input makes polling more complicated -- when you poll, you
 258 must stop your search if there are <em>either</em> characters in the buffer
 259 <em>or</em> characters available from the underlying file descriptor.
 260 </p>
 261
 262 <p>
 263 The most direct way to fix this problem is to use unbuffered operating
 264 system calls to read (and poll) the underlying file descriptor
 265 directly.  On Unix, use <tt>read(0, ...)</tt> to read from standard input, and
 266 use <tt>select()</tt> to poll it.  See the man pages read(2) and select(2).
 267 (Don't follow the example of GNU Chess 4 and use the FIONREAD ioctl to
 268 poll for input.  It is not very portable; that is, it does not exist
 269 on all versions of Unix, and is broken on some that do have it.)  On
 270 Win32, you can use either the Unix-like <tt>_read(0, ...)</tt> or the native
 271 Win32 <tt>ReadFile()</tt> to read.  Unfortunately, under Win32, the function to
 272 use for polling is different depending on whether the input device is
 273 a pipe, a console, or something else.  (More Microsoft brain damage
 274 here -- did they never hear of device independence?)  For pipes, you
 275 can use <tt>PeekNamedPipe</tt> to poll (even when the pipe is unnamed).
 276 For consoles,
 277 you can use <tt>GetNumberOfConsoleInputEvents</tt>.  For sockets only, you can
 278 use <tt>select()</tt>.  It might be possible to use
 279 <tt>WaitForSingleObject</tt> more
 280 generally, but I have not tried it.  Some code to do these things can
 281 be found in Crafty's utility.c, but I don't guarantee that it's all
 282 correct or optimal.
 283 </p>
 284
 285 <p>
 286 A second way to fix the problem might be to ask your I/O library not
 287 to buffer on input.  It should then be safe to poll the underlying
 288 file descriptor as described above.  With C, you can try calling
 289 <tt>setbuf(stdin, NULL)</tt>.  However, I have never tried this.  Also, there
 290 could be problems if you use <tt>scanf()</tt>, at least with certain patterns,
 291 because <tt>scanf()</tt> sometimes needs to read one extra character and "push
 292 it back" into the buffer; hence, there is a one-character pushback
 293 buffer even if you asked for stdio to be unbuffered.  With C++, you
 294 can try <tt>cin.rdbuf()-&gt;setbuf(NULL, 0)</tt>, but again, I have never tried
 295 this.
 296 </p>
 297
 298 <p>
 299 A third way to fix the problem is to check whether there are
 300 characters in the buffer whenever you poll.  C I/O libraries generally
 301 do not provide any portable way to do this.  Under C++, you can use
 302 <tt>cin.rdbuf()-&gt;in_avail()</tt>.  This method has been reported to
 303 work with
 304 EXchess.  Remember that if there are no characters in the buffer, you
 305 still have to poll the underlying file descriptor too, using the
 306 method described above.
 307 </p>
 308
 309 <p>
 310 A fourth way to fix the problem is to use a separate thread to read
 311 from stdin.  This way works well if you are familiar with thread
 312 programming.  This thread can be blocked waiting for input to come in
 313 at all times, while the main thread of your engine does its thinking.
 314 When input arrives, you have the thread put the input into a buffer
 315 and set a flag in a global variable.  Your search routine then
 316 periodically tests the global variable to see if there is input to
 317 process, and stops if there is.  WinBoard and my Win32 ports of ICC
 318 timestamp and FICS timeseal use threads to handle multiple input
 319 sources.
 320 </p>
 321
 322 <h2><a name="7">7. Signals</a></h2>
 323
 324 <p>Engines that run on Unix need to be concerned with two Unix
 325 signals: <tt>SIGTERM</tt> and <tt>SIGINT</tt>.  This applies both to
 326 engines that run under xboard and (the unusual case of) engines that
 327 WinBoard remotely runs on a Unix host using the -firstHost or
 328 -secondHost feature.  It does not apply to engines that run on
 329 Windows, because Windows does not have Unix-style signals.
 330 <font color=red>
 331 Beginning with version 2, you can now turn off the use of
 332 either or both
 333 signals.  See the "feature" command in <a href="#6">section 9</a> below.
 334 </font>
 335 </p>
 336
 337 <p>First, when an engine is sent the "quit" command, it is also given
 338 a <tt>SIGTERM</tt> signal shortly afterward to make sure it goes away.
 339 If your engine reliably responds to "quit", and the signal causes
 340 problems for you, you should either ignore it by calling
 341 <tt>signal(SIGTERM, SIG_IGN)</tt> at the start of your program,
 342 or disable it with the "feature" command.</p>
 343
 344 <p>Second, xboard will send an interrupt signal (<tt>SIGINT</tt>) at
 345 certain times when it believes the engine may not be listening to user
 346 input (thinking or pondering).  WinBoard currently does this only when
 347 the engine is running remotely using the -firstHost or -secondHost
 348 feature, not when it is running locally.  You probably need to know
 349 only enough about this grungy feature to keep it from getting in your
 350 way.
 351 </p>
 352
 353 <p>
 354 The <tt>SIGINT</tt>s are basically tailored to the needs of GNU Chess 4
 355 on systems where its input polling code is broken or disabled.
 356 Because they work in a rather peculiar way, it is recommended that you
 357 either ignore <tt>SIGINT</tt> by having your engine call
 358 <tt>signal(SIGINT, SIG_IGN)</tt>, or disable it with the "feature"
 359 command.</p>
 360
 361 <p>
 362 Here are details for the curious.  If xboard needs to send a command
 363 when it is the chess engine's move (such as before the "?" command),
 364 it sends a <tt>SIGINT</tt> first.  If xboard needs to send commands when it is
 365 not the chess engine's move, but the chess engine may be pondering
 366 (thinking on its opponent's time) or analyzing (analysis or analyze
 367 file mode), xboard sends a <tt>SIGINT</tt> before the first such command only.
 368 Another <tt>SIGINT</tt> is not sent until another move is made, even if xboard
 369 issues more commands.  This behavior is necessary for GNU Chess 4.  The
 370 first <tt>SIGINT</tt> stops it from pondering until the next move, but on some
 371 systems, GNU Chess 4 will die if it receives a <tt>SIGINT</tt> when not
 372 actually thinking or pondering.
 373 </p>
 374
 375 <p>
 376 There are two reasons why WinBoard does not send the Win32 equivalent
 377 of <tt>SIGINT</tt> (which is called <tt>CTRL_C_EVENT</tt>) to local
 378 engines.  First, the Win32 GNU Chess 4 port does not need it.  Second, I
 379 could not find a way to get it to work.  Win32 seems to be designed
 380 under the assumption that only console applications, not windowed
 381 applications, would ever want to send a <tt>CTRL_C_EVENT</tt>.
 382 </p>
 383
 384 <h2><a name="8">8. Commands from xboard to the engine</a></h2>
 385
 386 <p>
 387 All commands from xboard to the engine end with a newline (\n), even
 388 where that is not explicitly stated.  All your output to xboard must
 389 be in complete lines; any form of prompt or partial line will cause
 390 problems.
 391 </p>
 392
 393 <p>
 394 At the beginning of each game, xboard sends an initialization string.
 395 This is currently "new\nrandom\n" unless the user changes it with the
 396 initString or secondInitString option.
 397 </p>
 398
 399 <p>
 400 xboard normally reuses the same chess engine process for multiple
 401 games.  At the end of a game, xboard will send the "force" command
 402 (see below) to make sure your engine stops thinking about the current
 403 position.  It will later send the initString again to start a new
 404 game.  If your engine can't play multiple games, you can disable reuse
 405 <font color=red>
 406 either with the "feature" command (beginning in protocol version
 407 2; see below) or
 408 </font>
 409 with xboard's -xreuse (or -xreuse2) command line
 410 option.  xboard will then ask the process to quit after each game and
 411 start a new process for the next game.
 412 </p>
 413
 414 <dl>
 415 <dt><strong>xboard</strong>
 416 <dd>This command will be sent once immediately after your engine
 417 process is started.  You can use it to put your engine into "xboard
 418 mode" if that is needed.  If your engine prints a prompt to ask for
 419 user input, you must turn off the prompt and output a newline when the
 420 "xboard" command comes in.
 421 <p>
 422
 423 <font color=red>
 424 <dt><strong>protover N</strong>
 425 <dd>Beginning in protocol version 2 (in which N=2), this command will
 426 be sent immediately after the "xboard" command.  If you receive some
 427 other command immediately after "xboard" (such as "new"), you can
 428 assume that protocol version 1 is in use.  The "protover" command is
 429 the only new command that xboard always sends in version 2.  All other
 430 new commands to the engine are sent only if the engine first enables
 431 them with the "feature" command.  Protocol versions will always be
 432 simple integers so that they can easily be compared.
 433
 434 <p>Your engine should reply to the protover command by sending the
 435 "feature" command (see below) with the list of non-default feature
 436 settings that you require, if any.
 437
 438 <p>Your engine should never refuse to run due to receiving a higher
 439 protocol version number than it is expecting!  New protocol versions
 440 will always be compatible with older ones by default; the larger
 441 version number is simply a hint that additional "feature" command
 442 options added in later protocol versions may be accepted.
 443 </font>
 444 <p>
 445
 446 <font color=red>
 447 <dt><strong>accepted</strong>
 448 <dt><strong>rejected</strong>
 449 <dd>These commands may be sent to your engine in reply to the "feature"
 450 command; see its documentation below.
 451 </font>
 452 <p>
 453
 454 <dt><strong>new</strong>
 455 <dd>Reset the board to the standard chess starting position.  Set
 456 White on move.  Leave force mode and set the engine to play Black.
 457 Associate the engine's clock with Black and the opponent's clock with
 458 White.  Reset clocks and time controls to the start of a new game.
 459 Stop clocks.  Do not ponder on this move, even if pondering is on.
 460 Remove any search depth limit previously set by the sd command.
 461 <p>
 462
 463 <dt><strong>variant VARNAME</strong>
 464 <dd>If the game is not standard chess, but a variant, this command is
 465 sent after "new" and before the first move or "edit" command.  Currently
 466 defined variant names are:
 467
 468 <table>
 469 <tr align="left"><th>wildcastle<td>Shuffle chess where king can castle from d file
 470 <tr align="left"><th>nocastle<td>Shuffle chess with no castling at all
 471 <tr align="left"><th>fischerandom<td>Fischer Random (not supported yet)
 472 <tr align="left"><th>bughouse<td>Bughouse, ICC/FICS rules
 473 <tr align="left"><th>crazyhouse<td>Crazyhouse, ICC/FICS rules
 474 <tr align="left"><th>losers<td>Win by losing all pieces or getting mated (ICC)
 475 <tr align="left"><th>suicide<td>Win by losing all pieces including king,
 476 or by having fewer pieces when one player has no legal moves (FICS)
 477 <tr align="left"><th><font color=red>giveaway</font>
 478 <td><font color=red>Win by losing all pieces including king,
 479 or by having no legal moves (ICC)</font>
 480 <tr align="left"><th>twokings<td>Weird ICC wild 9
 481 <tr align="left"><th>kriegspiel<td>Kriegspiel (engines not supported)
 482 <tr align="left"><th>atomic<td>Atomic
 483 <tr align="left"><th>3check<td>Win by giving check 3 times
 484 <tr align="left"><th>unknown<td>Unknown variant (not supported)
 485 </table>
 486 <p>
 487
 488 <dt><strong>quit</strong>
 489 <dd>The chess engine should immediately exit.  This command is used
 490 when xboard is itself exiting, and also between games if the -xreuse
 491 command line option is given (or -xreuse2 for the second engine).
 492 See also <a href="#7">Signals</a> above.
 493 <p>
 494
 495 <dt><strong>random</strong>
 496 <dd>This command is specific to GNU Chess 4.  You can either ignore it
 497 completely (that is, treat it as a no-op) or implement it as GNU Chess
 498 does.  The command toggles "random" mode (that is, it sets random =
 499 !random).  In random mode, the engine adds a small random value to its
 500 evaluation function to vary its play.  The "new" command sets random
 501 mode off.
 502 <p>
 503
 504 <dt><strong>force</strong>
 505 <dd>Set the engine to play neither color ("force mode").  Stop clocks.
 506 The engine should check that moves received in force mode are legal
 507 and made in the proper turn, but should not think, ponder, or make
 508 moves of its own.
 509 <p>
 510
 511 <dt><strong>go</strong>
 512 <dd>Leave force mode and set the engine to play the color that is on
 513 move.  Associate the engine's clock with the color that is on move,
 514 the opponent's clock with the color that is not on move.  Start the engine's
 515 clock.  Start thinking and eventually make a move.
 516 <p>
 517
 518 <dt><font color=red><strong>playother</strong></font>
 519 <dd>
 520 <font color=red>
 521 (This command is new in protocol version 2.  It is not
 522 sent unless you enable it with the feature command.)
 523 Leave force mode and set the engine to play the color that is <i>not</i> on
 524 move.  Associate the opponent's clock with the color that is on move,
 525 the engine's clock with the color that is not on move.  Start the opponent's
 526 clock.  If pondering is enabled, the engine should begin pondering.
 527 If the engine later receives a move, it should start thinking and eventually
 528 reply.
 529 </font>
 530 <p>
 531
 532 <dt><strong>white</strong>
 533 <dd>
 534 <font color=red>
 535 (This command is obsolete as of protocol version 2, but is still
 536 sent in some situations to accommodate older engines unless you disable it
 537 with the feature command.)
 538 </font>
 539 Set White on move.  Set the engine to play Black.  Stop clocks.
 540 <p>
 541
 542 <dt><strong>black</strong>
 543 <dd>
 544 <font color=red>
 545 (This command is obsolete as of protocol version 2, but is still
 546 sent in some situations to accommodate older engines unless you disable it
 547 with the feature command.)
 548 </font>
 549 Set Black on move.  Set the engine to play White.  Stop clocks.
 550 <p>
 551
 552 <dt><strong>level MPS BASE INC</strong>
 553 <dd>Set time controls.  See the <a href="#11">Time Control</a> section below.
 554 <p>
 555
 556 <dt><strong>st TIME</strong>
 557 <dd>Set time controls.  See the <a href="#11">Time Control</a> section
 558 below. The commands "level" and "st" are not used together.
 559 <p>
 560
 561 <dt><strong>sd DEPTH</strong>
 562 <dd>The engine should limit its thinking to DEPTH ply.
 563 <p>
 564
 565 <dt><strong>time N</strong>
 566 <dd>Set a clock that always belongs to the engine.  N is a number in
 567   centiseconds (units of 1/100 second).  Even if the engine changes to
 568   playing the opposite color, this clock remains with the engine.
 569 <p>
 570
 571 <dt><strong>otim N</strong>
 572
 573 <dd>Set a clock that always belongs to the opponent.  N is a number in
 574 centiseconds (units of 1/100 second).  Even if the opponent changes to
 575 playing the opposite color, this clock remains with the opponent.
 576 <p>
 577 If needed for purposes of board display in force mode (where the
 578 engine is not participating in the game) the time clock should be
 579 associated with the last color that the engine was set to play, the
 580 otim clock with the opposite color.
 581 </p>
 582
 583 <p>
 584 <font color=red>
 585 Beginning in protocol version 2, if you can't handle the time and
 586 otim commands, you can use the "feature" command to disable them; see
 587 below.
 588 </font>
 589 The following techniques from older protocol versions also
 590 work: You can ignore the time and otim commands (that is, treat them
 591 as no-ops), or send back "Error (unknown command): time" the first
 592 time you see "time".
 593 </p>
 594
 595 <dt><strong>MOVE</strong>
 596 <dd>See below for the syntax of moves.  If the move is illegal, print
 597 an error message; see the section "<a href="#9">Commands from the engine to
 598 xboard</a>".  If the move is legal and in turn, make it.  If not in force
 599 mode, stop the opponent's clock, start the engine's clock, start
 600 thinking, and eventually make a move.
 601 <p>
 602 When xboard sends your engine a move, it normally sends coordinate
 603 algebraic notation.  Examples:
 604 <p>
 605 <table>
 606 <tr align="left"><td>Normal moves:<td>e2e4
 607 <tr align="left"><td>Pawn promotion:<td>e7e8q
 608 <tr align="left"><td>Castling:<td>e1g1, e1c1, e8g8, e8c8
 609 <tr align="left"><td>Bughouse/crazyhouse drop:<td>P@h3
 610 <tr align="left"><td>ICS Wild 0/1 castling:<td>d1f1, d1b1, d8f8, d8b8
 611 <tr align="left"><td>FischerRandom castling:<td>O-O, O-O-O (oh, not zero)
 612 </table>
 613
 614 <p>
 615 <font color=red>
 616 Beginning in protocol version 2, you can use the feature command
 617 to select SAN (standard algebraic notation) instead; for example, e4,
 618 Nf3, exd5, Bxf7+, Qxf7#, e8=Q, O-O, or P@h3.  Note that the last form,
 619 P@h3, is a extension to the PGN standard's definition of SAN, which does
 620 not support bughouse or crazyhouse.
 621 </font>
 622 </p>
 623
 624 <p>
 625 xboard doesn't reliably detect illegal moves, because it does not keep
 626 track of castling unavailability due to king or rook moves, or en
 627 passant availability.  If xboard sends an illegal move, send back an
 628 error message so that xboard can retract it and inform the user; see
 629 the section "<a href="#9">Commands from the engine to xboard</a>".
 630 </p>
 631
 632 <font color=red>
 633 <dt><strong>usermove MOVE</strong>
 634 <dd>By default, moves are sent to the engine without a command name;
 635 the notation is just sent as a line by itself.
 636 Beginning in protocol version 2, you can use the feature command
 637 to cause the command name "usermove" to be sent before the move.
 638 Example: "usermove e2e4".
 639 </font>
 640 </p>
 641
 642 <dt><strong>?</strong>
 643 <dd>Move now.  If your engine is thinking, it should move immediately;
 644   otherwise, the command should be ignored (treated as a no-op).  It
 645   is permissible for your engine to always ignore the ? command.  The
 646   only bad consequence is that xboard's Move Now menu command will do
 647   nothing.
 648 <p>
 649 It is also permissible for your engine to move immediately if it gets
 650 any command while thinking, as long as it processes the command right
 651 after moving, but it's preferable if you don't do this.  For example,
 652 xboard may send post, nopost, easy, hard, force, quit,
 653 <font color=red>
 654 or other commands
 655 </font>
 656 while the engine is on move.
 657 </p>
 658
 659 <font color=red>
 660 <dt><strong>ping N</strong>
 661 <dd>
 662 In this command, N is a decimal number.  When you receive the command,
 663 reply by sending the string <strong>pong N</strong>, where N is the
 664 same number you received.  Important: You must not reply to a "ping"
 665 command until you have finished executing all commands that you
 666 received before it.  Pondering does not count; if you receive a ping
 667 while pondering, you should reply immediately and continue pondering.
 668 Because of the way xboard uses the ping command, if you implement the
 669 other commands in this protocol, you should never see a "ping" command
 670 when it is your move; however, if you do, you must not send the "pong"
 671 reply to xboard until after you send your move.  For example, xboard
 672 may send "?" immediately followed by "ping".  If you implement the "?"
 673 command, you will have moved by the time you see the subsequent ping
 674 command.  Similarly, xboard may send a sequence like "force", "new",
 675 "ping".  You must not send the pong response until after you have
 676 finished executing the "new" command and are ready for the new game to
 677 start.
 678
 679 <p>
 680 The ping command is new in protocol version 2 and will not be sent
 681 unless you enable it with the "feature" command.  Its purpose is to
 682 allow several race conditions that could occur in previous versions of
 683 the protocol to be fixed, so it is highly recommended that you
 684 implement it.  It is especially important in simple engines that do
 685 not ponder and do not poll for input while thinking, but it is needed in all
 686 engines.
 687 </p>
 688 </font>
 689
 690 <dt><strong>draw</strong>
 691 <dd>The engine's opponent offers the engine a draw.  To accept the
 692 draw, send "offer draw".  To decline, ignore the offer (that is, send
 693 nothing).  If you're playing on ICS, it's possible for the draw offer
 694 to have been withdrawn by the time you accept it, so don't assume the
 695 game is over because you accept a draw offer.  Continue playing until
 696 xboard tells you the game is over.  See also "offer draw" below.
 697 <p>
 698
 699 <dt><strong>result RESULT {COMMENT}</strong>
 700 <dd>After the end of each game, xboard will send you a result command.
 701 You can use this command to trigger learning.  RESULT is either 1-0,
 702 0-1, 1/2-1/2, or *, indicating whether white won, black won, the game
 703 was a draw, or the game was unfinished.  The COMMENT string is purely
 704 a human-readable comment; its content is unspecified and subject to
 705 change.  In ICS mode, it is passed through from ICS uninterpreted.
 706 Example: <pre>result 1-0 {White mates}</pre>
 707 <p>
 708 Here are some notes on interpreting the "result" command.  Some apply
 709 only to playing on ICS ("Zippy" mode).
 710 </p>
 711
 712 <p>
 713 If you won but did not just play a mate, your opponent must have
 714 resigned or forfeited.  If you lost but were not just mated, you
 715 probably forfeited on time, or perhaps the operator resigned manually.
 716 If there was a draw for some nonobvious reason, perhaps your opponent
 717 called your flag when he had insufficient mating material (or vice
 718 versa), or perhaps the operator agreed to a draw manually.
 719 </p>
 720
 721 <p>
 722 You will get a result command even if you already know the game ended
 723 -- for example, after you just checkmated your opponent.  In fact, if
 724 you send the "RESULT {COMMENT}" command (discussed below), you will
 725 simply get the same thing fed back to you with "result" tacked in
 726 front.  You might not always get a "result *" command, however.  In
 727 particular, you won't get one in local chess engine mode when the user
 728 stops playing by selecting Reset, Edit Game, Exit or the like.
 729 </p>
 730
 731 <font color=red>
 732 <dt><strong>setboard FEN</strong>
 733 <dd>The setboard command is the new way to set up positions, beginning
 734 in protocol version 2.  It is not used unless it has been selected
 735 with the feature command.  Here FEN is a position in Forsythe-Edwards
 736 Notation, as defined in the PGN standard.
 737
 738 <p><i>Illegal positions:</i> Note that either setboard or edit can
 739 be used to send an illegal position to the engine.  The user can
 740 create any position with xboard's Edit Position command (even, say,
 741 an empty board, or a board with 64 white kings and no black ones).
 742 If your engine receives a position that it considers illegal,
 743 I suggest that you send the response "tellusererror Illegal position",
 744 and then respond to any attempted move with "Illegal move" until
 745 the next new, edit, or setboard command.</p>
 746 </font>
 747 <p>
 748
 749 <dt><strong>edit</strong>
 750 <dd>
 751 <font color=red>
 752 The edit command is the old way to set up positions.  For compatibility
 753 with old engines, it is still used by default, but new engines may prefer
 754 to use the feature command (see below) to cause xboard to use setboard instead.
 755 </font>
 756 The edit command puts the chess engine into a special mode, where
 757 it accepts the following subcommands:
 758 <table>
 759 <tr align="left"><th>c<td>change current piece color, initially white
 760 <tr align="left"><th>Pa4 (for example)<td>place pawn of current color on a4
 761 <tr align="left"><th>xa4 (for example)<td>empty the square a4 (not used by xboard)
 762 <tr align="left"><th>#<td>clear board
 763 <tr align="left"><th>.<td>leave edit mode
 764 </table>
 765 <font color=red>
 766 See the Idioms section below for additional subcommands used in
 767 ChessBase's implementation of the protocol.
 768 </font>
 769
 770 <p>The edit command does not change the side to move.  To set up a
 771 black-on-move position, xboard uses the following command sequence:
 772 </p>
 773 <pre>
 774     new
 775     force
 776     a2a3
 777     edit
 778     &lt;edit commands&gt;
 779     .
 780 </pre>
 781
 782 <p>
 783 This sequence is used to avoid the "black" command, which is now
 784 considered obsolete and which many engines never did implement as
 785 specified in this document.
 786 </p>
 787
 788 <p>
 789 After an edit command is complete, if a king and a rook are on their
 790 home squares, castling is assumed to be available to them.  En passant
 791 capture is assumed to be illegal on the current move regardless of the
 792 positions of the pawns.  The clock for the 50 move rule starts at
 793 zero, and for purposes of the draw by repetition rule, no prior
 794 positions are deemed to have occurred.
 795 </p>
 796
 797 <dt><strong>hint</strong>
 798 <dd>If the user asks for a hint, xboard sends your engine the command
 799 "hint".  Your engine should respond with "Hint: xxx", where xxx is a
 800 suggested move.  If there is no move to suggest, you can ignore the
 801 hint command (that is, treat it as a no-op).
 802 <p>
 803
 804 <dt><strong>bk</strong>
 805 <dd>If the user selects "Book" from the xboard menu, xboard will send
 806 your engine the command "bk".  You can send any text you like as the
 807 response, as long as each line begins with a blank space or tab (\t)
 808 character, and you send an empty line at the end.  The text pops up in
 809 a modal information dialog.
 810 <p>
 811
 812 <dt><strong>undo</strong>
 813 <dd>If the user asks to back up one move, xboard will send you the
 814 "undo" command.  xboard will not send this command without putting you
 815 in "force" mode first, so you don't have to worry about what should
 816 happen if the user asks to undo a move your engine made.  (GNU Chess 4
 817 actually switches to playing the opposite color in this case.)
 818 <p>
 819
 820 <dt><strong>remove</strong>
 821 <dd>If the user asks to retract a move, xboard will send you the
 822 "remove" command.  It sends this command only when the user is on
 823 move.  Your engine should undo the last two moves (one for each
 824 player) and continue playing the same color.
 825 <p>
 826
 827 <dt><strong>hard</strong>
 828 <dd>Turn on pondering (thinking on the opponent's time, also known as
 829 "permanent brain").  xboard will not make any assumption about what
 830 your default is for pondering or whether "new" affects this setting.
 831 <p>
 832
 833 <dt><strong>easy</strong>
 834 <dd>Turn off pondering.
 835 <p>
 836
 837 <dt><strong>post</strong>
 838 <dd>Turn on thinking/pondering output.
 839 See <a href="#10">Thinking Output</a> section.
 840 <p>
 841
 842 <dt><strong>nopost</strong>
 843 <dd>Turn off thinking/pondering output.
 844 <p>
 845
 846 <dt><strong>analyze</strong>
 847 <dd>Enter analyze mode.  See <a href="#12">Analyze Mode</a> section.
 848 <p>
 849
 850 <dt><strong>name X</strong> <dd>This command informs the engine of its
 851 opponent's name.  When the engine is playing on a chess server, xboard
 852 obtains the opponent's name from the server.
 853 <font color=red>
 854 When the engine is
 855 playing locally against a human user, xboard obtains the user's login
 856 name from the local operating system.  When the engine is playing
 857 locally against another engine, xboard uses either the other engine's
 858 filename or the name that the other engine supplied in the myname
 859 option to the feature command.  By default, xboard uses the name
 860 command only when the engine is playing on a chess server.  Beginning
 861 in protocol version 2, you can change this with the name option to the
 862 feature command; see below.
 863 </font>
 864 <p>
 865
 866 <dt><strong>rating</strong>
 867 <dd>In ICS mode, xboard obtains the ICS opponent's rating from the
 868 "Creating:" message that appears before each game.  (This message may
 869 not appear on servers using outdated versions of the FICS code.)  In
 870 Zippy mode, it sends these ratings on to the chess engine using the
 871 "rating" command.  The chess engine's own rating comes first, and if
 872 either opponent is not rated, his rating is given as 0.
 873 <font color=red>
 874 In the future this command may also be used in other modes, if ratings
 875 are known.
 876 </font>
 877 Example: <pre>rating 2600 1500</pre>
 878 <p>
 879
 880 <font color=red>
 881 <dt><strong>ics HOSTNAME</strong>
 882 <dd>If HOSTNAME is "-", the engine is playing against a local
 883 opponent; otherwise, the engine is playing on an Internet Chess Server
 884 (ICS) with the given hostname.  This command is new in protocol
 885 version 2 and is not sent unless the engine has enabled it with
 886 the "feature" command.  Example: "ics freechess.org"
 887 </font>
 888 <p>
 889
 890 <dt><strong>computer</strong>
 891 <dd>The opponent is also a computer chess engine.  Some engines alter
 892 their playing style when they receive this command.
 893 <p>
 894
 895 <font color=red>
 896 <dt><strong>pause</strong>
 897 <dt><strong>resume</strong>
 898 <dd>(These commands are new in protocol
 899 version 2 and will not be sent unless feature pause=1 is set.  At
 900 this writing, xboard actually does not use the commands at all, but it
 901 or other interfaces may use them in the future.)
 902 The "pause" command puts the engine into a special state where it
 903 does not think, ponder, or otherwise consume significant CPU time.
 904 The current thinking or pondering (if any) is suspended and both
 905 player's clocks are stopped.  The only command that the interface may
 906 send to the engine while it is in the paused state is "resume".  The
 907 paused thinking or pondering (if any) resumes from exactly where it
 908 left off, and the clock of the player on move resumes running from
 909 where it stopped.
 910 </font>
 911 </dl>
 912
 913 <h3>Bughouse commands:</h3>
 914
 915 <p>
 916 xboard now supports bughouse engines when in Zippy mode.  See
 917 <a href="http://www.tim-mann.org/xboard/zippy.README"
 918 >zippy.README</a> for information on Zippy mode and how to turn on the
 919 bughouse support.  The bughouse move format is given above.  xboard
 920 sends the following additional commands to the engine when in bughouse
 921 mode.
 922 Commands to inform your engine of the partner's game state may
 923 be added in the future.
 924 </p>
 925
 926 <dl>
 927 <dt><strong>partner &lt;player&gt;</strong>
 928 <dd>&lt;player&gt; is now your partner for future games.  Example: <pre>partner mann</pre>
 929 <p>
 930
 931 <dt><strong>partner</strong>
 932 <dd>Meaning: You no longer have a partner.
 933 <p>
 934
 935 <dt><strong>ptell &lt;text&gt;</strong>
 936 <dd>Your partner told you &lt;text&gt;, either with a ptell or an ordinary tell.
 937 <p>
 938
 939 <dt><strong>holding [&lt;white&gt;] [&lt;black&gt;]</strong>
 940 <dd>White currently holds &lt;white&gt;; black currently holds &lt;black&gt;.
 941   Example: <pre>holding [PPPRQ] []</pre>
 942
 943 <dt><strong>holding [&lt;white&gt;] [&lt;black&gt;] &lt;color&gt;&lt;piece&gt;</strong>
 944 <dd>White currently holds &lt;white&gt;; black currently holds &lt;black&gt;, after
 945   &lt;color&gt; acquired &lt;piece&gt;.   Example: <pre>holding [PPPRQ] [R] BR</pre>
 946 </dl>
 947
 948 <h2><a name="9">9. Commands from the engine to xboard</a></h2>
 949
 950 <p>
 951 <font color=red>
 952 In general, an engine should not send any output to xboard that is not
 953 described in this document.  As the protocol is extended, newer
 954 versions of xboard may recognize additional strings as commands that
 955 were previously not assigned a meaning.
 956 </font>
 957 </p>
 958
 959 <dl>
 960 <font color=red>
 961 <dt><strong>feature FEATURE1=VALUE1 FEATURE2=VALUE2 ...</strong>
 962
 963 <dd>Beginning with version 2, the protocol includes the "feature"
 964 command, which lets your engine control certain optional protocol
 965 features.  Feature settings are written as FEATURE=VALUE, where
 966 FEATURE is a name from the list below and VALUE is the value to be
 967 assigned.  Features can take string, integer, or boolean values; the
 968 type of value is listed for each feature.  String values are written
 969 in double quotes (for example, <tt>feature myname="Miracle Chess
 970 0.9"</tt>), integers are written in decimal, and boolean values are
 971 written as 0 for false, 1 for true.  Any number of features can be set
 972 in one feature command, or multiple feature commands can be given.
 973
 974 <p>
 975 Your engine should send one or more feature commands immediately after
 976 receiving the "protover" command, since xboard needs to know the
 977 values of some features before sending further commands to the engine.
 978 Because engines that predate protocol version 2 do not send "feature",
 979 xboard uses a timeout mechanism: when it first starts your engine, it
 980 sends "xboard" and "protover N", then listens for feature commands for
 981 two seconds before sending any other commands.  To end this timeout
 982 and avoid the wait, set the feature "done=1" at the end of your last
 983 feature command.  To increase the timeout, if needed, set the feature
 984 "done=0" before your first feature command and "done=1" at the end.
 985 If needed, it is okay for your engine to set done=0 soon as it starts,
 986 even before it receives the xboard and protover commands.  This can be
 987 useful if your engine takes a long time to initialize itself.  It
 988 should be harmless even if you are talking to a (version 1) user
 989 interface that does not understand the "feature" command, since such
 990 interfaces generally ignore commands from the engine that they do not
 991 understand.
 992 </p>
 993
 994 <p>
 995 The feature command is designed to let the protocol change without
 996 breaking engines that were written for older protocol versions.  When
 997 a new feature is added to the protocol, its default value is always
 998 chosen to be compatible with older versions of the protocol that did
 999 not have the feature.  Any feature that your engine does not set in a
1000 "feature" command retains its default value, so as the protocol
1001 changes, you do not have to change your engine to keep up with it
1002 unless you want to take advantage of a new feature.  Because some
1003 features are improvements to the protocol, while others are meant to
1004 cater to engines that do not implement all the protocol features, the
1005 recommended setting for a feature is not always the same as the
1006 default setting.  The listing below gives both default and recommended
1007 settings for most features.
1008 </p>
1009
1010 <p>
1011 You may want to code your engine so as to be able to work with
1012 multiple versions of the engine protocol.  Protocol version 1 does not
1013 send the protover command and does not implement the feature command;
1014 if you send a feature command in protocol version 1, it will have no
1015 effect and there will be no response.  In protocol version 2 or later,
1016 each feature F that you set generates the response "accepted F" if the
1017 feature is implemented, or "rejected F" if it is not.  Thus an engine
1018 author can request any feature without having to keep track of which
1019 protocol version it was introduced in; you need only check whether the
1020 feature is accepted or rejected.  This mechanism also makes it
1021 possible for a user interface author to implement a subset of a
1022 protocol version by rejecting some features that are defined in that
1023 version; however, you should realize that engine authors are likely to
1024 code for xboard and may not be prepared to have a feature that they
1025 depend on be rejected.
1026 </p>
1027
1028 <p>
1029 Here are the features that are currently defined.
1030 </p>
1031
1032 <dl>
1033 <dt><strong>ping</strong> (boolean, default 0, recommended 1)
1034 <dd>If ping=1, xboard may use the protocol's new "ping" command;
1035 if ping=0, xboard will not use the command.
1036
1037 <dt><strong>setboard</strong> (boolean, default 0, recommended 1)
1038 <dd>If setboard=1, xboard will use the protocol's new "setboard" command
1039 to set up positions; if setboard=0, it will use the older "edit" command.
1040
1041 <dt><strong>playother</strong> (boolean, default 0, recommended 1)
1042 <dd>If playother=1, xboard will use the protocol's new "playother" command
1043 when appropriate; if playother=0, it will not use the command.
1044
1045 <dt><strong>san</strong> (boolean, default 0)
1046 <dd>If san=1, xboard will send moves to the engine in standard algebraic
1047 notation (SAN); for example, Nf3.  If san=0, xboard will send moves in
1048 coordinate notation; for example, g1f3.  See MOVE in
1049 <a href="#8">section 8</a> above for more details of both kinds of notation.
1050
1051 <dt><strong>usermove</strong> (boolean, default 0)
1052 <dd>If usermove=1, xboard will send moves to the engine with the
1053 command "usermove MOVE"; if usermove=0, xboard will send just the move,
1054 with no command name.
1055
1056 <dt><strong>time</strong> (boolean, default 1, recommended 1)
1057 <dd>If time=1, xboard will send the "time" and "otim" commands to
1058 update the engine's clocks; if time=0, it will not.
1059
1060 <dt><strong>draw</strong> (boolean, default 1, recommended 1)
1061 <dd>If draw=1, xboard will send the "draw" command if the engine's opponent
1062 offers a draw; if draw=0, xboard will not inform the engine about
1063 draw offers.  Note that if draw=1, you may receive a draw offer while you
1064 are on move; if this will cause you to move immediately, you should set
1065 draw=0.
1066
1067 <dt><strong>sigint</strong> (boolean, default 1)
1068 <dd>If sigint=1, xboard may send SIGINT (the interrupt signal) to
1069 the engine as <a href="#7">section 7</a> above; if sigint=0, it will
1070 not.
1071
1072 <dt><strong>sigterm</strong> (boolean, default 1)
1073 <dd>If sigterm=1, xboard may send SIGTERM (the termination signal) to
1074 the engine as <a href="#7">section 7</a> above; if sigterm=0, it will
1075 not.
1076
1077 <dt><strong>reuse</strong> (boolean, default 1, recommended 1)
1078 <dd>If reuse=1, xboard may reuse your engine for multiple games.  If
1079 reuse=0 (or if the user has set the -xreuse option on xboard's command
1080 line), xboard will kill the engine process after every game and start
1081 a fresh process for the next game.
1082
1083 <dt><strong>analyze</strong> (boolean, default 1, recommended 1)
1084 <dd>If analyze=0, xboard will not try to use the "analyze" command; it
1085 will pop up an error message if the user asks for analysis mode.  If
1086 analyze=1, xboard will try to use the command if the user asks for
1087 analysis mode.
1088
1089 <dt><strong>myname</strong> (string, default determined from engine filename)
1090 <dd>This feature lets you set the name that xboard will use for your
1091 engine in window banners, in the PGN tags of saved game files, and when
1092 sending the "name" command to another engine.
1093
1094 <dt><strong>variants</strong> (string, see text below)
1095 <dd>This feature indicates which chess variants your engine accepts.
1096 It should be a comma-separated list of variant names.  See the table
1097 under the "variant" command in <a href="#8">section 8</a> above.  If
1098 you do not set this feature, xboard will assume by default that your
1099 engine supports all variants.  (However, the -zippyVariants
1100 command-line option still limits which variants will be accepted in
1101 Zippy mode.)  It is recommended that you set this feature to the
1102 correct value for your engine (just "normal" in most cases) rather
1103 than leaving the default in place, so that the user will get an
1104 appropriate error message if he tries to play a variant that your
1105 engine does not support.
1106
1107 <dt><strong>colors</strong> (boolean, default 1, recommended 0)
1108 <dd>If colors=1, xboard uses the obsolete "white" and "black"
1109 commands in a stylized way that works with most older chess engines
1110 that require the commands.  See the "<a href="#13">Idioms</a>" section
1111 below for details.  If colors=0, xboard does not use the "white" and
1112 "black" commands at all.
1113
1114 <dt><strong>ics</strong> (boolean, default 0)
1115 <dd>If ics=1, xboard will use the protocol's new "ics" command
1116 to inform the engine of whether or not it is playing on a chess server;
1117 if ics=0, it will not.
1118
1119 <dt><strong>name</strong> (boolean, see text below)
1120 <dd>If name=1, xboard will use the protocol's "name" command
1121 to inform the engine of the opponent's name; if name=0, it will not.
1122 By default, name=1 if the engine is playing on a chess server; name=0 if not.
1123
1124 <dt><strong>pause</strong> (boolean, default 0)
1125 <dd>If pause=1, xboard may use the protocol's new "pause" command;
1126 if pause=0, xboard assumes that the engine does not support this command.
1127
1128 <dt><strong>done</strong> (integer, no default)
1129 <dd>If you set done=1 during the initial two-second timeout after
1130 xboard sends you the "xboard" command, the
1131 timeout will end and xboard will not look for any more feature
1132 commands before starting normal operation.
1133 If you set done=0, the initial timeout is increased to one hour;
1134 in this case, you must set done=1 before xboard will enter normal operation.
1135 </dl>
1136 </font>
1137 <p>
1138
1139 <dt><strong>Illegal move: MOVE</strong>
1140 <dt><strong>Illegal move (REASON): MOVE</strong>
1141 <dd>If your engine receives a MOVE command that is recognizably a move
1142 but is not legal in the current position, your engine must print an
1143 error message in one of the above formats so that xboard can pass the
1144 error on to the user and retract the move.  The (REASON) is entirely
1145 optional.  Examples:
1146
1147 <pre>
1148   Illegal move: e2e4
1149   Illegal move (in check): Nf3
1150   Illegal move (moving into check): e1g1
1151 </pre>
1152 <p>
1153 Generally, xboard will never send an ambiguous move, so it does not
1154 matter whether you respond to such a move with an Illegal move message
1155 or an Error message.
1156 </p>
1157
1158 <dt><strong>Error (ERRORTYPE): COMMAND</strong>
1159 <dd>If your engine receives a command it does not understand or does
1160 not implement, it should print an error message in the above format so
1161 that xboard can parse it.  Examples:
1162 <pre>
1163   Error (ambiguous move): Nf3
1164   Error (unknown command): analyze
1165   Error (command not legal now): undo
1166   Error (too many parameters): level 1 2 3 4 5 6 7
1167 </pre>
1168
1169 <dt><strong>move MOVE</strong>
1170 <dd>Your engine is making the move MOVE.  Do not echo moves from
1171 xboard with this command; send only new moves made by the engine.
1172
1173 <font color=red>
1174 <p>For the actual move text from your chess engine (in place of MOVE
1175 above), your move should be either
1176 <ul>
1177 <li>in coordinate notation (e.g.,
1178 e2e4, e7e8q) with castling indicated by the King's two-square move (e.g.,
1179 e1g1), or
1180 <li>in Standard Algebraic Notation (SAN) as defined in the
1181 Portable Game Notation standard (e.g, e4, Nf3, O-O, cxb5, Nxe4, e8=Q),
1182 with the extension piece@square (e.g., P@f7) to handle piece placement
1183 in bughouse and crazyhouse.
1184 </ul>
1185 xboard itself also accepts some variants of SAN, but for compatibility
1186 with non-xboard interfaces, it is best not to rely on this behavior.
1187 </p>
1188
1189 <p>Warning: Even though all versions of this protocol specification
1190 have indicated that xboard accepts SAN moves, some non-xboard
1191 interfaces are known to accept only coordinate notation.  See the
1192 Idioms section for more information on the known limitations of some
1193 non-xboard interfaces.  It should be safe to send SAN moves if you
1194 receive a "protover 2" (or later) command from the interface, but
1195 otherwise it is best to stick to coordinate notation for maximum
1196 compatibility.  An even more conservative approach would be for your
1197 engine to send SAN to the interface only if you have set feature san=1
1198 (which causes the interface to send SAN to you) and have received
1199 "accepted san" in reply.
1200 </p>
1201 </font>
1202
1203 <dt><strong>RESULT {COMMENT}</strong> <dd>When your engine detects
1204 that the game has ended by rule, your engine must output a line of the
1205 form "RESULT {comment}" (without the quotes), where RESULT is a PGN
1206 result code (1-0, 0-1, or 1/2-1/2), and comment is the reason.  Here
1207 "by rule" means that the game is definitely over because of what
1208 happened on the board.  In normal chess, this includes checkmate,
1209 stalemate, triple repetition, the 50 move rule, or insufficient
1210 material; it does not include loss on time or the like.
1211 Examples:
1212 <pre>
1213   0-1 {Black mates}
1214   1-0 {White mates}
1215   1/2-1/2 {Draw by repetition}
1216   1/2-1/2 {Stalemate}
1217 </pre>
1218
1219 <p>
1220 xboard relays the result to the user, the ICS, the other engine in Two
1221 Machines mode, and the PGN save file as required.
1222 </p>
1223
1224 <dt><strong>resign</strong>
1225 <dd>If your engine wants to resign, it can send the command "resign".
1226 Alternatively, it can use the "RESULT {comment}" command if the string
1227 "resign" is included in the comment; for example "0-1 {White
1228 resigns}".  xboard relays the resignation to the user, the ICS, the
1229 other engine in Two Machines mode, and the PGN save file as required.
1230 <p>
1231
1232 <dt><strong>offer draw</strong>
1233 <dd>If your engine wants to offer a draw by agreement (as opposed to
1234 claiming a draw by rule), it can send the command "offer draw".
1235 xboard relays the offer to the user, the ICS, the other engine in Two
1236 Machines mode, and the PGN save file as required.  In Machine White,
1237 Machine Black, or Two Machines mode, the offer is considered valid
1238 until your engine has made two more moves.
1239 <p>
1240
1241 <font color=red>
1242 <dt><strong>tellopponent MESSAGE</strong>
1243 <dd>This command lets the engine give a message to its opponent,
1244 independent of whether the opponent is a user on the local machine or
1245 a remote ICS user (Zippy mode).  MESSAGE consists of any characters,
1246 including whitespace, to the end of the line.  When the engine is
1247 playing against a user on the local machine, xboard pops up an
1248 information dialog containing the message.  When the engine is playing
1249 against an opponent on the ICS (Zippy mode), xboard sends "say
1250 MESSAGE\n" to the ICS.
1251 <p>
1252
1253 <dt><strong>tellothers MESSAGE</strong>
1254 <dd>This command lets the engine give a message to people watching the
1255 game other than the engine's opponent.  MESSAGE consists of any
1256 characters, including whitespace, to the end of the line.  When the
1257 engine is playing against a user on the local machine, this command
1258 does nothing.  When the engine is playing against an opponent on the
1259 ICS (Zippy mode), xboard sends "whisper MESSAGE\n" to the ICS.
1260 <p>
1261
1262 <dt><strong>tellall MESSAGE</strong>
1263 <dd>This command lets the engine give a message to its opponent and
1264 other people watching the game,
1265 independent of whether the opponent is a user on the local machine or
1266 a remote ICS user (Zippy mode).  MESSAGE consists of any characters,
1267 including whitespace, to the end of the line.  When the engine is
1268 playing against a user on the local machine, xboard pops up an
1269 information dialog containing the message.  When the engine is playing
1270 against an opponent on the ICS (Zippy mode), xboard sends "kibitz
1271 MESSAGE\n" to the ICS.
1272 </font>
1273 <p>
1274
1275 <dt><strong>telluser MESSAGE</strong>
1276 <dd>xboard pops up an information dialog containing the message.
1277 MESSAGE consists of any characters, including whitespace, to the end
1278 of the line.
1279 <p>
1280
1281 <dt><strong>tellusererror MESSAGE</strong>
1282 <dd>xboard pops up an error dialog containing the message.
1283 MESSAGE consists of any characters, including whitespace, to the end
1284 of the line.
1285 <p>
1286
1287 <dt><strong>askuser REPTAG MESSAGE</strong>
1288 <dd>Here REPTAG is a string containing no whitespace, and MESSAGE
1289 consists of any characters, including whitespace, to the end of the
1290 line.  xboard pops up a question dialog that says MESSAGE and
1291 has a typein box.  If the user types in "bar", xboard sends "REPTAG
1292 bar" to the engine.  The user can cancel the dialog and send nothing.
1293 <p>
1294
1295 <dt><strong>tellics MESSAGE</strong>
1296 <dd>In Zippy mode, xboard sends "MESSAGE\n" to ICS.  MESSAGE consists
1297 of any characters, including whitespace, to the end of the line.
1298 <p>
1299
1300 <font color=red>
1301 <dt><strong>tellicsnoalias MESSAGE</strong>
1302 <dd>In Zippy mode, xboard sends "xMESSAGE\n" to ICS, where "x" is a
1303 character that prevents the ICS from expanding command aliases, if
1304 xboard knows of such a character.  (On chessclub.com and chess.net,
1305 "/" is used; on freechess.org, "$" is used.)  MESSAGE consists of any
1306 characters, including whitespace, to the end of the line.
1307 </font>
1308 </dl>
1309 <p>
1310
1311 <h2><a name="10">10. Thinking Output</a></h2>
1312
1313 <p>
1314 If the user asks your engine to "show thinking", xboard sends your
1315 engine the "post" command.  It sends "nopost" to turn thinking off.
1316 In post mode, your engine sends output lines to show the progress of
1317 its thinking.  The engine can send as many or few of these lines as it
1318 wants to, whenever it wants to.  Typically they would be sent when the
1319 PV (principal variation) changes or the depth changes.  The thinking
1320 output should be in the following format:
1321 </p>
1322
1323 <pre>ply score time nodes pv</pre>
1324
1325 Where:
1326 <table>
1327 <tr align="left"><th>ply<td>Integer giving current search depth.
1328 <tr align="left"><th>score<td>Integer giving current evaluation in centipawns.
1329 <tr align="left"><th>time<td>Current search time in centiseconds (ex:
1330 1028 = 10.28 seconds).
1331
1332 <tr align="left"><th>nodes<td>Nodes searched.
1333 <tr align="left"><th>pv<td>Freeform text giving current "best" line.
1334 You can continue the pv onto another line if you start each
1335 continuation line with at least four space characters.
1336 </table>
1337
1338 <p>
1339 Example:
1340 </p>
1341
1342 <pre>  9 156 1084 48000 Nf3 Nc6 Nc3 Nf6</pre>
1343
1344 <p>
1345 Meaning:
1346 </p>
1347
1348 9 ply, score=1.56, time = 10.84 seconds, nodes=48000,
1349 PV = "Nf3 Nc6 Nc3 Nf6"
1350
1351 <p>
1352 Longer example from actual Crafty output:
1353 </p>
1354 <pre>
1355   4    109      14   1435  1. e4 d5 2. Qf3 dxe4 3. Qxe4 Nc6
1356   4    116      23   2252  1. Nf3 Nc6 2. e4 e6
1357   4    116      27   2589  1. Nf3 Nc6 2. e4 e6
1358   5    141      44   4539  1. Nf3 Nc6 2. O-O e5 3. e4
1359   5    141      54   5568  1. Nf3 Nc6 2. O-O e5 3. e4
1360 </pre>
1361
1362 <p>
1363 You can use the PV to show other things; for instance, while in book,
1364 Crafty shows the observed frequency of different reply moves in its
1365 book.  In situations like this where your engine is not really
1366 searching, start the PV with a '(' character:
1367 </p>
1368
1369 <pre>
1370   0      0       0      0  (e4 64%, d4 24%)
1371 </pre>
1372
1373 <p>
1374 GNU Chess output is very slightly different.  The ply number is
1375 followed by an extra nonblank character, and the time is in seconds,
1376 not hundredths of seconds.  For compatibility, xboard accepts the
1377 extra character and takes it as a flag indicating the different time
1378 units.  Example:
1379 </p>
1380
1381 <pre>
1382  2.     14    0       38   d1d2  e8e7
1383  3+     78    0       65   d1d2  e8e7  d2d3
1384  3&     14    0       89   d1d2  e8e7  d2d3
1385  3&     76    0      191   d1e2  e8e7  e2e3
1386  3.     76    0      215   d1e2  e8e7  e2e3
1387  4&     15    0      366   d1e2  e8e7  e2e3  e7e6
1388  4.     15    0      515   d1e2  e8e7  e2e3  e7e6
1389  5+     74    0      702   d1e2  f7f5  e2e3  e8e7  e3f4
1390  5&     71    0     1085   d1e2  e8e7  e2e3  e7e6  e3f4
1391  5.     71    0     1669   d1e2  e8e7  e2e3  e7e6  e3f4
1392  6&     48    0     3035   d1e2  e8e7  e2e3  e7e6  e3e4  f7f5  e4d4
1393  6.     48    0     3720   d1e2  e8e7  e2e3  e7e6  e3e4  f7f5  e4d4
1394  7&     48    0     6381   d1e2  e8e7  e2e3  e7e6  e3e4  f7f5  e4d4
1395  7.     48    0    10056   d1e2  e8e7  e2e3  e7e6  e3e4  f7f5  e4d4
1396  8&     66    1    20536   d1e2  e8e7  e2e3  e7e6  e3d4  g7g5  a2a4  f7f5
1397  8.     66    1    24387   d1e2  e8e7  e2e3  e7e6  e3d4  g7g5  a2a4  f7f5
1398  9&     62    2    38886   d1e2  e8e7  e2e3  e7e6  e3d4  h7h5  a2a4  h5h4
1399                            d4e4
1400  9.     62    4    72578   d1e2  e8e7  e2e3  e7e6  e3d4  h7h5  a2a4  h5h4
1401                            d4e4
1402 10&     34    7   135944   d1e2  e8e7  e2e3  e7e6  e3d4  h7h5  c2c4  h5h4
1403                            d4e4  f7f5  e4f4
1404 10.     34    9   173474   d1e2  e8e7  e2e3  e7e6  e3d4  h7h5  c2c4  h5h4
1405                            d4e4  f7f5  e4f4
1406 </pre>
1407
1408 <p>If your engine is pondering (thinking on its opponent's time) in post
1409 mode, it can show its thinking then too.  In this case your engine may
1410 omit the hint move (the move it is assuming its opponent will make)
1411 from the thinking lines <em>if and only if</em> it sends xboard the move in
1412 the usual "Hint: xxx" format before sending the first line.
1413 </p>
1414
1415 <h2><a name="11">11. Time control</a></h2>
1416
1417 <p>
1418 xboard supports three styles of time control: conventional chess clocks,
1419 the ICS-style incremental clock, and an exact number of seconds per move.
1420 </p>
1421
1422 <p>In conventional clock mode, every time control period is the same.
1423 That is, if the time control is 40 moves in 5 minutes, then after each
1424 side has made 40 moves, they each get an additional 5 minutes, and so
1425 on, ad infinitum.  At some future time it would be nice to support a
1426 series of distinct time controls.  This is very low on my personal
1427 priority list, but code donations to the xboard project are accepted,
1428 so feel free to take a swing at it.  I suggest you talk to me first,
1429 though.
1430 </p>
1431
1432 <p>
1433 The command to set a conventional time control looks like this:
1434 </p>
1435
1436 <pre>
1437   level 40 5 0
1438   level 40 0:30 0
1439 </pre>
1440
1441 <p>
1442 The 40 means that there are 40 moves per time control.  The 5 means
1443 there are 5 minutes in the control.  In the second example, the 0:30
1444 means there are 30 seconds.  The final 0 means that we are in
1445 conventional clock mode.
1446 </p>
1447
1448 <p>
1449 The command to set an incremental time control looks like this:
1450 </p>
1451
1452 <pre>
1453   level 0 2 12
1454 </pre>
1455
1456 <p>
1457 Here the 0 means "play the whole game in this time control period",
1458 the 2 means "base=2 minutes", and the 12 means "inc=12 seconds".  As
1459 in conventional clock mode, the second argument to level can be in
1460 minutes and seconds.
1461 </p>
1462
1463 <p>
1464 At the start of the game, each player's clock is set to base minutes.
1465 Immediately after a player makes a move, inc seconds are added to his
1466 clock.  A player's clock counts down while it is his turn.  Your flag
1467 can be called whenever your clock is zero or negative.  (Your clock
1468 can go negative and then become positive again because of the
1469 increment.)
1470 </p>
1471
1472 <p>
1473 A special rule on some ICS implementations: if you ask for a game with
1474 base=0, the clocks really start at 10 seconds instead of 0.  xboard
1475 itself does not know about this rule, so it passes the 0 on to the
1476 engine instead of changing it to 0:10.
1477 </p>
1478
1479 <p>
1480 ICS also has time odds games.  With time odds, each player has his own
1481 (base, inc) pair, but otherwise things work the same as in normal
1482 games.  The Zippy xboard accepts time odds games but ignores the fact
1483 that the opponent's parameters are different; this is perhaps not
1484 quite the right thing to do, but gnuchess doesn't understand time
1485 odds.  Time odds games are always unrated.
1486 </p>
1487
1488 <p>
1489 The command to set an exact number of seconds per move looks like this:
1490 </p>
1491
1492 <pre>
1493   st 30
1494 </pre>
1495
1496 <p>
1497 This means that each move must be made in at most 30 seconds.  Time not used
1498 on one move does not accumulate for use on later moves.
1499 </p>
1500
1501 <h2><a name="12">12. Analyze Mode</a></h2>
1502
1503 <p>xboard supports analyzing fresh games, edited positions, and games
1504 from files.  However, all of these look the same from the chess
1505 engine's perspective. Basically, the engine just has to respond to the
1506 "analyze" command.
1507 <font color=red>
1508 Beginning in protocol version 2,
1509 if your engine does not support analyze mode, it should use
1510 the feature command to set analyze=0.
1511 </font>
1512 The older method of
1513 printing the error message "Error (unknown command): analyze" in
1514 response to the "analyze" command will also work, however.
1515 </p>
1516
1517 <p>
1518 To enter analyze mode, xboard sends the command sequence "post", "analyze".
1519 Analyze mode in your engine should be
1520 similar to force mode, except that your engine thinks about what move
1521 it would make next if it were on move.  Your engine should accept the
1522 following commands while in analyze mode:
1523 </p>
1524
1525 <ul>
1526 <li>Any legal move, as in force mode
1527 <li><strong>undo</strong>&nbsp;&nbsp; Back up one move and analyze previous position.
1528 <li><strong>new</strong>&nbsp;&nbsp; Reset position to start of game but stay in analyze mode.
1529 <font color=red>
1530 <li><strong>setboard</strong> if you have set feature setboard=1; otherwise <strong>edit</strong>.  Exiting edit mode returns to analyze mode.
1531 </font>
1532 <li><strong>exit</strong>&nbsp;&nbsp; Leave analyze mode.
1533 <li><strong>.</strong>&nbsp;&nbsp; Send a search status update (optional); see below.
1534 <font color=red><li>
1535 <strong>bk</strong>&nbsp;&nbsp; Show book moves from this position,
1536 if any; see above.</font>
1537 <font color=red><li>
1538 <strong>hint</strong>&nbsp;&nbsp; Show the predicted move from this
1539 position, if any; see above.</font>
1540 </ul>
1541
1542 <p>
1543 If the user selects "Periodic Updates", xboard will send the string
1544 ".\n" to the chess engine periodically during analyze mode, unless the
1545 last PV received began with a '(' character.
1546 </p>
1547
1548 <p>
1549 The chess engine should respond to ".\n" with a line like this:
1550 </p>
1551
1552 <pre>
1553 stat01: time nodes ply mvleft mvtot <font color=red>mvname</font>
1554 </pre>
1555
1556 Where:
1557 <table>
1558 <tr align="left"><th>time<td>Elapsed search time in centiseconds (ie: 567 = 5.67 seconds).
1559 <tr align="left"><th>nodes<td>Nodes searched so far.
1560 <tr align="left"><th>ply<td>Search depth so far.
1561 <tr align="left"><th>mvleft<td>Number of moves left to consider at this depth.
1562 <tr align="left"><th>mvtot<td>Total number of moves to consider.
1563 <tr align="left"><th><font color=red>mvname</font><td><font color=red>
1564 Move currently being considered (SAN or coordinate notation).  Optional;
1565 added in protocol version 2.</font>
1566 </table>
1567
1568 <p>
1569 Examples:
1570 </p>
1571 <pre>
1572   stat01: 1234 30000 7 5 30
1573   stat01: 1234 30000 7 5 30 Nf3
1574 </pre>
1575
1576 <p>
1577 Meaning:
1578 </p>
1579
1580 <p>After 12.34 seconds, I've searched 7 ply/30000 nodes, there are a
1581   total of 30 legal moves, and I have 5 more moves to search
1582   before going to depth 8.  In the second example, of the 30 legal
1583   moves, the one I am currently searching is Nf3.</p>
1584
1585 <p>
1586 Implementation of the "." command is optional. If the engine does not
1587 respond to the "." command with a "stat01..." line, xboard will stop
1588 sending "."  commands.  If the engine does not implement this command,
1589 the analysis window will use a shortened format to display the engine
1590 info.
1591 </p>
1592
1593 <p>
1594 To give the user some extra information, the chess engine can output
1595 the strings "++\n" and "--\n", to indicate that the current search is
1596 failing high or low, respectively.  You don't have to send anything
1597 else to say "Okay, I'm not failing high/low anymore."  xboard will
1598 figure this out itself.
1599 </p>
1600
1601 <h2><a name="13">13. Idioms and backward compatibility features</a></h2>
1602
1603 <p>
1604 Some engines have variant interpretations of the force/go/white/black,
1605 time/otim, and hard/easy command sets.
1606 In order to accommodate these older engines, xboard uses these commands
1607 only according to the stylized patterns ("idioms") given in this section.
1608 The obsolete white and black commands
1609 have historically been particularly troublesome, and it is recommended
1610 that new engines set the feature colors=0 and/or ignore the commands.
1611 </p>
1612
1613 <dl>
1614
1615 <dt><strong>time N</strong>
1616 <dt><strong>otim N</strong>
1617 <dt><strong>MOVE</strong>
1618 <dd>Sent when the opponent makes a move and the engine is already
1619 playing the opposite color.
1620 <p>
1621
1622 <dt><strong>white</strong>
1623 <dt><strong>go</strong>
1624 <dd>Sent when the engine is in force mode or playing Black but should
1625 switch to playing White.  This sequence is sent only when White is
1626 already on move.
1627 <font color=red>
1628 If you set the feature colors=0, "white" is not sent.
1629 </font>
1630 <p>
1631
1632 <dt><strong>black</strong>
1633 <dt><strong>go</strong>
1634 <dd>Sent when the engine is in force mode or playing White but should
1635 switch to playing Black.  This sequence is sent only when Black is
1636 already on move.
1637 <font color=red>
1638 If you set the feature colors=0, "black" is not sent.
1639 </font>
1640 <p>
1641
1642 <dt><strong>white</strong>
1643 <dt><strong>time N</strong>
1644 <dt><strong>otim N</strong>
1645 <dt><strong>black</strong>
1646 <dt><strong>go</strong>
1647 <dd>Sent when Black is on move, the engine is in force mode or playing
1648 White, and the engine's clock needs to be updated before it starts
1649 playing.
1650 The initial "white" is a kludge to accommodate GNU Chess
1651 4's variant interpretation of these commands.
1652 <font color=red>
1653 If you set the feature colors=0, "white" and "black" are not sent.
1654 </font>
1655 <p>
1656
1657 <dt><strong>black</strong>
1658 <dt><strong>time N</strong>
1659 <dt><strong>otim N</strong>
1660 <dt><strong>white</strong>
1661 <dt><strong>go</strong>
1662 <dd>Sent when White is on move, the engine is in force mode or playing
1663 Black, and the engine's clock needs to be updated before it starts
1664 playing.  See previous idiom.
1665 The initial "black" is a kludge to accommodate GNU Chess
1666 4's variant interpretation of these commands.
1667 <font color=red>
1668 If you set the feature colors=0, "black" and "white" are not sent.
1669 </font>
1670 <p>
1671
1672 <dt><strong>hard</strong>
1673 <dt><strong>easy</strong>
1674 <dd>Sent in sequence to turn off pondering if xboard is not sure
1675 whether it is on.  When xboard is sure, it will send "hard" or "easy"
1676 alone.  xboard does this because "easy" is a toggle in GNU Chess 4 but
1677 "hard" is an absolute on.
1678
1679 </dl>
1680
1681 <p>
1682 To support older engines, certain additional commands from the engine
1683 to xboard are also recognized.  (These are commands by themselves, not
1684 values to be placed in the comment field of the PGN result code.)
1685 These forms are not recommended for new engines; use the PGN result
1686 code commands or the resign command instead.
1687 </p>
1688
1689 <table>
1690 <tr align="left"><th>Command              <th>Interpreted as
1691 <tr align="left"><td>White resigns        <td>0-1 {White resigns}
1692 <tr align="left"><td>Black resigns        <td>1-0 {Black resigns}
1693 <tr align="left"><td>White                <td>1-0 {White mates}
1694 <tr align="left"><td>Black                <td>0-1 {Black mates}
1695 <tr align="left"><td>Draw                 <td>1/2-1/2 {Draw}
1696 <tr align="left"><td>computer mates       <td>1-0 {White mates} or 0-1 {Black mates}
1697 <tr align="left"><td>opponent mates       <td>1-0 {White mates} or 0-1 {Black mates}
1698 <tr align="left"><td>computer resigns     <td>0-1 {White resigns} or 1-0 {Black resigns}
1699 <tr align="left"><td>game is a draw       <td>1/2-1/2 {Draw}
1700 <tr align="left"><td>checkmate            <td>1-0 {White mates} or 0-1 {Black mates}
1701 </table>
1702
1703 <p>
1704 Commands in the above table are recognized if they begin a line and
1705 arbitrary characters follow, so (for example) "White mates" will be
1706 recognized as "White", and "game is a draw by the 50 move rule" will
1707 be recognized as "game is a draw".  All the commands are
1708 case-sensitive.
1709 </p>
1710
1711 <p>
1712 An alternative move syntax is also recognized:
1713 </p>
1714
1715 <table>
1716 <tr align="left"><th>Command              <th>Interpreted as
1717 <tr align="left"><td>NUMBER ... MOVE      <td>move MOVE
1718 </table>
1719
1720 <p>
1721 Here NUMBER means any string of decimal digits, optionally ending in a
1722 period.  MOVE is any string containing no whitespace.  In this command
1723 format, xboard requires the "..." even if your engine is playing
1724 White.  A command of the form NUMBER MOVE will be ignored.  This odd
1725 treatment of the commands is needed for compatibility with gnuchessx.
1726 The original reasons for it are lost in the mists of time, but I
1727 suspect it was originally a bug in the earliest versions of xboard,
1728 before I started working on it, which someone "fixed" in the wrong
1729 way, by creating a special version of gnuchess (gnuchessx) instead of
1730 changing xboard.
1731 </p>
1732
1733 <p>
1734 Any line that contains the words "offer" and "draw" is recognized as
1735 "offer draw".
1736 </p>
1737
1738 <p>
1739 The "Illegal move" message is recognized even if spelled "illegal
1740 move" and even if the colon (":") is omitted.  This accommodates GNU
1741 Chess 4, which prints messages like "Illegal move (no matching
1742 move)e2e4", and old versions of Crafty, which print just "illegal move".
1743 </p>
1744
1745 <p>
1746 In Zippy mode, for compatibility with older versions of Crafty,
1747 xboard passes through to ICS any line that begins "kibitz", "whisper",
1748 "tell", or "draw".  Do not use this feature in new code.  Instead, use the
1749 commands "tellall", "tellothers", "tellopponent", "tellics" (if needed),
1750 "1/2-1/2 {COMMENT}", or "offer draw", as appropriate.
1751 </p>
1752
1753 <p>
1754 <font color=red>
1755 If the engine responds to the "sd DEPTH" command with an error message
1756 indicating the command is not supported (such as "Illegal move: sd"),
1757 xboard sets an internal flag and subsequently uses the command
1758 "depth\nDEPTH" instead, for the benefit of GNU Chess 4.  Note the
1759 newline in the middle of this command!  New engines should not rely on
1760 this feature.
1761 </font>
1762 </p>
1763
1764 <p>
1765 <font color=red>
1766 If the engine responds to the "st TIME" command with an error message
1767 indicating the command is not supported (such as "Illegal move: st"),
1768 xboard sets an internal flag and subsequently uses the command "level
1769 1 TIME" instead, for the benefit of GNU Chess 4.  Note that this is
1770 not a standard use of the level command, as TIME seconds are not added
1771 after each player makes 1 move; rather, each move is made in at most
1772 TIME seconds.  New engines should not implement or rely on this
1773 feature.
1774 </font>
1775 </p>
1776
1777 <font color=red>
1778 <p>
1779 In support of the -firstHost/-secondHost features, which allow a chess
1780 engine to be run on another machine using the rsh protocol, xboard recognizes
1781 error messages that are likely to come from rsh as fatal errors.  The following
1782 messages are currently recognized:
1783 </p>
1784
1785 <blockquote>
1786 unknown host<br>
1787 No remote directory<br>
1788 not found<br>
1789 No such file<br>
1790 can't alloc<br>
1791 Permission denied<br>
1792 </blockquote>
1793 </font>
1794
1795 <p>
1796 <font color=red>
1797 ChessBase/Fritz now implements the xboard/winboard protocol and can use
1798 WinBoard-compatible engines in its GUI.  ChessBase's version of the
1799 protocol is generally the same as version 1, except that they have
1800 added the commands <strong>fritz</strong>, <strong>reset</strong>, and
1801 <strong>ponder</strong>, and the edit subcommands
1802 <strong>castle</strong> and <strong>ep</strong>.  If you want your
1803 engine to work well with the ChessBase/Fritz GUI, you may need to
1804 implement these additional commands, and you should also be aware of
1805 the peculiar way that ChessBase uses the protocol.  See their <a
1806 href="http://www.chessbase.com/Products/engines/winboard/tech.htm"
1807 >web page</a> for documentation.
1808 </font>
1809 </p>
1810
1811 <p>
1812 <font color=red>
1813 ChessMaster 8000 also implements version 1 of the xboard/winboard
1814 protocol and can use WinBoard-compatible engines.  The original
1815 release of CM8000 also has one additional restriction: only pure
1816 coordinate notation (e.g., e2e4) is accepted in the move command.  A
1817 patch to correct this should be available from The Learning Company
1818 (makers of CM8000) in February 2001.
1819 </font>
1820 </p>
1821
1822 <hr noshade size="2">
1823 <address>converted to HTML by <a href="http://www.jakob.at/steffen/">Steffen A. Jakob</a></address>
1824 </body>
1825 </html>