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

Testing

Post by sje »

For distributing intermediate versions of the interface, I'm going send only the source so that recipients can also test the build process. An added benefit is that people won't have to worry about getting any malware hidden in a binary executable file.
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Where is the USB port entry usder OS/X?

Post by sje »

ifekali wrote:I'm running the DGT board on the mac just fine. Here's me running picochess:
https://www.dropbox.com/s/kc6tr322r09c7 ... .17.31.png
For some reason, it appears that png images can't be embedded here.

The terminal window in the above image link says that the DGT board is living on the port /dev/cu.usbserial-fd521.

At present, I have my DGT USB board plugged into my Intel iMac OS/X 10.7.5 and it shows up in the system information summary as an FTDI USB <-> Serial device. This was expected. However, there is no corresponding entry in the /dev directory; no cu.usbserial-fd521. Any comments?
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Re: Where is the USB port entry usder OS/X?

Post by sje »

sje wrote:However, there is no corresponding entry in the /dev directory; no cu.usbserial-fd521. Any comments?
Answers:

Step 1: Go to http://www.ftdichip.com/Drivers/VCP.htm and get the FTDI VCP (Virtual COM Port) driver for Mac OS/X. (The Linux driver is also available from the page.)

Step 2: Install the driver.

Step 3: Reboot. (Might not be necessary here.)

Step 4: Attach the DGT USB board. This action will cause OS/X to load the FTDI driver kernel extension and it will also create a cu/tty pair of files in the /dev directory.

Step 5: From a Terminal window, go to the /dev directory and look for a file with a name starting with cu.usbserial. In my case, the entry was:

Code: Select all

crw-rw-rw-  1 root  wheel      17,   5 Dec 13 06&#58;51 cu.usbserial-0000101D
So far, so good.

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

Gestures

Post by sje »

Gestures

The term "gesture" appeared in the context of human-to-computer interface input back some twenty years ago. It means any manual device input more complex than the use of simple binary (buttons, keys) or simple analog (knobs, sliders).

Playing chess with a sensory board of any flavor qualifies as a use of gestures for interaction because such combines several different simpler interactions as parts of a composite input.

I classify chessboard gestures into four groups:

1. Move gestures to communicate moves;

2. Position gestures to set up a position including setting up a new game;

3. Termination gestures to indicate game termination status (resignation, draw acceptance, etc);

4. Meta gestures for program control (setting levels and options).
shiv
Member
Posts: 57
Joined: Sat Nov 24, 2007 10:32 pm

Re: Where is the USB port entry usder OS/X?

Post by shiv »

sje wrote:
ifekali wrote:I'm running the DGT board on the mac just fine. Here's me running picochess:
https://www.dropbox.com/s/kc6tr322r09c7 ... .17.31.png
For some reason, it appears that png images can't be embedded here.

The terminal window in the above image link says that the DGT board is living on the port /dev/cu.usbserial-fd521.

At present, I have my DGT USB board plugged into my Intel iMac OS/X 10.7.5 and it shows up in the system information summary as an FTDI USB <-> Serial device. This was expected. However, there is no corresponding entry in the /dev directory; no cu.usbserial-fd521. Any comments?
Hi, I am interested in this project as well. Interestingly, I have contributed to pico chess and also have my own chess GUI supporting the DGT board on Linux and Mac OS X at HTTPS://github.com/sshivaji/kivy-chess

The project currently requires many manual steps to build.

That project uses the dgtnix C++ libraries via python, dgtnix.so is a shared object accessible to python.
User avatar
Harvey Williamson
Site Admin
Posts: 6079
Joined: Sun Jul 29, 2007 6:57 am
Location: Media City, UK
Contact:

Re: Where is the USB port entry usder OS/X?

Post by Harvey Williamson »

sje wrote:
ifekali wrote:I'm running the DGT board on the mac just fine. Here's me running picochess:
https://www.dropbox.com/s/kc6tr322r09c7 ... .17.31.png
For some reason, it appears that png images can't be embedded here.
That png does not seem to work but it usually does. You need to use Image
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Re: Where is the USB port entry usder OS/X?

Post by sje »

Harvey Williamson wrote:
sje wrote:
ifekali wrote:I'm running the DGT board on the mac just fine. Here's me running picochess:
https://www.dropbox.com/s/kc6tr322r09c7 ... .17.31.png
For some reason, it appears that png images can't be embedded here.
That png does not seem to work but it usually does. You need to use Image
Not working for me. Spaces in filename? Using https vs http?
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Re: Where is the USB port entry usder OS/X?

Post by sje »

shiv wrote:That project uses the dgtnix C++ libraries via python, dgtnix.so is a shared object accessible to python.
My copy of dgtnix is written in C, not C++.

The design decision here is what to put in a library and what to put in the application code.

Anything dealing strictly with the low level physical details of the serial/USB link are independent of the application and so don't belong there. That's why I'll use the FTDI driver on OS/X; FTD wrote it and FTD hardware is used in the DGT board. (Except the old RS-232 DGT boards, which can be handled with a FTD serial/US adapter.)

The chess specific code could also go into a library of its own. However, since that code is small and is used no place other than the chess application, then it can be part of the source of the application. This is the best approach here because the code is open source and also because it allows the application developer to more easily adjust its functionality.

The interface source can be easily integrated into the application because of the namespace capability of C++. For chess software not written in C++,
the interface source could be run as a separate process and communicate with the application in one of several different ways.

--------

I placed my order for a DGT XL clock ten days ago, but the clock hasn't yet been shipped. It is hard to test hardware without the hardware.
shiv
Member
Posts: 57
Joined: Sat Nov 24, 2007 10:32 pm

Re: Where is the USB port entry usder OS/X?

Post by shiv »

sje wrote:
shiv wrote:That project uses the dgtnix C++ libraries via python, dgtnix.so is a shared object accessible to python.
My copy of dgtnix is written in C, not C++.

The design decision here is what to put in a library and what to put in the application code.

Anything dealing strictly with the low level physical details of the serial/USB link are independent of the application and so don't belong there. That's why I'll use the FTDI driver on OS/X; FTD wrote it and FTD hardware is used in the DGT board. (Except the old RS-232 DGT boards, which can be handled with a FTD serial/US adapter.)

The chess specific code could also go into a library of its own. However, since that code is small and is used no place other than the chess application, then it can be part of the source of the application. This is the best approach here because the code is open source and also because it allows the application developer to more easily adjust its functionality.

The interface source can be easily integrated into the application because of the namespace capability of C++. For chess software not written in C++,
the interface source could be run as a separate process and communicate with the application in one of several different ways.

--------

I placed my order for a DGT XL clock ten days ago, but the clock hasn't yet been shipped. It is hard to test hardware without the hardware.
I meant C for the dgtnix adapter, C++ is used in pico chess as the application layer. I have modified dgtnix.c several times, adding rudimentary error recovery logic, support for DGT clock buttons, and most recently support for execution on Android. Dgtnix.c is viewable at https://github.com/jromang/Stockfish/bl ... c/dgtnix.c

You can also compile it via the python bridge at https://github.com/sshivaji/kivy-chess/tree/master/dgt
Instructions are on the page. You dont need a DGT XL clock to test this interaction.

Do you have published specs somewhere that I can comment on for the library? I see that some of your earlier posts on this thread cover some of the API. My current gripes/areas for improvement with the current dgtnix are:

1. Very sensitive to electrical interference.
2. Not easy to make work on Android. I had to root my android and install ftdi on it. Was not easy to replicate on other devices.

I am glad you are planning to improve DGT support on non windows platforms. It was to precisely to get this working well on OSX/Linux that I had to write an open source app from scratch (kivy chess)!
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Interface specifications

Post by sje »

shiv wrote:Do you have published specs somewhere that I can comment on for the library? My current gripes/areas for improvement with the current dgtnix are:

1. Very sensitive to electrical interference.
2. Not easy to make work on Android. I had to root my android and install ftdi on it. Was not easy to replicate on other devices.
All of the FTDI information I've seen can be found at the FTD site: http://www.ftdichip.com/

Low level physical and timing characteristics of the communication links with board hardware are the responsibility of the makers (FTD and perhaps others), as they are the ones who know the hardware and wrote the OS specific drivers.

To reduce confusion, I will now give a name to my little interface project. It is now called ESCI (Edwards' Simple Chessboard Interface).

All of the ESCI specifications will appear in this forum or in documentation files clearly referenced here.

Essentially, an application and the ESCI will communicate by passing ASCII text strings. There may be a pair of special calls for initialization and termination. Unix signaling may be used to assist with efficient asynchronous messaging. The ESCI code will live in its own C++ namespace and will not share any class definitions with the controlling application.

The ESCI code will as much as possible remain ignorant of low level communications issues which might be dependent on the hardware makers. The ESCI will talk with its controlling application ot the chess level with moves and positions using SAN, FEN, and the like. There might be some timing customization parameters set by the controlling application, but only to make things easier for humans to handle pieces with less chance of move error entry.
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Routines and calls

Post by sje »

Routines:

To read a string from the interface:

Code: Select all

ESCI&#58;&#58;ReadString&#40;<string-variable>&#41;;
A ReadString() call will return the empty string if the board has nothing to say.

To write a string to the interface:

Code: Select all

ESCI&#58;&#58;WriteString&#40;<string-expression>&#41;;
A WriteString() call sending the empty string does nothing.

Input from the board for a move:

Code: Select all

ESCI&#58;&#58;ReadString&#40;&#41;; -> "Usermove Nf3"
Note that SAN is used and no illegal moves are sent.

Output to the board for a move:

Code: Select all

ESCI&#58;&#58;WriteString&#40;"Playmove d5"&#41;;
Again, illegal moves are not allowed. The interface does full, exact checking in all cases.
shiv
Member
Posts: 57
Joined: Sat Nov 24, 2007 10:32 pm

Re: Routines and calls

Post by shiv »

sje wrote: Input from the board for a move:

Code: Select all

ESCI&#58;&#58;ReadString&#40;&#41;; -> "Usermove Nf3"
Note that SAN is used and no illegal moves are sent.
How will you implement ReadString to read a move. In my case, I had to get previous fen, store it, Get New fen, compute all legal moves on old fen. Finally, return the legal move that successfully worked. Is your interface planning to take care of this whole interaction? That would be quite useful.
User avatar
sje
Full Member
Posts: 639
Joined: Sat Sep 28, 2013 2:28 am
Location: Land of Snow, Mud, and Bugs, NH USA

Re: Routines and calls

Post by sje »

shiv wrote:How will you implement ReadString to read a move. In my case, I had to get previous fen, store it, Get New fen, compute all legal moves on old fen. Finally, return the legal move that successfully worked. Is your interface planning to take care of this whole interaction? That would be quite useful.
The ESCI will know all the Rules of Chess and all applicable Chess Data Interchange standards.
shiv
Member
Posts: 57
Joined: Sat Nov 24, 2007 10:32 pm

Re: Routines and calls

Post by shiv »

sje wrote:
shiv wrote:How will you implement ReadString to read a move. In my case, I had to get previous fen, store it, Get New fen, compute all legal moves on old fen. Finally, return the legal move that successfully worked. Is your interface planning to take care of this whole interaction? That would be quite useful.
The ESCI will know all the Rules of Chess and all applicable Chess Data Interchange standards.
That would be great. This frees up the application from performing cumbersome logic. In addition, it is useful to have this interaction work via ESCI as python code to do the same can be far slower than C++. Will watch for new developments in this thread.
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 »

The compliance to standards is a two way street. The ESCI will output exact SAN and FEN, but it also expects exact SAN and FEN. And this could mean some adjustments for other programs.

Examples:

SAN strings with extraneous disambiguation will be rejected. (Fritz has been seen to emit these.)

SAN strings with a missing promotion indicator will be rejected. (Stockfish has been seen to emit these.)
Post Reply