Ben Hague schrieb:
Hello! > I've just got a Dream Cheeky USB Roll-Up Chess Game. > http://www.dreamlink.info/product/roll-up-chess-game.php . This uses a > very simple protocol where you press on the origin square and then the > destination square. I have written a simple driver and added support on > SCID by using the text move entry interface. > The problems I have are that this is Linux > only, doesn't fail gracefully and should be a configurable option. I'd suggest to think about wether it would not be a lot more convenient to define an interface within scid to connect hardware and define a protocol for that interface and interface any hardware with that. Adding every other input device via essentially the same TCL stuff will result (IMHO!) in a lot of douplicate code doing all the same things all over again and it will be PITA to keep this running. That is exactly the reason why I try to convince you all that this pretty simple xboard/uci-styled input engine protocol that just talks via stdio like any other chess engine is advantageous. Ben, maybe you'd want to consider having a look at http://dgtdrv.sourceforge.net and check out the protocol description at http://dgtdrv.sourceforge.net/dgtdrv-3.html. Its really simple you'd just have to add some read/write via stdio to your current TCL code it could all stay in tcl and be spawned by scid using the same backend I'm currently coding for the DGT. Point is: you'll also come to the same problems I'm just working on like checking wether the user did the correct moves and stuff like that, or if you don't have this problems it will work with my backend code as well and do this gracefull exit and stuff. I could surely mail you my current scid-code you could start upon. > However I know very little about tcl so I'm not clear on how this should > be done, particularly how to fit it into SCID properly. If you don't like TCL you could code it in <place your favourite language here> as I'd talk to your driver just by stdio :) > Also, it seems to would be nice to have all possible input devices, such > as the DGT or Citrine in the same place, but they appear to work in > rather different ways, so would this be possible? It is possible. That's exactly why I tend to suggest the input engine approach instead of hacking code into scid. :) BTW: DGT is working at least on the level you just described fo your driver, even a bit better. I'm currently working on more "what would the user expect it to look like" issues. We could also discuss it here or via PM. -- Kind regards, Alexander Wagner Universitaetsbibliothek Ilmenau Langewiesener Str. 37 98693 Ilmenau Tel.: 03677/69-4521 , Fax.: 03677/69-4617 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
