Hi! >> > - when the board sends a move, it should also be sent to FICS, if >> > connected AND playing a game; >> >> Right. I admit that I do not want to recode all interfaces >> to engines and other transports. Probably there's also some >> redesign of the gameplay part necessary? > > A move can be entered into Scid in several ways : > - by internet play (FICS); > - external board; > - mouse; > - keyboard; > - etc.
But one can put one function above all this that works as a general input... My problem here is, I can most likely not do such things. My TCL and my knowledge of scids interal is too limited to dig arround there. > All those inputs are handled by separate procedures > (present in different files). In each of these procedures > it is necessary to send the new board position to a > currently analysing engine. It certainly would be nice to > gather all these in one place. I have started to do it in > Pocket PC code as I wrote it so it is easier for me here. To me it looks as if you are coding scid pocket entirely diffrent then the real thing. Isn't it possible to have it on a common code basis? >> and so on. IMHO that would simplify the drivers >> considerably and ease up the code within scid as it >> unifies the interface and avoids double coding. The >> "board driver" would then just act as a translator >> between the board events and scid. > > I don't have a clear idea right now of the best way of > event flow management. But I would always prefer a pure > Tcl implementation, even for HID handling. That's no problem. A central procedure for handling the events from any kind of input should suffice for that. For external input engine I'd just code a namespace that does the external communication and passes on the commands to this internal handler. Your Citrine code would do the same and pass the commands to that handler as well. At this stage it is IMHO actually of no importance how the HID is handled. > Right now the code to handle Citrine's board is about 150 > lines of Tcl code, which is simple to port and maintain. I can only speak of the dgt, but give that one a factor of 10 for the hardware specific part within dgtnix + the same for dgtdrv to get the logic to just speak about the concept of a move. Most of this is convert 0xSomething from /dev/ttyUSB0 to "move e2e4". (The dgts hardware works on a much lower level than your Citrine seems to work. Sad, but true) > Stdio, sockets or message queues are just the transport > layer, Right. > and just one side of the problem. I implemented > engine/engine tournament on Pocket PC Why again only for CE? > and I did it in pure Tcl code. I don't think dgtdrv should > be of any use here. Actually it could be one of the engines. >> Well the user has to say this at one point. The problem is >> how he sais this. > > The user enters "play mode" or "opening training mode" > explicitely. This is for me how he says if he wants to be > in analysis mode or not. But then I need to know that from some point in scid. The minimum is some accessible flag. Tell me how I can read it and I'll use it. IMHO the better way would be to call some sc_getmode and it is returned, but I've no principle problem with globals. >> !enter setup mode! >> !end setup mode! >> !move now! >> !end game 1-0! >> !end game 0-1! >> !end game 1/2-1/2! >> >> which are all triggered by lifting the king(s) and setting >> it(them) back. I think that you've "some way" on the citrine >> to end a game and issue a move now. You might not have >> "setup mode" as you can't set up a board position. So well, >> you'd just not generate that message in your citrine driver >> then. It's handled by the backend, so if it arrives, well >> it's handled. But if it never arrives, well... > > With the Citrine I can issue a "move now" but not a "end a > game". This board has great limitations and a very poor > interface. Ok, well then, you just don't throw that message and that's it. What is not issued is just not handled and there's always the scid's way to do it. I never said that you have to be able to send all messages I specified ;) I just defined a set of possible message, imagining of course that the DGT might well define one of the largest sets possible. >> > and I am surprised to see that the DGT is as bad as the Citrine : no >> > flow control at all ! >> >> We wondered as well and actually this seems ot pose a >> problem with the Mac. Current status is that we can compile >> everything on OS X, the lib is there, dgtdrv2 compiles but >> it hangs upon initialisation. So if some skilled OS X >> developer is listening owning either board and know how to >> get them to work... > > There are two things that may help here : > - use a software to sniff serial port of Mac; I do not have one ;) > - don't you have a CTS/RTS problem ? At least not on the PC. Could be on the Mac, but as I do not have one... > As DGT board has no flow control, hence will not send a > CTS when asked a RTS, the solution is to wire pins 7 and 8 > on a DB9 socket. I'll pass that on to dgtnix probably it is a solution. -- Kind regards, Alexander Wagner Universitaetsbibliothek Ilmenau Langewiesener Str. 37 98693 Ilmenau Tel.: 03677/69-4521 , Fax.: 03677/69-4617 ------------------------------------------------------------------------- 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
