DGT board C++ interface project

You can discuss all aspects of programming and technical matters here.

Moderators: Harvey Williamson, Watchman

User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

DGT board C++ interface project

Post by sje »

I've starting working on an open DGT board C++ interface project for the Mac OS/X and the Linux platforms. I can post notes and progress here if there is an interest.
ifekali
Member
Posts: 98
Joined: Thu Dec 05, 2013 11:19 am

Re: DGT board C++ interface project

Post by ifekali »

sje wrote:I've starting working on an open DGT board C++ interface project for the Mac OS/X and the Linux platforms. I can post notes and progress here if there is an interest.
I am *very* interested. Thank you.

-Izmet
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Post by sje »

Work is in progress. At present, I'm just gathering documentation and code samples. Currently, I have a DGT USB e-board. Soon I'll have a DGT XL clock and a PicoChess set-up for testing existing code plus some incremental modifications of my own.

I do not have the budget for other DGT e-board models, specifically the Bluetooth version.

The basic plan is to build the DGT board/clock C++ interface as a self contained set of routines written in its own C++ namespace and being independent from all other code. Use of an XL clock will be optional.

The C++ build chains used will be those available on Mac OS/X versions 10.4.11 through 10.7.5 and on the current Debian Linux distribution. Both 32 bit and 64 builds are to be made. Ideally, there will be very few conditional compilation preprocessor directives. Simplicity is preferred over speed, and all possible error conditions will be tested.

The DGT board/clock C++ interface will be distributed as source code under the BSD license and without warranty. There will be no initial costs or royalties so that I will be viewed being as impartial by all. And while the first version will be only for DGT hardware, the code should be sufficiently general to handle hardware by other, future manufacturers.

Communication between the interface and the containing application is done by simple ASCII text message passing. The Chess Data Interchange formats (SAN, FEN, and PGN) will be used as much as is feasible; the assumption is that anyone smart enough to write a chess program is also smart enough to both generate and parse these data formats. There will be no sharing of C++ class definitions and so no need to enforce naming discipline other than having a separate namespace for the interface. To handle asynchronous output from the interface, the application can elect to poll, to set a data receive buffer address, or to receive a signal followed by a data read.

The interface will contain routines to handle 64 LED and 81 LED indicator arrays, even though such aren't yet generally available.

The first program to use the interface will be a simple, text only interactive application which will run in a terminal emulation window. It will serve as a test harness to assist with the development of the interface and it will also serve as a tutorial example. It will be distributed with the interface with the same license and terms.

The second program will be my own Symbolic and it will remain private.

Other programs will hopefully come from third party software vendors, particularly those marketing chess applications for the Macintosh. I can offer some general assistance here, but not the actual integration.

Of course, much is subject to change. Because of personal medical issues which often delay my work, I can average at best only a few hours per week and so I can offer no schedule.
User avatar
fourthirty
Full Member
Posts: 762
Joined: Fri Dec 06, 2013 8:46 pm
Location: San Francisco

Post by fourthirty »

Very interested also. Thanks sje!
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Post by sje »

One new datum: When the DGT USB board is connected to my Windows 8 notebook, Windows sees the board as a generic USB/serial converter and not as a chessboard. I'd guess that this is because the DGT USB board design is a copy of the original DGT serial board design with a USB converter added. This may have an impact on initial board detection as the computer can't tell the difference between a general USB/serial converter and one which is part of a DGT USB board. In turn, this means that the user might have to manually specify the port which has the physical connection to the board.
User avatar
Mark Uniacke
Hiarcs Author
Posts: 1455
Joined: Sun Jul 29, 2007 1:32 pm
Location: United Kingdom
Contact:

Post by Mark Uniacke »

I will add my interest to this work. We would love to be able to add support for DGT boards on Mac in HCE.

I think there is someone at DGT who also may be able to offer help or at least advice. Please let me know if that will help as I have some contacts at DGT.
Best wishes,
Mark

https://www.hiarcs.com
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Post by sje »

Mark Uniacke wrote:We would love to be able to add support for DGT boards on Mac in HCE.
And not just standalone DGT boards, but also equipment like a Revelation II running its no-frills DGT emulation and connected via Bluetooth.

Plus we want to accommodate those using other kinds of boards, like the Novag Citrine. Also, homebrew boards; if these can't all be connected directly, at least the C++ interface source will be available for builders to try their own modifications.

--------

I've done some more investigation and it looks like a calling application will have to query the user as to which port or ports are in use for board connections. If all DGT boards had the same, native USB hardware interface, then auto configuration would be possible. But instead the there's either a serial/USB converter or a Bluetooth connection imitating a serial link. And it's possible that there may be more than one brand and model of the serial/USB converters used.
User avatar
Mark Uniacke
Hiarcs Author
Posts: 1455
Joined: Sun Jul 29, 2007 1:32 pm
Location: United Kingdom
Contact:

Post by Mark Uniacke »

Thanks Steven. Sounds very interesting and useful. I saw Albert Vasse at the London Chess Classic today (yesterday now), and so I will ask him who in DGT would be the best contact and I will try and put them in touch with you if that is ok.
Best wishes,
Mark

https://www.hiarcs.com
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Post by sje »

Mark Uniacke wrote:I saw Albert Vasse at the London Chess Classic today (yesterday now), and so I will ask him who in DGT would be the best contact and I will try and put them in touch with you if that is ok.
Sure. I'll likely have plenty of questions as the work progresses.
User avatar
Mark Uniacke
Hiarcs Author
Posts: 1455
Joined: Sun Jul 29, 2007 1:32 pm
Location: United Kingdom
Contact:

Post by Mark Uniacke »

Also I have a DGT Rev II which I could test with when the time comes...
Best wishes,
Mark

https://www.hiarcs.com
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Post by sje »

One of the goals of the project is to avoid any explicit access to C I/O library routines because of interference issues with C++ I/O library routines accessed in the same process space. This means avoidance of any routine which depends upon an underlying C FILE variable or a C file descriptor.

An issue here is the low level manipulation of old style (RS-232) serial links. Routines for this manipulation do not exist in the C++ library. However, with the use of USB serial links, there really isn't a need for such as the low level details are properly encapsulated in the host system's USB drivers.

The decision here is to not support the old style serial links in the interface. This means that an old style RS-232 DGT board will need a serial/USB adapter to connect to the host computer. I believe this to be a reasonable approach because:

1. The interface is simpler and retains high level portability.

2. Most, perhaps nearly all DGT boards sold today are either USB or Bluetooth, and both of these flavors hide all low level serial link management.

3. A serial/USB adapter is fairly inexpensive and easily obtainable, so someone with an RS-232 DGT board is not abandoned.

4. Has anyone bought a computer with an RS-232 port in the past ten years?
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Post by sje »

Mark Uniacke wrote:Also I have a DGT Rev II which I could test with when the time comes...
This is good, because getting a Bluetooth DGT board or a Revelation II is not in my budget for the foreseeable future.
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Some interface calls

Post by sje »

Some interface calls

Interface call: Get MPD Snapshot

A FEN string has six field to describe a chess position. The first of the six is the MPD (Man Placement Data) field and it gives the location of the chessmen on the board. When the interface takes an MPD snapshot, the corresponding MPD string is returned and not an entire FEN string.

The returned MPD string from an MPD snapshot is not adjusted for board rotation even if a need for rotation has been communicated to the interface. The MPD snapshot call is likely to be used only for assistance with testing the interface.

Example: given the position
[fen]3rr2k/7p/p4p2/4qP1Q/4b2N/1P5P/P1p3PK/2B2R2 w - - 1 33[/fen]
an MPD snapshot returns the string "3rr2k/7p/p4p2/4qP1Q/4b2N/1P5P/P1p3PK/2B2R2".

Important note: The MPD might not represent legal data if the position is not legal.

--------

Interface call: Get SOD Snapshot

The term "SOD" means Square Occupancy Data and an SOD snapshot return a string which indicates which squares on the board are occupied. This call is intended for use with a chessboard which has occupancy recognition but perhaps not piece recognition.

The returned SOD string from an SOD snapshot is not adjusted for board rotation even if a need for rotation has been communicated to the interface.

Example: given the position
[fen]3rr2k/7p/p4p2/4qP1Q/4b2N/1P5P/P1p3PK/2B2R2 w - - 1 33[/fen]
an SOD snapshot returns the string "3**2*/7*/*4*2/4**1*/4*2*/1*5*/*1*3**/2*2*2".

--------

Interface call: Get FEN Snapshot

A FEN snapshot request returns a FEN string giving the current position on the board. Note that data other than the MPD does not physically appear on the actual chessboard; the interface maintains this data in the board context kept for each connected chessboard.

The returned FEN string from a FEN snapshot is adjusted for board rotation.

Extensions to FEN for chess variants are not supported.

Important note: The FEN will not represent legal data if the position is not legal.

--------

Interface call: Put MPD

The Put MPD call is used to give identities to occupied squares on the connected board. This call is intended for use with a chessboard which has occupancy recognition but perhaps not piece recognition. The Put MPD call sends an MPD string of the piece placement.

--------

Interface call: Put FEN Scalars

The second through sixth fields of a FEN string are called the the FEN scalars. The interface needs to know the values of these scalars to maintain the position context retained for each connected chessboard. The Put FEN Scalars call sends a string of these scalar values to the interface.
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Board contexts

Post by sje »

Board contexts

The interface maintains a context for each connected chessboard. This context tracks the location of the chessmen as given by the board hardware plus all other data needed to describe the position to support communication using the chess data interchange standards.

This means that the interface is smart enough to talk to the host application using FEN and SAN instead of lower level coordinate formats. This also hides data representation formats specific to a particular manufacturer Further, this helps hide differences in the capability among different chessboard models.
ifekali
Member
Posts: 98
Joined: Thu Dec 05, 2013 11:19 am

Post by ifekali »

sje wrote:
Mark Uniacke wrote:Also I have a DGT Rev II which I could test with when the time comes...
This is good, because getting a Bluetooth DGT board or a Revelation II is not in my budget for the foreseeable future.
I can test on Citrine, DGT USB eboard and Rev II on Mac Pro.

-Izmet
Post Reply