On Sat, 2010-11-06 at 15:37 +0100, Joost 't Hart wrote: > 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... >
There's almost certainly a better way to do it in Windows. It might be possible to get it working with my code but I suspect it'd be less effort to start from scratch than to try to coax libhid into working on Windows. > 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. The driver doesn't know. The problem is that the board doesn't know. Basically it's just 64 switches and it tells you whenever one is pressed. > 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"... It can and does, or indeed any combination of two squares. It seemed to me to be better to have SCID deal with all the validation, as that is the ultimate arbiter anyway. Plus, as the driver has no knowledge of the board state SCID would be doing most of the work anyway, just at one remove. > 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. :-) Castling is a king move, and move the rook very gently, en passant is just the move of the pawn doing the capturing. > 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... Quite true. I did put together a little program that will send moves directly to whatever program has the focus, http://www.wtfai.me.uk/wtfai/files/monitorcheeky.c, so if SCID has the focus then you can use an unmodified SCID, which for me is probably the best option. I've tried using it again to enter games, and it does work OKish despite its obvious limitations but I'd still rather use a mouse. If anyone really wants to use it and can't program themselves then I'm willing to try to fix any problems that arise, but for me the fundamental problem is the hardware is too over-simplified, and that can't be fixed. Ben Hague ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
