Re: [Scid-users] Dream Cheeky USB chess board

[Joost 't H. <joo...@pl...>]

On 11/06/2010 02:13 AM, Jerry K wrote:

Hi,

You may want to catch up with Ben directly...

But what I learned from the source code:

This driver cannot be compiled for windows out of the box, because it 
uses the high level hid usb api that was developed for MacOS and 
(adopted by Linux). As far as I know, this api is not available on Windows.

Which does not mean that the code cannot be ported to Windows...

I do not know anything of the board, but what this driver does is 
straightforward.

It installs two processes:

The first process (the /read_socket/ function) listens to Scid, and 
waits for an "f" command to appear. This command signals that Scid 
wants/expects board orientation flipped. The orientation is stored in 
/upright/ which sits in shared memory between the two processes.
It occurs to me that in a first instance of the driver we could do 
without this process. Unfortunately this is not where the portability 
problems are. It looks very much like the input command interface of a 
chess engine.

The second process (from line 165 onwards) reads stuff from the board's 
hid interface, interprets it, and forwards its conclusion to Scid 
(again, like an engine returns its evaluation).
The stuff it reads is two consecutive strings of 64 bits. Each bit 
corresponds to a square on the board. If a bit is set <something> has 
changed on that square. One string corresponds to the source of a move, 
the other corresponds to the destination.
The bit-to-square translation has the /upright/ orientation status as a 
parameter.

All in all, a string like "g1f3<enter>" (or "b8c6<enter>", depending on 
the orientation) is sent to Scid.

I have some questions on the code:
1) I cannot see how the driver knows which string corresponds to source 
and which one to destination. There must be a risk that board and driver 
run out of sync.
2) I do not know what triggers Scid to send the flip command, but the 
driver is not robust against such commands appearing at random moments 
in time. The /upright/ flag should be protected in between source and 
destination decoding. If not, the driver may send something like "g1c6"...
3) The driver scans all bits in the string. That is, it continues after 
it has met a bit set. This might only be target for optimization, but on 
the other hand I am not sure how the board signals moves like castling 
and en-passant capturing. Given what the board sends us, I would not be 
surprised if these moves are not understood by the system (board and/or 
driver). In the best case I would expect something like "h1g1<enter>" 
after white's short castling on the board - if he makes the move really 
fast. :-)
4) The board does not transfer any information on (chess) pieces. This 
implies that promoting a pawn cannot produce anything more than 
"g7g8<enter>" and needs some additional manual inferference on Scid's end.

All in all, I expect there's still a bit of work to do...

Cheers,
Joost.

> Have followed a recent posting that Ben Hague kindly gave and downloaded the
> source code from
> http://wtfai.me.uk/wtfai/files/cheekychessmonitor-0.1.tar.bz2
>
> Am not a coder!
>
> I have a laptop running windows xp. Am desperate to get my dream cheeky usb
> board to work with scid. (Indeed I only discovered scid because of the Google
> search I made because I hoped someone had done something with this potentially
> great-value-for-money bit of kit. ( I think its the software that Dream Cheeky
> provided that is horrible)
>
> New to newsgroups.
>
> My best understanding of the README file of the source code package is that the
> instructions to compile are for Unix type systems.
>
> Can anyone give help me compile for xp?
>
> thnx
>
> Jerry
>
>