Alexander Wagner a écrit : > 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. > I found the solution : I needed to link pin 7 and 8 of the serial link (CTS and RTS). Three days to fix this bug ... > 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 bought a Iogear GBS301 (Bluetooth class 1 with a range of 100 m). http://www.amazon.fr/Adaptateur-S%C3%A9rie-Bluetooth-Classe-100m/dp/B000CPMBO6/ref=sr_1_1?ie=UTF8&s=electronics&qid=1199727684&sr=8-1 I ordered it at : http://www.expansys.com/
The price is the lowest I found on internet (about 60 €), and at least it works with the Novag Citrine and my PDA (Dell Axim x51v). > > 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. > > Yes, I start to fully agree ;-) > 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? > As you stated before, there is a need of a general interface for HID : - board will not send their moves in the same format; - when the board sends a move, it should also be sent to FICS, if connected AND playing a game; - when the board has a starting position this should trigger a "sc_game new" - etc. I have a general problem with moves handling : UCI format, SAN, Novag's format, etc. and for example the first move sent by Scid maybe e2e4 or e4e2 (depending upon user's choice of destination square before start square). So the code I wrote so far is kind of "spaghetti code" that should be cleaned up through interface definition. But the task is certainly not doable in a few hours. > 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? This is the "referee mode" used by Novag, the opposite being "playing mode" (for example in FICS I set the var ::fics::playing). I don't think it is possible to switch between the two mode in a transparent manner. Either the human plays, or he analyses. > 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? > The cases for "playing mode" are limited : - FICS and ::fics::playing == 1 - playing against an engine (training menu) - opening training - etc. The rest is "analysis mode" > 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? > > I fully agree with that. Note that such interface should consider board limitations. For examples I can't send with the Citrine some events like "king lifted". > 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... > See below an example code used to debug Citrine on Windows/WinCE. All options are explained at http://ftp.tcl.tk/man/tcl8.5/TclCmd/open.htm#M22 and I am surprised to see that the DGT is as bad as the Citrine : no flow control at all ! Pascal ======================= package require Tk set device "COM6:" set fd 0 toplevel .w text .w.output -width 20 -height 10 entry .w.input -width 20 button .w.send -text Envoi -command { ::writechan [.w.input get] .w.input delete 0 end } bind .w.input <Return> { .w.send invoke } pack .w.output .w.input .w.send ################## proc init {} { set ::fd [open $::device r+] fconfigure $::fd -mode 57600,n,8,1 -buffering line -blocking 0 fileevent $::fd readable ::readchan } ################### proc writechan {line} { .w.output insert end "->$line\n" puts $::fd $line } ############### proc readchan {} { set line [gets $::fd] .w.output insert end "$line\n" } ################## init wm iconify . ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
