DGT board C++ interface project
Moderators: Harvey Williamson, Watchman
- sje
- Full Member
- Posts: 639
- Joined: Sat Sep 28, 2013 2:28 am
- Location: Land of Snow, Mud, and Bugs, NH USA
Testing
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.
- 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?
For some reason, it appears that png images can't be embedded here.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
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?
- 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?
Answers:sje wrote:However, there is no corresponding entry in the /dev directory; no cu.usbserial-fd521. Any comments?
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:51 cu.usbserial-0000101D
More to come.
- sje
- Full Member
- Posts: 639
- Joined: Sat Sep 28, 2013 2:28 am
- Location: Land of Snow, Mud, and Bugs, NH USA
Gestures
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).
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).
Re: Where is the USB port entry usder OS/X?
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-chesssje wrote:For some reason, it appears that png images can't be embedded here.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
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?
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.
- 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?
That png does not seem to work but it usually does. You need to usesje wrote:For some reason, it appears that png images can't be embedded here.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
- 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?
Not working for me. Spaces in filename? Using https vs http?Harvey Williamson wrote:That png does not seem to work but it usually does. You need to usesje wrote:For some reason, it appears that png images can't be embedded here.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
- 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?
My copy of dgtnix is written in C, not C++.shiv wrote:That project uses the dgtnix C++ libraries via python, dgtnix.so is a shared object accessible to python.
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.
Re: Where is the USB port entry usder OS/X?
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.csje wrote:My copy of dgtnix is written in C, not C++.shiv wrote:That project uses the dgtnix C++ libraries via python, dgtnix.so is a shared object accessible to python.
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.
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)!
- sje
- Full Member
- Posts: 639
- Joined: Sat Sep 28, 2013 2:28 am
- Location: Land of Snow, Mud, and Bugs, NH USA
Interface specifications
All of the FTDI information I've seen can be found at the FTD site: http://www.ftdichip.com/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.
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.
- 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
Routines:
To read a string from the interface:
A ReadString() call will return the empty string if the board has nothing to say.
To write a string to the interface:
A WriteString() call sending the empty string does nothing.
Input from the board for a move:
Note that SAN is used and no illegal moves are sent.
Output to the board for a move:
Again, illegal moves are not allowed. The interface does full, exact checking in all cases.
To read a string from the interface:
Code: Select all
ESCI::ReadString(<string-variable>);
To write a string to the interface:
Code: Select all
ESCI::WriteString(<string-expression>);
Input from the board for a move:
Code: Select all
ESCI::ReadString(); -> "Usermove Nf3"
Output to the board for a move:
Code: Select all
ESCI::WriteString("Playmove d5");
Re: Routines and calls
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.sje wrote: Input from the board for a move:Note that SAN is used and no illegal moves are sent.Code: Select all
ESCI::ReadString(); -> "Usermove Nf3"
- 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
The ESCI will know all the Rules of Chess and all applicable Chess Data Interchange standards.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.
Re: Routines and calls
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.sje wrote:The ESCI will know all the Rules of Chess and all applicable Chess Data Interchange standards.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.
- sje
- Full Member
- Posts: 639
- Joined: Sat Sep 28, 2013 2:28 am
- Location: Land of Snow, Mud, and Bugs, NH USA
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.)
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.)