Good Morning! > I stopped for a while working on FICS because I received > my Novag Citrine.
:) I consider FICS something that has now some basic functionality but could be extended by others/later on. Maybe I'll also have a look into it but right now I'm working on DGT. > Right now I can enter moves on it and they are copied in > Scid, and vice versa. I've got problems through a > Bluetooth/serial link with Scid Pocket : I can send data > from Citrine to Pocket PC but the data sent from Pocket PC > does not seem to be received by the Citrine. Sounds strange. Did you also try with a "real computer"? Just to exclude a problem on CE. BTW: just to ask what adaptor are you using and what did you pay for it? I did not find anything resonable yet but did no deep digging. > I managed to play a game on FICS but things get difficult > to cope with when some errors are made by the user, and is > is very difficult to get things synchronized again. Well, at last ... ;) Actually that's the main point I'm talking about. It is not to connect the hardware as such, but the error handling and the interaction with the user in the sense that the user makes some mistake that poses the main difficulties. The recent version of the input engine code implements some error checking that seems ok also with boards that don't recognise the pieces as the one Ben mentioned and the Novag as well. (You can get it from the cvs at dgtdrv.sf.net.) Currently I can detect a wrong move by comparing scids internal position to the board position. That drops the requirement that scid tells me the last move made by the engine (though I'd still like to have that easily available). Generally the current input engine support fullfills the same functionality as you mentioned plus some additional features that require the driver to detect the pieces though. I.e. set scids current position to the one on the board, set up positions on the board and transfer them to scid, make moves for either side to input a game, all such tings. From that point you could say that we have full input engine support and a proof of concept for DGT boards since the end of last year. ;) But it's still the question I posed quite some time: how do we think scid should interact with the user if he uses some sort of HID? Another point is concerned with the problem of how to know wether the user plays black or white in an actual game or wether he plays both colours while entering a game / analysing, and how to switch these modes in a transparent manner. Currently this is done by setting it manually, but I'm not yet satsified with that. Did you already think of that? I could add another button to switch that between black, white and analysis mode, hm. Well... Maybe using the way by "setup mode" is more convenient, that is remove both kings and set them back with the colour to move last and then expect that this is the users side to play. If he then issues a "move now" I could switch sides. But then stays the problem how to enable analysis mode. By a switch play/analysis? What are the options for the Citrine here? How is it handled there? So we could come to some common implementation? Wouldn't it make sense to place all this handling code in an abstract way within some part of scid and implement only a driver for each piece of hardware instead of reinventing this all the time again? From maintainability I'd strongly vote for that. Some backend where I can send something like "e2e4" to instead that is then checked for validity and stuff and just returns "ok" or proper error codes? Some part of code that issues some "getboard" message when necessary to check positions and so on? Concerning dgt support in native tcl: could you give me a simple sample for _low level_ serial I/O? 9600 bps 8 bit 1 start one 1 stop, neither soft- nor hardware flow control, sending and receiving individual _bytes_, that is also strings that may start with char(0)? I'm not promising anything there but I did a first test version and it fails at this point already. DGTs interface is pretty "C-ish", and this has to be reproduced if you want to drop dgtnix libs and other external C stuff. I could supply the init-sequence in plain C in case... -- 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
