An idea to interface with e-boards

[Odd Gunnar Malin]

Hi.
I’m making a chess gui for letting me play against chess engines with my dgt board. I don’t need many features but what I need isn’t available in the GUI’s I have tried, maybe except for picochess.

I’m using QT as a framework, but their serial port classes are not working as they should, missing bytes now and then. So I ended up doing the interfacing with native windows api. Then you get into all sort of trouble with threads and sending messages between the native code and QT code.

Then I got another idea.

What about letting chess gui interface with e-board through a method similar with what they do with chess engines. E.g., create a command line protocol and let the e-board driver and the gui be two separated things.

I see big benefit nowadays with all these e-board coming on the marked, DGT, Millennium, Certabo, Square off, the new Ribinta, and probably more, maybe some of the old chess computers could have interfaceing to a PC.

Then all the e-board makers had to do is to create a driver with this universal protocol to be able to interface with a lot of GUI’s.

The gui makers already have a framework to use with their interfacing with chess engines, It should be much easier to add e-board support with reusing this than writing their own support for all these boards. I know there exist a dll that are build upon DGT’s rabbit plugin, but it is not always easy to interface with a dll from all framework you are programming with, and a commercial couldn’t use this anyhow.

One problem could be that it would make it easier to cheat on online sites, but I guess the cheaters have many methods to perform their hobby.

I will try to implement this to see if it is useful, or if there are problem with the method.

[mvanthoor]

Then I got another idea.

What about letting chess gui interface with e-board through a method similar with what they do with chess engines. E.g., create a command line protocol and let the e-board driver and the gui be two separated things.
...
I will try to implement this to see if it is useful, or if there are problem with the method.

http://dgtdrv.sourceforge.net/

This project does something similar. It implements an "engine" that at one side communicates with the GUI through UCI, and on the other side with the DGT-board through its own interface.

So yes, your idea will work, as it has been done already. I intend to do something similar, because I don't want to build the e-board communication code directly into the application:

GUI <-- (ecbp) -> Communicator <-- (dgt / certaob stuff) --> e-board

- GUI: the chess user interface
- ecbp: electronic chess board protocol
- Communicator: an executable that is loaded by the GUI and communicates with stdin/stdout just like it does with an engine
- This is the DGT / Certabo (whatever) stuff communicating with the eBoard.

The DGT-stuff is known. Certabo and Milliennium are too (through Aart Bik's Android app; does he have any documentation ?)

If "ecbp" would be standardized, a "Communicator" could be built for every digital chessboard, and that board would work with any GUI implementing ecbp.

I'm willing to help with this, as somewhere in the future, I'm going to make it anyway for my own GUI. As I have two DGT-boards and nothing else at the moment, I'd obviously only be able to write a communicator for DGT. If so, I'd write it in Rust.

[Odd Gunnar Malin]

http://dgtdrv.sourceforge.net/

This project does something similar. It implements an "engine" that at one side communicates with the GUI through UCI, and on the other side with the DGT-board through its own interface.

I see in my files that at least in 2004 I too made a dgt2wb driver that worked like this. Probably earlier too when dgt let us download dgtbrd13.h.

I'm willing to help with this, as somewhere in the future, I'm going to make it anyway for my own GUI. As I have two DGT-boards and nothing else at the moment, I'd obviously only be able to write a communicator for DGT. If so, I'd write it in Rust.

I don't know Rust but it is probably easier to create cross platform drivers, since I have problem with QT (missing bytes on serial communication) I use native windows code. And else I'm more like Sinatra (did it my way), so it isn't good for sample code neiter.

I have good knowledge of the DGT protocol too (have ref:72002 description) and also have two board (one serial and one usb) and DGT Pegasus in order. I also have two XL and one 3000 clock. In addition an DGT Centaur, they who work on the dgtcentaurmods try to simulate an Millennium board too.

I will make some test setup for me here since I have most of the code snips I need. But you could do the same if it not too much work. I guess you get better feel if you test in real envirioment.

Is it better to move this discussion to the programming sub forum? I could keep a draft on my github page if there is comming something substance out of it, or maybe better in the chessprogramming wiki (who can do this?).

[mvanthoor]

I see in my files that at least in 2004 I too made a dgt2wb driver that worked like this. Probably earlier too when dgt let us download dgtbrd13.h.

Ow; cool. I should look if there are still some developer resources on the DGT site; or maybe through the way-back machine.

I don't know Rust but it is probably easier to create cross platform drivers, since I have problem with QT (missing bytes on serial communication) I use native windows code. And else I'm more like Sinatra (did it my way), so it isn't good for sample code neiter.

I'd just write the exe in Rust (not a driver that needs to be loaded when the operating system starts). It's easy to write cross-platform executables in Rust. You could of course implement your own DGT communicator in C or C++.

I have good knowledge of the DGT protocol too (have ref:72002 description) and also have two board (one serial and one usb) and DGT Pegasus in order. I also have two XL and one 3000 clock. In addition an DGT Centaur, they who work on the dgtcentaurmods try to simulate an Millennium board too.

I don't know the DGT protocol. I intended to lift it from Picochess some day and port it to Rust; then put a UCI-like communication on top of it between that EXE and the GUI. We could try to standardize that communication between the EXE ("communicator" ?) and the GUI, so we get an e-board protocol.

I will make some test setup for me here since I have most of the code snips I need. But you could do the same if it not too much work. I guess you get better feel if you test in real envirioment.

As said, I do have two DGT-boards (mini-USB Walnut and USB-C Walnut), 2 DGT3000 Limited clocks, and the XL clock. Maybe at some point in the future I'll get a smaller Certabo board, just to have a smaller board. If there is an open source program that can already communicate with the Certabo board, we could lift their protocol from that program and use the same e-board interface on top of it.

In the end, any GUI could use any e-board, as long as an "ECBP Communicator" exists.

Is it better to move this discussion to the programming sub forum? I could keep a draft on my github page if there is comming something substance out of it, or maybe better in the chessprogramming wiki (who can do this?).

It could go to the programming forum. Any mod here can do this. I think it's still too early for the CPW. We'd need to have something working first.

PS: I'd probably write my GUI in Electron, probably with part of my chess engine (the move generator, for legality checking etc) running as the back end, compiled to WASM. I still need to look into this. However, I think it should be easy enough to set up a minimal application (single window) that displays a board (ASCII if need be) to be able to start work on a communicator EXE.