About RDChess

Update: I have stopped the development of RDChess. The RDChess.exe file still runs under Windows 10, but I have not updated the installation process. This blog is kept online for historical reasons only!

One of my main interests in leisure time has been programming chess. Beside my job and my family I have written the chess program RDChess, spending many evening and weekend hours for this hobby. In the mean time I have stepped down development of RDChess. Anyway the current last version V3.23 works still under Windows 7 and is still freeware :-). You may try RDChess yourself and download a free copy. Or look at the RDChess User Manual (english) oder in die RDChess Bedienungsanleitung (deutsch).

Read a Technical Description of the RDChess program, describing shortly the architecture, data structures, search and evaluation routines of the program. Mostly the program follows the "main stream" architecture of brute force programs of the Northwestern University program CHESS 4.5 type, but has a few "proprietary" program technical features. RDChess is comparably in strength to other freeware programs like "GNUCHESS for Windows". I am not a good chess player and lose practically every time against my own program. Anyway RDChess loses regulary against commercially sold chess programs like Fritz. Read further about the strength of the program and how to test it.

If you are a chess programmer, interested in how RDChess works in detail, look into the source code. Remark: The source code (Borland Delphi, x86 assembler) is well commented but contains comments in a mixture of German and English language, so be aware you may not understand the source not knowing the German language.

Wednesday, January 13, 2010

RDChess WinBoard Interface implementation

The following description is meant for computer programmers, who are interested in how and what of the WinBoard protocol is implemented in RDChess.

If you want to know how to install RDChess into Winboard please go to the User Manual Part 3 Installation
The WinBoard Communication protocol has been the most common link for playing chess games between chess engines. Recently even the commercial chess programs support this interface. The best known program is WinBoard by Tim Mann.
A newer interface is the  UCI (Universal Chess Interface) protocol, which has more functions than WinBoard. UCI is supported e.g. by Arena.

Implementation of the WinBoard interface in RDChess:
RDChess is a Delphi program written in Object Pascal. The main program is a single process (thread) and uses heavily the Borland Visual Component Library (VCL).
Winboard.exe (or an equivilant program) starts RDChess and creates 2 pipes for standard input and standard output. 
My interface code is based on an example by Tony Werten

RDChess writes to the output pipe with an output handle (created by gHandleout:=getstdhandle(std_output_handle) ) by calling _lwrite(gHandleout,PCHAR (string),length).
RDChess reads from the standard input in an own thread WBReadThread, derived from the VCL TThread class.
In the thread function ( procedure TWBReadThread.Execute ) the commands received from WinBoard are read and analysed. It is critical and Borland does not recommend to use VCL functions in this extra thread, because many are not thread safe. So I use at some points the Delphi supplied method Synchronize. Larger work is postponed to the main thread  by posting messages to the RDChess main thread with PostMessage(MainForm.Handle, ...) .
A few calls to VCL functions and global variables are still used directly in the thread execute method, but I also use frequent calls to Application.ProcessMessage, which should decrease the risk of a collision. 

WBReadThread is set to a lower priority than the main thread in order that the main thread ends his work on a received command  faster before it takes actions for a newer command. (e.g. all the work at receiving a "result" winboard command (for instance saving the chess game) must be done before a received "new" winboard command sets all data to a new game). I had problems with synchronizing the both tasks at the beginning of using the thread (and even program crashes!) until RDChess V3.07, but in V3.08 it seems there are no problems.
RDChess  "uses" currently   the following Winboard commands
Receiving (WinBoard-> RDChess):
  •  xboard, new, random,  protversion 2 
  •  hard, easy, post, nopost, computer, name, ics hostname
  • rating (in ICS mode)
  •  level, st  (all 3 styles conventional, ICS-style, nr of seconds per move)
  • sd (set maximum search depth)
  •  time, otim (used optionally for synchronizing of RDChess internal timining routines with WinBoard timing)
  • force, go, white, black
  • hint, "?" (move now)
  • moves in standard notation (not SAN format !)
  • remove
  • setboard FEN (for setup of positions and at loading games)
  • analyze, undo ,  "." , bk (bk only partially implemented)
  • result
  • draw
  • quit
Sending (RDChess -> WinBoard):
  • answers to protversion 2:
      name=1      // request the name from the opponent!!!
      time=1       // send  time and otim cmds
      setboard=1 // FEN-cmd  instead of edit-cmd
      ics=1        // inform about ICS data

      analyze=1    // implemented
  • move xxxx (computermove calculated by RDChess)
  • 0-1  (or  1-0, 1/2-1/2)  {xxxxxx}    xxxxxx = result/ resigns
  • "offer draw" (when RDChess is behind 12 pawn units and at certain types of endgames (RK-RK; QK-QK) and the opponent is not in time troubles)
  • Error (xxxxxxxxxxx) : yyyyy  // error messages from RDChess to the opponent
  • Thinking output ( ply score time nodes pv) (when state is "post command received")
  • Status update (stat01: time nodes ply mvleft mvtot mvname) in response to a received "." cmd.  mvleft and mvtot are not supported and set to a default value 1.
RDChess understands only the newer (protversion 2) position setup command "setboard" and not the older "edit" commands for seting up positions. This means that currently chess games may be loaded from .pgn files with the program Winboard.exe only and not with the program Arena.exe.