Author: Roberto Waldteufel
Date: 01:14:17 09/15/98
Go up one level in this thread
On September 14, 1998 at 16:56:14, Robert Hyatt wrote: >On September 14, 1998 at 12:44:16, Amir Ban wrote: > >>On September 14, 1998 at 09:05:33, Robert Hyatt wrote: >> >> >>>actually auto232 is dependent on DOS (the original version) due to the >>>command-line buffer stuffing approach it took. And that was the only way to >>>make the non-auto232 programs use auto232, by scanning the graphics memory to >>>see when the board is updated and then send that to the other program via a >>>serial cable and the dos console-input buffer... >>> >> >>That's not how the DOS autoplayer worked, and besides you are confusing the >>auto232 serial protocol with Donninger's DOS autoplayer. > >that's how the one I tried about 3 years ago worked. A different driver for >each engine, that was loaded as a "TSR" program under dos. And it would send >the move to the other dos box over the serial cable, and let it stuff the move >wherever it was supposed to go, however it needed to be stuffed... > > > >> >> >>>notice that winboard protocol is also supported by 20 programs or more, and >>>that at least one *commercial* program will have the winboard protocol support >>>included soon (I'll leave it to the programmer to spill the beans if he wants). >> >>Then why is SSDF and everybody else playing thousands of auto232 games and not >>winboard games ? > >because commercial engines don't support winboard. yet. But I'll go out on >a limb and bet that they will, over time, because the protocol is better and >more complete than auto232.. > > >> >> >>>But auto232 is incomplete, and cryptic, which are my two main complaints (if >>>you factor out the DOS version with the timing problems). >>> >> >>I implemented auto232 in both the DOS and Windows versions. Some minor problems >>but the thing works. I didn't deal with any timing problem. > >Interesting that you didn't. I stayed in contact with several of the SSDF >guys, as I got auto232 (noname) to work, and found that more than a few games >were "hanging", and not just games with Crafty involved. Other programs as >well, including top-ranked commercial ones. The windows implementation gets >rid of the ugly TSR approach and ought to be far better, but the protocol is >simply not complete. Do we have to live with something just because it works? >Or can we, on occasion, rectify gross omissions and ambiguities and fix the >thing? We've made several iterations on the winboard protocol to add >information like offering/accepting draws, and so forth... > > > > > >> >> >>> >>> >>>first criticism: no under-promotion. I've lost drawn games and drawn won >>>games due to this sort of problem, when a beta version of xboard didn't handle >>>underpromotion either. >> >>Currently you can't play any move, and you are worried about under-promotions ? > > >crafty works fine with the DOS-based auto232. Except when it hits on a >tablebase during the search. This causes the game to hang for reasons unknown. >Other programs probing during the search are having the same problem. I haven't >don'e a windows-version and probably won't. And yes, I worry about playing a >legitimate game of chess. And not allowing under-promotions is silly. I can >think of several games that were lost due to this bug, one by a program called >LaChex at an ACM event in 1992, because his program never considered promoting >to anything but a queen. And it turned a win into an instant loss. > > > > >> >> >>> >>>second criticism: incomplete. Can't find out who I am playing. Can't find >>>out the rating of who I am playing. Can't offer a draw to my opponent. Can't >>>accept a draw, if offered by my opponent. etc... >>> >> >>The inability to conclude a game without that horrible timeout is indeed the >>worst part of auto232. These are minor issues, that have been discussed before, >>and can be easily amended without breaking the entire standard. >> >> >>>IE it seems that the timing is right to do a *complete* protocol. Design it >>>right from the ground up. And if the protocol is separated from the engine by >>>using an interface program (as we do with winboard/xboard) then, for a temporary >>>compatibility fix, a special auto232 to new-interface-spec program could be >>>written to filter/adjust messages as needed... with the long-term goal of >>>phasing this kludge out.. >>> >> >>What for ? >> >>You are thinking about this the wrong way. Nobody abandons an old established >>standard for such superficial reasons. > > >These are not exactly "superficial". They are deep shortcomings. The current >windows version can't be modified at all without shipping source code to >everyone, having them recompile their programs and then distribute the patched >versions. I doubt commercial programmers will take that expense lying down. >Separating the interface from the engine makes a lot of sense. The interface >can be extended, bugs can be fixed, and it can be distributed without requiring >compiles or anything for each engine... > >But lots of "old" standards have been abandoned. Check out ethernet and how >it has evolved... > > > > >> >>> >>>I already have auto232 support in crafty... It has been there for two years at >>>least. As far as genius, I don't really care about it. It would be possible to >>>design the "interface program" with an old auto232-compatibility mode so that it >>>can talk to an auto232 program and simply give up the features that the old >>>auto232 protocol doesn't support.. >>> >> >>You can propose a new standard. You can't impose it. It has a chance if the old >>standard is not too entrenched and if the developers and the users have enough >>interest to go through the hassle and the cost (and they *always* want a really >>compelling reason for that). >> >>Amir > > >I'm not trying to impose a new standard... But there are now far more >"amateur" programs than there are "commercial" programs, and almost all of the >amateur programs are supporting winboard, or have supported winboard in the >past. IE Ferret started out with this built in... > >All I want is *one* external interface that everyone likes. Then we can get >tim to modify xboard/winboard if needed. I can write the unix interface to >connect two machines. Someone else can write the windows interface (again, the >interface has to be separate from the source of the engine, so that the engine >only knows about the protocol format and can parse the commands properly)... > >It would mean we would *all* be xboard / winboard compatible, that you could >sell a unix version without having to rewrite your GUI from the ground up. An >ICS interface would be available for anyone wanting to run a commercial program >on a server. Etc. > >Lots of advantages... nothing negative that I can see at all, other than the >initial work to include everything we think the protocol should have, and then >everyone modifies their engine to understand those messages... > >Then, until the rules of chess change, we should be set, once and for all, with >none of the current "holes" in the protocol... > >This isn't a "crusade"... I just don't want to have to support the original >auto232, then make the changes for the new windows auto232, and then make more >changes when someone decides to fix the problems with the basic protocol. It >would be far better to have *one* protocol for all of this stuff... And the >sooner, the better, because there are lots of new engines in development right >now... This has been a problem for me while developing Rabbit. I started out using a 16-bit DOS compiler, and I implemented Auto232 fairly successfully under DOS when Rabbit was invited to play in FSV Summer98, although I had trouble with Rabbit playing book moves too fast. Then I got a faster 32-bit Windows compiler and ported Rabbit to that - my DOS program became a Windows program and Auto232 has not worked since then. I am very interested to make Rabbit compatible with some form of autoplayer so it can more easily participate in computer chess tournaments, but I am completely stuck with Windows! If a new protocol and interface is going to become available, I hope to support it in Rabbit. My guess is that quite a few other programmers will be ready to support it as long as it is easy to implement. I like the idea of a separate interface and engine, but I would need to know exactly how to communicate between Rabbit and the the Autoplayer. Has anybody actually started work on the project yet? Best wishes, Roberto
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.