HIARCS Chess Forums Forum Index HIARCS Chess Forums
World Championship winning computer chess software program & downloads for chess database, analysis and play on PC, Mac and iPhone
 
 QuestionsQuestions   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Private MessagesPrivate Messages   Log inLog in 

DGT board C++ interface project
Goto page 1, 2, 3, 4  Next
 
Post new topic   Reply to topic    HIARCS Chess Forums Forum Index -> Programming Discussions
View previous topic :: View next topic  
Author
sje
Full Member


Joined: 28 Sep 2013
Posts: 639
Full Name: Steven Edwards
Location: Land of Snow, Mud, and Bugs, NH USA

PostPosted: Thu Nov 28, 2013 10:32 pm    Post subject: DGT board C++ interface project Reply with quote

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.
Back to top
View user's profile Send private message
ifekali
Member


Joined: 05 Dec 2013
Posts: 97

PostPosted: Thu Dec 05, 2013 3:58 pm    Post subject: Re: DGT board C++ interface project Reply with quote

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
Back to top
View user's profile Send private message
sje
Full Member


Joined: 28 Sep 2013
Posts: 639
Full Name: Steven Edwards
Location: Land of Snow, Mud, and Bugs, NH USA

PostPosted: Fri Dec 06, 2013 4:43 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
fourthirty
Member


Joined: 06 Dec 2013
Posts: 278
Full Name: Greg
Location: San Francisco

PostPosted: Sat Dec 07, 2013 2:04 am    Post subject: Reply with quote

Very interested also. Thanks sje!
Back to top
View user's profile Send private message
sje
Full Member


Joined: 28 Sep 2013
Posts: 639
Full Name: Steven Edwards
Location: Land of Snow, Mud, and Bugs, NH USA

PostPosted: Sat Dec 07, 2013 4:56 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Mark Uniacke
Hiarcs Author


Joined: 29 Jul 2007
Posts: 1266
Full Name: Mark Uniacke
Location: United Kingdom

PostPosted: Wed Dec 11, 2013 1:28 am    Post subject: Reply with quote

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

http://www.hiarcs.com
Back to top
View user's profile Send private message Visit poster's website
sje
Full Member


Joined: 28 Sep 2013
Posts: 639
Full Name: Steven Edwards
Location: Land of Snow, Mud, and Bugs, NH USA

PostPosted: Wed Dec 11, 2013 1:46 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Mark Uniacke
Hiarcs Author


Joined: 29 Jul 2007
Posts: 1266
Full Name: Mark Uniacke
Location: United Kingdom

PostPosted: Wed Dec 11, 2013 2:24 am    Post subject: Reply with quote

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

http://www.hiarcs.com
Back to top
View user's profile Send private message Visit poster's website
sje
Full Member


Joined: 28 Sep 2013
Posts: 639
Full Name: Steven Edwards
Location: Land of Snow, Mud, and Bugs, NH USA

PostPosted: Wed Dec 11, 2013 2:29 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Mark Uniacke
Hiarcs Author


Joined: 29 Jul 2007
Posts: 1266
Full Name: Mark Uniacke
Location: United Kingdom

PostPosted: Wed Dec 11, 2013 2:36 am    Post subject: Reply with quote

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

http://www.hiarcs.com
Back to top
View user's profile Send private message Visit poster's website
sje
Full Member


Joined: 28 Sep 2013
Posts: 639
Full Name: Steven Edwards
Location: Land of Snow, Mud, and Bugs, NH USA

PostPosted: Wed Dec 11, 2013 2:13 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
sje
Full Member


Joined: 28 Sep 2013
Posts: 639
Full Name: Steven Edwards
Location: Land of Snow, Mud, and Bugs, NH USA

PostPosted: Wed Dec 11, 2013 2:15 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
sje
Full Member


Joined: 28 Sep 2013
Posts: 639
Full Name: Steven Edwards
Location: Land of Snow, Mud, and Bugs, NH USA

PostPosted: Wed Dec 11, 2013 3:06 pm    Post subject: Some interface calls Reply with quote

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

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

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.
Back to top
View user's profile Send private message
sje
Full Member


Joined: 28 Sep 2013
Posts: 639
Full Name: Steven Edwards
Location: Land of Snow, Mud, and Bugs, NH USA

PostPosted: Wed Dec 11, 2013 3:26 pm    Post subject: Board contexts Reply with quote

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.
Back to top
View user's profile Send private message
ifekali
Member


Joined: 05 Dec 2013
Posts: 97

PostPosted: Thu Dec 12, 2013 11:19 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    HIARCS Chess Forums Forum Index -> Programming Discussions All times are GMT
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP