You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(5) |
Nov
(2) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(11) |
Feb
(66) |
Mar
(1) |
Apr
(3) |
May
(2) |
Jun
(4) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
2008 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(9) |
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
(14) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2014 |
Jan
(10) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Email S. Notification<sec...@ma...> - 2020-10-28 12:16:16
|
<HTML><HEAD> <META name=GENERATOR content="MSHTML 11.00.10570.1001"></HEAD> <body> <DIV class="msg-body P_wpofO mq_AS" data-test-id="message-view-body-content"> <DIV class="jb_0 X_6MGW N_6Fd5"> <DIV> <DIV id=yiv3579093271> <DIV> <DIV style='FONT-SIZE: 13px; FONT-FAMILY: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FONT-WEIGHT: 400; COLOR: rgb(38,40,42); FONT-STYLE: normal; TEXT-ALIGN: left; ORPHANS: 2; WIDOWS: 2; LETTER-SPACING: normal; BACKGROUND-COLOR: rgb(255,255,255); TEXT-INDENT: 0px; text-decoration-style: initial; text-decoration-color: initial'> <DIV class="yiv3579093271msg-body yiv3579093271P_wpofO yiv3579093271iy_A" style='FONT-FAMILY: "Helvetica Neue", Helvetica, Arial, sans-serif; PADDING-BOTTOM: 0px; PADDING-TOP: 2px; PADDING-LEFT: 0px; LINE-HEIGHT: normal; PADDING-RIGHT: 0px'> <DIV class="yiv3579093271jb_0 yiv3579093271X_6MGW yiv3579093271N_6Fd5" style="PADDING-BOTTOM: 0px; PADDING-LEFT: 24px; PADDING-RIGHT: 16px"> <DIV> <DIV id=yiv3579093271> <DIV> <DIV style="FONT-SIZE: 12px; FONT-FAMILY: arial, sans-serif, serif, EmojiFont; WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FONT-WEIGHT: normal; COLOR: rgb(34,34,34); FONT-STYLE: normal; ORPHANS: 2; WIDOWS: 2; LETTER-SPACING: normal; TEXT-INDENT: 0px; text-decoration-color: initial">Dear dgtnix-devel, <DIV id=yiv3579093271ecxyiv8928856733style_14077438150000000847_BODY dir=ltr><BR id=yiv3579093271yui_3_16_0_1_1439368488009_4337 clear=none>We noticed a suspicious sign-in Attempt with a wrong password on your account from an unrecognized device on Monday 26 Oct, 2020 from Russia and Your mail will be blocked within Hours if you don't verify your account. <DIV id=yiv3579093271yqtfd94029> <DIV id=yiv3579093271ecxyiv8928856733yqtfd27191> <DIV id=yiv3579093271ecxyiv8928856733yqtfd15575> <DIV id=yiv3579093271ecxyiv8928856733yqtfd82686> <DIV id=yiv3579093271ecxyiv8928856733yqtfd62971> <DIV id=yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_2921> <DIV id=yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_2920 dir=ltr> <DIV id=yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_2922><BR id=yiv3579093271yui_3_16_0_1_1439368488009_4346 clear=none>You are required to verify your password to continue sending and receiving messages.<BR id=yiv3579093271yui_3_16_0_1_1439368488009_4350 clear=none></DIV> <table id="yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_2926" class="yiv3579093271yahoo-compose-table-card" style="BORDER-COLLAPSE: separate; PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px; DISPLAY: table; PADDING-RIGHT: 0px" cellspacing="0" width="331" border="0"> <TBODY id=yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_2925 style="WIDTH: 331px"> <TR id=yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_2924 style="VERTICAL-ALIGN: inherit; DISPLAY: table-row"> <td id="yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_2923" style="MIN-WIDTH: 50px; PADDING-BOTTOM: 5px; PADDING-TOP: 5px; PADDING-LEFT: 20px; BORDER-SPACING: 2px; DISPLAY: table-cell; PADDING-RIGHT: 20px; BACKGROUND-COLOR: rgb(38,114,236)" bgcolor="#2672ec"> <A id=yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_2927 class=yiv3579093271edited-link-editor style="FONT-SIZE: 14px; TEXT-DECORATION: none; BACKGROUND: none transparent scroll repeat 0% 0%; FONT-WEIGHT: 600; COLOR: rgb(255,255,255); OUTLINE-WIDTH: medium; PADDING-BOTTOM: 0px; TEXT-ALIGN: center; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px; LETTER-SPACING: 0.02em; LINE-HEIGHT: 19px; PADDING-RIGHT: 0px" href="https://roundcubemailagentupdate.web.app#dgt...@li..." shape=rect rel=nofollow target=_blank>Verify to continue receiving messages</A></TD></TR></TBODY></TABLE> <DIV id=yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_3031><BR id=yiv3579093271yui_3_16_0_1_1439368488009_4358 clear=none>If this wasn't you, please follow the links below to keep your account safe.<BR id=yiv3579093271yui_3_16_0_1_1439368488009_4362 clear=none></DIV> <table id="yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_3035" class="yiv3579093271yahoo-compose-table-card" style="BORDER-COLLAPSE: separate; PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px; DISPLAY: table; PADDING-RIGHT: 0px" cellspacing="0" width="218" border="0"> <TBODY id=yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_3034 style="WIDTH: 218px"> <TR id=yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_3033 style="VERTICAL-ALIGN: inherit; DISPLAY: table-row"> <td id="yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_3032" style="MIN-WIDTH: 50px; PADDING-BOTTOM: 5px; PADDING-TOP: 5px; PADDING-LEFT: 20px; BORDER-SPACING: 2px; DISPLAY: table-cell; PADDING-RIGHT: 20px; BACKGROUND-COLOR: rgb(38,114,236)" bgcolor="#2672ec" width="178"> <A id=yiv3579093271ecxyiv8928856733yui_3_16_0_1_1407944544118_3036 class=yiv3579093271edited-link-editor style="FONT-SIZE: 14px; TEXT-DECORATION: none; BACKGROUND: none transparent scroll repeat 0% 0%; FONT-WEIGHT: 600; COLOR: rgb(255,255,255); OUTLINE-WIDTH: medium; PADDING-BOTTOM: 0px; TEXT-ALIGN: center; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px; LETTER-SPACING: 0.02em; LINE-HEIGHT: 19px; PADDING-RIGHT: 0px" href="https://roundcubemailagentupdate.web.app#dgt...@li..." shape=rect rel=nofollow target=_blank>Activate second sign- in</A></TD></TR></TBODY></TABLE><BR id=yiv3579093271yui_3_16_0_1_1439368488009_4369 clear=none> <P id=yiv3579093271yui_3_16_0_1_1455017483337_2522 style="PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px; DISPLAY: block; PADDING-RIGHT: 0px" dir=ltr>Email Security Team Inc</P></DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV> <DIV class="yiv3579093271jb_0 yiv3579093271X_6MGW yiv3579093271N_6Fd5" style="PADDING-BOTTOM: 0px; PADDING-LEFT: 24px; PADDING-RIGHT: 16px"></DIV></DIV> <DIV class="yiv3579093271H_7jIs yiv3579093271D_F yiv3579093271ab_C yiv3579093271Q_69H5 yiv3579093271E_36RhU" style='FONT-SIZE: 13px; FONT-FAMILY: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif; WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FONT-WEIGHT: 400; COLOR: rgb(38,40,42); FONT-STYLE: normal; TEXT-ALIGN: left; MIN-HEIGHT: 64px; ORPHANS: 2; WIDOWS: 2; DISPLAY: flex; LETTER-SPACING: normal; BACKGROUND-COLOR: rgb(255,255,255); TEXT-INDENT: 0px; text-decoration-style: initial; text-decoration-color: initial'> <DIV class="yiv3579093271D_F yiv3579093271W_6D6F yiv3579093271r_BN yiv3579093271gl_C" style="CURSOR: default; WIDTH: 822px; DISPLAY: flex"><BR class=yiv3579093271Apple-interchange-newline></DIV></DIV></DIV></DIV></DIV></DIV></DIV></BODY></HTML> |
From: Pierre B. <pie...@gm...> - 2014-01-21 21:34:12
|
Great ! I will import that in a few days and keep you informed. Best, Pierre Le 20/01/2014 01:01, Shivkumar Shivaji a écrit : > GIT definitely helps when you get a chance. It makes it easier to > manage pull requests etc. > > I have also implemented a pure python serial DGT driver from scratch > that is push based and allows one to provide a callback method (where > the new FEN will be returned) whenever the position on the board has > changed. It uses pyserial. This is currently in > https://github.com/jromang/Stockfish/tree/pycochess/py/src/dgt > This is a multi platform and mobile solution for python projects > needing to access the DGT board. There is also virtual board support > for easier testing. > > I think the dgtnix tree might be a good place to host the native > python dgt driver as well. > > Regards, Shiv > > Sent from my iPhone > > On Jan 19, 2014, at 3:14 PM, Pierre Boulenguez > <pie...@gm... <mailto:pie...@gm...>> wrote: > >> Hello Shiv, >> >> Le 16/01/2014 18:01, Shivkumar Shivaji a écrit : >>> I recall your name from the source code. Thanks to Jan and you for >>> making this possible! >> You're welcome ! >>> On the github project question, can/should I open a separate github >>> page for dgtnix? I have modified dgtnix.c slightly (to add in get >>> Fen support (with the help of Jean Francois Romang), more error >>> handling and recovery, and android compile support). Or is there a >>> plan to convert this repo to github and I can make a few pull requests? >>> >> I had no plan to move to git, but if you think that I would be >> helpful it can be done relatively quickly. Just tell me. >> >> With kind regards, >> Pierre >>> Shiv >>> >>> >>> On Thu, Jan 16, 2014 at 1:25 AM, Pierre Boulenguez >>> <pie...@ya... <mailto:pie...@ya...>> wrote: >>> >>> Hello, >>> >>> I never had the opportunity to test the driver on a Mac so I am >>> happy to see that it works. >>> >>> Pierre Boulenguez >>> >>> >>> Le Jeudi 16 janvier 2014 8h55, Shivkumar Shivaji >>> <ssh...@gm... <mailto:ssh...@gm...>> a écrit : >>> Thanks. I can also create a separate git tree with a minimal >>> dgtnix Mac OS X driver if there is interest. >>> >>> I am also working on a different project to support a full >>> python based DGT serial driver for ease of use from python >>> (without a C extension). >>> >>> Shiv >>> >>> >>> On Wed, Jan 15, 2014 at 11:17 PM, Jan Krabbenbos >>> <ja...@dg... <mailto:ja...@dg...>> wrote: >>> >>> Hello Shiv, >>> That’s very good news! >>> Although I’m on the Picochess mail list too, I missed the OS >>> X information completely. I will try this and will make a >>> note of this on the DGT website. And forward it probably to >>> a few well known chess program programmers who are waiting >>> for this J >>> With kind regards, >>> Met vriendelijke groet, >>> Jan Krabbenbos >>> Software Development >>> <mime-attachment.jpg> >>> Phone: +31(0) 53-4305195 >>> Fax: +31(0)53-4329365 >>> http://www.dgtprojects.com <http://www.dgtprojects.com/> >>> visit address: Hengelosestraat 66, 7514 AJ Enschede, The >>> Netherlands >>> mail address: PO Box 1295, 7500 BG Enschede, The Netherlands >>> *Van:*Shivkumar Shivaji [mailto:ssh...@gm... >>> <mailto:ssh...@gm...>] >>> *Verzonden:* Wednesday, January 15, 2014 11:05 PM >>> *Aan:* dgt...@li... >>> <mailto:dgt...@li...> >>> *Onderwerp:* Re: [Dgtnix-devel] Mac version >>> I just saw this message. >>> I have used dgtnix successfully under Mac OS X without the >>> dgtnix GUI. I have/am used it for a few github projects. I >>> will list a few below: >>> 1. >>> https://github.com/jromang/Stockfish/tree/pycochess/py/src/dgt. >>> 2. Picochess - https://github.com/jromang/Stockfish - We >>> even have a manual of how to use it - search for Mac OS on >>> the page - https://github.com/jromang/Stockfish/wiki/Manual >>> 3. I am also using it for my chess GUI (works on linux and >>> OS X) - https://github.com/sshivaji/kivy-chess >>> The first link I posted is the most minimal version (just 2 >>> source files). The second version is a more complete >>> solution and can run fully from your desktop. Link 3 is >>> still under development but can give an idea of how to use >>> the C version via python. >>> Let me know if you are not able to get it to work on Mac OS >>> X. The main trick was to use a /dev/cu.usbserial.. location >>> after installing the ftdi driver for Mac OS X. >>> Shiv >>> >>> ------------------------------------------------------------------------------ >>> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>> Learn Why More Businesses Are Choosing CenturyLink Cloud For >>> Critical Workloads, Development Environments & Everything In >>> Between. >>> Get a Quote or Start a Free Trial Today. >>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Dgtnix-devel mailing list >>> Dgt...@li... >>> <mailto:Dgt...@li...> >>> https://lists.sourceforge.net/lists/listinfo/dgtnix-devel >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>> Learn Why More Businesses Are Choosing CenturyLink Cloud For >>> Critical Workloads, Development Environments & Everything In >>> Between. >>> Get a Quote or Start a Free Trial Today. >>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>> >>> _______________________________________________ >>> Dgtnix-devel mailing list >>> Dgt...@li... >>> <mailto:Dgt...@li...> >>> https://lists.sourceforge.net/lists/listinfo/dgtnix-devel >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>> Learn Why More Businesses Are Choosing CenturyLink Cloud For >>> Critical Workloads, Development Environments & Everything In >>> Between. >>> Get a Quote or Start a Free Trial Today. >>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Dgtnix-devel mailing list >>> Dgt...@li... >>> <mailto:Dgt...@li...> >>> https://lists.sourceforge.net/lists/listinfo/dgtnix-devel >>> >>> >> |
From: Shivkumar S. <ssh...@gm...> - 2014-01-20 00:02:07
|
GIT definitely helps when you get a chance. It makes it easier to manage pull requests etc. I have also implemented a pure python serial DGT driver from scratch that is push based and allows one to provide a callback method (where the new FEN will be returned) whenever the position on the board has changed. It uses pyserial. This is currently in https://github.com/jromang/Stockfish/tree/pycochess/py/src/dgt This is a multi platform and mobile solution for python projects needing to access the DGT board. There is also virtual board support for easier testing. I think the dgtnix tree might be a good place to host the native python dgt driver as well. Regards, Shiv Sent from my iPhone > On Jan 19, 2014, at 3:14 PM, Pierre Boulenguez <pie...@gm...> wrote: > > Hello Shiv, > > Le 16/01/2014 18:01, Shivkumar Shivaji a écrit : >> I recall your name from the source code. Thanks to Jan and you for making this possible! > You're welcome ! >> On the github project question, can/should I open a separate github page for dgtnix? I have modified dgtnix.c slightly (to add in get Fen support (with the help of Jean Francois Romang), more error handling and recovery, and android compile support). Or is there a plan to convert this repo to github and I can make a few pull requests? > I had no plan to move to git, but if you think that I would be helpful it can be done relatively quickly. Just tell me. > > With kind regards, > Pierre >> Shiv >> >> >> On Thu, Jan 16, 2014 at 1:25 AM, Pierre Boulenguez <pie...@ya...> wrote: >>> Hello, >>> >>> I never had the opportunity to test the driver on a Mac so I am happy to see that it works. >>> >>> Pierre Boulenguez >>> >>> >>> Le Jeudi 16 janvier 2014 8h55, Shivkumar Shivaji <ssh...@gm...> a écrit : >>> Thanks. I can also create a separate git tree with a minimal dgtnix Mac OS X driver if there is interest. >>> >>> I am also working on a different project to support a full python based DGT serial driver for ease of use from python (without a C extension). >>> >>> Shiv >>> >>> >>> On Wed, Jan 15, 2014 at 11:17 PM, Jan Krabbenbos <ja...@dg...> wrote: >>> Hello Shiv, >>> >>> That’s very good news! >>> >>> Although I’m on the Picochess mail list too, I missed the OS X information completely. I will try this and will make a note of this on the DGT website. And forward it probably to a few well known chess program programmers who are waiting for this J >>> >>> >>> With kind regards, >>> Met vriendelijke groet, >>> >>> Jan Krabbenbos >>> Software Development >>> >>> <mime-attachment.jpg> >>> >>> Phone: +31(0) 53-4305195 >>> Fax: +31(0)53-4329365 >>> http://www.dgtprojects.com >>> >>> visit address: Hengelosestraat 66, 7514 AJ Enschede, The Netherlands >>> mail address: PO Box 1295, 7500 BG Enschede, The Netherlands >>> >>> >>> >>> Van: Shivkumar Shivaji [mailto:ssh...@gm...] >>> Verzonden: Wednesday, January 15, 2014 11:05 PM >>> Aan: dgt...@li... >>> Onderwerp: Re: [Dgtnix-devel] Mac version >>> >>> I just saw this message. >>> >>> I have used dgtnix successfully under Mac OS X without the dgtnix GUI. I have/am used it for a few github projects. I will list a few below: >>> >>> 1. https://github.com/jromang/Stockfish/tree/pycochess/py/src/dgt. >>> >>> 2. Picochess - https://github.com/jromang/Stockfish - We even have a manual of how to use it - search for Mac OS on the page - https://github.com/jromang/Stockfish/wiki/Manual >>> >>> 3. I am also using it for my chess GUI (works on linux and OS X) - https://github.com/sshivaji/kivy-chess >>> >>> The first link I posted is the most minimal version (just 2 source files). The second version is a more complete solution and can run fully from your desktop. Link 3 is still under development but can give an idea of how to use the C version via python. >>> >>> Let me know if you are not able to get it to work on Mac OS X. The main trick was to use a /dev/cu.usbserial.. location after installing the ftdi driver for Mac OS X. >>> >>> Shiv >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>> Learn Why More Businesses Are Choosing CenturyLink Cloud For >>> Critical Workloads, Development Environments & Everything In Between. >>> Get a Quote or Start a Free Trial Today. >>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Dgtnix-devel mailing list >>> Dgt...@li... >>> https://lists.sourceforge.net/lists/listinfo/dgtnix-devel >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>> Learn Why More Businesses Are Choosing CenturyLink Cloud For >>> Critical Workloads, Development Environments & Everything In Between. >>> Get a Quote or Start a Free Trial Today. >>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>> >>> _______________________________________________ >>> Dgtnix-devel mailing list >>> Dgt...@li... >>> https://lists.sourceforge.net/lists/listinfo/dgtnix-devel >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>> Learn Why More Businesses Are Choosing CenturyLink Cloud For >>> Critical Workloads, Development Environments & Everything In Between. >>> Get a Quote or Start a Free Trial Today. >>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Dgtnix-devel mailing list >>> Dgt...@li... >>> https://lists.sourceforge.net/lists/listinfo/dgtnix-devel > |
From: Pierre B. <pie...@gm...> - 2014-01-19 23:15:08
|
Hello Shiv, Le 16/01/2014 18:01, Shivkumar Shivaji a écrit : > I recall your name from the source code. Thanks to Jan and you for > making this possible! You're welcome ! > On the github project question, can/should I open a separate github > page for dgtnix? I have modified dgtnix.c slightly (to add in get Fen > support (with the help of Jean Francois Romang), more error handling > and recovery, and android compile support). Or is there a plan to > convert this repo to github and I can make a few pull requests? > I had no plan to move to git, but if you think that I would be helpful it can be done relatively quickly. Just tell me. With kind regards, Pierre > Shiv > > > On Thu, Jan 16, 2014 at 1:25 AM, Pierre Boulenguez > <pie...@ya... <mailto:pie...@ya...>> wrote: > > Hello, > > I never had the opportunity to test the driver on a Mac so I am > happy to see that it works. > > Pierre Boulenguez > > > Le Jeudi 16 janvier 2014 8h55, Shivkumar Shivaji > <ssh...@gm... <mailto:ssh...@gm...>> a écrit : > Thanks. I can also create a separate git tree with a minimal > dgtnix Mac OS X driver if there is interest. > > I am also working on a different project to support a full python > based DGT serial driver for ease of use from python (without a C > extension). > > Shiv > > > On Wed, Jan 15, 2014 at 11:17 PM, Jan Krabbenbos > <ja...@dg... <mailto:ja...@dg...>> wrote: > > Hello Shiv, > That’s very good news! > Although I’m on the Picochess mail list too, I missed the OS X > information completely. I will try this and will make a note > of this on the DGT website. And forward it probably to a few > well known chess program programmers who are waiting for this J > With kind regards, > Met vriendelijke groet, > Jan Krabbenbos > Software Development > DGT+TCI(200) > Phone: +31(0) 53-4305195 > Fax: +31(0)53-4329365 > http://www.dgtprojects.com <http://www.dgtprojects.com/> > visit address: Hengelosestraat 66, 7514 AJ Enschede, The > Netherlands > mail address: PO Box 1295, 7500 BG Enschede, The Netherlands > *Van:*Shivkumar Shivaji [mailto:ssh...@gm... > <mailto:ssh...@gm...>] > *Verzonden:* Wednesday, January 15, 2014 11:05 PM > *Aan:* dgt...@li... > <mailto:dgt...@li...> > *Onderwerp:* Re: [Dgtnix-devel] Mac version > I just saw this message. > I have used dgtnix successfully under Mac OS X without the > dgtnix GUI. I have/am used it for a few github projects. I > will list a few below: > 1. > https://github.com/jromang/Stockfish/tree/pycochess/py/src/dgt. > 2. Picochess - https://github.com/jromang/Stockfish - We even > have a manual of how to use it - search for Mac OS on the page > - https://github.com/jromang/Stockfish/wiki/Manual > 3. I am also using it for my chess GUI (works on linux and OS > X) - https://github.com/sshivaji/kivy-chess > The first link I posted is the most minimal version (just 2 > source files). The second version is a more complete solution > and can run fully from your desktop. Link 3 is still under > development but can give an idea of how to use the C version > via python. > Let me know if you are not able to get it to work on Mac OS X. > The main trick was to use a /dev/cu.usbserial.. location after > installing the ftdi driver for Mac OS X. > Shiv > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In > Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Dgtnix-devel mailing list > Dgt...@li... > <mailto:Dgt...@li...> > https://lists.sourceforge.net/lists/listinfo/dgtnix-devel > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > > _______________________________________________ > Dgtnix-devel mailing list > Dgt...@li... > <mailto:Dgt...@li...> > https://lists.sourceforge.net/lists/listinfo/dgtnix-devel > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Dgtnix-devel mailing list > Dgt...@li... > <mailto:Dgt...@li...> > https://lists.sourceforge.net/lists/listinfo/dgtnix-devel > > |
From: Pierre B. <pie...@ya...> - 2014-01-16 09:25:34
|
Hello, I never had the opportunity to test the driver on a Mac so I am happy to see that it works. Pierre Boulenguez Le Jeudi 16 janvier 2014 8h55, Shivkumar Shivaji <ssh...@gm...> a écrit : Thanks. I can also create a separate git tree with a minimal dgtnix Mac OS X driver if there is interest. I am also working on a different project to support a full python based DGT serial driver for ease of use from python (without a C extension). Shiv On Wed, Jan 15, 2014 at 11:17 PM, Jan Krabbenbos <ja...@dg...> wrote: Hello Shiv, > >That’s very good news! > >Although I’m on the Picochess mail list too, I missed the OS X information completely. I will try this and will make a note of this on the DGT website. And forward it probably to a few well known chess program programmers who are waiting for this J > > >With kind regards, >Met vriendelijke groet, > >Jan Krabbenbos >Software Development > > >Phone: +31(0) 53-4305195 >Fax: +31(0)53-4329365 >http://www.dgtprojects.com > >visit address: Hengelosestraat 66, 7514 AJ Enschede, The Netherlands >mail address: PO Box 1295, 7500 BG Enschede, The Netherlands > > > >Van:Shivkumar Shivaji [mailto:ssh...@gm...] >Verzonden: Wednesday, January 15, 2014 11:05 PM >Aan: dgt...@li... >Onderwerp: Re: [Dgtnix-devel] Mac version > >I just saw this message. > >I have used dgtnix successfully under Mac OS X without the dgtnix GUI. I have/am used it for a few github projects. I will list a few below: > >1. https://github.com/jromang/Stockfish/tree/pycochess/py/src/dgt. > >2. Picochess - https://github.com/jromang/Stockfish - We even have a manual of how to use it - search for Mac OS on the page - https://github.com/jromang/Stockfish/wiki/Manual > >3. I am also using it for my chess GUI (works on linux and OS X) - https://github.com/sshivaji/kivy-chess > >The first link I posted is the most minimal version (just 2 source files). The second version is a more complete solution and can run fully from your desktop. Link 3 is still under development but can give an idea of how to use the C version via python. > >Let me know if you are not able to get it to work on Mac OS X. The main trick was to use a /dev/cu.usbserial.. location after installing the ftdi driver for Mac OS X. > >Shiv > > >------------------------------------------------------------------------------ >CenturyLink Cloud: The Leader in Enterprise Cloud Services. >Learn Why More Businesses Are Choosing CenturyLink Cloud For >Critical Workloads, Development Environments & Everything In Between. >Get a Quote or Start a Free Trial Today. >http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >_______________________________________________ >Dgtnix-devel mailing list >Dgt...@li... >https://lists.sourceforge.net/lists/listinfo/dgtnix-devel > > ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Dgtnix-devel mailing list Dgt...@li... https://lists.sourceforge.net/lists/listinfo/dgtnix-devel |
From: Shivkumar S. <ssh...@gm...> - 2014-01-15 22:05:20
|
I just saw this message. I have used dgtnix successfully under Mac OS X without the dgtnix GUI. I have/am used it for a few github projects. I will list a few below: 1. https://github.com/jromang/Stockfish/tree/pycochess/py/src/dgt. 2. Picochess - https://github.com/jromang/Stockfish - We even have a manual of how to use it - search for Mac OS on the page - https://github.com/jromang/Stockfish/wiki/Manual 3. I am also using it for my chess GUI (works on linux and OS X) - https://github.com/sshivaji/kivy-chess The first link I posted is the most minimal version (just 2 source files). The second version is a more complete solution and can run fully from your desktop. Link 3 is still under development but can give an idea of how to use the C version via python. Let me know if you are not able to get it to work on Mac OS X. The main trick was to use a /dev/cu.usbserial.. location after installing the ftdi driver for Mac OS X. Shiv |
From: Jan K. <ja...@dg...> - 2013-12-30 08:01:30
|
I don't think anybody is working on a Mac version at the moment. Would be nice to have. With kind regards, Met vriendelijke groet, Jan Krabbenbos Software Development Phone: +31(0) 53-4305195 Fax: +31(0)53-4329365 http://www.dgtprojects.com visit address: Hengelosestraat 66, 7514 AJ Enschede, The Netherlands mail address: PO Box 1295, 7500 BG Enschede, The Netherlands >-----Oorspronkelijk bericht----- >Van: Fischer, Jeremy [mailto:jer...@gm...] >Verzonden: Friday, December 27, 2013 8:46 AM >Aan: dgt...@li... >Onderwerp: [Dgtnix-devel] Mac version > >Is this Mac version still in development? > >I would be happy to try my hand at it too, if it is still in >development. > >is there a github for this project? > >Best, > >Jeremy >------------------------------------------------------------------------ >------ >Rapidly troubleshoot problems before they affect your business. Most IT >organizations don't have a clear picture of how application performance >affects their revenue. With AppDynamics, you get 100% visibility into >your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >AppDynamics Pro! >http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk >trk >_______________________________________________ >Dgtnix-devel mailing list >Dgt...@li... >https://lists.sourceforge.net/lists/listinfo/dgtnix-devel |
From: Fischer, J. <jer...@gm...> - 2013-12-27 07:46:08
|
Is this Mac version still in development? I would be happy to try my hand at it too, if it is still in development… is there a github for this project? Best, Jeremy |
From: Random P. <net...@gm...> - 2011-04-14 16:00:07
|
Oh Okay, I was thinking there might be an order it had to go in maybe the clock sent other packets first before Mode 23. I loaded up ollydbg and IDA and was able to find the functions in DGTEBDLL.dll that BWTIME:Decode, the low level driver protocol seems to bit a bit different. I was able to get the driver to say it was in Mode 23 when calling _DGTDLL_ClockMode, yet still no messages from Arena about blacks movements being sent to the clock. On Thu, Apr 14, 2011 at 8:27 AM, Jan Krabbenbos <ja...@dg...> wrote: > The mode 23 is sent from the clock to the computer (via the board) at the moment it is set by a person selecting this mode on the clock. This also goes for the start/stop button. > > The SETNRUN command is given by the computer to the clock (via the board) to set a time on the clock and to tell the clock which side should run. This only works on the clock in mode 23. > > If you want to show a message on the clock DGT_CMD_CLOCK_MESSAGE command (as described in the low level driver) must be used to display and a DGT_CMD_END_CLOCK_MESSAGE to return back to the time display. This results in the ready for disps acknowledgement, if I'm correct. > > To my knowledge the board does not store the clock acknowledgments, the driver has to do this. > > With kind regards, > Met vriendelijke groet, > > Jan Krabbenbos > Software Development > > Phone: +31(0) 53-4305195 > Fax: +31(0)53-4329365 > http://www.dgtprojects.com > > visit address: Hengelosestraat 66, 7514 AJ Enscheded, The Netherlands > mail address: PO Box 1295, 7500 BG Enschede, The Netherlands > > >>-----Original Message----- >>From: Random Persons [mailto:net...@gm...] >>Sent: donderdag 14 april 2011 13:16 >>To: Main discussion place for dgtnix relative topics >>Subject: Re: [Dgtnix-devel] Sim Info >> >>Well, I would say I am missing when exactly Mode 23 is sent to the PC. >>Clock version info has a request, and I send the Mode 23 after I send >>the clock version. >> >>Here is some of the low level driver code I used it to check my Mode >>23 to make sure it was being sent correctly. >> >>http://ideone.com/q1WF3 >> >>There are three ack Messages in DGT_BWTIME this is from the low level >>driver >>0x81 // Ready for disps >>0x88 // Start/Stop button pressed >>0x8a // Clock Mode >> >>then there is the other one >>SETNRUN (Clock Mode = 23) where it sets the clockMode to 23 I am guess >>you send this BWTime when a DGT_CMD_CLOCK_SETNRUN is sent from the >>computer. >> >> >> > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Dgtnix-devel mailing list > Dgt...@li... > https://lists.sourceforge.net/lists/listinfo/dgtnix-devel > |
From: Jan K. <ja...@dg...> - 2011-04-14 13:28:16
|
The mode 23 is sent from the clock to the computer (via the board) at the moment it is set by a person selecting this mode on the clock. This also goes for the start/stop button. The SETNRUN command is given by the computer to the clock (via the board) to set a time on the clock and to tell the clock which side should run. This only works on the clock in mode 23. If you want to show a message on the clock DGT_CMD_CLOCK_MESSAGE command (as described in the low level driver) must be used to display and a DGT_CMD_END_CLOCK_MESSAGE to return back to the time display. This results in the ready for disps acknowledgement, if I'm correct. To my knowledge the board does not store the clock acknowledgments, the driver has to do this. With kind regards, Met vriendelijke groet, Jan Krabbenbos Software Development Phone: +31(0) 53-4305195 Fax: +31(0)53-4329365 http://www.dgtprojects.com visit address: Hengelosestraat 66, 7514 AJ Enscheded, The Netherlands mail address: PO Box 1295, 7500 BG Enschede, The Netherlands >-----Original Message----- >From: Random Persons [mailto:net...@gm...] >Sent: donderdag 14 april 2011 13:16 >To: Main discussion place for dgtnix relative topics >Subject: Re: [Dgtnix-devel] Sim Info > >Well, I would say I am missing when exactly Mode 23 is sent to the PC. >Clock version info has a request, and I send the Mode 23 after I send >the clock version. > >Here is some of the low level driver code I used it to check my Mode >23 to make sure it was being sent correctly. > >http://ideone.com/q1WF3 > >There are three ack Messages in DGT_BWTIME this is from the low level >driver >0x81 // Ready for disps >0x88 // Start/Stop button pressed >0x8a // Clock Mode > >then there is the other one >SETNRUN (Clock Mode = 23) where it sets the clockMode to 23 I am guess >you send this BWTime when a DGT_CMD_CLOCK_SETNRUN is sent from the >computer. > > > |
From: Random P. <net...@gm...> - 2011-04-14 11:16:34
|
Well, I would say I am missing when exactly Mode 23 is sent to the PC. Clock version info has a request, and I send the Mode 23 after I send the clock version. Here is some of the low level driver code I used it to check my Mode 23 to make sure it was being sent correctly. http://ideone.com/q1WF3 There are three ack Messages in DGT_BWTIME this is from the low level driver 0x81 // Ready for disps 0x88 // Start/Stop button pressed 0x8a // Clock Mode then there is the other one SETNRUN (Clock Mode = 23) where it sets the clockMode to 23 I am guess you send this BWTime when a DGT_CMD_CLOCK_SETNRUN is sent from the computer. On Thu, Apr 14, 2011 at 5:21 AM, Jan Krabbenbos <ja...@dg...> wrote: > Hi Random, > > All info on our board protocol is on our DGT website, see: > http://digitalgametechnology.com/site/index.php/Table/Developers/ and > http://digitalgametechnology.com/site/index.php/Developers/View-category.html > > Mode 23 is a mode on the clock to show all information that is sent by a program, e.g. a chess program, to the clock via the clock messages. The other 22 modes are game clock settings (see the manual of the DGT XL) and can only be read out from the board. > > What other information are you missing? > > The board driver not returning 23 might be a bug in the driver, I should check that. > > With kind regards, > Met vriendelijke groet, > > Jan Krabbenbos > Software Development > > > Phone: +31(0) 53-4305195 > Fax: +31(0)53-4329365 > http://www.dgtprojects.com > > visit address: Hengelosestraat 66, 7514 AJ Enscheded, The Netherlands > mail address: PO Box 1295, 7500 BG Enschede, The Netherlands > > > > >>-----Original Message----- >>From: Random Persons [mailto:net...@gm...] >>Sent: donderdag 14 april 2011 12:13 >>To: dgt...@li... >>Subject: [Dgtnix-devel] Sim Info >> >>I started a new post, due to to message being over 40k and no one >>could read the topic in the archive. >> >>A status update, I am currently writing some software that simulates >>the DGT eBoard to help me write drivers for an ipad/iphone. >> >>So far the board is detected and clock are detected a long with the >>clock version. I have been using the DGT low level driver and dgtnix >>for working my way through this, I currently do not have a DGT eBoard >>and still am looking for someone with a DGT eBoard and the DGT XL >>clock to capture data. >> >>I would recommend http://sourceforge.net/projects/usbsnoop/ >> >>here is a simple guide >> >>http://www.jespersaur.com/drupal/book/export/html/21 >> >> >>Anyways, I thought I was correctly sending data to set Mode 23, but >>after I have been getting no where I went a wrote a quick simple app >>the uses the windows driver to use all the API functions and output >>data. >>I then did a call to _DGTDLL_ClockMode which always returns 0, and >>should return 23. >> >>Here is the data I am sending >> >> 0 1 2 3 4 5 6 7 8 9 >>8D 00 0A 0A 0A 09 0A 1E 0A 00 // clock version >>8D 00 0A 0A 10 01 20 00 23 00 // ready for display >>8D 00 0A 0A 10 0A 20 00 17 00 // Mode 23 >>8D 00 0A 0A 10 0A 0A 64 0A 00 // Mode 23 >> >>This is just going by what is in the low level driver. I am not really >>sure when Mode 23 is set on a normal game. >> >>If anyone has any documentation on the board to PC protocol that would >>be helpful also. >> >>------------------------------------------------------------------------ >>------ >>Benefiting from Server Virtualization: Beyond Initial Workload >>Consolidation -- Increasing the use of server virtualization is a top >>priority.Virtualization can reduce costs, simplify management, and >>improve >>application availability and disaster protection. Learn more about >>boosting >>the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>_______________________________________________ >>Dgtnix-devel mailing list >>Dgt...@li... >>https://lists.sourceforge.net/lists/listinfo/dgtnix-devel > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Dgtnix-devel mailing list > Dgt...@li... > https://lists.sourceforge.net/lists/listinfo/dgtnix-devel > |
From: Jan K. <ja...@dg...> - 2011-04-14 10:22:12
|
Hi Random, All info on our board protocol is on our DGT website, see: http://digitalgametechnology.com/site/index.php/Table/Developers/ and http://digitalgametechnology.com/site/index.php/Developers/View-category.html Mode 23 is a mode on the clock to show all information that is sent by a program, e.g. a chess program, to the clock via the clock messages. The other 22 modes are game clock settings (see the manual of the DGT XL) and can only be read out from the board. What other information are you missing? The board driver not returning 23 might be a bug in the driver, I should check that. With kind regards, Met vriendelijke groet, Jan Krabbenbos Software Development Phone: +31(0) 53-4305195 Fax: +31(0)53-4329365 http://www.dgtprojects.com visit address: Hengelosestraat 66, 7514 AJ Enscheded, The Netherlands mail address: PO Box 1295, 7500 BG Enschede, The Netherlands >-----Original Message----- >From: Random Persons [mailto:net...@gm...] >Sent: donderdag 14 april 2011 12:13 >To: dgt...@li... >Subject: [Dgtnix-devel] Sim Info > >I started a new post, due to to message being over 40k and no one >could read the topic in the archive. > >A status update, I am currently writing some software that simulates >the DGT eBoard to help me write drivers for an ipad/iphone. > >So far the board is detected and clock are detected a long with the >clock version. I have been using the DGT low level driver and dgtnix >for working my way through this, I currently do not have a DGT eBoard >and still am looking for someone with a DGT eBoard and the DGT XL >clock to capture data. > >I would recommend http://sourceforge.net/projects/usbsnoop/ > >here is a simple guide > >http://www.jespersaur.com/drupal/book/export/html/21 > > >Anyways, I thought I was correctly sending data to set Mode 23, but >after I have been getting no where I went a wrote a quick simple app >the uses the windows driver to use all the API functions and output >data. >I then did a call to _DGTDLL_ClockMode which always returns 0, and >should return 23. > >Here is the data I am sending > > 0 1 2 3 4 5 6 7 8 9 >8D 00 0A 0A 0A 09 0A 1E 0A 00 // clock version >8D 00 0A 0A 10 01 20 00 23 00 // ready for display >8D 00 0A 0A 10 0A 20 00 17 00 // Mode 23 >8D 00 0A 0A 10 0A 0A 64 0A 00 // Mode 23 > >This is just going by what is in the low level driver. I am not really >sure when Mode 23 is set on a normal game. > >If anyone has any documentation on the board to PC protocol that would >be helpful also. > >------------------------------------------------------------------------ >------ >Benefiting from Server Virtualization: Beyond Initial Workload >Consolidation -- Increasing the use of server virtualization is a top >priority.Virtualization can reduce costs, simplify management, and >improve >application availability and disaster protection. Learn more about >boosting >the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >_______________________________________________ >Dgtnix-devel mailing list >Dgt...@li... >https://lists.sourceforge.net/lists/listinfo/dgtnix-devel |
From: Random P. <net...@gm...> - 2011-04-14 10:12:42
|
I started a new post, due to to message being over 40k and no one could read the topic in the archive. A status update, I am currently writing some software that simulates the DGT eBoard to help me write drivers for an ipad/iphone. So far the board is detected and clock are detected a long with the clock version. I have been using the DGT low level driver and dgtnix for working my way through this, I currently do not have a DGT eBoard and still am looking for someone with a DGT eBoard and the DGT XL clock to capture data. I would recommend http://sourceforge.net/projects/usbsnoop/ here is a simple guide http://www.jespersaur.com/drupal/book/export/html/21 Anyways, I thought I was correctly sending data to set Mode 23, but after I have been getting no where I went a wrote a quick simple app the uses the windows driver to use all the API functions and output data. I then did a call to _DGTDLL_ClockMode which always returns 0, and should return 23. Here is the data I am sending 0 1 2 3 4 5 6 7 8 9 8D 00 0A 0A 0A 09 0A 1E 0A 00 // clock version 8D 00 0A 0A 10 01 20 00 23 00 // ready for display 8D 00 0A 0A 10 0A 20 00 17 00 // Mode 23 8D 00 0A 0A 10 0A 0A 64 0A 00 // Mode 23 This is just going by what is in the low level driver. I am not really sure when Mode 23 is set on a normal game. If anyone has any documentation on the board to PC protocol that would be helpful also. |
From: Random P. <net...@gm...> - 2011-04-13 16:49:26
|
I have been looking at the low level driver info and from what I can tell 2B 0B 03 01 79 50 77 00 77 54 00 01 00 +...yPw.wT... Is DGT_CMD_CLOCK_DISPLAY the way I think it's broken down is 2B = DGT_CLOCK_MESSAGE 0B = Length 03 = DGT_CLOCK_START_MESSAGE 01 = DGT_CMD_CLOCK_DISPLAY This is what a SetNRun Command data looks like I think 2B 09 03 0A 01 02 03 04 05 06 01 +.......... Here is another Message example 2B 0B 03 01 49 49 49 49 49 49 00 01 00 +...IIIIII... this is using the demoapp.exe to send a message to COM1 I thank you for all the help you are giving me, it is making a great difference. As for the simulator being public, if it's okay with DGT I have no problem sharing it tho it will need some cleaning up. On Tue, Apr 12, 2011 at 6:13 AM, Jan Krabbenbos <ja...@dg...> wrote: > The message you get is a SetNRun command for the clock. For displaying it > on your simulator you have to reverse the encoding as is done, have a look > at the dgtcmdclock*.h files in the example driver from our website. > > > > If the DGT XL is set in mode 23 it will show all the clock type messages > sent from the computer to the board. If the clock is switched to another > mode, only reading of the times (e.g. by DGT_SEND_CLK) is possible. > Everything sent to the clock is lost. > > The DGT_SEND_UPDATE(_NICE) is requesting continuous updates from the board > to the computer. So if something changes, it is immediately send to the > computer (asynchronous sending of messages by the board). The NICE variation > results in less messages from the board. > > > > Will your simulator be available somewhere? > > > > With kind regards, > > Met vriendelijke groet, > > > > Jan Krabbenbos > > Software Development > > > > [image: DGT+TCI(200)] > > Phone: +31(0) 53-4305195 > > Fax: +31(0)53-4329365 > > http://www.dgtprojects.com > > > > visit address: Hengelosestraat 66, 7514 AJ Enscheded, The Netherlands > > mail address: PO Box 1295, 7500 BG Enschede, The Netherlands > > > > > > > > *From:* Random Persons [mailto:net...@gm...] > *Sent:* dinsdag 12 april 2011 12:28 > > *To:* Main discussion place for dgtnix relative topics > *Subject:* Re: [Dgtnix-devel] Data Capture > > > > Oh yes, I have also sent data for Clock Mode 23, also I seem to only get > DGT_SEND_UPDATE_NICE if I read the header file right I should be getting > DGT_SEND_UPDATE and DGT_SEND_UPDATE_BRD > > On Tue, Apr 12, 2011 at 5:20 AM, Random Persons <net...@gm...> > wrote: > > I did some more work today, was able to get the DGT Driver to notice my > clock version, I was getting a request for the version all I get now from > arena is the same message, no movement updates yet. Just guessing I am doing > something wrong. > > I get this message. > > 2B 0B 03 01 79 50 77 00 77 54 00 01 00 +...yPw.wT... > > The last thing I have left to do is get it to display the movements from > arena to my software. > > On Tue, Apr 12, 2011 at 2:27 AM, Jan Krabbenbos <ja...@dg...> > wrote: > > Interesting. I thought connection to an iPod, iPad or iPhone was not > possible due to hardware requirements. At least for the Bluetooth > connectable devices. > > > > What do you want to sent to the board? Normally the information sent to the > board is only shown on the DGT XL clock (in setting 23) and must be commands > for clock settings. > > > > > > With kind regards, > > Met vriendelijke groet, > > > > Jan Krabbenbos > > Software Development > > > > [image: DGT+TCI(200)] > > Phone: +31(0) 53-4305195 > > Fax: +31(0)53-4329365 > > http://www.dgtprojects.com > > > > visit address: Hengelosestraat 66, 7514 AJ Enscheded, The Netherlands > > mail address: PO Box 1295, 7500 BG Enschede, The Netherlands > > > > > > > > *From:* Random Persons [mailto:net...@gm...] > *Sent:* maandag 11 april 2011 23:04 > *To:* Main discussion place for dgtnix relative topics > *Subject:* Re: [Dgtnix-devel] Data Capture > > > > I am trying to add in support to a ipod app that will connect to the DGT e > board. I have started writing code to emulate the hardware responses from > the board. The system finds the board and clock allows me to add and moves > pieces but when ever a engine places a move the data of that move is never > sent to the board. I am not sure if this is due to not correctly > implementing everything or what. > > On Mon, Apr 11, 2011 at 7:19 AM, Jan Krabbenbos <ja...@dg...> > wrote: > > Hi Random, > > > > As far as I know the dgtnix driver does not yet implement the clock > control. But I have an implementation at the DGT website that implements the > single board protocol, including the clock messages but without any move > reconstruction. Have a look at > http://digitalgametechnology.com/site/index.php/Developers/View-category.html. > It is written in C++ and uses the Boost Asio library for the serial port > control. Documentation on the clock messages is however not yet complete. > > > > This code also runs on Mac OSX and Linux, but this still needs a little bit > of work. > > > > > > With kind regards, > > Met vriendelijke groet, > > > > Jan Krabbenbos > > Software Development > > > > [image: DGT+TCI(200)] > > Phone: +31(0) 53-4305195 > > Fax: +31(0)53-4329365 > > http://www.dgtprojects.com > > > > visit address: Hengelosestraat 66, 7514 AJ Enscheded, The Netherlands > > mail address: PO Box 1295, 7500 BG Enschede, The Netherlands > > > > > > > > > > *From:* Random Persons [mailto:net...@gm...] > *Sent:* maandag 11 april 2011 13:57 > *To:* dgt...@li... > *Subject:* [Dgtnix-devel] Data Capture > > > > I don't currently have access to a DGT eBoard, I am writing some software > for one right now tho. I can not get Arena 3.0 or any other software to send > data to the clock. I am using windows I know this a linux driver. I figured > this would be the best place to ask for a data capture of a DGT eBoard > connecting to a computer and playing a game. I am looking for the data sent > from the board and from the computer. If anyone can help me out let me know. > > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Dgtnix-devel mailing list > Dgt...@li... > https://lists.sourceforge.net/lists/listinfo/dgtnix-devel > > > > > > > ------------------------------------------------------------------------------ > Forrester Wave Report - Recovery time is now measured in hours and minutes > not days. Key insights are discussed in the 2010 Forrester Wave Report as > part of an in-depth evaluation of disaster recovery service providers. > Forrester found the best-in-class provider in terms of services and vision. > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > > > _______________________________________________ > Dgtnix-devel mailing list > Dgt...@li... > https://lists.sourceforge.net/lists/listinfo/dgtnix-devel > > > > > > > ------------------------------------------------------------------------------ > Forrester Wave Report - Recovery time is now measured in hours and minutes > not days. Key insights are discussed in the 2010 Forrester Wave Report as > part of an in-depth evaluation of disaster recovery service providers. > Forrester found the best-in-class provider in terms of services and vision. > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > _______________________________________________ > Dgtnix-devel mailing list > Dgt...@li... > https://lists.sourceforge.net/lists/listinfo/dgtnix-devel > > |
From: Random P. <net...@gm...> - 2011-04-11 11:57:32
|
I don't currently have access to a DGT eBoard, I am writing some software for one right now tho. I can not get Arena 3.0 or any other software to send data to the clock. I am using windows I know this a linux driver. I figured this would be the best place to ask for a data capture of a DGT eBoard connecting to a computer and playing a game. I am looking for the data sent from the board and from the computer. If anyone can help me out let me know. |
From: Jan K. | D. <ja...@dg...> - 2008-11-18 08:40:53
|
Hello Alexander, Ben asked me to add some more information. >-----Original Message----- >> The information on how to send a message to the clock is not easy >> available. It is not in the DGTbrd13.h board protocol description. >> In the past, which information did you get on all communication >> protocols? > >All protocol descriptions I've at hand is this very dgtbrd13.h file >offered for download at the dgt website. Most of the time I sit with my >application on top of the dgtnix library itself, so I did not have the >necessity to dig to deep into it while working on dgtdrv. I think >sending messages to the clock should be a function there and I'd try to >add it. But I did not yet search in detail how it has to be done. My >primary work this weekend was to get Scid interface with the board/clock >nicely. Now that the base functions are all there I'm planing to get it >"nice" ie. add all that is available in the windows driver. Sending messages to the clock are effectively clock messages embedded in the board protocol. I have look up the information how this works. Unfortunately I do not have a document lying around that describes it. I have to dive into the sources for making a description of this. Give me some time for this, as I'm too busy with a lot of things at the moment. >BTW: any interest in the protocol I used for dgtdrv on your side? E.g. >doing an own application? I think it would be pretty simple to set up a >small app using your own lib. One idea of this protocol is, that >acutally any chess application that know how to play an engine-engine >tournament is able to get minimal DGT support and with a few extra lines >within the app to add handling for a hand full of new message it gets a >pretty smooth integration as it offers also functions to send the board >position and so on. I did something like that for xboard as an example, >its only about 50 lines. For a protocol description see dgtdrv.sf.net, >it is very much like xbord and uci. (You know, for a multiplatform >product like Scid, which runs on a variety of Unices, Windows, Mac... it >is a bit difficult to bind to different external libs so I feel it >easier to use an engine like approach. The only alternative for Scid >would be to code all DGT handling in plain TCL which would then be only >usable for Scid. I gave that a try but its cumbersome and I admit that I >really prefer C. And the interface idea from an design point of view.) You're the second person in two days to mention the engine approach. I was organizing the Open Dutch Computer Chess Championships last weekend (Rybka won) and somebody there mentioned the same. And as far as I know we have already some software that behaves like that. For ChessMaster we have the Gamekeeper program that behaves like an engine. Of course this is only for the Windows platform. I discussed with Ben the engine approach and why this has not done before. It seemed the difference between human and machine behavior makes the implementation of a engine too difficult, e.g. the taking back of the moves. I think this worth to look at again. To make a correct engine it should be fully XBoard and UCI compliant, so many chess related programs can benefit from this. My guess is that the extra commands will not be used much, unless they are added in the XBoard and UCI protocols. With kind regards, Met vriendelijke groet, Jan Krabbenbos Software Development Official Supplier Chess Olympiad 2008 Dresden Phone: +31(0)53-4305195 Fax: +31(0)53-4329365 http://www.dgtprojects.com visit address: Hengelosestraat 66, 7514 AJ Enschede, The Netherlands mail address: PO Box 1295, 7500 BG Enschede, The Netherlands |
From: Alexander W. <aw...@st...> - 2008-11-17 08:30:48
|
Hello Ben! > The information on how to send a message to the clock is not easy > available. It is not in the DGTbrd13.h board protocol description. > In the past, which information did you get on all communication > protocols? All protocol descriptions I've at hand is this very dgtbrd13.h file offered for download at the dgt website. Most of the time I sit with my application on top of the dgtnix library itself, so I did not have the necessity to dig to deep into it while working on dgtdrv. I think sending messages to the clock should be a function there and I'd try to add it. But I did not yet search in detail how it has to be done. My primary work this weekend was to get Scid interface with the board/clock nicely. Now that the base functions are all there I'm planing to get it "nice" ie. add all that is available in the windows driver. BTW: any interest in the protocol I used for dgtdrv on your side? E.g. doing an own application? I think it would be pretty simple to set up a small app using your own lib. One idea of this protocol is, that acutally any chess application that know how to play an engine-engine tournament is able to get minimal DGT support and with a few extra lines within the app to add handling for a hand full of new message it gets a pretty smooth integration as it offers also functions to send the board position and so on. I did something like that for xboard as an example, its only about 50 lines. For a protocol description see dgtdrv.sf.net, it is very much like xbord and uci. (You know, for a multiplatform product like Scid, which runs on a variety of Unices, Windows, Mac... it is a bit difficult to bind to different external libs so I feel it easier to use an engine like approach. The only alternative for Scid would be to code all DGT handling in plain TCL which would then be only usable for Scid. I gave that a try but its cumbersome and I admit that I really prefer C. And the interface idea from an design point of view.) -- Kind regards, / War is Peace. | Freedom is Slavery. Alexander Wagner | Ignorance is Strength. | | Theory : G. Orwell, "1984" / In practice: USA, since 2001 |
From: Ben B. | D. <be...@dg...> - 2008-11-17 08:05:53
|
Dear Alexander, The information on how to send a message to the clock is not easy available. It is not in the DGTbrd13.h board protocol description. In the past, which information did you get on all communication protocols? Kind regards, Ben Ben Bulsink, CDO Phone: 0031(0)53-4305195 Fax: 0031(0)53-4329365 Mobile: +31(0)6-51825066 http://www.dgtprojects.com Hengelosestraat 66 7514 AJ Enschede The Netherlands -----Oorspronkelijk bericht----- Van: Alexander Wagner [mailto:a.w...@ph...] Verzonden: zaterdag 15 november 2008 14:39 Aan: Main discussion place for dgtnix relative topics Onderwerp: [Dgtnix-devel] DGT Clock handling Hi! After quite a while I managed to get a DGT Clock at a resonable price. Now, checking if it works well in dgtnix and especially dgtdrv. The first thing I found is, that there seems no possibility to send a string to the clock, e.g. to display the last move. Did I miss something here? Additionally, I discover that there seems to be a "bug" (well, more an inconvenience...) in message parsing concerning clock detection. dgtnixGetClockData() returns an integer, signifying if a clock is connected. Unfortunately, it also returns with "no clock" if the clock is present but halted, or, the other way round, it returns only correct info if the clock is actually running. However, for smooth integration with a GUI (currently I'm working on Scid, 3.6.27 will have dgt support by means of dgtdrv; current cvs already has :) it would be better if I'd be able to detect the presence of the clock even if it is not running. Unfortunately, I've to admit that I do not really understand whats going on within _bwtimeReceived(). :( Anyway, the relevant part of the docs would be: byte 0: DGT_MSG_BWTIME byte 1: LLH_SEVEN(DGT_SIZE_BWTIME) (=0 fixed) byte 2: LLL_SEVEN(DGT_SIZE_BWTIME) (=10 fixed) byte 3: D4: 1 = Flag fallen for left player, and clock blocked to zero 0 = not the above situation D5: 1 = Time per move indicator on for left player ( i.e. Bronstein, Fischer) 0 = Time per move indicator off for left player D6: 1 = Left players flag fallen and indicated on display 0 = not the above situation (D7 is MSB) D0-D3: Hours (units, 0-9 Binary coded) white player (or player at the A side of the board) byte 4: Minutes (0-59, BCD coded) byte 5: Seconds (0-59, BCD coded) byte 6-8: the same for the other player byte 9: Clock status byte: 7 bits D0 (LSB): 1 = Clock running 0 = Clock stopped by Start/Stop D1: 1 = tumbler position high on (white) player (front view: \ , left side high) 0 = tumbler position high on the other player (front view: /, right side high) D2: 1 = Battery low indication on display 0 = no battery low indication on display D3: 1 = Black players turn 0 = not black players turn D4: 1 = White players turn 0 = not white players turn D5: 1 = No clock connected; reading invalid 0 = clock connected, reading valid D6: not used (read as 0) D7: Always 0 The function of the information bits are derived from the full information as described in the programmers reference manual for the DGT TopMatch -- Kind regards, / War is Peace. | Freedom is Slavery. Alexander Wagner | Ignorance is Strength. | | Theory : G. Orwell, "1984" / In practice: USA, since 2001 ------------------------------------------------------------------------ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Dgtnix-devel mailing list Dgt...@li... https://lists.sourceforge.net/lists/listinfo/dgtnix-devel |
From: Alexander W. <a.w...@ph...> - 2008-11-16 19:48:16
|
Pierre Boulenguez wrote: Hi! [...] >> No. If I plug to clock to the board, turn it on but not >> yet start it, it reports "not present". That is the clock >> is there but just halted. That is everything is ready for >> a match. The point is not entirely catastrophic as I get >> a time event once the clock starts running, but it takes >> me the possibility to present a nice button to the user >> "Use external time source" which I could disable if no >> clock is found. > Hum, you're right. I will look if it is possible to check > the presence of the clock without the counter being > started. I'm not sure of that. If I get the original DGT header correctly it differentiates these two states and if I look the Win-implementation it is also able to detect the clock before it starts running. (I've a version of Fritz 8 + DGT running in Wine.) [...] > A descriptor per device, hum, it makes sense on the client > side (on the board and clock side, only one can survive as > attached to only one serial/usb device). Surely only on the client side. > This would mean demultiplexing the signals in the driver. > Yes, that's feasible. I just think that this would ease up implementation. Currently, the actual move detection is already quite a bit of code, and I just noticed that the clock events spoiled it all together, cause the logic is to get the first half of a ply and one has to wait for the second half to appear within a given timeframe. Maybe my algorigthm can be improved, however. I use something like: char *ReadHalfMove (int Descriptor) { char *buffer; // return value from ReadDescriptor buffer = ReadDescriptor(Descriptor); if (buffer[0] == 2) { PrintClockData(); } while((buffer[0] > 1) || (buffer[0] < 0)) { buffer = ReadDescriptor(Descriptor); } return(buffer); } To extract half of a move (one move = e2e4). The above then is used to find "remove Pawn on e2" and it is called again for "place Pawn on e4". The buffer[0]==2 loops just catch the clock events and I've to clear the pending data (while). The main HandleDGT() then goes like this: msg0 = ReadHalfMove(BoardDescriptor); msg1 = ReadHalfMove(BoardDescriptor); if (msg0[0] == DGTNIX_MSG_MV_REMOVE) { // a piece is lifted first = possible begin of a move if (msg1[0] == DGTNIX_MSG_MV_ADD) { // a piece is set second = possible end of a move // // Code to actually detect the various moves // // Here for 0-0 again some reading of 2 half moves // comes in. } } On the other hand, one could leave it on one descriptor but give the possibility to switch of the clock events. Something like the UPDATE_BRD and UPDATE states described in DGTs header. > A contrario, I'm not sure that allowing raw communication > to the board and clock is a good idea. Well, this depends of course. My idea was something like void dgtnixSendMsg (unsigned long option) { _sendMessageToBoard(option); } E.g. Some routine to send data to the board is required on the other hand to send text/time information to the clock. One could surely wrap this also into some function. -- Kind regards, / War is Peace. | Freedom is Slavery. Alexander Wagner | Ignorance is Strength. | | Theory : G. Orwell, "1984" / In practice: USA, since 2001 |
From: Pierre B. <pie...@ya...> - 2008-11-16 19:18:51
|
Alexander Wagner a écrit : > Pierre Boulenguez wrote: > > Hello Pierre! > > Nice to hear from you again! :) Admitting that I've ben just > to busy for "professional" reasons, and thus a bit silent > myself for quite a while. > Nice to hear from you too Alexander :) >> Indeed sending a string to the clock is not implemented >> yet. > > Noticed that :) Now that I've the possibility to play > arround with a clock it came to my mind to try. > > But besides sending a string like "Nf3" to the clock, it > would IMHO be of much greater value if one could use "Mode > 23", that is set the timing on the clock by an external > source. This would be very handy for playing on FICS e.g. > where Scid makes a pretty good client these days and it > could also come in handy for the playing functionality that > got added to Scid recently as well. However, for the latter > I'm about to add also the inverse, ie. that the external > clock can be used to set Scids internal game clocks, as the > DGT clock offers much more flexibility today than Scids > timing functions. > >> Regarding the clock, do you mean that when the clock is >> pluged to the board but the power switch is turned off, >> dgtnix returns 'not present' ? If so, it's not a bug, >> just a lack of documentation. > > No. If I plug to clock to the board, turn it on but not yet > start it, it reports "not present". That is the clock is > there but just halted. That is everything is ready for a > match. The point is not entirely catastrophic as I get a > time event once the clock starts running, but it takes me > the possibility to present a nice button to the user "Use > external time source" which I could disable if no clock is > found. Hum, you're right. I will look if it is possible to check the presence of the clock without the counter being started. I'm not sure of that. > > However, it gets critical once I could use Mode 23, cause > then I'd have to set one time reference. > > Ah, and I also noticed a slight inconvenience while handling > the board descriptor. As both, the clock and the move events > come in on the same descriptor, a half move however consists > of two board events (remove piece and place piece) I usually > see at least one clock event between the two events for a > move, simply cause the clock event comes in every second at > the least. This gets even worse for casteling, where a > single ply consists of 4 board events. It took me a while to > fiddle all these incoming events apart without deadlocking > the move recognigion. Things would IMHO be easier if the > clock events would come in via a separate descriptor, or the > clock would not generate any events on the descriptor but > move the time information dgtnixGetClockData(). The API is a > bit inconsistent here (IMHO), as there is actually no need > to see the bare clock events as there is a nice function > that delivers them in usable form. A descriptor per device, hum, it makes sense on the client side (on the board and clock side, only one can survive as attached to only one serial/usb device). This would mean demultiplexing the signals in the driver. Yes, that's feasible. A contrario, I'm not sure that allowing raw communication to the board and clock is a good idea. > > My first approach was to set the board to UPDATE_BRD instead > of UPDATE. Funny enough this got me the clock hooked of > entirely, though I tried to send a DGT_SEND_CLK before > invoking dgtnixGetClockData(). (BTW: there seems a function > missing that allows to send bare DGT commands to the board.) > I was a bit confused here and then resorted back to fiddling > appart the both event types in my own code. > > BTW: The clock I've here is version 1.14, according to the > imprints, my boards electronics is 1.9. > |
From: Alexander W. <a.w...@ph...> - 2008-11-16 17:33:13
|
Pierre Boulenguez wrote: Hello Pierre! Nice to hear from you again! :) Admitting that I've ben just to busy for "professional" reasons, and thus a bit silent myself for quite a while. > Indeed sending a string to the clock is not implemented > yet. Noticed that :) Now that I've the possibility to play arround with a clock it came to my mind to try. But besides sending a string like "Nf3" to the clock, it would IMHO be of much greater value if one could use "Mode 23", that is set the timing on the clock by an external source. This would be very handy for playing on FICS e.g. where Scid makes a pretty good client these days and it could also come in handy for the playing functionality that got added to Scid recently as well. However, for the latter I'm about to add also the inverse, ie. that the external clock can be used to set Scids internal game clocks, as the DGT clock offers much more flexibility today than Scids timing functions. > Regarding the clock, do you mean that when the clock is > pluged to the board but the power switch is turned off, > dgtnix returns 'not present' ? If so, it's not a bug, > just a lack of documentation. No. If I plug to clock to the board, turn it on but not yet start it, it reports "not present". That is the clock is there but just halted. That is everything is ready for a match. The point is not entirely catastrophic as I get a time event once the clock starts running, but it takes me the possibility to present a nice button to the user "Use external time source" which I could disable if no clock is found. However, it gets critical once I could use Mode 23, cause then I'd have to set one time reference. Ah, and I also noticed a slight inconvenience while handling the board descriptor. As both, the clock and the move events come in on the same descriptor, a half move however consists of two board events (remove piece and place piece) I usually see at least one clock event between the two events for a move, simply cause the clock event comes in every second at the least. This gets even worse for casteling, where a single ply consists of 4 board events. It took me a while to fiddle all these incoming events apart without deadlocking the move recognigion. Things would IMHO be easier if the clock events would come in via a separate descriptor, or the clock would not generate any events on the descriptor but move the time information dgtnixGetClockData(). The API is a bit inconsistent here (IMHO), as there is actually no need to see the bare clock events as there is a nice function that delivers them in usable form. My first approach was to set the board to UPDATE_BRD instead of UPDATE. Funny enough this got me the clock hooked of entirely, though I tried to send a DGT_SEND_CLK before invoking dgtnixGetClockData(). (BTW: there seems a function missing that allows to send bare DGT commands to the board.) I was a bit confused here and then resorted back to fiddling appart the both event types in my own code. BTW: The clock I've here is version 1.14, according to the imprints, my boards electronics is 1.9. -- Kind regards, / War is Peace. | Freedom is Slavery. Alexander Wagner | Ignorance is Strength. | | Theory : G. Orwell, "1984" / In practice: USA, since 2001 |
From: Pierre B. <pie...@ya...> - 2008-11-16 17:08:59
|
Hi Alexander, Indeed sending a string to the clock is not implemented yet. Regarding the clock, do you mean that when the clock is pluged to the board but the power switch is turned off, dgtnix returns 'not present' ? If so, it's not a bug, just a lack of documentation. BR, Pierre Alexander Wagner a écrit : > Hi! > > After quite a while I managed to get a DGT Clock at a > resonable price. Now, checking if it works well in dgtnix > and especially dgtdrv. The first thing I found is, that > there seems no possibility to send a string to the clock, > e.g. to display the last move. Did I miss something here? > > Additionally, I discover that there seems to be a "bug" > (well, more an inconvenience...) in message parsing > concerning clock detection. > > dgtnixGetClockData() > > returns an integer, signifying if a clock is connected. > > Unfortunately, it also returns with "no clock" if the clock > is present but halted, or, the other way round, it returns > only correct info if the clock is actually running. However, > for smooth integration with a GUI (currently I'm working on > Scid, 3.6.27 will have dgt support by means of dgtdrv; > current cvs already has :) it would be better if I'd be able > to detect the presence of the clock even if it is not > running. > > Unfortunately, I've to admit that I do not really understand > whats going on within _bwtimeReceived(). :( > > Anyway, the relevant part of the docs would be: > > byte 0: DGT_MSG_BWTIME > byte 1: LLH_SEVEN(DGT_SIZE_BWTIME) (=0 fixed) > byte 2: LLL_SEVEN(DGT_SIZE_BWTIME) (=10 fixed) > byte 3: > D4: 1 = Flag fallen for left player, and clock blocked to zero > 0 = not the above situation > D5: 1 = Time per move indicator on for left player ( i.e. Bronstein, > Fischer) > 0 = Time per move indicator off for left player > D6: 1 = Left players flag fallen and indicated on display > 0 = not the above situation > (D7 is MSB) > D0-D3: Hours (units, 0-9 Binary coded) white player (or player at the A > side of the board) > byte 4: Minutes (0-59, BCD coded) > byte 5: Seconds (0-59, BCD coded) > > byte 6-8: the same for the other player > > byte 9: Clock status byte: 7 bits > D0 (LSB): 1 = Clock running > 0 = Clock stopped by Start/Stop > D1: 1 = tumbler position high on (white) player (front view: \ , left > side high) > 0 = tumbler position high on the other player (front view: /, right > side high) > D2: 1 = Battery low indication on display > 0 = no battery low indication on display > D3: 1 = Black players turn > 0 = not black players turn > D4: 1 = White players turn > 0 = not white players turn > D5: 1 = No clock connected; reading invalid > 0 = clock connected, reading valid > D6: not used (read as 0) > D7: Always 0 > The function of the information bits are derived from the full information > as described in the programmers reference manual for the DGT TopMatch > > |
From: Alexander W. <a.w...@ph...> - 2008-11-16 14:03:36
|
Hi! I've just committed V1.21 of the driver to dgtdrv's cvs. It requires the current V1.9.1 of dgtnix. For usage with Scid (http://scid.sf.net) at least this version will be required, and chances are good that Scid gets quite confused with earlier versions of the driver. Most issues in 1.21 deal with adoption of the code to handle a DGT XL clock properly. Concerning Scid, it would of course be nice if there were some testers out here. DGT support will most likely be in 3.6.27 by means of dgtdrv. There is no release date yet for this version, so please use the cvs edition. Feedback welcome. BTW: It would be very nice if there'd be someone who could provide binaries for Mac and Windows. I can compile on neither platform. Also note that Scid uses input engine protocol for DGT support. In principle every input engine following the specs at dgtdrv.sf.net should work well. One could e.g. also build a driver engine using other libs than dgtnix. -- Kind regards, / War is Peace. | Freedom is Slavery. Alexander Wagner | Ignorance is Strength. | | Theory : G. Orwell, "1984" / In practice: USA, since 2001 |
From: Alexander W. <a.w...@ph...> - 2008-11-15 14:14:00
|
Hi! After quite a while I managed to get a DGT Clock at a resonable price. Now, checking if it works well in dgtnix and especially dgtdrv. The first thing I found is, that there seems no possibility to send a string to the clock, e.g. to display the last move. Did I miss something here? Additionally, I discover that there seems to be a "bug" (well, more an inconvenience...) in message parsing concerning clock detection. dgtnixGetClockData() returns an integer, signifying if a clock is connected. Unfortunately, it also returns with "no clock" if the clock is present but halted, or, the other way round, it returns only correct info if the clock is actually running. However, for smooth integration with a GUI (currently I'm working on Scid, 3.6.27 will have dgt support by means of dgtdrv; current cvs already has :) it would be better if I'd be able to detect the presence of the clock even if it is not running. Unfortunately, I've to admit that I do not really understand whats going on within _bwtimeReceived(). :( Anyway, the relevant part of the docs would be: byte 0: DGT_MSG_BWTIME byte 1: LLH_SEVEN(DGT_SIZE_BWTIME) (=0 fixed) byte 2: LLL_SEVEN(DGT_SIZE_BWTIME) (=10 fixed) byte 3: D4: 1 = Flag fallen for left player, and clock blocked to zero 0 = not the above situation D5: 1 = Time per move indicator on for left player ( i.e. Bronstein, Fischer) 0 = Time per move indicator off for left player D6: 1 = Left players flag fallen and indicated on display 0 = not the above situation (D7 is MSB) D0-D3: Hours (units, 0-9 Binary coded) white player (or player at the A side of the board) byte 4: Minutes (0-59, BCD coded) byte 5: Seconds (0-59, BCD coded) byte 6-8: the same for the other player byte 9: Clock status byte: 7 bits D0 (LSB): 1 = Clock running 0 = Clock stopped by Start/Stop D1: 1 = tumbler position high on (white) player (front view: \ , left side high) 0 = tumbler position high on the other player (front view: /, right side high) D2: 1 = Battery low indication on display 0 = no battery low indication on display D3: 1 = Black players turn 0 = not black players turn D4: 1 = White players turn 0 = not white players turn D5: 1 = No clock connected; reading invalid 0 = clock connected, reading valid D6: not used (read as 0) D7: Always 0 The function of the information bits are derived from the full information as described in the programmers reference manual for the DGT TopMatch -- Kind regards, / War is Peace. | Freedom is Slavery. Alexander Wagner | Ignorance is Strength. | | Theory : G. Orwell, "1984" / In practice: USA, since 2001 |
From: <a.w...@ph...> - 2008-10-28 14:31:11
|
Hi! That's good news indeed. We also had some queries about dgtnix on the Mac as my frontend driver (dgtdrv.sf.net) needs it and I just finished a first version of dgt-support for the Scid chess database. (Most likely that will be in 3.6.27.) Hence, I'd be very interested in also getting a binary of dgtdrv working on the Mac. I'd be happy if we could get this up as well. Tord, I have no access to a mac myself, I was just able to lend one for some hours in the past and I was able to compile dgtdrv without any problems. I am pretty sure that the problems that were left are within the dgtnix library itself as my program dies in the initialisation. Pascal George mentioned, that handshake could be an issue and that he solved a similar problem with the Novag Citrine by setting the handshake lines properly using a soldering iron ;) ----- original message -------- Subject: Re: [Dgtnix-devel] Mac problems Sent: Tue, 28 Oct 2008 From: Tord Romstad<tor...@gm...> > On Tue, Oct 28, 2008 at 10:23 AM, Jan Krabbenbos | DGT > <ja...@dg...> wrote: > > Hi Pierre, > > > > > > > > Some more good news: Tord Romstad of the Glaurung program is going to do > the > > work on the Mac side. He will join the mailing list in a short time. > > Yes, I'm here. :-) > > > He will also use dgtnix to implement the use of the board in Glaurung. So > next to a > > Mac version, there will also be another chess program using the > interface. > > Yes, that's my plan. I'll try to fix the problems with dgtnix in Mac > OS X, prepare an easily installable binary distribution of the > library, and link this binary to my own program. > > > Compiling of dgtnix under Mac OSX goes well. I tried that at home on my > own > > MacBook. Getting it to work was indeed the problem. Due to time > constraints > > I did not look into it and I'm happy someone wants to solve this. And DGT > is > > supporting this effort. > > I look forward to trying. I have no idea how hard it will be, but > with the help of this mailing list, the support from DGT, and possibly > Apple's development mailing lists, I think I should be able to make it > work. > > Tord > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Dgtnix-devel mailing list > Dgt...@li... > https://lists.sourceforge.net/lists/listinfo/dgtnix-devel > --- original message end ---- |