Author: Vincent Diepeveen
Date: 06:14:35 03/30/01
Go up one level in this thread
On March 29, 2001 at 10:54:38, Robert Hyatt wrote: >On March 29, 2001 at 09:24:12, Ed Schröder wrote: > >>On March 29, 2001 at 07:43:53, pete wrote: >> >>>On March 29, 2001 at 00:22:03, Robert Hyatt wrote: >>> >>>>> >>>>>There was an extremely nice answer to this and similar posts published in the >>>>>German CSS magazine in an article by Chrilly Donninger some time ago. >>>>> >>>>>It would simply be great if it could be put to the Web ; it explained how the >>>>>autoplayer started and developped and really opened my eyes . >>>>> >>>>>After reading it I understood the problems of the autoplayer and the reasons for >>>>>them much better . >>>>> >>>>>I don't know who holds the rights for it but it was >>>>> >>>>>a.) very convincing >>>>>b.) understandable to any non-programmer guy , too . >>>>> >>>>>pete >>>> >>>> >>>>Don't believe everything you read. >>> >>>Thanks for the tip . >>> >>> I wrote serial I/O multiplexing code >>>>using an 8080 microprocessor. I had _no_ timing dependencies. If you see >>>>old pictures of Cray Blitz and my electronic chess board, you will see a >>>>chess board with a built-in modem, all driven by a Z80 microprocessor. That >>>>thing talked to the cray, to the chess board, and to a dumb terminal so we could >>>>see what the Cray was thinking. Maintaining three separate streams of data >>>>context. Nary a timing issue. >>>> >>>>There were ways to write auto232 without the timing nonsense. It simply wasn't >>>>done. >>>> >>>>And as a result, it belongs in a "hefty bag" if you know what I mean. :) >>> >>>Well , actually I am under the impression you haven't read the article >>>mentioned. Unfortunately the CSS homepage is down and I don't have it handy >>>either currently. From what I remember the autoplayer initially was nothing more >>>than a side-product of the implementation for support of an existing >>>electronical chessboard Auto232 . I don't remember the exact numbers now but the >>>memory limitations were extreme . The article explained the reasons for some >>>technical shortcomings very well . >>> >>>The article agreed that the implementation might not be very well at all and >>>encouraged people to simply write something better if they don't like the >>>product quoting a similar statement from you about Crafty :-). >> >>Yes I remember Chrilly qouting Bob, "auto232 is a piece of junk" with a >>wink. When auto232 came out, I believe it was 1994, it was a sensation. >>Suddenly you could play matches all automatic. It has changed the CC >>community as auto232 rapidly became the key to judge the playing strength >>of new released engines. Piece of junk or not, it still is the key today. >> >>I write this because I feel that using this tool should be discussed >>endlessly, its pro's, its contra's, its bugs. CCC is for 90% about playing >>strength and chess programs are being judged on the use of this fragile >>tool. >> >>In this spirit I have enjoyed Chrilly's contribution because he wrote some >>details I wasn't aware off, and wasn't hiding any quirks of auto232 being >>completely open and honest about a simple idea he once had which changed >>the CC community to a great extend. >> >>Never forget that auto232 is a vulnerable system and many things can go >>wrong. During the beta-poriod of the upcoming Rebel 11 update suddenly >>auto232 complaints from the beta-team came (aborted matches) while nothing >>has been changed in the auto232 code. At first I told the beta-team to >>ignore the complaints saying, "there is nothing changed, auto232 just has >>its own mysterious ways, you never get it optimal". >> >>But Lex could not resist and made changes resulting in a more stabile >>autoplayer. Maybe if Lex reads this he can explain a bit about the nature >>of the changes and why he thinks the autoplayer code suddenly behave >>awkward while nothing had changed. Looking at my own experiences I am >>pretty sure his explanations will be vague, probably related to what Bob >>has been said about "timings", maybe the nowadays faster hardware could >>be an issue too. >> >>Making your engine auto232 compatible is a risky job, a road full of stings, >>you lay your faith in the hands of a fragile master-slave protocol. Bugs in >>the software is almost inevitable because bugs are hard to trace, if not >>impossible. When there is a bug you first have to realize there is one >>because the bug is invisible as in the Rebel case and it took me years to >>realize it and then proof it, which was a story of its own. >> >>To be complete, I don't believe a word of some critical voices who suggest >>deliberate manipulation by producers to get an unfair advantage. Auto232 may >>crash all the time in won/lost or draw positions, it is just random. If there >>are bugs this is not deliberate, it just comes with the nasty protocol you >>are trying to control in which you never will succeed in a 100% successful >>way. >> >>2 hurrays for auto232 as 3 is too much. >> >>Ed >> >> >> >>>pete > > >To me, auto232 pales when compared to the winboard system. I have been using >xboard/winboard to play matches for _years_ and have _never_ had to deal with >introducing delays, varying the delays depending on whether or not I am probing >endgame databases, etc. I have had bunches of problems implementing xboard/winboard protocol. I'm not saying the protocol is bad, but basically winboard protocol is a CONSOLE protocol. It works perfect for console engines. It has no error correction or whatever build in. Using this to communicate between 2 machines would be a disaster without a proper way of shipping commands. Remember, hardly anyone with 2 or more computers has a network, even though it costs nothing nowadays. People simply can't install it! They can however put a nullmodem cable between 2 computers. No problems there. The auto232 protocol is very easy, but it has of course serious flaws if you look to it in a theoretic way. From practical viewpoint it's very good for slow level matches. Winboard protocol would already fail here as it would set both computers at the same level for example, where definitely most persons have different speed computers! The basic idea of the auto232 protocol is that you just ship a move to it and get moves from it. Also starting a search command. That's it. So the principles of it are VERY EASY. The biggest part of the protocol is how it ships things to the other computer. I DON'T DOUBT THERE ARE BIG IMPROVEMENTS POSSIBLE THERE. Especially under NT 4.0 i couldn't get the chrilly auto232 player to work! Note it said in header file: "auto232 for win95,98". So it's incompatible, it's a big pain in the ass for a lot of different things, but it's very easy to get to work, even for a beginning programmer! The winboard protocol has more commands how to adress the ENGINE. Where here you need to adress the windows INTERFACE of course. you have shit to do with the engine. You want a module that simply handles all things for you! A big problem for winboard engines for example is if i put one on computer A and one on computer B i have NO IDEA how to let them play against each other without using an auto232 player!!!!!!!!!!!!!!!!!!!!! Auto232 handles right that. Auto232 is nothing more as a small file that connects a computer A to a computer B. The command set to ship is of course very small but sufficient. it ships the move basically, that's it. In DOS the auto232 player was even easier. Just write and read from the parallel port!! So definitely auto232 is a bit outdated when looking to the possibilities nowadays, but it works more than ok. >Some of the auto232 ideas were definitely neat. Grabbing a chess move by >watching video RAM. Sending it over an RS232C port. But Jesus, this can be >done without making it highly sensitive to various timing issues. Without doubts the way in which both programs communicate can be done better. Also the implementation of chrilly is eating loads of system time at startup. My complete interface is parallellized by just that auto232 thread (if it's a single cpu computer). Also i would like to have something that works in both win2000, NT, 98, ME and 95. Linux is no big deal as crafty can be loaded as winboard engine anyway. >I will certainly say one thing. Anybody that writes code with that many timing >holes had better _never_ try to write a parallel chess engine. It will _never_ >be debugged with those kinds of critical design flaws included. Here we agree completely. >Writing code to handle asynchronous events is not difficult. In fact, if I >were trying to write a driver that misbehaves as badly as auto232, I really >would not know where to start. It would be very hard for me to write code >that fails or works depending on lots of random timing considerations. > >So conceptually, yes auto232 is great. But its implementation sucks with two >straws. :) That's just implementation level and protocol level. The basic idea is that you link a C file to your interface and you only cut'n paste in WndProc() handler a few catches of auto232. So linking a C file and adding 10 lines of C code you can already start using auto232 player. This basic concept should NEVER be changed. Of course recognizing more commands would be cool, but the bottom line remains the same! On the other hand the winboard protocol is simply STEERING the engine, which is a bad idea IMHO, as i get all kind of stupid commands which are useless like 'hard' 'white' (though it is already white to move) and all kind of silly commands. Like adjusting time a millisecond though we have plenty of time left to play the game, why adjust time already then? Even worse, why adjust time every move? then the weird ? command in winboard. i still wonder what it is doing. is it forcing a move or is it asking for a move or is it stopping search? Further i miss also the current line. I always show every second a current line of what diep is seraching now. On the other hand if i debug winboard protocol using winboard.debug from other engines, then after a while it is loaded with all kind of nodes a second data! So there are flaws in both protocols obviously, both aren't bugfree nor doing what we want to the full extend. Basic thing is that auto232 practically works perfectly. Yet the few 'features' it has like shipping a save game command, those are already commercially exploited! Then there are the weird chessbase commands. Well it's their right to communicate between their engines all kind of secret information, that's none of my business. But it gives me a bad feeling that when i play 2 chessbase interfaces against each other that they share with each other secret information. Vincent
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.