pgeorges schrieb:
Good morning!
>> 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 ...
Ah! Ok, maybe I should have mentioned that e.g. the dgt
doesn't use any flow control either. Seems the same with
you.
>> 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).
Thanks for the pointer!
>> 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;
Small corrections: some boards do not even send "moves" ;)
> - 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?
> - when the board has a starting position this should trigger a "sc_game
> new"
Actually I'd say the driver can trigger that.
IMHO(!) what we need is some "command interface" where I can
send the events from the HID to that are then piped intot
the usual scids event processing. I think of it like
/----- FICS
/------ Board Hardware
scid /------- Keyboard
\------- Mouse
\------ ...
Then I could write a driver in the way:
sub ScidEventHandler($scidevent)
{
if ($event =~ m/^move/) {
SendToDriver($event);
}
}
sub DriverEventHandler()
{
$event = ReceiveBoardEvent();
if ($event == $newgame) {
sc_event $newgame;
}
elsif ($event == $setupmode) {
$FEN = ReadPosition()
sc_event $setposition $fen
}
}
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 have a general problem with moves handling : UCI format,
> SAN, Novag's format, etc.
... DGTs binary expression (no you do _not_ get e2e4 from
the dgt ;)
> and for example the first move sent by Scid maybe e2e4 or
> e4e2 (depending upon user's choice of destination square before start
> square).
Ahm well this at least has to be unfied.
> 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.
Right. BTW: input engine tries exactly this unification of
interface. It's its main purpose... So probably we could
reuse its messages for the internal scid message bus? I see
that you object using stdio for the board driver due to CE.
Well I do not stick to stdio communication as a religious
lemma. Still I'd suggest to consider it as it might give
drivers that are useable by other programs as well so the
value for the programmers and users is much larger than
implementing a single piece of code for a single app.
E.g. if scid allows for playing an engine match (analysis
engine 1 against engine 2) I could even hook up dgtdrv into
this. The xboard code to add position recognigion etc. was
about 50 lines.
>> 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.
Well the user has to say this at one point. The problem is
how he sais this.
>> 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.
IMHO the backend should take a move and decide what to do
with it. Its no good if I check all this within the hardware
driver and then decide what the move does and where it is
sent to. E.g. you add a new protocol for whatever and you'd
have to touch all drivers? Doesn't sound a convenient
approach.
> The rest is "analysis mode"
Agree that this is probably the main mode in scid.
>> 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".
Right. You'd even not break down the communication to that
limit. If you've a look at the input engine protocol (I just
take this as an example as I invested some minutes to think
about it, and it's still RFC) you'll not get "king lifted"
but you might get events like
!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...
>> 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
I'll check that. But your sample looks pretty similar what I
tried myself without success yet. Though I admit that
porting dgtnix to tcl is not my main concern right now.
> 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...
--
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
