Novag UCB drivers (Winboard and UCI)

[GONeill]

The only drivers I could find for the Novag Universal Electronic Chess Board (UCB) didn't work properly for me. I did some investigating, which led to me to updating the documentation of how it communicates:

http://goneill.co.nz/novag

Then I wrote some new drivers, creating both a Winbaord and a UCI one. I've tested them in Arena and Chessmaster and they seem to work OK. Improvements over the previous programs include being less sensitive to when the board is turned on, the ability to play multiple games without reseting the UCB power and (at least in Arena) starting the game from the normal position, a FEN or PGN.

But the program does still need to be run as a chess engine so it isn't as good as having board support built into the interface (e.g. like the DGT board in Arena).

Download from my ArenaSwiss web page:

http://goneill.co.nz/arenaswiss

[hgm]

But the program does still need to be run as a chess engine so it isn't as good as having board support built into the interface (e.g. like the DGT board in Arena).

Actually it would be better to extend the protocol with engine->GUI commands that would allow the board to do what it needs to do, but what normal engines cannot. That would keep the design modular.

For example, WinBoard/XBoard has an option -firstPseudo / -secondPseudo, which tells the GUI the corresponding 'engine' is actually a pseudo-engine, which should be allowed to use some extra commands. Such as altering the times on the clocks through time / otim commands sent from engine to GUI. (This is useful for pseudo-engines that are connection adapters for runing on a server, or peer-to-peer connections between remote GUIs.)

What are functions you would consider useful? E.g. a GUI could be made to accept moves (and their retraction) from the 'second engine' when this is a pseudo-engine, in analysis mode.

[GONeill]

A small update to the Winboard and UCI engines. Nothing major, just a slightly improved screen.

HGM: Sorry for not replying.

Actually it would be better to extend the protocol with engine->GUI commands that would allow the board to do what it needs to do, but what normal engines cannot. That would keep the design modular.

I started thinking about what would be needed and after a while realised it wouldn't help me. The reason for the WB and UCI versions is to try and make the UCB useful with as many interfaces as possible. While extending the protocol would help with Winboard it's unlikely any of the other GUI's I use would incorporate the changes. For example, Chessmaster uses WB1 and unless UbiSoft have a massive change of heart that is never going to change.

[hgm]

Well, you know what they say: you can lead a horse to water, but you can't make it drink.

If GUI developers are not willing to implement an interface by adding a few extra protocol commands, it doesn't seem very likely they would consider implementing an interface with a DLL from scratch. If the goal is to make it work on as many existing GUIs as possible, it seems to me that a pseudo-engine driver would achieve that overwhelmingly, with only some functionality not working on GUIs that refuse to implement it. While making a new DLL interface would work exactly on zero GUIs...

[GONeill]

Exactly. Implementing a new DLL from scratch would be a total waste of time.

Instead I took the existing, public documentation of the DGT Rabbit plugin and created a DLL file that exposes identical functions. I then tried to work out how existing interfaces use those functions so that I could make them work with the UCB. So far I have been able to do this with Arena and LucasChess.

Theoretically I should be able to make the UCB work with every GUI that currently supports the DGT e-boards, which is most of them. In practise I will run into problems of not knowing exactly what data they require from some of the callback functions. For example _DGTDLL_Status() passes a string but I have no idea what that string should contain. There are also problems that the DGT is just a better board: it knows which pieces are on which square, while the UCB doesn't. So a GUI doesn't have to pass a position to the DGT but does for the UCB, and if that is required to play a game then I will never get it working for that GUI.

[GONeill]

PS. For anybody who has just found this thread, we are referring to the DLL described here: http://www.talkchess.com/forum/viewtopic.php?t=63657