Author: Robert Hyatt
Date: 13:56:14 09/14/98
Go up one level in this thread
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 page took 0.01 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.