$Id: engine-intf.html,v 2.1 2003/10/27 19:21:00 mann Exp $<br>\r
Version 2; implemented in xboard/WinBoard 4.2.1 and later.<br>\r
Changes since version 1 are indicated in <font color=red>red</font>.<br>\r
-Changes for WinBoard 4.3.xx are indicated in <font color=green>green</font>.\r
+Changes for WinBoard 4.3.xx are indicated in <font color=green>green</font>.<br>\r
+Proposed changes, implemented only in alpha versions are indicated in <font color=blue>blue</font>.\r
<hr noshade size="2">\r
\r
<ul>\r
<td><font color=green>shuffle variant like FRC (10x8 board)</font>\r
<tr align="left"><th><font color=green>cylinder</font>\r
<td><font color=green>Pieces wrap around between side edges, like board is a cylinder</font>\r
+<tr align="left"><th><font color=blue>super</font>\r
+<td><font color=blue>Superchess: a shuffle variant with 4 fairy pieces on 8x8 board</font>\r
<tr align="left"><th>unknown<td>Unknown variant (not supported)\r
</table>\r
<p>\r
that many engines implement it wrong.\r
The clocks in fact always remain with the color.\r
Which clock reading is relayed with "time", and which by "otim", is determined by which side the engine plays.\r
-Not that the way the clocks operate and receive extra time (in accordance with the selected time control)\r
+Note that the way the clocks operate and receive extra time (in accordance with the selected time control)\r
is not affected in any way by which moves are made by the engine, which by the opponent, and which were forced.\r
</font>\r
</p>\r
left off, and the clock of the player on move resumes running from\r
where it stopped.\r
</font>\r
+<p>\r
+\r
+<dt><font color=blue><strong>memory N</strong></font>\r
+<dd><font color=blue>\r
+This command informs the engine on how much memory it is allowed to use maximally, in MegaBytes.\r
+On receipt of this command, the engine should adapt the size of its hash tables accordingly.\r
+This command does only fix the total memory use,\r
+the engine has to decide for itself \r
+(or be configured by the user by other means) \r
+how to divide up the available memory between the various tables it wants to use \r
+(e.g. main hash, pawn hash, tablebase cache, bitbases).\r
+This command will only be sent to engines that have requested it through the memory feature,\r
+and only at the beginning of a game\r
+(before any moves have been done).\r
+</font>\r
+<p>\r
+\r
+<dt><font color=blue><strong>cores N</strong></font>\r
+<dd><font color=blue>\r
+This command informs the engine on how many CPU cores it is allowed to use maximally.\r
+This could be interpreted as the number of search threads for SMP engines. \r
+(Threads that do not consume significant amounts of CPU time, like I/O threads, need not be included in the count.)\r
+This command will only be sent to engines that have requested it through the smp feature.\r
+The engine should be able to respond to the "cores" command any time during a game,\r
+but it is allowed to finish a search in progress before procesing the command.\r
+(Reaction during ponder time should be immediate, though.)\r
+</font>\r
+<p>\r
+\r
+<dt><font color=blue><strong>egtpath TYPE PATH</strong></font>\r
+<dd><font color=blue>\r
+This command informs the engine in which directory (given by the PATH argument)\r
+it can find end-game tables of the specified TYPE.\r
+The TYPE argument can be any character string which does not contain spaces.\r
+Currently <strong>nalimov</strong> and <strong>scorpio</strong> are defined types, \r
+for Nalimov tablebases and Scorpio bitbases, respectively,\r
+but future developers of other formats are free to define their own format names.\r
+The GUI simply matches the TYPE names the engine says it supports \r
+with those that the user supplied when configuring xboard.\r
+For every match, it sends a separate "y" command.\r
+The PATH argument would normally (for Nalimov) be the pathname of the directory the EGT files are in,\r
+but could also be the name of a file, or in fact anything the particular EGT type requires.\r
+It is upto the developer of the EGT format to specify the syntax of this parameter.\r
+This command will only be sent to engines that have told the GUI they support EGTs of the given TYPE\r
+through the egt feature.\r
+</font>\r
</dl>\r
\r
<h3>Bughouse commands:</h3>\r
correct value for your engine (just "normal" in most cases) rather\r
than leaving the default in place, so that the user will get an\r
appropriate error message if he tries to play a variant that your\r
-engine does not support.\r
+engine does not support.</font>\r
<br>\r
-If your engine can play variants on a deviating board size,\r
+<font color=green>If your engine can play variants on a deviating board size,\r
like capablanca on an 8x8 board, or capablanca crazyhouse,\r
it can list them amongst the variants with a prefix spcifying board size plus\r
holdings size, like 8x8+0_capablanca or 10x8+7_capablanca.\r
or do so at their own risk.\r
</font>\r
\r
+<dt><font color=blue>\r
+<strong>memory</strong> (boolean, default 0)\r
+</font>\r
+<dd><font color=blue>\r
+If memory=1, the size of the total amount of memory available for the memory-consuming tables of the engine \r
+(e.g. hash, EGTB cache)\r
+will be set by the GUI through the "memory" command.\r
+</font>\r
+\r
+<dt><font color=blue>\r
+<strong>smp</strong> (boolean, default 0)\r
+</font>\r
+<dd><font color=blue>\r
+If smp=1, the GUI will send the "cores" command to the engine to inform it how many CPU cores it can use.\r
+</font>\r
+\r
+<dt><font color=blue>\r
+<strong>egt</strong> (string, see text below)\r
+</font>\r
+<dd><font color=blue>\r
+This feature indicates which end-game table formats the engine supports.\r
+It should be a comma-separated list of format names.\r
+See under the "egtpath" command in <a href="#8">section 8</a> above.\r
+If you do not set this feature, xboard will assume the engine does not support end-game tables,\r
+and will not send any "egtpath" commands to inform the engine about their whereabouts.\r
+</font>\r
+\r
<dt><font color=red>\r
<strong>done</strong> (integer, no default)\r
</font>\r
increment.)\r
</p>\r
\r
-<p>\r
+<p><font color=blue>\r
The number of moves given in the level command (when non-zero) should \r
be taken as the number of moves still to do before the specified time\r
will be added to the clock, if the "level" command is received after\r
it should understand that it should do the next 20 moves in 22 minutes\r
(pehaps because the secondary session was 20 moves per 15 minutes,\r
and it had 7 minutes left on its clock after the first 40 moves).\r
-</p>\r
+</font></p>\r
\r
<p>\r
A special rule on some ICS implementations: if you ask for a game with\r
projects / xboard.git / blobdiff