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.
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.
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
- 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.
