On 06/01/11 13:57, Jan Krabbenbos wrote: Hello Jan!
> Is there anybody who has experience how to connect a DGT EBoard with SCID > under Windows? Is it just compiling dgtdrv and connect this through an Input > Engine with the board? I have a customer asking this and have not done this > yet myself. I never tried to compile dgtdrv myself on Windows, still I think dgtdrv wouldn't actually pose a problem here. It's plain C/C++ using only std i/o and doesn't contain any hardware specific code. If you use it you'll most likely run into difficulties with dgtnix libs in the backend containing all hardware specific code or the way how Windows handles a serial USB connection. E.g. I got dgtnix compiling out of the box on a Mac, dgtdrv startet up nicely, but it never got any answer back from the board at all. If I understood the issues correctly they stem from the missing handshake in the DGT protocol specs. It seems that the Mac drivers insist on hardware handshake or any handshake at all while the DGT board doesn't use either kind. So I sent the hello to the board, it might even have answered, but the driver sat there and waited forever for the handshake to complete. I think Pascal had a similar issue with the Novag Citrine connecting to Scid, at least I have some solution in mind involving a soldering iron and connecting two pins to get the Citrine working with his Windows CE port, so it seems to be similar there as well. @dgtdrv/Mac I was not able to resolve this issue myself being almost ignorant of hardware stuff and I didn't want to use a soldering iron and connect something I soldered together to the MacPro of a colleague. At least not without proper insurance... ;) Anyway, I think the easiest way for you @DGT is to build a simple input engine based on your own libs. In Scid you can specify which engine to call, so it doesn't have to share a name or whatever. Just go to Tools/Connect Hardware/Configure. Scid expects a port, an engine command and an engine parameter. You can see those for dgtdrv here: http://dgtdrv.sourceforge.net/dgtdrv-6.html They are just passed to the external program in the form external.exe port parameter literally. So you can come up with whatever you want here. The procotol for input engine is also simple, it's mainly xboard/uci (for this usecase the difference doesn't matter as I ignore most of the input from the GUI anyway as they are not applicable) plus some extensions specified here: http://dgtdrv.sourceforge.net/dgtdrv-3.html There might even be a suitable tool for Windows around (I'm ingorant of that platform myself, so I don't know). You could basically use every tool that allows to use xboard in an engine-engine match where the other engine is the DGT. Such a tool however will not allow for the special moves defined in input engine protocol like position setup, the DGT's version of "new game" and so on, so I think it is wise to add the parameters input engine protocol adds. It really tries to be a minimal superset to xboard/uci. You might like to note that the current maintainer of xboard/winboard just contacted me to implement those additions there as well and as an official addition to xboard protocol. -- Kind regards, / War is Peace. | Freedom is Slavery. Alexander Wagner | Ignorance is Strength. | | Theory : G. Orwell, "1984" / In practice: USA, since 2001 ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
