Novag UCB Communications

Introduction

I have a Novag Universal Electronic Chess Board and the Novag Sapphire II computer, and decided to create my own version of the program to enable the UCB to talk to interfaces such as Arena and Chessmaster.

The initial information was based on an old web page by Nick Biggs and a Java program by Luc Porchon, but I found that for my version of the equipment the information was not totally accurate. The main difference was how positions are sent to the UCB. I don't know if the older information was wrong or if Novag changed the specification so I allow the "UCB Version" to be set to 1 or 2 to enable both to be tried. Using version 1 on my equipment causes all sorts of errors, so I think you'll soon find out which version you need.

This document details the UCB communications as I understand them. I do not cover the Sapphire communication rules here as I was really only interested in the UCB, except that in some cases I needed to see how the Sapphire responded in order to get the correct UCB commands.

I used this information to create two versions of the program: UCB-WB and UCB-UCI (both for Windows) to allow for the Winboard and UCI chess engine protocols. I feel these are an improvement over previous versions since it is no longer necessary to turn the UCB off and on for each new game. Also games can be started from a FEN position or a series of moves (e.g. from a PGN). I then developed a DLL version that allows the UCB to be used as a built in board rather than a chess engine.

UCB cable

The cable that came with my board had an RJ12 connector at one end and a female DB25 at the other. I used a DB25-DB9 connector and then a serial-USB converter to connect it to the computer:
    USB to Serial DB9 RS232 cable
One day the cable stopped working so I made a replacement using the following parts:
    RJ12 6P/6C cable
    DB9 female connector
    DB9 plastic shell
The important thing is that the cable is 6P/6C (6 pins, 6 conections) as many of the RJ11/RJ12 cables available only use 4 wires. Cut one end off the cable, strip the wires you need and solder them to the plug. The pin connections are as follows (noting that the DB9 picture shows the front holes, not the back pins that are soldered to):

cable
RJ12DB9-FSignal
1--
23TD
34DTR
42RD
56DSR
65GND

The cable will work if only TD, RD and GND are connected so DTR and DSR seem optional. Note that for this case "TD" means the data being transmitted from the computer to the UCB.

UCB protocol

The communications with the UCB use standard serial port settings of:

Speed:      9600 baud
Data bits:  8
Stop bits:  1
Parity:     none
Handshake:  none

UCB power on

When the UCB is first turned on it sends a series of commands, to which the Sapphire sends certain responses. I believe most of these are to configure the Sapphire rather than the UCB. All commands sent to the UCB end in the Carriage Return/Line Feed characters.

<space>

The first thing the UCB does is send a space. This doesn't seem to do anything, but can be used to recognise that the UCB is talking. There is no response to this.

I

A request for the ID of the device connected to the UCB. I'm not sure if the values sent back affect the UCB in anyway, but the Sapphire responds with:

ID SAPPHIRE II 1.02
E OFF

Some Novag computers will Echo back every command sent to them. This isn't required for the UCB so this command turns it off. There is no reply to this command.

V

The Sapphire can output data in Human or Video mode. For computer communications we want Video mode. The Sapphire responds with:

Video Mode
A OFF

The Sapphire can send clock times with each move, but the UCB doesn't want this so turns it off. The Sapphire responds with:

Autoclock off
X ON

Tells the Sapphire to transmit moves as they are made. The Sapphire responds with:

Xmit on
P

A request for the current board position. This command can be sent at other times too, so is covered in the section below.

Commands from the UCB

During play the UCB can send various commands.

P

A request for the current board position. The older documentation and programs specified that the response to this should be eight lines of data:

.rnbqkbnr
.pppppppp
.
.
.
.
.PPPPPPPP
.RNBQKBNR+

So black pieces are in lower case, white in upper case and all empty squares are shown with a space. There is a character at the end of the last line to indicate which colour moves next ("+" for white and "-" for black). I call this UCB Version 1 in my programs.

For my board this didn't work and sometimes caused the UCB to stop responding. I found my Sapphire output a different format which works correctly with my UCB and has nine lines of data:

Position Board
.8rnbqkbnr
.7pppppppp
.6
.5
.4
.3
.2PPPPPPPP
.1RNBQKBNR+

A header line has been added as well as the rank numbers. I call this UCB Version 2 in my programs.

M<move>

When a move is made on the board the UCB sends that move using the "from" and "to" squares. If a pawn promotion occurs then a "/" character is added together with the promotion piece. For example, valid moves are:

Me2e4
Me1g1    (Castles king side)
Ma7a8/Q  (Pawn promotes to queen)

En Passant, Check or Checkmate moves are shown as normal moves (i.e. no "ep", "+" or "++" characters are added).

N

If the pieces are returned to the starting position the UCB will send an "N" character, meaning new game. In my programs I ignore this as it doesn't tell the interface why the previous game ended. I prefer to use the options in the interface to end games with either a win, loss or draw and have it then tell the UCB that a new game is to start.

J

The UCB uses this to tell the Sapphire to start thinking and make a move. I ignore this as the interface already knows whose move it is.

T

This indicates that you have tried to take back a move on the UCB. Since games with my programs have to be engine verses engine games (which don't permit take backs) I have to ignore this command.

Commands to the UCB

M<move>

To tell the UCB to show a move on the board, the M command is sent. The format is slightly different to before as it includes a "-" character. For example, valid moves are:

Me2-e4
Me1-g1    (Castles king side)
Ma7-a8/q  (Pawn promotes to queen)

Again, no extra characters are added for en passant or check moves. Note that for pawn promotions the move includes the piece required and the UCB will understand it, but the UCB will not indicate in any way on the board which piece is required. You have to look at the interface screen to see what the pawn is being promoted to.

New Game

A new game can be started by sending this command to the UCB. For some reason the Sapphire adds a space at the end after the word Game, but this doesn't seem to be significant. After this command has been sent the UCB will not send the normal "N" command when the pieces are returned to the starting position.

<Position>

The eight or nine data lines for a position can the sent to the UCB at any time to change the position of the pieces.

<Sounds> and <Flip board>

I never managed to find commands to control the sounds that the UCB makes or to rotate the board so that black is at the bottom. It is still necessary to control sound using the manual method of raising and replacing the left white rook (on square A1 or H8) twice, and orientation by lifting and replacing the black king (on D1). Unfortunately these can only be done in the normal starting position.

Important note

When sending commands to the UCB it is important to remember that the UCB has no input buffer. So if you have a list of moves to send you cannot send them all and then expect the UCB to display them one by one as the moves are made on the board. Instead you must send one and then wait for that move to be made before sending the next one. The same applies if you want to send an opening position or "New Game" command followed by the first move: you have to give time for the pieces to be put in place before sending that move.

The wait could either be for a set amount of time (e.g. one minute to set up the position, and 15 seconds between moves) or controlled by a window that allows the user to confirm when the action has been completed. I prefer the latter.

Regardless of which approach is chosen there is an additional complication. The program runs as a chess engine and one of the rules of those is that they must always remain responsive to the interface. So in the UCI protocol the program must respond to an "isready" prompt even though it is waiting for the user to make the action. So any window presented to the user for confirmation must be non-modal and the program loop must keep checking for, and responding to, any interface commands while it waits.