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 Previous  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: Fri Dec 13, 2013 12:33 am    Post subject: Testing Reply with quote

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.
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 13, 2013 2:52 am    Post subject: Where is the USB port entry usder OS/X? Reply with quote

ifekali wrote:
I'm running the DGT board on the mac just fine. Here's me running picochess:
https://www.dropbox.com/s/kc6tr322r09c7os/Screenshot%202013-12-08%2018.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?
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 13, 2013 12:07 pm    Post subject: Re: Where is the USB port entry usder OS/X? Reply with quote

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:
crw-rw-rw-  1 root  wheel      17,   5 Dec 13 06:51 cu.usbserial-0000101D

So far, so good.

More to come.
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: Sun Dec 15, 2013 6:16 am    Post subject: Gestures Reply with quote

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


Joined: 24 Nov 2007
Posts: 52

PostPosted: Sun Dec 15, 2013 7:51 am    Post subject: Re: Where is the USB port entry usder OS/X? Reply with quote

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/kc6tr322r09c7os/Screenshot%202013-12-08%2018.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.
Back to top
View user's profile Send private message
Harvey Williamson
Site Admin


Joined: 29 Jul 2007
Posts: 5928
Full Name: Harvey Williamson
Location: Media City, UK

PostPosted: Sun Dec 15, 2013 9:50 am    Post subject: Re: Where is the USB port entry usder OS/X? Reply with quote

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/kc6tr322r09c7os/Screenshot%202013-12-08%2018.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 [img] in the tags not png


_________________
www.Hiarcs.com
Back to top
View user's profile Send private message Send e-mail 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: Sun Dec 15, 2013 2:56 pm    Post subject: Re: Where is the USB port entry usder OS/X? Reply with quote

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/kc6tr322r09c7os/Screenshot%202013-12-08%2018.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 [img] in the tags not png


Not working for me. Spaces in filename? Using https vs http?
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: Sun Dec 15, 2013 3:17 pm    Post subject: Re: Where is the USB port entry usder OS/X? Reply with quote

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


Joined: 24 Nov 2007
Posts: 52

PostPosted: Sun Dec 15, 2013 5:55 pm    Post subject: Re: Where is the USB port entry usder OS/X? Reply with quote

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/blob/dgt/src/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)!
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: Sun Dec 15, 2013 6:23 pm    Post subject: Interface specifications Reply with quote

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.
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: Sun Dec 15, 2013 6:39 pm    Post subject: Routines and calls Reply with quote

Routines:

To read a string from the interface:
Code:
ESCI::ReadString(<string-variable>);

A ReadString() call will return the empty string if the board has nothing to say.

To write a string to the interface:
Code:
ESCI::WriteString(<string-expression>);

A WriteString() call sending the empty string does nothing.

Input from the board for a move:
Code:
ESCI::ReadString(); -> "Usermove Nf3"

Note that SAN is used and no illegal moves are sent.

Output to the board for a move:
Code:
ESCI::WriteString("Playmove d5");

Again, illegal moves are not allowed. The interface does full, exact checking in all cases.
Back to top
View user's profile Send private message
shiv
Member


Joined: 24 Nov 2007
Posts: 52

PostPosted: Sun Dec 15, 2013 6:53 pm    Post subject: Re: Routines and calls Reply with quote

sje wrote:

Input from the board for a move:
Code:
ESCI::ReadString(); -> "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.
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: Sun Dec 15, 2013 6:56 pm    Post subject: Re: Routines and calls Reply with quote

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


Joined: 24 Nov 2007
Posts: 52

PostPosted: Sun Dec 15, 2013 7:55 pm    Post subject: Re: Routines and calls Reply with quote

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.
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: Mon Dec 16, 2013 2:30 am    Post subject: Reply with quote

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.)
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 Previous  1, 2, 3, 4  Next
Page 2 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