Author: Robert Hyatt
Date: 07:54:38 03/29/01
Go up one level in this thread
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. 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. 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. 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. :)
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.