From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: CoreWars source code Date: 1 Apr 1994 03:46:49 GMT Message-ID: <2ng5f9$fq2@agate.berkeley.edu> Ramon Turner wrote: >Does anyone know of an ftp site or an email address where I can get or request >source code for a CoreWars environment? I would prefer the C or C++ languages >over anything else, but anything will do. Thanks in advance for any replies. The best would probably be /pub/corewar/systems/pmars04s.tar.Z, by anon ftp to soda.berkeley.edu. This simulator is written in portable C and supports the '94 standard. There are a couple of others (also on soda) and if you would like one of those, email me or post here. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Core War for Windows Message-ID: <1994Apr1.043631.22460@news.vanderbilt.edu> Date: Fri, 1 Apr 1994 04:36:31 GMT In article <9403301957.AA62291@rs6000.baldwinw.edu> brem@rs6000.baldwinw.edu writes: >Now available for Windows 3.1 users is a Core War simulator compliant with >the '88 Standard (it's shareware). [...] First impressions about "Corewar for Windows": It looks nice and is very easy to use. The core uses the same symbols for core updates and execution however. There is no core disassembly or debugger. As expected for a Windoze program, execution is slow. The assembler accepts both "modern-style" warriors with comma between operands and "pre-net" warriors. You can load a variable number of warriors into core. Shareware registration is $35.00, a bit steep considering the abundance of good and free simulators. You cannot change the settings in the unregistered version. With its default settings of coresize=8000 and maxtasks=64, the program is crippleware because it is incompatible with either ICWST or net standards. Interestingly, the registered version allows you to switch between in-register and in-memory evaluation. The latter is default, so I couldn't run validate.red to test ICWS'88 compliance. It ran the few KotH programs I presented to it without apparent problems however. In summary, this simulator may appeal to the corewar novice and is commendable for bringing ICWS'88 compatible corewar to the Windows gaming community. Its lack of debugging tools and insufficient speed makes it unsuitable for serious warrior development though. -Stefan (stst@vuse.vanderbilt.edu) From: richard@thegate.hacktic.nl (Richard van der Brugge) Subject: Re: A tutorial full of code Message-ID: <040194214432Rnf0.77b9@thegate.hacktic.nl> Date: Fri, 01 Apr 1994 21:44:00 GMT morrell@math.utah.edu (Steven C. Morrell) writes: >To give the reader a sense of how effective each program is, I would >also like to submit all of these sample programs to the Intel Hill. >Does anybody object? No, excellent idea! __________________________________________________________________________ Richard van der Brugge | BEWARE : I smoke and i use PGP, this makes richard@thegate.hacktic.nl | me a criminal in The Netherlands and the USA -------------------------------------------------------------------------- From: cs421hale@envmsa.eas.asu.edu (NEUMANN) Subject: decompress question Message-ID: <1APR199415055344@envmsa.eas.asu.edu> Date: Fri, 1 Apr 1994 22:05:00 GMT I would like to look at the tutorials but they all have the .Z extension and I don't have the uncompress program. I also can't remember what it is called. What is the name of this 'unzip' program and where can I get it. Thanks. Looking forward to the up coming tutorial. Robert Hale aurgh@acvax.inre.asu.edu I do have FTP access. From: mmajorow@news.delphi.com (MMAJOROWICZ@DELPHI.COM) Subject: Re: A tutorial full of code Date: 1 Apr 1994 22:13:27 -0500 Message-ID: <2ninsn$rve@news.delphi.com> ----- It seems that everyone wants a corewar tutorial that shows how incresingly complex warriors run. Well... Okay, I will write one. ----- I would like to see a set of "benchmark" redcode programs that a person could judge their warriors against. Maybe even sets of programs with different levels of difficulty. A novice has no idea how to choose a good set of programs to test their warrior against. Mike Majorowicz From: mmajorow@news.delphi.com (MMAJOROWICZ@DELPHI.COM) Subject: More on beginner's hill Date: 1 Apr 1994 22:29:45 -0500 Message-ID: <2nior9$stb@news.delphi.com> I've been giving some thought to the idea of a beginners hill. I doubt this is a practical idea, but I thought I'd toss it up anyway. The biggest problem I see with a beginners hill is how to prevent it from becoming a spot for the top ten programs to get pushed of the regular hill. A solution to this problem may be to test a warrior against the current warriors from the regular hill first, and only allow warriors that score below 80% of the lowest score on the regular hill be submitted to the beginners hill. To prevent stagnation due to fluctuations in the scores on the regular hill, the top warrior on the beginners hill could be automatically resubmitted once a week. People with warriors on the regular hill should be automatically excluded from the beginners hill. If it turns out to be popular, you could even have different levels of beginners hills, ie: a 60% hill, a 70% hill, etc. Mike Majorowicz From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: More on beginner's hill Date: 2 Apr 1994 04:37:49 GMT Message-ID: <2nisqt$41d@agate.berkeley.edu> MMAJOROWICZ@DELPHI.COM wrote: >The biggest problem I see with a beginners hill is how to prevent it from >becoming a spot for the top ten programs to get pushed of the regular hill. Do you mean "a spot for the top ten programs which got pushed off the regular hill," i.e. people whose programs didn't make it onto the real hill would submit them to the beginner's hill instead? If so, I don't really think that it would be a problem -- I think that most people know whether they are "beginners" or not. And if some program does too well on the beginner's hill, we can kill it (automatically) and submit it to the real hill (see below). >A solution to this problem may be to test a warrior against the >current warriors from the regular hill first, and only allow warriors that >score below 80% of the lowest score on the regular hill be submitted to the >beginners hill. [...] This sounds like it would put rather a lot of load on the server, testing every program against two hills. How about any program that does well on the beginner's hill is automatically removed after (say) two weeks and submitted to the regular hill. This would effectively prevent the beginner's hill from being overrun with good programs, which after all is the point (so that beginners have a chance to get on). >People with warriors on the regular hill should be automatically excluded >from the beginners hill. Of course. As I said, I think people know if they qualify as beginners. >If it turns out to be popular, you could even have different levels of >beginners hills, ie: a 60% hill, a 70% hill, etc. Hmmm. IMHO, that's a little much -- after all, one hill has 20 spots, and if good programs are routinely killed and submitted to the regular hill, then there really wouldn't be much stagnation or anything... no, I think that one beginner's hill would be enough. Also, some general thoughts about a beginner's hill: I'm not so sure that it would be a good idea in the first place. I remember when I was just starting to write corewar programs, I had a really horrible program (which of course had taken lots of work, etc.) which I submitted to the hill with grand hopes, and I was rather harshly disillusioned when I got the results back :-) But maybe this is good. After all, if I had submitted that program to a beginner's hill and it had done well, then I would have tried to improve it and make it as good as possible. This development time would be wasted -- improving a really bad program because it did well on a beginner's hill. (As a matter of fact, the program was a really primitive version of mice, and I learned a lot by finding out that this approach had already been tried and optimized far beyond what I could have done.) So, instead of wasting my time reinventing the wheel (as I would have been inclined to do had the program succeeded on a beginners's hill) I scrapped the program and tried other approaches, reading tutorials, etc. and finally produced a program which made it onto 19th place on the hill or thereabouts. But the point is, if my program had gotten onto a beginner's hill, I think I would have spent less time figuring out what I had done wrong. Invention stops with success. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: devink@tartarus.uwa.edu.au (Devin Kilminster) Subject: Re: More on beginner's hill Date: 2 Apr 1994 13:06:33 GMT Message-ID: <2njqkp$7c5@styx.uwa.edu.au> Michael Constant (mconst@soda.berkeley.edu) wrote: : which made it onto 19th place on the hill or thereabouts. But the point is, : if my program had gotten onto a beginner's hill, I think I would have spent : less time figuring out what I had done wrong. Invention stops with success. This is a very good point. However it must be said that another thing that stops invention dead in it's tracks is failure after failure - when your program is able to get onto hill it is very encouraging. So rather than a beginner's hill, maybe we need a hill that is easy to get onto (so one can make ones mark) but still represents a wide range of difficulty, so that reaching the top is a real acheivement. Perhaps a way to do this would be to limit each player to only one warrior at a time - everyone would have their best warrior on the hill and people would be able to see where they stand. Devin Kilminster. From: bdthomse%peruvian.cs.utah.edu@cs.utah.edu (Brant Thomsen) Subject: The '94 Warrior Date: 2 Apr 94 13:48:59 MST Message-ID: <1994Apr2.134900.8347@hellgate.utah.edu> __ __| | ) _ \ | | \ \ / _) | __ \ _ \ / ( | | | \ \ \ / _` | __| __| | _ \ __| | | | | __/ \__ |___ __| \ \ \ / ( | | | | ( | | _| _| |_|\___| _/ _| \_/\_/ \__,_|_| _| _|\___/ _| April 2, 1994 Issue #5 ______________________________________________________________________________ This newletter covers the current status of the ICWS '94 Draft hills, and also attempts to keep up with the latest ideas in how the new standard will affect corewars in general. I hope you enjoy it! If you are unfamiliar with the '94 draft standard, you can learn more about it by reading the FAQ for this newsgroup. In addition, the program pMARS includes a highly recommended tutorial on the new standard. Feel free to send me e-mail if you have any difficulty finding either of them, if you need to have a corewar item mailed to you, or if you have any other questions. The FAQ is available through anonymous FTP to rtfm.mit.edu, as /pub/usenet/news.answers/games/corewar-faq.Z ______________________________________________________________________________ The ICWS '94 Draft Hill: Core size: 8000 instrucitons Max processes: 8000 per program Duration: After 80,000 cycles, a tie is declared. Max entry length: 100 instructions The current ICWS '94 Draft hill: # %W/ %L/ %T Name Author Score Age 1 42/ 31/ 27 Killer instinct Anders Ivner 154 10 2 38/ 24/ 38 NC II Wayne Sheppard 153 65 3 38/ 25/ 37 Sphinx v5.1 W. Mintardjo 150 68 4 32/ 22/ 46 ttti94 nandor sieben 143 16 5 43/ 44/ 13 Fire Storm v1.1 W. Mintardjo 142 71 6 34/ 27/ 40 JustTakingALookSee J.Layland 141 64 7 31/ 22/ 47 ttti nandor sieben 140 21 8 40/ 42/ 17 Sylvester v1.0 Brant D. Thomsen 139 47 9 32/ 25/ 43 Twimpede/88 Jay Han 139 1 10 39/ 43/ 18 Request v2.0 Brant D. Thomsen 136 3 11 39/ 43/ 17 Ntttgtstitd Simon Hovell 136 11 12 31/ 27/ 42 Snake Wayne Sheppard 134 20 13 38/ 42/ 21 Fast Food v2.1 Brant D. Thomsen 134 23 14 38/ 43/ 19 Beholder's Eye v1.7 W. Mintardjo 132 77 15 40/ 47/ 13 Rave 4 Stefan Strack 132 4 16 40/ 48/ 12 Rave Stefan Strack 132 48 17 38/ 44/ 18 SJ-4 J.Layland 131 14 18 37/ 42/ 21 Christopher Steven Morrell 131 9 19 36/ 42/ 22 tiny J.Layland 130 45 20 39/ 49/ 13 Testing an Idea Brant D. Thomsen 128 2 21 39/ 50/ 12 Impurge 94 Fredrik Ohrstrom 127 7 It looks like the '94 draft hill has really slowed down. I would speculate that this is a result of the greatly increased amount of attention being given to the '94 experimental hill. The one new program since the last issue to make it onto the hill is Jay Han's "Twimpede/88". Congratulations, Jay, on this unique honor! ______________________________________________________________________________ The ICWS '94 Draft Experimental Hill: Core size: 55,440 instructions Max processes: 10,000 per program Duration: After 500,000 cycles, a tie is declared. Max entry length: 200 instructions The current ICWS '94 Experimental hill: # %W/ %L/ %T Name Author Score Age 1 48/ 28/ 24 Request-55440 Brant D. Thomsen 169 35 2 33/ 11/ 56 Variation A-1.a Jay Han 156 4 3 46/ 40/ 14 Kill Imps!!! Steven Morrell 152 22 4 35/ 24/ 41 CG-X IV Brant D. Thomsen 145 86 5 31/ 17/ 52 Lucky 13 Stefan Strack 144 1 6 28/ 15/ 57 Twimpede Jay Han 141 2 7 44/ 47/ 9 Rave B4 Stefan Strack 140 44 8 21/ 10/ 69 Imperfection v2.3 Michael Constant 132 29 9 36/ 40/ 24 Vanity IIx Stefan Strack 132 26 10 23/ 19/ 58 Bimper Wayne Sheppard 127 10 11 29/ 34/ 36 Night Crawler Wayne Sheppard 124 45 12 37/ 51/ 12 The Count Jay Han 124 25 13 35/ 50/ 16 Dagger v6.0 X Michael Constant 119 75 14 21/ 22/ 57 BigImps James Layland 119 95 15 18/ 20/ 62 BigImp Alex MacAulay 117 76 16 18/ 22/ 60 Skimp 127 Jay Han 113 57 17 27/ 47/ 26 Sunburst 33 Jay Han 107 65 18 10/ 21/ 68 bimp.c test Wayne Sheppard 99 12 19 11/ 22/ 67 bimp.c test Wayne Sheppard 99 20 20 5/ 26/ 70 Impale v2a James Ojaste 84 3 21 1/ 1/ 3 Lucky 13 Stefan Strack 5 7 Before I even attempt to summarize what has been happening on the '94 experimental hill, I think it would be helpful to reprint the hill as it was during the last issue. (17 Days previously.) The current ICWS '94 Experimental hill: # %W/ %L/ %T Name Author Score Age 1 53/ 12/ 35 BigImp Alex MacAulay 194 25 2 52/ 17/ 30 Imperfection v1.0 X Michael Constant 187 21 3 60/ 34/ 6 Rave 3 (55440) Stefan Strack 185 36 4 42/ 13/ 45 Skimp 127 Jay Han 171 6 5 54/ 42/ 4 No Ties Allowed Wayne Sheppard 166 41 6 51/ 38/ 10 Dagger v6.0 X Michael Constant 164 24 7 41/ 17/ 42 BigImps James Layland 164 44 8 49/ 39/ 12 Sunburst 33 Jay Han 159 14 9 44/ 31/ 25 CG-X IV Brant D. Thomsen 157 35 10 49/ 42/ 10 BS J.Layland 156 43 11 41/ 34/ 25 Iron Gate Wayne Sheppard 148 40 12 35/ 26/ 39 FatImp Jay Han 144 1 13 40/ 50/ 10 Silly 2 James Ojaste 130 7 14 41/ 54/ 5 Silly James Ojaste 129 9 15 33/ 46/ 21 testing testing Fredrik Ohrstrom 121 31 16 32/ 46/ 22 Crimp Jay Han 118 2 17 34/ 53/ 13 VJX-2a James Ojaste 115 28 18 28/ 42/ 31 Bloom Jay Han 114 12 19 30/ 50/ 20 Surprise7b James Ojaste 109 10 20 32/ 59/ 8 VJX-2 James Ojaste 105 29 Since the last issue of _The_'94_Warrior_, 51 new programs have made it onto the hill -- this is 3 new programs a day. Of the first 12 programs on the hill, only one was on the hill during the last issue. More programs have been submitted in this period than in the entire life of the hill previously. (Are you getting the point yet?!) Perhaps the most surprising thing about the current standings on the hill is the amount of diversity there is between the warriors. Scanners, stones, and imp-spiral combinations are all well represented. In fact, the warrior currently at the top of the hill is a vampire. (Certainly not what I would have predicted.) It looks as if this is the hill where the excitement is! ______________________________________________________________________________ HINTS and HELPS: To assist program development on the '94 experimental hill, I have used Michael Constant's "Optima" program to calculate the twenty most-efficient step-sizes for mods 1 to 10. (A mod 1 step-size will eventually cover every location in the core, a mod 2 step-size will eventually cover one-half of the locations in the core, etc.) Notice that there is a bug in the version of "Optima" released last year. A quick fix is to make the variable "i" in the function "opt" long instead of short. An easier fix will be to wait until Michael releases the next version. This bug only makes itself known when using a large coresize and a large step size. In fact, it was due to this bug that I ended up using a step-size of 9719 in the 55440 coresize version of Request -- it was the best mod 1 step the program could find. [The source code for Request-55440 will probably be included in the next issue. I figured the following tables would be more useful given the current number of programs being submitted to the '94 experimental hill. Also, there are a couple of points about program development I am finishing up for a future hint, and "Request" will be good example to use for them.] Results of running "Optima" on a 55440 size core: Mod 1: 16211 6.183968 23269 6.183968 15481 6.132795 16921 6.132795 22889 6.113332 24151 6.113332 16369 6.065658 21649 6.065658 12689 6.056693 15611 6.056693 20509 6.056693 21151 6.056693 20617 6.052941 22873 6.052941 12503 6.048468 16393 6.048468 16817 6.045978 21247 6.045978 9719 6.028265 23399 6.028265 Mod 2: 16238 11.586204 20498 11.477182 21502 11.477182 22766 11.439446 23266 11.439446 15458 11.393845 16462 11.393845 12718 11.343555 23278 11.343555 11974 11.340597 20474 11.340597 15314 11.325805 22706 11.325805 16894 11.307190 23234 11.307190 20546 11.242397 21074 11.242397 20458 11.233378 24422 11.233378 20558 11.232151 Mod 3: 24357 16.517452 21381 16.368905 22971 16.368905 14907 16.340657 20373 16.340657 21057 16.330429 22503 16.330429 14691 16.305265 15261 16.305265 19461 16.144705 20571 16.144705 24483 16.085124 16473 16.023107 20607 16.023107 16827 16.003463 22773 16.003463 9687 16.002976 23007 16.002976 19911 15.997132 23439 15.997132 Mod 4: 22964 22.001587 20996 21.523631 24356 21.523631 17228 21.204705 24148 21.204705 22756 21.191717 23476 21.191717 15548 21.175265 22892 21.175265 20068 21.112923 23228 21.112923 24196 20.981312 23404 20.955336 20476 20.869038 23924 20.869038 16508 20.834981 23428 20.834981 21508 20.811025 22508 20.811025 12988 20.771196 Mod 5: 21445 26.052133 23435 26.052133 9865 25.878055 21215 25.878055 24175 25.794624 24905 25.794624 12115 25.712546 21485 25.712546 16265 25.675566 22735 25.675566 11785 25.657527 16465 25.657527 20315 25.560566 24875 25.560566 16925 25.451881 24125 25.451881 9965 25.415351 21475 25.415351 9925 25.400469 15445 25.400469 Mod 6: 16134 31.110510 21174 31.110510 15234 30.829960 21486 30.829960 21246 30.807230 20994 30.786449 16374 30.408486 14946 30.113649 19986 30.113649 19938 29.889598 21522 29.889598 17142 29.831800 24198 29.831800 16194 29.815564 24834 29.815564 20298 29.745427 24762 29.745427 20058 29.643468 21642 29.643468 17382 29.622686 Mod 7: 16373 35.304963 21427 35.304963 21007 35.243086 24367 35.243086 20041 35.102538 21049 35.102538 24157 34.939891 24997 34.939891 21623 34.906301 24983 34.906301 23429 34.649956 25459 34.649956 17129 34.616366 21161 34.616366 15043 34.480237 21077 34.480237 20293 34.479353 22547 34.479353 14651 34.413057 24899 34.413057 Mod 8: 12104 39.494299 24184 39.494299 20344 39.289941 21256 39.289941 15272 39.236831 21752 39.236831 16232 39.235676 22952 39.235676 19864 38.698802 20296 38.698802 20456 38.686102 25064 38.686102 13144 38.587964 23384 38.587964 24424 38.525617 25096 38.525617 16024 38.514071 16904 38.514071 23416 38.514071 24296 38.514071 Mod 9: 12087 44.316123 21177 44.316123 14967 43.623478 24903 43.623478 21141 43.594252 21501 43.594252 20961 43.468583 21519 43.468583 16983 43.337068 22887 43.337068 11997 43.281539 21627 43.281539 14841 43.227472 22761 43.227472 19647 43.107647 21663 43.107647 16749 42.900146 24309 42.900146 16461 42.870921 24219 42.870921 Mod 10: 19990 48.630705 21050 48.630705 21470 48.029948 22930 48.029948 16210 47.889230 24830 47.889230 16910 47.670936 24130 47.670936 13150 47.441819 23230 47.441819 9970 47.376872 22910 47.376872 15350 47.310121 22790 47.310121 12490 47.265019 19930 47.265019 21430 47.061158 23930 47.061158 16930 47.021469 19330 46.691322 ______________________________________________________________________________ Looking to the Future: The lastest draft of the standard has been on soda.berkeley.edu for a couple of months now (as /pub/corewar/documents/icws94.0202.Z). Take a look at it and let the newsgroup know what you think. There are some interesting additions to the former '94 draft standard, so it's worth your effort to get a copy and study it. Also, please submit your programs to the '94 hills. We'd love to have your best KOTH warrior on the standard '94 hill, even if it is still '88 compliant. If you have any comments or questions about the '94 hills or the '94 standard that you think might be of general interest, please let me know. Good luck, and happy computing! ______________________________________________________________________________ Brant D. Thomsen, Editor Snail mail: 1197 East 6290 South (bdthomse@peruvian.cs.utah.edu) Salt Lake City, UT 84121 University of Utah U.S.A. -- Brant D. Thomsen Man will occasionally stumble over the truth, (bdthomse@peruvian.cs.utah.edu) but most times he will pick himself up University of Utah and carry on. - Winston Churchill From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: More on beginner's hill Date: 2 Apr 1994 20:39:51 GMT Message-ID: <2nkl6n$4d4@agate.berkeley.edu> Devin Kilminster wrote: >So rather than a beginner's hill, maybe we need a hill that is easy to >get onto (so one can make ones mark) but still represents a wide range of >difficulty, so that reaching the top is a real acheivement. > >Perhaps a way to do this would be to limit each player to only one >warrior at a time - everyone would have their best warrior on the hill >and people would be able to see where they stand. Do you mean that the regular hill would only allow one warrior per person? This is bad because it would discourage invention -- if I would have to kill off my standard mediocre program to test a new strategy, I might be more inclined to just improve my standard program and forget about the new strategy. However, a "beginner's" hill (we would need a new name) where anyone could submit one and only one warrior would be a good idea, IMHO. It would represent a wide range of standard, tested, warriors and but would give new people a chance to get on. Unfortunately, it could get to the point where the "beginner's" hill was just as overrun with really good warriors as the regular hill, and so our poor J. Random Corewarrior will be doubly disappointed when he can't make it onto *either* :-( Maybe the best idea would be not a new hill but better tutorials (like the proposed "tutorial full of code"). With enough help, even the newest of newbies should be able to write a 20th place program. And this would have the advantage of not encouraging development of useless, old-fashioned programs (see my last post on this thread). Any other ideas, anyone? -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: stormking.com server update Message-ID: <1994Apr2.231359.28721@news.vanderbilt.edu> Date: Sat, 2 Apr 1994 23:13:59 GMT I am about to update the stormking.com server with pMARS v0.5, which features three new experimental opcodes by popular request: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal (its antipode) NOP - do nothing v0.5 will be uploaded to soda as soon as we finish with some new debugger features; watch for an announcement here. This server update would be a good moment to also change the hills over to "deterministic mode" by adding the -f or -F nnn switches as discussed previously. The "nnn" would be changed approx. once per month. Please mail me if you prefer a) the way it's been so far, b) -f, or c) -F nnn, so Scott can implement the majority preference. -Stefan (stst@vuse.vanderbilt.edu) Date: Mon, 4 Apr 1994 00:11:41 MST From: Message-ID: <94094.001141AHNAS@ASUACAD.BITNET> Subject: Re: Newbie questions! mars88 doesn't like unix style end of line charachters. The dos edit program solves this problem. Nandor. From: ehpharr@whale.st.usm.edu (Eugene Houser Pharr) Subject: More on beginner's hill Date: 4 Apr 1994 10:09:13 -0500 Message-ID: <2npaip$3638@whale.st.usm.edu> How about a "Practice" hill(s). Practice hills would accept submissions send results but not actually admit new warriors. Each practice hill would have a selection designed to test specific characteristics. For instance: Avamp Hill - loaded with avamp using opponents ranging from weak to deadly. Useful for testing the durability of vamp warriors. Stone Hill - loaded with a variety of "bomb the heck out'a them" warriors. Paper Hill - "prepare to be papered!" ... etc. The ability to test a program against all of the various imp approaches could be very useful in gate perfection; or Whatever.... And of course, one hill could feature the ICWS annual champions.... Just a thought Gene Pharr (BTW - would doing all this in the '94 dialect be to much to ask?) :-) -- ``` | Sometimes Known As: | "Don't mind me, I'm just (o o) | genep@ndbc.noaa.gov | passing through." -- --oOO--(_)--OOo--| and/or Eugene H. Pharr, Jr. | Dave Letterman From: bcohen@acsu.buffalo.edu (Bram Cohen) Subject: need help debugging Message-ID: Date: Mon, 4 Apr 1994 19:36:37 GMT Here's some code which I don't think works but it's hard to tell since pmars doesn't have an option for passively viewing an ongoing battle (at least none that I'm aware of. If you know of a way of doing that easily under UNIX *please* let me know about it. The pmars debugger is great, BTW.) splbomba SPL 0,#splbombb-artillery splbombb SPL 0,#datbomb-artillery datbomb DAT #0,#splbomba-artillery bomb MOV @artillery, Date: Mon, 4 Apr 1994 21:28:38 GMT In article bcohen@acsu.buffalo.edu (Bram Cohen) writes: >In article <1994Apr2.231359.28721@news.vanderbilt.edu>, >Stefan Strack wrote: >>I am about to update the stormking.com server with pMARS v0.5, which >>features three new experimental opcodes by popular request: >> >[snip] >>NOP - do nothing >> > >Why not just let people use JMP 1 ? This was discussed here not too long ago. The argument of the NOP proponents was that NOP with two operand increment/decrement could be useful in imp-gates. I am adding support for these three opcodes so we can find out whether they are worth including in the standard draft. (I don't like NOP much myself, although I can see uses for SNE). -Stefan (stst@vuse.vanderbilt.edu) From: morrell@math.utah.edu (Steven C. Morrell) Subject: Chapter 1 beta-release is ready Date: Mon, 4 Apr 1994 21:41:54 GMT Message-ID: Okay, corewar fans. Chapter 1 is done and available for your inspection via anonymous ftp to soda.berkeley.edu as /pub/corewar/incoming/chapter1. I am waiting to do all of the KOTH fighting until I have everything written so that all programs attack the same hill. I would also like submissions and names of warriors that I can use. My last posting seemed to scare everybody away, so my new policy is send in whatever you want. I mentioned that you would be responsible for sending out your code if it wasn't archived. This is just because I am leaving the University of Utah in June and won't be able to be a file server for long. You will still be responsible for supplying code. Be sure to send me comments -- four warriors on the Intel KOTH with the "verbose" command just aren't sending me enough mail! Steven Morrell morrell@math.utah.edu From: morrell@math.utah.edu (Steven C. Morrell) Subject: Montage Date: Mon, 4 Apr 1994 22:22:43 GMT Message-ID: Here is the code for Montage, my first real attempt at an imp-stone combo. The most important contribution this program makes is that it has a new stone in it. I had a tough time deciding whether I wanted gate-breaking imps or 7-pt imps, so I just put both of them in. The gate-breaking imps are closer together than in Cannonade, making them less vulnerable to SPL bombs but more vulnerable to imp-traps. (Imp traps? I forgot to mention them in chapter 1. OH NO!!!) The stone is a mega-self-splitting stone that's a bit bigger than Extra-Extra, but maybe a little more durable because it has 2 SPL 0's. It bombs core with a mod-1 pattern until it hits itself, at which time it runs a subtraction core-clear. After that, mostly for cosmetic purposes, it jumps to an imp-gate. Of course, by that time, any free imps should have overrun everything, so I'm not sure it's worth the extra cycle to plant the imp-gate. ;redcode verbose ;name Montage ;kill Montage ;author Steven Morrell ;strategy Stone and a bunch of imps and an imp gate. p1 equ boot+300 p2 equ boot+302+2667 p3 equ boot+303 p4 equ boot+400 stone spl 0,<-50 spl 0,<-51 mov <3359,-3359 add 2,-1 djn -2,<-54 dat <3359,<-3359 imp1 mov 0,2667 imp2 mov 0,2668 imp4 mov 0,1143 gate jmp -3359,<3359-10 boot mov stone+5,-200+5 mov stone+4, Message-ID: <94094.224959AHNAS@ASUACAD.BITNET> Subject: optima I'm a little bit suspicious about the optima numbers for 55440 in the 94 warrior. The optima numbers usually occure in pairs and for mod 4 the best number 22964 does not have a pair with the same optima value. Since nobody proved this conjecture the numbers can be right as well. Speaking of conjectures I'd like to encourge people to try to prove my other conjecture, namely that the optima numbers are the same as the smallest average biggest unbombed area numbers ( program for this was posted a while ago ) . Nandor. From: rschuler@iastate.edu (Rodney Schuler) Subject: Re: stormking.com server update Date: 4 Apr 1994 23:01:36 GMT Message-ID: <2nq68g$bsu@news.iastate.edu> In article <1994Apr2.231359.28721@news.vanderbilt.edu>, >Stefan Strack wrote: >[snip] >>NOP - do nothing >> >Why not just let people use JMP 1 ? Because, sometimes you need the A-field to hold some useful data. From: mconst@soda.berkeley.edu (Michael Constant) Subject: Optima v2.1 Date: 5 Apr 1994 02:42:18 GMT Message-ID: <2nqj6a$i66@agate.berkeley.edu> Optima v2.1 is now on soda.berkeley.edu in /pub/corewar/incoming; optimapc.exe (self-extracting) for PC users, or optima.shar for everyone else. The only difference from v2.0 is a bug fix (credit to Brant for both the bug report and the subsequent fix! Thanks!). v2.0 would crash trying to calculate mod-1 numbers (or mod-2 if the coresize is big enough) where the step size was bigger than 65535-coresize; this is fixed by changing i (in opt()) to be long instead of short. Everyone using Optima v2.0 should probably upgrade; this bug tends to manifest itself rather often. Of course, everyone *not* using v2.0 is lower scum than ever walked the face of the earth^Ushould get a copy immediately; this program will make your corewar development *much* easier. If you're unsure on what it actually does and why you need a copy, please mail me! -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mchapman@isle.waterloo-rdp.on.ca (M.Chapman) Subject: Re: Corewar System for BBS? Date: Tue, 5 Apr 1994 15:21:26 GMT Message-ID: <1994Apr5.152126.1003@isle.waterloo-rdp.on.ca> Stefan Strack (stst@vuse.vanderbilt.edu) wrote: : In article cs018226@hkpu01.hkp.hk (Kevin Lam) writes: : >Hi all, is there any BBS door program such that a PC-based BBS can : >run as a corewar server? : > : >Best wishes, : >Kevin. : Not that I am aware of. A good start for writing your own would be to take : a look at my mts.c (in soda.berkeley.edu:/pub/corewar/systems/pmars04s.zip), : a round-robin scheduler that works with pmars, mercury2 and other corewar : systems. : Tell me what you need for a BBS door and I can probably add a KotH server mode : to mts by the next release of pmars. : -Stefan (stst@vuse.vanderbilt.edu) well.. so far my friend and i have started to right a door for RA BBS. we have ity setup so the user ul's there warrior and can choose to put it on the hill or fight someone rightaway or wait for the 2am tourney. we used mts.c , pmars(the one at berkely) and good old BC++ 3.1 ... if we get it to work right (for a change) i'll see about getting it out there.. (I may end up uuendcoding it here .. or mayhaps mail it to someone with ftp access) .. -- | Tass Chapman | m.chapman@ieee.org | FIDO 1:221\403 | | Conestoga College- Elec' Tech' Eng. Telecommunications | | Kitchener Ontario Canada | "OOPS... I guess that's not a thing conductive to a long life." From: sd@ecst.csuchico.edu (Bruno Puntz Jones) Subject: New KotH Server Now Available! Date: 5 Apr 1994 17:49:03 GMT Message-ID: <2ns8afINNmop@charnel.ecst.csuchico.edu> Yes, that's right, there's a new hill on the block! Right now the Internet Pizza Server KotH corewar simulator is only up for beta-testing, but it should be healthy enough to handle most anything. If all goes well, the hills should be up and running properly within a few days. So submit your warriors today! First 20 customers guaranteed a place on the hill! :) To submit your corewar programs to the Pizza Hill, simply mail them to pizza@ecst.csuchico.edu with the subject of "redcode" or "koth". Due to the variety of services the Internet Pizza Server provides, your mail _must_ have a subject of "redcode" or "koth" or you will recieve an error message. This is easily done with the -s switch in most mailers. For example, if you usually used the command: "cat test.red | mail koth@stormking.com" to submit the same program to the Pizza Hill, you would use the command: "cat test.red | mail -s 'redcode' pizza@ecst.csuchico.edu" It's as simple as that. I am looking for input on the ICWS'88 Experimental hill. The most interesting idea I could think of is listed below, but I'm looking for better, more permanent ideas. Also, any ideas on the beginner's hill would be appreciated as well. Bug reports, ideas, and anything else you want to tell me should be mailed to sd@ecst.csuchico.edu, or to the Pizza Server with the subject of "bugs". and now, here are the specs of the various hills: ICWS'88 Standard Hill Specs: (Accessed with ";redcode") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '88 ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x") coresize: 4096 max. processes: 32 duration: after 65,536 cycles, a tie is declared. max. entry length: 64 minimum distance: 64 instruction set: ICWS '88 ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 maximum age: At age 100, warriors are retired. instruction set: ICWS '94 Draft ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x") coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: ICWS '94 Draft -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~\/~~\ /~~~\/\ / \ \ / /~\ /~~~YY~~~\\ /~~~~ Thomas H. Davies V \/\ /\ V / V |\/\/| V\ / sd@ecst.csuchico.edu "Hard before beer, V \ / | / | V you're in the clear; \/ | /\ | Member C.W.M. beer before hard, Motto of |/oo\| Since 1987 you're in the yard." Chico State |/\| Date: Tue, 5 Apr 1994 18:16:32 MST From: Message-ID: <94095.181632AHNAS@ASUACAD.BITNET> Subject: Re: optima I run my optima calculator program and I got the same numbers. So it seems that optima numbers are not in pairs :-( This is curious. Nandor. From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: optima Date: 5 Apr 1994 21:18:35 GMT Message-ID: <2nskjb$5rs@agate.berkeley.edu> In article <94094.224959AHNAS@asuacad.bitnet>, wrote: >I'm a little bit suspicious about the optima numbers for 55440 in the >94 warrior. The optima numbers usually occure in pairs and for mod 4 >the best number 22964 does not have a pair with the same optima value. >Since nobody proved this conjecture the numbers can be right as well. I think that this is simply a false conjecture. Certainly it is true for *many* numbers but it's obviously not true in extreme cases (eg. coresize 8000, mod 1000 -- the best number is 3000 == 5000 but there are no others). I think that 55440 mod 4 is just another one of these cases. However, it would be interesting to prove which numbers Nandor's conjecture holds for, because it certainly works a lot of the time. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: New KotH Server Now Available! Date: 5 Apr 1994 23:45:10 GMT Message-ID: <2nst66$92a@agate.berkeley.edu> Bruno Puntz Jones wrote: >Right now the Internet Pizza Server KotH corewar simulator is only up for >beta-testing, but it should be healthy enough to handle most anything. If >all goes well, the hills should be up and running properly within a few days. Sounds great! This means we'll have 3 hills... maybe the rather outdated Intel hill is ready to go... I don't know if we really need so many. >I am looking for input on the ICWS'88 Experimental hill. The most interesting >idea I could think of is listed below, but I'm looking for better, more >permanent ideas. Counting that the '88 standard is being phased out anyway, maybe we don't really need an '88 experimental hill. I think that people's corewar development should be turned instead towards '94 and (especially) '94-x. >Also, any ideas on the beginner's hill would be appreciated as well. Well... not like I'm flaming it or anything, but it seems to me that your specs for a beginner's hill are going against the opinion of the masses on rec.games.corewar. If I remember correctly, most of the people expressing opinions were *against* having a specific age-limit for beginner's hill warriors. In fact, I don't know if people in general want a beginner's hill at all; I personally like 's idea of a beginner's "hill" which would let you submit programs to it, and would battle them against several examples each of stone, paper, scissors, imp, vamp, anti-vamp, etc., and report the scores (so you can see what areas your program could stand improvement in), but not actually put your program onto the hill. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Optima v2.2 Date: 6 Apr 1994 00:27:36 GMT Message-ID: <2nsvlo$a14@agate.berkeley.edu> James *would* tell me about another Optima bug right *after* I'd released Optima v2.1... :-) Anyway, there's another bug fix and another version increase, and another reason for you to get your very own copy of Optima from soda. If you don't have the filenames memorized by now, mail me. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Optima v2.2 Date: 6 Apr 1994 00:38:33 GMT Message-ID: <2nt0a9$a7u@agate.berkeley.edu> Oh, I forgot to say, this bug fix applies only to Unix users. If you have the PC version you don't need it (but if you didn't get v2.1 then you should get v2.2 because the v2.1 bug fix *does* apply to you). -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y Date: Wed, 6 Apr 1994 01:18:51 MST From: Message-ID: <94096.011851AHNAS@ASUACAD.BITNET> Subject: Re: optima I tried Michael's optima program with coresize 8000 mod 4 and I got 3516 as best number. I think this is wrong. To make it possible to compare results I uploaded optimatp.zip to soda. It contains a turbo pascal source and dos executable optima calculator program. It's about 2.5 times as fast as Michael's program ( at least for coresize 8000 and mod 4 ). It's able to find the best optima number in an intervall [1,k] . For a full search k should be corsize/2 . Note that optima calculation is not the ultimate weapon, the idea is to use a program to optimize constants so everubody should have his own constant calculator program. Nandor. From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: More on beginner's hill Date: 6 Apr 1994 03:19:48 GMT Message-ID: <2nt9ok$d1r@agate.berkeley.edu> Eugene Houser Pharr wrote: >How about a "Practice" hill(s). Practice hills would accept submissions >send results but not actually admit new warriors. Each practice hill >would have a selection designed to test specific characteristics. I think this is the best beginner's hill idea so far. It's fair, it's useful to beginners, and it encourages development of good warriors. In fact, we could have veterans (voluntarily) post their best examples of the different warrior forms on the practice hill(s) (without posting the code, if they didn't want to) so that beginners would have a chance to see how their code stands up not only against standard, basic warrior forms, but against the state of the art programs in that area. As far as actual implementation goes, I would recommend a single practice hill which has a sampling of all of the basic warrior forms, say a few generic examples and a few real examples of each. The score report would include W/L/T for each opponent as well as an overall "Paper" rating, etc., and finally an overall rating. Then a beginner could see, at a glance, where his programs needed improvement. (I try not to think of myself as a beginner but I'd use a practice hill like this if we implemented it!) -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 6 Apr 1994 11:13:06 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1994/01/03 Version: 2.1.5 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 69 2. Is it Core War or Core Wars? 82 3. Where can I find more information about Core War? 90 4. Core War has changed since Dewdney's articles. Where do I get 108 a copy of the current instruction set? 5. What is this ICWS'94? 122 6. What is the ICWS? 138 7. What is TCWN? 148 8. How do I join? 156 9. Are back issues of TCWNs available? 173 10. What is the EBS? 180 11. Where are the Core War archives? 196 12. Where can I find a Core War system for . . . ? 214 13. I do not have ftp. How do I get all of this great stuff? 262 14. I do not have access to Usenet. How do I post and receive news? 269 15. When is the next tournament? 287 16. What is KOTH? How do I enter? 296 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 440 18. How does SLT (Skip if Less Than) work? 452 19. What does (expression or term of your choice) mean? 464 20. Other questions? 592 --------------------------------------------------------------------- Q 1: What is Core War? A 1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 The Redcode language has changed somewhat since; see Q 4. --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (soda.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q11) --------------------------------------------------------------------- Q 5: What is this ICWS'94? A 5: There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a post-increment indirect addressing mode and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft for more information (soda.berkeley.edu pub/corewar/documents/icws94.draft.Z). You can try out the new standard by submitting warriors to the experimental '94 KotH server (see Q16). pMARS, a corewar system that implements ICWS'94 is available at soda (see Q12). --------------------------------------------------------------------- Q 6: What is the ICWS? A 6: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). --------------------------------------------------------------------- Q 7: What is TCWN? A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 8: How do I join? A 8: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 9: Are back issues of TCWN available? A 9: Recent issues can be found on soda.berkeley.edu (see Q11). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- Q10: What is the EBS? A10: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994 (see Q 5). Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- A11: Where is the Core War archive? Q11: Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from soda.berkeley.edu (128.32.149.19) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q12: Where can I find a Core War system for . . . ? A12: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are Unix X-Window, IBM PC-compatible (sorry, no systems specifically designed for MS-Windows yet), Macintosh, and Amiga Core War systems available there. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than soda.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at soda: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-10.hqx - corewar for the Mac core-11.hqx - corewar for the Mac core-wars-simulator.hqx - same as core-11.hqx? corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z - corewar for UNIX/X-windows. This program runs the KotH server at intel.com koth.shar.Z - older version kothpc.zip - port of older version of KotH to the PC deluxe20c.tar.Z - corewar for UNIX (X-windows or curses) and PC mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible icons.zip - corewar icons for MS-Windows macrored.zip - a redcode macro-preprocessor (PC) c88v49.zip - PC corewar, textmode display mars88.zip - PC corewar, graphics mode display corwp302.zip - PC corewar, textmode display, slowish mercury2.zip - PC corewar written in assembly, fast! mtourn11.zip - tournament scheduler for mercury (req. 4DOS) pmars03s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars03s.tar.Z - same as above pmars03.zip - PC executables, graphics display version macpmars02.sit.hqx - pMARS executable for Mac ApMARS03.lha - pMARS executable for Amiga ---------------------------------------------------------------------- Q13: I do not have ftp. How do I get all of this great stuff? A13: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. ---------------------------------------------------------------------- Q14: I do not have access to Usenet. How do I post and receive news? A14: To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com ListProcessor. To join, send: SUB COREWAR-L FirstName LastName to: LISTPROC@STORMKING.COM You can send mail to corewar-l@stormking.com to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (tuc@stormking.com). Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q15: When is the next tournament? A15: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. ---------------------------------------------------------------------- Q16: What is KOTH? How do I enter? A16: King Of The Hill (KOTH) is an ongoing Core War tournament available to anyone with email provided by William Shubert (wms@iwarp.intel.com). You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail daemon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives in an hour, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. MORE ON KOTH COREWAR IMPLEMENTATION Core size: 8000 instructions Max processes: 8000 per program Duration: After 80,000 cycles, a tie is declared. Max entry length: 100 instructions Programs are guaranteed a 100 instruction block (inclusive of their warrior's instructions) without overlapping their opponent. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Rule variants for "eXperimental" corewar: The same as above but use ";redcode-x" to start your program. Your program will be entered into a second tournament with slightly different rules. The rules are: - All addressing modes are allowed with all instructions. - There is an additional addressing mode, called "postincrement". To use it try an instruction like "mov >5,6". - The maximum write distance is 250 instructions. That is, every time your program tries to modify memory, the address is checked; if it is more than 250 instructions from the process doing the modify, then memory is left unchanged, but the instruction continues as normal. - A tie is not declared until 150,000 cycles per program have elapsed. KotH runs on any Unix system with an X windows interface. The source code to KotH is available by email from William Shubert. Write to him at (wms@iwarp.intel.com) for a copy or get it by anonymous FTP from soda.berkeley.edu in the pub/corewar/systems directory (see Q12). STORMKING.COM KOTH: A second KotH server is installed at stormking.com. Send your warrior to koth@stormking.com. Since this is an UUCP site, it may take a day before you get results back. There are currently five separate hills that you can select by starting your program with ;redcode, ;redcode-x ;redcode-icws, ;redcode-94, or ;redcode-94x. ;redcode and ;redcode-x select hills with rules of the regular and experimental hills at intel.com (see above). ;redcode-icws sends your warrior to the ICWS-hill. Rules here follow that of the annual ICWS tournament, in short: Core size: 8192 instructions Max processes: 64 per program Duration: After 100,000 cycles, a tie is declared. Max entry length: 300 instructions ;redcode-94 selects the experimental ICWS'94 (see Q 5 for more on this proposed new standard). Core size, Max processes, etc. are identical to the regular hills at stormking and intel.com. ;redcode-94x selects the experimental '94 or simply "Big Hill". Here the core size is 55440, a number with many small factors, that might lead to more complex warriors. Like the '94 hill, the '94x hill supports the ICWS'94 dialect. Here all parameters: Core size: 55,440 instructions Max processes: 10,000 per program Duration: After 500,000 cycles, a tie is declared. Max entry length: 200 instructions All hills at stormking.com except for the x-hill run portable MARS, a platform-independent corewar system available at soda (see Q12). The contact person is for this server is Scott J. Ellentuch (tuc@stormking.com). Please send all bug reports, inquiries, etc. to him and me (stst@vuse.vanderbilt.edu). ---------------------------------------------------------------------- Q17: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A17: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. ---------------------------------------------------------------------- Q18: How does SLT (Skip if Less Than) work? A18: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q19: What does (expression or term of your choice) mean? A19: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, Date: Wed, 6 Apr 1994 11:30:28 GMT Hi out there. I am planning to write a simple simulator to be used in connection with testing my own corewarprograms. I plan to use it to evaluate a lot of diferent small programs against each others. I have a problem tough. mov <2,<2 What evaluates first, the source or the destination, and mov @2,<2 what in this case? Some of you experts out there must know the answer. Please give me an answer. (Post it to the newsgroup) Peter Nyman Hansen email: gammel@diku.dk From: lewin@tpr1.ftw.bnr.com Subject: Problems with new KotH server Message-ID: <1994Apr6.162308.28712@vulcan.iss.bnr.com> Date: Wed, 6 Apr 1994 16:23:08 GMT Is anyone else having problems mailing to pizza@ecst.csuchico.edu? I keep getting messages along the lines of ....timed out waiting for hairball.ecst.csuchico.edu...(approx) Anyone have any suggestions. Thanks, Karl From: jlayland@kilroy.jpl.nasa.gov (James Layland) Subject: Re: optima Date: 6 Apr 1994 16:41:16 GMT Message-ID: <2nuonc$slu@elroy.jpl.nasa.gov> In article <94096.011851AHNAS@asuacad.bitnet>, wrote: >I tried Michael's optima program with coresize 8000 mod 4 and I got 3516 >as best number. I think this is wrong. To make it possible to compare This is wrong, but I believe this should be fixed by the most recent bugfix Michael uploaded. I saw this number at one point when I tried using 32-bit ints instead of 16-bit ints in Michael's code. Using version 2.2 I get 3364 and 3044 as expected. -- James Layland jlayland@grissom.jpl.nasa.gov From: fjw2@ns1.cc.lehigh.edu (FRANK JUDE WOJCIK) Subject: Re: More on beginner's hill Message-ID: <1994Apr6.211909.162338@ns1.cc.lehigh.edu> Date: Wed, 6 Apr 1994 21:19:09 GMT I think that Michael's idea about a hill with a few samples of each warrior class is a good idea, but I have another one. Let's combine the ''we could use a beginner's hill'' and ''Let's start phasing into the '94 & '94-x standards'' ideas into one: ''Use the intel hill ('88) as a beginner's hill.'' Opinions? -- ----- Frank J. T. Wojcik "This is that thing you call sarcasm, isn't it?" fjw2@lehigh.edu -Ford Prefect in Douglas Adams' _Mostly_Harmless_ GE d- -p+ c++++ l u(++) e*() m+@ s++/++ n-@ h+() f- g+(-) w++() t+(+++)@ r !y finger fjw2@cs2.CC.lehigh.edu = C8 E8 73 86 FB DB C2 61 0D 60 23 7A EB CB 23 61 From: bcolglaz@eelpout.micro.umn.edu (Benjamin Colglazier) Subject: Re: More on beginner's hill Message-ID: Date: Wed, 6 Apr 1994 22:19:56 GMT The 'practice hill' sounds really good. I think for BEST effect though, it should have pre-chosen warriors, whose source code is made public via anonymous ftp. That way, a programmer can not only test his warrior against different levels of opponents, but he can look at their code to see why he's getting those results. It also gives novices something concrete & practical to build off of. -ben From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: More on beginner's hill Message-ID: <1994Apr6.230501.25518@news.vanderbilt.edu> Date: Wed, 6 Apr 1994 23:05:01 GMT In article bcolglaz@eelpout.micro.umn.edu (Benjamin Colglazier) writes: > The 'practice hill' sounds really good. I think for BEST effect though, it >should have pre-chosen warriors, whose source code is made public via >anonymous ftp. That way, a programmer can not only test his warrior against >different levels of opponents, but he can look at their code to see why he's >getting those results. [..] > Better yet, download those warriors and run the battles at home :-). This way, you can use your favorite debugger/core viewer to see what's really going on. Seriously though, if anyone has the time to write the scripts and the resources to run a beginner's hill, mail me and I'll send you the scripts that currently run the stormking.com hills; that might be a good starting point. >-ben -Stefan (stst@vuse.vanderbilt.edu) From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: optima Date: 6 Apr 1994 23:48:18 GMT Message-ID: <2nvho2$41i@agate.berkeley.edu> In article <94096.011851AHNAS@asuacad.bitnet>, wrote: >To make it possible to compare results I >uploaded optimatp.zip to soda. It contains a turbo pascal source and >dos executable optima calculator program. It's about 2.5 times as fast >as Michael's program ( at least for coresize 8000 and mod 4 ). In defence of my program, I think I ought to say several things: 1. Mine estimates how long the calculation will take. I hope you did not count the time it takes to make the estimate! 2. Mine sacrifices a little speed for the ability to respond to a ^C at any time, and to display a progress indicator. Nandor's doesn't respond to ^C at all, and so between no progress indicator, no time estimate, and no break capability, it's hard to tell if your computer's locked up. (note: I'm explaining why mine is slower, not trying to flame Nandor's program. It *is* faster than mine and it calculates optima numbers perfectly well. I just like mine better. ;-) 3. Nandor's program does have one speed-increasing feature that mine should, relating to the way it counts distances from the current bomb. This is not a difficult feature to add to mine, and I am updating mine even as I write this. 4. Nandor's is written in Pascal. Mine is in C. What more need be said? :-) -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y Date: Thu, 7 Apr 1994 00:11:09 MST From: Message-ID: <94097.001109AHNAS@ASUACAD.BITNET> Subject: Re: optima I was wrong again (maybe I should just shut up for awhile). Michael's program is prefectly good, though the result is not sorted which caused my confusion. Sorry about this. Nandor. From: fjw2@ns1.cc.lehigh.edu (FRANK JUDE WOJCIK) Subject: Re: New KotH Server Now Available! Message-ID: <1994Apr7.045601.105487@ns1.cc.lehigh.edu> Date: Thu, 7 Apr 1994 04:56:01 GMT Umm, there seems to be a small bug in this hill. I can't kill off any of my programs. There are now about 5 of them up there at least. To whomever it may concern, I only want Zipper v0.3 up there - please kill the rest. Thank you much. -- ----- Frank J. T. Wojcik "This is that thing you call sarcasm, isn't it?" fjw2@lehigh.edu -Ford Prefect in Douglas Adams' _Mostly_Harmless_ GE d- -p+ c++++ l u(++) e*() m+@ s++/++ n-@ h+() f- g+(-) w++() t+(+++)@ r !y finger fjw2@cs2.CC.lehigh.edu = C8 E8 73 86 FB DB C2 61 0D 60 23 7A EB CB 23 61 Date: Thu, 7 Apr 1994 12:19:33 MST From: Message-ID: <94097.121933AHNAS@ASUACAD.BITNET> Subject: Re: More on beginner's hill A practice hill is not the same as a beginner hill. For a beginner it's encourageing to get onto a hill. To get a score is not so exiting. I support the age limit solution for the beginner hill. Of course a practice hill is a good idea in addition to the beginner hill. Long ago I maintained a list of the oldest programs. I think this would work for the practice hill. The practice hill should contain the oldest programs on the various hills. So the practice hill would change although very slowly ( not many warriors live long ). Nandor. From: fullanto@cwis.isu.edu (FULLMER_ANTONETTE) Subject: Learning... Date: 7 Apr 1994 13:41:12 -0600 Message-ID: <2o1nko$k9j@cwis.isu.edu> From: fullanto@cwis.isu.edu (FULLMER_ANTONETTE) Subject: Learning Date: 7 Apr 1994 13:47:26 -0600 Message-ID: <2o1o0e$l2g@cwis.isu.edu> Hi everyone. I'm trying to learn how to program redcode, but almost every explanation I've seen seems to assume that you already know assembly language, and I don't. Anyway, I had and idea for a warrior, although I have no idea how to go about programming it. I'm not very comfortable with the terminology yet, but I think you could probably call it a stone-vampire-spiral combination. It would launch a small number of processes, each of which would bomb a certain area in core with either DAT or JMP to a DAT in the warrior, I'm not sure which would be better. Maybe after I learn it a little better, I could change the launching process after launch to subvert enemy programs, but that's quite a ways in the future, methinks... Anyway, each process would have a "timer" DAT instruction that it would increment each time it dropped a bomb. Then it would check the next process' timer. If the next timer were more than two less than it's own, it would assume that the next process was dead or otherwise incapacitated, and make a copy of itself over the next (dead) process. Has something like this been tried before? If so, how did it do? Could somebody send me some example code for such a program? It's easier for me to figure out code from an idea rather than trying to figure out an idea from it's code. From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: New KotH Server Now Available! Date: 7 Apr 1994 17:23:04 GMT Message-ID: <2o1fho$l1n@agate.berkeley.edu> Frank Jude Wojcik wrote: >Umm, there seems to be a small bug in this hill. I can't kill off any of my >programs. There are now about 5 of them up there at least. This is probably because there aren't enough programs on the hill yet. When you kill a program it doesn't actually remove it from the hill, it just assigns it a ridiculously low score and assumes that the next real submission to the hill will knock your killed program off. However, the Pizza hills are still new and none of them have 20 people yet, so there's nobody to knock your old versions of Zipper off. Just wait -- after a while the hill will fill up and your killed programs should get knocked off. If they don't then kill them again and then it should work. (This might be necessary depending on how the koth server scores new programs fighting killed programs. I don't know exactly how it works.) Also, this doesn't apply to the current situation, but just so that you know: if you need to send a "fake" program just to kill another one of your programs off (i.e. if you had two programs on the hill and decided that one of them was taking too many points away from the other) then the "fake" program you submit must have at least one line that's *not* DAT 0, 0. If the program is composed entirely of DAT 0, 0 then the koth server assumes that you just want to check the standings of the hill, and doesn't bother battling your program against the rest -- or, more importantly, reading the header information to find things like ";kill" instructions. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: wms@ssd.intel.com (William Shubert) Subject: KotH Server Announcement Message-ID: Date: Thu, 7 Apr 1994 18:38:58 GMT Hello everybody, As you have probably heard there is a now Corewar server running on "ecst.csuchico.edu". This server promises to have the same fast turnaround as my server but with more hill options, including a '94 hill. This makes my hill at Intel rather redundant, and so I plan to phase it out. I have exchanged mail with Thomas Davies, who set up the new site, and he is completely willing to accept all the submissions that have in the past been going to my hill. So please, use his new hill! It's been a really fun three (has it really been three?) years providing this service to the internet community but as some of you know I've somewhat lost touch with the corewar community and I'll be happy to get my machine cycles back. For now my hill will continue to operate, but as soon as it's use has dropped off enough (hopefully in a few days) I will be shutting it down for good. Thanks to all of those who used my server in the past! -Bill (wms@ssd.intel.com) From: rwcapili@ecn.uoknor.edu (Robert Wilhelm Capili) Subject: newbie Date: 7 Apr 1994 22:14:09 GMT Message-ID: <2o20jh$anc@constellation.ecn.uoknor.edu> Could someone please mail me some text on how to get started here? Thanks in advance Rob (rwcapili@essex.ecn.uoknor.edu) From: bcohen@acsu.buffalo.edu (Bram Cohen) Subject: pmars on VAX VMS Message-ID: Date: Thu, 7 Apr 1994 22:59:57 GMT Has anyone managed to get this to work? I don't usually use VAX, but I can't run pmars on my other account due to annoying and unavoidable circumstances. Anyone out there even familiar with VMS? From: dr@st-andrews.ac.uk (Duncan Rowland) Subject: FAW Date: 8 Apr 1994 15:31:32 GMT Message-ID: <2o3tck$4hq@calvin.st-and.ac.uk> please could someone mail me th FAQ for this group - or if there isn't one tell me some ftp sites with usefull information on setting up a corewar preferably with a bit of history and some code too. -Thanks-Duncan. From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: More on beginner's hill Date: 8 Apr 1994 18:01:15 GMT Message-ID: <2o465b$eug@agate.berkeley.edu> In article <94097.121933AHNAS@asuacad.bitnet>, wrote: > A practice hill is not the same as a beginner hill. For a beginner it's > encourageing to get onto a hill. To get a score is not so exiting. But the point of the practice hill is that beginners will use it to make their programs better, so that they can get onto the real hill. Maybe we could add another 5-10 spots to the real hill to make it easier for (beginners) to get on. > Long ago I maintained a list of the oldest programs. I think this would > work for the practice hill. The practice hill should contain the oldest > programs on the various hills. So the practice hill would change although > very slowly ( not many warriors live long ). This sounds good to me. People will be able to test their programs against time-honored strategies, and will start finding ways to defeat them, which will keep the hill from standing still. For beginners, it still has the beneficial effect of testing their program against standard warrior forms. However, I think that the practice hill should also have some "generic" warriors that were never meant to be on the hill (eg. a standard paper with no extra features at all). This would make it more useful to beginners. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: b1824@dpx20.iut-orsay.fr Subject: pre-decrement Date: 8 Apr 1994 18:39:47 -0400 Message-ID: <9404081100.AA49131@dpx20.iut-orsay.fr> Hello, I'm very new to CoreWar, so I've some problems with the language: 1) to which standard belong the instructions PCT, RND 2) Is there a limit in writing distance ? 3) if I do jmp <2 , the adress will be first decremented, then there will be a jump or not ? I think it is very hard for beginner like me to know which instructions are allowed when you talk about corewar ( you should specify 88, 94...) Thanks, Luc(b1824@dpx20.iut-orsay.fr) From: fullanto@cwis.isu.edu (FULLMER_ANTONETTE) Subject: Hmmm.. Date: 8 Apr 1994 22:34:34 -0600 Message-ID: <2o5b8q$8il@cwis.isu.edu> From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: More on beginner's hill Date: 9 Apr 1994 01:59:07 GMT Message-ID: <2o525b$ofo@agate.berkeley.edu> In article <1994Apr6.230501.25518@news.vanderbilt.edu>, Stefan Strack wrote: >Seriously though, if anyone has the time to write the scripts and the >resources to run a beginner's hill, mail me [...] There's already a "beginner's hill" spot on the Pizza server; why not just update it to / add a spot for the "practice hill" we've been discussing? -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: stormking.com server update Date: 9 Apr 1994 05:31:00 GMT Message-ID: <2o5eik$r76@agate.berkeley.edu> Stefan Strack wrote: >I am about to update the stormking.com server with pMARS v0.5, which >features three new experimental opcodes by popular request: > [SEQ, SNE, and NOP] While we're implementing controversial new features, how about IJZ (Increment and Jump if Zero), and the { and } modes (A-field pre-decrement indirect and A-field post-increment indirect, respectively). (If it wouldn't be too much work, of course -- it seems to me that IJZ, at least, would not be hard to implement.) -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: koth updates Message-ID: <1994Apr9.072953.18782@news.vanderbilt.edu> Date: Sat, 9 Apr 1994 07:29:53 GMT Thomas Davies has just updated the pizza server with pMARS v0.5. The stormking.com hills will follow shortly. For the '94 hills, this means that you can now use the experimental opcodes SEQ, SNE and NOP. Those who are moving their ICWS'88 warriors from Bill Shubert's hill should keep in mind that pizza's '88 hills are also running pMARS. For one thing, this means that you can use for/rof to compact your decoys. It also means that EQU expressions are no longer implicitely parenthesized, so if you've been using this "feature" you will now need to put parentheses explicitely (Mintardjo's "Winter Werewolf 3" is one of the warriors that wouldn't quite work as expected on the new ICWS'88 hill). By popular demand (ahem, two votes, both in favor of "-F nnn"), all hills are now running in deterministic mode. The pMARS -F switch seeds the pseudo random generator with seed "nnn", i.e. the 100 rounds per confrontation will have a fixed series of initial placements of warrior 2. This reduces random score fluctuations; i.e. if you submit the same warrior twice, the individual and cumulative scores will be identical (provided the hill hasn't changed in the meantime of course). If you submit a new version of your warrior that doesn't have a new bombing or scanning pattern, you can be sure that all changes in score are due to the changes you introduced, and not due to statistical fluctuations. The random number seed (and therefore the sequence of initial placements) changes automatically at the 1st of every month. -Stefan (stst@vuse.vanderbilt.edu) From: fullanto@cwis.isu.edu (FULLMER_ANTONETTE) Subject: Re: stormking.com server update Date: 9 Apr 1994 20:23:26 -0600 Message-ID: <2o7nuu$2ee@cwis.isu.edu> >and Jump if Zero), and the { and } modes (A-field pre-decrement indirect >and A-field post-increment indirect, respectively). (If it wouldn't be too How about giving a short explanation of indirect adressing to those of us who are having trouble with DIRECT addressing, much less indirect addressing. (knew I should have taken some time out to learn assembly...) :) From: mconst@soda.berkeley.edu (Michael Constant) Subject: Explaining Addressing Modes Date: 10 Apr 1994 17:55:16 GMT Message-ID: <2o9ei4$nca@agate.berkeley.edu> FULLMER_ANTONETTE wrote: >>and Jump if Zero), and the { and } modes (A-field pre-decrement indirect >>and A-field post-increment indirect, respectively). (If it wouldn't be too > >How about giving a short explanation of indirect adressing to those of us >who are having trouble with DIRECT addressing, much less indirect >addressing. (knew I should have taken some time out to learn assembly...) The tutorial *does* explain this, but not very well. So, here's my own attempt to clear up the mystery: There are 5 addressing modes: immediate (#), direct ($ or just blank), indirect (@), pre-decrement indirect (<), and post-increment indirect (>). (Note: The last of these (>) is only available under the proposed '94 standard, not '88.) Here is how they work. For each explanation, X is the number following the address mode under discussion, eg. for immediate it might be MOV #x, 2 So, here are the explanations: Immediate: Simply refers to the number x. (Actually this is slightly simplistic and doesn't always work for '94 programming (it's fine for '88), but it's good enough for beginning programmers. Anyone who wants the *real* explanation of how immediate addressing works, mail me.) Example: MOV #5, 2 copies the number 5 to the B-field of the instruction 2 ahead of the current instruction. Direct: Refers to the instruction x ahead of the current instruction. Example: MOV 5, 2 copies the instruction 5 ahead to the instruction 2 ahead. (The instruction 2 ahead is overwritten.) Indirect: Refers to the instruction that's as far further ahead of the instruction x ahead as the instruction x ahead's B- field. (Stop and think about that.) Example: MOV @5, 2 would look at the B-field of the instruction 5 ahead, and go that many more instructions forward (past the instruction 5 ahead) and copy the instructino *there* to the instruction 2 ahead. Pre-decrement Like indirect, but decrements the B-field in question before Indirect: using it. Example: MOV <5, 2 would look at the B-field of the instruction 5 ahead (just like indirect), _decrement_that_B-field_, and then go as many instructions further forward as the (new) B-field, and copy the instruction *there* to the instruction 2 ahead. The B-field stays decremented. (Note: like the explanation of immediate addressing, this explanation does not explain all. Namely, it leaves out a discussion of in-register and in-memory evaluation. If you want to know how it really works, mail Stefan (stst@vuse.vanderbilt.edu) and CC the mail to me cause *I* don't understand it! :-) Post-increment Like indirect, but increments the B-field in question after Indirect: using it. Example: MOV >5, 2 would look at the B-field of the instruction 5 ahead, count that many more instructions forward (just like indirect), copy the instruction there to the instruction 2 ahead, and finally increment the B-field it used. (Obviously it stays incremented, otherwise there would be no point.) Note that this mode is only available under the proposed '94 standard. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: fjw2@ns1.cc.lehigh.edu (FRANK JUDE WOJCIK) Subject: Re: New KotH Server Now Available! Message-ID: <1994Apr11.004423.207713@ns1.cc.lehigh.edu> Date: Mon, 11 Apr 1994 00:44:23 GMT [much deletia] Well, thanks for the info, but my programs got knocked off anyway :( >Just wait -- after a >while the hill will fill up and your killed programs should get knocked off. Thanks for the vote of confidence :P ;) > Michael Constant (mconst@soda.berkeley.edu) > > GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y -- ----- Frank J. T. Wojcik "This is that thing you call sarcasm, isn't it?" fjw2@lehigh.edu -Ford Prefect in Douglas Adams' _Mostly_Harmless_ GE d- -p+ c++++ l u(++) e*() m+@ s++/++ n-@ h+() f- g+(-) w++() t+(+++)@ r !y finger fjw2@cs2.CC.lehigh.edu = C8 E8 73 86 FB DB C2 61 0D 60 23 7A EB CB 23 61 From: macaulay@ecr.mu.oz.au (Alexander_William MACAULAY) Subject: Redcoder 2.0 Message-ID: <9410120.21598@mulga.cs.mu.OZ.AU> Date: Mon, 11 Apr 1994 10:13:12 GMT Redcoder 2.0, a Macintosh Core War simulator and full development system, is now available for ftp from soda.berkeley.edu. At the moment you can find it in the directory /pub/corewar/incoming, but it should eventually be moved to /pub/corewar/systems. Redcoder 2.0 supports the ICWS '94 draft standard (it makes use of the pMARS assembler so that you can do all those nice things like multi-line equates, for-rof loops, etc.). Another major addition to Redcoder is a text core-view window which is great for debugging programs. You also get to choose from several different sets of patterns to draw changes to the core. Read the "About Redcoder 2.0" file included with Redcoder for more information and instructions on how to use the program. --- Alex MacAulay (macaulay@ecr.mu.oz.au) From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: The new Pizza server is great! Message-ID: Date: 11 Apr 1994 16:43:28 GMT Hello all, Thanks to Thomas Davies for setting up the new Pizza KoTH server. It has all the hills you've wanted (minus the practice hills, maybe), and has a turn-around time comparable to Intel's. At last I can submit my 94x warriors and have the results the same day! So, I transfered all my 94 warriors there. I think stormking can still be useful as a test site for experimental Corewar (e.g. with the new opcodes), while Intel's hill is discontinued. As an evidence to my ever increasing enthusiasm, I'll post the code for my latest two warriors, Variation D-1 and Scanalyzer-V.3a. Variation is riding at the top of the hill, but not #1, though it's #1 on Stormking. That's mainly due, IMHO, to the fact that there still are many ampty slots on the Pizza hill. So, go ahead and fill that space! You have a few *guaranteed* Hill spots right now! -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Variation D-1 Message-ID: Date: 11 Apr 1994 16:59:39 GMT Remember when I posted my moderately-successful Stimpede? It basically had a ExtraExtra stone with a 2-process 19-point imp-spiral. I improved it by changing the ending slightly, and adding more trashing (put DJN where there was a JMP). Variation A-1.a was the successor, and it had an extra wimp to tie CG-X and to have an extra edge againts other stone/imps, at the expense of more vulnerability to scanners and vampires. The latest Variation D-1 has a slightly different twist to the stone part. After some bombing, the "buckle" line is replaces by "stop", so that the stone doesn't generate more processes (the stone becomes ineffective if we hit the processes max). Later on, it drops "patch" onto "stone", which steers away processes into the core-clear. However, all the processes at "loop" and "cast" keep bombing for a while before they're drained. The constants are adjusted so that the complete bombing run almost exactly hits every other core location either by decrementing or bombing (there's a slight over-reach). The core-clear is an ultra-standard one, changing into a perfect gate. At this point there are still 3000+ processes running, so the time spent in my own spiral is negligible (or so I hope). Notice the wimp that's started right after the stone. This wimp also generates a number of processes, but nowhere near what the stone accumulates over time. The stone and the spiral are vulnerable to CG-X's decrementing run, but the wimp is not, so I get 90+% ties against CG-X, compared to about 25% losses with Stimpede. Finally, notice that when the stone hits itself with "stop" on "buckle", it becomes a 50% gate, which is enough to gain another few points againts other spirals. Againts other stone/imps, my stone has a 50/50 chance of winning against the opponent's and then when the stone is dead, the wimp will kill the opponent's stone and spiral. So, why have a spiral at all? That's a good question, and I'll answer to it after I experiment with my upcoming Nova series. ;redcode-94x ;name Variation D-1 ;author Jay Han ;strategy Variation on the theme of "Twimpede" ;strategy Added a split/wimp ;strategy Stonger imp-gating, less trashing ;macro org start ; Mod-2 stone p1 equ 27739 s1 equ 34 p2 equ 27705 s2 equ -34 gate equ top-39 top equ stop stop dat.f Date: 11 Apr 1994 17:24:53 GMT I made several attempts at making a decent scanner for a long time. My previous Scanalyzers were just scanners, and I'd tried different bombing patterns and scanning patterns, but none had achieved a very good score. Maybe I should learn to use the Optima program! :-) Anyway, encouraged by the success of my simple vampire, named The Count, I decided to combine a vampire and a scanner. The idea is to have a regular scanner, and when something is detected, drop a tailored fang on the target location, and continue scanning. After a while, start a core-clear that ends by killing of the pit, then become a perfect gate (we never know, those spirals survive anything!). The "fang" is just a JMP, and we first move it to the target, then substract the target's offset from "scan" from the fang's A-operand. The fang now points to "pit". One of the problems (as in any scanner) is that there's only a single process, and I can't have a spiral for life insurance, much less a wimp. However, my future plans include a combination stone/spiral/vampire/wimp. The vampire would cast fangs in a loop similar to ExtraExtra, while the stone trashes the core in parallel. That way, I can start a spiral and even a wimp without too much penalty in terms of bombing speed. The one big problem with ExtraExtra vampire is how to stop them. For a stone, it's simple, you just lay out replacement instruction varefully at predetermined locations, and voila, you have a self-modifying program. A vampire, however, only knows fangs. One solution is to set up the stone to kill off the vampire after a while. The problem is that your choice of constants is getting real narrow, because you have to make it so that it hits three core locations at predetermined time. Another solution is to have a wimp to kill your vampire. Also, you mustn't let the vampire hit your stone. That's even trickier, and involves a careful choice of the constant. As I mentioned before, I use a spiral primarily as a life insurance. As long as the tail process is not killed, a spiral survives most anything, except a perfect gate. And the tail process is darn hard to find in the big core. Only stone-type warriors benefit from this, though, because you can pour thousands of processes in a stone or a vampire, but not in a scanner. How about papers? I don't think there's any paper on the 94x hill right now (my puny attempt, The Hunt, was quickly discarded). Why is that so? I remember some discussion before the big hill was set up where we said paper-type fast-replicating warriors would have an advantage in the big core. Apparently that is not so, at least at the current state of the art. As usual, all comments are welcome. I am fervent believer in the '94 Big hill standard (mainly because that's the rules under which I have been the most successful! :-) ). ;redcode-94x ;name Scanalyzer-V.3a ;author Jay Han ;strategy Scanner/Vampire ;macro org scan start equ loop-3 step equ -34 loop add.f inc, scan scan cmp.i start+step, start slt.ab #tail+200, scan count djn.b loop, #27719 mov.i fang, @scan sub.ba scan, @scan add.f half, scan p jmn.b scan, count half spl.b #step, My friend ported pMars to OS/2, and now he's working on a GUI version of it for Presentation Manager... He wants to know if there is any inter est for this OS/2 version, and any suggestions as to features he should add. If he get's any interest, he might work a bit faster... :) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: pMars for OS/2 Message-ID: <1994Apr12.052141.15343@news.vanderbilt.edu> Date: Tue, 12 Apr 1994 05:21:41 GMT In article <19940411210052IZZYVD5@MVS.OAC.UCLA.EDU> IZZYVD5@MVS.OAC.UCLA.EDU writes: >My friend ported pMars to OS/2, and now he's working on a GUI version >of it for Presentation Manager... He wants to know if there is any inter >est for this OS/2 version, and any suggestions as to features he should >add. If he get's any interest, he might work a bit faster... :) Great! Ask your friend to contact me, so we can coordinate integrating OS/2 specific extensions into the base distribution. pMARS is a continuously evolving team project; so it's important that ports to other platforms don't become outdated as soon as we release a new version (Chris Lindensmith, are you still working on that Mac port with display?). -Stefan (stst@vuse.vanderbilt.edu) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: pMARS v0.5.0 uploaded to soda Message-ID: <1994Apr12.062713.15827@news.vanderbilt.edu> Date: Tue, 12 Apr 1994 06:27:13 GMT I have just uploaded the latest version of pMARS to soda.berkeley.edu. For now in pub/corewar/incoming, eventually in pub/corewar/systems are: pmars05s.zip - C source, portable zip archive pmars05s.tar.Z - same, tar'd and compressed pmars05.zip - DOS 16-bit executables (BC 3.1), pshell pmars05g.zip - DOS 32-bit execs (djgpp), supports large (94x) core Anyone willing to update the Mac and Amiga ports at soda? v0.5 has been running at stormking.com and pizza for the past few days. It is a major release in that it fixes one pretty serious overflow problem that may occur with large coresizes. There are also a number of new features and a menu-driven frontend for DOS, so it's probably worth downloading. Below is the file "whatsnew.050". Enjoy, Stefan (stst@vuse.vanderbilt.edu) (for the pMARS group) ____________________ What's new in version 0.5.0 Bug fixes: o MULtiplying large numbers in a large coresize (55440) can no longer produce an overflow-related segmentation fault o END without argument no longer overrides a previous ORG statement New features, Simulator/Assembler: o added three experimental opcodes: SEQ (Skip if EQual, synonym for CMP) SNE (Skip if Not Equal, opposite of SEQ) NOP (No OPeration = do nothing) [You can disable these by compiling without -DNEW_OPCODES] o added predefined variables that you can reference in your warrior source: CORESIZE MAXPROCESSES MAXLENGTH MINDISTANCE MAXCYCLES o Redcode expressions can now contain C-style comparison and boolean operators. Together with predefined variables, this can be used to write redcode that adjusts to the core parameters, e.g.: POINT EQU (CORESIZE == 55440)*13 + (CORESIZE == 8000)*3 Debugger (cdb): o The DOS debugger has two side-by-side, independendly scrollable display panels. This allows for simultaneous display of both warriors, code vs. addresses accessed by code, etc.. The SWITCH (macro: ) and CLOSE (macro: ) commands control the panel display. o The macro language has been enhanced with nestable loop blocks (!!~cmd~...~![n]), a macro termination command (RESET), and conditional execution via the IF command. It is now possible to write complicated macros for automatic selection of constants, stepping through code until a particular condition is met, etc.. The default macro file "pmars.mac" contains a few sample macros, including one that calculates imp numbers. o The process queue is now as accessible for debugging as the core array using the new PQUEUE command. PQUEUE switches cdb into "process queue mode" in which the LIST, EDIT and FILL commands act on the process queue instead of the core array. PQUEUE is useful for debugging complicated multi-process warriors, like imp-spiral/stone combos. E.g., it is easy to find out whether a spiral executes without "gaps" and how many processes are executing a given core location (and to automate these tasks with macros). pshell: The DOS version of pMARS (pmars05.zip) now includes a menu-driven frontend. pshell allows you to select warriors from a directory listing, configure pMARS and the tournament scheduler MTS from pull-down menus, and call an external editor. If you like mars88's interface, pshell is for you. From: nike@indirect.com (Laurence Canter) Subject: Green Card Lottery- Final One? Date: 12 Apr 1994 08:10:58 GMT Message-ID: <2odl2i$41v@herald.indirect.com> Green Card Lottery 1994 May Be The Last One! THE DEADLINE HAS BEEN ANNOUNCED. The Green Card Lottery is a completely legal program giving away a certain annual allotment of Green Cards to persons born in certain countries. The lottery program was scheduled to continue on a permanent basis. However, recently, Senator Alan J Simpson introduced a bill into the U. S. Congress which could end any future lotteries. THE 1994 LOTTERY IS SCHEDULED TO TAKE PLACE SOON, BUT IT MAY BE THE VERY LAST ONE. PERSONS BORN IN MOST COUNTRIES QUALIFY, MANY FOR FIRST TIME. The only countries NOT qualifying are: Mexico; India; P.R. China; Taiwan, Philippines, North Korea, Canada, United Kingdom (except Northern Ireland), Jamaica, Domican Republic, El Salvador and Vietnam. Lottery registration will take place soon. 55,000 Green Cards will be given to those who register correctly. NO JOB IS REQUIRED. THERE IS A STRICT JUNE DEADLINE. THE TIME TO START IS NOW!! For FREE information via Email, send request to cslaw@indirect.com -- ***************************************************************** Canter & Siegel, Immigration Attorneys 3333 E Camelback Road, Ste 250, Phoenix AZ 85018 USA cslaw@indirect.com telephone (602)661-3911 Fax (602) 451-7617 From: mchapman@isle.waterloo-rdp.on.ca (M.Chapman) Subject: soda.berkley Date: Tue, 12 Apr 1994 12:13:52 GMT Message-ID: <1994Apr12.121352.773@isle.waterloo-rdp.on.ca> can soda.berkley be accessed via gopher? i don;t have ftp access but i can get into the gopher system. -- | Tass Chapman | m.chapman@ieee.org | FIDO 1:221\403 | | Conestoga College- Elec' Tech' Eng. Telecommunications | | Kitchener Ontario Canada | "OOPS... I guess that's not a thing conductive to a long life." From: fullanto@cwis.isu.edu (FULLMER_ANTONETTE) Subject: Re: The new Pizza server is great! Date: 12 Apr 1994 13:10:43 -0600 Message-ID: <2oernj$g0i@cwis.isu.edu> Could somebody post the address for the new server? My news reader only keeps about the last 30 messages or so, it seems... Also, instructions about how to post a warrior to the hill would be extremely helpful. Thanks From: mike@sna.co.umist.ac.uk (Mike Reddy) Subject: Genetic Algorhithms in Corewar Message-ID: <1994Apr12.132528.4376@nessie.mcc.ac.uk> Date: Tue, 12 Apr 1994 13:25:28 GMT Anyone know of any GA approaches to 'evolving' corewar warriors? I have a student who is interested in developing a system of cross-over production of code from parent warriors to run in the corewar environment; it being not advisable to have real viruses evolving on a computer 8-) We would probably need to get some source code for the c corewar program so that we could insert the creation aspects of the code and then run them to determine survival from within the program, rather than loading them up manually (which would slow down the number of generations that can evolve over a given time). We have access to PCs Macs and Suns though I would prefer the student to use a Mac platform. Yours Mike Reddy mreddy@uk.ac.glamorgan OR mreddy@uk.ac.glam.genvax From: mike@sna.co.umist.ac.uk (Mike Reddy) Subject: Genetic Algorithms and cross-over in corewar Message-ID: <1994Apr12.134340.9377@nessie.mcc.ac.uk> Date: Tue, 12 Apr 1994 13:43:40 GMT We would probably need to get some source code for the c corewar program so that we could insert the creation aspects of the code and then run them to determine survival from within the program, rather than loading them up manually (which would slow down the number of generations that can evolve over a given time). We have access to PCs Macs and Suns though I would prefer the student to use a Mac platform. Yours Mike Reddy mreddy@uk.ac.glamorgan OR mreddy@uk.ac.glam.genvax From: SFCLUB@invest.rostov-na-donu.su (SFCLUB) Subject: Date: Tue, 12 Apr 94 14:08:10 +0300 Message-ID: list From: Dave Darling Subject: Creating N procs Message-ID: <1994Apr12.170950.7074@riacs.edu> Date: Tue, 12 Apr 94 17:09:50 GMT There have been times when I have wanted to create N processes that get to one particular instruction at the same time. I eventually stole a bit of code from one program (Extra Extra??? I forget..) and modified it to suit my needs... I'm not sure, but I think that there's room for another tool/utility program in this--how to get N processes going at once, such that all of them will hit instruction at the "same time" (i.e., "r"egisters in pMARS would look like: .... [M] -> M M M ..... ) I'm not entirely sure that it's possible to have those processes be a contiguous chunk out of many more. If that confused you, what I mean is: You've got ten processes running. You need six more for some symbiotic stuff you're doing. Can you get those six more to execute consecutively, without having one of the other ten going between two of them? I'd give it a try, but I still don't see the pattern for creating N processes. Sigh. Anyone else want to take a crack at it? --DD From: jlayland@kilroy.jpl.nasa.gov (James Layland) Subject: Re: Creating N procs Date: 12 Apr 1994 18:01:25 GMT Message-ID: <2oenll$lr9@elroy.jpl.nasa.gov> In article <1994Apr12.170950.7074@riacs.edu>, Dave Darling wrote: > There have been times when I have wanted to create N processes that >get to one particular instruction at the same time. I eventually stole a >bit of code from one program (Extra Extra??? I forget..) and modified it >to suit my needs... The way to do this is: Subtract one from the number of processes you want. Convert it to a binary number. Write SPL 1 for every "1". Write MOV -1, 0 for every "0". E.g. to create 13 processes: 13-1 = 12. 12 = 1100 in binary Your code should read a SPL 1 b SPL 1 c MOV -1,0 d MOV -1,0 e .... ; there will be 13 processes here After executing a, there will be 2 processes at b. After executing b, there will be 4 processes at c. After executing c once, c becomes SPL 1; the other 3 processes each create a new process, for a total of 7 processes at d. Similarly, d creates 7-1=6 new processes, for a total of 13 processes at e, which will all execute consecutively, as desired. -- James Layland jlayland@grissom.jpl.nasa.gov From: Dave Darling Subject: Re: Creating N procs Message-ID: <1994Apr12.181407.7636@riacs.edu> Date: Tue, 12 Apr 94 18:14:07 GMT In article <2oenll$lr9@elroy.jpl.nasa.gov> James Layland, jlayland@kilroy.jpl.nasa.gov writes: >The way to do this is: > In article <2oenll$lr9@elroy.jpl.nasa.gov> James Layland, jlayland@kilroy.jpl.nasa.gov writes: >The way to do this is: [ . . . ] Thanks! I had a feeling I was missing something! --DD From: bmury@uglx.UVic.CA (Brian Mury) Subject: Re: Amiga Version??? Message-ID: <1994Apr12.195744.22650@sol.UVic.CA> Date: Tue, 12 Apr 94 19:57:44 GMT > Is there an Amiga version of CoreWars Available... If not, where can >I get the source code for it... I would really like a response, cuz I've >always wanted to do some codeing of my own... Thanks... Ftp to soda.berkeley.edu, cd to the directory pub/corewar/systems, and get the file MADgic41.lzh. You can also get the file MAD50B.lha, which is a more recent version, but is a beta version and doesn't include all the example redcode files (and documentation, I think). From: bcohen@acsu.buffalo.edu (Bram Cohen) Subject: Re: Creating N procs Message-ID: Date: Tue, 12 Apr 1994 21:01:10 GMT In article <1994Apr12.170950.7074@riacs.edu>, Dave Darling wrote: > I'm not sure, but I think that there's room for another tool/utility >program in this--how to get N processes going at once, such that all of >them will hit instruction at the "same time" (i.e., "r"egisters in pMARS >would look like: .... [M] -> M M M ..... ) I'm not entirely sure that >it's possible to have those processes be a contiguous chunk out of many >more. If that confused you, what I mean is: You've got ten processes >running. You need six more for some symbiotic stuff you're doing. Can >you get those six more to execute consecutively, without having one of >the other ten going between two of them? The imp-spiral generation program discussed a little while ago did this. Just string together a bunch of SPL 1's and MOV -1,0's in the right order. For example: start SPL 1 SPL 1 MOV -1,0 SPL 1 MOV -1,0 MOV 0,1 will create an imp which gets executed six times before moving to the next position. The streams are automatically consecutive since they were all generated by the same initial stream. From: Dave Darling Subject: s4b source Message-ID: <1994Apr13.170929.17474@riacs.edu> Date: Wed, 13 Apr 94 17:09:29 GMT I am posting the source for s4b, a simple four-line (grew to five) bomber which made it onto the hill by the skin of its teeth (and, I think, by someone killing one of their other programs....). It's nothing special, but the curious thing is that it converts it- self into a slow core clear. A DAT instruction winds up at "start", and it makes the ADD affect something way out in core somewhere. The B-field of "stone" is pointing to "start", and the autodecrement, MOV, (essentally no-op) ADD, and DJN wind up clearing core. Some constant fiddling could probably adjust this so that the SPL is left alive--unforunately, this version suicides at the end of the clear. ;redcode ;name s4b ;author D. Darling ;strategy Simple 4-line Bomber ;strategy Apologies if this = Herem, etc... ;strategy Now 5-line: self-SPL+core clear step EQU 2365 start SPL 0, <-10 stone MOV <-6, <-12 ADD inc, stone DJN stone, <-3 inc DAT Date: Wed, 13 Apr 1994 17:59:33 GMT Well, it's been three days since the KotH server at my site got any mail, so I guess that the traffic has moved to the new Pizza server. I'll be taking my server down now; thanks everybody who used it, and thanks to Tom Davies for setting up the replacement! Bye! -Bill (wms@ssd.intel.com) From: mconst@soda.berkeley.edu (Michael Constant) Subject: MNCT Round 3... Date: 14 Apr 1994 00:06:25 GMT Message-ID: <2oi1e1$afv@agate.berkeley.edu> OK, this is it. I think that the time has come for MNCT to end... maybe this view is partially caused by the fact that I couldn't run round 3 with pmars0.4 because it kept crashing with a segmentation fault (I assume this is due to the bug mentioned in the whatsnew.050 file). However, with the new version, Alex MacAulay's program won't even compile because (apparently) the "coresize" variable has been removed. Unfortunately his program depended on the coresize variable and won't even get close to running without it (am I right, Alex?) Anyway, if anyone else wants to finish up round 3 (and possibly continue the tournament) this is fine with me and I'll mail the good person the submissions for round 3. If not, I think I'll just post the code for round 3 and then get on with my life... running a corewar tournament sure does take a lot of time... -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Answers to frequently asked questions (FAQ) - updated Message-ID: <1994Apr14.003711.1741@news.vanderbilt.edu> Date: Thu, 14 Apr 1994 00:37:11 GMT I'm posting this manually to answer questions that have been coming up about the new KotH. The FAQ list is automatically posted every 14 days; mail me if you think this is not often enough. From: stst@vuse.vanderbilt.edu (Stefan Strack) Organization: The Core War Newsletter Newsgroups: rec.games.corewar,rec.answers,news.answers Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Followup-To: rec.games.corewar Reply-To: stst@vuse.vanderbilt.edu (Stefan Strack) Summary: This posting contains a list of Frequently Asked Questions (and their answers) about the game Core War. It should be read by anyone interested in posting to the rec.games.corewar newsgroup or submitting warriors to the ongoing Core War tournament - KotH. Approved: news-answers-request@MIT.Edu Archive-name: games/corewar-faq Last-modified: 1994/04/13 Version: 2.2.0 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 69 2. Is it Core War or Core Wars? 82 3. Where can I find more information about Core War? 90 4. Core War has changed since Dewdney's articles. Where do I get 108 a copy of the current instruction set? 5. What is this ICWS'94? 126 6. What is the ICWS? 142 7. What is TCWN? 152 8. How do I join? 160 9. Are back issues of TCWNs available? 177 10. What is the EBS? 184 11. Where are the Core War archives? 200 12. Where can I find a Core War system for . . . ? 218 13. I do not have ftp. How do I get all of this great stuff? 267 14. I do not have access to Usenet. How do I post and receive news? 274 15. When is the next tournament? 292 16. What is KOTH? How do I enter? 303 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 459 18. How does SLT (Skip if Less Than) work? 471 19. What does (expression or term of your choice) mean? 483 20. Other questions? 611 --------------------------------------------------------------------- Q 1: What is Core War? A 1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 The Redcode language has changed somewhat since; see Q 4. --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (soda.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q11) Steven Morrell (morrell@math.utah.edu) is preparing a more pratically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. --------------------------------------------------------------------- Q 5: What is this ICWS'94? A 5: There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a post-increment indirect addressing mode and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft for more information (soda.berkeley.edu pub/corewar/documents/icws94.0202.Z). You can try out the new standard by submitting warriors to the '94 hills of the KotH servers (see Q16). Two corewar systems currently support ICWS'94: pMARS (various platforms) and Redcoder (Mac). Both are available at soda (see Q12). --------------------------------------------------------------------- Q 6: What is the ICWS? A 6: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). --------------------------------------------------------------------- Q 7: What is TCWN? A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 8: How do I join? A 8: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 9: Are back issues of TCWN available? A 9: Recent issues can be found on soda.berkeley.edu (see Q11). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- Q10: What is the EBS? A10: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994 (see Q 5). Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- Q11: Where is the Core War archive? A11: Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from soda.berkeley.edu (128.32.149.19) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q12: Where can I find a Core War system for . . . ? A12: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than soda.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at soda: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-20.hqx - corewar for the Mac, supports ICWS'88 and '94 core-11.hqx - corewar for the Mac core-wars-simulator.hqx - same as core-11.hqx? corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z - corewar for UNIX/X-windows. This program ran the former KotH server at intel.com koth.shar.Z - older version kothpc.zip - port of older version of KotH to the PC deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible icons.zip - corewar icons for MS-Windows macrored.zip - a redcode macro-preprocessor (PC) c88v49.zip - PC corewar, textmode display mars88.zip - PC corewar, graphics mode display corwp302.zip - PC corewar, textmode display, slowish mercury2.zip - PC corewar written in assembly, fast! mtourn11.zip - tournament scheduler for mercury (req. 4DOS) pmars05s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars05s.tar.Z - same as above pmars05.zip - 16-bit PC executables, graphics display version pmars05g.zip - 32-bit PC execs (djgpp, large core) macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincore.zip - MS-Windows system, shareware ($35) ---------------------------------------------------------------------- Q13: I do not have ftp. How do I get all of this great stuff? A13: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. ---------------------------------------------------------------------- Q14: I do not have access to Usenet. How do I post and receive news? A14: To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com ListProcessor. To join, send: SUB COREWAR-L FirstName LastName to: LISTPROC@STORMKING.COM You can send mail to corewar-l@stormking.com to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (tuc@stormking.com). Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q15: When is the next tournament? A15: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. Informal double-elimination tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. ---------------------------------------------------------------------- Q16: What is KOTH? How do I enter? A16: King Of The Hill (KOTH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. The original KOTH was developed and run by William Shubert at Intel, and discontinued after almost three years of service. Currently, KOTHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: "koth@stormking.com" is maintained by Scott J. Ellentuch (tuc@stormking.com) and "pizza@ecst.csuchico.edu" by Thomas H. Davies (sd@ecst.csuchico.edu). Both KOTHs provide very similar services and are therefore covered together. The principal difference is that "pizza" has a much faster internet connection than "stormking". Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail daemon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. There are currently five separate hills you can select by starting your program with ;redcode, ;redcode-x ;redcode-b, ;redcode-94, or ;redcode-94x. More information on these hills is listed below. 3) Mail this file to "koth@stormking.com" or "pizza@ecst.csuchico.edu". "Pizza" requires a subject of "koth" (use the -s flag on most mailers). 4) Within a few minutes (or the next day for "stormking") you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so (or the next day for "stormking") you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives during that time, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Here are the Specs for the various hills: ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '88 ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws", available at "stormking" only) coresize: 8192 instructions max. processes: 8000 per program duration: After 100,000 cycles, a tie is declared. max. entry length: 300 minimum distance: 300 instruction set: ICWS '88 ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x", available at "pizza" only) coresize: 4096 max. processes: 32 duration: after 65,536 cycles, a tie is declared. max. entry length: 64 minimum distance: 64 instruction set: ICWS '88 ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza" only) coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "stormking" and "pizza") coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: ICWS '94 Draft All hills run portable MARS (pMARS) version 0.5, a platform-independent corewar system available at soda (see Q12). The '94 and '94x hills allow three experimental opcodes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) ---------------------------------------------------------------------- Q17: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A17: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. ---------------------------------------------------------------------- Q18: How does SLT (Skip if Less Than) work? A18: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q19: What does (expression or term of your choice) mean? A19: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, =============================================== Second Announcement of the 2nd International KNOBELN --- Game-Strategy Programming Contest =============================================== [Note some changes in the dates at end compared to first announcement !] This is an announcement for the KNOBELN-contest, taking place on Sunday, May 15th, 1994. The contest is run at the University of Karlsruhe, Germany, by Lutz Prechelt. Arbitrary teams can participate in the contest via email. PLEASE REDISTRIBUTE THIS ANNOUNCEMENT AS WIDELY AS YOU CAN e.g. to local and regional newsgroups, bulletin boards, pin boards, friends, and colleagues. ----------------- Type of Contest: ----------------- To participate, you must program in C a strategy for a simple game and send it to me by email. The game is quite interesting since there clearly is no canonical best strategy (the success of a strategy depends on the behavior of all other participants). This means that you have to make your strategy adaptive to an environment of opponents not known in advance. -------------- Rules of Game: -------------- 1. Both players (at the same time) chose an integer number in the interval a..b. This selection of two numbers is called a "throw". The players can watch each throw as it is made (i.e. they can know all numbers they and their opponent have thrown up to the current throw) Assumption: Player P choses p1 and player Q choses q1. 2. If p1 equals q1, nobody wins a point. 3. Otherwise, the player with the higher number wins, unless the number is more than twice as high as that of his opponent. Let's assume that p1 > q1, then P wins if 2*q1 >= p1 and Q wins if 2*q1 < p1. 4. A player who wins a throw with some number N gets floor(log2(N)) points in this throw. The other player gets 0 points in this throw. Example: if P wins, he/she gets floor(log2(p1)) points e.g. if p1 = 6800, player P gets 12 points. 5. A game consists of L throws. 6. Both players must throw series of non-decreasing throws. These series must (for each player individually) have a length of AT LEAST k throws. Example: If P throws (p1, p2, p3, .....) then p1 <= p2 <= p3 <= ... <= p(k) is required. After that, p(k) > p(k+1) is allowed. If p(k) > p(k+1) then p(k+1) <= p(k+2) <= ... <= p(k+k) is required. else there exists some smallest number j, with j > k for which p(j) > p(j+1) and then p(j+1) <= p(j+2) <= ... <= p(j+k) is required. and so on through the whole game. If for instance k = 3 then the sequence 1, 2, 3, 1, 4, 5, 6, 8, 2 is allowed, while 1, 2, 3, 4, 1, 2, 1 is not ^ too early In this contest the parameters for the game are: a = 1, b = 12288, k = 8, L = 1000 -------------------- Rules of Tournament: -------------------- The tournament is performed in successive rounds with randomly mixed groups of 20 to 41 participants. Within each group, each strategy plays one game against every strategy in that group (including itself). At least those half of the participants, that have won most points in their group (no matter how many their opponents got), proceed to the next round, which is played with newly mixed groups. The winners of the last round are the winners of the tournament; the results of previous rounds are discarded. Any strategy is allowed to fail once per round. Failing means doing anything that is forbidden by the contest rules. The game in question is immediately stopped, its intermediate results are discarded and it is rescheduled. If the strategy who failed had already failed before in the same round, the game is not rescheduled but the strategy is disqualified from the contest. All its remaining games in that round will not be carried out and all its previous games in that round will not be counted. See section 'requirements for programs' for additional rules. ----------------------- Disciplines of Contest: ----------------------- In the contest, two disciplines are played. Discipline 1: KNOBELN The first (and main) discipline is the normal KNOBELN tournament as described above. The winners of its final round in order will be announced as "the winners of the International KNOBELN contest". Discipline 2: Knobeln Evolution Participants of this discipline are those contest participants that reached the final round of the first discipline. The results of this final round are used as the basis for the following evolutionary computation: 1. A population of players is created that initially consists of, say, 5 exemplars of each strategy. (A different number may be chosen in the actual contest) 2. This population is used as the group for a virtual round of a Knobeln tournament: Each exemplar plays once against every other. These games are not actually carried out; their result is just taken to be the same as in the real final round of the original Knobeln tournament. 3. After this round, each player has won a certain amount of points. This amount is also a certain fraction of the total number of points won overall (by all participating players). This fraction F is used as a measure of 'success' that determines the number of exemplars of this player in the next round: The total number N of exemplars in the population is held constant and the number of exemplars of each player p in the next round is computed as the rounded value of N*F(p). 4. The evolution ends when the fractions of the population the players hold have stabilized. 5. The rank of each player is determined by the fraction is holds at the end of the evolution; the higher the fraction, the higher the rank. Those players that have fraction 0 get no rank. The ranked players of Knobeln Evolution, will be announced as "the winners of Knobeln Evolution in the International KNOBELN contest". ---------------------------- Characteristics of the Game: ---------------------------- The method of counting within a game and the method of selecting the winners of a group have an interesting impact on the goal of a strategy: It must actually try to arrange a cooperation with its 'opponent', because otherwise none of the two will usually be able to win many points. Trying to 'exploit' the opponent will work only if the opponent is not intelligent enough to strike back or has an attitude that is so extremely cooperative that is tolerates being exploited. It is NOT important to have more points than the opponent in any single game. Instead it is important to have more points than the other strategies on the average. The problem of programming a strategy could thus be formulated as "How do I (quickly) arrange a cooperation with a machine partner, if there is no predefined protocol to do so and the only communication channel is mutual exchange of integers, one at a time ?" It is clear, that there exists no optimal strategy: It is impossible to guarantee that a strategy A is able to arrange a cooperation with a strategy B, even if both are perfectly willing to cooperate in principle. This is true because both strategies have to 'guess' what might be suitable protocols to communicate. The two strategies of a game should together form a self-organizing system that organizes for cooperation. It should be noted that in the first contest (1993), aggressive strategies that tried to exploit their opponents got quite a good share of success despite the cooperation bias of the rules. The evolution rules of discipline 2 have the following consequence: A strategy that builds its success on strong exploitation of only a few other strategies that are themselves not very successful will have a hard time because these less successful strategies will vanish during the evolution. Strategies that yield roughly the same results for almost all opponents will score better. Discipline 2 was not part of the contest last year. ------------------------------ How to Announce Participation: ------------------------------ If you want to participate in the contest, send email of the following form: --- To: knobeln@ira.uka.de Subject: registration for KNOBELN mail-address: ourname@machine.domain.alfdkj mail-preference: LAP,DGP,GRG,RSM team-name: the_heavy_lords_of_knobeln Organization: University of Northeast Sacrodata, Intellect City, Eggland team-members: Joe Cool, 45, professional systems programmer, 20-year-experienced programmer Jane More, 20, graduate student of computer science, hackeress fluent in 34 programming languages Mona Morn, 35, Professor of CS, hobby game strategy programmer Bill Neat, 24, undergraduate student of psychology, advanced beginner (will be my first C program!) --- Please use this format EXACTLY as shown, because the registration will be processed automatically. In particular, put all of the 'Organization' entry on a single line (which may be longer than 80 characters if necessary) and don't put spaces in front of the colons. Don't put additional information into this mail; send separate mail instead, if necessary. - "mail-address" gives the email address that uniquely identifies the team, it should be an internet domain style address. - "mail-preference" is a comma-separated list of some of the following declarators (in all uppercase): LAP send list of all participants (full registration format) LGP send list of my groups' participants (team names only) DGP send detailed game protocol for each of my games (every throw) GRP send game result (points) for each of my games GRG send group result (all games of all participants) GRR send group result (ranking) RSM send summaries of rounds (includes all group rankings) - "team-name" can be any string that is a valid C identifier of at most 30 characters and should be a funny name for the team. It must in particular not contain any spaces - "Organization" should be the name of the institution the team is at or something else sensible, if no such thing exists. Please also give city and country/state. - "team-members" should contain a two-line informal description of each member of the team, giving his/her name, age in years, occupation, computer science and programming background, in this order. Team size should be anywhere between 1 and 10. Personnel should not be shared among teams. When I receive your registration, I will send an answer either (a) that your registration is not accepted, (e.g. because there are already too many participants registered), or (b) that your registration is accepted and your authentification string is . I may also tell you that I have slightly modified your team name, if it conflicts with an already registered one. I expect that case (a) will never occur. Please allow some time (ca. 3 days) for the answer to arrive. Notes: - If you are unable to send email to me or if I am unable to send email to you, you can not participate in the contest. Please use only Internet domain style email addresses. - Notification of acceptance or rejection will usually be sent within 72 hours. I reserve the right to limit participation of multiple teams from the same organization. - You must keep the authentification string carefully. It will be used to check, whether a strategy that swears to come from your team really does (see below "Sending Programs"). ----------------- Sending Programs: ----------------- To send in the first version or a new version of your program, send me email of the following form: ---- To: knobeln@ira.uka.de Subject: please compile /* <> team_name authentification_string */ /* your source code goes here */ ---- <> has to be given exactly as shown. The same is true for the "Subject:". For insert the name of your team as given in the registration. For insert the string that I sent you with the registration acknowledge. Your program will be compiled automatically shortly after your email arrives and you will be sent a report about the results of the compilation. A successfully compiled program is automatically stored to be used in the contest. The latest version is used always. --------------------------- Requirements for programs: --------------------------- 1. Pure C (ANSI or KR), i.e., no library routines called, except int init_random () int log2 (int number) int next_random (int low, int high) int make_throw (int my_throw) int count_points (int throw1, int throw2, int *points1, int *points2); (You will receive a detailed description of these functions upon registration) 2. Must be compilable with GNU C compiler (gcc). 3. Must be in a single file, no #includes 4. Must have at most 10000 lexical elements (after preprocessing) Lexical elements are: identifier, keyword, number, character in string denoter, character in char denoter, special character NO lexical elements (i.e. not counted) are: blank, Tab, newline, comment Information about how many lexical elements your program has is sent to you as a report from automatic compilation as described above. 5. The size of the process that runs the program must not grow beyond 1024 kB on a SUN SparcStation 2 running SUN OS 4.1. The value used to test this is the one shown by 'ps -u' in the column labeled 'SZ' (SIZE). 6. Must finish every game of 1000 throws in less than 30 seconds of cpu time on a SUN SparcStation 2 (which has about 20 SPECmarks). 7. Source code must contain a verbal description of the main program ideas of the strategy: Whether it tries to exploit and/or cooperate, and what techniques it uses to achieve that. The description should be at least about 15 lines long (but more detailed is fine). Please enclose the description in #if 0 ..... #endif. The description is not counted in the number of lexical elements. I recommend (but this is not enforced) that programs do not use floating point arithmetic and that programs are structured as infinite loops, i.e., do not terminate automatically after 1000 throws. ----------------------- Technical Environment: ----------------------- 1. In order to write and hand-test a strategy, you need the definitions of the library procedures mentioned above, called 'knobellib.c'. The source code for these functions is only 130 lines and will be sent to you via email with the notification of acceptance of your registration. Link your strategy with this module, but do not include the source code of the module into your strategy or else it will be rejected. This is the only mandatory software you need; all other parts described below are just utilities for your strategy development and analysis. 2. If you want to run complete games between two strategies in the same kind of environment that will be used in the actual contest, you need the source code of the 'knobeln' program (or must write something similar yourself). You will need a UNIX machine in order to compile and run it (or otherwise must make some simplifications in the code). This program was originally written in C-Refine. You will receive both a C-Refine and a pure C version. 3. 'protocolfmt' is a Perl script that formats the compact game protocols sent to you during the contest (if you request them) to the full format. There are two ways to get the source code of these programs (about 60 kB altogether): 1. by anonymous ftp (prefered method): Sanfrancisco.ira.uka.de [129.13.13.110]: /pub/knobeln94.tar.Z (22 kB) (in the directory /pub/knobeln93 on the same server you can also find several large files with the software and results of last year's Knobeln contest. I will NOT send these by mail) 2. by mailserver. Send email of the following form: To: prechelt@ira.uka.de Subject: SEND knobelnsoftware -------------------- The Actual Contest: -------------------- The actual contest will be run at the dates given below. At some time before, every team has to send its strategy as described above. It will be compiled and linked automatically, and you will receive a report about the success of this procedure or any problems that occur. This automatic compilation feature is disabled during the tournament. During the contest, all participants will receive information about what happens, if they have announced a corresponding mail-preference upon registration: - When the contest starts, the registration record of all participants is sent to all participants with mailpreference LAP. - When a group starts, a list of its participants (team names only) is sent to the members of this group with mailpreference LGP. - When a group is finished, - the game protocols of all games of participant X are sent to participant X if the participant has mailpreference DGP. - the game results of all games of participant X are sent to participant X if the participant has mailpreference GRP (superfluous if DGP is given). - the game results of all games of the whole group are sent to those participants that have mailpreference GRG. - the ranking of participants in the group is sent to those participants of the group that have mailpreference GRR. - When a round is finished a handwritten summary of all groups of this round is sent to all participants of the contest that have mailpreference RSM. These summaries will at least include all group ranking, so that RSM makes GRR superfluous. ------------------ The 1993 Contest: ------------------ A similar contest was run last year; 41 teams from 9 countries participated. The differences to this year's rules were: 1. Two tournaments were run, with a one-week pause in between during which the participants could change their strategy. 2. Strategies did not have to play against themselves. 3. The Knobeln evolution was not played. ------------- Legal Issues: ------------- By applying for registrations all members of a team assert that they understand and agree with the following points: The team members allow the organizer of the contest to publish all or part of the information contained in the strategy program and in the strategy description. Such publication will mention the contest context and will give credit to the team by mentioning (at least) the team name or the team's organization or the names of one or several team members. In particular, the team members allow the organizer to distribute freely the source code of the strategy programs after the contest. ---------------- Important Dates: ---------------- 94/03/22 beginning of registration 94/03/23 beginning of compilation service 94/05/15 9:00 UT registration deadline 94/05/15 11:00 UT end of compilation service 94/05/15 12:00 UT START OF CONTEST 94/05/21 Results posted to Usenet: rec.games.misc, misc.misc UT is Universal Time (also known as Greenwich Mean Time GMT). Note that registrations issued after 94/05/10 will be acknowledged only immeadiately before the deadline and that programs can be sent only after a registration is acknowledged. Good luck and have fun ! Lutz -- Lutz Prechelt (email: prechelt@ira.uka.de) | Whenever you Institut fuer Programmstrukturen und Datenorganisation | complicate things, Universitaet Karlsruhe; 76128 Karlsruhe; Germany | they get (Voice: ++49/721/608-4068, FAX: ++49/721/694092) | less simple. From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: The new Pizza server is great! Message-ID: Date: 14 Apr 1994 13:26:11 GMT In article <2oernj$g0i@cwis.isu.edu> fullanto@cwis.isu.edu (FULLMER_ANTONETTE) writes: > From: fullanto@cwis.isu.edu (FULLMER_ANTONETTE) > Subject: Re: The new Pizza server is great! > Date: 12 Apr 1994 19:10:43 PST-8 > > Could somebody post the address for the new server? My news reader > only keeps about the last 30 messages or so, it seems... > Also, instructions about how to post a warrior to the hill would be > extremely helpful. Thanks Following this message is an excerpt of the original posting. BTW, what's going to happen to _Push_Off_ and _The_'94_Warrior_, now that we have both Hills on the same site? It seems that there's a move to permanently phase out the '88 standard. My own experience is that the two remaining Hills (94 and 94-X) are significantly different. I feel that if there are going to be two "reviews", they should be _The_Small_Warrior_ and _The_Big_Warrior_ (OK, so I'm biased toward the big Hill :-) ). -------------------------------------------------------------------- To submit your corewar programs to the Pizza Hill, simply mail them to pizza@ecst.csuchico.edu with the subject of "redcode" or "koth". Due to the variety of services the Internet Pizza Server provides, your mail _must_ have a subject of "redcode" or "koth" or you will recieve an error message. This is easily done with the -s switch in most mailers. For example, if you usually used the command: "cat test.red | mail koth@stormking.com" to submit the same program to the Pizza Hill, you would use the command: "cat test.red | mail -s 'redcode' pizza@ecst.csuchico.edu" It's as simple as that. I am looking for input on the ICWS'88 Experimental hill. The most interesting idea I could think of is listed below, but I'm looking for better, more permanent ideas. Also, any ideas on the beginner's hill would be appreciated as well. Bug reports, ideas, and anything else you want to tell me should be mailed to sd@ecst.csuchico.edu, or to the Pizza Server with the subject of "bugs". and now, here are the specs of the various hills: ICWS'88 Standard Hill Specs: (Accessed with ";redcode") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '88 ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x") coresize: 4096 max. processes: 32 duration: after 65,536 cycles, a tie is declared. max. entry length: 64 minimum distance: 64 instruction set: ICWS '88 ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 maximum age: At age 100, warriors are retired. instruction set: ICWS '94 Draft ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x") coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: ICWS '94 Draft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~\/~~\ /~~~\/\ / \ \ / /~\ /~~~YY~~~\\ /~~~~ Thomas H. Davies V \/\ /\ V / V |\/\/| V\ / sd@ecst.csuchico.edu "Hard before beer, V \ / | / | V you're in the clear; \/ | /\ | Member C.W.M. beer before hard, Motto of |/oo\| Since 1987 you're in the yard." Chico State |/\| -------------------------------------------------------------------- See you on the Pizza Hill! -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: simon@cis.ufl.edu (Simon Mark Arthur) Subject: Death of the Intel hill Date: 14 Apr 1994 15:32:10 GMT Message-ID: <2ojnlq$m2e@snoopy.cis.ufl.edu> Goodbye, Intel hill. Thanks to wms. From: andre@targon.UUCP (Andre van Dalen) Subject: Pizza koth OK? Message-ID: <4245@targon.UUCP> Date: 14 Apr 94 16:10:27 GMT I send a test program Invest to the koth on pizza, and when I send it again I noticed that I had two on the hill, so I send a third one with a ;kill line in it. Then I saw that although all 3 programs are the same, one ended up with 110 points and the other two with 7 and 8! This cannot be correct, what is the matter here? -- The mail| AAA DDDD It's not the kill, but the thrill of the chase. demon...| AA AAvv vvDD DD Ketchup is a vegetable. hits!.@&| AAAAAAAvv vvDD DD adalen.via@sni.de --more--| AAA AAAvvvDDDDDD Andre van Dalen, uunet!sun4nl!targon!andre From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Announcing: Spring '94 EBS tourney (was Re: MNCT Round 3...) Message-ID: <1994Apr14.162256.14961@news.vanderbilt.edu> Date: Thu, 14 Apr 1994 16:22:56 GMT In article <2oi1e1$afv@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: >OK, this is it. I think that the time has come for MNCT to end... > [...], Alex MacAulay's program won't even compile because (apparently) >the "coresize" variable has been removed. [...] Not removed, but renamed to "CORESIZE" (identifiers are case-sensitive). > Michael Constant (mconst@soda.berkeley.edu) Anyway, thanks for holding the tournament. I particularly liked the "white warrior" problem and the prime-factorization round. We should repeat this some time, with fewer weeks between rounds. In the meantime, I am going to hold a double-elimination tournament with weekly rounds, just like the summer and fall tourneys of last year (soda.berkeley.edu:/pub/corewar/redcode/st93warriors.zip includes a rapport of this kind of tourney). Rules will alternate between '94 (coresize=8000) and '94x (coresize=55440) hill specs. If there's demand, I'll also throw in a pure '88 round. If there are enough participants, I'll divide them up into an A- and B-league (verterans and beginners). The submission deadline for round 1 is Friday, April 22nd. Rules are '94x (big) hill specs, and you may use the new opcodes. Your opponent in round 1 will be chosen randomly. And as though the fame was not enough incentive already, the tournament winner will receive a free ICWS membership and subscription to the newsletter for one year. -Stefan (stst@vuse.vanderbilt.edu) From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Uh-oh! Message-ID: Date: 14 Apr 1994 18:05:55 GMT Hey, you won't believe this. By mistake, I submitted my warrior, Twimpede+/8000-E.3b on the big hill at Pizza, where it was supposed to go on the 8K hill... and it scored 14th! I'm not kidding, there's no mistake in the name, it really *is* a warrior (my quite successful Twimpede/Variation series) tailored for the 8K core size! Interesting... -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: sd@ecst.csuchico.edu (Bruno Puntz Jones) Subject: The Pizza Hill Date: 14 Apr 1994 19:12:20 GMT Message-ID: <2ok4ikINNcod@charnel.ecst.csuchico.edu> The Pizza Hill is officially open for business until furter notice. Special thanks to Stefan Strack for all the help setting this monster up, and to all you out there who sent in your warriors and showed me this wasn't going to be a big waste of time. :) Here is a list of KotH related services. To access any of these, simply send mail to (pizza@ecst.csuchico.edu) with the service as the subject. info, help - Sends you a complete list of services and some helpful information on getting started. koth - Submit your corewar programs for challenge of the Pizza Hill. For more information try "koth info". Additional sub-commands are: submit - submit a warrior (default) help, info - mails you infomation on the Pizza Hill status - returns the current rankings of the hills faq - mails you the rec.games.corewar FAQ bugs, beej - Either will take your message body and forward it to beej@ecst.csuchico.edu (and others). Use this to send in bug reports. I am still looking for input on the ICWS'88 Experimental hill. The most interesting idea I could think of has recieved a total of three submissions in the last week (one of them from me :). Simply mail them to the Pizza Server with the subject of "bugs", or it might be better to discuss the ideas here. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~\/~~\ /~~~\/\ / \ \ / /~\ /~~~YY~~~\\ /~~~~ Thomas H. Davies V \/\ /\ V / V |\/\/| V\ / sd@ecst.csuchico.edu "Hard before beer, V \ / | / | V you're in the clear; \/ | /\ | Member C.W.M. beer before hard, Motto of |/oo\| Since 1987 you're in the yard." Chico State |/\| From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: The Pizza Hill Message-ID: <1994Apr14.194620.20014@news.vanderbilt.edu> Date: Thu, 14 Apr 1994 19:46:20 GMT In article <2ok4ikINNcod@charnel.ecst.csuchico.edu> sd@ecst.csuchico.edu (Bruno Puntz Jones) writes: >I am still looking for input on the ICWS'88 Experimental hill. The most >interesting idea I could think of has recieved a total of three submissions >in the last week (one of them from me :). [...] > Thomas H. Davies V \/\ /\ V / V |\/\/| V\ / How about a "chaos" or "random" hill: for each submission, pick a coresize at random, but within a given interval. Other parameters are calculated based on the random coresize value: max processes = coresize cycles = coresize * 10 max length = coresize < 32768 ? 100 : 200 min distance = max length (just an example) Since you can use CORESIZE, MAXPROCESSES, etc. in your warrior, writing efficient code for the random hill shouldn't be too taxing. BTW, this better be a ICWS'94 draft hill, because MUL and DIV can make your life a lot easier. -Stefan (stst@vuse.vanderbilt.edu) From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Genetic Algorhithms in Corewar Date: 14 Apr 1994 20:56:13 GMT Message-ID: <2okald$7qt@agate.berkeley.edu> Mike Reddy wrote: > Anyone know of any GA approaches to 'evolving' corewar warriors? I have a > student who is interested in developing a system of cross-over production > of code from parent warriors to run in the corewar environment; it being > not advisable to have real viruses evolving on a computer 8-) Hmmm... this is a neat idea, but I don't think that it would work. First of all, most corewar algorithms are blatantly incompatible with each other and would not work well together in a single program. But even if you eliminated this difficulty by sticking to a single type of program (say, try to evolve the perfect replicator) I still don't think that any genetic approach, esp. not crossover, would work because most (good) programs are very tightly integrated. You can't take the arm of one and the leg of another, even if one has a good reach and the other can jump high. > We would probably need to get some source code for the > corewar program so that we could insert the creation aspects of the code and > then run them to determine survival from within the program, rather than > loading them up manually (which would slow down the number of generations > that can evolve over a given time). We have access to PCs Macs and Suns > though I would prefer the student to use a Mac platform. The source code for several corewar simulators is easily available, and could be modified to allow evolution of warriors. However, I think that I see another problem here: any reasonable fitness test for a corewar program will take a long time even on a Sun; and on most macs and PC it would be *really* slow. This is because the only fitness test I can think of is to run the test program against lots of standard warriors, and see how well it does. The "industry standard" for fairness is to run 100 rounds; suppose (for speed, at the price of accuracy) we reduce it to 50 rounds just for testing (and this will increase the random effects and make the final evolved programs (slightly) worse). I personally like to test my programs against 6 or 7 standard opponents, and I think this is reasonable. So, we end up with 50 battles each against 6 warriors, for a total of 300 rounds to evaluate one test program. On my PC, 300 rounds (in pMARS) takes about 10-15 minutes... at that rate it'll take a l...o...n...g... time to evolve anything good. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Pizza koth OK? Date: 14 Apr 1994 21:05:33 GMT Message-ID: <2okb6t$7vd@agate.berkeley.edu> In article <4245@targon.uucp>, Andre van Dalen wrote: >I send a test program Invest to the koth on pizza, and when I send it >again I noticed that I had two on the hill, so I send a third one with >a ;kill line in it. > >Then I saw that although all 3 programs are the same, one ended up with >110 points and the other two with 7 and 8! Don't worry, this is normal. When you kill a program the koth server doesn't actually kick it off the hill, it just assigns it a ridiculously low score and assumes that the next program submitted will knock it off. So, the two "dead" versions of Invest should be knocked off the hill as soon as someone else submits a program to that hill. BTW, this is not peculiar to the pizza hill: all of the hills behave this way. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: pk6811s@acad.drake.edu Subject: Re: Redcoder 2.0 Message-ID: <1994Apr14.183446.1@acad.drake.edu> Date: Fri, 15 Apr 1994 00:34:46 GMT Hooray!!! Paul Kline pk6811s@acad.drake.edu From: morrell@math.utah.edu (Steven C. Morrell) Subject: B-Panama V Date: Fri, 15 Apr 1994 17:17:00 GMT Message-ID: Here is the source for B-panama V, a stone with paper backup. It reached the age of 107 on the Intel hill before the Great Core Dump, and is now hovering about 10th on the standard Pizza Hill. The stone hogs most of the processes, so even if a copy of the paper gets stunned, the stone can often grind out a win. If all runs smoothly, the stone will do an addition core-clear and then commit suicide. The bits of imp-killing paper then take over. The key of this paper is that it must be virulent enough to survive attacks form both the stone and the other program, even when slowed down. Here's how it does on the Pizza Hill: Keystone t21 53/10/37 Christopher 47/42/11 SJ-4a 42/30/28 Dragon Spear 41/45/14 Iron Gate 1.5 38/49/13 Juggernaut v1.5 38/49/13 Night Crawler 35/ 5/60 Vanity II 35/44/21 Request v2.0 33/33/34 B-Panama V 24/ /55 CAPS KEY IS STUCK AGAIN 22/30/48 Killer instinct 18/16/66 FlyPaper 3.0 13/21/66 Impact v1.0 11/ 7/82 Montage 11/13/76 Yop La Boum v2.1 10/29/61 Der Zweite Blitzkrieg 10/37/53 ttti 6/ 7/87 Deck of Many Things 6/34/60 Patapouf v2.0 3/13/84 ;redcode verbose ;name B-Panama V ;author Steven Morrell ;strategy Let's see if we can pick on some imps... ;strategy Version 5- complete overhaul of stone and paper. stone spl 0,<-50 spl 0,<-51 mov <3359,-3359 add 2,-1 djn -2,<-54 dat <3359,<-3359 boot mov stone+5,-200+5 mov stone+4, One that writes to the core display in such a way as to spell out the message: "Terminate the others!" Sorry if this is a really old (and no longer funny) idea, but I just thought of it. And it wasn't in the FAQ. David Norman (dnor01@cs.aukuni.ac.nz) " Of course, I see things like this...X-| " - policeman from the Young Ones From: pk6811s@acad.drake.edu Subject: Re: KotH server at ssd.intel.com down Message-ID: <1994Apr16.171558.1@acad.drake.edu> Date: Sat, 16 Apr 1994 23:15:58 GMT > Well, it's been three days since the KotH server at my site got any > mail, so I guess that the traffic has moved to the new Pizza server. > I'll be taking my server down now; thanks everybody who used it, and > thanks to Tom Davies for setting up the replacement! Bye! > -Bill (wms@ssd.intel.com) > Thank you Bill, for being the first. Paul Kline pk6811s@acad.drake.edu Date: Sun, 17 Apr 1994 22:44:34 MST From: Message-ID: <94107.224434AHNAS@ASUACAD.BITNET> Subject: Re: Genetic Algorhithms in Corewar There is an articel about this on soda. Check it out. I don't think it's a good idea to test evolving warriors against hand written warriors. It would'n show too much. An evolving warrior doesn't have a chance. So the evolving warriors should be tested against each other. Nandor. From: macaulay@kakadu7.ecr.mu.oz.au (Alexander_William MACAULAY) Subject: Re: MNCT Round 3... Message-ID: <9410811.8744@mulga.cs.mu.OZ.AU> Date: Mon, 18 Apr 1994 01:51:11 GMT In article <2oi1e1$afv@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: >OK, this is it. I think that the time has come for MNCT to end... maybe this >view is partially caused by the fact that I couldn't run round 3 with >pmars0.4 because it kept crashing with a segmentation fault (I assume this >is due to the bug mentioned in the whatsnew.050 file). However, with the >new version, Alex MacAulay's program won't even compile because (apparently) >the "coresize" variable has been removed. Unfortunately his program >depended on the coresize variable and won't even get close to running >without it (am I right, Alex?) Yep, that's right. One option would be for you to put a 'coresize equ ...' at the top of the program. Anyway, I thought that you had already run the round 3 and posted the results some time ago. If this is the end, I'd like to say that I've enjoyed participating in this tournament and that it was quite unique in the variety of its rounds. I hope to see something like this again in the future. Alex MacAulay (macaulay@ecr.mu.oz.au). From: koo1068@acfcluster.nyu.edu Subject: posthow do I access these Date: 18 Apr 94 11:36:26 EST Message-ID: <1994Apr18.113626.1@acfcluster.nyu.edu> someone write me and tell me how to access the games Core War and King of the Hill (if they are even 2 separate games.) I program, I think I'd find them interesting. thanks From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: MNCT Round 3... Date: 18 Apr 1994 19:01:26 GMT Message-ID: <2oule6$59b@agate.berkeley.edu> Alexander_William MACAULAY wrote: > Anyway, I thought that you had already run the round 3 and posted the > results some time ago. The results you saw were only for the first coresize I used in testing. Since it was a variable coresize round, I thought it would only be fair to run it in more than one coresize, to get an accurate impression of how well the different programs do. However, the first coresize I used (the one you saw the results for) was small (I don't remember the number) and pmars crashed as soon as it was in a big coresize so I couldn't run the rest. > If this is the end, I'd like to say that I've enjoyed participating in > this tournament and that it was quite unique in the variety of its rounds. > I hope to see something like this again in the future. Glad you enjoyed it! -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: tomw@bingsun2.cc.binghamton.edu (Thomas Whittaker) Subject: Slope 3D? Date: 18 Apr 1994 20:53:35 -0400 Message-ID: <2ova2f$ach@bingsun2.cc.binghamton.edu> Does anyone have or heard of Slope 3D? It is some sort of graphics demo of slope rendering. Tom Whittaker From: bdthomse%peruvian.cs.utah.edu@cs.utah.edu (Brant Thomsen) Subject: The '94 Warrior Date: 18 Apr 94 23:46:26 MDT Message-ID: <1994Apr18.234626.6872@hellgate.utah.edu> __ __| | ) _ \ | | \ \ / _) | __ \ _ \ / ( | | | \ \ \ / _` | __| __| | _ \ __| | | | | __/ \__ |___ __| \ \ \ / ( | | | | ( | | _| _| |_|\___| _/ _| \_/\_/ \__,_|_| _| _|\___/ _| April 18, 1994 Issue #6 ______________________________________________________________________________ This newletter covers the current status of the ICWS '94 Draft hills, and also attempts to keep up with the latest ideas in how the new standard will affect corewars in general. I hope you enjoy it! If you are unfamiliar with the '94 draft standard, you can learn more about it by reading the FAQ for this newsgroup. In addition, the program pMARS includes a highly recommended tutorial on the new standard. Feel free to send me e-mail if you have any difficulty finding either of them, if you need to have a corewar item mailed to you, or if you have any other questions. The FAQ is available through anonymous FTP to rtfm.mit.edu, as /pub/usenet/news.answers/games/corewar-faq.Z ______________________________________________________________________________ CHANGES and CORRECTIONS: There have been several changes since the last issue of _The_'94_Warrior_ came off the electronic presses. With luck, I'll manage to get most of them. The first big event is the addition of two (or three) new opcodes for version 0.5 of pMARS. It was recently downloaded to soda.berkeley.edu (in the pub/corewar/incoming directory). Even if you don't think you will ever need to use SEQ, SNE, or NOP, there are a couple of bug fixes that make it worth the effort to upgrade. The another big event is the creation of a new hill server, "pizza". "Pizza" is operated by Thomas Davies, and he's doing a great job at it! Most of the programs residing at the "Intel KotH" and "stormking" have already managed to migrate over, and there are several new programs on "pizza" as well. The "pizza" hills eliminate the major complaint users had with the "stormking" hills: you no longer need to wait a day or two to get back the results of a warrior submission. (The process of submitting a warrior to a hill on "pizza" is covered in the latest FAQ for the rec.games.corewar newsgroup. Send me mail if you didn't receive a copy of it.) Along with the creation of the "pizza" server came the passing of the Bill Shubert's hill at Intel. Thanks, Bill, for the many years you have used your resources to allow the rest of us to hone our corewars skills. The game has improved greatly because of your efforts! You'll also want to catch the first chapter of Steven Morrell's "MY FIRST COREWAR BOOK". It's on soda.berkeley.edu in the pub/corewar/incoming directory as "chapter1.Z". Even if Steven didn't mention my name in it and he attended some school other than the University of Utah, I would still recommend it. It's that good! For those of you developing warriors in large core sizes, the upgraded version of Optima I mentioned in the last issue is now available on soda. If you are experimenting with different core sizes (like the small core on "pizza", this program is a necessity.) And, for those of you with a competitive streak, I would highly encourage you to enter Stefan Strack's upcoming corewar tournament. In case you missed the announcement, here it is again: In the meantime, I am going to hold a double-elimination tournament with weekly rounds, just like the summer and fall tourneys of last year (soda.berkeley.edu:/pub/corewar/redcode/st93warriors.zip includes a rapport of this kind of tourney). Rules will alternate between '94 (coresize=8000) and '94x (coresize=55440) hill specs. If there's demand, I'll also throw in a pure '88 round. If there are enough participants, I'll divide them up into an A- and B-league (verterans and beginners). The submission deadline for round 1 is Friday, April 22nd. Rules are '94x (big) hill specs, and you may use the new opcodes. Your opponent in round 1 will be chosen randomly. And as though the fame was not enough incentive already, the tournament winner will receive a free ICWS membership and subscription to the newsletter for one year. -Stefan (stst@vuse.vanderbilt.edu) Just in case those prizes are not good enough for you, I will also throw in a free one-year subscription to _The_'94_Warrior_ for the winner. Seriously though, Stefan always does a great job with his tournaments, and I heartily recommend you give this one a try. ______________________________________________________________________________ The ICWS '94 Draft Hill: Core size: 8000 instrucitons Max processes: 8000 per program Duration: After 80,000 cycles, a tie is declared. Max entry length: 100 instructions The current ICWS '94 Draft hill: # %W/ %L/ %T Name Author Score Age 1 45/ 20/ 34 Der Zweite Blitzkrieg - 9 Mike Nonemacher 170 13 2 47/ 31/ 21 Sauron v1.7 Michael Constant 163 3 3 42/ 30/ 28 Killer instinct Anders Ivner 154 64 4 46/ 41/ 13 Dragon Spear c w blue 151 63 5 36/ 22/ 42 Lucky 3 Stefan Strack 150 23 6 43/ 36/ 21 Request v2.0 Brant D. Thomsen 149 61 7 45/ 43/ 12 Iron Gate 1.5 Wayne Sheppard 148 7 8 31/ 17/ 53 Blue Funk Steven Morrell 145 30 9 33/ 21/ 46 Twimpede+/8000-E.2c Jay Han 144 17 10 32/ 21/ 47 Imperfection v3.1 Michael Constant 142 15 11 34/ 26/ 40 NC 94 Wayne Sheppard 142 43 12 31/ 24/ 44 Splash Jay Han 139 1 13 38/ 38/ 25 NTA 94 Wayne Sheppard 137 51 14 40/ 43/ 17 Test Stefan Strack 137 26 15 40/ 42/ 18 Sylvester v1.0 Brant D. Thomsen 137 60 16 38/ 41/ 22 Fast Food v2.1 Brant D. Thomsen 134 58 17 34/ 34/ 32 Match Stick c w blue 133 41 18 31/ 32/ 37 Little Flea v1.2 Michael Constant 129 5 19 38/ 49/ 13 Dagger v6.0 Michael Constant 126 67 20 32/ 45/ 23 Assassin v1.0 Michael Constant 119 20 For this issue, I was planning to post the results of both the "stormking" and "pizza" '94 hills. However, as I haven't gotten back the results of the queries I sent to "stormking" almost four days ago, I decided to simply make a clean switch to pizza this month. Send any complaints to the editorial board. I believe most of the programs that are on the '94 draft hill on "stormking" have made it over to "pizza". Next issue, after things have settled down a little bit on the new hills, I will attempt to analyze what is happening. ______________________________________________________________________________ The ICWS '94 Draft Experimental Hill: Core size: 55,440 instructions Max processes: 10,000 per program Duration: After 500,000 cycles, a tie is declared. Max entry length: 200 instructions The current ICWS '94 Experimental (Big) hill: # %W/ %L/ %T Name Author Score Age 1 49/ 15/ 36 Variation G-1 Jay Han 182 1 2 47/ 15/ 38 Variation E-2.c Jay Han 178 13 3 44/ 16/ 39 Splash 1 Jay Han 172 2 4 45/ 22/ 32 Lucky 13 Stefan Strack 168 43 5 49/ 32/ 20 Request-55440 Brant D. Thomsen 165 37 6 35/ 18/ 47 Imperfection v2.4 Michael Constant 153 8 7 47/ 41/ 12 Rave B4 Stefan Strack 153 29 8 45/ 42/ 13 Virus Jay Han 148 3 9 44/ 43/ 13 bigproba nandor sieben 145 41 10 42/ 46/ 12 Scanalyzer-W Jay Han 138 4 11 42/ 46/ 13 Scanalyzer-V.3b Jay Han 138 11 12 35/ 33/ 32 Big Flea v1.1 Michael Constant 137 7 13 38/ 46/ 15 amoeba v82 Richard van der Brug 131 18 14 38/ 47/ 15 Dagger v8.0 Michael Constant 130 24 15 38/ 46/ 16 Sunburst 33 Jay Han 130 31 16 30/ 31/ 38 Nova-A.1b Jay 129 12 17 29/ 32/ 39 Skimp 127 Jay Han 127 30 18 34/ 42/ 23 IceCube 1.4 Richard van der Brug 126 17 19 32/ 40/ 28 Veeble Jr. T. H. Davies 125 27 20 36/ 51/ 13 Kill Imps!!! Steven Morrell 121 26 The comments for the other hill apply here as well. ______________________________________________________________________________ HINTS and HELPS: For today's hint, I will be using the source code to "Request v2.0" for the 55440 size '94 hill. "Request" is very similar to my earlier "Distance" vampires (I know, I'm stuck in a rut ...) with the exception that the fangs use indirect addressing instead of direct addressing to send the processes to the pit. By using a two line piece of code that contuously rewrites the reference value used by the fangs, I can "undo" any damage caused by standard anti-vampire programs. * * * Writing code for a large coresize provides an interesting challenge. Possibly the most frustrating thing about it is that it is hard to display and analyze 55440 locations. I find that, more than ever, I am forced to rely on other programs to help me generate the information I want for my corewars warriors. For instance, when I wanted to make the '94 version of my vampire "Request" run in the 55440 coresize, I tried several things to make the process easier. As you may have guessed by reading the last issue of _The_'94_Warrior_, one of the first programs I used was "Optima" by Michael Constant. This, however, was just the beginning. Take a look at the following "c" code: /* Determine coverage with different RedCode spacing for bombers */ #include #include #define WIDTH 80 int main(int argc, char *argv[]) { long sp, coresize, first, step, lines = WIDTH+1, printed, count; int i, core[WIDTH]; if (argc < 4 || argc > 5) { printf("\nUsage: %s coresize step first [lines]\n", argv[0]); return 0; } coresize = atol(argv[1]); step = atol(argv[2]); if(step < 0) step += coresize; first = atol(argv[3]); if(argc > 4) lines = atol(argv[4]); for(i = 0; i < WIDTH; i++) core[i] = 0; printed = 0; sp = first; count = 0; printf("%ld:\n", step); do { if(sp >= 0 && sp < WIDTH) { core[sp] = 1; for(i = 0; i < WIDTH; i++) if(i == first) printf("@"); else printf("%c", core[i] ? '*' : ' '); printed++; } sp += step; sp %= coresize; count++; } while(sp != first && printed < lines); printf("\nMod: %ld\n", coresize / count); return 0; } This program simply takes an imaginary chunk of computer core with a given starting point and step size, and plots how that piece of core will be hit up as the bombing progresses. Then I was able to simply take the pieces of request and fit them into the spaces that were hit latest. (Since my computer screen is 80 columns wide, I simply used that size of core. Feel free to change WIDTH as appropriate.) In the output, the "@" indicates the very first location bombed (if it is in the range printed). Of course, you can also make that the last location bombed by simply adding one step value to your starting value. Also, take a look at the bootstrapping code itself. By using the "FOR" macro, and using the "SUB" statements in my bootstrapping code, it is trivial to change the locations of the different parts of the vampire, because the distances between them are automatically computed by the boot-strapping code based on the number of "DAT" statements between the segments. I can even change the order of the segments without touching my bootstrapping code; I simply use the cut an paste tools in my editor to rearrange the segments as I wanted them. The end result: a competitive program that I have never run inside of a size 55440 core. Is this a good way to go about it? I have no idea. It is, however, an excellent example about how much trouble some people will go to to avoid a little bit of work. * * * ;redcode-94x ;name Request-55440 ;author Brant D. Thomsen ;strategy '94 Vampire ;strategy The latest program in my "quest" ;strategy to yield less wins to anti-vampiric programs. ;strategy Submitted: @date@ step equ 9719 init equ (pit+1+step) gate equ (jump-12) decoy equ (gate-1+step) FOR 132 dat #start*10, #1 ; Provide a large decoy. ROF start mov jump, adder-2 FOR 9 dat #start*10, #1 ROF help mov #pit-decoy, decoy jmp help, Subject: '94 redcode Date: Tue, 19 Apr 1994 00:18:47 -0400 Message-ID: <8hgpibO00WB3FLSmcb@andrew.cmu.edu> OK, I'm (finally) moving into the '94 standard, and I came upon one major hitch: I have 4 programs to test against - all of which came with pMARS! I haven't seen any code for '94 warriors here, other than the 2 or 3 examples from the Big Hill. I'll post the source for Der Zweite Blitzkrieg as soon as I get around to making it post-worthy, but it'd be nice if there were a few more examples of successful '94 redcode for testing. Just an idea... And while I'm on the subject (or close...), I hafta throw in my comments on the big hill. It seems to me like there's nothing to limit the proliferation of stone-spiral combos. As a few other people have observed, paper warriors don't last at all on the big hill, so it doesn't seem like there's enough variation. Is this as true as I'm representing? Of course, I haven't touched the big hill yet, so I'm not one of the more informed on this topic, but that's my impression. Any opinions? Mike Nonemacher mn2f+@andrew.cmu.edu From: kgliner@netcom.com (Kevin Gliner) Subject: Re: Slope 3D? Message-ID: Date: Tue, 19 Apr 1994 21:30:11 GMT You can get Slope3d off of CIS or GEnie. It's an example of one method for combining height-mapping with raycasting. No source is included. I would have uploaded it o the internet, but I'm not familiar with the particulars of file transfers on the net. From: mconst@soda.berkeley.edu (Michael Constant) Subject: More Source Postings Date: 19 Apr 1994 22:13:24 GMT Message-ID: <2p1l24$35l@agate.berkeley.edu> Here is the source for all the programs (mostly quite bad) that I've submitted recently to the standard '94 hill at pizza. I would encourage everyone else out there to post the code even for your bad programs, because often others can profit by your mistakes and even improve your programs to the point where they become really viable. First and foremost is Sauron v1.8, currently a strong second place on the Pizza '94 hill. (Don't you just *love* it when people (like me) are soooooo nice (like me) that they post their prize program as soon as it gets a good score on the hill?) Sauron is a combination program, with the main feature (at least the one which takes up the most space in the code) being the quick-scan (label "look"). If it finds anything with the quick- scan, Sauron will bomb it with spl/jmps (as documented in the program, I got the idea (and a bit of the implementation) for spl/jmp from Mike Nonemacher's Blitzkrieg (I was using spl-carpet, which didn't work as well because it covered less distance in the same amount of time)). After the spl/jmp bombing, Sauron will do a double coreclear which degenerates into a hyperperfect gate (the name I made up just now for a gate which will keep out gate-crashing imps; so-called because it's even more perfect than the standard "perfect" gate.) However, if no enemy is found with the initial quick-scan, Sauron will launch a 3x2 imp-spiral (3 points, 2 layers) and a stone with a partial coreclear (it wipes *almost* the entire core, but it commits suicide right before the last bit is done. I don't consider this to be a serious problem, especially with the imps around to clean up anything the stone leaves). Before you ask: this program was *not* based on Blitzkrieg. In fact when I was writing it I thought it was unique until I took another look around my piles of source listings (yeah, they're on my computer, but they're piles nonetheless... I can be a slob electronically too :-) and found Blitzkrieg. That's when I got the inspiration to change the quick-scan bombing from spl-carpet to spl/jmp. Oh yeah, you were wondering where the poem in the strategy section came in: well, Sauron was called the "Lord of the Rings" and this program was originally designed to beat imps (it actually ended up doing better against scanners). Okay, it's a lame attempt at humor, but *I* thought it was funny... One last thing: I have not tried to make this program easy to read. I'm just posting it as is, so you can have the benefit of seeing it as soon as possible. If you don't understand how some bit of it works, please mail me, I'd be happy to answer any questions you may have. (Among other things, it would mean to me that someone actually read the source to my program and cared about it! Wow!) Besides, it gives me an excuse *never* to clean up the code, since (I can say) I've already posted it, so why bother? :-) Anyway, without further ado: ;redcode-94 ;name Sauron v1.8 ;author Michael Constant ;strategy "Three Rings for the Elven-kings under the sky, ;strategy Seven for the Dwarf-lords in their halls of stone, ;strategy Nine for Mortal Men doomed to die, ;strategy One for the Dark Lord on his dark throne ;strategy In the Land of Mordor where the Shadows lie. ;strategy One Ring to rule them all, One Ring to find them, ;strategy One Ring to bring them all and in the darkness bind them ;strategy In the Land of Mordor where the Shadows lie." ;strategy -- J.R.R. Tolkien, _Lord_of_the_Rings_ ;macro DIST equ 2300 cclear mov split, <-10 ; lazy man's two-pass coreclear :-) jmz.a cclear, last+10 split spl #11, <-30 mov bomb, <-5 jump jmp -1, <-32 f impgen spl 1, stone+4+1 mov -1, 0 spl 1 spl 2 jmp @0, imp add #2667, -1 bomb dat <-31-2668,<-31 ; is this right? I'm not very familiar ; with gate-breaking imps but it seems to ; work against Cannonade. look qscan for 36 ; this would be 38 if there was enough room in the program cmp.x look+((qscan+1)*100), look+4000+((qscan+1)*100) mov.ab #20+look+((qscan+1)*100)-found, @found rof found jmz blind, #0 zap mov.i jump, @found mov.i split, scan count djn -1, #0 jmp scan, 0 [ big DAT 0, 0 spacer removed ] which dat 0, #split split spl -1, #-22 The Red Carpet was my first attempt at a carpet-bombing cmp-scanner, and I don't think I need to post it because it had no innovations and there are a lot of better cmp-scanners out there. Imperfection v3.1 (for regular core) is a standard stone/imp combo. Note the decoy at the *beginning* to confuse any program which assumes decoys at the end (I know several programs which do this but I can't call them to mind right now -- sorry). The coreclearing stone is awful code, but it works... the one in Sauron (qv.) is a lot better (at least vs. scanners). Maybe I should replace it, but I haven't gotten around to trying yet. ;redcode-94 ;name Imperfection v3.1 ;author Michael Constant ;kill Imperfection ;strategy standard stone/spiral ;macro DIST equ 2500 STEP equ 889 IMPBOOT equ 400 org boot foo decoy for 74 spl.i #500+(decoy*3), #decoy+1 rof boot mov stone, stone+DIST mov stone+1,stone+1+DIST mov stone+2,stone+2+DIST mov stone+3,stone+3+DIST mov stone+4,stone+4+DIST mov bar, stone+DIST+4+76 mov bar, stone+DIST+4+75 spl stone+DIST, <-2000 spl stone+DIST, <-3000 launch mov imp, imp+IMPBOOT spl 1, <-2000 mov -1, 0 mov -1, 0 mov -1, 0 spl 1, <-3000 spl 1, <-4000 spl 2, <3000 jmp @0, imp+IMPBOOT add #STEP, -1 bar dat #1, #10 stone mov.i 76 imp mov.i #0, STEP Whew! That's it, I think. Well, I hope to inspire another round of source postings -- there have been a lot of new programs recently. Does anyone else want to reveal their secrets? -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: IZZYVD5@MVS.OAC.UCLA.EDU Subject: PMpmars for OS/2 Date: Tue, 19 Apr 1994 23:00 Message-ID: <19940419230028IZZYVD5@MVS.OAC.UCLA.EDU> My friend is getting along on his GUI version of PMARS.... C He wants suggestions. He is Jason, reachable at: p30bjrk@pic.ucla.edu It's at least as fast as the windows one (WinCore) and it'll be free (unlike WinCore) like all the other pMars versions. (He also would like to know if Stefan Strack got his mail...) From: ENG_WWE@LUB001.LAMAR.EDU Message-ID: <940420002802.40402619@LUB001.LAMAR.EDU> Subject: New to Corewar, help me please:) Date: Wed, 20 Apr 1994 0:28:01 -0500 (CDT) Hello all, and yes I have read the FAQ:) I also have gotten the corewar tutorial from soda.intel.com. I have even gone so far as to download _c88v49_ to run on the machine I have at the moment. I now have three questions: 1)Is there a good guide to the theory or design behind _redcode_ programs? Something that will help a layman like myself better understand the concept behind what is going on in the core? (I have a little programing exp in BA**C and QuickBA**C and have just started learning assembly for the 80?86 processor). 2)Where is there a KOTH I can send my program to and what is the etiquet for sending programs (such as how advanced do your programing skills need to be before you submit to KOTH)? 3)Is there a listing of old _redcode_ programs that can be studied (or is there anyone out there willing to send me some of their code)? 4)(With math like this I may never be able to program) Is there a mailserver that echos this newsgroup? I do not seem to get this newsgroup (or any rec. games.* for that mater) where I am. Thank your for your time and bandwidth. Sorry about the length of both text and ignorance in this post. Warren Eckstein GO-d+pc++++luu-e+m---s+/+n-h---f?!gw+try** eng_wwe@lub001.lamar.edu From: mconst@OCF.Berkeley.EDU (Michael Constant) Subject: Re: '94 redcode Date: 20 Apr 1994 01:37:26 GMT Message-ID: <2p210m$7sb@agate.berkeley.edu> In article <8hgpibO00WB3FLSmcb@andrew.cmu.edu>, Michael N Nonemacher wrote: >And while I'm on the subject (or close...), I hafta throw in my comments >on the big hill. It seems to me like there's nothing to limit the >proliferation of stone-spiral combos. As a few other people have >observed, paper warriors don't last at all on the big hill, so it >doesn't seem like there's enough variation. How can you complain? There are *two* copies of Variation on the Big Hill right now! :-) But seriously, there are several programs to do nasty things to imps. First of all, any program called "Kill More Imps!!!" (Steven Morrell) can't be exactly cooperative with imp spirals (although it never seems to beet Imperfection...) and my own Sauron v2.0 (now in testing on the Big Hill) is also not kind to them. The imps *will* die, never fear. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: Michael N Nonemacher Subject: Der Zweite Blitzkrieg source Date: Wed, 20 Apr 1994 14:29:51 -0400 Message-ID: OK, as promised, here's the source to Der Zweite Blitzkrieg. Any questions about how it works, E-mail me at "mn2f+@andrew.cmu.edu". Here 'tis: ;redcode-94 ;name Der Zweite Blitzkrieg - 94 ;author Mike Nonemacher ;strategy quick-scan -> stone-spiral -> 2-pass coreclear -> gate ;strategy Only very minor mods from '88 version ;kill Der Zweite ;Real strategy: ;Quick-scan, spl/jmps what it found. Nimbus-style 7-point spiral launch. ;Slightly adapted Blitzkrieg stone (had to make it self-splitting), bombs ;itself to turn itself into a spl/dat coreclear -> gate. Has at minimum ;around 130 processes in gate, with 15 in the spiral, so I have at least a ;90% gate, but the gate also adds processes constantly, so it's usually ;more than that. Since I don't bomb myself with the stone's split, I can ;sustain a hit to either the stone's spl 0 or jmp -2. ;The stone should give me a winning record against scanners, and the spiral ;makes sure I at least tie other stones (without gates) and spirals. The ;spl/dat coreclear should kill paper (as well as the quick-scan, since no ;one ever has only one copy of their paper anymore), and the 7-point spiral ;will thwart most anti-imp strategies (Iron Trap, 3-point coreclear (Iron ;Sword), 3-point decrement (Imprimis 7), and most anti-imp paper). BOOT EQU 3405 ;Just picked this one at random C EQU 328 ;bombing increment - small, mod-8 GVAL EQU -19 ;decrement for gate INCR EQU 20 ;offset of inc from stone PTR EQU -11 ;offset of ptr from stone+4 I EQU 1232 ;offset of start of spiral from imp D EQU 1143 ;7-point spiral CMP1 EQU (start-2)*SC/2+CMPST ;EQUs for quick-scan CMP2 EQU CMP1+4000 MOV1 EQU (start-1)*SC/2+CMPST-BPTR+67 BPTR EQU bptr1 ;point 67 past what we found SC EQU 112 ;only 34 scans would fit :( CMPST EQU start+33 ;make sure stone doesn't kill spl/jmps start for 34 cmp.i CMP1, CMP2 ;Quick-scan mov.ab #MOV1, BPTR rof bptr1 jmz.b ok, #0 ;skip if we didn't find anything mov.i jump, GVAL stone sub.f stone+INCR, 1 mov.i <-19, 1 jmp.f -2, >split+GVAL mov.i @PTR, GVAL-2 gate dat.f >GVAL-1, #0 isp mov.i imp, imp+I mov.i inc, top+BOOT-4+INCR spl 1 spl 1 spl 1 mov.i -1, 0 ;generate 15 consecutive processes src spl 2, #jump+1 jmp @0, imp+I add.ab #D, -1 inc dat.f #C, #-C END start From: Michael N Nonemacher Subject: Re: Der Zweite Blitzkrieg source Date: Wed, 20 Apr 1994 16:25:13 -0400 Message-ID: Oooosp! The code I posted won't quite work. All it needs to work is the addition of ";macro" after the ;kill line. Enjoy! From: cb15955@academia.swt.edu (karo) Subject: close Date: 20 Apr 94 18:43:27 CST Message-ID: <1994Apr20.184327.1@academia.swt.edu> I just downloaded the pmars05.zip file from soda (using bin mode or course) and when I unzip it, it lists all of the filenames but is says "unknown compression method" beside each one. I've talked to the local gurus and they said I should direct the question to the one who compressed the files in the first place to find out what version was used. Can anybody help? I don't know who put it there, or else I would've asked via e-mail. karo -- ???????????????????????????????????????????????????????????????????????????? Corey Barton "karo" CB15955@academia.swt.edu I'm not really an idiot... but I play one on TV! ???????????????????????????????????????????????????????????????????????????? From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: EBS Spring Tournament deadline approaches Message-ID: <1994Apr20.195548.6192@news.vanderbilt.edu> Date: Wed, 20 Apr 1994 19:55:48 GMT Last call for submissions to the Spring EBS double-elimination tournament starting this Friday, April 22. Again, rules for the 1st round are that of the 94x (big) hill, i.e.: coresize: 55440 cycles: 500000 max procs: 10000 max length: 200 min distance: 200 standard: ICWS'94 draft + SEQ,SNE,NOP (round 2 on April 29 will be "standard" hill specs) Like last time, I will send the code for all entries, along with the player pairings for the upcoming round to all participants as soon as the round is played. You can send a new warrior for the next round or tell me to use your previous one. Please include a ;contact line in your submission and indicate whether you want the warrior sources as uuencoded tar.Z or zip archive. Send your entry (one per person) to stst@vuse.vanderbilt.edu by Friday, 20:00 CDT (no late entries). I will run the 1st round Friday night and post/mail out results Saturday or Sunday. I especially encourage beginners to participate. This is your chance to get your hands on some top-quality Redcode. Also, the one-on-one format of this tournament makes it possible to win with highly specialized warriors that might never make it onto the hill. -Stefan (stst@vuse.vanderbilt.edu) From: mconst@soda.berkeley.edu (Michael Constant) Subject: '94 Standard Date: 20 Apr 1994 22:02:59 GMT Message-ID: <2p48qj$5al@agate.berkeley.edu> I have nothing in particular to say in this post, just a miscellaneous comment that might start a thread: I think that the '94 standard is really coming into its own. About a month ago, any good '88 program could do well on the '94 hill. However, by now, even programs at or near the top of the '88 hill are having trouble doing well against '94 programs. (I noticed this because, for some reason, there have been many '88 and pseudo-88 programs submitted to the '94 hill recently. A pseudo-88 program (my name) is one which was written for '88 and later ported to '94, but which probably does not take advantage of all the available features.) This is good, it means that people are really finding ways to use the new standard. Just thought people might want to know.. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: Michael N Nonemacher Subject: Re: '94 Standard Date: Thu, 21 Apr 1994 00:02:10 -0400 Message-ID: <0hhTf2u00WB2IpYVsp@andrew.cmu.edu> Excerpts from netnews.rec.games.corewar: 20-Apr-94 '94 Standard by Michael Constant@soda.berkeley.edu >I think that the '94 standard is really coming into its own. About a month >ago, any good '88 program could do well on the '94 hill. However, by now, >even programs at or near the top of the '88 hill are having trouble doing >well against '94 programs. (I noticed this because, for some reason, there >have been many '88 and pseudo-88 programs submitted to the '94 hill recently. >A pseudo-88 program (my name) is one which was written for '88 and later >ported to '94, but which probably does not take advantage of all the available > >features.) This is good, it means that people are really finding ways to use >the new standard. Just thought people might want to know.. Good point. I've noticed this, too. Then again, Der Zweite Blitzkrieg debuted at #1 with 179, and #2 was Killer Instinct with 160, but things have since balanced out :(. Mike Nonemacher mn2f+@andrew.cmu.edu From: fjw2@ns1.cc.lehigh.edu (FRANK JUDE WOJCIK) Subject: Re: More Source Postings Message-ID: <1994Apr21.132222.165403@ns1.cc.lehigh.edu> Date: Thu, 21 Apr 1994 13:22:22 GMT >Whew! That's it, I think. Well, I hope to inspire another round of source >postings -- there have been a lot of new programs recently. Does anyone >else want to reveal their secrets? Secrets? My code hardly uses any secrets, and does quite badly, and is for the '88 hill, but here it is anyway. There's a *lot* of optimization that could possibly be done, but I really don't care to. It could probably be redone fairly easily (and possibly more effectively) for the '94 hill, which I may do, but... Here it is anyway. (WARNING: I am a terrible newbie, so go easy! :) This is based on my Zipper series, which also did terribly. But this has active programs instead of DAT decoys. This was *supposed* to do well against all those scanners, but it just was too big & not fast enough, I guess... It starts off with an imp-gate (front program), mod-1 bomber (back program & middle program)(I fooled around with this a bit - making it mod-something else did zilch), and (what I thought was) a neat little trick. The processes are just so that if either the front or back process is killed, "cnt" becomes !=4000. Based on which program is killed, it then copies the retailation program out of the way of the attack, attempts to kill off the other processes, and JMPs to the copied program. The retaliatory bomber is based on Leprachaun(?)(sp) modified to be a 2/3 imp-gate at the end. It was the best I could do. ;redcode verbose ;author Frank J. T. Wojcik ;name Banana Split v1.4 ;strategy Program which acts like three different ones. ;strategy v1.0 -- Initial release. Slow and long. ;strategy v1.1 -- No more bootstrap! Faster. Better bomber. ;strategy v1.2 -- *Much* faster bomber. Probably won't do much, but... ;strategy v1.3 -- Fixed a really stupid bug introduced in 1.2. ;strategy v1.4 -- Turned final bomber into 2/3 imp-gate when done. fp JMP 1,<-5 ;Front Program Top JMP 1,<-6 ADD #1,cnt JMP 1,<-8 JMP -3,<-9 ;Front Program Bottom DAT #0, #0 : [lots of DAT #0, #0's deleted] : DAT #0, #0 cnt DAT #0, #4000 boot SPL fp,cnt (cnt<0), #1 failed --> move fwd MOV 0), #2 failed --> move bck CMP @mvpt1,cpb ;Copy the retaliation program... JMP -2,Back Program ADD #-1,cnt MOV bomb, Michael Constant (mconst@soda.berkeley.edu) > > GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y > -- ----- Frank J. T. Wojcik "This is that thing you call sarcasm, isn't it?" - D.A. fjw2@lehigh.edu "Oh, very good, Worf. Eat any good books lately?" - Q GE d- -p+ c++++ l u(++) e*() m+@ s++/++ n-@ h+() f- g+(-) w++() t+(+++)@ r !y finger fjw2@cs2.CC.lehigh.edu = C8 E8 73 86 FB DB C2 61 0D 60 23 7A EB CB 23 61 From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 22 Apr 1994 00:13:00 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1994/04/11 Version: 2.2.1 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 69 2. Is it Core War or Core Wars? 82 3. Where can I find more information about Core War? 90 4. Core War has changed since Dewdney's articles. Where do I get 108 a copy of the current instruction set? 5. What is this ICWS'94? 126 6. What is the ICWS? 143 7. What is TCWN? 153 8. How do I join? 161 9. Are back issues of TCWNs available? 178 10. What is the EBS? 185 11. Where are the Core War archives? 201 12. Where can I find a Core War system for . . . ? 219 13. I do not have ftp. How do I get all of this great stuff? 268 14. I do not have access to Usenet. How do I post and receive news? 275 15. When is the next tournament? 293 16. What is KotH? How do I enter? 304 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 466 18. How does SLT (Skip if Less Than) work? 478 19. What does (expression or term of your choice) mean? 490 20. Other questions? 633 --------------------------------------------------------------------- Q 1: What is Core War? A 1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 The Redcode language has changed somewhat since; see Q 4. --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (soda.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q11) Steven Morrell (morrell@math.utah.edu) is preparing a more pratically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. --------------------------------------------------------------------- Q 5: What is this ICWS'94? A 5: There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a post-increment indirect addressing mode and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft for more information (soda.berkeley.edu pub/corewar/documents/icws94.0202.Z). You can try out the new standard by submitting warriors to the '94 hills of the KotH servers (see Q16). Two corewar systems currently support ICWS'94, pMARS (various platforms) and Redcoder (Mac), both available at soda (see Q12). --------------------------------------------------------------------- Q 6: What is the ICWS? A 6: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). --------------------------------------------------------------------- Q 7: What is TCWN? A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 8: How do I join? A 8: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 9: Are back issues of TCWN available? A 9: Recent issues can be found on soda.berkeley.edu (see Q11). Older issues (up to Winter 1991) are also available (see the next TCWN for details). ----------------------------------------------------- Q10: What is the EBS? A10: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994 (see Q 5). Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- Q11: Where is the Core War archive? A11: Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from soda.berkeley.edu (128.32.149.19) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q12: Where can I find a Core War system for . . . ? A12: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than soda.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at soda: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-20.hqx - corewar for the Mac, supports ICWS'88 and '94 core-11.hqx - corewar for the Mac core-wars-simulator.hqx - same as core-11.hqx? corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z - corewar for UNIX/X-windows. This program ran the former KotH server at intel.com koth.shar.Z - older version kothpc.zip - port of older version of KotH to the PC deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible icons.zip - corewar icons for MS-Windows macrored.zip - a redcode macro-preprocessor (PC) c88v49.zip - PC corewar, textmode display mars88.zip - PC corewar, graphics mode display corwp302.zip - PC corewar, textmode display, slowish mercury2.zip - PC corewar written in assembly, fast! mtourn11.zip - tournament scheduler for mercury (req. 4DOS) pmars05s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars05s.tar.Z - same as above pmars05.zip - 16-bit PC executables, graphics display version pmars05g.zip - 32-bit PC execs (djgpp, large core) macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincore.zip - MS-Windows system, shareware ($35) ---------------------------------------------------------------------- Q13: I do not have ftp. How do I get all of this great stuff? A13: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. ---------------------------------------------------------------------- Q14: I do not have access to Usenet. How do I post and receive news? A14: To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com ListProcessor. To join, send: SUB COREWAR-L FirstName LastName to: LISTPROC@STORMKING.COM You can send mail to corewar-l@stormking.com to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (tuc@stormking.com). Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q15: When is the next tournament? A15: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. Informal double-elimination tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. ---------------------------------------------------------------------- Q16: What is KotH? How do I enter? A16: King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. The original KotH was developed and run by William Shubert at Intel, and discontinued after almost three years of service. Currently, KotHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: "koth@stormking.com" is maintained by Scott J. Ellentuch (tuc@stormking.com) and "pizza@ecst.csuchico.edu" by Thomas H. Davies (sd@ecst.csuchico.edu). Both KotHs provide very similar services and are therefore covered together. The principal difference is that "pizza" has a much faster internet connection than "stormking". Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail daemon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. Thells you can select by starting your program with ;redcode, ;redcode-x, ;redcode-icws, ;redcode-b, ;redcode-94, or ;redcode-94x. More information on these hills is listed below. 3) Mail this file to "koth@stormking.com" or "pizza@ecst.csuchico.edu". "Pizza" requires a subject of "koth" (use the -s flag on most mailers). 4) Within a few minutes (or the next day for "stormking") you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so (or the next day for "stormking") you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives during that time, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Here are the Specs for the various hills: ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '88 ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws", available at "stormking" only) coresize: 8192 instructions max. processes: 8000 per program duration: After 100,000 cycles, a tie is declared. max. entry length: 300 minimum distance: 300 instruction set: ICWS '88 ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x", available at "pizza" only) coresize: 4096 max. processes: 32 duration: after 65,536 cycles, a tie is declared. max. entry length: 64 minimum distance: 64 instruction set: ICWS '88 ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza" only) coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "stormking" and "pizza") coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: ICWS '94 Draft If you just want to get a status report without actually challenging the hills, send email with ";status" as the message body (and don't forget "Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject: koth help" you will receive instructions that may be more up to date than those contained in this document. All hills run portable MARS (pMARS) version 0.5, a platform-independent corewar system available at soda (see Q12). The '94 and '94x hills allow three experimental opcodes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) ---------------------------------------------------------------------- Q17: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A17: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH or pmars -8) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. Note that under ICWS'94, DAT 0, 0 is a legal instruction. ---------------------------------------------------------------------- Q18: How does SLT (Skip if Less Than) work? A18: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q19: What does (expression or term of your choice) mean? A19: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Gate-busting - (also gate-crashing) technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0, 2668) with a standard one to overrun imp-gates. Hybrids - warriors that combine two or more of the basic strategies, either in sequence (e.g. stone->paper) or in parallel (e.g. imp/stone). Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. le ... ... SPL 0, Date: 22 Apr 1994 10:54:13 GMT In article <2p210m$7sb@agate.berkeley.edu> mconst@OCF.Berkeley.EDU (Michael Constant) writes: > From: mconst@OCF.Berkeley.EDU (Michael Constant) > Subject: Re: '94 redcode > Date: 20 Apr 1994 01:37:26 PST-8 > > How can you complain? There are *two* copies of Variation on the > Big Hill right now! :-) Yeah, sorry about that, but hey, when you have a #1 warrior and want to improve it, you'd want to try it without having to kill the #1... Anyway, my Janitors should have taken care of all the half-duplicates. > But seriously, there are several programs to do nasty things to > imps. First of all, any program called "Kill More Imps!!!" > (Steven Morrell) can't be exactly cooperative with imp spirals > (although it never seems to beet Imperfection...) and my own > Sauron v2.0 (now in testing on the Big Hill) is also not kind to > them. The imps *will* die, never fear. Hahahaha! That's what you think! :-) Seriously again, there are also a few vampires on the big hill that are doing pretty good (including my own Virus). The problem is, I'm not very fond of papers to start with, and I haven't been able to program even a decent one. The only one I got on the big hill was when the hill was far less competitive. So... any paper wizards? :-) -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 22 Apr 1994 11:18:39 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1994/04/11 Version: 2.2.1 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 69 2. Is it Core War or Core Wars? 82 3. Where can I find more information about Core War? 90 4. Core War has changed since Dewdney's articles. Where do I get 108 a copy of the current instruction set? 5. What is this ICWS'94? 126 6. What is the ICWS? 143 7. What is TCWN? 153 8. How do I join? 161 9. Are back issues of TCWNs available? 178 10. What is the EBS? 185 11. Where are the Core War archives? 201 12. Where can I find a Core War system for . . . ? 219 13. I do not have ftp. How do I get all of this great stuff? 268 14. I do not have access to Usenet. How do I post and receive news? 275 15. When is the next tournament? 293 16. What is KotH? How do I enter? 304 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 466 18. How does SLT (Skip if Less Than) work? 478 19. What does (expression or term of your choice) mean? 490 20. Other questions? 633 --------------------------------------------------------------------- Q 1: What is Core War? A 1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 The Redcode language has changed somewhat since; see Q 4. --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (soda.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q11) Steven Morrell (morrell@math.utah.edu) is preparing a more pratically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. --------------------------------------------------------------------- Q 5: What is this ICWS'94? A 5: There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a post-increment indirect addressing mode and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft for more information (soda.berkeley.edu pub/corewar/documents/icws94.0202.Z). You can try out the new standard by submitting warriors to the '94 hills of the KotH servers (see Q16). Two corewar systems currently support ICWS'94, pMARS (various platforms) and Redcoder (Mac), both available at soda (see Q12). --------------------------------------------------------------------- Q 6: What is the ICWS? A 6: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). --------------------------------------------------------------------- Q 7: What is TCWN? A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 8: How do I join? A 8: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 9: Are back issues of TCWN available? A 9: Recent issues can be found on soda.berkeley.edu (see Q11). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- Q10: What is the EBS? A10: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994 (see Q 5). Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- Q11: Where is the Core War archive? A11: Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from soda.berkeley.edu (128.32.149.19) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q12: Where can I find a Core War system for . . . ? A12: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than soda.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at soda: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-20.hqx - corewar for the Mac, supports ICWS'88 and '94 core-11.hqx - corewar for the Mac core-wars-simulator.hqx - same as core-11.hqx? corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z - corewar for UNIX/X-windows. This program ran the former KotH server at intel.com koth.shar.Z - older version kothpc.zip - port of older version of KotH to the PC deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible icons.zip - corewar icons for MS-Windows macrored.zip - a redcode macro-preprocessor (PC) c88v49.zip - PC corewar, textmode display mars88.zip - PC corewar, graphics mode display corwp302.zip - PC corewar, textmode display, slowish mercury2.zip - PC corewar written in assembly, fast! mtourn11.zip - tournament scheduler for mercury (req. 4DOS) pmars05s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars05s.tar.Z - same as above pmars05.zip - 16-bit PC executables, graphics display version pmars05g.zip - 32-bit PC execs (djgpp, large core) macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincore.zip - MS-Windows system, shareware ($35) ---------------------------------------------------------------------- Q13: I do not have ftp. How do I get all of this great stuff? A13: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. ---------------------------------------------------------------------- Q14: I do not have access to Usenet. How do I post and receive news? A14: To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com ListProcessor. To join, send: SUB COREWAR-L FirstName LastName to: LISTPROC@STORMKING.COM You can send mail to corewar-l@stormking.com to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (tuc@stormking.com). Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q15: When is the next tournament? A15: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. Informal double-elimination tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. ---------------------------------------------------------------------- Q16: What is KotH? How do I enter? A16: King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. The original KotH was developed and run by William Shubert at Intel, and discontinued after almost three years of service. Currently, KotHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: "koth@stormking.com" is maintained by Scott J. Ellentuch (tuc@stormking.com) and "pizza@ecst.csuchico.edu" by Thomas H. Davies (sd@ecst.csuchico.edu). Both KotHs provide very similar services and are therefore covered together. The principal difference is that "pizza" has a much faster internet connection than "stormking". Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail daemon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. There are currently six separate hills you can select by starting your program with ;redcode, ;redcode-x, ;redcode-icws, ;redcode-b, ;redcode-94, or ;redcode-94x. More information on these hills is listed below. 3) Mail this file to "koth@stormking.com" or "pizza@ecst.csuchico.edu". "Pizza" requires a subject of "koth" (use the -s flag on most mailers). 4) Within a few minutes (or the next day for "stormking") you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so (or the next day for "stormking") you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives during that time, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Here are the Specs for the various hills: ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '88 ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws", available at "stormking" only) coresize: 8192 instructions max. processes: 8000 per program duration: After 100,000 cycles, a tie is declared. max. entry length: 300 minimum distance: 300 instruction set: ICWS '88 ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x", available at "pizza" only) coresize: 4096 max. processes: 32 duration: after 65,536 cycles, a tie is declared. max. entry length: 64 minimum distance: 64 instruction set: ICWS '88 ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza" only) coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "stormking" and "pizza") coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: ICWS '94 Draft If you just want to get a status report without actually challenging the hills, send email with ";status" as the message body (and don't forget "Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject: koth help" you will receive instructions that may be more up to date than those contained in this document. All hills run portable MARS (pMARS) version 0.5, a platform-independent corewar system available at soda (see Q12). The '94 and '94x hills allow three experimental opcodes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) ---------------------------------------------------------------------- Q17: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A17: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH or pmars -8) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. Note that under ICWS'94, DAT 0, 0 is a legal instruction. ---------------------------------------------------------------------- Q18: How does SLT (Skip if Less Than) work? A18: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q19: What does (expression or term of your choice) mean? A19: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Gate-busting - (also gate-crashing) technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0, 2668) with a standard one to overrun imp-gates. Hybrids - warriors that combine two or more of the basic strategies, either in sequence (e.g. stone->paper) or in parallel (e.g. imp/stone). Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, Date: 22 Apr 1994 12:25:51 GMT Okay, followin the good example set by Michael, I'll divulge my little secrets. I've been going hard at the big hill, and I currently have seven warriors on the hill. Yes, I know, I really should retire Splash, but I still find it interesting that "Variation G-1" and "Splash" are so close in performance. Anyway, I'll start with the uninteresting ones. Sunburst was mercifully pushed off lately, so good riddance (it was a '88 stone with new constants). Skimp 127 is nothing more than a 2-process 127-point imp-spiral. Interestingly, Kill More Imps!!! doesn't seem all that efficient againts it. For the more interesting stuff, I decided to make a separate post for each warrior. So here goes! -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Variation G-1 Message-ID: Date: 22 Apr 1994 12:36:43 GMT Last time I checked, Variation G-1 was barely #1 on pizza, though it has had over 10 points of margin over #3 at one point (#2 was Splash). Well, enough bragging. Variation, as the ;strategy line says, is a variation on the theme of my mildly successful Twimpede. If you remember, Twimpede was basically a Mod-2 ExtraExtra stone with a 19-point 2-process spiral, and a wimp. The genius (ahem) was to add in the extra wimp, as it would sometimes be the last thing alive, extolling a tie against CG and a win over other stones. There have been a few dozen Variations along the way, as I experimented with different designs. Variation A-1.a was #1 at Stomrking for a while. In the latest version, I was able to squeeze one more instruction out of the stone without hindering functionality. Also, I added some random core trashing during the spiral start-up sequence. There's some decoy also, and the wimp is booted off the main body. With all this confusion, Variation G-1 gets a 60/30/10 against Dagger v6.0, and 55/35/10 against Kill Imps!!! As a comparison, it beats Imperfection v1.0 50/0/50 ;redcode-94x ;name Variation G-1 ;author Jay Han ;strategy Stone/Spiral with tons of decoy and a wimp ;macro org start p1 equ 27739 s1 equ 34 p2 equ 27705 s2 equ -34 gate equ inc+s2 loop add.f inc, cast stone spl.b loop, Date: 22 Apr 1994 12:38:50 GMT Okay, so flame me if you have to, but I'm sort of usurping the #3 spot at the big hill with Splash. Splash is really "only" Variation G-1 with a two-pass core-clear. I thought it would be slightly better than Variation, but it was slightly worse. I guess its mileage will vary with the type of opponents it gets. ;redcode-94x ;name Splash 1 ;author Jay Han ;strategy Stone/Spiral with 2-pass core-clear ;macro org entry p1 equ 27739 s1 equ 34 p2 equ 27705 s2 equ -34 gate equ inc+s2-4 gate2 equ inc+s2 offset equ top-19 top dat.f 0, patch+1 loop add.f inc, cast stone spl.b loop, Date: 22 Apr 1994 12:42:44 GMT And what about Sissy? It's really only an experiment, and I think I'll retire it before long. It's another variation on Variation G-1, this time with a short scanning pass before the stone. It doesn't do much good, it's all I can tell you. ;redcode-94x ;name Sissy ;author Jay Han ;strategy SiSSy: Scan-Stone-Spiral, and a wimp ;strategy Fast Scanner/Vampire like Scanalyzer-W ;strategy Stone/Spiral/Wimp like Twimpede ;macro org scan start equ scan-200 step equ -50 loop add.f pit, scan scan sne.i start+step, start count djn.b loop, #548 jmz.b phase, count mov.i fang, @scan sub.ba scan, @scan add.f half, scan jmp.b scan, Date: 22 Apr 1994 12:46:14 GMT A vampire. Yes, there aren't only stone/imp on the big hill! My first campire, The Missionary, was fairly successful, so I followed up and did The Count, which was even better, and finally Virus. Virus is a Mod-3.5 vampire, meaning that there are gaps of 3 or 2 untouched locations, but never more. The pit is a standard pit, with the added feature that at the end of the fang-planting run, the pit is neatly surrounded by fangs that jump back into it, in case for some strange reason the pit overflows. After the bombing run, a core-clear is started, and the pit is wiped out last. Also, the core-clear becomes a perfect gate, because imps have been known to rise from the dead. There's a large decoy at the end, just for fun. ;redcode-94x ;name Virus ;author Jay Han ;strategy Vampire ;macro start equ 20 step equ 23 n equ 16873 org bite gate equ head-step loop add.x head ,fang bite mov.i fang ,@fang ptr djn.b loop ,#n-1 head spl.b #step ,<-step kill mov.i bomb , Date: 22 Apr 1994 12:50:05 GMT The Scanalyzer-V series was thus named because it bombed not with SPL/JMP or a SPL carpet, but with a vampire fang. The advantage of using fangs is that you control the pit. You *could* put the slaves to work, although Scanalyzer-W doesn't... yet. That's in my plans. I also plan to include some stone component to get a better edge againts other scanners. Anyway, it's a Mod-2 CMP-scanner. And that's about it. ;redcode-94x ;name Scanalyzer-W ;author Jay Han ;strategy Scanner/Vampire ;macro org scan start equ scan-200 step equ -34 loop add.f inc, scan scan cmp.i start+step, start slt.ab #399, scan count djn.b loop, #13860 mov.i fang, @scan sub.ba scan, @scan add.f half, scan p jmn.b scan, count inc spl.b #step*2, Date: 22 Apr 1994 12:53:22 GMT What can I say? I really didn't expect this one to get on the hill at all. It's a warrior derived from The Count (remember, the vampire). What I wanted to try was to make a vampire/spiral combo. Just for fun. So what I needed was a multi-process vampire. No easy way to do that, because unlike stones, who self-destruct, a vampire must gracefully quit before it is enslaved itself. I'm still working on a vampire that really looks like ExtraExtra. It's tricky. I need some tools to come up with good constants that maximize the spread patterns and land exactly where I want them to, at exactly the right moment. ;redcode-94x ;name Nova-A.1b ;author Jay "Thierry" Han ;strategy Fast Vampire + Imp-spiral ;macro org start init equ 40+3*step step equ 52 gate equ source-step source spl.b #0, Jay "Thierry" Han wrote: > Skimp 127 is nothing more than a 2-process 127-point imp-spiral. That's neat... how does it manage to do so well then? Maybe the sheer number of points affords it a rather large chance of hitting something like a scanner right as it starts. > Interestingly, Kill More Imps!!! doesn't seem all that efficient againts it. Hmmm... Kill More Imps!!! can't beat Imperfection either. Hey Steven, what is it supposed to beat if not imps? Or are Imperfection and Skimp 127 just special cases? I think the original Kill Imps!!! was more effective against my programs. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Corewar Tutorials Date: 23 Apr 1994 22:24:34 GMT Message-ID: <2pc772$9fi@agate.berkeley.edu> To go with Steven Morrell's wonderful corewar tutorial, I would like to write a basic redcode tutorial for new corewar programmers. I think that this would be useful because the standard tutorial.1,2 files are getting dated, and there is no really good '94 draft tutorial for beginners (that I can find). Does anyone else think this would be useful? -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: hardekbc@acpub.duke.edu (Benjamin C. Hardekopf) Subject: Re: Corewar Tutorials Date: 23 Apr 1994 23:40:16 GMT Message-ID: <2pcbl0$jop@news.duke.edu> I for one would be very grateful for a redcode tutorial like that. Great idea! Thanks. -Ben %%%%%%%%%%%%%%%%% Onward, through the fog! From: pk6811s@acad.drake.edu Subject: '94 Standard Message-ID: <1994Apr23.190831.1@acad.drake.edu> Date: Sun, 24 Apr 1994 01:08:31 GMT It seems likely to me that there are three warrior forms put at a disadvantage under the 94 rules. These may not be completely fatal, only time will tell. First is the carpet-bombing cmp-scanner using a djn-stream. The djn- stream is succeptible to a stone using post-increment in this fashion: stone mov >a,b Post-increment leaves DAT 0,1's all over core. When the djn-stream of the cmp-scanner runs over a DAT 0,1 it falls into its bombing routine, wasting time. Carpet-bombers can waste a LOT of time doing this. Worse, both carpet-bombers and spl-jmp bombers can be tricked into bombing their own code with this technique. How important is the djn-stream to the success of cmp-scanners? Or to stones for that matter? Stones won't waste a lot of time on these dat 0,1's, but the continued draining of processes may upset the timing between the stone and some other component of the program. My own Keystone is history, since it thinks any 1's are paper. Second, under 94 very good antivamp code is trivial. Here's an example: spl 1 spl 1 spl 1 av1 add.ab <-10,@av2 av2 mov bomb,<-10 av1 adds the a-operand of 8 instructions to the location that av2 is pointing at, then av2 bombs from wherever that points to. Since the vampire fang is a jmp statement, and jmp's always jump to their a-operand, this routine bombs the pit immediately on detecting a fang. Put the two lines in one of a set of replicators and you'll rarely lose to a vampire. There may be ways for vampires to mask their fangs, but it certainly will make them less efficient to do so. Third (sorry Wayne) Night and its derivatives Night Crawler and NC Decoy. Night uses a mod-2 bombing pattern, then mops up by ADDing its dat-increment to every instruction in core. Normally this causes any surviving SPL 0's to jump into never-never land and die. However this can be prevented by using the immediate-mode on the SPL's a-operand: spl #0 No matter if something is added to the zero, the immediate mode guarantees the split won't jump away. -- This is not meant to be a vote against the 94 rules, I kind of like the new features. But you can bet all my warriors will be taking advantage of THESE features from now on :-) Paul Kline pk6811s@acad.drake.edu From: fph1@cornell.edu (Francis P Hwang) Subject: Knowing nothing about machine language Date: Sun, 24 Apr 1994 13:05:11 -0800 Message-ID: This might be an unusual question, but I've wanted to get into Corewar for some time now, but every time I get any kind of tutorial, I find that it (quite reasonably) assumes a lot of knowledge about machine language. I'm a CS major myself, but only a freshman, so it'll be a little while before I learn any machine language in a class, and I'm getting a little impatient. My question is this: 1) Are there any kind of Corewar tutorials that assume no knowledge of machine language at all? (I have programmed enough to understand a lot of the basic concepts, addressing & so forth.) 2) If no such tutorial exists, could someone direct me to a beginner level book about machine language that could teach me enough about it so that I could start playing right away? Plenty thanks in advance. Francis P. Hwang From: wsheppar@sct.edu (Wayne Sheppard) Subject: Re: '94 Standard Date: 24 Apr 1994 13:13:03 -0400 Message-ID: <2pe9av$n1v@st6000.sct.edu> In article <1994Apr23.190831.1@acad.drake.edu> pk6811s@acad.drake.edu writes: >Third (sorry Wayne) Night and its derivatives Night Crawler and NC Decoy. >Night uses a mod-2 bombing pattern, then mops up by ADDing >its dat-increment to every instruction in core. Normally this causes >any surviving SPL 0's to jump into never-never land and die. However >this can be prevented by using the immediate-mode on the SPL's a-operand: > > spl #0 Lucky for me, I've already adapted to these changes. One good trick for the stones out there is to use the SPL as your constants. spl #2234,#-2234 This acts just like an spl 0, but can be added to your MOV statement to eliminate a DAT line. Speaking of the ADD/coreclear, I've discarded that. Some of you may notice that NC 94 now picks up 15-20 wins vs imps. Instead of the addition coreclear I now jump to a coreclear/gate. spl #-3044,<3044 add -1,1 mov >1-3044-3044,1 jmp -2 After bombing the core at mod-4, MOV increments the ADD. Then ADD adds the SPL to JMP. This causes all 100 or so processes to JMP to the coreclear routine. Then the MOV increments ADD again, so the JMP doesn't get changed. I haven't had time to optimize it, so no full code release yet. Maybe I need to add a quick-cmp scan? ;) Wayne Sheppard wsheppar@st6000.sct.edu -- Wayne Sheppard wsheppar@st6000.sct.edu From: The Cosmic Net Guide - Davin Petersen Subject: Re: Corewar Tutorials Date: 24 Apr 1994 18:48:32 -0400 Message-ID: On Sun, 24 Apr 1994, Michael Constant wrote: > To go with Steven Morrell's wonderful corewar tutorial, I would like to write > a basic redcode tutorial for new corewar programmers. I think that this would > be useful because the standard tutorial.1,2 files are getting dated, and there > is no really good '94 draft tutorial for beginners (that I can find). > > Does anyone else think this would be useful? You got my vote. I'm a newbie to this area so any help would be appreciated. Question for the general public - I picked up the macro reader for DOS and mars88. Did I get the right ones? Is the unix verison of mars POSIX complient, or does it support LINUX? Are there more current RedCode interpreters out there? Davin Petersen (503)885-0162 OIT P.O. 2382 Klamath Falls, OR (nothin' fancy here) 97061 From: hardekbc@acpub.duke.edu (Benjamin C. Hardekopf) Subject: Re: Knowing nothing about machine language Date: 24 Apr 1994 19:03:22 GMT Message-ID: <2pefpq$pn6@news.duke.edu> In article , Francis P Hwang wrote: [snip] > 1) Are there any kind of Corewar tutorials that assume no knowledge of >machine language at all? (I have programmed enough to understand a lot of >the basic concepts, addressing & so forth.) > 2) If no such tutorial exists, could someone direct me to a beginner >level book about machine language that could teach me enough about it so >that I could start playing right away? [snip] I would also appreciate anything like the above. Thanks! -Ben ********* Ben Hardekopf Aspiring Comp Sci/EE major Duke University motto: Onward, through the fog! From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: '94 Standard Message-ID: <1994Apr24.214628.12844@news.vanderbilt.edu> Date: Sun, 24 Apr 1994 21:46:28 GMT In article <1994Apr23.190831.1@acad.drake.edu> pk6811s@acad.drake.edu writes: >It seems likely to me that there are three warrior forms put at a >disadvantage under the 94 rules. [..] >First is the carpet-bombing cmp-scanner using a djn-stream. The djn- >stream is succeptible to a stone using post-increment in this fashion: > > stone mov >a,b > >Post-increment leaves DAT 0,1's all over core. When the djn-stream >of the cmp-scanner runs over a DAT 0,1 it falls into its bombing routine, >wasting time. Carpet-bombers can waste a LOT of time doing this. Worse, >both carpet-bombers and spl-jmp bombers can be tricked into bombing >their own code with this technique. >[..] >Paul Kline Easy to avoid this one. Simply decrement core with djn.f -3,<-100 This instruction only falls thru if both A and B-number are 1 (and does more damage incidentally). -Stefan (stst@vuse.vanderbilt.edu) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: EBS tourney round 1 results Message-ID: <1994Apr25.031812.19259@news.vanderbilt.edu> Date: Mon, 25 Apr 1994 03:18:12 GMT Results for the 1st round of the spring EBS tournament are in. This was truly a battle of the imps (except for Brant's vampire "Request-55440"). As others have pointed out, the big coresize seems to favor imp/stone combos heavily. Perhaps this is because two of their "natural ememies" are not very effective: Quick-scans cannot cover the entire core because of the program length limit and papers just don't fill the big core fast enough. Here are the results. Pairings were chosen randomly. ------------------------------------------------------------------------ Der Zweite Blitzkrieg by Mike Nonemacher scores 94 (3 12 85) Blue Funk by Steven Morrell scores 121 (12 3 85) BigImps by James Layland scores 115 (10 5 85) impostor by na'ndor sieben scores 100 (5 10 85) Sauron v2.4 by Michael Constant scores 88 (25 62 13) Request-55440 by Brant D. Thomsen scores 199 (62 25 13) Bakers Dozen by Wayne Sheppard scores 52 (1 50 49) Big by Jay Han scores 199 (50 1 49) ------------------------------------------------------------------------ In the second round, held coming Friday, April 29th, we'll have the following confrontations: Winner bracket: James Layland vs. Steven Morrell Jay Han vs. Brant Thomsen Loser bracket: Nandor Sieben vs. Mike Nonemacher Wayne Sheppard vs. Michael Constant The finalist of the loser bracket will challenge the finalist of the winner bracket for the tournament champion title. The rules for the second round will be "standard" '94 specs, i.e.: coresize: 8000 max processes: 8000 max cycles: 80000 max length: 100 min distance: 100 standard: draft '94+SEQ,SNE,NOP If you don't send new entries by next Friday, I'll use this round's :-) Cheers, Stefan (stst@vuse.vanderbilt.edu) P.S.: these are the round-robin results (no bearing on the outcome of the tournament): ------------------------------------------------------------------------ Elapsed time: 15025 seconds (04:10:25) Rank Name Author %W %L %T Score ___________________________________________________________________________ 1 Big Jay Han 32 11 57 1380 2 Request-55440 Brant D. Thomsen 43 35 23 1352 3 Sauron v2.4 Michael Constant 29 37 34 1088 4 Blue Funk Steven Morrell 16 11 73 1081 5 Der Zweite Blitzkrieg Mike Nonemacher 14 12 75 1044 6 BigImps James Layland 8 13 78 927 7 Bakers Dozen Wayne Sheppard 11 20 70 916 8 impostor na'ndor sieben 7 20 73 839 From: mds@iastate.edu (Mark D. Smucker) Subject: Should a newbie learn '88 or '94+SEQ,SNE,NOP ? Date: 26 Apr 1994 01:13:54 GMT Message-ID: <2phpsi$n1o@news.iastate.edu> I've been getting interested in core war now for about a week and have a good clue about how to start writing programs, but was wondering what the suggested standard is. Is everyone writing '94+SEQ,SNE,NOP code now? Can '88 programs do well against "smarter" '94+SEQ,SNE,NOP programs? Thanks, Mark D. Smucker --- mds@iastate.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Should a newbie learn '88 or '94+SEQ,SNE,NOP ? Message-ID: <1994Apr26.044550.17469@news.vanderbilt.edu> Date: Tue, 26 Apr 1994 04:45:50 GMT In article <2phpsi$n1o@news.iastate.edu> mds@iastate.edu (Mark D. Smucker) writes: >I've been getting interested in core war now for about a week and have >a good clue about how to start writing programs, but was wondering >what the suggested standard is. > >Is everyone writing '94+SEQ,SNE,NOP code now? > '88 and '94 are not really that much different, but '94 lets you do things in fewer lines of code. I would actually suggest starting off by learning '94, because the modifiers make the code more transparent (IMO at least), and '94 subsumes '88. (SEQ),SNE,NOP are very much experimental at this point, i.e. no one has published code that uses these opcodes to an advantage. >Can '88 programs do well against "smarter" '94+SEQ,SNE,NOP programs? > Many '88 programs can be shortened by a few intructions by translating them into '94. This makes them more difficult to find and therefore higher scoring but hardly smarter. Only time will tell whether the additional flexibility that '94 allows will result in a greater diversity of strategies. It took three years after the introduction of ICWS'88 for CMP-scanners, and four years for imp-spirals to be discovered (imp-spirals were possible even under ICWS'86), and we have only just started programming in ICWS'94. >Thanks, > >Mark D. Smucker --- mds@iastate.edu > -Stefan (stst@vuse.vanderbilt.edu) From: morrell@math.utah.edu (Steven C. Morrell) Subject: Re: More redcode (Big) Date: Tue, 26 Apr 1994 06:32:20 GMT Message-ID: In article <2p99ba$j72@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: Hmmm... Kill More Imps!!! can't beat Imperfection either. Hey Steven, what is it supposed to beat if not imps? Or are Imperfection and Skimp 127 just special cases? I think the original Kill Imps!!! was more effective against my programs. Kill More Imps!!! is designed to trap 13-pt imps only. But, hey, it's a lot shorter than Kill Imps!!! And you need a different kind of decoy to fool each of them. It sounds like I'd better submit the original again 8D Steven Morrell morrell@math.utah.edu From: humber@elearn.edu.yorku.ca (The Humberview School) Subject: Re: MARS Message-ID: Date: Tue, 26 Apr 1994 12:29:05 GMT Hello. I am interested in MARS, but have an aged 8088 computer. Do you know about any MARS simulators available on FTP to supprt 8088s? The 8088's spped is from 4.77MHz to 8MHz. Sincerely, Anonymous Student -- ************************************************************************ The Humberview Public High School E-mail: humber@YorkU.CA From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Corewar Tutorials Date: 26 Apr 1994 17:09:36 GMT Message-ID: <2pjhsg$16v@agate.berkeley.edu> Due to the overwhelmingly positive response (two posts, 12 (!) letters) I will be writing the promised tutorial. To clarify, my tutorial will be a basic redcode tutorial, with '88 and '94 draft standards. It will *not* teach how to write *good* programs -- that's what Steven's tutorial is for. The two tutorials will complement each other, because Steven's assumes a basic familiarity with redcode programming. It should be available on soda within two weeks or so (I'll post an announcement here). Anyone who doesn't have ftp can mail me and I will send them a copy when it's done. -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: hutchd2@nuge108.its.rpi.edu (DMH) Subject: Re: Knowing nothing about machine language Date: 26 Apr 1994 19:25:33 GMT Message-ID: <2pjpre$a8l@usenet.rpi.edu> I also would like to find tutorials that don't assume previous knowledge of machine language- The commands seem fairly straight foward; but when put together, more often then not, they still register as a great big '0' when I try to understand even simple programs. The only machine language code I have done, was for a general COLD class. Please post help for some poor newbies who just want to get in on the fun :) Thanks, Dan. =-=-=-=-=-=-= Date: Tue, 26 Apr 1994 23:32:53 MST From: Message-ID: <94116.233253AHNAS@ASUACAD.BITNET> Subject: pmarsv grx display We need help to decide what would be the best way to display in pmarsv graphics version. In the last version (DJGPP alpha release) I use ** *. .. .* *. ** *. ** *. .. For diplaying execution,increment,decrement,write, read . The problem with this is that if a location is displayed as execution then it overwrites any previous access. For example we can't tell who wrote last the location where a process died. In mars88 I use 3x3 raster, exetution is displayed as an empty box, and all the other accesses displayed as a single point in the middle of the box. This way an execution and a write can be seen at the same time. The problem with this approach is that read,write,increment all looks like the same. To solve this problem I made it possible to determine separately which accesses we want to display and which we don't . In pmarsv it's not possible we can't display read access only when write access is also displayed. Since pmarsv works with big coresize I can't use 3x3 raster simply because I don't have enough room. Michael's suggestion is to use ** *. for write and .. .* for write I'm not sure what he wants for read, increment, decrement. Please send your opinion about this problem. I want to implement the most popular way to do this. Please look at mars88 if you don't know what I mean by separate adjustment of read/write/increment . If nobody understands what I'm saying (this is very much possible) just tell me and I'll try to explain it. Thanks, Nandor. From: pk6811s@acad.drake.edu Subject: Re: '94 Standard Message-ID: <1994Apr26.210927.1@acad.drake.edu> Date: Wed, 27 Apr 1994 03:09:27 GMT In article <2pe9av$n1v@st6000.sct.edu>, wsheppar@sct.edu (Wayne Sheppard) writes: > spl #-3044,<3044 > add -1,1 > mov >1-3044-3044,1 > jmp -2 > And if you arrange it like this: capstone spl #step,<-step stone mov >cnt-(step*count1),cnt+(step*count1) add capstone,stone cnt jmp stone,capstone 'cnt' will get bombed with the spl and all your cycles can fall directly into your 2-pass core-clear :-) The 2-pass core-clear is definitely good for stone against paper, but seemingly useless against imps :-( BTW, here's an interesting '94 imp structure: spl 1 spl 1 spl 1 jmp >0,imp imp mov 0,>1 Not very durable against most opponents, but can overrun a wimp. Paul Kline pk6811s@acad.drake.edu From: mconst@OCF.Berkeley.EDU (Michael Constant) Subject: Re: pmarsv grx display Date: 27 Apr 1994 19:34:41 GMT Message-ID: <2pmeoh$s1a@agate.berkeley.edu> In article <94116.233253AHNAS@asuacad.bitnet>, wrote: >We need help to decide what would be the best way to display in pmarsv >graphics version. >In the last version (DJGPP alpha release) I use >** *. .. .* *. >** *. ** *. .. >For diplaying execution,increment,decrement,write, read . My main concern is that when a process dies (or malfunctions) you can't tell who wrote to it last. We could fix this by making execute *. ** and leaving all the others the same. The main problem with *this* is that then an increment and a decrement to the same location would look like an execution, which would be a Bad Thing. Also you wouldn't see anything if a part of your program was decremented or incremented. So, the best solution I can come up with is to have two modes -- pmarsv mode and mars88 mode. In mars88 mode execute would be ** *. and everything else would be .. .* with a selector to determine what is displayed. In pamrsv mode, the display would work as it currently does. That way you could use pmarsv mode when you want to see exactly what is being done to core (by a stone, for example) but mars88 mode when you need to analyze why some part of your program is failing. Remember, the selector in mars88 mode makes it a good deal more powerful than you might think at first glance. Oh, and one other thing. Would it be easy to make the graphics display use the easier-to-read 3x3 raster for small (say <10000 or so) coresizes and only use the 2x2 for big ones, or will it have to use the 2x2 for everything (like the current alpha version)? -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mnq@myhost.subdomain.domain (Mitchell N. Quinn) Subject: Warrior by startegy list? Date: 28 Apr 1994 19:48:39 GMT Message-ID: <2pp3un$8sc@redwood.cs.scarolina.edu> I was wondering if anybody out there has a list of warriors according to the strategy they employ. I have written a program using a Genetic Algorithm to breed and test corewar programs. A list of this type, or just a listing of the 'classic' warriors by stategy would be a great help. thanks, Mitch Quinn quinn@usceast.cs.scarolina.edu quinn@pacer1.usca.scarolina.edu From: huangch@cps.msu.edu.cps.msu.edu (Cheng Chang Huang) Subject: Re: Tutorial Date: 29 Apr 1994 17:14:19 GMT Message-ID: <2prf9b$10l8@msuinfo.cl.msu.edu> Hi, Seen many posting mentioning Steve's tutorial. Where can I get it? Thanks, Chengchang Huang -- Chengchang Huang (huangch@cps.msu.edu) Computer Science Dept. Michigan State University From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Tutorial Date: 29 Apr 1994 20:09:13 GMT Message-ID: <2prph9$mun@agate.berkeley.edu> > Seen many postings mentioning Steve's tutorial. Where can I get it? By anonymous ftp to soda.berkeley.edu, as /pub/corewar/incoming/chapter1.Z (more chapters coming soon!) If you don't have ftp you can ask him for a copy (morrell@math.utah.edu) or you can ask me. -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: fullanto@cwis.isu.edu (Antonette Nixon) Subject: finding mod numbers Date: 30 Apr 1994 01:50:21 -0600 Message-ID: <2pt2jt$5vn@cwis.isu.edu> Quick question. How would I go about writing an algorithm to figure out what mod a particular constant is? For example, if I had the number 3158 (picked randomly just now), how would I go about finding what kind of a bombing pattern using that constant would give? From: bcohen@acsu.buffalo.edu (Bram Cohen) Subject: Low competition on the '88 hill? Message-ID: Date: Sat, 30 Apr 1994 01:55:31 GMT I managed to get a warrior onto the very bottom of the '88 hill a few days ago and, much to my surprise, it's still there. Has so much of the action now moved onto the '94 hill that noone wants to bother pushing a poor pathetic imp-spiral like myself off the bottom of the '88 hill? -- ___ ___ / \____ ############################ / \_/ \ \_ __ \ # Bram Cohen # / \_/ / \/ # bcohen@acsu.buffalo.edu # /\ ___/ # Just trying to be myself # From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: EBS spring tournament: round 2 results Date: 30 Apr 1994 14:34:17 -0500 Message-ID: <9404301927.AA04550@idnsun.gpct.Vanderbilt.Edu.noname> The second round of the EBS spring tourney featured a wide variety of strategies: next to imps we had paper (repimp), vampires and an anti-imp scanner (ivscan). In the winner bracket, James Layland's ivscan outdid Steven Morrell's ^C, and Jay Han's Small defeated Brant Thomsen's Request. Next week's round looks like a battle of the big J's when Jay and James meet for the remaining match in the winner bracket. Steven and Brant move to the loser bracket, where they will continue to fight until a single challenger for the winner bracket finalist remains. ^C by Steven Morrell scores 93 (22 51 27) ivscan by J.Layland scores 180 (51 22 27) Request v2.0 by Brant D. Thomsen scores 121 (30 39 31) Small by Jay Han scores 148 (39 30 31) In loser bracket, Michael Constant's Sauron succumbed to Wayne Sheppard's NC 94, and Nandor Sieben's repimp (read rep-imp :-) was defeated by Mike Nonemacher's Paradox. Michael and Nandor are out of the tournament; thanks for playing, guys. Wayne and Mike continue on. NC 94 by Wayne Sheppard scores 156 (37 18 45) Sauron T by Michael Constant scores 99 (18 37 45) Paradox v2 by Mike Nonemacher scores 115 (9 3 88) repimp by nandor sieben scores 97 (3 9 88) To recap, here the pairings for round 3, held next Friday May 6th: J.Layland vs. Jay Han Steven Morrell vs. Brant Thomsen Wayne Sheppard vs. Mike Nonemacher Remember, next round we're back to 94x, i.e. big core rules (and I'll keep trying to upload the new big core graphics version of pmarsv to soda, so far no luck). Cheers, Stefan (stst@vuse.vanderbilt.edu) P.S.: as always, here the round-robin results: Elapsed time: 3461 seconds (00:57:41) Rank Name Author %W %L %T Score ___________________________________________________________________________ 1 ivscan J.Layland 34 25 41 1293 2 Sauron T Michael Constant 37 33 30 1281 3 Request v2.0 Brant D. Thomsen 36 36 28 1225 4 Paradox v2 Mike Nonemacher 20 17 62 1109 5 NC 94 Wayne Sheppard 18 22 59 1030 6 Small Jay Han 17 20 63 1022 7 ^C Steven Morrell 16 22 62 984 8 repimp nandor sieben 3 6 91 894 From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: finding mod numbers Date: 30 Apr 1994 22:38:45 GMT Message-ID: <2pumll$l5t@agate.berkeley.edu> Antonette Nixon wrote: >Quick question. How would I go about writing an algorithm to figure out >what mod a particular constant is? For example, if I had the number 3158 >(picked randomly just now), how would I go about finding what kind of a >bombing pattern using that constant would give? There are two easy ways. By far the better of the two is to get my Optima program (not Nandor's -- his doesn't have this feature) from soda (mail me for the filenames if you don't have them already). Optima has a feature for testing any given step size and telling you its mod number and optima number. The other way is to write a Dwarf program using that step size, and watch it on a graphical core-viewer until the pattern repeats. Then count the space between bombs. (You have to write a slightly more complicated bomber if the mod number is less than 4, so that is doesn't hit itself. It's not hard though. Mail me if you have any questions.) -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y