dgtdrv aims to be a uci/xboard/crafty compatible interface (input engine) for the DGT Electronic Chess board on POSIX platforms. It relies on the dgtnix library.
I've built this and successfully connected my DGT board to SCID. No need to patch SCID. The input driver code is in the current version already. (Tools->connect hardware-->)
dgtnix (dgtnix.sourceforge.net) built without problems on Ubuntu 18.10, but the dgtdrv was a bit harder. Since it's not updated since 2009 it's to be expected that things have changed. Anyway, after some debugging I got it to work...
Maybe it's time to update the code. It's really nice to be able to connect the DGT board to SCID on linux. This code is great and deserves a little attention from someone who knows what they are doing.
Building on Ubuntu:
In the sourcefiel dgtdrv2.cpp add the unistd headers. Add it it among the includes in the start of the source.
#include<unistd.h>
In the makefile the -ldgtnix needs to be stated after libs. If not it wont build on ubuntu distros, but create undefined reference errors about dgtnix even though it's there. Strangely it still works on debian distros.
So changing the Makefile makes it work in ubuntu to. Look in the bottom of the makefile and move the -ldgtnix parameter like so:
Maybe the best solution would be to port the configuration to autoconf.
The binary goes SIGSEGV after initialization.
The compiled binary throws a SIGSEGV after initializing the board. This happens when PrintFEN() is calling WriteInfoString(). For some reason InfoStr becomes (null). Just disabling writing to the log fixes it.
va_list ap;
va_start(ap, InfoStr);
vfprintf(stdout, InfoStr, ap);
// Debug:
// When printing the FEN, the second vfprintf gets a null and
// causes a SIGSEGV.
// Haven't found the root cause.
// vfprintf(LOGFILE, InfoStr, ap);
va_end(ap);
Even more strange. When debugging I got help and threw a fprintf to stderr in PrintFEN() just before WriteInfoString. This then made the SIGSEGV go away, and also fixed things, but the log just reads "INFO FEN (null)" If someone wants to fix it this way this is what I did that fixed it:
fprintf(stderr, "pos is %d and FEN is '%s'\n", pos, FEN);
WriteInfoString("FEN %s\n", FEN);
It works, but it's not obvious to me why...
Last edit: Lars Christian 2019-01-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I've built this and successfully connected my DGT board to SCID. No need to patch SCID. The input driver code is in the current version already. (Tools->connect hardware-->)
dgtnix (dgtnix.sourceforge.net) built without problems on Ubuntu 18.10, but the dgtdrv was a bit harder. Since it's not updated since 2009 it's to be expected that things have changed. Anyway, after some debugging I got it to work...
Maybe it's time to update the code. It's really nice to be able to connect the DGT board to SCID on linux. This code is great and deserves a little attention from someone who knows what they are doing.
Building on Ubuntu:
In the sourcefiel dgtdrv2.cpp add the unistd headers. Add it it among the includes in the start of the source.
In the makefile the -ldgtnix needs to be stated after libs. If not it wont build on ubuntu distros, but create undefined reference errors about dgtnix even though it's there. Strangely it still works on debian distros.
So changing the Makefile makes it work in ubuntu to. Look in the bottom of the makefile and move the -ldgtnix parameter like so:
Maybe the best solution would be to port the configuration to autoconf.
The binary goes SIGSEGV after initialization.
The compiled binary throws a SIGSEGV after initializing the board. This happens when PrintFEN() is calling WriteInfoString(). For some reason InfoStr becomes (null). Just disabling writing to the log fixes it.
Even more strange. When debugging I got help and threw a fprintf to stderr in PrintFEN() just before WriteInfoString. This then made the SIGSEGV go away, and also fixed things, but the log just reads "INFO FEN (null)" If someone wants to fix it this way this is what I did that fixed it:
It works, but it's not obvious to me why...
Last edit: Lars Christian 2019-01-04