From: Jan K. | D. <ja...@dg...> - 2008-11-18 08:40:53
|
Hello Alexander, Ben asked me to add some more information. >-----Original Message----- >> The information on how to send a message to the clock is not easy >> available. It is not in the DGTbrd13.h board protocol description. >> In the past, which information did you get on all communication >> protocols? > >All protocol descriptions I've at hand is this very dgtbrd13.h file >offered for download at the dgt website. Most of the time I sit with my >application on top of the dgtnix library itself, so I did not have the >necessity to dig to deep into it while working on dgtdrv. I think >sending messages to the clock should be a function there and I'd try to >add it. But I did not yet search in detail how it has to be done. My >primary work this weekend was to get Scid interface with the board/clock >nicely. Now that the base functions are all there I'm planing to get it >"nice" ie. add all that is available in the windows driver. Sending messages to the clock are effectively clock messages embedded in the board protocol. I have look up the information how this works. Unfortunately I do not have a document lying around that describes it. I have to dive into the sources for making a description of this. Give me some time for this, as I'm too busy with a lot of things at the moment. >BTW: any interest in the protocol I used for dgtdrv on your side? E.g. >doing an own application? I think it would be pretty simple to set up a >small app using your own lib. One idea of this protocol is, that >acutally any chess application that know how to play an engine-engine >tournament is able to get minimal DGT support and with a few extra lines >within the app to add handling for a hand full of new message it gets a >pretty smooth integration as it offers also functions to send the board >position and so on. I did something like that for xboard as an example, >its only about 50 lines. For a protocol description see dgtdrv.sf.net, >it is very much like xbord and uci. (You know, for a multiplatform >product like Scid, which runs on a variety of Unices, Windows, Mac... it >is a bit difficult to bind to different external libs so I feel it >easier to use an engine like approach. The only alternative for Scid >would be to code all DGT handling in plain TCL which would then be only >usable for Scid. I gave that a try but its cumbersome and I admit that I >really prefer C. And the interface idea from an design point of view.) You're the second person in two days to mention the engine approach. I was organizing the Open Dutch Computer Chess Championships last weekend (Rybka won) and somebody there mentioned the same. And as far as I know we have already some software that behaves like that. For ChessMaster we have the Gamekeeper program that behaves like an engine. Of course this is only for the Windows platform. I discussed with Ben the engine approach and why this has not done before. It seemed the difference between human and machine behavior makes the implementation of a engine too difficult, e.g. the taking back of the moves. I think this worth to look at again. To make a correct engine it should be fully XBoard and UCI compliant, so many chess related programs can benefit from this. My guess is that the extra commands will not be used much, unless they are added in the XBoard and UCI protocols. With kind regards, Met vriendelijke groet, Jan Krabbenbos Software Development Official Supplier Chess Olympiad 2008 Dresden Phone: +31(0)53-4305195 Fax: +31(0)53-4329365 http://www.dgtprojects.com visit address: Hengelosestraat 66, 7514 AJ Enschede, The Netherlands mail address: PO Box 1295, 7500 BG Enschede, The Netherlands |