From: hastings-matthew@CS.YALE.EDU (Matthew Hastings) Subject: Lots of redcode Message-ID: <1992Jul1.133434.6571@cs.yale.edu> Date: Wed, 1 Jul 1992 13:34:34 GMT I am including in this post the code to almost everything good I�ve written. That means:Proteus, HitBeast (not so good, but interesting), Smooth Noodle Map, Smooth Noodle Map4, Precipice (previously posted true), Trinity (2&3=1), Icewall (already posted and not so good), Falling Leaf 1.21, and Shears. First Proteus->Smooth Noodle Map->Smooth Noodle Map4 (actually I�ll give the mod�d present ver. w/ improved launch). Proteus (it CHANGES from a dwarf to a mouse) ptr dat #0 #0 mouse mov #12 ptr loop mov @ptr Date: 1 Jul 92 17:43:31 GMT hastings-matthew@CS.YALE.EDU (Matthew Hastings) writes: (...) : convert from this new trap to the old one). You do lose something though: : the core-clear is slower, but as a test I ran one program which jumped into : these two traps and the 2nd trap cleared more of core faster. So, against : RotLD type programs, it may be better. Not against other vampires because : if you hit their trap and they hit you, you want to clear as fast as possible : to get them before they hit your trap and get a tie. Also possible are When against other vampire, it's better to have a SLOW trap, since if both of you get captured, the one with the faster clear will be kill (since it is now living in the other program trap which will be killed by your fast trap). This assumes that you are not a self-splitter, of course. -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Kobold Message-ID: <1992Jul1.203517.10431@vuse.vanderbilt.edu> Date: Wed, 1 Jul 1992 20:35:17 GMT In case some of you may wonder (I know at least Eric Prestemon did :-)), this is the code for "Kobold", currently somewhere around #4 or 5. This is a dwarf that modifies *two* core addresses per 3-instruction loop by incrementing both bomb-source and -target, and is therefore as fast as a standard CMP-scanner. After the loop-counter expires, the program drops into core clear (necessary because a self-splitting opponent may not be dead yet). The constants were chosen for extremely dense bombing: 2400 loops with increment -37/offset 13,; "Kobold" then modifies itself and continues for the remaining 1031 loops with erratic bombing. A version of "Kobold" that ends the bomb loop with "DJN -2,<3429" instead of the loop-counter proved to be unstable and scored 10 pts less than the original. Enjoy, Stefan (stst@vuse.vanderbilt.edu) ;redcode ;name Kobold ;kill Kobold ;author Stefan Strack ;strategy Fast dwarf: bombs with DAT 0 and decrements, finally clears core ;strategy (optimized version of Scanners' Nightmare) ;strategy Submitted: @date@ COUNT equ 431 ;may be smaller without penalty FIRST equ 5+(37*COUNT) move mov Date: Wed, 1 Jul 1992 22:54:58 GMT That's funny... My dumb bomb which modify 3 locations / 4 instructions and then clears core didn't make it on the hill.... Guess I'm bad at timing and constants... It was confetti: ;redcode ;name Confetti ;author Pierre Baillargeon ;strategy v0.99: Leave stuff everywhere. ;kill Confetti dist equ -47 top add #dist, kill mov step, Date: Thu, 2 Jul 92 04:28:27 GMT I did a little testing on backfire regarding messing up memory to make other scanners work harder, but the tradeoff cost too much. The difference is down at LOOP, with the JMZ SPLAT,WHERE. In other words, if something has a 0-B field, rather than skipping it, we bomb it anyway. Of course, since this is done before we see if we shoot ourselves, I had to add a 1 bfield to two jumps, all the other b-fields were already "safe". Whereas earlier BackFire programs were scoring 125-135, 1.70 only scored 107, I assume because reducing the bombing rate to 2/3 of the old rate was too much. Also note I'm bombing with DAT #4567,#0, so that we leave a 0 B-field so we don't confuse ourselves. The camoflage (deleted) has a similar form, so that we aren't confusing ourselves. I've tried several different forms of camoflage, and using a non-0 B-field hurts Backfire more than it hurts the other programs (especially the blind ones :-) so it isn't quite true that your camoflage should always end with a 1 b-field. I didn't notice a statistically significant difference between 1.61 and 1.70, but the difference is copying away from the camoflage by 4000 cells, so anyone scanning by mirroring will not find 1.70. One final note: Backfire and Ike are not doing the same thing (I've noticed people tend to group them together). Backfire bombs @-location, Ike bombs @location. The difference being, Ike will find a relocator, especially if you use several MOV label,2345 statements to copy the code rather than using Date: Thu, 2 Jul 92 05:01:33 GMT Blame my roommate for the name on this one :-) As the strategy lines indicate, this is what happened when I modified StealthHunter using the information from J. Cisek's scanning article. Dominatrix is a scanning slaver that drops JMP PIT bombs, and the pit being a core clear routine that eventually kills itself. BTW, just in case anyone is wondering, the current hill is more than likely a bit tougher than the '90 ICWS tournament. Paper '90 went 10/85/5 vs Dominatrix, so I thought I had a hit, since few of my programs do well against Paper. Note Paper, on the other hand, went 42/43/15, definitely a tougher opponent. Anyone interested in submitting the '90 ICWS winners to the current hill to see how they do? ;redcode ;name Dominatrix 1.04 ;author Eric J. Schwertfeger ;strategy Scanner/Slaver ;strategy The result of StealthHunter and ;strategy J. Cisek's scanning article ;strategy Faster Scanning, slower bombing ;strategy need better constants :-( ;strategy Submitted: @date@ ;kill Probe SPLIT EQU (191-STEP) START EQU (100) STEP EQU (411) BLANK EQU (LOOP-2) LOOP ADD INC,WHERE WHERE CMP START,START+SPLIT SLT #TAIL+1,WHERE JMP LOOP MOV JMPBOMB,BOMB SUB WHERE,BOMB SLT #-6,WHERE MOV BOMB,@WHERE SUB ALIGN,WHERE JMP WHERE ALIGN DAT #SPLIT,#SPLIT INC DAT #STEP,#STEP JMPBOMB JMP (PIT-WHERE-SPLIT),4000 BOMB DAT #0,#0 PLOOP MOV TAIL+1, Date: Thu, 2 Jul 1992 05:38:34 GMT wow.... mabye this is another case of crimp/charon but here is my warrior.. tiny v.52 ;redcode verbose ;name Tiny v.52 ;author Paul S. Kilroy ;strategy I dont know how original this is... but it is basically stone ;strategy with coreclear. ;strategy v.52 - Different system.. inc add off, move move mov <4000+1, -184+1+4 djn inc, #2000 off mov -184, <-184 jmp -1, <-10 <- i cant remember why i put this line here.. i think it might of been to stop imps.. but im not sure.... -- -Paul (kilroy@mik.uky.edu) Date: Thursday, 2 Jul 1992 09:34:58 MST From: Message-ID: <92184.093458AZNXS@ASUACAD.BITNET> Subject: tezst ;Here is tezst my favorite unsuccessfull warrior. It hits itself twice ;( first at dest, second at dest-1 ). It bombs half of the core with ;jmp -2 then goes to the clear routine and bombs everything with dat. ;I don't know why it is so unsuccessfull, maybe because of the jmp -2 bombs. ;redcode ;Name tezst ;Author nandor sieben clear mov -4 , <0 start add #3044 , dest mov dest , @dest ;second hit dest jmp start , Date: Thu, 2 Jul 1992 14:12:40 GMT For the past three months I habevn't been able to do much work on CW, but an idea came to mind -- write a program that works like Zip -- pick the best attack once you determine what you are up against. How tough would it be to check to see if the bomb you scan can be properly killed, say, by Backfire or by Ike, then have your program jump to either of those bombing routines as a subroutine. Maybe too complex for a 100-instruction limit, but an idea. I tried another idea -- using the scan loop from XTC and putting a 'burp' (previously posted - small dwarf-life routine) as a 'warhead'. Since I am having troubles getting KotH working on my machine, I haven't been able to play as much lately. :-( Jack. -- John M. Twilley | A decapitated cockroach lives for several nautilus@acm.rpi.edu | weeks before finally dying of starvation. From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: BackFire Update (it isn't doing so well :-) Message-ID: <1992Jul2.152202.14717@oucsace.cs.ohiou.edu> Date: 2 Jul 92 15:22:02 GMT In article nautilus@lachesis.acm.rpi.edu (John M. Twilley) writes: > >For the past three months I habevn't been able to do much work on CW, but >an idea came to mind -- write a program that works like Zip -- pick the >best attack once you determine what you are up against. How tough would >it be to check to see if the bomb you scan can be properly killed, say, >by Backfire or by Ike, then have your program jump to either of those bombing >routines as a subroutine. Maybe too complex for a 100-instruction limit, >but an idea. It isn't a bad idea, but I was tinkering with this myself when I had the Virus series (Virus and Bacteria) going. I finally decided to run them without finding out what type of enemy it was against for the reason of time. Once a program detects a certain type of enemy, it is too late to start that type of bombing since the enemy has already got a head start on you. Once you figure out how to get around this little problem, you will have a very nice program indeed. Oh, one other problem... for each of the different types of programs you detect, you will probably become even more vulnerable to the ones you do not detect. It is also not as easy to detect what kind of program you are fighting against... at least while given the current limitations of the core war rules... Don't forget to have a good day! Some people never remember this. ------------------------------------------------------------------------------- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu (Flame me, not the net!) Bitnet: adkins@ouaccvma.bitnet ------------------------------------------------------------------------------- Ohio University of Athens Home of the Great Hocking River From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Answers to Frequently Asked Questions (FAQ) for rec.games.corewar Message-ID: <1992Jul6.035323.16346@vuse.vanderbilt.edu> Date: Mon, 6 Jul 1992 03:53:23 GMT [posted biweekly and mailed on request, -Stefan (stst@vuse.vanderbilt.edu)] Last Update: May 8, 1992 TABLE OF CONTENTS ----------------- 1. What is Core War? 2. Is it Core War or Core Wars? 3. Where can I find more information about Core War? 4. What is the ICWS? 5. What is TCWN? 6. How do I join? 7. Are back issues of TCWNs available? 8. What is the EBS? 9. Where are the Core War archives? 10. Where can I find a Core War system for . . . ? 11. When is the next tournament? 12. What is KOTH? How do I enter? 13. Other questions? --------------------------------------------------------------------- Q1: What is Core War? A1: 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 possesion 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. ---------------------------------------------------------------------- Q2: Is it "Core War" or "Core Wars"? A2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. "Core War" is preferred in reference to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q3: Where can I find more information about Core War? A3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 Library of Congress Call Number: QA76.6 .D517 1988 --------------------------------------------------------------------- Q4: What is the ICWS? A4: 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). --------------------------------------------------------------------- Q5: What is TCWN? A5: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and is also made available through this newsgroup. --------------------------------------------------------------------- Q6: How do I join? A6: For more information about joining the ICWS and/or subscribing to TCWN, contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 EMail: jonn@microsoft.com The ICWS and TCWN have finally been transferred. You should be seeing much more from each now. ---------------------------------------------------------------------- Q7: Are back issues of TCWN available? A7: Back issues of the TCWN (up to Winter 1991) are available from AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 Prices are unknown at this time, but should be around $5.00 (the original cover price). --------------------------------------------------------------------- Q8: What is the EBS? A8: 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 will be entered into the annual ICWS tournament. Now that rec.games.corewar has been created, the EBS has moved its business to the newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994. Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- A9: Where is the Core War archive? Q9: 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.131.179) in the /pub/corewar directories. 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. ---------------------------------------------------------------------- Q10: Where can I find a Core War system for . . . ? A10: First, check out the Core War systems available via anonymous ftp from soda.berkeley.edu. Currently, there are X-Window, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. Others may appear. The following suppliers have ICWS'88 compatible systems for IBM PC compatibles: The Core War Colosseum AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 Price: $39.95 CoreMaster(TM) THINK Software 524 Paige Drive Birmingham, AL 35226 (205)979-9475 Price: $34.95 + $3.00 S&H Apple Macintosh computers: Core! Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 EMail: jonn@microsoft.com (Note: Core! is NOT a Microsoft product.) Price: $14.00 registration fee, plus $3.00 S&H. S&H fee waived if you send 800k disk and stamped, self-addressed envelope. Also available from sumex-aim.stanford.edu and listserv@ricevm1.rice.edu and soda.berkeley.edu. Commodore Amiga computers: The MADgic Core Mark A. Durham P.O. Box 301173 Houston, TX 77230-1173 Version 4.1 of The MADgic Core is available from soda.berkeley.edu. CoreWars (German language version) UNICORN systems Bernstrasse 67 CH-4852 Rothrist Switzerland Price: sFr 45.-- Commodore 64/128 computers: Barry Cohen 65 West 90th Street, #23E New York, NY 10024 Price: Not Available Please post information about any systems not listed here. Information about the systems (base system, ICWS standards compatibility, extensions, price, etc.) will be included next month's FAQs. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Please post any review of any Core War system you have tried out so that others may learn from your experience. ---------------------------------------------------------------------- Q11: When is the next tournament? A11: The EBS is in the middle of a tournament right now. There will be another starting in the Fall. Otherwise, keep looking to r.g.cw for upcoming tournament announcements. ---------------------------------------------------------------------- Q12: What is KOTH? How do I enter? A12: King Of The Hill (KOTH) is an ongoing Core War tournament available to anyone with EMail provided by William Shubert . 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". If your program finished in the top twenty, it will remain on the hill until such time as it finishes twenty-first against another challenger, at which time it "falls off" the hill. Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail demon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program compiled correctly or not. If it did compile correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives in an hour, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "Foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. MORE ON KOTH COREWAR IMPLEMENTATION Core size: 8,000 instructions Max processes: 8,000 per program Duration: After 80,000 cycles per program a tie is declared. Max entry length: 100 instructions Battles played: Your warrior will play each opponent fifty times. Scoring: 2 points for each win, 1 point for each tie, no points for each loss. Programs are guaranteed a 100 instruction block (inclusive of their warrior's instructions) without overlapping their opponent. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb dat #0 dwarf add #4,bomb mov bomb,@bomb jmp dwarf end dwarf Rule variants for "eXperimental" corewar: The same as above but use ";redcode-x" to start your program. Your program will be entered into a second tournament with slightly different rules. The rules are: - All addressing modes are allowed with all instructions. - There is an additional addressing mode, called "postincrement". To use it try an instruction like "mov >5,6". - The maximum write distance is 250 instructions. That is, every time your program tries to modify memory, the address is checked; if it is more than 250 instructions from the process doing the modify, then memory is left unchanged, but the instruction continues as normal. KotH runs on any Unix system with an X windows interface. The source code to KotH is available by EMail from William Shubert. Write to him at for a copy. ---------------------------------------------------------------------- Q13: Other questions? A13: Just ask. Someone in the newsgroup will be able to answer your question. From: wms@iwarp.intel.com (William Shubert) Subject: KotH standings Message-ID: <1992Jul6.215916.27167@iWarp.intel.com> Date: Mon, 6 Jul 1992 21:59:16 GMT Here's the current ICWS '88 standings: # %W/ %L/ %T Name Author Score Age 1 45/ 25/ 30 Flash Paper3.7 Matt Hastings 164 14 2 49/ 41/ 10 test acht Stefan Strack 158 12 3 47/ 38/ 15 Smooth Noodle Map Matt Hastings 157 220 4 48/ 42/ 10 Crimp 2 Andy Pierce 153 286 5 48/ 42/ 10 Charon v6.0a J.Cisek & S.Strack 153 292 6 42/ 31/ 28 Note Paper Scott Nelson 152 613 7 46/ 44/ 10 Agony 2.4b Stefan Strack 149 23 8 45/ 43/ 11 Sucker 4 Stefan Strack 148 215 9 45/ 44/ 11 Gibraltar Eric Prestemon 146 6 10 43/ 42/ 14 Trinity Matt Hastings 145 219 11 44/ 44/ 11 izotrop nandor sieben 145 363 12 42/ 39/ 20 Warm Body 0.20 Eric J. Schwertfeger 144 59 13 43/ 43/ 14 PitTrap v4.0 J.Cisek 144 119 14 42/ 40/ 19 RotLD 2 nandor sieben 143 97 15 45/ 47/ 8 RoadRunner I S. Halvorsen 143 193 16 47/ 51/ 2 Kobold Stefan Strack 143 74 17 43/ 45/ 12 Falling Leaf 1.21 Matt Hastings 141 100 18 43/ 45/ 12 Precipice Matt Hastings 141 347 19 40/ 40/ 20 Spider (he is our hero) J.Cisek 139 327 20 43/ 53/ 4 Miny v.1 Paul S. Kilroy 132 1 And on the x-hill: # %W/ %L/ %T Name Author Score Age 1 61/ 25/ 14 Spider 2.0 Bill Shubert 197 26 2 47/ 33/ 20 bfx-preliminary+clearer Eric Prestemon 161 7 3 48/ 37/ 15 Snark 10 Scott Nelson 160 62 4 46/ 40/ 14 Odin J.Cisek 152 78 5 31/ 12/ 58 Brute-Force 1.2 Ray Cromwell 150 24 6 42/ 38/ 20 ImpDwarf Gun 1.0 Warren vonRoeschlaub 145 5 7 35/ 24/ 41 MiniShwing! [x] v1.2 T. H. Davies 145 73 8 45/ 46/ 9 Juggernaut 6.0 Scott Nelson 144 52 9 31/ 24/ 46 Splitting Nightmare D Stig Hemmer 138 3 10 40/ 45/ 15 Leaper-X 4.0 Jeff Raven 136 75 11 35/ 40/ 25 Crimson v2.1 J.Cisek 131 58 12 39/ 50/ 10 Viper J.Cisek 128 60 13 35/ 45/ 20 jumping bean 2.0 Eric Prestemon 126 44 14 28/ 32/ 40 Bookworm J.Cisek 123 33 15 28/ 34/ 38 Bridge Scott Adkins 122 86 16 37/ 52/ 11 tse-tse-x Eric Prestemon 121 32 17 21/ 24/ 55 Absolute 222 James Jesensky 118 57 18 24/ 31/ 45 Rabbits [x] Paul S. Kilroy 117 70 19 24/ 33/ 44 multi mice -x nandor sieben 115 87 20 22/ 31/ 47 Scud Kurt vonRoeschlaub 113 1 Sorry, I've been real busy, no time for a summary. -Bill (wms@iwarp.intel.com) From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: ICWS and my address Message-ID: <1681D5F2D.DURHAM@ricevm1.rice.edu> Date: Tue, 7 Jul 1992 11:46:05 GMT First, the ICWS is doing OK financially since the change in Directorship and the mailing of the Spring 1992 issue of "The Core War Newsletter". We have been unable to contact many previous members whose addresses have changed so long ago that their mail is no longer being forwarded. If you are a member of the ICWS and did not receive your Spring 1992 issue of TCWN, then contact Jon Newman and let him know. We can still use as many new members as we can get. Also, I need new articles for upcoming TCWNs. Second, I am still looking for a new Email address. The post office changed my zip code as of July 1, 1992, so here is my newest address and phone number. Hopefully, these won't change for many years to come. Mark A. Durham 18 Honeysuckle Terrace Spartanburg, SC 29307 (803)579-0431 Mark A. Durham MAD From: jonn@microsoft.com (Jon Newman) Subject: Announcing the International Core War Society! Message-ID: <1992Jul07.212413.2046@microsoft.com> Date: 07 Jul 92 21:24:13 GMT Announcing the International Core War Society! Core War is a "programmer's game," where human competitors write programs which compete against one another in a simulated computer. These programs are similar in a way to the "icebreakers" of science fiction writer William Gibson's milieu. Core War was first popularized by A.K. Dewdney's "Computer Recreations" articles in Scientific American starting in 1984, although it had existed in different forms since the 1970s. Core War simulators exist for virtually every computing platform, and hundreds of human competitors have submitted Core War fighter programs to the annual Core War tournaments held since 1986. The International Core War Society, or ICWS, has served the community of Core War programmers since 1986. Today, as the new Director of the ICWS, I invite you to become a member. The primary activities of the ICWS are: -- Publication of a quarterly newsletter, The Core War Newsletter (or TCWN); -- An annual tournament (around December), featuring the best fighter programs from around the world; -- The development of a new Core War Standard (the current standard was instituted in 1988); and -- The promotion of Core War for research and recreational purposes, both in the United States and at several ICWS Branch Sections in other countries and on the international computer network. Membership in the ICWS will entitle you to: -- Four issues of our quarterly Newsletter; -- One entry in the annual tournament; and -- One copy of ICWS '88, the standard for the language in which Core War fighter programs are written. (This is available seperately for US$4.) Membership currently costs US$15 per year. Overseas members are welcome at the same rate, but checks must be drawn on US branches of US banks. Postal money orders (from nations where the US Post Office honors same) and cash will also be accepted. Make checks out to "Jon Newman" (not to the ICWS until further financial arrangements are complete) and send them to: Jon Newman Director, ICWS 13824 NE 87th Street Redmond, WA 98052-1959 USA Free or reduced-rate memberships are available to members in less- developed nations; ask for details. The ICWS has several international Branch Sections. Members of the Branch Sections need not pay dues to the ICWS, but do not receive membership benefits such as The Core War Newsletter or the Core War standard. Some Branch Sections hold their own tournaments, the winners of which are entered in the ICWS tournament. Of special interest is the Electronic Branch Section (or EBS), open to anyone with access to electronic mail. Most EBS business is done on the newsgroup rec.games.corewar. EBS members (anyone on "the net") can get access to electronic copies of the Newsletter and other ICWS documents, plus a special ongoing contest accessible only via electronic mail. Please refrain from sending "so what is this anyway" postings to rec.games.corewar; instead, look back through your bulletin board archive for a FAQ (or Frequently Asked Questions) posting, which should answer almost any questions you might have about rec.games.corewar and the EBS. The best way to contact me is via electronic mail, at JONN@MICROSOFT.COM. (Microsoft sometimes has mailer trouble; if your electronic mail is not answered within two weeks, please resubmit your mail.) Questions can also be sent to the above postal address. If you can send a stamped self-addressed envelope with postal mail, this will help me answer as soon as possible. Please remember that the Director of the ICWS gets quite a lot of mail; this little courtesy will be very helpful. Finally, please note that the Microsoft has no connection with the ICWS. In fact, they don't know about any of this, and they probably wouldn't approve. Microsoft takes no responsibility or liability for any activities of the ICWS. (Microsoft treats me well, I try not to get it in trouble.) Yours, Jon Newman Appendix: Core War simulators (list provided by Mark Durham) The International Core War Society does not sell Core War simulators, and cannot provide any such program. The ICWS is working on a system for validating that these simulators conform to the current standard, but at present we cannot guarantee that they conform. The following suppliers have ICWS'88 compatible systems for IBM PC compatibles: The Core War Colosseum AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 Price: $39.95 CoreMaster(TM) THINK Software 524 Paige Drive Birmingham, AL 35226 (205)979-9475 Price: $34.95 + $3.00 S&H Apple Macintosh computers: Core! Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 EMail: jonn@microsoft.com (Note: Core! is NOT a Microsoft product.) Price: $14.00 registration fee, plus $3.00 S&H. S&H fee waived if you send an 800k disk and a stamped, self-addressed envelope. Also available from sumex-aim.stanford.edu and listserv@ricevm1.rice.edu and soda.berkeley.edu. Commodore Amiga computers: The MADgic Core Mark A. Durham P.O. Box 301173 Houston, TX 77230-1173 EMail: durham@ricevm1.rice.edu A version of The MADgic Core is available from soda.berkeley.edu. CoreWars (German language version) UNICORN systems Bernstrasse 67 CH-4852 Rothrist Switzerland Price: sFr 45.-- Commodore 64/128 computers: Barry Cohen 65 West 90th Street, #23E New York, NY 10024 Price: Not Available My apologies to those of you who have Core War systems which are not listed here or are incorrectly listed here. Please send me information about the systems (base system, ICWS standards compatibility, extensions, price, etc.) and I will be sure to include it in next month's MAD FAQs. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available from various sources. Programs written for these simulators may not work properly in ICWS '88-compatible simulators or in the ICWS- sanctioned tournaments. -- jonn@microsoft.com This is not the official opinion of Microsoft Corporation. Bill Rules! From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Announcing the International Core War Society! Message-ID: <1992Jul8.194112.28604@vuse.vanderbilt.edu> Date: Wed, 8 Jul 1992 19:41:12 GMT In article <1992Jul07.212413.2046@microsoft.com> jonn@microsoft.com (Jon Newman) writes: >Membership in the ICWS will entitle you to: >-- Four issues of our quarterly Newsletter; >-- One entry in the annual tournament; and >-- One copy of ICWS '88, the standard for the language in which >Core War fighter programs are written. (This is available >seperately for US$4.) Plus you get to vote on new standards (which alone might be worth the $15 membership fee :-)). -Stefan (stst@vuse.vanderbilt.edu) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Charon v7.0 Message-ID: <1992Jul8.235307.14001@vuse.vanderbilt.edu> Date: Wed, 8 Jul 1992 23:53:07 GMT Below the most recent version of Charon (v7.0), a SPL/JMP (ahem, SPL/JMZ) bombing CMP scanner. In the tradition of "small is beautiful", Charon v7.0 is now 11 instructions long and is therefore the smallest CMP scanner currently on the hill. The key is the jmz @-1,0 instruction which doubles as the return of the bombing code and the second bomb instruction. Whereas other CMP scanners (Charon v6.0, Crimp 2, Agony 2.4b, izotrop (?)) drop into core clear mode when a JMN comp,scan signals self-bombing, Charon v7.0 triggers when the core decrementing train catches up from behind. This may sound dangerous, but works quite well if the constants are chosen carefully. This modification also makes the program more robust to being caught by the opponent's DJN train: instead of idling, Charon v7.0 falls prematurely into clear. Enjoy, Stefan (stst@vuse.vanderbilt.edu) ;redcode ;name Charon v7.0 ;author J.Cisek & S.Strack STEP equ 68 ;scan constants: DIST equ 34 ;small, so can be reused in core clear FIRST equ comp-(STEP*93) ;determines duration of scan scan add incr,comp comp cmp FIRST-DIST,FIRST slt #incr-comp+DIST+1,comp ;don't hit self (and in shadow) djn scan, Date: Thu, 9 Jul 1992 00:50:51 GMT While I am at posting code, here's Agony 2.4b. I posted version 2.1, the first really successful Agony, a couple of months ago, but I thought I'd keep you up to date. Agony is a CMP scanner that bombs with a train of SPLits a la XTC (to which the name is an allusion). It appears to have been the first instance of the compact scan-loop (integrating SLT) and the self-bombing-triggers-core-clear trick; that's why Agony is one of my old favorites. 2.4b improves upon previous versions by including core mutagenizing (borrowed from Andy's Crimp) and by shrinking the CMP-distance down to 12. This smaller number cuts down the cycles wasted on bombing decoys (28), although this still compares unfavorably to the 4 cycles that SPL/JMP bombing takes. Enjoy, Stefan (stst@vuse.vanderbilt.edu) ;redcode ;name Agony 2.4b ;kill Agony ;author Stefan Strack ;strategy Small-interval CMP scanner that bombs with a SPL 0 carpet. ;strategy 2.0: smaller ;strategy 2.1: larger, but should tie less; changed scan constants ;strategy 2.2a: smaller ;strategy 2.3a: mutagenizes core ;strategy 2.4: smaller CMP interval, spends less time bombing ;strategy 2.4b: mutagenize constant optimized ;strategy Submitted: @date@ CDIST equ 12 IVAL equ 28 FIRST equ scan-OFFSET+IVAL OFFSET equ 5324 scan sub incr,comp comp cmp FIRST-CDIST,FIRST slt #incr-comp+CDIST+(bptr-comp)+1,comp djn scan, Date: Thu, 9 Jul 1992 22:51:27 GMT Here is B-scanners live in vain, perhaps the most succesful B-scanner recently written. It entered at no.4, really surprising me. This, though is probably due to the presence of 2( or more?) replicators on the hill to help it's score. It has dropped quite a bit to 10 or so. The nice part is that it is functionally equivalent to Scissors from the 90 contest but 6 lines shorter and mod 2 instread of mod 4. The trick that enables this is the indirect off of the bombed location. See the 4th line of code. Except for Agony and maybe one or two others this is the best replicator killer I've seen (yes, it beat Flash Paper3.7 worse than Crimp, Charon v7.0 or any of the others.) start add #1226,3 jmz -1,@2 mov grave,@1 mov prog,<0 jmn -4,-4 prog spl 0,0 mov @10,<-1 grave jmp -1,0 end start From: maniac@cleanhead.cs.unlv.edu (Eric J. Schwertfeger) Subject: Retreat 1.00 (X-Hill warrior) Message-ID: <1992Jul9.235210.7412@unlv.edu> Date: Thu, 9 Jul 92 23:52:10 GMT This was a really interesting idea, my first idea for an X-hill warrior that was novel, but it didn't do well, and I'll be out of town for three weeks, so I'm posting the code in hopes that someone makes a decent X-warrior out of it while I'm gone. The basic idea was to set up two processes, one that was an X-Hill optimized dwarf (three lines, bombs every 4'th, bombs only within 250 spaces). The second was the monitor. when the first was killed, the monitor would start another monitor and become an X-dwarf. The problems it has are simple. It works OK if attacked from the direction of the X-Dwarf, but if attacked from the direction of the monitor, the monitor dies, leaving the X-Dwarf alone, and with a decent chance of getting killed. Like I said, and interesting but unsuccessful idea, Especially against splitting nightmare, which would run the "Kill the damaged X-Dwarf" routine I put in to reduce suseptibility to SPL/JMP bombing. ;redcode-x ;name Retreat 1.00R ;author Eric J. Schwertfeger ;strategy Same as v 1.00F, but runs in reverse. Does better ;strategy against spider, we'll see about how it does against ;strategy the rest. BOMB EQU (DWARFX-217) LEAP EQU (-250+(SRC-COPY)) START MOV #0, SRC ;Initialize Copy variables. MOV #(LEAP-1), DEST MOV #10, COUNT COPY MOV Date: 10 Jul 92 11:10:30 GMT An idea for extending the spl instruction. spl A, B Now the B specifies a life time of the new process. This could be in cycles or instruction executions. After the "time" has passed, the process dies. There are important details like "can a process have a longer life than its parent?" If B=0 then there is no life limit. Campbell P.S. Its good to be back on the hill after a painfull absence. -- Hi, I'm a .signature virus. Copy me to yours and then wipe all your files. Campbell Fraser: fraserc@dcs.glasgow.ac.uk Computing Science Department, University of Glasgow, Glasgow G12 8QQ From: hastings-matthew@CS.YALE.EDU (Matthew Hastings) Subject: Core Wars Philosophy Message-ID: <1992Jul11.014539.1570@cs.yale.edu> Date: Sat, 11 Jul 1992 01:45:39 GMT The philosophy of corewars. Well, a frequent complaint by many people is that there are classes of programs that kill other classes in a non-transitive fashion. Scissors beats Paper beats Stone beats Scissors. The two most obvious responses to this are:yes, but programs get better and better in each class. For example, Note and Flash Paper both beat Scissors (I think). The second response is that on the present hill, there are many programs that blend two type. Good examples are Smooth Noodle Map (incorporates a replicator into a Stone), Precipice (slaver running a side core-clear process so it can do well against Stones), Dynamic Duo (most slavers are one process, this is multi-process) and many others (I gave mostly my own programs because I understand how they work better than I do others and because I write lots of these hybrid porgrams). However, I want to suggest a different view of the situation. Let's say two people are fighting ech other in a duel of corewar programs. After much effort, each invents very good programs, which happen to fall neatly into the three basic classes. Then they both enter a program into the core and see how they score. The correct way to analyze the situation is by means of game theory:construct a payoff matrix, detailing results against each of the other guys three programs and construct an optimal mixed strategy. This would be a randomized strategy with given probabilities for submitting each program. At this equilibrium, when each is using a mixed strategy, it will be the case that neither player can improve his socre by changing strategy (this all applies to the case in which the players fight a zero sum version of corewar, I think it all still applies when not zero sum (win+lose does not equal tie+tie, but I haven't read too much about game theory, just Prisoners Dilemna, a good book). The Hill is a simialr environment. Here though, what should happen is that the hill converges to an optimized mixed strategy (to within 5% since only 20 programs fit on the hill). Whenver more programs of a given type appear on the Hill then there should be, the opponent (those guys submitting programs) adjusts his strategy and wipes out a few of those extra programs. So, in a theoretical sense you COULD solve corewar:just construct the payoff matrix corresponding to every possible program and compute best strategy. This line of thought also applies to questions like optimizing programs to beat certain others. Let's say we have 3 types of programs:B-scanners, program w/ all zero B-fields and replicators (leave all the others out). Next let's say that replicaotrs kill the all zero B-field program 100-0. The B-scanner kills replicators about 60-40. The all B-fileds program goes 70-30 against the B-scanners. Then if there are a lot of replicators B-scanners appear. The B-scanners let all zero B-field program appear, not many but some. In the end, on an infinite hill, with correct ratio of programs, all should wind up iwth the same score! So there is justification for such programs Further, I don't see any harm with classes of programs that have cycles of who beats whom. Finally, this does suggest that a programs performance may be for the moment determined by the lack of optimal mix on the hill, but over time things converge. To give a simple practical example, when I submitted scrap paper, it was abt. 16th but pulled Note Paper down too. Flash Paper 3.7 also pushed Note Paper down. Well, hope this doesn't sound too much like a preprint of an article to be published in Journal o f Mathematical Redcode (J. Mat. Red.) :-) From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: process life Message-ID: <1992Jul11.015326.8262@vlsi.polymtl.ca> Date: Sat, 11 Jul 1992 01:53:26 GMT fraserc@dcs.glasgow.ac.uk (Campbell Fraserc) writes: : An idea for extending the spl instruction. Another idea on the spl instruction would be to make the two processes generated have the same amount of processing time and that a process CAN'T loose time-slice allocation from 'friend' processes spliting. What all this means is a tree like process generation scheme instead of a linear list of process. ie: if you have two processes and one split up, then one run half the time, the other two one fourth. My goal in suggesting this is balance. I believe that a good core war design should try to have a counter action to every possible attack, a good program being one able to mix everything effectivly. Rigth now, there's almost no protection against spl/jmp. That combination would still be effective, but not as totally destructive as it is right now. -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Redcode source (Note Paper) Message-ID: <61920@cup.portal.com> Date: Sat, 11 Jul 92 12:23:24 PDT Here by popular demand, the source to Note Paper. With an age of over 500, It has been in almost every position on the hill. Since it only takes 3 words to make a copy and split to it, Note Paper can often continue to replicate even after being 'trapped.' ;redcode quiet ;name Note Paper ;author Scott Nelson ;strategy Small version of Plain Paper. ;strategy smaller. start spl p2 ;decrease chance of lucky hit by dwarf. spl 1 spl 1 spl 1 ;start 8 processes going spl paper2 spl paper3 spl paper4 spl paper5 ; mov #8, 0 ;set source paper1 mov <-1, <1 ;make copy spl @0, 6301 ;split to copy mov 2, <-1 ;make next copy a little further away jmz -4, -4 ;loop dat #-100 dat #8 dat #8 dat #8 mov #8, 8 paper2 mov <-1, <1 spl @0, 6501 mov 2, <-1 jmz -4, -4 dat #-100 dat #8 dat #8 dat #8 mov #8, 8 paper3 mov <-1, <1 spl @0, 6701 mov 2, <-1 jmz -4, -4 dat #300 dat #8 dat #8 dat #8 mov #8, 8 paper4 mov <-1, <1 spl @0, 6901 mov 2, <-1 jmz -4, -4 dat #-100 dat #8 dat #8 dat #8 mov #8, 8 paper5 mov <-1, <1 spl @0, 5901 mov 2, <-1 jmz -4, -4 dat #-100 dat #8 dat #8 dat #8 mov #8, 8 paper6 mov <-1, <1 spl @0, 5701 mov 2, <-1 jmz -4, -4 dat #-100 dat #8 dat #8 dat #8 mov #8, 8 paper7 mov <-1, <1 spl @0, 5501 mov 2, <-1 jmz -4, -4 dat #-100 dat #8 dat #8 dat #8 mov #8, 8 paper8 mov <-1, <1 spl @0, 5301 mov 2, <-1 jmz -4, -4 dat #-100 dat #8 dat #8 dat #8 mov #8, 8 paper9 mov <-1, <1 spl @0, 5201 mov 2, <-1 jmz -4, -4 dat #-100 ; p2 spl 1 spl 1 spl 1 spl paper6 spl paper7 spl paper8 spl paper9 paper10 mov #8, 0 mov <-1, <1 spl @0, 7001 mov 2, <-1 jmz -4, -4 end start |+-------------------------------------------------------------------------+| If the probability of E-coli mutating into leprosy were 1 in 100,000,000,000 there would be more than 10 new cases every day. <<>> From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: Core Wars Philosophy Message-ID: <61922@cup.portal.com> Date: Sat, 11 Jul 92 13:29:53 PDT >7/10/92 18:45 49/3631 hastings-matthew@CS.YALE.EDU (Matthew Hastings) >The philosophy of corewars. Because of the size of Matthew's post I will include only a summary. > [Many people complain about the Non-transitive nature of corewar.] > [there are two obvious responces] > [1.) yes, but programs get better] > For example, Note and Flash Paper both beat Scissors (I think). actually "Note Paper" wins only 30% of the time, but 30% IS better than the 12% of the time "Paper" wins. > [2.) Many programs aren't in easy to split categories (example: hybrids)] > However, I want to suggest a different view of the situation. > [description of how hill would respond if programs were only of the paper, > scissors, stone variety] > Further, I don't see any harm with classes of programs that have cycles > of who beats whom. > [over time, the hill will become 'smooth'] --- Well, I agree with virtually everything you've said. I must point out however, that for any program there exists an anti-program (one which beats that program over 60% of the time), for any strategy there exists an anti-strategy, (one which beats that strategy over 60% of the time), and most important, for any set of strategies, there exists an anti-program (one which beats that set of strategies over 60% of the time). There is also a second problem with KOTH, since it is NOT infinite, it is possible to manipulate it. Rather than writing a better warrior, I can submit warriors which cause my other warriors to rise on the Hill. This is the Meta-game problem. Taken to its logical extreme, I could 'wipe' the hill (by submitting programs tailored to kill those on it) and end up with 20 warriors which did nothing but JMP 0. (even though the hill has gotten MUCH tougher than when I started submitting programs to it, I still believe that this is possible.) A good solution to this problem would be to limit the number of entries by one contestant. For KOTH, I would suggest a limit of 3. |+-------------------------------------------------------------+| My dog's better than your dog, my dog's better than yours, My dog's better than your dog, my dog's better than yours. - B. Bush. <<>> From: kilroy@mik.uky.edu (Paul S. Kilroy) Subject: Re: process life Message-ID: Date: Sat, 11 Jul 1992 15:49:05 GMT In <1992Jul11.015326.8262@vlsi.polymtl.ca> dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) writes: |Rigth now, |there's almost no protection against spl/jmp. That combination would still |be effective, but not as totally destructive as it is right now. |-- |"Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B |"This is a mad house !" - Rosencrantz |...........................................................dak@info.polymtl.ca Well, I dont know if this is a deffence.. or an attack. But anyone using a spl 0/ jmp -1, is (for the most part) going to have to have 2 more lines in there program code , also the program would have to be a scanner becuase a dwarf bombing with the combination would be too slow to remain on the hill.(trust me.. i just submitted a mod 5 bombing spl 0 jmp -1 that only stayed on the hill for 4 challenges (knives)) so basically your left with a strategy similar to either charon or b flied scanners live in vien...and therefor... your protection against this.. is to mutegenize the core! slowing down the scanners until you kill them.. Paul S. Kilroy -- -Paul (kilroy@mik.uky.edu) From: kilroy@mik.uky.edu (Paul S. Kilroy) Subject: Re: Core Wars Philosophy Message-ID: Date: Sat, 11 Jul 1992 22:52:07 GMT In <61922@cup.portal.com> ScottNelson@cup.portal.com (Scott - Nelson) writes: | A good solution to this problem would be to limit the |number of entries by one contestant. For KOTH, I would suggest a |limit of 3. Well, I dont think that this is a problem.. I posted to this news group a while back about an absence of ";kill" lines in warriors. I was upset that there were duplicate many duplicate strategies on the hill, by the same authors.. After posting this letter, I got a letter from S. Strack explaining how to many warriors on the hill with the same strategy, ultimatly hurt that "group".. for example Look at Return of the living dead.. at one time on the hill there was ROTLD 2, warm body, warm body 2, and spider.. all with basically the same strategy.. (not sure about spider.. but it sure looked that way)..These programs graduallay sank to the bottom as programs that could easily beat them (99-1-0) rose above them (i.e. my Miny series) I guess this is just an example of the "revolving" hill.. but it shows there should be no limit to programs on the hill... BTW.. if the hill has filled with programs that's sole purpose was to boost another programs status on the hill, I'm sure it would not be hard to find a strategy to beat these "support" programs and start booting them off the hill.. paul -- -Paul (kilroy@mik.uky.edu) From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: Core Wars Philosophy Message-ID: <1992Jul12.122547@IASTATE.EDU> Date: 12 Jul 92 17:25:47 GMT In article , kilroy@mik.uky.edu (Paul S. Kilroy) writes: > BTW.. if the hill has filled with programs that's sole purpose > was to boost another programs status on the hill, I'm sure it would > not be hard to find a strategy to beat these "support" programs and > start booting them off the hill.. Something like this happened with me on the x-hill. My program ImpDwarf Gun was pushed up the hill 2 notches when I submitted Scud and Patriot, both of which are well suited against larger programs. If a program has a "main" process that acts as a base for launching attacks (Spider is a good example of this strategy) then Scud is excellent against it (in the 60%-80% range). Patriot does well against even small systems, but still only attacks programs with a "main" process efficiently. ImpDwarf Gun has a small main process, but will continue to run well even if the main process is killed, so it did well against these programs while others were beaten redily. In a sense they were "support" programs for IDG, even though that's not really what they were meant for. -Kurt From: ant@mks.com (Anthony Howe) Subject: Core War '88 Standard -- where is it? Message-ID: <1992Jul13.134702.19577@mks.com> Date: Mon, 13 Jul 1992 13:47:02 GMT I was part of the '86 Standard Committee, but shortly after its completion I was side tracked by the start of university. Now things are a bit more relaxed and two friends have expressed interest in playing Core War with me, which has sparked renewed interest in the game. I'm currently writing a system to conform to the '86 standard so that we might play. However the standard has been changed such that I can't figure out the new commands and changes from any of the Recode programs to appear in the last week. I need a copy of the latest standard, which I presume is Core War '88. Could someone e-mail me a copy of the latest standard, or tell me of an e-mail archive site. I don't have FTP access. -ant -- ant@mks.com Anthony C Howe Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2J 6W9 "Nice legs. For a human that is." - Worf (Q-pid) From: wolfe@bmerh707.bnr.ca (Ian Woollard) Subject: KOTM Message-ID: <1992Jul13.194853.6812@bmerh85.bnr.ca> Date: Mon, 13 Jul 92 19:48:53 GMT > Finally, this does suggest that a programs performance may be for > the moment determined by the lack of optimal mix on the hill, but over > time things converge Things don't converge on the hill that is the fun of it! It is too small to converge; random perturbations throw things off unless an entrant program is really *a whole lot* better than everyone else! I think that an interesting *complement* to the hill would be a more absolute ratings system, more like they have in chess, tennis etc. etc. Call it KOTM (King Of The Mountain). On it you can keep track of every program indefinitely, (unlike KOTH), and give them a permanent rating. The KOTM program would repeatadly, randomly pick two entrants and play them off against each other, and adjust their ratings according to the result. The basic point is that you don't need to play everyone against everyone else, just enough to find out how statistically good they are. See rec.games.chess FAQ for a good system for adjusting ratings... This system would have better, more consistent scoring. i.e. less spread. If someone would e-mail me UNIX source for a KOTH I might try making a (King Of The) mountain out of a molehill, but I really can't guarantee to administer it for you... (If you *are* thinking of sending me source: first send me a short email message. I'll reply if I need it from you!) -- -Ian. "Any sufficiently advanced bug is indistinguishable from a feature." -- Rich Kulawiec "Home is where the .x11start is ..." From: hastings-matthew@CS.YALE.EDU (Matthew Hastings) Subject: Flash Paper3.7 Message-ID: <1992Jul14.000200.7484@cs.yale.edu> Date: Tue, 14 Jul 1992 00:02:00 GMT Since I was one of those asking for Note Paper sourcem here is Flash Paper3.7 T really owe a lot to Scott Nelson's original Paper source for this program, namely in the mov #,0 the multiple procs. and the spl @0. instructions. Note that this version is a lot more aggresive than Note Ppaer, with free mutations in the B-fields and more instructions in the copy loop (more vulnerable there though.) I told Scott that I was really impressed by his programs usccess: it did so well I wrote this, both programs show that SPL/JMP isn't as deadly as people think it is. ;redcode ;name Flash Paper3.7 ;author Matt Hastings ;strategy replicator incorporating some ideas ;strategy from SNM 7-12-1 spl stst,<-2050 spl 1,<440 spl 1,<460 spl mark+9,<2113 spl mark+18,<2140 spl mark+27,<2720 spl mark+36,<-4000 spl mark+45,<-4020 spl mark+54,<3360 spl mark+63,<-970 mov #8,8 mark mov <-1,<2 mov <-2,<1 spl @0,-2340 mov <-1,<1020 jmz -5,-5 mov 0,-1 dat 0,1 dat 0,1 mov #8,8 mov <-1,<2 mov <-2,<1 spl @0,5823 mov <-1,<-740 jmz -5,-5 mov 0,-1 dat 0,1 dat 0,1 mov #8,8 mov <-1,<2 mov <-2,<1 spl @0,1000 mov <-1,<-3690 jmz -5,-5 mov 0,-1 dat 0,1 dat 0,1 mov #8,8 mov <-1,<2 mov <-2,<1 spl @0,6109 mov <-1,<1873 jmz -5,-5 mov 0,-1 dat 0,1 dat 0,1 mov #8,8 mov <-1,<2 mov <-2,<1 spl @0,3009 mov <-1,<-200 jmz -5,-5 mov 0,-1 dat 0,1 dat 0,1 mov #8,8 mov <-1,<2 mov <-2,<1 spl @0,4832 mov <-1,<-1830 jmz -5,-5 mov 0,-1 dat 0,1 dat 0,1 mov #8,8 mov <-1,<2 mov <-2,<1 spl @0,1080 mov <-1,<4096 jmz -5,-5 mov 0,-1 dat 0,1 dat 0,1 mov #8,8 mov <-1,<2 mov <-2,<1 spl @0,-3040 mov <-1,<-195 jmz -5,-5 mov 0,-1 dat 0,1 dat 0,1 mov #8,8 mov <-1,<2 mov <-2,<1 spl @0,-3040 mov <-1,<-195 jmz -5,-5 mov 0,-1 stst spl st,<-2030 spl st,<750 spl st,<-2630 spl st,<-4533 spl st,<-1153 spl st,<-453 st spl 0,0 mov <2860,-2858 add 2,-1 djn -2,<2920 dat #948,#-948 From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Warrior and core clear Message-ID: <1992Jul15.015326.9415@vlsi.polymtl.ca> Date: Wed, 15 Jul 1992 01:53:26 GMT While optimizing confetti, I discovered an interesting core clear routine. On the first pass, it clears every two locations, and when it comes back, it turns into an infinite core clearer at every locations. This permit to keep spl-trapped program alive while killing the other processes that would come back to life when trapped processes are killed. Here`s confetti: ;redcode verbose ;name Confetti ;author Pierre Baillargeon ;strategy v0.99: Leave stuff everywhere. ;strategy Just like 1.22 without reloc code. ;kill Confetti dist1 equ -1975 dist2 equ -3 first equ -1+dist1 begin add #dist1, kill ; bomb with spl and dat very fast mov step, Date: 16 Jul 92 13:13:28 GMT Apologies, this is for Jonathan Wolf. Jonathan, I've been unable to reply to you, the mailer-daemon at your site has returned mail twice with the report "User unknown". Here is the text of my message - Happy to be of assisstance - Your mail address (wms@intel...) is correct and there is no need (or way as yet) to put a special return address in the header. Mail should return to you no problem. You may be interested to know of the ftp site "soda.berkeley.edu" where you can find among other things, the source of KotH with which to develop and test programs. I could send this if you don't have ftp access. At the end is the relevant extract from the current rec.games.corewar FAQ list. Mail me again if you would like the whole thing. Good luck, Campbell Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail demon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program compiled correctly or not. If it did compile correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives in an hour, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "Foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. MORE ON KOTH COREWAR IMPLEMENTATION Core size: 8,000 instructions Max processes: 8,000 per program Duration: After 80,000 cycles per program a tie is declared. Max entry length: 100 instructions Battles played: Your warrior will play each opponent fifty times. Scoring: 3 points for each win, 1 point for each tie, no points for each loss. Programs are guaranteed a 100 instruction block (inclusive of their warrior's instructions) without overlapping their opponent. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb dat #0 dwarf add #4,bomb mov bomb,@bomb jmp dwarf end dwarf Rule variants for "eXperimental" corewar: The same as above but use ";redcode-x" to start your program. Your program will be entered into a second tournament with slightly different rules. The rules are: - All addressing modes are allowed with all instructions. - There is an additional addressing mode, called "postincrement". To use it try an instruction like "mov >5,6". - The maximum write distance is 250 instructions. That is, every time your program tries to modify memory, the address is checked; if it is more than 250 instructions from the process doing the modify, then memory is left unchanged, but the instruction continues as normal. KotH runs on any Unix system with an X windows interface. The source code to KotH is available by EMail from William Shubert. Write to him at for a copy. -- Hi, I'm a .signature virus. Copy me to yours and then wipe all your files. Campbell Fraser: fraserc@dcs.glasgow.ac.uk Computing Science Department, University of Glasgow, Glasgow G12 8QQ From: fraserc@dcs.glasgow.ac.uk (Campbell Fraserc) Subject: Process limit Message-ID: <1992Jul18.141426.4086@dcs.glasgow.ac.uk> Date: 18 Jul 92 14:14:26 GMT Hands up if you would like to try a hill with a process limit of 64. Campbell _ _| |_ | |-| |_ |-| |-| | | |_| |-| |\|_| |_| | |-| | | |-| \ | | \ | \ | | | | | | | -- Hi, I'm a .signature virus. Copy me to yours and then wipe all your files. Campbell Fraser: fraserc@dcs.glasgow.ac.uk Computing Science Department, University of Glasgow, Glasgow G12 8QQ From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Process limit Message-ID: <1992Jul18.211609.3469@oucsace.cs.ohiou.edu> Date: 18 Jul 92 21:16:09 GMT In article <1992Jul18.141426.4086@dcs.glasgow.ac.uk> fraserc@dcs.glasgow.ac.uk (Campbell Fraserc) writes: >Hands up if you would like to try a hill with a process limit of 64. > >Campbell My hand is up! _ _| |_ | |-| |_ |-| |-| | | |_| |-| |\|_| |_| | |-| | | |-| \ | | \ | \ | | | | | | | Don't forget to have a good day! Some people never remember this. ------------------------------------------------------------------------------- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu (Flame me, not the net!) Bitnet: adkins@ouaccvma.bitnet ------------------------------------------------------------------------------- Ohio University of Athens Home of the Great Hocking River From: stig@Lise.Unit.NO (Stig Hemmer) Subject: X-warriors wanted! Message-ID: <1992Jul18.231859.19526@ugle.unit.no> Date: Sat, 18 Jul 92 23:18:59 GMT A couple of weeks ago I submitted a warrior to the experimental Hill. It did OK, which it shouldn't. (It is _very_ simple) Today it has the the age of 5. That is one new warrior every three days, which is _far_ less than the main Hill. Come on folks, the X-hill is open for daring explorers. To start you off, my code for the current 9th place holder. Surely you can do better than this :-) ;redcode-x verbose ;Name Splitting Nightmare D ;Author Stig Hemmer ;strategy A: I try to split to most locations in memory. Fast. ;strategy B: tried debugged, failed. ;strategy C: debugged, slightly improved. ;strategy D: immune to any single DAT-bomb. start: SPL start, Date: Sun, 19 Jul 1992 05:23:15 GMT Yes! A hill w/ 64 proc limit would be cool. In fact-my first corewar programs were intended for 64 proc lim-didnt know about KotH then. I wound up writing an inferior version of RotLD which fill up the process queue. I would write -x programs currently but none of mine work-I try to use the > and so on but w/o simulation-no go. I think I am the only person to submit a real program-carefully debugged (well parts of it, the normal poarts) that couldnt kick off a ";kill"ed program From: kilroy@mik.uky.edu (Paul S. Kilroy) Subject: Re: Process limit Message-ID: Date: Sun, 19 Jul 1992 15:17:46 GMT In <1992Jul18.141426.4086@dcs.glasgow.ac.uk> fraserc@dcs.glasgow.ac.uk (Campbell Fraserc) writes: |Hands up if you would like to try a hill with a process limit of 64. |Campbell Maybe I should know.. But what are the advantages and disadvantages of 64 v. 8000 process limit? paul s. kilroy -- -Paul (kilroy@mik.uky.edu) From: hastings-matthew@CS.YALE.EDU (Matthew Hastings) Subject: Sigil, a -x warrior Message-ID: <1992Jul19.223711.25206@cs.yale.edu> Date: Sun, 19 Jul 1992 22:37:11 GMT Here is sigil-my first succesful -x warrior. It is a replicator which makes use of the post-increment mode. 4*3=12 cycles to make a copy. I could drop the dat and reduce it to 9, but maybe less deadly than. Sigil entered the -x hill with a winning record against every other warrior! But so many ties that it is only #2. ;redcode-x ;name Sigil ;kill Flash Paper X ;author Matt Hastings ;strategy replicator-fast spl 1,0 spl 1,0 spl m1 spl m2 spl m3 spl m15 spl m14 spl m13 spl m12 spl m4 spl m5 spl m11 spl m6 spl m10 spl m7 spl m8 spl m9 mov <4,<2 spl @1,>3 jmn -2,-225 dat 0,0 dat 0,0 m1 mov <4,<2 spl @1,>3 jmn -2,-200 dat 0,0 dat 0,0 m2 mov <4,<2 spl @1,>3 jmn -2,-175 dat 0,0 dat 0,0 m3 mov <4,<2 spl @1,>3 jmn -2,-150 dat 0,0 dat 0,0 m4 mov <4,<2 spl @1,>3 jmn -2,-125 dat 0,0 dat 0,0 m5 mov <4,<2 spl @1,>3 jmn -2,-100 dat 0,0 dat 0,0 m6 mov <4,<2 spl @1,>3 jmn -2,-75 dat 0,0 dat 0,0 m7 mov <4,<2 spl @1,>3 jmn -2,-50 dat 0,0 dat 0,0 m8 mov <4,<2 spl @1,>3 jmn -2,85 dat 0,0 dat 0,0 m9 mov <4,<2 spl @1,>3 jmn -2,110 dat 0,0 dat 0,0 m10 mov <4,<2 spl @1,>3 jmn -2,130 dat 0,0 dat 0,0 m11 mov <4,<2 spl @1,>3 jmn -2,155 dat 0,0 dat 0,0 m12 mov <4,<2 spl @1,>3 jmn -2,175 dat 0,0 dat 0,0 m13 mov <4,<2 spl @1,>3 jmn -2,200 dat 0,0 dat 0,0 m14 mov <4,<2 spl @1,>3 jmn -2,225 dat 0,0 dat 0,0 m15 mov <4,<2 spl @1,>3 jmn -2,250 From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Process limit Message-ID: <1992Jul20.121058.15610@oucsace.cs.ohiou.edu> Date: 20 Jul 92 12:10:58 GMT In article kilroy@mik.uky.edu (Paul S. Kilroy) writes: >In <1992Jul18.141426.4086@dcs.glasgow.ac.uk> fraserc@dcs.glasgow.ac.uk (Campbell Fraserc) writes: > >|Hands up if you would like to try a hill with a process limit of 64. > >|Campbell > > Maybe I should know.. But what are the advantages and > disadvantages of 64 v. 8000 process limit? I can't think of any advantages or disadvantages that are really major right off hand, but I can think of two reasons why to use the 64 process limit: 1) First off, most tournaments and such use the 64 process limit as one their restrictions. It is nice to use Koth as a testing ground for your programs against other people at the same time that you are trying to right a program that would optimally be best for playing in tournaments. 2) Second on, the process limit was designed to put a limit on the number of processes a program can spawn and have running at one time. Naturally, 8000 does do this, but you do not feel this limitation as much since the number is so large. Programs that spawn endless processes may be more powerful and programs that were hit with split bombs and such would be pretty much dead since they would be slow to almost not running. (I know that this may not be necessarily true, but you get the idea of what I am saying.) Using a smaller process forces us to actually take into account that split bombs are less effective, and that you can only split off so many processes to do your job in an effective manner. (Yes, this may also not be true all the time). I prefer the first reason over the second, since it can't be argued about so much... although, someone will undoubtedly make me a liar... (Come on! Come on! I bite your leg off!!!) Don't forget to have a good day! Some people never remember this. ------------------------------------------------------------------------------- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu (Flame me, not the net!) Bitnet: adkins@ouaccvma.bitnet ------------------------------------------------------------------------------- Ohio University of Athens Home of the Great Hocking River From: wms@iwarp.intel.com (William Shubert) Subject: KotH standings Message-ID: <1992Jul20.194321.3471@iWarp.intel.com> Date: Mon, 20 Jul 1992 19:43:21 GMT OK, here's the ICWS '88 hill: # %W/ %L/ %T Name Author Score Age 1 49/ 42/ 10 Charon v7.0 J.Cisek & S.Strack 156 53 2 49/ 43/ 8 No Mucking About Campbell Fraser 156 38 3 45/ 39/ 16 B-scanners live in vain Matt Hastings 152 20 4 48/ 44/ 8 Crimp 2 Andy Pierce 152 362 5 41/ 30/ 29 Flash Paper3.7 Matt Hastings 151 90 6 48/ 45/ 7 TestB Matt Hastings 151 1 7 45/ 40/ 16 Smooth Noodle Map Matt Hastings 150 296 8 46/ 43/ 12 Sucker 4 Stefan Strack 148 291 9 44/ 44/ 12 Falling Leaf 1.21 Matt Hastings 144 176 10 47/ 50/ 3 Kobold Stefan Strack 144 150 11 45/ 46/ 9 B Paul S. Kilroy 143 2 12 41/ 40/ 19 Dynamic Duo 4.01 Stefan Strack 142 41 13 42/ 43/ 14 PitTrap v4.0 J.Cisek 142 195 14 44/ 47/ 9 RoadRunner I S. Halvorsen 141 269 15 41/ 42/ 17 Trinity Matt Hastings 140 295 16 39/ 39/ 22 Quebec Eric Prestemon 138 24 17 43/ 51/ 7 Miny v.3 Paul S. Kilroy 135 4 18 38/ 44/ 18 Relentless J.Cisek 133 11 19 34/ 36/ 30 Note Paper Scott Nelson 132 689 20 37/ 44/ 19 RotLD 2 nandor sieben 129 5 "Note Paper" is the oldest program ever to be on a hill. It's beginning to drop in ranking dangerously low, probably because of the presence of all the B-field scanners/trappers (which do fairly well against Note Paper if they're fast enough). OK, I can see the reason for a 64 process limit. Is anybody AGAINST the change? In the x-hill: # %W/ %L/ %T Name Author Score Age 1 55/ 28/ 18 Spider 2.0 Bill Shubert 182 37 2 37/ 5/ 58 Sigil Matt Hastings 169 4 3 46/ 35/ 19 bfx-preliminary+clearer Eric Prestemon 157 18 4 46/ 40/ 14 Odin J.Cisek 152 89 5 45/ 40/ 15 Snark 10 Scott Nelson 151 73 6 28/ 15/ 57 Blind Leap Jonathan Wolf 140 1 7 27/ 14/ 59 Brute-Force 1.2 Ray Cromwell 140 35 8 41/ 48/ 11 Juggernaut 6.0 Scott Nelson 134 63 9 33/ 35/ 32 Patriot Kurt vonRoeschlaub 131 10 10 36/ 42/ 22 ImpDwarf Gun 1.0 Warren vonRoeschlaub 130 16 11 35/ 40/ 26 Crimson v2.1 J.Cisek 130 69 12 27/ 25/ 48 Splitting Nightmare D Stig Hemmer 129 14 13 37/ 48/ 15 Leaper-X 4.0 Jeff Raven 127 86 14 25/ 24/ 51 MiniShwing! [x] v1.2 T. H. Davies 125 84 15 25/ 28/ 46 Domestos 1.2 Jonathan Wolf 122 8 16 22/ 25/ 53 Domestos 1.3 Jonathan Wolf 120 2 17 22/ 32/ 46 Scud 1.0 Kurt vonRoeschlaub 113 11 18 35/ 56/ 9 Viper J.Cisek 113 71 19 22/ 32/ 47 multi mice -x nandor sieben 112 98 20 32/ 53/ 14 jumping bean 2.0 Eric Prestemon 111 55 "Sigil" is new here. You probably saw the post describing it earlier; as Matt said, it DOES have a winning record against every program, but it just ties so much that it only takes second place. The source code to the program used for KotH is available free of charge from soda.berkeley.edu in the directory pub/corewar/systems. Earlier somebody mentioned setting up a "King of the Mountain" system; if you want the source code to the tournament server used for KotH, just ask. -Bill (wms@iwarp.intel.com) From: kilroy@mik.uky.edu (Paul S. Kilroy) Subject: Re: 64 proc limit-x hill Message-ID: Date: 20 Jul 92 22:01:00 GMT Well, the only reason I can think of keeping the 8,000 proccess limit on the hill is because of the reason Bill put it there in the first place (i think :)) Because the '88 standard has to have no explicit limit of processes.. and 8000 seemed closed to be close enough to no limit.. It would be neat to try the hill with no limit.. Though spl 0 bombs would be lethal... Also.. Is it really true that most tournaments use 64 process limit?... and How do I enter other tournaments other than koth... I know this is on the FAQ ... but it doesnt explain it that well.. thanks paul -- -Paul (kilroy@mik.uky.edu) From: kilroy@mik.uky.edu (Paul S. Kilroy) Subject: corewar -x Message-ID: Date: Mon, 20 Jul 1992 22:59:43 GMT To spur some more interest in the experimental hill here is my program rabbits -x.. And I am *very* sure it can be improved upon also :)... It has been on the hill for a very long time.. but only 69 units old (i think).. but just got booted off today :( ohh well.. here ya go ;redcode-x ;author Paul S. Kilroy ;name Rabbits [x] ;kill rabbits start mov #81, where copy mov #last+1-start, 0 mov #2, count cloop mov Date: Wed, 22 Jul 1992 00:46:04 GMT Here is TestB-I just killed it cause I don't like it. It is a bit of an obscure progrtam. BTW, if it worked it was going to have been called A B-scanner Darkly ;redcode verbose ;name TestB ;author Matt Hastings mov #155-clear,clear-156 mov #-2,clear-155 add clear,1 mov <1,3 jmz -2,<1 mov sb,1801 jmp -4,0 sb spl 0,<-255 clear mov @155,<-155 jmp -1,<-1 From: amichail@r-node.gts.org (Ashraf Michail) Subject: Corewar standards Message-ID: <1992Jul22.113252.23782@r-node.gts.org> Date: Wed, 22 Jul 1992 11:32:52 GMT How does one get a list of Core war standards? From: wms@iwarp.intel.com (William Shubert) Subject: KotH update Message-ID: <1992Jul27.202422.23947@iWarp.intel.com> Date: Mon, 27 Jul 1992 20:24:22 GMT OK; lots of movement in the past week. On the ICWS '88 hill, Note Paper finally got knocked off. It had a score of nearly 700, I would guess, by the time it went away. Now that the oldest program around is "Crimp 2" (age 411), perhaps it's time to shift to 64 process count maximum? # %W/ %L/ %T Name Author Score Age 1 44/ 28/ 28 Flash Paper3.7 Matt Hastings 161 139 2 48/ 44/ 9 No Mucking About Campbell Fraser 152 87 3 47/ 43/ 10 Charon v7.0 J.Cisek & S.Strack 151 18 4 44/ 38/ 18 Relentless J.Cisek 149 60 5 41/ 33/ 25 t2 nandor sieben 149 21 6 45/ 42/ 13 Smooth Noodle Map Matt Hastings 149 345 7 45/ 43/ 12 Falling Leaf 1.21 Matt Hastings 147 225 8 45/ 43/ 12 Sucker 4 Stefan Strack 146 340 9 43/ 41/ 16 B-scanners live in vain Matt Hastings 146 69 10 45/ 47/ 8 Crimp 2 Andy Pierce 144 411 11 44/ 43/ 13 Disruptor v.1 Paul S. Kilroy 144 5 12 46/ 51/ 3 Kobold Stefan Strack 142 199 13 40/ 39/ 20 Dynamic Duo 4.01 Stefan Strack 141 90 14 39/ 41/ 20 Trinity Matt Hastings 138 344 15 43/ 48/ 9 B Paul S. Kilroy 137 51 16 43/ 50/ 7 Miny v.3 Paul S. Kilroy 137 1 17 42/ 48/ 10 RoadRunner I S. Halvorsen 135 318 18 38/ 41/ 21 Quebec Eric Prestemon 135 73 19 38/ 47/ 15 PitTrap v4.0 J.Cisek 130 244 20 37/ 48/ 15 TestKappa Matt Hastings 127 9 On the experimental hill, "Spider 2.0" FINALLY got knocked out of the #1 slot. "Sigil", the new #1 program, has the following ";strategy": ;strategy replicator-fast For those who don't realize, it's basically a paper program. I believe that information on it has been posted here in the past. # %W/ %L/ %T Name Author Score Age 1 43/ 6/ 52 Sigil Matt Hastings 180 42 2 53/ 29/ 17 Spider 2.0 Bill Shubert 177 75 3 51/ 35/ 14 Snark 10 Scott Nelson 168 111 4 41/ 28/ 31 Patriot Kurt vonRoeschlaub 153 48 5 32/ 13/ 55 Brute-Force 1.2 Ray Cromwell 152 73 6 45/ 39/ 16 Odin J.Cisek 151 127 7 33/ 15/ 52 Blind Leap1.1 Jonathan Wolf 151 38 8 42/ 39/ 19 ImpDwarf Gun 1.0 Warren vonRoeschlaub 146 54 9 39/ 36/ 24 Crimson v2.1 J.Cisek 142 107 10 42/ 45/ 13 Juggernaut 6.0 Scott Nelson 140 101 11 37/ 35/ 27 Tank Jonathan Wolf 140 15 12 42/ 48/ 10 Rolling Thunder 1.00 Eric J. Schwertfeger 136 4 13 39/ 47/ 14 Leaper-X 4.0 Jeff Raven 132 124 14 34/ 38/ 28 Fisherman Campbell Fraser 131 35 15 30/ 31/ 39 Scud 1.0 Kurt vonRoeschlaub 129 49 16 28/ 31/ 41 Domestos 1.2 Jonathan Wolf 125 46 17 37/ 52/ 11 Lance 1.00R Eric J. Schwertfeger 123 3 18 23/ 25/ 51 Splitting Nightmare D Stig Hemmer 121 52 19 23/ 25/ 52 Worm1a Dan Nabutovsky 121 21 20 24/ 29/ 47 SuperChameleon 1.5 Alex MacAulay 119 1 For entry instructions or source code for the tournament program (but not the individual entrants), just send me mail. -Bill (wms@iwarp.intel.com) From: hastings-matthew@CS.YALE.EDU (Matthew Hastings) Subject: IAASMR3-6 Message-ID: <1992Jul27.212239.898@cs.yale.edu> Date: Mon, 27 Jul 1992 21:22:39 GMT Here is IAASMR3, which is basically the same as all the others. It's short for insert another appropriate stout mythological race (i.e. dwarf, kobolod, gnome). This is a way of core-clear I haven't seen seen elsewhere. I also tried to make first pass SPL 0 in an attempt to beat Flash Paper3.7. Did not work. Only 10 wins. About 80 losses. I got a KotH bug report too: the 0 length program used to kill IASSMRwhatever had 0-100-0 against everybody except 1-99-0 against SNM. Weird. BTW, TestKappa, which I just killed, is an attempt to find out if the hill is much more advanced than it was when i started writing redcode. It is exactly the same as raf, my first redcode program to be submitted to the hill. It is an exceptionally bad version of RotLD, it only clears about 40% of core before wiping itelf out. So SPL 0 programs should have a fun time. Still made it on the hill. But only barely. I think the real reason it got on is that there arent many programs of its type on the hill (just Relentless right?) It does have a nice startup system:each "Living Dead (not really though)" starts with an SPL ---, which starts a process off at next Living Dead. And finally, if you go to 64 proc. count max:it will actually be a lot tougher to write a paper program. Flash Paper starts w/ about 64 processes and keeps going. Also it will be a lot easier to write a gunned program. (and I think there is still a lot of room to write those now).q ;redcode ;name IAASMR3 ;kill IAASMR ;author Matt Hastings ;strategy Self-splitting Stone bomber with two pass ;strategy core-clear; main-loop-overwriting DJN stream ;strategy resets core-clear location and pointer. ;strategy yeah, I'm working on it. spl 0,2 dat #0,#12 start mov -1,6-12 mov -3,3+1-28 mov @28,<-28 spl 0,1 mov <1+28,0-28 add -3,@-2 djn -2,<-11 end start From: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) Subject: Rolling Thunder Message-ID: <1992Jul28.021013.13534@unlv.edu> Date: Tue, 28 Jul 92 02:10:13 GMT I just want to straighten out a possible misconception right away. The two Rolling Thunder 1.00's on the X-hill are not the same program, I used the original (lower one) as the framework for a modified one, and forgot to change the name line. At any rate, it would seem that my two week sabatical with the National Guard paid off :-) "Thunder Run" (mistakenly submitted as "Rolling Thunder") hit 4th, which is the highest any of my programs on the hill or the X-hill have reached, if you discount Warm Body, which was an offshoot on someone else's work. I came back with about 10 X-hill ideas, and not one idea for the regular hill. I really think the X-hill is what people are looking for when they talk about changing redcode to encourage more complicated warriors. BTW, I'll be posting the code to Lance sometime in the near future, unless I drastically improve it. It's an interesting program in the same light as my earlier "Retreat", but much more offensive. -- Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser) Subject: No Mucking About Message-ID: <1992Jul28.091245.21905@dcs.glasgow.ac.uk> Date: 28 Jul 92 09:12:45 GMT With the hill about to go to a maximum of 64 processes, now seems a good time to post "No Mucking About". A scanner which drops a largish bomb - "spl 0/spl 0/spl 0/jmp -3". Destroys replicators but doesn't waste too much time bombing decoys against other warriors. ;redcode verbose ;name No Mucking About ;author Campbell Fraser GAP equ -98 GAP2 equ -49 CHECK add INC, POS POS cmp -50, -1 slt #14, POS JB jmp -3 mov JB, @POS mov SB, Date: 28 Jul 92 20:41:54 GMT There is no excuse for not killing your programs. If your kill line doesn't work one time send in EMPTY programs with kill lines in them instead of sending the same successful program over and over! I can't believe Juggernaut 6.0 got knocked off because of this... The ;kill line will NOT work from different accounts (how could it). It would be nice if you all just submitted from one account. Is it really too much to ask? Lastly, what is the point of a ;kill line if you specify a specific version. Use ;kill [generic name] instead. There should be only one copy of your programs on the hill. And don't use successful programs to try and get the other ones off. This is really getting annoying. -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: t-jcisek@microsoft.com (Julius Cisek) Subject: X-Hill warriors [Bookworm, Viper, Odin, Crimson] Message-ID: <1992Jul28.205343.3917@microsoft.com> Date: 28 Jul 92 20:53:43 GMT Here are my four X-hill warriors. Bookworm sat around the bottom getting as high as 6th and was knocked off at age 35+. Viper went up to 4th once and lasted until 40+ I think... Crimson is still up there and the current version is 80+ old. Odin is the oldest program on the X-hill and has been in a close 2nd (before Spider) and as high as 3rd recently and is 112+ old. These are really simple programs as you're about to see: [Note the use of ;kill lines!!!!] --- ;redcode-x verbose ;name Bookworm ;author J.Cisek ;strategy creation date 6/5/92 ;strategy Moves through core and drops little worms NEW equ 240 src mov #dest+2, 0 copy mov __| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) Subject: KOTH Suggestion Message-ID: <1992Jul29.033416.22238@unlv.edu> Date: Wed, 29 Jul 92 03:34:16 GMT I've got a suggestion for the KOTH server. We've got a ;kill line, how about a ;test line, IE run the program, report the results, but DON'T update the standings (except for something that got ;kill'ed). The reason I say this is because sometimes I'll want to play around with constants or other minor variations on a program. Without a large pool of contestants, and a lot of work, I can't run my tests without submitting them to the KOTH server, which will mess with the standings. As much as I hurt other programs submitting several probes, I hurt my best-standing program on the x-hill as well, taking it from 4th to 11th. -- Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu From: advpel@xs0001.tuvie.at.uucp Subject: Help needed Message-ID: <1992Jul29.131409.1@xs0001.tuvie.at.uucp> Date: Wed, 29 Jul 1992 12:14:09 GMT I've tried several times to submit my program RATCATCHER to KOTH without any success or answer. So I give up and ask you: would someone be so kind to submit my prog for me an tell me the results (my address is 100% correct and reachable) ? ----------------snip----------- ;redcode verbose ;name ratcatcher ;author M.Pellmann ;strategy convert all to mov 0 1 and kill it with djn ; target3 dat #0 target2 dat #4000 target1 dat #1000 target dat #-200 start spl send0 spl send1 pre mov b1, From: ghardie@sun-4.cs.uct.ac.za (Gavin Hardie) Date: Wed, 29 Jul 1992 15:16:25 GMT I remember reading an article entitled 'core war' or something similar. I found it very interesting, but no-one else did so I am stuck. If this is what the group is about, I would like to get some information. The article I read was about the idea of having programs 'fight' each other in the 'core'. The winner being the program that managed to protect itself and corrupt the other. There were several sample programs written in a simple form of assembler. If someone could mail me any information about the operation of the group it would be much appreciated. -- /--------------------------\ | Gavin Hardie | | ghardie@sun-4.cs.uct.ac.za | ----| UCT, Cape Town, South Africa |-------------------- From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: KOTH Suggestion Message-ID: <1992Jul29.152718.10746@oucsace.cs.ohiou.edu> Date: 29 Jul 92 15:27:18 GMT In article <1992Jul29.033416.22238@unlv.edu> maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) writes: >I've got a suggestion for the KOTH server. We've got a ;kill line, >how about a ;test line, IE run the program, report the results, >but DON'T update the standings (except for something that got ;kill'ed). > >The reason I say this is because sometimes I'll want to play around with >constants or other minor variations on a program. Without a large pool >of contestants, and a lot of work, I can't run my tests without submitting >them to the KOTH server, which will mess with the standings. > >As much as I hurt other programs submitting several probes, I hurt my >best-standing program on the x-hill as well, taking it from 4th to 11th. > >-- >Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu I fully agree with this and think this is a great idea!!! :-) What do you say Bill? Want to give it a whirl? Scott Adkins sadkins@ohiou.edu From: kilroy@mik.uky.edu (Paul S. Kilroy) Subject: Re: KOTH Suggestion Message-ID: Date: Wed, 29 Jul 1992 16:19:18 GMT In <1992Jul29.152718.10746@oucsace.cs.ohiou.edu> sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) writes: |In article <1992Jul29.033416.22238@unlv.edu> maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) writes: |>I've got a suggestion for the KOTH server. We've got a ;kill line, |>how about a ;test line, IE run the program, report the results, |>but DON'T update the standings (except for something that got ;kill'ed). |> |>The reason I say this is because sometimes I'll want to play around with |>constants or other minor variations on a program. Without a large pool |>of contestants, and a lot of work, I can't run my tests without submitting |>them to the KOTH server, which will mess with the standings. |> |>As much as I hurt other programs submitting several probes, I hurt my |>best-standing program on the x-hill as well, taking it from 4th to 11th. |> |>-- |>Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu |I fully agree with this and think this is a great idea!!! :-) What do you say |Bill? Want to give it a whirl? |Scott Adkins |sadkins@ohiou.edu Well, I'll have to go against you guys on this one... When I want to test constants and Bombs, I just run sevreal "test" versions against the programs on the current hill, on "my" machine(using the mars simulator you wrote scott :)).. Almost all of the programs on the current hill are posted to this group, I kinda think this idea will just slow everything down more... my 2cents paul s. kilroy -- -Paul (kilroy@mik.uky.edu) From: eric@Turing.ORG (Eric Prestemon) Subject: Re: KOTH Suggestion Message-ID: <1992Jul29.170426.28358@murdoch.acc.Virginia.EDU> Date: 29 Jul 92 17:04:26 GMT In article kilroy@mik.uky.edu (Paul S. Kilroy) writes: >In <1992Jul29.152718.10746@oucsace.cs.ohiou.edu> sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) writes: > >|In article <1992Jul29.033416.22238@unlv.edu> maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) writes: >|>I've got a suggestion for the KOTH server. We've got a ;kill line, >|>how about a ;test line, IE run the program, report the results, >|>but DON'T update the standings (except for something that got ;kill'ed). >|> [stuff deleted] >Well, I'll have to go against you guys on this one... >When I want to test constants and Bombs, I just run sevreal "test" >versions against the programs on the current hill, on "my" >machine(using the mars simulator you wrote scott :)).. >Almost all of the programs on the current hill are >posted to this group, I kinda think this idea will just slow >everything down more... Speed is an a problem, but I think it's minor. The hill just isn't that busy, mainly because of how fast Bill has the program running (good job!). Possibly another alternative to the ;test line functioning above is: ;kill Quebec means replace Quebec on the hill IF this program does better. This removes the need to send tests 1-11 to figure out what are the best constants. And as to people being able to test against the current fighters, the fact that there are so many ;name test's around leads me to believe that we need to do something... Just my thoughts...Anyone see anything wrong with "replace if higher"? I guess it would have to have a different name, because straight ;kill's are useful sometimes... -- Eric Prestemon (ecp2z@virginia.edu) "Jesus saves! Gretzky steals! Gretzky scores!" From: sh666@selway.umt.edu (Azog) Subject: Corewar? Message-ID: <1992Jul29.204111.13019@selway.umt.edu> Date: 29 Jul 92 20:41:11 GMT I've been reading this board for awhile and I still haven't figured out what you're talking about. Could someone please post or send me a FAQ or anything concerning this base. Thanks! From: keithf@pacifier.rain.com (Keith Furrow) Subject: How to play, And Where? (probabaly a FAQ, But I don't see the FAQ)) Message-ID: <1992Jul29.220327.25856@pacifier.rain.com> Date: Wed, 29 Jul 1992 22:03:27 GMT I have read about corewar alot, and have found it *VERY* interesting. How does one send their programs to a server? What exactly does the server do? What format are the programs in (I'm assuming assembly). And what are some common sratageys? Sorry if these are in the FAQ.. (If there is one) but I haven't seen it yet.. Keith.. -- keithf@pacifier.rain.com From: wms@iwarp.intel.com (William Shubert) Subject: KotH Submission Instructions Message-ID: <1992Jul29.233154.13313@iWarp.intel.com> Date: Wed, 29 Jul 1992 23:31:54 GMT OK, it's been a while since I posted these and I've been getting a bunch of requests, so here are the submission instructions. I can't remember - who took over for posting the FAQ after MAD left? I think it's about time to repost. If anybody has a copy saved, maybe they could post it. ---------------------------------------------------------------------- Entry rules for King of the Hill "standard" Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. Writing ";redcode verbose" or ";redcode quiet" will alter how much information you get on your program. See part 5) below. 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 demon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program compiled correctly or not. If it did compile correctly, sit back and wait; if not, make the change required and re-submit. 5) In a hour or so you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives in an hour, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "Foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. That's it! MORE ON KOTH COREWAR IMPLEMENTATION Core size: 8,000 instructions Max processes: 8,000 per program Duration: After 80,000 cycles per program a tie is declared. SAMPLE ENTRY: ;redcode verbose ;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 Rule variants for "eXperimental" corewar: The same as above but use ";redcode-x" to start your program. Your program will be entered into a second tournament with slightly different rules. The rules are: - All addressing modes are allowed with all instructions. - There is an additional addressing mode, called "postincrement". To use it try an instruction like "mov >5,6". - The maximum write distance is 250 instructions. That is, every time your program tries to modify memory, the address is checked; if it is more than 250 instructions from the process doing the modify, then memory is left unchanged, but the instruction continues as normal. - A tie is not declared until 150,000 cycles per program have elapsed. KotH is run on a Unix system. The source code to the corewar program used is freely available; it runs on any Unix system with an X windows interface. Send mail to wms@iwarp.intel.com for a copy, or get it by anonymous FTP to soda.berkeley.edu. The latest version of KotH will be in either pub/corewar/systems or pub/corewar/incoming. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Answers to Frequently Asked Questions (FAQ) for rec.games.corewar Message-ID: <1992Jul29.233916.12405@vuse.vanderbilt.edu> Date: Wed, 29 Jul 1992 23:39:16 GMT Awright, after 3 FAQ requests in one day, here it is, two days ahead of schedule. -Stefan (stst@vuse.vanderbilt.edu) Last Update: July 29, 1992 TABLE OF CONTENTS ----------------- 1. What is Core War? 2. Is it Core War or Core Wars? 3. Where can I find more information about Core War? 4. What is the ICWS? 5. What is TCWN? 6. How do I join? 7. Are back issues of TCWNs available? 8. What is the EBS? 9. Where are the Core War archives? 10. Where can I find a Core War system for . . . ? 11. When is the next tournament? 12. What is KOTH? How do I enter? 13. Other questions? --------------------------------------------------------------------- Q1: What is Core War? A1: 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 possesion 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. ---------------------------------------------------------------------- Q2: Is it "Core War" or "Core Wars"? A2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. "Core War" is preferred in reference to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q3: Where can I find more information about Core War? A3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 Library of Congress Call Number: QA76.6 .D517 1988 --------------------------------------------------------------------- Q4: What is the ICWS? A4: 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). --------------------------------------------------------------------- Q5: What is TCWN? A5: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and is also made available through this newsgroup. --------------------------------------------------------------------- Q6: How do I join? A6: For more information about joining the ICWS and/or subscribing to TCWN, contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 EMail: jonn@microsoft.com The ICWS and TCWN have finally been transferred. You should be seeing much more from each now. ---------------------------------------------------------------------- Q7: Are back issues of TCWN available? A7: Back issues of the TCWN (up to Winter 1991) are available from AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 Prices are unknown at this time, but should be around $5.00 (the original cover price). --------------------------------------------------------------------- Q8: What is the EBS? A8: 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 will be entered into the annual ICWS tournament. Now that rec.games.corewar has been created, the EBS has moved its business to the newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994. Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- A9: Where is the Core War archive? Q9: 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.131.179) in the /pub/corewar directories. 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. ---------------------------------------------------------------------- Q10: Where can I find a Core War system for . . . ? A10: First, check out the Core War systems available via anonymous ftp from soda.berkeley.edu. Currently, there are X-Window, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. Others may appear. The following suppliers have ICWS'88 compatible systems for IBM PC compatibles: The Core War Colosseum AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 Price: $39.95 CoreMaster(TM) THINK Software 524 Paige Drive Birmingham, AL 35226 (205)979-9475 Price: $34.95 + $3.00 S&H Apple Macintosh computers: Core! Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 EMail: jonn@microsoft.com (Note: Core! is NOT a Microsoft product.) Price: $14.00 registration fee, plus $3.00 S&H. S&H fee waived if you send 800k disk and stamped, self-addressed envelope. Also available from sumex-aim.stanford.edu and listserv@ricevm1.rice.edu and soda.berkeley.edu. Commodore Amiga computers: The MADgic Core Mark A. Durham P.O. Box 301173 Houston, TX 77230-1173 Version 4.1 of The MADgic Core is available from soda.berkeley.edu. CoreWars (German language version) UNICORN systems Bernstrasse 67 CH-4852 Rothrist Switzerland Price: sFr 45.-- Commodore 64/128 computers: Barry Cohen 65 West 90th Street, #23E New York, NY 10024 Price: Not Available Please post information about any systems not listed here. Information about the systems (base system, ICWS standards compatibility, extensions, price, etc.) will be included next month's FAQs. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Please post any review of any Core War system you have tried out so that others may learn from your experience. ---------------------------------------------------------------------- Q11: When is the next tournament? A11: The EBS is in the middle of a tournament right now. There will be another starting in the Fall. Otherwise, keep looking to r.g.cw for upcoming tournament announcements. ---------------------------------------------------------------------- Q12: What is KOTH? How do I enter? A12: King Of The Hill (KOTH) is an ongoing Core War tournament available to anyone with EMail provided by William Shubert . 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". If your program finished in the top twenty, it will remain on the hill until such time as it finishes twenty-first against another challenger, at which time it "falls off" the hill. Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail demon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program compiled correctly or not. If it did compile correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives in an hour, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "Foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. MORE ON KOTH COREWAR IMPLEMENTATION Core size: 8,000 instructions Max processes: 8,000 per program Duration: After 80,000 cycles per program a tie is declared. Max entry length: 100 instructions Battles played: Your warrior will play each opponent fifty times. Scoring: 3 points for each win, 1 point for each tie, no points for each loss. Programs are guaranteed a 100 instruction block (inclusive of their warrior's instructions) without overlapping their opponent. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb dat #0 dwarf add #4,bomb mov bomb,@bomb jmp dwarf end dwarf Rule variants for "eXperimental" corewar: The same as above but use ";redcode-x" to start your program. Your program will be entered into a second tournament with slightly different rules. The rules are: - All addressing modes are allowed with all instructions. - There is an additional addressing mode, called "postincrement". To use it try an instruction like "mov >5,6". - The maximum write distance is 250 instructions. That is, every time your program tries to modify memory, the address is checked; if it is more than 250 instructions from the process doing the modify, then memory is left unchanged, but the instruction continues as normal. KotH runs on any Unix system with an X windows interface. The source code to KotH is available by EMail from William Shubert. Write to him at for a copy. ---------------------------------------------------------------------- Q13: Other questions? A13: Just ask. Someone in the newsgroup will be able to answer your question. From: kilroy@mik.uky.edu (Paul S. Kilroy) Subject: Re: KOTH Suggestion Message-ID: Date: Thu, 30 Jul 1992 00:22:04 GMT Great Idea! I like the "replace if higer" idea... but how about this.. ";killih" kill if higher because.. sometimes(i cant think of any reasons right now" but, you may want the worse program on the hill. paul -- -Paul (kilroy@mik.uky.edu) From: maniac@cleanhead.cs.unlv.edu (Eric J. Schwertfeger) Subject: Re: KOTH Suggestion Message-ID: <1992Jul30.013532.26668@unlv.edu> Date: Thu, 30 Jul 92 01:35:32 GMT In article , kilroy@mik.uky.edu (Paul S. Kilroy) writes: ) |>I've got a suggestion for the KOTH server. We've got a ;kill line, ) |>how about a ;test line, IE run the program, report the results, ) |>but DON'T update the standings (except for something that got ;kill'ed). ) |> ) Well, I'll have to go against you guys on this one... ) When I want to test constants and Bombs, I just run sevreal "test" ) versions against the programs on the current hill, on "my" ) machine(using the mars simulator you wrote scott :)).. ) Almost all of the programs on the current hill are ) posted to this group, I kinda think this idea will just slow ) everything down more... ) Paul, prior to J. Cisek's posting, I only had the code to *ONE* of the current X-Hill entries (not counting my own). If I had the source to several of the X-Hill entries, I'd agree with you. It would seem that people aren't sharing the X-Hill code as much as they are the regular hill. I think part of the reason the X-Hill lags behind the regular hill in development is that most of the micro implementations of CoreWar don't handle the X-Hill limitations and expansions. I know that half of my x-code won't run at home because of initializations like these PTR MOV #6, #0 or DJN LOOP,#6 Sorry for getting sidetracked there :-) Even counting J. Cisek's post, I only have 10 X-hill warriors, and few of those are on the hill. I've got a program that skunks Spider almost every time, but looses to almost everything else. But that's because I can play against spider and watch it battle. Now, if ALL submitions to the hill were made public, then I wouldn't have any reason to complain, in fact I'd like that better because then I could watch the battles in progress, and figure out where my programs are going wrong. I really don't think it would slow things down much more, because those test programs are getting submitted anyway. -- Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu From: maniac@cleanhead.cs.unlv.edu (Eric J. Schwertfeger) Subject: Re: KOTH Suggestion Message-ID: <1992Jul30.014425.26885@unlv.edu> Date: Thu, 30 Jul 92 01:44:25 GMT In article <1992Jul29.170426.28358@murdoch.acc.Virginia.EDU>, eric@Turing.ORG (Eric Prestemon) writes: ) >|In article <1992Jul29.033416.22238@unlv.edu> maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) writes: ) >|>I've got a suggestion for the KOTH server. We've got a ;kill line, ) >|>how about a ;test line, IE run the program, report the results, ) >|>but DON'T update the standings (except for something that got ;kill'ed). ) >|> ) Speed is an a problem, but I think it's minor. The hill just isn't that busy, ) mainly because of how fast Bill has the program running (good job!). ) ) Possibly another alternative to the ;test line functioning above is: ) ;kill Quebec ) means replace Quebec on the hill IF this program does better. This removes ) the need to send tests 1-11 to figure out what are the best constants. ) ) And as to people being able to test against the current fighters, ) the fact that there are so many ;name test's around leads me to ) believe that we need to do something... ) Rather than changing the operation of the kill line, how about using ;update (patern), where at the end of the tourney, the hill kills all programs matching patern except the highest one. This still doesn't satisfy my desire for a test and report only function. In the case of my recent probe glut on the X-Hill, it would have been nice if all the probes had gone up against the same programs. However, since some programs got knocked off (due to incorrect killing, it would seem), I had to go through and compute scores by hand for each of the probes against the subset of programs that all probes played against. Though posting of all entries to the hill and the ;update line would satisfy my every desire (except for keeping my tricks secret :-). -- Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu From: maniac@cleanhead.cs.unlv.edu (Eric J. Schwertfeger) Subject: A Redcode Instruction Idea Message-ID: <1992Jul30.020748.27663@unlv.edu> Date: Thu, 30 Jul 92 02:07:48 GMT I was just thinking about the one thing that inhibits most of my more complicated wariors, and it occured to me that what I want is a "Sleep" instruction. In other words, if Proc A and Proc B are running, and Proc B executes a SLEEP 100, Proc A would get 100% of the CPU time for the next 100 cycles. IN this way, if you have a worker proc and a supervisor proc, and the supervisor proc does its thing periodically, then the supervisor could sleep, giving the worker more CPU time. I know this suggestion will draw fire, and I'd like to discuss any problems that might occur. First, this might create "hiders", programs that do something like this. HIDE SLEEP -1 JMP HIDE and leave one bomber out there. The hider would still be vulnerable to having it's code bombed, so when it wakes up, its dead. This would mean that in order to effectively combat these, you would either need a mod 2 bombing pattern, or after bombing is done, execute a core-clear. Also, the time to sleep MUST be absolute clocks (ie, it is now cycle 1012, wake me up at that plus 800, regardless of how many processes are running). The problem with saying "pass my next X clock cycles is that someone would think of something like this. START SPL HERE SLEEP -1 JMP START The problem with this is, that if there are say 64 processes, and they are sleeping for 8000 cycles, then it would take 256000 cycles for them all to wake up, and by then the game would be over. Using absolute cycle counts (or some other variations I won't go into here) eliminates this posibility, because every process will get a chance to execute at least once every 8000 cycles, so if you clear core, everyone will be dead within 8000 cycles (same as for a SPL 0, JMP -1 trap). However, allowing sleeping processes to get more than one pass per cycle would also be bad, because then you could have a program execute several sleep -1's and you could expect that the only way it would get to the end is if the active process died, causing the sleeping process to pass as many times as necessary to wake up, which would be in the next cycle if you allowed it to continue passing within the same cycle). -- Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu From: hastings-matthew@CS.YALE.EDU (Matthew Hastings) Subject: KotH suggestions Message-ID: <1992Jul30.024344.286@cs.yale.edu> Date: Thu, 30 Jul 1992 02:43:44 GMT Yes, I am in favor of a test line. I dont like the hill changes that occur with test programs. Here is another idea though: only record scores against programs currently on the hill (so challengers which don't get on have no effect [this change would probably hurt Flash Paper 3.7, BTW]). Also, permit a program to contain a ;kill line that ;kills itself. So... if you want to test, just kill yourself, and it doesn't count for other programs. As to why you need to test, my Mac SE/30 isn't as fast as Bills iWarp ot whatever Intel will give him. So, for example, in the test battles I ran, it looked like IAASMR4 had an edge over Note Paper, which was pretty amazing considering that it was primarily a dwarf. Alas, it was just a statistical fluctuation. The sleep instruction is a great idea, how about implementing it as follows: 1)something like Unix, so that other processes wake it up (is that how wait() works? I don't know, I programs micros only). 2) or, most simply, just some number of times that it will be skipped in the process queue. Since you got to always execute one process it is impossible this way then to sleep until time runs out. SO for example, if process one executes sleep 2 and process two is the only other running process, it goes, 1 (goes to sleep) 2 (1 is skipped) 2 (1 is skipped) 2 1. If say two executed a sleep 1 it might go: 1 (goes to sleep) 2 (executes sleep 1) (1 is skipped) (2 is skipped) (1 is skipped) 2 1. No loss of processing time of course, only big change in process order. Now the real questrion:until other changes are made and big programs become more feasible, who'd wnat to use this when you could be bombing? From: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) Subject: Re: KotH suggestions Message-ID: <1992Jul30.041652.1273@unlv.edu> Date: Thu, 30 Jul 92 04:16:52 GMT In article <1992Jul30.024344.286@cs.yale.edu>, hastings-matthew@CS.YALE.EDU (Matthew Hastings) writes: ) Yes, I am in favor of a test line. I dont like the hill changes that ) occur with test programs. Here is another idea though: only record ) scores against programs currently on the hill (so challengers which ) don't get on have no effect [this change would probably hurt Flash Paper 3.7, ) BTW]). Also, permit a program to contain a ;kill line that ;kills itself. ) So... if you want to test, just kill yourself, and it doesn't count for ) other programs. I think that would be the best solution. I had thought about that while I was off the net, but had forgotten. The MAIN reason I thought that this would be an improvement is this 1) A new program, in order to make the hill, has to score high against the best programs. BUT 2) An old program increases it's score every time a buggy program is submitted. Or how about all the 0-line programs that are submitted to kill a program or to peek at who is on the hill. I'm pretty sure these raise the scores of the programs on the hill. Every time I submit a program now, I tweek the constants so the new version will trounce the old version (pretty simple to do if you understand my X-Hill programs). I think this is a better solution that what I suggested, because it fixes this problem as well as the "test program" problem. I do think the kill-self line should be different, rather than just changing the way the current kill command functions, because I've seen people submit a newer program with the same name as the old one, and kill the old one at the same time. -- Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Twill Message-ID: <1992Jul30.041916.6694@samba.oit.unc.edu> Date: Thu, 30 Jul 1992 04:19:16 GMT Well, it looks like I still have a few surprises left after all. :-) Twill entered KotH at #1 and seems to be swapping off with FlashPaper at the moment (except for it and Crimp 2's accidental deletion due to a KotH "feature" which Bill tells me he will hunt down and ;kill :-) ) Here is the code to Twill. Basically it is a dwarf which bombs with a mov Date: Thu, 30 Jul 92 05:26:22 GMT Well, it would seem that 5 of the dozen ideas I had while out with the national guard are paying off. Here's a quick description of each of the programs I have currently, or recently, on the X-Hill. Rolling Thunder: A basic mod-2 bomber, it bombs through memory, then copies itself down and continues bombing. What makes it effective is that it bombs only a small area at the far reach of the write limit. this has the effect that against a slow moving target, Rolling Thunder will hit the target almost as soon as the target could hit back. Thunder Run: Starts 2 Rolling Thunders, going in opposite directions. Weaker against vampires, but does better against DAT bombers, since once you kill one, you then have to worry about one coming from the other direction. Lance: The first in the weapon series, it creates a small 2-instruction lance out 200-and-some-odd ahead of itself, and uses that to bomb the 250 locations ahead of that, basically bombing before it can be hit. It does a mod-6 bombing pattern, dropping a bomb in the -200 to -500 range every 4 cycles, and dropping a bomb ahead every 8 cycles. it then copies itself just above the area it cleared, and continues. Halberd: Similar to Lance, but bombs mod-6 with a JMP PIT instruction for 2 passes through memory, then switches to DAT , killing the pit with it's first dat bomb. Katana: My first X-Hill scanner, it doesn't use a cooperating process like the last two, it just rolls through memory looking at every 5th cell (should change that to every 6th, so that with wraparound and eventually bomb mod-2), and bombs anything it finds. It slows down for decoys and the like, but in clear memory it runs at over twice the speed of light. As each of these are pushed off the hill, and I can improve them no more, I'll be posting the source code to each. Probably even before then, in some cases. -- Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu From: eric@Turing.ORG (Eric Prestemon) Subject: Re: KotH suggestions Message-ID: <1992Jul30.132532.25687@murdoch.acc.Virginia.EDU> Date: Thu, 30 Jul 1992 13:25:32 GMT In article <1992Jul30.041652.1273@unlv.edu> maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) writes: >In article <1992Jul30.024344.286@cs.yale.edu>, hastings-matthew@CS.YALE.EDU (Matthew Hastings) writes: >) Yes, I am in favor of a test line. I dont like the hill changes that >) occur with test programs. Here is another idea though: only record >) scores against programs currently on the hill (so challengers which >) don't get on have no effect [this change would probably hurt Flash Paper 3.7, [stuff deleted] >I think that would be the best solution. I had thought about that while I was >off the net, but had forgotten. The MAIN reason I thought that this would >be an improvement is this > > 1) A new program, in order to make the hill, has to score high > against the best programs. > > BUT > > 2) An old program increases it's score every time a buggy program > is submitted. Or how about all the 0-line programs that are submitted > to kill a program or to peek at who is on the hill. I'm pretty sure > these raise the scores of the programs on the hill. > I was going to reply by mail, but since 2 people posted this misconception, (which I have publicly stated also) I figure this should be posted. The scores of the hill are based only on the 21 fighters that appear on the list. Long-lasting programs do not gain an advantage. Trust me, I know. I have had programs stay between 18 and 20 for a long time. =) Their scores didn't go up as time went on (unfortunately). -Eric Chairman, Committee for a Kill-If-Higher Line. -- Eric Prestemon (ecp2z@virginia.edu) "Jesus saves! Gretzky steals! Gretzky scores!" From: AZNXS@ASUACAD.BITNET Subject: Re: KOTH Suggestion Message-ID: <92212.092307AZNXS@ASUACAD.BITNET> Date: 30 Jul 92 16:23:07 GMT 1 vote for ;test 1 vote for the new ;kill /* what do you think of the name ;kill+ Nandor. From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: A Redcode Instruction Idea Message-ID: <1992Jul31.000242.18672@vlsi.polymtl.ca> Date: Fri, 31 Jul 1992 00:02:42 GMT maniac@cleanhead.cs.unlv.edu (Eric J. Schwertfeger) writes: : I was just thinking about the one thing that inhibits most of : my more complicated wariors, and it occured to me that what : I want is a "Sleep" instruction. I'm all for this. This seems like the right counter-balance to the spl instruction. Can't think of any offensive for it right now, but I'm sure someone will... (oups... just thought of one :). -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca