From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Optima numbers occuring in pairs Date: 1 Jul 1994 03:17:42 GMT Message-ID: <2v01sm$ta@agate.berkeley.edu> Jay "Thierry" Han wrote: >The perfect pattern would be dichotomic: bomb at mod-4000, then >mod-2000, then mod-1000, 500, 250, 125, etc. narrowing it down >without hitting previous bombs. This, I believe, ensures the >earliest discovery of the opponent. But would that be the perfect pattern? It seems to me that while a binary search would be the best for an opponent of unknown size, it it is far from optimal for finding an opponent of known size. A plain mod-10 bombing run will work better against scanners. I know that my programs work better when I tailor the bombing patterns to beat specific-size opponents, rather than using standard optima numbers (which try to approximate a binary search). -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: morrell@jeeves.math.utah.edu (Steven C. Morrell) Subject: Chapter 2 is ready Date: Sat, 2 Jul 1994 21:30:52 GMT Message-ID: Chapter 2 of my tutorial on stones is now available via anonymous FTP at ftp.csua.berkeley.edu. Additionally, chapter 1 has been updated, after some helpful suggestions from J. Layland. Presently they are available as chapter2.Z and chapter1.1.Z in the /pub/corewar/incoming directory, but eventually they should be moved to the /documents subdirectory and the present chapter1.Z, which is now outdated, should be removed. Steven Morrell morrell@math.utah.edu From: uj211@freenet.Victoria.BC.CA (Ben Young) Subject: '94 draft standard Message-ID: <1994Jul3.050219.2320@freenet.victoria.bc.ca> Date: Sun, 3 Jul 1994 05:02:19 GMT I think my first post ended up in some bit bucket somewhere, so I'll try this again... Can somebody email me a copy of the '94 draft standard? I can't get anything via FTP as the Victoria Freenet doesn't allow users to use FTP. Also, I have no access to any of the unix decompression/deencryption utilities. I'd also appreciate any tips about good MARS programs that handle the '94 draft standard and run on an IBM compatible (386) or a Mac, and where I can get them (other than the FTP site...) My address is uj211@freenet.victoria.bc.ca Tnx in advance! -- --Ben Young------UJ211@freenet.victoria.bc.ca------VE7AJT-- It is said that the Devil has all the best tunes. This is broadly true. But Heaven has the best choreographers. - Terry Pratchett & Neil Gaimann - Good Omens. From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: Optima numbers occuring in pairs Message-ID: Date: 03 Jul 1994 15:48:13 GMT In article <2v01sm$ta@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: > Jay "Thierry" Han wrote: > >The perfect pattern would be dichotomic: bomb at mod-4000, then > >mod-2000, then mod-1000, 500, 250, 125, etc. narrowing it down > >without hitting previous bombs. This, I believe, ensures the > >earliest discovery of the opponent. > > But would that be the perfect pattern? It seems to me that while a > binary search would be the best for an opponent of unknown size, it > it is far from optimal for finding an opponent of known size. A plain > mod-10 bombing run will work better against scanners. I know that my > programs work better when I tailor the bombing patterns to beat > specific-size opponents, rather than using standard optima numbers > (which try to approximate a binary search). ^^^^^^^^^^^ That's the gotcha, I think. The problem indeed is that it's impossible to compare a fixed-step pattern and a binary pattern of the same speed. We could "cheat", for experiment's sake, and maybe someone will go into the trouble of actually trying it (by, say, slowing down the opponents, or whatever). Your point stands, however, that if you do know the opponent's size, you don't have to go into the trouble of doing the binary search. You might even get lucky and find a pattern that is efficient against several opponents. I wouldn't say though that the binary pattern is "far from optimal" in any case. Any bombing that's fast enough will do well, *in the average*, against scanners, unless that scanner itself uses a non-fixed step. Anyway, all this is pretty theoretical, as I don't think you could write a binary pattern that's efficient enough. Certainly not one that's as fast as a fixed step. -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science & 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: s934146@minyos.xx.rmit.EDU.AU (Jonathan Benson) Subject: KoTH killing programs??? Date: 4 Jul 1994 11:18:21 GMT Message-ID: <2v8r5t$ma2@aggedor.rmit.EDU.AU> How do I kill a program that I have on the hill but don't want there. I've tried doing what it says in the FAQ, etc. I.e. a ;kill But it doesn't work, as a result of which I have a "JMP 0" program rating higher than my other efforts. :( SNAFU Any help appreciated. -- | Jonathan Benson | E-Mail: s934146@minyos.xx.rmit.edu.au | | | Royal Melbourne Institute Of Technology | | | Melbourne, Victoria, Australia | From: al663@FreeNet.Carleton.CA (Chris Sibbitt) Subject: This is ticking me off! CoreStep. Message-ID: Date: Mon, 4 Jul 1994 21:42:41 GMT Ummm, let's see... I received corestep awhile ago, but unfortunately couldn't compile it.. I don't know why, all the proper files were there, but it still wouldn't work (Crappy compiler.... probably from the stone-age). Anyways.... I was hoping that there is at least one person out there who has a Dos PC, and would be kind enough to send me a uuencoded executable of corestep, ie. precompiled, ready to run WITHOUT any extra files. And for anyone who might remember, yes, it was a LONG time ago that I got the uncompiled ver. of corestep, but I brushed it off hoping that I wouldn't need it... and now I do... quite badly in fact. -Chris -- | Name: Chris Sibbitt (a.k.a. Wanderer) |Burble............GAK! |����� | Address: al663@freenet.carleton.ca | So? Sue me! |����� JNMP wuz here... !696! GU(cs/m) d(?) (-)p(+) c++@ l u(+) e* m--- s+ !n(---) h(--) f+@ !g w+@ t+ r x? From: morrell@jeeves.math.utah.edu (Steven C. Morrell) Subject: A mailing list for my tutorial Date: Wed, 6 Jul 1994 05:51:52 GMT Message-ID: For those of you who do not have anonymous ftp and decompress software, I have started a mailing list for my "tutorial full of code" where you can get the latest chapter hot off the press. To sign up, just send me a request, and I'll even throw in the first two chapters that I've written! If you haven't received chapter 2 in the mail today, you are not yet on the mailing list. These chapters are, of course, available via anonymous ftp at ftp.csua.berkeley.edu in the /pub/corewar/documents directory. Steven Morrell morrell@math.utah.edu From: pk6811s@acad.drake.edu Subject: Homemade Ice Cream - yum! Date: 7 Jul 94 13:47:34 CST Message-ID: <1994Jul7.134734.1@acad.drake.edu> Homemade Ice Cream is FAR more successful than I thought it would be. Basically it only loses to Torch, Sasami (what IS that thing anyway?) Stimpy, and SJ-4. And ties Ryooki and Azuka. The basic goal was to re-introduce paper on the Hill. Since imps came back paper was the poor relation - too lossy against scanners and spl-jmp bombers, and since all the stones seem to have spirals - unable to score massively against anybody. Of course, Ryooki and Azuka are also paper - just paper??? Earlier experiments showed that an effective means of locating scanners (at least the ones on the Hill) is a sub/jmz scan using a small step size - around 11. The same scan is also somewhat effective in locating rapid-launched spirals, large launch routines, and vampire fangs. Having found something the first thing to do is to save that instruction on the chance it is a fang or spiral, then proceed to bomb the location and some distance backward from there - on the chance it is someone's startup code. Then reset the pointer to the original found location. To attack a spiral just start dat-bombing using the found instruction as the increment. But before starting, how about subtracting it once and dat-bombing THAT location? If our found instruction was a fang this will zap the vampire's proto-fang and upset his bombing sequence. Then perform the spiral attack until dat-zero is found - using dat-zero as the bomb in case the increment happens to be zero. What happens next depends on what the opponent is. If a scanner, either he is dead or he is going to win once the paper is launched. If a vampire, we might not have zapped his fang and he's still dangerous. If a stone-imp, even if the imp is dead he might have killed our paper. At this point it makes sense to start two independent activities, just in case one of them has been killed. This 'redundancy' is an effecive way to introduce second-phase strategy, since the risk of both sets of code having been bombed are small. The antivamp routine is designed to find one fang and attack the a-pointer location, then core-clear and gate. The core-clear won't happen unless the paper is killed, but it does give some useful backup in that instance. The paper is my old 7-process version that frequently kills short 3-point spirals - which seem to be popular again. Next, space the components out so they don't all get clobbered at the same time. First try was equal spacing - which worked well. Then it occured to me that this would leave me open to disaster against an opponent using certain step sizes which could bomb all the components in a brief period. So I tried uneven spacing and gained a small overall improvement against several opponents. The antivamp uses a little different bomb - 'MOV 20,<5' - which hopefully will destroy any processes trapped in the pit. It also starts its search only 200 instructions away - thus if the paper is dead antivamp will complete the search rapidly, finding the paper, and start the core-clear. ;redcode-94 quiet ;name Homemade Ice Cream ;kill Homemade Ice Cream ;author P.Kline ;strategy bscan, spiral attack, antivamp, paper ;macro unpit mov 20,<5 ; destroy vampire's pit avb dat 0,0 spiral dat 0,0 scan sub #13,trace ; initial scan start jmz.f scan,@trace mov @trace,spiral ; save for spiral-attack trace mov p1b,-130 ; bombs away sub #8,@start djn trace,#13 jmp fintrap,1000 for 7 dat 0,0 rof gloc dat 0,0 for 9 dat 0,0 rof fintrap add #8*13,trace ; reset pointer trptr sub spiral,trace ; in case it's a fang... killimp mov avb,@trace ; spiral-attack on imps add spiral,@trptr jmn.f killimp,@trace; until dat-zero is found spl av,1000 dloc jmp p1,gate+50 for 22 dat 0,0 rof av jmz.a 0, __ __| | ) _ \ | | \ \ / _) | __ \ _ \ / ( | | | \ \ \ / _` | __| __| | _ \ __| | | | | __/ \__ |___ __| \ \ \ / ( | | | | ( | | _| _| |_|\___| _/ _| \_/\_/ \__,_|_| _| _|\___/ _| July 7, 1994 Issue #10 ______________________________________________________________________________ This newsletter covers the current status of the ICWS '94 Draft hills, and also attempts to keep up with the latest ideas on 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: The next chapter in Steven Morrell's "My First Corewar Book" is now available by anonymous FTP to ftp.csua.berkeley.edu (NOTE THE NEW ADDRESS) in the pub\corewar\incoming as "chapter.2.Z". This chapter provides an excellent overview on "stones" that every budding corewar expert will want to have a copy of. The first ten issues of this newsletter can also be found on ftp.csua.berkeley.edu as "94warr1.txt.Z". If you missed any issues in the past, now is your chance to get them. ______________________________________________________________________________ The ICWS '94 Draft Hill: Core size: 8000 instructions 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 on "Pizza": # %W/ %L/ %T Name Author Score Age 1 47/ 32/ 22 Homemade Ice Cream P.Kline 161 1 2 40/ 27/ 33 Torch t5 P.Kline 154 23 3 37/ 24/ 39 Sasami T.Hsu 150 43 4 35/ 20/ 45 Blue Funk 3 Steven Morrell 149 18 5 42/ 39/ 19 Pyramid v5.5 Michael Constant 146 108 6 42/ 39/ 19 Keystone t33 P.Kline 145 130 7 33/ 22/ 45 Ryooki T.Hsu 143 5 8 30/ 18/ 53 Aeka T.Hsu 141 20 9 38/ 36/ 26 Stimpy v2.0 Brant D. Thomsen 140 59 10 31/ 22/ 47 NC 94 Wayne Sheppard 139 343 11 39/ 39/ 21 Christopher Steven Morrell 139 251 12 29/ 19/ 51 Cannonade P.Kline 139 188 13 28/ 19/ 53 Insight v1.0 Brant D. Thomsen 138 50 14 31/ 25/ 44 Lucky 3 Stefan Strack 137 323 15 40/ 43/ 18 SJ-4 J.Layland 137 19 16 41/ 47/ 13 Iron Gate 1.5 Wayne Sheppard 135 307 17 27/ 21/ 53 Blue Funk Steven Morrell 132 330 18 36/ 41/ 23 Sauron v6.0 Michael Constant 132 54 19 41/ 49/ 10 Rave 4.1 Stefan Strack 132 295 20 36/ 43/ 21 Request v2.0 Brant D. Thomsen 129 11 The hill became much younger over the last couple of weeks with the loss of the two oldest programs. "Dragon Spear" by C. W. Blue was kicked off the hill at the rip old age of 346. Three cycles later, "Request" by Brant Thomsen also was overcome, at the age of 347. With the loss of these two fossels, "NC (Night Crawler) 94" is now the oldest program -- and it looks like it will be sticking around for a while still. See Steven Morrell's new tutorial if you're curious how NC does so well. "Blue Funk 3", "Ryooki" and "Homemade Ice Cream" are three new additions to the hill that all seem to be doing well. Excited corewar fans everywhere are anxiously waiting to find out what other exciting warriors Paul Kline will be cooking up in the future. The current ICWS '94 Draft hill on "Stormking": # %W/ %L/ %T Name Author Score Age 1 44/ 29/ 26 Sauron v3.6 Michael Constant 160 3 2 42/ 30/ 28 Killer instinct Anders Ivner 154 26 3 36/ 20/ 43 Twimpede+/8000-d1 Jay Han 152 16 4 35/ 20/ 45 Lucky 3 Stefan Strack 151 14 5 36/ 22/ 42 NC II Wayne Sheppard 150 81 6 36/ 24/ 40 Sphinx v5.1 W. Mintardjo 147 84 7 43/ 40/ 17 Ntttgtstitd Simon Hovell 146 27 8 41/ 38/ 21 Request v2.0 Brant D. Thomsen 144 19 9 38/ 33/ 29 stone-test Stefan Strack 142 1 10 41/ 41/ 18 Sylvester v1.0 Brant D. Thomsen 141 63 11 29/ 19/ 52 ttti nandor sieben 140 37 12 32/ 25/ 43 JustTakingALookSee J.Layland 139 80 13 29/ 20/ 50 ttti94 nandor sieben 138 32 14 30/ 23/ 46 Snake Wayne Sheppard 137 36 15 39/ 42/ 18 Beholder's Eye v1.7 W. Mintardjo 136 93 16 42/ 48/ 10 Rave 4.1 Stefan Strack 135 9 17 39/ 44/ 18 SJ-4 J.Layland 134 30 18 38/ 42/ 21 tiny J.Layland 133 61 19 37/ 43/ 20 Christopher Steven Morrell 131 25 20 36/ 44/ 20 Fast Food v2.1 Brant D. Thomsen 128 39 ______________________________________________________________________________ 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 on "Pizza": # %W/ %L/ %T Name Author Score Age 1 49/ 34/ 17 ivscan6b J.Layland 165 22 2 47/ 35/ 18 Pyramid v5.3 Michael Constant 159 49 3 46/ 34/ 20 Request-55440 Brant D. Thomsen 158 158 4 36/ 17/ 47 Aleph 1 Jay Han 156 20 5 36/ 24/ 40 Variation G-1 Jay Han 148 122 6 43/ 39/ 18 Fscan Jay Han 146 6 7 41/ 37/ 22 Aleph 0 Jay Han 146 21 8 40/ 36/ 24 Stimpy v2.0 Brant D. Thomsen 144 13 9 31/ 23/ 46 NotSoBigImps James Layland 140 18 10 38/ 36/ 26 Lump J.Layland 139 103 11 31/ 24/ 44 Der Zweite Blitzkrieg - 9 Mike Nonemacher 138 120 12 39/ 39/ 22 Vanity IIx Stefan Strack 138 113 13 42/ 48/ 10 Rave B4.1 Stefan Strack 137 119 14 32/ 29/ 39 Lucky 13 Stefan Strack 136 164 15 30/ 24/ 46 Blue Funk Steven Morrell 136 12 16 41/ 47/ 13 Squint Mike Nonemacher 135 96 17 31/ 27/ 43 Splash 1 Jay Han 135 123 18 40/ 49/ 11 Plasma v5 Wayne Sheppard 130 60 19 27/ 23/ 50 Insight v1.0 Brant D. Thomsen 130 1 20 31/ 32/ 37 Sasami / 55440 T.Hsu 130 8 Things still appear to be quiet on the Experimental hill. Personally, I expect this hill to really pick up as some of the new programs on the '94 hill start moving over. I have found it especially interesting how differently programs can do between the two hills. For example, my program "Request" does much better on the Experimental hill, while "Insight" does much better on the Standard hill -- both results being exactly the opposite of what I expected! The current ICWS '94 Experimental (Big) hill on "Stormking": # %W/ %L/ %T Name Author Score Age 1 48/ 12/ 40 Variation M-1 Jay Han 184 2 2 46/ 30/ 24 Request-55440 Brant D. Thomsen 162 54 3 40/ 20/ 40 Lucky 13 Stefan Strack 161 20 4 46/ 36/ 18 Raiden Richard van der Brug 157 3 5 45/ 35/ 19 Vanity IIx Stefan Strack 155 8 6 35/ 18/ 47 Bakers Dozen Wayne Sheppard 153 13 7 40/ 30/ 31 Sauron v2.4 Michael Constant 150 5 8 30/ 15/ 55 Imperfection v2.3 Michael Constant 146 48 9 36/ 31/ 33 Variation D-1 Jay Han 142 15 10 44/ 47/ 10 Rave B4.1 Stefan Strack 141 9 11 42/ 46/ 12 bigproba nandor sieben 138 12 12 41/ 46/ 14 Dagger v7.0 Michael Constant 136 14 13 40/ 48/ 11 The Count Jay Han 132 44 14 27/ 23/ 50 BigImp Alex MacAulay 132 95 15 30/ 29/ 41 jmpWetPaper-94x-a J.M.Pohjalainen 131 1 16 26/ 23/ 51 BigImps James Layland 129 114 17 31/ 35/ 34 Veeble Jr. T. H. Davies 126 16 18 28/ 37/ 34 Industrious Stefan Strack 119 4 19 29/ 40/ 31 Open Arms Stefan Strack 117 7 20 29/ 41/ 30 Test Stefan Strack 116 6 ______________________________________________________________________________ HINTS and HELPS: When I first put together the program "Insight", there were several things I was thinking about. Perhaps most of all was the thought that if I quickly threw something together I could have have the first program on the '94 draft hill that uses A-field indirection. (I'm still not sure if that is the case.) However, beyond that, I wanted to create a simple program that I could use to discover weaknesses in other's programs. I suppose, in that regard, "Insight" is rather similar to James Layland's DJN stream experiment. (B.T.W. If you want to know why "Insight" and "Stimpy" did so well against the DJN.F program, simply look at the decoy!) The fact that "Insight" is actually managing to stay on the hill is simply a nice bonus. ;redcode-94 ;name Insight v1.0 ;author Brant D. Thomsen ;strategy Stone/imp-spiral ;strategy Uses A-field indirection ;strategy Submitted: @date@ ;assert CORESIZE == 8000 step equ 3039 init equ step+1 gate equ -12 impstep equ 2667 cdist equ CORESIZE / 22 dat.A #1, #1 ; Large decoy to slow DJN streams, dat.A #1, 1 ; while still remaining unique dat.A #1, @1 ; in case of CMP scanners. dat.A #1, <1 . . . dat.BA 1, >1 dat.BA 1, *1 dat.BA 1, {1 dat.BA 1, }1 stone spl #gate, > "Blue Funk 3", "Ryooki" and "Homemade Ice Cream" are three new additions to > the hill that all seem to be doing well. Excited corewar fans everywhere are > anxiously waiting to find out what other exciting warriors Paul Kline will be > cooking up in the future. Not to mention T.Hsu, who's not bashful about taking the Hill by storm! > > Perhaps the one lesson I can give you from this program is that it may be a > good idea to use _non-zero_ A-field values on you SPL #, JMP #, MOV #, and > DJN # instructions. As there are no true A-field scanners out there, (they And somewhere down the line people will be asking "how come everyone uses non-zero A-fields?". The answer will be that sometime in the distant, dark evolutionary past there was a predator that used a-field indirection. > I am also running up against the interesting problem of running out of ideas > for hints that apply exclusively to the '94 standard. Either we need to add > some more features to pMARS, or I'll need to start using more general hints > instead. (There's always IJZ, of course ... ) More general hints! > One other issue that needs to be dealt with is, quite honestly, the amount of > time that is required to generate these newsletters. With my new job and > upcoming marriage making large demands on my schedule, I find that I am Uh-Oh. Better set some priorities Brandt. What's more important... :-) > What I would like from each of you is a list of what you would like to see > most in future editions of the Warrior. Which parts of the current newsletter > format do you like and dislike the most, and what new features would do the > most to encourage, entertain, and educate the corewar community? What > specific topics would you like to see covered? One local longtime sports radio announcer has been quoted as saying, "When you run out of things to say, keep talking!". The point being that a certain level of noise is useful in just holding people's attention. Of course we don't want just *noise*, but even discussion about little things, like boot distances, zero/non-zero fields, old warriors, or early tournaments, discovered effects of 'tweaking', are interesting. And your audience is made up of everyone from unwashed newcomers to gray- haired oldtimers, so almost any discussion is good for somebody. Another useful thing is to encourage source postings. If people even posted programs that failed, there could be discussion about the strengths and weaknesses of the code. It's not like writing an encyclopedia. The newsletter is more like a discussion leader. Ask questions, pose ridiculous ideas, use humor. Keep stirring the pot and see what cooks. Paul Kline pk6811s@acad.drake.edu From: Dave Darling Subject: Paper combos Message-ID: <1994Jul8.201510.1288@riacs.edu> Date: Fri, 8 Jul 94 20:15:10 GMT I've been thinking about Papers for quite a while. I was very pleased to see Homemade Ice Cream on the hill, and published in this group! It got me thinking once again about various Paper combinations. It seems obvious that Paper by itself cannot score enough wins to make it onto the Hill. Not too surprising, as most programs on the Hill are multi-strategy forms. However, I think that the paper/stone combo is just about the only one I've ever seen. Has anyone managed to make a paper/scissors combo work? Or even a paper/spiral? I guess that the key to either one of those would be to keep the paper inactive, or at least slowed down, early. But I guess that would not be real good for the spiral. Just some random thoughts--hoping to spark an interesting discussion. --DD Dave Darling, | HELP! I'm in TQM training, Cockpit Graphics Programmer | and I can't get up! GU d--@ -p+(p-) c+ !l(l--) u++(u--) e- m---@ s+/+ n+@ h+ f? g-(g+) w++ t++ r+@ y* From: jlayland@kilroy.jpl.nasa.gov (James Layland) Subject: Re: Paper combos Message-ID: <1994Jul9.014530.23551@llyene.jpl.nasa.gov> Date: Sat, 9 Jul 1994 01:45:30 GMT In article <1994Jul8.201510.1288@riacs.edu>, Dave Darling wrote: > It seems obvious that Paper by itself cannot score enough wins to make >it onto the Hill. Not too surprising, as most programs on the Hill are >multi-strategy forms. However, I think that the paper/stone combo is just >about the only one I've ever seen. > Has anyone managed to make a paper/scissors combo work? Or even a >paper/spiral? I guess that the key to either one of those would be to >keep the paper inactive, or at least slowed down, early. But I guess that >would not be real good for the spiral. FlyPaper was a temporarily successful hybrid which used a small scanner rather than a stone to try to take out larger scanners. To make it smaller and launch the paper quicker against stones, it only found one thing, bombed it then launched the paper. Decoys and quickscans contributed to its demise. Dan Nabutovsky successfully used a paper/scissors combination in Stefan's 1993 tournament (stampp.red). However, in the tournament, he only needed to score better than one opponent, so large numbers of ties were not a problem. I can't think of any paper/imp combinations. My guess is that anything that killed the paper would take out the imps at the same time, although I have frequently been frustrated by the ability of imps to survive paralysis and keep going after stunning their companion stone. Tell us if you find anything that works... -- James Layland jlayland@grissom.jpl.nasa.gov From: pk6811s@acad.drake.edu Subject: Re: Paper combos Date: 9 Jul 94 20:22:11 CST Message-ID: <1994Jul9.202211.1@acad.drake.edu> In article <...> jlayland@kilroy.jpl.nasa.gov (James Layland) writes: > > I can't think of any paper/imp combinations. My guess is that anything that > killed the paper would take out the imps at the same time, although I have > frequently been frustrated by the ability of imps to survive paralysis and keep > going after stunning their companion stone. > I think the problem is that once the paper gets spl-stunned, the spiral get very little time. It may survive the core-clear, but then it gets stopped by a gate. It might be possible to get ties if you launch lots of spirals with the paper, so they can't all be gated. In theory if you had a very fast paper... you could start it after a delay, hoping one copy would get to a location already scanned/spl-bombed by the opponent. If even one copy survived the core-clear you could get a win. And most scanners finish their core-clear with plenty of time left in the game. Also, CW Blue had a paper that carried a pit along with it that had some success. One problem with paper is that it wastes so much time overwriting itself. Maybe someone could work out 'optimal' numbers for replicators that would reduce this to a minimum :-) Paul Kline @c@ pk6811s@acad.drake.edu - ignorance exceeded only by inquisitance - From: leon.kotze@digitec.co.za (Leon Kotze) Subject: Program Message-ID: <758.155.uupcb@digitec.co.za> Date: 10 Jul 94 14:19:00 GMT I am trying to get a copy of a Corewar simulator/game with an introductory guide for what corewar is. I saw a message a while ago with the relevant information but I have somehow lost it. I have access to FTP and E-mail (Address at bottom). Thanking you Leon Kotze (leon.kotze@digitec.co.za) --- . SPEED 1.40 [NR] . ---- --- Digitec Online --- Johannesburg, South Africa --- tel +27 11 476-2008 --- From: vh@fline.nullnet.fi (Ville-Hermanni Kilpi{) Subject: Corewar FAQ ? Message-ID: Date: Sun, 10 Jul 1994 16:25:39 GMT Is there a Corewar FAQ and where could it be found ? Does somebody post it regulary ? Also I'm looking a program which run these Corewar codes in PC. Any suggestions what software is good ? -- * vh@fline.nullnet.fi From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 12 Jul 1994 05:07:22 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1994/07/09 Version: 2.3.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 116 a copy of the current instruction set? 5. What is ICWS'94? Which simulators support ICWS'94? 135 6. What is the ICWS? 152 7. What is TCWN? 162 8. How do I join? 170 9. Are back issues of TCWNs available? 187 10. What is the EBS? 194 11. Where are the Core War archives? 208 12. Where can I find a Core War system for . . . ? 226 13. I do not have ftp. How do I get all of this great stuff? 275 14. I do not have access to Usenet. How do I post and receive news? 285 15. When is the next tournament? 303 16. What is KotH? How do I enter? 314 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 483 18. How does SLT (Skip if Less Than) work? 495 19. What does (expression or term of your choice) mean? 507 20. Other questions? 650 --------------------------------------------------------------------- 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 two anthologies: 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 Author: Dewdney, A. K. Title: The Magic Machine: A Handbook of Computer Sorcery Published: New York: W. H. Freeman (c) 1990 ISBN: 0-7167-2125-2 (Hardcover), 0-7167-2144-9 (Paperback) Library of Congress Call Number: QA76.6 .D5173 1990 A.K. Dewdney's articles are still the most readable introduction to Core War, even though the Redcode dialect described in there is no longer current (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 practically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. Michael Constant (mconst@ soda.berkeley.edu) is reportedly working on a beginner's introduction. --------------------------------------------------------------------- Q 5: What is ICWS'94? Which simulators support 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 (see Q 5). ---------------------------------------------------------------------- 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. It is a good idea to check pub/corewar/incoming for program updates first. 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-21.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) pmars06s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars06s.tar.Z - same as above pmars06.zip - PC executables with graphics display, req 386+ macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincor11.zip - MS-Windows system, shareware ($15) ---------------------------------------------------------------------- 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. If you don't have access to the net at all, send me a 3.5 '' diskette in a self-addressed disk mailer with postage and I will mail it back with an image of the Core War archives in PC format. My address is at the end of this post. ---------------------------------------------------------------------- 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 a line starting with ";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. The server kills programs by assigning an impossibly low score; it may therefore take another successful challenge before a killed program is actually removed from the hill. 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.6, a platform-independent corewar system available at soda (see Q12). The '94 and '94x hills allow three experimental opcodes and addressing modes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) * - indirect using A-field as pointer { - predecrement indirect using A-field } - postincrement indirect using A-field ---------------------------------------------------------------------- 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, - While cruising the NUM8000 file I found something interesting in the larger imp numbers. There are some pairs of numbers that make for natural gate-busting combinations. Unfortunately the smallest pair is 7799/7801, which require a minimum of 199 and 201 processes each! If you launch a MOV.I #0,7801 and MOV.I #0,7799 pair of spirals into core such that they alternate cycles, and the 7801 spiral is gated first - voila! it gets decremented twice and sets up the 7799 spiral to pass the gate. I ran 100 battles against a 'JMP 0,<-5' opponent and the spirals won 66 times. (Also interesting is that 7799 = -201 and 7801 = -199) Now if someone could just figure a reliable way to launch over 400 processes against Rave and Iron Gate... - One advantage of big spirals is the likelihood that they will be inside the gate by the time the opponent starts gating. - On another topic, I think someone could adapt Torch's mov/spl bomb for a Leprechaun/SJ-4a style bomb/scanner. It would have a faster 'useful' delivery than Torch, since the second half of the bomb would never be moved unless there really was something to attack. - My 'test' program that was on the '94 hill for a few days was a simple hack. Just copy three 61-point imp launchers into core and start them, then start imp-killing paper. Lots of ties, but not many wins. Have to add a stone or something. - Using the post-increment operator it is easy to write a replicator that makes two copies instead of one - less overhead per copy. You still get a lot of overwriting however :-( - There's also a way to write a replicator to protect it against a _scanning_ vampire. Hmmm.. now with a-indirect operators maybe even easier than before! - ...so many ideas - so little time... :-) Paul Kline pk6811s@acad.drake.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: pMARS v0.6.2 maintenance release Message-ID: <1994Jul16.195508.3500@news.vanderbilt.edu> Date: Sat, 16 Jul 1994 19:55:08 GMT Now at soda.berkeley.edu, in pub/corewar/incoming: -rw-rw-rw- 1 stst 240425 Jul 16 14:14 pmars062.zip - DOS execs -rw-rw-rw- 1 stst 181056 Jul 16 14:14 pmars06s.tar.Z - C source -rw-rw-rw- 1 stst 137370 Jul 16 14:17 pmars06s.zip - C source (if you can't FTP, use ftpmail@decwrl.dec.com, message body: help) This is mostly a bug fix release; there was a subtle screw-up with the new } addressing mode. -Stefan (stst@vuse.vanderbilt.edu) >____________________ >What's new in version 0.6.2 > >Bug fixes: > > MOV.I x,}x used to execute according to in-memory evaluation. This > inconsistency is now fixed. Thanks to Ting Hsu for the bug report. > > The assembler used to read (but not assemble) past an END statement > resulting in error messages for text after END. Fixed. > > >New features: > > pMARS can now assemble warrior posts directly. You no longer have to > remove headers, extented descriptions and signatures, because text > before a ;redcode and after an END line is ignored. From: bremermr@rock-opera.cc.purdue.edu (Myer Bremer) Subject: reflections Message-ID: Date: Tue, 19 Jul 1994 17:00:28 GMT Greetings. I've been following this newsgroup for awhile, and I finally decided to join the festivities. Many thanks go to all the veterans for their support of new players--answering our newbie questions, posting redcode. Special thanks to the pMars team, to S. Morrell for his corewar tutorial, and to P. Kline ( _PUSH OFF_ helped me immensely). My question: what are reflections and how do you apply them? Thanks in advance. Myer R Bremer. From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: reflections Date: 19 Jul 1994 18:08:29 GMT Message-ID: <30h4qt$hbl@agate.berkeley.edu> Myer Bremer wrote: > My question: what are reflections and how do you apply them? From the Corewar FAQ: "Reflection - Copy of a program or program part, positioned to make the active program invisible to a CMP-scanner." CMP-scanners work by comparing location X with location X+N, and then bombing them if they are unequal. Normally N is quite a small number, typically 34, 98, or 14. A standard way to protect your program from CMP-scanners is to place identical copies ("reflections") of it in memory at offsets of 14, 34, 98, or any other common scan-numbers. This will cause CMP- scanners to ignore your program completely, so your program will be free to wreak whatever havoc it pleases. However, keep in mind that CMP-scanners have gotten quite advanced in the past year or so, and most of them use DJN-streams (see the FAQ for details) which are likely to hit your program even if the scan does not. However, if you are writing a stone or some similar program, the reflections may give you the extra time you need. (Also, keep in mind that reflections make your overall program image bigger, so any program with reflections is likely to lose pathetically to quick- scanners like Pyramid. Quick-scanners typically compare locations several hundred core locations apart, so you won't be able to place reflections at those locations. Then, the reflections you put in originally to combat regular "slow" scanners become a disadvantage.) -- Michael Constant (mconst@soda.berkeley.edu) From: ameoba@eskimo.com (Sean McKeon) Subject: Newbie ?'s Message-ID: Date: Wed, 20 Jul 1994 23:26:17 GMT Hello, I have been interested in corewar for some time now, but I just recently got interested in seriously programming. My question is, how should I start? I have the how to program CW files off soda.berkeley.edu, any input would be appriciated. Date: Fri, 22 Jul 1994 14:14:25 MST From: Message-ID: <94203.141426AHNAS@ASUACAD.BITNET> Subject: Re: reflections A reflection sometimes only slows down the opponent scanner even if there is no djn stream. The reason is that even if a program at location n has reflections at n-k and at n+k, the code for example at n-k has no reflection at (n-k)-k so it will be bombed and after that our reflection is gone and our code will be bombed. Nandor. From: pk6811s@acad.drake.edu Subject: Re: reflections (and boot distances) Date: 23 Jul 94 19:23:40 CST Message-ID: <1994Jul23.192340.1@acad.drake.edu> In article <94203.141426AHNAS@ASUACAD.BITNET>, writes: > A reflection sometimes only slows down the opponent scanner even if there is no > djn stream. The reason is that even if a program at location n has > reflections at n-k and at n+k, the code for example at n-k has no reflection > at (n-k)-k so it will be bombed and after that our reflection is gone and > our code will be bombed. > Nandor. Many scanners are incapable of attacking either copy. A cmp-scanner compares N and N+D. If they are equal he scans N-2D and N-D. If they are not equal he attacks N+D and resets to scan N-D and N. Rescanning requires fewer code lines than attacking N and N+D at the same time. If I have active code at location 1000 and a reflection at 1076 a cmp-scanner using a cmp-distance of 76 as described above can't attack either of them. Here's why: If he scans 1000 and 1076 they are equal and he moves on. If he scans 1076 and 1152 -> he attacks 1152 and resets to scan 1000 and 1076, which are equal. .............X.........X....................................... |_________| |__compare these locations |_________| |__if equal compare these |__if not equal attack this one and... |_________| |__reset to compare these Most of the spl-jmp bombing cmp-scanners, including Iron Gate, are of this form. Agony and Rave use a different attack and can zap the copy which later leads to attacking the real code. These days later is too late :-) Anyway, since reflections became popular a couple of years ago nobody is publishing their actual scan distances anymore. Of course any published constants are succeptible to attack. If you know the boot distance of a particular program you can destroy it easily. And if you know the step increment of a stone you can do the same. Pretty soon nobody will want to publish anything. Fortunately you have to wipe more than a single opponent to get on the Hill, so any tailored attacks would need to be very cleverly written to maintain efficiency against a variety of opponents. -------- Speaking of boot distances.... It seems to me that an effective boot distance would be something close to 4000, but not *too* close. That way against a one-shot scanner (ala FlyPaper and Homemade Ice Cream) you would have an even chance of being protected by the decoy. Using a short boot distance leaves you open to that kind of scanning if it will find you before the decoy every time. Paul Kline pk6811s@acad.drake.edu From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: The '94 Warrior Date: 24 Jul 1994 02:25:26 -0500 Message-ID: <9407240725.AA10219@peruvian.cs.utah.edu> __ __| | ) _ \ | | \ \ / _) | __ \ _ \ / ( | | | \ \ \ / _` | __| __| | _ \ __| | | | | __/ \__ |___ __| \ \ \ / ( | | | | ( | | _| _| |_|\___| _/ _| \_/\_/ \__,_|_| _| _|\___/ _| July 23, 1994 Issue #11 ______________________________________________________________________________ In the past, _The_'94_Warrior_ was specifically dedicated to encouraging and supporting the '94 draft standard. Starting with this issue, the newsletter is oriented towards corewars in general. I have kept the title to avoid confusion, and because it is still my hope to keep abreast of, and possibly even accelerate, the latest advances in corewars. I hope you enjoy it! The FAQ is available through anonymous FTP to rtfm.mit.edu, as /pub/usenet/news.answers/games/corewar-faq.Z. There are also several tutorials on the '88 and '94 (draft) standard available on ftp.csua.berkeley.edu that will greatly ease the process of becoming a proficient "redcoder." ______________________________________________________________________________ CHANGES and CORRECTIONS: A slightly updated version of pMARS has been uploaded to ftp.csua.berkeley.edu. Version 0.6.2 has some minor bug fixes, and will also make it much easier to use code that you download from the newsgroup. (A very nice touch!) Thanks again to the pMARS group for an excellent job! Starting with this issue of the Warrior, I will be covering what I consider to be the three most active corewar hills: the '94 Draft Hill, the '94 Experimental (Big) Hill, and the '88 Standard Hill (all on Pizza@ecst.csuchico.edu). If there is enough interest, I can add other hills as well. (I considered adding the beginner's hill; but, since I have no programs on it, I have no idea what is happening there. Anyone want to cover that hill for me? Would anyone object if I kept a simple program on the hill just so I could follow it for a while?) ______________________________________________________________________________ The ICWS '94 Draft Hill: Standard: '94 Draft (with extensions) Core size: 8000 instructions 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 on "Pizza": # %W/ %L/ %T Name Author Score Age 1 41/ 26/ 33 Torch t5 P.Kline 155 51 2 46/ 38/ 16 Pyramid v5.5 Michael Constant 154 136 3 43/ 33/ 24 Homemade Ice Cream P.Kline 153 23 4 38/ 25/ 37 Sasami T.Hsu 152 71 5 34/ 21/ 44 Blue Funk 3 Steven Morrell 148 46 6 34/ 20/ 46 Ryooki T.Hsu 147 12 7 43/ 41/ 17 SJ-4 J.Layland 145 47 8 30/ 19/ 51 Aeka T.Hsu 141 1 9 39/ 37/ 24 Stimpy v2.0 Brant D. Thomsen 141 87 10 30/ 19/ 51 Cannonade P.Kline 141 216 11 32/ 23/ 45 NC 94 Wayne Sheppard 141 371 12 35/ 30/ 35 FlyPaper 3.0f J.Layland 140 2 13 38/ 37/ 25 Request v3.0 Brant D. Thomsen 140 14 14 37/ 37/ 26 IVScan 8000 James Layland 137 9 15 41/ 47/ 12 Iron Gate 1.5 Wayne Sheppard 136 335 16 39/ 43/ 18 Keystone t33 P.Kline 135 158 17 38/ 42/ 20 Christopher Steven Morrell 134 279 18 27/ 22/ 51 Blue Funk Steven Morrell 133 358 19 30/ 29/ 41 Lucky 3 Stefan Strack 132 351 20 41/ 52/ 7 test P.Kline 131 4 Another one of the old programs has disappeared from the hill: Rave 4.1 by Stefan Strack was killed at the respectable age of 320. Rave is a "CMP" scanner, and was one of the very first programs written specifically for the '94 standard. The leaders on the hill are no surprise, as we have the same five programs on the top of the hill that were there last issue. However, the competition is increasing. The difference between the scores of the top and bottom warriors on the hill is 24, compared with 32 just last issue. That's about as close as I have ever seen them. ______________________________________________________________________________ The ICWS '94 Draft Experimental Hill: Standard: '94 Draft (with extensions) 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 on "Pizza": # %W/ %L/ %T Name Author Score Age 1 49/ 34/ 17 ivscan6b J.Layland 165 22 2 47/ 35/ 18 Pyramid v5.3 Michael Constant 159 49 3 46/ 34/ 20 Request-55440 Brant D. Thomsen 158 158 4 36/ 17/ 47 Aleph 1 Jay Han 156 20 5 36/ 24/ 40 Variation G-1 Jay Han 148 122 6 43/ 39/ 18 Fscan Jay Han 146 6 7 41/ 37/ 22 Aleph 0 Jay Han 146 21 8 40/ 36/ 24 Stimpy v2.0 Brant D. Thomsen 144 13 9 31/ 23/ 46 NotSoBigImps James Layland 140 18 10 38/ 36/ 26 Lump J.Layland 139 103 11 31/ 24/ 44 Der Zweite Blitzkrieg - 9 Mike Nonemacher 138 120 12 39/ 39/ 22 Vanity IIx Stefan Strack 138 113 13 42/ 48/ 10 Rave B4.1 Stefan Strack 137 119 14 32/ 29/ 39 Lucky 13 Stefan Strack 136 164 15 30/ 24/ 46 Blue Funk Steven Morrell 136 12 16 41/ 47/ 13 Squint Mike Nonemacher 135 96 17 31/ 27/ 43 Splash 1 Jay Han 135 123 18 40/ 49/ 11 Plasma v5 Wayne Sheppard 130 60 19 27/ 23/ 50 Insight v1.0 Brant D. Thomsen 130 1 20 31/ 32/ 37 Sasami / 55440 T.Hsu 130 8 I suppose it's difficult to justify picking this as one of the three most active hills, as it hasn't changed since the last issue of _The_'94_Warrior_. Personally, I just like the fact that this hill has such a different "feel" than the smaller '94 hill. It makes it a completely different challenge to do well on it. (Besides, Jay Han might not forgive me if I dropped it!) ______________________________________________________________________________ The ICWS '88 Standard Hill: Standard: '88 Core size: 8000 instructions Max processes: 8000 per program Duration: After 80,000 cycles, a tie is declared. Max entry length: 100 instructions The current Standard KotH hill on "Pizza": # %W/ %L/ %T Name Author Score Age 1 41/ 26/ 33 Der Zweite Blitzkrieg Mike Nonemacher 156 41 2 46/ 38/ 16 SJ-4a J.Layland 155 40 3 39/ 24/ 37 Night Crawler Wayne Sheppard 154 69 4 44/ 37/ 19 Christopher Steven Morrell 150 33 5 42/ 36/ 22 Yop La Boum v2.1 P.E.M & E.C. 149 37 6 41/ 34/ 25 Blue Blood Ned Flanders 148 1 7 40/ 33/ 27 Keystone t21 P.Kline 147 79 8 43/ 40/ 17 Request v2.0 Brant D. Thomsen 147 60 9 44/ 42/ 13 Dragon Spear c w blue 146 59 10 34/ 22/ 45 ttti nandor sieben 146 63 11 40/ 35/ 25 Unknown Ned Flanders 146 2 12 43/ 43/ 14 Iron Gate 1.5 Wayne Sheppard 144 90 13 44/ 44/ 12 Q2 version 2.0 Travis Nixon 143 4 14 34/ 26/ 39 CAPS KEY IS STUCK AGAIN Steven Morrell 142 47 15 33/ 26/ 41 Blue Funk 88 Steven Morrell 141 6 16 40/ 41/ 19 Vanity II Stefan Strack 140 81 17 44/ 48/ 9 Juggernaut v1.5 Anders Ivner 140 82 18 37/ 36/ 26 Killer instinct Anders Ivner 138 84 19 40/ 43/ 17 Sauron v8.8 Michael Constant 137 36 20 35/ 33/ 33 FlyPaper 3.0 J.Layland 137 39 I've noticed that the '88 hill has turned into "beginners" hill of sorts. Most the hills that have contributed to the aging of this hill recently have been hanging around the bottom. This explains the absence of programs between the ages of 33 and 6. (Christoper was, I believe, the last program to move over from the original KotH hill.) However, a couple of new programs have finally broken this trend. Q2 by Travis Nixon was right up at the top of the hill when it was first submitted, and Blue Blood by Ned Flanders is currently doing very well. ______________________________________________________________________________ HINTS and HELPS: This month's hint has been supplied by Ting-Yu Hsu. T. Hsu has been a powerful influence on the hill; Sasami has been in the top 5 on the '94 Pizza Draft Hill since it's submission over a month ago. I'm especially excited to be able to present this article, because replicators (also know as "paper" programs) are an area I am particularly weak in. (I know, I know, one of these days ...) Creating a Competitive Paper One of the warrior forms I have always enjoyed was the replicator. Unfortunately, replicators have been around so long that any good warrior (i.e., koth) can take one out. Thus, I took it upon myself to remedy this situation. Below is a side by side comparison of your typical paper and Ryooki, the only pure paper on the hill. Line Paper Ryooki ---- --------------------- ---------------------- 1 mov #6 ,0 nop >0 ,0 2 mov <-1 ,<1 mov <-1 ,{1 3 spl @0 ,-3365 spl @-3365,>800 4 mov 2 ,<-1 mov 3 ,{-1 5 mov 2 ,}25 6 jmz -4 ,-4 jmz.f *-4 ,*-4 7 dat <2667,<2667*2 dat <2667 ,<2667*2 Let's take the obvious addition first. Line 5 is an anti-vamp line. Look how easy this is to accomplish with A-field indirection. A more subtle application of line 5 is that it also serves to kill off older copies of itself. To understand this point, you must realize that 100 copies of paper running through core is more effective than 1000 copies of paper. Although paper is a replicator, every time it replicates the effectiveness of each individual copy decreases even though the effectiveness of the whole increases. As more and more copies of paper appear in core, however, the decreasing effectiveness of each individual copy starts to outweigh the increasing effectiveness of the whole. This is best known as the point of diminishing returns. Ryooki attempt to combat this by killing off copies which are more than one generation old. Probably the most important change is in line 6 (which forces the change in line 1). By performing a jmz.f, Ryooki vastly increases her chance of detecting a modification within her code. Additionally, by using indirection to perform the check and jump, Ryooki is actually using two lines to determine whether a modification occurred, not just one line. The change in line 1 is just a side effect of using jmz.f, since a "mov #7,0" would cause the jmz.f to consistently fail. The final change is in line 3 (which forces the changes in lines 2 and 4). With the availability of A-field indirection, Ryooki is able to store its destination pointer in the A-field of the spl statement. Besides freeing up the B-field, which Ryooki uses to randomly trash core, it also gives the spl a chance to check whether the next copy of Ryooki is in good shape. That is, when Ryooki performs her spl, her spl pointer should be pointing to a "nop >0,0" instruction. If this is not the case, I do not care where Ryooki splits to as long as it is NOT where the spl is pointing to. This works under the assumption that jumping to a random location is better than jumping to a location which you know is corrupt. Here is how the two replicators perform against warriors on the hill which I have code for (using mts and pmars -b -r 100 -F 2345). Some of the code is a bit out of date, but I didn't feel like browsing my mail for koth scores. (If someone out there could e-mail me more recent sources of warriors on the hill, I would appreciate it since I've been without a news feed for a few months now.) Rank Name Author %W %L %T Score ___________________________________________________________________________ 1 Paper Scott Nelson 18 38 43 1465 2 Request v2.0 Brant D. Thomsen 92 6 2 278 3 Iron Gate Wayne Sheppard 89 7 4 271 4 SJ-4a J.Layland 88 5 7 271 5 Stimpy v2.0 Brant D. Thomsen 86 6 8 266 6 Rave Stefan Strack 78 10 12 246 7 Sasami T.Hsu 41 7 52 175 8 Torch t5 P.Kline 40 13 47 167 9 Pyramid v2.0 Michael Constant 46 35 19 157 10 Blue Funk 3 Steven Morrell 7 13 80 101 11 Blue Funk Steven Morrell 6 16 78 96 12 Cannonade P.Kline 1 9 90 93 13 Aeka T.Hsu 2 15 83 89 14 Insight v1.0 Brant D. Thomsen 1 13 86 89 15 NC 94 Wayne Sheppard 0 35 65 65 16 Keystone t33 P.Kline 0 81 19 19 Rank Name Author %W %L %T Score ___________________________________________________________________________ 1 Ryooki T.Hsu 32 27 41 2051 2 Rave Stefan Strack 87 10 3 264 3 Stimpy v2.0 Brant D. Thomsen 82 9 9 255 4 Iron Gate Wayne Sheppard 76 16 8 236 5 SJ-4a J.Layland 71 15 14 227 6 Torch t5 P.Kline 44 26 30 162 7 Sasami T.Hsu 31 23 46 139 8 Blue Funk 3 Steven Morrell 7 16 77 98 9 Blue Funk Steven Morrell 1 13 86 89 10 Insight v1.0 Brant D. Thomsen 1 14 85 88 11 Aeka T.Hsu 0 13 87 87 12 Cannonade P.Kline 1 28 71 74 13 NC 94 Wayne Sheppard 0 31 69 69 14 Request v2.0 Brant D. Thomsen 9 79 12 39 15 Keystone t33 P.Kline 0 90 10 10 16 Pyramid v2.0 Michael Constant 1 98 1 4 From the rankings above, you should notice a few trends. First off, Ryooki beats up on the vampires due to her anti-vamp code, Ryooki does about the same against stones even though she is one line larger than paper, and finally, Ryooki tends to get more wins off programs designed to kill paper, like scanners and spl bombers. Here are scores for Ryooki when I remove the anti-vamp line. As you can see, the 6 line version of Ryooki scores pretty much the same as the 7 line version. It does better against the stones and worse against the vampires which is to be expected. Notice the performances of Torch and Sasami, two spl bombing warriors. If you compare these scores against the ones from paper, you should notice how much better Ryooki is at surviving non-dat bombs. Rank Name Author %W %L %T Score ___________________________________________________________________________ 1 Ryooki w/o anti-vamp T.Hsu 27 30 43 1863 2 Rave Stefan Strack 92 5 3 279 3 Stimpy v2.0 Brant D. Thomsen 83 7 10 259 4 Iron Gate Wayne Sheppard 79 14 7 244 5 SJ-4a J.Layland 78 13 9 243 6 Request v2.0 Brant D. Thomsen 47 50 3 144 7 Torch t5 P.Kline 29 25 46 133 8 Sasami T.Hsu 20 20 60 120 9 Cannonade P.Kline 1 14 85 88 10 Insight v1.0 Brant D. Thomsen 1 14 85 88 11 Blue Funk Steven Morrell 4 21 75 87 12 Blue Funk 3 Steven Morrell 6 25 69 87 13 Aeka T.Hsu 0 14 86 86 14 NC 94 Wayne Sheppard 0 34 66 66 15 Pyramid v2.0 Michael Constant 9 66 25 52 16 Keystone t33 P.Kline 0 84 16 16 Ryooki scored 28/22/50 when I first submitted it to koth, but since then her preferred targets, slow starting stones and vampires, have been knocked off the hill, so she is only hovering around 26/24/50 nowadays. Finally, below in all her glory is the version of Ryooki which is currently on the hill. Just for informational purposes, Ryooki is a female rabbit (who meows like cat) from the Japanese anime "Tenchi Muyo". T.Hsu ting@teloquent.com ------------------------------------------------------------------------------ ;redcode-94 ;name Ryooki ;kill Ryooki ;author T.Hsu ;strategy Just a simple paper ;assert CORESIZE == 8000 && MAXLENGTH >= 100 && VERSION >= 60 ;macro ;----------------------------------------------------------------------------- ; 1.0 Just an imp killing paper. ; 1.1 Use nop and jmz.f in the paper. ; 1.2 Use "mov 0,}0" instead of nop. Use "spl @nxt" instead of "spl nxt". ; 1.3 Larger due to anti-vampire code. Use labels instead of numbers. ; 1.4 Use "nop >0,0" instead of "mov 0,}0". org boot_paper nxt_paper equ -3365 boot_paper spl 1 ,0 spl 1 ,0 mov.i -1,#0 p_src nop >0 ,0 ; B-fld holds source p_cpy mov.i 800 ; A-fld holds destination mov.i p_bomb ,{p_dst ; anti-imp instruction mov.i p_bomb ,}25 ; anti-vamp instruction jmz.f *p_cpy ,*p_cpy p_bomb dat <2667 ,<2667*2 ; bomb designed to kill imps cnt for 90 dat 0,0 rof ______________________________________________________________________________ Looking to the Future: I hope you enjoy the new format of the Warrior, and that you find the next one to be worth the month-long wait. As always, your comments, suggestions, criticisms, and submissions are encouraged and appreciated. From: tuc@phantom.com (Scott J. Ellentuch) Subject: StormKing.Com temp problems Date: 25 Jul 1994 17:11:16 GMT Message-ID: <310rnk$pl1@dockmaster.phantom.com> Hello all, Since Noon Saturday, the IBM RS/6000 at Stormking.Com that runs the KOTH Hill failed. Currently the SCSI and 16 port terminal server have been identified as blown. The SCSI was replaced, and the hills look intact. The 16 port terminal server is on order and should be replaced by noon on Wed. At this time the hills should be back on line. Please bear with us, as this is the 2nd time in 3 weeks the system failed. HOWEVER, we are also working on some things that should TOTALLY ENTHRALL the r.g.c people. Scott tuc@stormking.com (PLEASE DON'T USE THE PHANTOM.COM ADDRESS) From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: Lost News Date: 26 Jul 1994 03:42:09 GMT Message-ID: <3120mh$b8k@magus.cs.utah.edu> Our newsreader has been out of commission the last few days. As a result, I am suspicious of how well distributed _The_'94_Warrior_ was when I published it a couple of days ago. If you didn't get a copy, send me e-mail and I will send it to you within a day or two (or simply re-post it.) Also, if you posted anything of importance to this newsgroup within the last few days, and think that material should be archived, please send me a copy of it. -- 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: mimel@irc.ircnw.com (OneEye) Subject: Sample programs Date: 28 Jul 1994 03:20:16 GMT Message-ID: <31785g$7lv@cleese.nas.com> Hello...I'm just starting to play corewars and I'm seeming to have a little bit of trouble. I've read the Tutorial.1 and 2 but I'm still not clear on somethings. Is there any other manuals, or sample programs that I could look at that are easy to understand? Perhaps some of the listings for the very first few sipmle corewar warriors. Thanks in advance... +----------------------------------+ | Michael McGuire | | Nick - OneEye | | [24755@ef.gc.maricopa.edu] | | [mimel@irc.ircnw.com] | | Phoenix, AZ | +----------------------------------+ From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 28 Jul 1994 04:57:33 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1994/07/09 Version: 2.3.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 116 a copy of the current instruction set? 5. What is ICWS'94? Which simulators support ICWS'94? 135 6. What is the ICWS? 152 7. What is TCWN? 162 8. How do I join? 170 9. Are back issues of TCWNs available? 187 10. What is the EBS? 194 11. Where are the Core War archives? 208 12. Where can I find a Core War system for . . . ? 226 13. I do not have ftp. How do I get all of this great stuff? 275 14. I do not have access to Usenet. How do I post and receive news? 285 15. When is the next tournament? 303 16. What is KotH? How do I enter? 314 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 483 18. How does SLT (Skip if Less Than) work? 495 19. What does (expression or term of your choice) mean? 507 20. Other questions? 650 --------------------------------------------------------------------- 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 two anthologies: 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 Author: Dewdney, A. K. Title: The Magic Machine: A Handbook of Computer Sorcery Published: New York: W. H. Freeman (c) 1990 ISBN: 0-7167-2125-2 (Hardcover), 0-7167-2144-9 (Paperback) Library of Congress Call Number: QA76.6 .D5173 1990 A.K. Dewdney's articles are still the most readable introduction to Core War, even though the Redcode dialect described in there is no longer current (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 practically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. Michael Constant (mconst@ soda.berkeley.edu) is reportedly working on a beginner's introduction. --------------------------------------------------------------------- Q 5: What is ICWS'94? Which simulators support 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 (see Q 5). ---------------------------------------------------------------------- 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. It is a good idea to check pub/corewar/incoming for program updates first. 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-21.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) pmars06s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars06s.tar.Z - same as above pmars06.zip - PC executables with graphics display, req 386+ macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincor11.zip - MS-Windows system, shareware ($15) ---------------------------------------------------------------------- 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. If you don't have access to the net at all, send me a 3.5 '' diskette in a self-addressed disk mailer with postage and I will mail it back with an image of the Core War archives in PC format. My address is at the end of this post. ---------------------------------------------------------------------- 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 a line starting with ";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. The server kills programs by assigning an impossibly low score; it may therefore take another successful challenge before a killed program is actually removed from the hill. 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.6, a platform-independent corewar system available at soda (see Q12). The '94 and '94x hills allow three experimental opcodes and addressing modes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) * - indirect using A-field as pointer { - predecrement indirect using A-field } - postincrement indirect using A-field ---------------------------------------------------------------------- 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, Two questions on addressing... 1. I don't understand whats going on when you address or add onto a data statment I see, (Sorry, this part of a document, and I lost the "front" of it and the (C) ) x-2 DAT #0, #0 ; Target instruction. x-1 DAT #0, #-1 ; Pointer instruction x MOV 0, @-1 ; Copies this instructino to location x-2 What am I moving? MOV 0, @-1 (-or-) 0 What is with this Dat instruction? DAT A,B How can you have two data fields? What is added to when you subtract or add. db --- * MegaMail 2.10 #1401:pcgfx!daniel.lo@netcom.com 7/26/19 11:50 From: mimel@irc.ircnw.com (OneEye) Subject: Ftp Site Date: 30 Jul 1994 21:52:45 GMT Message-ID: <31ei3d$qhe@cleese.nas.com> I've been trying for the past two days to get a hold of the ftp site - "ftp.csua.berkeley.edu" to get some Corewar related material. Unfortunately the site seems to be down or something. Does anyone know what is wrong with the site and when it will be working again? Also, is there another site I can use until then? Thanks in advance. +----------------------------------+ | Michael McGuire | | Nick - OneEye | | [24755@ef.gc.maricopa.edu] | | [mimel@irc.ircnw.com] | | Phoenix, AZ | +----------------------------------+ Date: Sun, 31 Jul 1994 20:53:36 MST From: Message-ID: <94212.205336AHNAS@ASUACAD.BITNET> Subject: post increment Do you guys like post-increment? The original argument was to create stack. Did anybody write a warrior using stack? I don't think a stack is very usefull. Post-increment also makes the the programmer's life harder and the system slower. I think it's less usable than pre-increment would be. Does anybody have a good argument for post-increment? Nandor.