Once again. I'm thinking about buying a DGT e-Board: http://www.dgtprojects.com/site/index.p ... nic-boards
The model of interest is the Bluetooth board which was introduced in 2009. After four years on the market, I assume that any bugs have been resolved.
The price of the board, pieces, and a DGT XL clock is about US$1,250. That's a nontrivial amount for me, so I need to have some questions answered before ordering.
1. Is the Bluetooth version essentially the same as the USB version in regard to interfacing software? There is already some USB interfacing code out there at http://dgtdrv.sourceforge.net/ and it would be nice if the same would run with Bluetooth.
2. How critical are the applications which come from DGT, all of which are for Windows? I don't want to buy a Windows box just to configure the board! Would these programs run under Linux under WINE? This could be a real showstopper.
3. Where is a reputable DGT dealer in the US? Some DGT dealers do not carry the e-Board, only DGT clocks. Our sponsor is listed as a DGT dealer, but I see no DGT products there.
4. Are there any DGT e-Board applications which run on Android or iOS devices?
DGT e-Board
Moderator: Ras
-
hgm
- Posts: 28403
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: DGT e-Board
Perhaps a bit off-topic, but I was wondering what extensions to XBoard protocol would be needed to allow a DGT board driver to conect to it as an engine. For playing against another engine it is possible to put the GUI in match mode, and when the user of the board indicates he wants to start a new game (e.g. by setting up the initial position there, placing the King of the color he wants to play last), the board can simply terminate any ongoing game through existing protocol RESULT messages, and terminate again when it gets assigned the wrong color by the GUI, so that the GUI will finally start the game for it in the right color (as in matches the colors alternate).
Setting up arbitrary positions is already possible through the undocumented 'setup FEN' engine->GUI command, which in the current XBoard implementation will only be obeyed when legality-testing is off, however. Unconditional obeyance could easily be made subject to a new XBoard option, however.
The main problem seems to be to use the game for analysis. What you would ideally want is to allow the user to play moves on the board, while an engine is spewing out analysis on the current position on the computer display. This requires a mode that is currently not supported by XBoard ata all, where two 'engines' are loaded (the board-driver pseudo engine and a real one), one of the two is in analysis mode, while the other is able to play moves for both sides!
In normal analysis mode XBoard is able to do analysis with two engines in parallel, however. So it would already be possible to run XBoard with board as first engine, and the real engine as second engine, and switch on this dual-engine analysis mode. Of course the board would never spew out any variants. But it would be only a minor protocol extension to allow engines to play moves in analysis mode, as well as receiving them. No exisiting real engine would ever do that, of course. But if the GUI in analysis mode would accept moves from any engine, and respond to it like the user would have entered that move (i.e. play it in the GUI and send it to the engines), the board could send such moves as the user plays them.
I guess the easiest way to implement it in the GUI would be to send the move to all engines, also back to the one that provides it (so you would not have to add code to make an exception for that). So the move sent by the engine in analysis mode should not be interpreted by the GUI as a move that engine already played, but more like a move hint for the move it wants the GUI to play. So it would perhaps be logical to use the existing 'Hint: MOVE' command for this, rather than the 'move MOVE' command.
It might also be good to have reverse timing commands, (to set the GUI clock from the engine), or even allow setting of the TC mode from the engine. That way the GUI clocks could be enslaved to the DGT clocks connected to the board. It would also be useful for pseudo-engines that are in reality communication adapters for peer-to-peer play, or connecting to (non-ICS) servers.
Setting up arbitrary positions is already possible through the undocumented 'setup FEN' engine->GUI command, which in the current XBoard implementation will only be obeyed when legality-testing is off, however. Unconditional obeyance could easily be made subject to a new XBoard option, however.
The main problem seems to be to use the game for analysis. What you would ideally want is to allow the user to play moves on the board, while an engine is spewing out analysis on the current position on the computer display. This requires a mode that is currently not supported by XBoard ata all, where two 'engines' are loaded (the board-driver pseudo engine and a real one), one of the two is in analysis mode, while the other is able to play moves for both sides!
In normal analysis mode XBoard is able to do analysis with two engines in parallel, however. So it would already be possible to run XBoard with board as first engine, and the real engine as second engine, and switch on this dual-engine analysis mode. Of course the board would never spew out any variants. But it would be only a minor protocol extension to allow engines to play moves in analysis mode, as well as receiving them. No exisiting real engine would ever do that, of course. But if the GUI in analysis mode would accept moves from any engine, and respond to it like the user would have entered that move (i.e. play it in the GUI and send it to the engines), the board could send such moves as the user plays them.
I guess the easiest way to implement it in the GUI would be to send the move to all engines, also back to the one that provides it (so you would not have to add code to make an exception for that). So the move sent by the engine in analysis mode should not be interpreted by the GUI as a move that engine already played, but more like a move hint for the move it wants the GUI to play. So it would perhaps be logical to use the existing 'Hint: MOVE' command for this, rather than the 'move MOVE' command.
It might also be good to have reverse timing commands, (to set the GUI clock from the engine), or even allow setting of the TC mode from the engine. That way the GUI clocks could be enslaved to the DGT clocks connected to the board. It would also be useful for pseudo-engines that are in reality communication adapters for peer-to-peer play, or connecting to (non-ICS) servers.
-
sje
- Posts: 4675
- Joined: Mon Mar 13, 2006 7:43 pm
Re: DGT e-Board
This is discussed at the SourceForge link above.hgm wrote:Perhaps a bit off-topic, but I was wondering what extensions to XBoard protocol would be needed to allow a DGT board driver to conect to it as an engine.
-
hgm
- Posts: 28403
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: DGT e-Board
Hmm.. Unfortunately the document where this is supposed to be discussed (the protocol description) gives a 404 error...
-
sje
- Posts: 4675
- Joined: Mon Mar 13, 2006 7:43 pm
Re: DGT e-Board
Perhaps you want http://dgtdrv.sourceforge.net/dgtdrv-3.htmlhgm wrote:Hmm.. Unfortunately the document where this is supposed to be discussed (the protocol description) gives a 404 error...
-
CRoberson
- Posts: 2094
- Joined: Mon Mar 13, 2006 2:31 am
- Location: North Carolina, USA
Re: DGT e-Board
Since you say our sponsor doesn't carry them:
Chess Central: http://www.chesscentral.com/DGT_Electro ... _s/198.htm
wholesalechess: http://www.wholesalechess.com/shop/ches ... -chess-set
chesshouse.com: http://www.chesshouse.com/dgt_electroni ... _s/361.htm
Chess Central: http://www.chesscentral.com/DGT_Electro ... _s/198.htm
wholesalechess: http://www.wholesalechess.com/shop/ches ... -chess-set
chesshouse.com: http://www.chesshouse.com/dgt_electroni ... _s/361.htm
-
sje
- Posts: 4675
- Joined: Mon Mar 13, 2006 7:43 pm
Re: DGT e-Board
There are several DGT North American dealers listed here: http://www.dgtnorthamerica.com/dealers.htmlCRoberson wrote:Since you say our sponsor doesn't carry them:
Chess Central: http://www.chesscentral.com/DGT_Electro ... _s/198.htm
wholesalechess: http://www.wholesalechess.com/shop/ches ... -chess-set
chesshouse.com: http://www.chesshouse.com/dgt_electroni ... _s/361.htm
And here: http://www.dgtprojects.com/site/index.p ... ted-states
But how many of them actually carry the electronic boards in stock? Perhaps none, as the board is a costly, low volume item. My guess is that most will offer delivery in two weeks, the first of which is waiting for the item to be shipped from Europe.
-
CRoberson
- Posts: 2094
- Joined: Mon Mar 13, 2006 2:31 am
- Location: North Carolina, USA
Re: DGT e-Board
Looks like a DGT board will work under LINUX with SCID.
Under SCID, click "connect hardware" -> configure. A box comes up and click the radio button for "input engine".
According the SCID's "HELP->index->DGT Electronic Chess Board" you can get the device driver from http://dgtdrv.sourceforge.net/
So, there you have plenty of reading and the possibility of it working.
My response might have been RTFM if there actually were a man page.
Under SCID, click "connect hardware" -> configure. A box comes up and click the radio button for "input engine".
According the SCID's "HELP->index->DGT Electronic Chess Board" you can get the device driver from http://dgtdrv.sourceforge.net/
So, there you have plenty of reading and the possibility of it working.
My response might have been RTFM if there actually were a man page.
-
sje
- Posts: 4675
- Joined: Mon Mar 13, 2006 7:43 pm
Re: DGT e-Board
Thank you for the tip. I've already got scid up and running. but I haven't done much with it yet.CRoberson wrote:Looks like a DGT board will work under LINUX with SCID.
My hope is that the wine API emulation running under Linux can handle the DGT bundled Windows applications, although I'm not ready to bet the farm on that one. As a very last resort, I've got an old Windows XP install disk from seven years ago that I can use on an old notebook that's not good for much else.
Getting a piece recognition board will be a big help doing analysis. Trying to manually set up a position on the Citrine is truly painful. And who knows, I might just get personal accounts on FICS and ICS so I can be mauled without having to stare at a computer screen.