From: andy@extro.ucc.su.OZ.AU (Andrew Miehs) Subject: Is there an FTP site for cellular automata software and info? Message-ID: <1993Feb2.090315.11465@ucc.su.OZ.AU> Date: Tue, 2 Feb 1993 09:03:15 GMT Is there an FTP site for cellular automata software and info? -- +-------------------------------+---------------------------------------------+ | Andrew Miehs | | | Mail: andy@extro.ucc.su.oz.au | $$$ THIS SPACE FOR RENT $$$ | | NB: Don't call me andy! | | From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Was Corewar Jargon Message-ID: Date: Tue, 2 Feb 1993 16:27:56 GMT I am readying a new revision of our FAQ list right now, so this is a good time to drop me your updates to the jargon section. In particular, I am looking for brief definitions (possibly with code example) of the following terms: imp :-) imp ring imp spiral imp gate [and whatever else] Secondly, the redcode source files at soda are pretty ancient and don't include any of the new breed of warriors posted here. Also, postings from this newsgroup no longer seem to be archived at soda. So, if you have a good collection of warriors posted here (preferably with the authors description intact but commented out), mail me so we can pool and put together a newsgroup-warriors.tar.Z, regularly updated and available for FTP at soda. This would probably flatten the learning curve for beginners considerably. (Scott, I believe you had a fairly complete collection?) -Stefan (stst@vuse.vanderbilt.edu) From: dboese@spartan.ac.BrockU.CA (Darcy Boese) Subject: Official NetHack 3.1 for PC Message-ID: <1993Feb3.134421.29635@spartan.ac.BrockU.CA> Date: Wed, 3 Feb 1993 13:44:21 GMT I managed to pin down that 'Y' bug for the official version for the PC... it only happens when I run the program on the department's 486's but not when run on 386's... From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Valentine Tournament 1993 Message-ID: <1993Feb3.154739.7572@oucsace.cs.ohiou.edu> Date: 3 Feb 93 15:47:39 GMT The Valentine Tournament is now in my hands... (look out...) :-) Since the tournament was started almost one year ago, and so much has happened since then in the ways of code development, I chose to can the old tournament and start up a new one. ATTENTION: Valentine Tournament 1993 I hereby give (nearly) two weeks announcement of the next official Core War Tournament. Double-elimination will be used to determine who the final victor will be. Each round will give the authors a chance to submit a new warrior or use the old warrior to battle in the next round. If a new warrior is not submitted before the next round, then the original warrior will be used. In cases where a round ends in a tie, then one week will be given for those authors to either submit new warriors or use the original warriors for the tie-breaking round. If at the end of this round a tie still exists, then I will play the two warriors again until a winner is decided. (This is done to prevent any delays in the rest of the tournament.) Each round will take place exactly two weeks after the previous round. The authors can either submit a new warrior or use the original warrior for the upcoming round. Warriors that lose their first battle will go into the loser's bracket of the tournament, and will eventually be given a second chance to battle the winner for victory. So, prepare your warriors and send them in! All warriors should be sent to "sadkins@ohiou.edu". Don't wait until the last minute! I would like to see a good turn out. Currently, I will place a one warrior maximum limit for each author, but this may be lifted if the turn out is low. Good luck! Scott Adkins sadkins@ohiou.edu (A copy will be sent to all the original participants of the last tournament.) -- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: wangsawm@prism.CS.ORST.EDU (W. Mintardjo) Subject: Newsgroup-digest maintenance Message-ID: <1kpjrpINN7v4@flop.ENGR.ORST.EDU> Date: 3 Feb 93 23:18:17 GMT I think it is not difficult for me to collect, sort and upload all the posted articles related to corewar to soda. Well? Mintardjo W From: pk6811s@acad.drake.edu Subject: Re: Newsgroup-digest maintenance Message-ID: <1993Feb4.083143.1@acad.drake.edu> Date: Thu, 4 Feb 1993 14:31:43 GMT > I think it is not difficult for me to collect, sort and upload all the posted > articles related to corewar to soda. > > Well? > > Mintardjo W I think that's great. Do you, or does anyone have a complete record of rec.games.corewar postings since the last upload to soda? I saved a few, but not all of them. And I just found out that our local news systems manager only maintains the last three calendar-days worth of postings :( Paul From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Valentine Tournament 1993 --- Rule update Message-ID: <1993Feb7.013432.26939@oucsace.cs.ohiou.edu> Date: 7 Feb 93 01:34:32 GMT Valentine Tournament 1993 ------------------------- Well, it appears that I have left out one minor detail about the rounds of the tournament. I have currently decided that each round will consist of two battles. Warrior A will be located at some random location R1. Warrior B will be located at some random location R2. In the first battle, Warrior A will be the first warrior to execute, followed by Warrior B. When this battle is over, I will reverse the roles and play again. So, in the second battle, Warrior A will be located at R2, Warrior B will be located at R1 and Warrior B will be the first warrior to execute. The method described above is similar to the method used in the last Valentine Tournament. If anyone has other suggestions on how to play each round, I will be more than happy to consider them... I have already received one suggestion that maybe each round should consist of 100 battles between the two warriors. This would reduce the chances of luck and increase the chances of performance, which might be more desirable... :-) So, what do you think? Use the 2 battles per round method or some other method? There is still a little time to decide... Now, for those who are interested: The Valentine Tournament 1993 begins February 14, 1993. I will accept entries up through that day and will begin the tournament later that night when it looks like I will not be receiving any more entries. I currently have set a limit of one warrior per contestant, but this may change if there are not enough entries. Please, please please... send in your warriors! It does *not* hurt to participate in tournaments! In fact, it can be quite exciting! If you do not have a warrior of your own, then submit something... anything... such as imp or dwarf! This will be nothing like you have experienced before... (i.e. it isn't like KotH), unless of course you *have* already experienced, but then that makes me a lier... (oh well...) Send all warriors to: Scott Adkins sadkins@ohiou.edu For a copy of the tournament rules, send me mail and I will send you a copy in a rather short time period... (so, I am online all day, heh heh, I *am* a bum...) :-) Catch you later! Scott -- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: A Call for Warriors! Message-ID: <1993Feb7.014347.27588@oucsace.cs.ohiou.edu> Date: 7 Feb 93 01:43:47 GMT ATTENTION: Petition for Warriors! I am collecting as much warrior code as possible and preparing a library to placed on ftp for your use and enjoyment! If you have a warrior that you would like to see in the library, then please mail them to me! Mr. Strack has been kind to help me out in this project and give me the opportunity to finish this major undertaking that I began some time ago. For all of those Core War Veterans: If you have ever posted a warrior to this newsgroup in the past, please mail those warriors to me... it is important to have an official, clean copy of the warriors to be placed in the library. I will most grateful for your contributions! It is time that we have a decent library of warriors to aid us in our own development process. If you want to contribute to this library, then send your warriors to the following: Scott Adkins sadkins@ohiou.edu All warriors sent to Mr. Strack will be forwarded to me, so if you have already mailed him a copy, then you do not need to mail me a copy. Thanks, Scott -- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Yet another Valentine Tournament 1993 Rules update! Message-ID: <1993Feb7.025431.4306@oucsace.cs.ohiou.edu> Date: 7 Feb 93 02:54:31 GMT Hmm... I must be getting old or something... The size of the core will be the standard 8000. Each battle will last a total of 100,000 cycles. ICWS '88 rules will be used. Equates are fully functional, parenthesis are permitted, order of precedence is enforced. I higly suggest that the A-field and the B-field be separated by a comma, since this will make exactly what you write very clear. The comma is not required, but higly recommended. If I missed anything, please let me know... Scott Adkins sadkins@ohiou.edu -- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 7 Feb 1993 06:02:19 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1993/02/04 Version: 2.0 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 67 2. Is it Core War or Core Wars? 80 3. Where can I find more information about Core War? 88 4. Core War has changed since Dewdney's articles. Where do I get 106 a copy of the current instruction set? 5. What is the ICWS? 120 6. What is TCWN? 130 7. How do I join? 138 8. Are back issues of TCWNs available? 163 9. What is the EBS? 179 10. Where are the Core War archives? 195 11. Where can I find a Core War system for . . . ? 212 12. I do not have ftp. How do I get all of this great stuff? 229 13. I do not have access to Usenet. How do I post and receive news? 236 14. When is the next tournament? 247 15. What is KOTH? How do I enter? 256 16. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 358 17. How does SLT (Skip if Less Than) work? 370 18. What does (expression or term of your choice) mean? 382 19. Other questions? 508 --------------------------------------------------------------------- Q 1: What is Core War? A 1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 The Redcode language has changed somewhat since; see Q 4. --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (soda.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q10) --------------------------------------------------------------------- Q 5: What is the ICWS? A 5: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). --------------------------------------------------------------------- Q 6: What is TCWN? A 6: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 7: How do I join? A 7: For more information about joining the ICWS (which includes a subscription to TCWN), contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current dues are $15.00 in US currency. If you wish to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please send it to Mark A. Durham Editor, The Core War Newsletter 18 Honeysuckle Terrace Spartanburg, SC 29307-3760 email: durham@cup.portal.com ---------------------------------------------------------------------- Q 8: Are back issues of TCWN available? A 8: Back issues of TCWN (up to Winter 1991) are available from AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 or contact William R. Buckley at xwbuckley@fullerton.edu. Prices are unknown at this time, but should be around $5.00 (the original cover price). More recent issues can be found on soda.berkeley.edu (see 10). --------------------------------------------------------------------- Q 9: What is the EBS? A 9: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994. Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- A10: Where is the Core War archive? Q10: 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. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q11: Where can I find a Core War system for . . . ? A11: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are Unix X-Window, IBM PC-compatible (sorry, no systems specifically designed for MS-Windows yet), Macintosh, and Amiga Core War systems available there. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than soda.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. ---------------------------------------------------------------------- Q12: I do not have ftp. How do I get all of this great stuff? A12: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. ---------------------------------------------------------------------- Q13: I do not have access to Usenet. How do I post and receive news? A13: A rec.games.corewar-specific server is in the works. Contact Jonathan Roy (faf@halcyon.com), Vice President of the Free Access Foundation, for more information. If you somehow receive rec.games.corewar but just can't post, you can email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q14: When is the next tournament? A14: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. ---------------------------------------------------------------------- Q15: What is KOTH? How do I enter? A15: King Of The Hill (KOTH) is an ongoing Core War tournament available to anyone with email provided by William Shubert (wms@iwarp.intel.com). You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". 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 daemon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives in an hour, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. MORE ON KOTH COREWAR IMPLEMENTATION Core size: 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 Programs are guaranteed a 100 instruction block (inclusive of their warrior's instructions) without overlapping their opponent. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Rule variants for "eXperimental" corewar: The same as above but use ";redcode-x" to start your program. Your program will be entered into a second tournament with slightly different rules. The rules are: - All addressing modes are allowed with all instructions. - There is an additional addressing mode, called "postincrement". To use it try an instruction like "mov >5,6". - The maximum write distance is 250 instructions. That is, every time your program tries to modify memory, the address is checked; if it is more than 250 instructions from the process doing the modify, then memory is left unchanged, but the instruction continues as normal. - A tie is not declared until 150,000 cycles per program have elapsed. KotH runs on any Unix system with an X windows interface. The source code to KotH is available by email from William Shubert. Write to him at (wms@iwarp.intel.com) for a copy or get it by anonymous FTP from soda.berkeley.edu in the pub/corewar/systems directory. ---------------------------------------------------------------------- Q16: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A16: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. ---------------------------------------------------------------------- Q17: How does SLT (Skip if Less Than) work? A17: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q18: What does (expression or term of your choice) mean? A18: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, Date: 7 Feb 93 19:15:53 GMT A problem seems to have developed with the White Pages service here at this University. In the last day or so, my email address "sadkins@ohiou.edu" is no longer being accepted! So, for everyone who wishes to send me email, with regards to warriors, tournament entries/questions, etc, then reply to the following address: Scott Adkins sadkins@bigbird.cs.ohiou.edu I have had several people already mention this problem to me, and in each case, they managed to get the correct address from my mail header (I think). In any the case, please start using the above address. Valentine Tournament 1993 ------------------------- Yet another rule update. I am using 64 processes per battle. Who knows, I have still probably left out something important... but at least I am not doing anything really unusual with the tournament. 8000 core size, 100000 cycles, 64 processes, 100 max line length. I am also getting requests to use something larger than 2 battles per round. So, I will be more than likely changing this to some larger number. I would like to hear more on this subject before deciding on a final number of battles per round. I may also change the time intervals between each round. It is currently 2 weeks between each round with the time in the middle being used for tie breaking battles. I will probably be changing this to just one week rounds and fighting the battles until somebody wins... no ties. I would like to here something about this as well. I am starting to get entries! So, be sure you join the fun as well! :-) Tournament Deadline is February 14, 1993. Scott Adkins sadkins@bigbird.cs.ohiou.edu -- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Valentine Tournament 1993 -- Official Rules! Message-ID: <1993Feb9.035542.8854@oucsace.cs.ohiou.edu> Date: 9 Feb 93 03:55:42 GMT Valentine Tournament 1993 --- Official Rules Each contestant will be allowed to submit one warrior for the first round of the tournament. The deadline for these warriors will be on February 14. If you would like to participate in this tournament (and I hope you will), then send your warrior to the following email address: Scott Adkins sadkins@bigbird.cs.ohiou.edu The tournament itself will be a standard double-elimination tournament. Each warrior will be paired off with another warrior. The winners of these battles will progress to the next round where they will be paired against the other winners of the round. The losers will be given a second chance to fight in the loser's bracket. If any warrior loses for the second time, then it will be eliminated from the tournament. In the end, there can only be one warrior to win it all. Could it be yours? Just for a little extra flavor, this tournament will emphasize the authors of these warriors, and not the warriors themselves. At the end of each round, each contestant will be given the code to the warrior they had just fought. In addition to this, they will be told who their opponent will be in the next round *and* will be given the code to the warrior that opponent used in the previous round. With this bit of knowledge, each contestant should be able to prepare for the next round. The first round will begin on February 14, 1993. Each round will occur exactly one week after that previous, thus February 21 will be the next round, and February 28 will be the round following that. Once the results of a round has been given to each contestant, then they have the remainder of that week to prepare for the next round. They may optionally choose to use the same warrior, or they may choose to submit a new warrior to be used instead. If I have not received any new warriors from each contestant, then I will use the same warrior for the next round. I will try and mail out the results of each round as soon as I can, in order to give as much time as possible to the contestants to prepare for the next round. Each round will be composed of 100 battles between two warriors. Half of these battles will be conducted with the first warrior executing first, and the other half of the battles will be conducted with the second warrior executing first. In addition to that, I will ensure that if the first warrior starts at location X, and the second warrior starts at location Y, then when it is time for the second warrior to execute first, then I will switch the locations as well. This means that the second warrior will start at location X, and the first warrior will start at location Y. All memory locations will be generated randomly (for the first half) and there are no restriction placed on how close or how far apart the warriors will be when they first start out. Scoring will be the number of wins multiplied by three added to the number of ties (3 * wins + ties). The warrior with the highest score will become the winner of that round between those two warriors. The losing warrior will either be entered into the loser's bracket or will be eliminated from the tournament if it was already in the loser's bracket. (Note, just because I say the warrior is being entered into the loser's bracket or a warrior is being eliminated does not mean much. It is really the author who is getting moved to the loser's bracket or getting knocked out of the tournament. Remember, the author may choose to use different warrior for each round... you never know!) In case of ties, which means the scores were equal, then I will replay that set of battles (all 100 of them) until I finally get a warrior that wins over the other. I do not want to slow down the progress of the tournament as a whole due to the fact that a couple of warriors insist that they can't beat each other! Each warrior may be no longer than 100 lines long. I will be using the ICWS '88 rules, which means that the core will be intialized to "Dat 0, 0" instruction, even though this is an illegal instruction in your redcode programming. Each program will be allowed a maximum of 8000 processes. The size of the core will be 8000 memory locations. As I said before, each program will be loaded randomly into the core with no restrictions on how close or how far apart they will be. The assembler that I will be using is one that I wrote. It supports full use of the EQU pseudo-instruction. It also supports full use of parenthesis and order of precedence of operations. Commas are not necessary between operands, but their use is higly recommended (since, if you say "dat -1 -1", it will be interpreted as "dat -2" and not "dat -1, -1"). Well, I think that is it. The rules are not really that complicated, but they are quite long. This is necessary to cover as many areas as possible in the tournament. After a round completes, I will post a summary of that round to the newsgroup, send a summary to each individual contestant, and also send a summary of each contestant's battles (just their warrior and their opponent's warrior) to them as well. Also note that I will not release any warrior code to public domain until after the tournament is over. The code that is released will be to the individual contestants under the guidelines that I have described above. If there are any questions at all regarding the tournament, then please feel free to contact me. I will put my email address below, since the top of this document is so far away... So, what are you waiting for? Send in *your* warrior today! Scott Adkins sadkins@bigbird.cs.ohiou.edu -- Scott W. Adkins Internet: sadkins@bigbird.cs.ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: adb2y@faraday.clas.Virginia.EDU (Allen David Boozer) Subject: Newbie questions! Message-ID: <1993Feb9.210801.22688@murdoch.acc.Virginia.EDU> Date: Tue, 9 Feb 1993 21:08:01 GMT Hi, all! I just started playing with Core Wars a few days ago. I have a few newbie questions: 1) The best corewars simulator I have found so far is Corewar Pro 3.0. Is this what you all use? 2) Here the latest verion of my first serious warrior: ---- Cut Here ---- ;redcode ;name Split-pit ;author David Boozer ;Strategy Bomb core with JMP's to a "pit", then clear the core. Pit ;Strategy causes opponent to clear core forwards, while clear core ;Strategy routine clears core backwards. loop: mov ptr, @ptr ; Bomb core with JMP instructions sub info, ptr djn loop, #421 mov #421, -1 djn -3, #6 jmp clear ; Clear the core with DAT's dat #0 ; 0's used to hide from scanners dat #0 dat #0 dat #0 dat #0 ptr jmp trap, #0 ; JMP instruction used to bomb core dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 info mov #-19, <19 ; Spacing of bombs dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 dat #0 clear mov dat0, this is just a test! From: pk6811s@acad.drake.edu Subject: Charon v8.1 Message-ID: <1993Feb11.095117.1@acad.drake.edu> Date: Thu, 11 Feb 1993 15:51:17 GMT Sefan and I (and Jules in a posthumous kind of way) would like to present: ;redcode ;name Charon v8.1 ;kill Charon ;author Cisek,Strack,Kline ;strategy creation date 4/22/92 ;strategy v2.0 4/22/92 total code overhaul ;strategy mod 3 cmp scan with optimal step, new deadly trap (SPL 0, JMP -1) ;strategy v3.0 5/3/92 integrated with Stefan Strack's Echo (much smaller) ;strategy v4.0 5/8/92 [pretty much a failure] ;strategy v5.0 5/12/92 same as 3.0, new clear core routine ;strategy v6.0 6/11/92 finally moved off axis (v5.0 was getting slaughtered ;strategy by programs copied across the axis) ;strategy v7.0 7/6/92 2 instructions smaller, different constants, ;strategy linear decrement triggers clear core. ;strategy [no longer hits itself to start clear core] ;strategy v8.0 12/22/92 now forward-scans for an extended time ;strategy using step-size that kills slow-moving imps ;strategy also protecting 3 lines against decrement ;strategy v8.1 1/25/93 new step-constants ;strategy Charon is the >original< spl/jmp bombing cmp scanner. ;strategy It scans using an off-axis CMP-scan, bombs with the spl/jmp ;strategy combination (thus slowing the enemy down), and eventually ;strategy clears the core with dats. ;strategy Submitted: @date@ STEP equ 68 ;scan constants: DIST equ 34 ;small, so can be reused in core clear DJNOFF equ decr-DIST FIRST equ DJNOFF+149 ;optimal offset to DJN train attack add switch,@compptr ;switch A- and B-fields mov jump,@comp compptr mov split, Date: Thu, 11 Feb 1993 15:53:09 GMT Here are a couple of warriors that I don't believe I have published before. Neither was successful on the Hill, but both illustrate some interesting principles. The first is Antivamp, which traces pit-trap snares back to their source. It is very effective against Sucker 4 and Twilight Pits, but otherwise a dud. But I have included the technique in Imprimis, Emerald, and Eeek to get some cheap points against S4 and TP. The second is Newscan, which is a wacky, cmp-scanning pit-trapper. Newscan uses a non-fixed distance between the a and b-fields of the cmp and cannot be defended against by reflections. Unlike the Charon and Agony-based cmp-scanners, which use 'cmp a,a+dist', Newscan uses 'cmp a,-a'. It first attacks the b-field location by moving a template jmp statement (jmp 3,0) and adding the cmp instruction to it. Then it attacks the a-field location by moving a different template jmp statement to a safe place, subtracting the cmp instruction from it, and moving that to wherever it then points. While Sucker 4 attacks one location every 3 instructions, Newscan searches 2 locations in every 3 and is therefore twice as fast. It also does not leave as many useless snares in core and can't be tracked back as easily by Antivamp. Unfortunately, Newscan is so large that it is spotted first by all the other cmp-scanners, and has a hard time against S4 and TP because of their very small size. ;redcode quiet ;name Antivamp ;kill Antivamp ;author P.Kline ;strategy traces snares back to pit-trappers avamp mov -2,<-10 sub @avamp, Date: Thu, 11 Feb 1993 19:25:07 GMT Newsgroups: rec.games.corewar Subject: Re: Charon v8.1 Summary: Expires: References: <1993Feb11.095117.1@acad.drake.edu> Sender: Followup-To: Distribution: Organization: Vanderbilt University School of Engineering, Nashville, TN, USA Keywords: In article <1993Feb11.095117.1@acad.drake.edu> pk6811s@acad.drake.edu writes: >Sefan and I (and Jules in a posthumous kind of way) would like to present: > >;redcode >;name Charon v8.1 > >Charon is a spl-jmp bombing cmp-scanner. It is the only scanner >on the Hill that relies completely on scanning/stunning/clearing >to win. * IT DOES NOT USE A GATE *. Well, Agony 3.1 uses the same principle and actually goes one step further: Charon v8.1 needs a <2667 in the B-field of its SPL/JMP bomb to muck up imps, whereas Agony clobbers them with a straight SPL 0,0 carpet (code soon). >For anyone who doesn't have a copy of Charon v7.0: > [..] > djn scan,<-5 ;mutagenize/distract/count-down to clear This must be an early test version of Paul's (which doesn't work BTW). The real Charon v7.0 has djn scan, Date: Fri, 12 Feb 1993 02:06:08 GMT Questions about corewars: Where can I get the latest and best unix corewars? soda.berkeley.edu? Where can I get the latest and best dos corewars? Is there a corewars program that does that neat color thing or whatever, just so you get a visual image as the game progresses? Does DJN work in most corewars versions? The IBM one I have unfortunately did not support DJN so I couldnt do one program. What will this do? Nothing? MOV #0 #-5 How exactly does PCT work? Does a subverted program keep executing? What exactly does that mean? Its executing another programs codes? I dont think I get these tournament treatment of subverted... suppposedly if you just subvert your opponent that is a tie (or is that just the way it was orginally done?) So a bprogram is destroyed whenb it tries to execute an unexecutable command? (such as a 0 bomb) while subverted means its still executing only another programs commands? How exactl.y is this treated? What are the newer commands that i've missed in the past year or two? I am only really aware of ADD,CMP,DAT,DJN,DJZ,JMG,JMP,JMZ,MOV,PCT,SPL,SUB,SWP From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: corewars! Message-ID: <1993Feb12.160419.22047@oucsace.cs.ohiou.edu> Date: 12 Feb 93 16:04:19 GMT In article c115086@cs.UAlberta.CA (Papp Denis Richard) writes: >Where can I get the latest and best unix corewars? soda.berkeley.edu? >Where can I get the latest and best dos corewars? Yeah, soda is the place to look for that stuff... as well as for documentation on how to play the game... I will putting out an updated library of warriors here in the next week, so that you and others can use them for your development process... Also, I will put out a copy of my new deluxe package in the next couple of days (unfinished, but close enough) for people to at least use... it won't have all the fancy display stuff yet (no xwindows or pc graphics) but it will work for both a pc and unix! It will be the same program I will use for the Valentine Tournament! >Does DJN work in most corewars versions? The IBM one I have unfortunately >did not support DJN so I couldnt do one program. DJN is part of the standard and is supported by any corewar program that is compatible with the standards. (Most of them are compatible these days, at least the ones at soda.) >What will this do? Nothing? MOV #0 #-5 This instruction is not legal under ICWS'88, but is legal in the extended rules. In the extended rules, it is interpreted as such: Since #-5 is immediate mode, it will treat it as memory location 0, the current location. It will then move the a-field to the b-field of the instruction... MOV #0, #-5 --> MOV #0, #0. >How exactly does PCT work? This instruction is only available in the extended rules, and only some of the systems out there will support it... (Mine does!) There is still a little debate on how it exactly works (well, how far it will work, that is). It essentially allows you to protect a memory location from one modification attemt... when something (including your own program) attempts to modify a protected instruction, the protection is removed and the instruction remains umodified. The next modification attempt will succeed, however, unless the instruction was re-protected before that point. >Does a subverted program keep executing? What exactly does that mean? Its >executing another programs codes? I dont think I get these tournament >treatment of subverted... suppposedly if you just subvert your opponent >that is a tie (or is that just the way it was orginally done?) >So a bprogram is destroyed whenb it tries to execute an unexecutable command? (such as a 0 bomb) >while subverted means its still executing only another programs commands? >How exactl.y is this treated? Subverted programs mean very little according to the current rules. The only way that a game will end is either when the time runs out and nobody has won (then it is a tie) or all of the processes of all but the last program were killed off (by executing a DAT instruction). Subverted programs will continue to run unless they happen to execute a DAT instruction, in which case they will surely die. >What are the newer commands that i've missed in the past year or two? I am >only really aware of ADD,CMP,DAT,DJN,DJZ,JMG,JMP,JMZ,MOV,PCT,SPL,SUB,SWP DJZ is not supported in any of the standards (it is a left over from the original rules of the game back in 1984 and 1985). JMG is not supported as well. PCT is supported only in the extended rules. SWP is usually referred to as XCH and is also only supported in the extended rules. The instructions that are supported for the ICWS'88 standard rules are as follows: Dat, Mov, Add, Sub, Jmp, Jmz, Jmn, Djn, Cmp, Slt, Spl Also, for the extended rules, I implemented XCH and PCT. Other instructions that are being considered include MUL and DIV. There has been talk about supported other Jmp and Cmp like instructions, but it isn't really going anywhere in that regard. Also note... even though a system might support extended instructions, it does not mean that a system will name it the same, use the same syntax, or even support it at all... (For instance, I support XCH and PCT only, and no other extra instructions). Hope this will help. I suggest looking at the documents directory on soda for more information. ftp soda.berkeley.edu and change to the /pub/corewar/documents directory. For the corewar systems, they are in /pub/corewar/systems directory. Good luck! Scott -- Scott W. Adkins Internet: sadkins@bigbird.cs.ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: parrinel@ux1.cso.uiuc.edu (Chris Parrinello) Subject: Corewar for DOS Message-ID: Date: Fri, 12 Feb 1993 16:28:13 GMT Where can I find a ICWS compatible version of Core War for DOS computers? I've found a version that is kept in the comp.sys.ibm archives but it doesn't say if it is compatible or not. I'm new at Core War and I am very interested in playing. Thanks alot! Chris From: trav@yaya.WPI.EDU (Travis Charles Korthas) Subject: test Date: 12 Feb 1993 23:19:49 GMT Message-ID: <1lhbal$iel@bigboote.WPI.EDU> sorry just a test -- ****************************************************************************** _______ Travis "FOURTYoz" Korthas (_______) | | Date: Saturday, 13 Feb 1993 17:58:12 MST From: Message-ID: <93044.175812AZNXS@ASUACAD.BITNET> Subject: systems on soda I'm going to upload the following file to soda , into the systems directory as a readme.1st file . If your system is not included here please send me a note. Nandor. The following is a short description of the Corewar systems on soda.berkeley.edu . This is not a full list. Please add the description od your system to this list, or send it to me to aznxs@asuacad.bitnet ========================================================================== CoreWar Pro version 3.02 is now available by anonymous FTP from soda.berkeley.edu as pub/corewar/{incoming|systems}/corwp302.zip This is an extended ICWS'88 Core War system for PC-compatibles with a windowing and menu-driven interface and strong debugging support. What's new: A new indirect addressing mode, post-increment indirect (">"). A number of non-standard instructions are no longer supported. Since pre-decrement and post-increment indirect addressing together can be used to implement a "software stack", the dedicated stack-instructions (GSB, RET, PSH, POP, SSZ) are no longer needed and were thus eliminated. The process control instructions SSP and RLS were abandoned, because SSP has overwhelming offensive potential (pointed out by several people on rec.games.corewar). The two operand version of SPL (Split with descendant count) has been debugged and renamed to SPC to avoid confusion with ICWS'88 SPL. The descendant_count(on/off) switch is therefore superfluous. The B-operand of MOV, ADD, SUB, RND and EXC can now be immediate for compatibility with ICWS'86 programs. An inconsistency in the order of operand evaluation in ADD and SUB instructions has been fixed. Interface: program prompts now allow editing the default string (thanks to Per Pilse for the modified ioreadln library module). Your feedback is welcome. Enjoy, Stefan (stst@vuse.vanderbilt.edu) ============================================================================ koth: For Unix/X11 systems. Features a graphic interface including dynamic disassembly, variable execution rates, and multiple programs at once. Also runs without X11, but then no output other than wins/losses is provided. This is the program used in the KotH tournament. -Bill (wms@ssd.intel.com) ============================================================================ Thought some of you might find this useful: I just finished porting Bill Shubert's King of the Hill corewar program to DOS (I don't have access to X-Windows and, besides, my boss doesn't like games at work :-( ). All switches are implemented (including "experimental hill" of course), except for display slowdown. I have uploaded the DOS executable to soda.berkeley.edu as pub/corewar/{incoming|systems}/kothpc.zip Length Method Size Ratio Date Time CRC-32 Attr Name ------ ------ ----- ----- ---- ---- ------ ---- ---- 3004 Implode 1790 41% 02-10-92 00:52 3dfce260 --w README 20353 Stored 20353 0% 02-10-92 04:46 8e980c38 --w KOTH.EXE ------ ------ --- ------- 23357 22143 6% 2 Mail me for a uuencoded copy if you don't have FTP-access. Enjoy, Stefan (stst@vuse.vanderbilt.edu) =========================================================================== MADgic41.lzh is Version 4.1 of The MADgic Core: Core War for the Amiga Copyright 1992 Mark A. Durham. It is freely distributable in its complete archived form. MAD4041.lzh is an upgrade for those who already have version 4.0 of The MADgic Core. Please, under no circumstances should anyone redistribute MAD4041.lzh! It is only for the convenience of those who have 4.0 and access to soda.berkeley.edu. The archive should be decompressed to an empty floppy disk to get the full effect of the system. It requires about 77% of an 880K disk. Mark A. Durham (MAD) Email: durham@ricevm1.rice.edu GEnie: M.DURHAM2 USmail: P.O. Box 301173 Houston, TX 77230-1173 ========================================================================== Mars88 is an ICWS'88 Core War system for PC compatibles with menu-driven user interface, high resolution ( every core location is visible ) core display, 3-panel disassembler, tasklist viewer, built in editor. It requires ega or vga for the core display and the dissassembler but otherwise works in text mode. 640 K RAM is highly recommended if you use the built in editor. Please send me your opinion, suggestion. Nandor Sieben aznxs@asuacad.bitnet ========================================================================== "Points" -- a public domain ditty by Scott Maxwell 23 March 1992 "Points" is a little program designed for use with Mark Durham's excellent Amiga Core War game, "MADgic Core 4.0." MADgic Core's associated tournament manager program produces its output in terms of how many battles a core warrior won, lost, or tied. While this information is useful, I wanted to be able to come up with a single number for comparing the programs. And so ... Points was born! To use Points, first redirect the tournament manager's output to a file. E.g., type TMARS >outfile tournament_file.tm Invoke Points on the output file by typing Points outfile You may redirect Points's output to a file, if you like. By default, Points assigns 3 points for a win, 1 for a tie, and 0 for a loss (I understand those values are fairly standard). However, you may choose different "weights," including non-integer values. See the usage text (by typing "Points" with no arguments) for more details. I release Points into the public domain with the following caveat: I hacked it together in a couple of hours, so don't expect it to be pretty. Also, I'm *not* responsible for bugs or anything else that might come of your choosing to use this program, including but not limited to fires, locust plagues, and the heat death of the universe. If you use Points, I'd appreciate your dropping me a note at CSMAXWEL@ECUVM1.BITNET or Scott.Maxwell@bbs.oit.unc.edu. Pretend you like it. The source is included (I used SAS/C 5.10b, but I imagine it's highly portable). I don't know why the executable is so fat; floating-point math, I guess. Enjoy. -- Scott Maxwell ========================================================================== From: andy@extro.ucc.su.OZ.AU (Andrew Miehs) Subject: core war tutorial WANTED Message-ID: <1993Feb15.070307.11381@ucc.su.OZ.AU> Date: Mon, 15 Feb 1993 07:03:07 GMT I'm looking for a good tutorial on core war STRATEGY. I have read plenty on how to program Redcode, but it doesn't give any hints as to how to program _successfully_. Have any of the big-time players taken the time out to write such a document? It'd be quite helpful for us newbies. -- +-------------------------------+---------------------------------------------+ | Andrew Miehs | | | Mail: andy@extro.ucc.su.oz.au | $$$ THIS SPACE FOR RENT $$$ | | NB: Don't call me andy! | | From: danielw@hpopd.pwd.hp.com (Daniel Wink) Date: Mon, 15 Feb 1993 13:50:17 GMT Subject: Newbie 2- Judgement Day Message-ID: <132850001@hpopd.pwd.hp.com> Yet another newbie ere... Can anybody please send me the ICWS '88 "ruleS" along with the tutorials mentioned in the FAQ Q.4? No access via ftp... Also, does anybody have documentation of the "extended" rules, or do these differ from implementation to implementation... Cheers...Martin ( using somebody elses account...) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Newbie 2- Judgement Day Message-ID: Date: Mon, 15 Feb 1993 20:12:23 GMT In article <132850001@hpopd.pwd.hp.com> danielw@hpopd.pwd.hp.com (Daniel Wink) writes: > >Can anybody please send me the ICWS '88 "ruleS" along with the tutorials >mentioned in the FAQ Q.4? > >No access via ftp... > Ever tried a mail server? mail ftpmail@decwrl.dec.com subject: reply connect soda.berkeley.edu chdir /pub/corewar/documents binary get tutorial.1.Z get tutorial.2.Z chdir standards get redcode-icws-88.Z quit >Also, does anybody have documentation of the "extended" rules, or do these >differ from implementation to implementation... > The only extended rules that have become a "standard by usage" are those of the experimental KotH (see the FAQ for more details). >Cheers...Martin ( using somebody elses account...) > -Stefan (stst@vuse.vanderbilt.edu) From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) Subject: Instruction execution question Message-ID: <84891@hydra.gatech.EDU> Date: 15 Feb 93 20:23:45 GMT I have a question concerning the exact order of instruction execution. How would the following code be executed? DJN <0,#2 Now I understand that the instruction gets fetched. Then the Amode decrements the core. Now does the DJN decrement affect the core memory or does it affect the instruction that has been fetched? It seems that it would affect the core memory. Therefore it would not take the jump. DJN <0,#3 Now this would result in a non-zero result so then the jump will be executed. But would it jump to 2 ahead or 1 ahead? How about: JMN <0,#1 I guess the main question is: Does the branching condition look at the fetched instruction if it is immediate mode? -- Wayne Edward Sheppard Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7804b Internet: gt7804b@prism.gatech.edu From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Valentine Tournament 1993 -- about Round 1 Message-ID: <1993Feb16.043558.25625@oucsace.cs.ohiou.edu> Date: 16 Feb 93 04:35:58 GMT Round 1 is done! :-) It has become obvious to me that I have a little more tweaking to do and a little more automation to do with my tournament package. I did a lot of work by hand (and a handy little script file), which I hope to avoid the next round coming up. The first round was quite interesting. There were a couple of programs that were neck and neck all the way up to the end! There also a couple of programs that just blew the opponents completely off the map! The order I arranged the opponents were based on the first come first serve basis. The #1 and #2 entries fought each other, etc. The losers of these battles will be placed in the Loser's bracket in order that they will have a second chance at the tournament. I am still putting together the summary and information files that I will be posting and sending out. I will hopefully have the results out sometime tomorrow... in any the case, the next round will start 7 days after the results are released... so no time will be lost. I had 16 warriors enter the tournament... it promises to be a good one. Stay tuned for more information! I will be back... Scott -- Scott W. Adkins Internet: sadkins@bigbird.cs.ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: ejensen@elen.utah.edu (Eric Jensen) Subject: Bugs? Message-ID: <1993Feb17.054707.24131@fcom.cc.utah.edu> Date: Wed, 17 Feb 93 05:47:07 GMT Several of the programs for the PC at soda seem to have irritating bugs, but maybe it's just my system or a single bit error somewhere. The program "DEBUG.EXE" which is a nice menu-driven MARS system by Stefan Strack (sp?) I think (who has several programs on the hill, I noticed. That Hill is a pretty tough place) The ESC key crashes the program and I have to reboot. Either in DEBUG.EXE or MARS88.EXE (i forget which one, sorry) there is a built-in editor that uses function keys for most operations. Apparently the program uses scan codes and my keyboard (AT 101-key) can't make the editor respond, and the only exit I can find (F7 doesn't work) is reboot. The program I have been using, because it seems to be the fastest, is C88V202.EXE, but this one also has a small problem. When in graphics (text-graphics, but battle-display anyway) mode, pressing "d" goes to the debugger. When running 10 rounds "C88 -r 10 dwarf imp" the display is not normally used to increase speed, but if you press the "d", it crashes, and (you guessed it) I have to reboot. It seems odd that _every_ program available would have bugs that I would find the first or second time using them, so I wonder if it an isolated incident. Does anyone else experience these problems? Downloading over a modem _could_ change a byte or two, but it probably wouldn't unzip (or un-lha) in that case. -ike, who hopes to appear on the Hill someday. -ike, who hopes his sad attempt at a tournament-class program won't be demolished in Valentine Tourny. From: un036316@wvnvms.wvnet.edu Subject: POST Newbie! Message-ID: <1993Feb17.123050.4963@wvnvms.wvnet.edu> Date: 17 Feb 93 12:30:50 EST I am just getting interested in corewars. I would like to find some documentation that would help me to get started. I would also like to get my hands on the software needed to create my own warriors on IBM compatibles. mr. bungle From: blanchs@yvax.byu.edu Subject: VMS Corewar? Message-ID: <1993Feb17.184248.1425@yvax.byu.edu> Date: 17 Feb 93 18:42:48 -0700 Does anyone know where I can get a Corewar system for VMS? Thanks! ------ Steven Blanch Email: blanchs@yvax.byu.edu From: estorman@uceng.uc.edu (Ernest Stormann) Subject: newbie Message-ID: Date: Wed, 17 Feb 1993 18:49:41 GMT Hello. Granted....I am a newbie, but I'm having immense trouble getting a warrior programmed. Is there any other tutorials besides the one on Soda? I would immensely appreciate any mail or postings. So far, I have a warrior that sits there....and sits, and sits.....and yes, just plain sits again. -Randall Flagg- -- ------------------------------------------------------------------------- | "I'm not dead, I'm metaphysically challenged." estorman@uceng.uc.edu| | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | From: wms@ssd.intel.com (William Shubert) Subject: Re: Instruction execution question Message-ID: Date: Wed, 17 Feb 1993 18:52:05 GMT gt7804b@prism.gatech.EDU (Wayne Edward Sheppard): >How would the following code be executed? > > DJN <0,#2 Under KotH, the whole instruction is read in; then the "<0" is evaluated, leaving "DJN <0,#1" in memory, then the "#2" read in earlier is decremented and written back (giving you "DJN <0,#1" again), then the jump IS taken because it was a #1 that was the final result. > DJN <0,#3 > >Now this would result in a non-zero result so then the jump will be >executed. But would it jump to 2 ahead or 1 ahead? It will jump 2 ahead since the value of "<0" will be evaluated as 2 before the #2 is decremented and written back to memory. >How about: > > JMN <0,#1 Same rules as above. It WILL jump. -Bill (wms@ssd.intel.com) From: wms@ssd.intel.com (William Shubert) Subject: Re: Instruction execution question Message-ID: Date: Wed, 17 Feb 1993 19:08:06 GMT I said: >gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) said: >>How about: >> >> JMN <0,#1 > Same rules as above. It WILL jump. Oops, sorry, I didn't look carefully enough. This WILL NOT jump because the "<0" decrements the "#1" before using it. -Bill (wms@ssd.intel.com) From: rmathews@zeus.calpoly.edu (Bob Mathews) Subject: Re: Bugs? Message-ID: <1993Feb17.210347.128620@zeus.calpoly.edu> Date: Wed, 17 Feb 1993 21:03:47 GMT ejensen@elen.utah.edu (Eric Jensen) writes: >It seems odd that _every_ program available would have bugs that >I would find the first or second time using them, so I wonder if >it an isolated incident. Does anyone else experience these problems? I have never been able to find a satisfactory (and non-X) MARS. Core Wars Professional is slick, but it becomes slug-bait when the process lists get long (like when someone hits a spl bomb). KothPC just crashes when this happens. The unix-curses implementations I've downloaded have been either non-ICWS or non-configureable. This has prevented me from ever really getting into the game. -- swehtam bob >WAUGH!< rmathews@oboe.calpoly.edu.and.spam here in the hall of heads, you look through the keyhole -tmbg M'YV0(`*."$BP8,$1"!$:7`@BH0*!#1 Date: Thu, 18 Feb 1993 17:25:49 GMT In article <..> andy@extro.ucc.su.OZ.AU (Andrew Miehs) writes: > I'm looking for a good tutorial on core war STRATEGY. I have read plenty > on how to program Redcode, but it doesn't give any hints as to how to program > _successfully_. Have any of the big-time players taken the time out to > write such a document? It'd be quite helpful for us newbies. > Gee, success seems to be so transient, how about hearing from someone who is just having FUN? :) Writing successful Redcode is a lot like writing successful poetry - you have to write volumes of stuff before you get anything good. You also have to read a lot; read and study every warrior you can find including the old ones. A lot of problems have been addressed and solved in the past, like imps and imp-gates. Then you have to watch hours of battles, preferably on an emulator with a core-display where you can see everything that's happening. Play pairs of warriors against each other dozens of times until you completely understand why one beats (or can't beat) the other. Then speculate on what change would be necessary to the losing program to make it more aggressive, or less vulnerable. You need to understand the strengths of the basic warrior-forms. Among these are: bomber - very fast,very small, kills stationary opponents cmp-scanner - moderately fast, small, kills replicating opponents b-scanner - very small, kills replicating opponents and larger scanners replicator - kills bombers, ties imps imp - difficult to kill, kills single-process opponents, ties a lot pit-trapper - very small, kills replicators and others as well All have their weaknesses also - being slower, larger, less aggressive, etc. These characterizations are subject to change with new developments, but seem to have held up over time. Some of the successful programs use combinations of forms to take advantage of their mutual strengths. It is very important to understand the power of 'magic' numbers. The most important of these are the optimal-pattern numbers, which efficiently bomb/scan the core. The ones published for coresize 8000 (by Nandor?) are: 3359 or 3039 mod 1 3094 or 2234 mod 2 3364 or 3044 mod 4 3315 or 2365 mod 5 2936 or 2376 mod 8 2930 or 2430 mod 10 if you need small numbers use: 73 mod 1 98 mod 2 76 mod 4 95 mod 5 If you want to experiment with other numbers, use a short testing program to see how well they pattern the core: start mov @start,start add inc,start jmp start inc dat #76 The size of your program is _very_ important, and here's why. A stone which bombs at 33% of c can hit every 100'th location in 240 cycles, and every 12'th in 2000. A cmp-scanner can scan them in half the time. Even if no one is using mod-100 and mod-12 patterns, they are approaching that kind of speed. If your program is 12 instructions or longer, you WILL be covered very fast. If your program is less than 12 instructions you will (sometimes) be missed a bit longer. Note that 12 is an example only, but somewhere around there is a break-point. If you can't make your program smaller, you could break it up into components and hide them around core. One thing that should not be overlooked is bombs or pointers that you create close to your active code - they can be attacked by scanners, and the fallout might affect your program. A useful approach to KotH is targeting a group of existing warriors. If you can identify a group with a common weakness, you can take advantage. For example, you might see a lot of cmp-scanners out there. Knowing that a fast bomber will beat them, you put one together with an optimal pattern number and a core clear and whammo! you are 20th on the Hill :) Then someone submits a paper warrior and off you go. Then you look at the report showing that you got massacred by all the imps and start thinking about how you can add a gate to your bomber to get a few more wins. Run a few dozen tests to get it right, post it, and now you are #18. Unfortunately adding the gate made you enough larger that the scanners are winning a few more (each!) so it's a tradeoff. At this point you make a choice to continue enhancing your bomber, or try something else. Both will be educational but I recommend the bomber since you have gained 'expertise' in bombing. Try different constants, research all the bombers you can find, see how they were used in combination with paper and imps as in Flash Paper, Smooth Noodle Map, Gamma Paper, Impression, Imprimis, etc. There will be programs that beat you 80% of the time - why? And is it one program or several that do that? Do not assume that a variation has been tried by anyone, and do not be surprised to find out later that it has. Testing fighters on your own machine is critical. Run lots of tests and watch them all the way to completion. When you make a change, do not assume anything about the effect - rerun your tests. Test against the best fighters you can get your hands on. If your program has multiple phases (ex: bombing and clearing) what is the effect of lengthening the first phase? The second? If you have multiple components, experiment with the spacing between them. It is very useful (and fun) to communicate with other participants. Most are helpful and will give advice. Some may not respond, usually because they have become otherwise-occupied. Feel free to post questions on rec.games.corewar, like: My Blasto program doesn't work on the Hill, how come?" blasto dat #2365 loop mov blasto,1000 add blasto,loop jmp loop Thanks in advance for your helpful advice, Courteous Newcomer and you will likely get a response like: Dear courteous, but naive Corewar participant, your Blasto program fails to work because you need to start the program at 'loop', not at 'blasto'. Just add the following line at the end: end loop Good luck, Battle-Scarred Veteran A few thoughts on communicating over the network. Remember that others do not get what you are 'thinking', only what appears in cold black-and- white (or green) on their screen. So be courteous, and try not to take immediate offense at jokes and the like. Use of the smiley and frowny faces is recommended [ :-) :-( ] for clarifying your state of mind. Sooner or later you will be looking at someone else's Great Warrior program, and have the idea that you can make it even better. If you put up a test, be sure to include a credit like: ;strategy testing a variation on Great Warrior Most of the time your change will be harmful instead of helpful, but if you do succeed you have an obligation to share it with the author if he's still around. Then he will tell you whether it's ok to put it up under your name, your combined names, or "thanks for the suggestion, I will make the change and credit you", or whatever. This is a sensitive area and other people's (helpful) comments are welcomed, but the point to remember is to grant credit where credit is due. You know, there are lots of 'tricks' out there that need to be catalogued somewhere. I'm thinking of every sort of 'ah-ha' idea that has made a program successful. Like Gamma Paper's using a very fast mod-8 bomber to clear out the scanners before replicating, or using predecremental dat in an imp-gate, or using a spl-zero to grow cycles in a stone. Maybe we need some articles like 'One Hundred Tricks with Bombers'. There's a lot of good stuff been published over the years, but no summation available anywhere. Anyway, good luck and _welcome_ to all newbies. Paul Kline pk6811s@acad.drake.edu From: Euphoria@junkpile.demon.co.uk (Ian Crowther) Subject: Re: Bugs? Date: Fri, 19 Feb 1993 00:14:26 +0000 Message-ID: In article <1993Feb17.054707.24131@fcom.cc.utah.edu> ejensen@elen.utah.edu (Eric Jensen) writes: > The program I have been using, because it seems to be the fastest, is > C88V202.EXE, but this one also has a small problem. When in graphics > (text-graphics, but battle-display anyway) mode, pressing "d" goes to > the debugger. When running 10 rounds "C88 -r 10 dwarf imp" the display > is not normally used to increase speed, but if you press the "d", it > crashes, and (you guessed it) I have to reboot. Alas I have had these problems and more, add to that that the trace option is almost unusable (plonks the information wherever it feels like onscreen) and it adds up to an irritatingly untested program. >:-( Also a Question, if I have a program which is passable but not excellent is it permissable to post it here and (grin) gather opinions upon its performance and tecniques..? Euphoria, but not always -- signature under anasthetic From: wangsawm@prism.CS.ORST.EDU (W. Mintardjo) Subject: Re: core war tutorial WANTED Message-ID: <1m1egvINNrd6@flop.ENGR.ORST.EDU> Date: 19 Feb 93 01:52:31 GMT pk6811s@acad.drake.edu in article <1993Feb18.112549.1@acad.drake.edu> writes: ---------- | ... | cmp-scanner - moderately fast, small, kills replicating opponents | b-scanner - very small, kills replicating opponents and larger scanners ^^^^^^^^^^^^^^^ Actually, B-scanner and CMP-scanner (assuming the true form of larger scanner) are almost equal in strength. CMP-scanner scans two locations in three steps (67% c) while B-scanner scans only one locations in two steps (50% c). Also, most CMP-scanners use DJN stream as part of their scanning which gives them additional attack + decoy. Both faster scanning and DJN stream compensate CMP scanner's size when fighting against B-scanner. | ... | pit-trapper - very small, kills replacators and others as well They are better than bombers against replicators. But still, both Sucker 4 and Twilight Pits lose 75% of the time against Note Paper. | ... ---------- --- Mintardjo W. From: maxwell@uxa.cso.uiuc.edu (maxwell scott) Subject: Re: Bugs? Date: Fri, 19 Feb 1993 03:12:35 GMT Message-ID: rmathews@zeus.calpoly.edu (Bob Mathews) writes: >I have never been able to find a satisfactory (and non-X) MARS. The MADgic Core 4.1 is damn nice. Worth buying an Amiga for ... :-) -- -----------------------------+------------------------------------------------- // Scott Maxwell ... | ``In terms of actual digital carnage, [the \\// but you can call me | Michelangelo virus] probably did far less damage XX maxwell@uxa.cso.uiuc.edu | than version 7.0 of PC Tools." -- Arlan Levitan From: ASMQK@ASUACAD.BITNET Subject: Re: Bugs? Message-ID: <93050.134844ASMQK@ASUACAD.BITNET> Date: 19 Feb 93 20:48:44 GMT I fixed the ESC bug in Mars88 so please download the new version from soda. This version is also shorter. I know I didn't write about it anywhere, but it's easy to figure out that everything in the config file can be changed including the editor. Nandor. From: parrinel@ux1.cso.uiuc.edu (Chris Parrinello) Subject: Sample redcode. Message-ID: Date: Fri, 19 Feb 1993 23:52:23 GMT I'm a new player and I have written my first recode which I submitted to KotH and was subsequently booted off :-). Anyway, I just read Paul Kline's article (thanks!) about reading and writing A LOT of code, he mentions a few basic techniques. Is there a place where I could ftp a collection of the basic strategies used by programers? Please followup responses to this newsgroup because I'm sure other people would be interested. Thanks in advance... Chris From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) Subject: Nothing new yet Message-ID: <85740@hydra.gatech.EDU> Date: 20 Feb 93 07:14:36 GMT I was just wondering if anybody has had any new ideas in the last ten weeks? All I have seen is a couple new imp spirals and a couple new scanners. BUT THERE HAS BEEN NO NEW IDEAS, NO NEW DEVELOPMENTS in a long while. Has Corewars degenerated into the optimum programs? What happened to the Rock-Paper-Scissor relationship? It seems that paper has been left out. The Rock programs (Imp Spirals) have eliminated all of the paper programs. All of the replicators that used to get alot of points by beating up on Stone are now out of luck. Is it possible to design a replicator that can take a impspiral out? But then replicators lose against most scanners There needs to be some way to break the gridlock. I still have a post from P.Kline oabout Scanner eradication from last September. Things sure have changed since then. I remember when Dan Nabwhatever posted his new 'Empire' program, which scored 195 with only 1% losses. That shook the hill. Will I find Corewar boring? Will I get tired of submiting the same old programs? Will I quit like Hastings did? I hope not. I would like to encourage everyone to post their code. Maybe someone can improve it. Maybe someone can be inspired by it. Maybe it will help new people get into the game, which might spawn new ideas. I want to know if we have found the perfect warrior, the imp ring. Is there any program that can beat an imp ring with a win-to-loss ratio of 7 to 3? If not, we have hit a dead end. -- Wayne Edward Sheppard Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7804b Internet: gt7804b@prism.gatech.edu From: durham@cup.portal.com (Mark Allen Durham) Subject: Re: Bugs? Message-ID: <76099@cup.portal.com> Date: Sat, 20 Feb 93 09:05:03 PST I thank Scott Maxwell for that completely unsolicited enthusiastic review of The MADgic Core. As good as version 4.1 is, wait until you see 5.0! I have just upgraded my system to Release 2.1 of the operating system and am incorporating new goodies even as you read this. (1.x users, don't worry. I won't leave you behind). Look for a Spring release. I'll post when it is available on soda. Mark A. Durham durham@cup.portal.com (until March 1, 1993) durham@ricevm1.rice.edu (March 1 -> ???) From: durham@cup.portal.com (Mark Allen Durham) Subject: Reply for Kuck Message-ID: <76100@cup.portal.com> Date: Sat, 20 Feb 93 09:10:58 PST Note: This is in reply to a post by Norbert Kuck (stud2@aifb.uni-karslruhe.de), but I was unable to reach him via the posted address. Since the answer to his question is probably of general interest anyway, I decided to post it. The question was, "What is the stone-scissors-paper analogy?" The stone-scissors-paper analogy has to do with a decision game called "Paper-Scissors-Stone" much like "Evens & Odds". The game is played by two people. On the count of three, each player reveals their choice between paper or scissors or stone through the use of hand signs. Paper is indicated by an open hand, stone by a closed hand, and scissors by extension of the index and middle fingers, separated to look like a pair of scissors. Stone beats scissors (because you can crush scissors with a stone) beats paper (because scissors cut paper) beats stone (because paper can wrap around stone). [In "Evens & Odds", players reveal either one or two extended fingers. If the sum of the extended fingers is even, the player with Evens "wins".] The reference in Core War to paper-scissors-stone is due to someone's demonstration (sorry, I forget whom) that there are (at least) three classes of programs which demonstrate cyclical superiority similar to that found in the decision game. Mark A. Durham durham@cup.portal.com From: ivner@lysator.liu.se (Anders Ivner) Subject: Re: Nothing new yet Message-ID: Date: Sat, 20 Feb 1993 19:12:20 GMT In article <85740@hydra.gatech.EDU> gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) writes: I still have a post from P.Kline oabout Scanner eradication from last September. Things sure have changed since then. I remember when Dan Nabwhatever posted his new 'Empire' program, which scored 195 with only 1% losses. That shook the hill. I think you've confused the facts a bit here... Dan Nabutovsky's program was called 'Impossible', and was in fact an improved version of 'Impire' which had conquered the hill one week earlier. I would like to encourage everyone to post their code. Maybe someone can improve it. Maybe someone can be inspired by it. Maybe it will help new people get into the game, which might spawn new ideas. Ok, so here goes: first an idea I've been having for awhile, but not quite managed to implement. loop add const, scan scan mov Date: Sun, 21 Feb 93 03:18:27 GMT In article Euphoria@junkpile.demon.co.uk (Ian Crowther) writes: >> The program I have been using, because it seems to be the fastest, is >> C88V202.EXE, but this one also has a small problem. When in graphics >> (text-graphics, but battle-display anyway) mode, pressing "d" goes to >> the debugger. When running 10 rounds "C88 -r 10 dwarf imp" the display >> is not normally used to increase speed, but if you press the "d", it >> crashes, and (you guessed it) I have to reboot. > >Alas I have had these problems and more, add to that that the trace option >is almost unusable (plonks the information wherever it feels like onscreen) >and it adds up to an irritatingly untested program. >:-( I was the original poster, and to be fair, the author of C88 has posted a new version (C88V320.ZIP) to soda and it is _much_ improved. Nice debugging, (shows core address, not just contents) with breakpoints. It also has a nicer display. The ascii graphics use the whole screen, and information is displayed in pop-up boxes. P.S. C88V320.ZIP was zipped with UNIX zip, and the pkunzip (on PC) I tried (i think it's an old version,though) didn't work. The Unix unzip works just great. -ike Subject: Re: Nothing new yet Message-ID: <1993Feb21.192009.29588@wisipc.weizmann.ac.il> From: fedimit@wisipc.weizmann.ac.il (Dan Nabutovsky) Date: Sun, 21 Feb 1993 19:20:09 GMT In article <85740@hydra.gatech.EDU> gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) writes: > > I still have a post from P.Kline oabout Scanner eradication from last > September. Things sure have changed since then. I remember when Dan > Nabwhatever posted his new 'Empire' program, which scored 195 with > only 1% losses. That shook the hill. > First imp ring, IMPire, was posted by Anders Ivner, not by me. It loosed about 8% of games and got ~180 points. Only then I posted my programs Impossible (first imp spiral) and Impressive. One of them scored ~187 with 1% losses, other scored ~195 with 2% losses. Dan Nabwhatever. :-> From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 22 Feb 1993 06:02:21 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1993/02/09 Version: 2.0.1 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 67 2. Is it Core War or Core Wars? 80 3. Where can I find more information about Core War? 88 4. Core War has changed since Dewdney's articles. Where do I get 106 a copy of the current instruction set? 5. What is the ICWS? 120 6. What is TCWN? 130 7. How do I join? 138 8. Are back issues of TCWNs available? 158 9. What is the EBS? 174 10. Where are the Core War archives? 190 11. Where can I find a Core War system for . . . ? 207 12. I do not have ftp. How do I get all of this great stuff? 224 13. I do not have access to Usenet. How do I post and receive news? 231 14. When is the next tournament? 242 15. What is KOTH? How do I enter? 251 16. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 353 17. How does SLT (Skip if Less Than) work? 365 18. What does (expression or term of your choice) mean? 377 19. Other questions? 503 --------------------------------------------------------------------- Q 1: What is Core War? A 1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 The Redcode language has changed somewhat since; see Q 4. --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (soda.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q10) --------------------------------------------------------------------- Q 5: What is the ICWS? A 5: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). --------------------------------------------------------------------- Q 6: What is TCWN? A 6: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 7: How do I join? A 7: For more information about joining the ICWS (which includes a subscription to TCWN), contact: A 7: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 8: Are back issues of TCWN available? A 8: Back issues of TCWN (up to Winter 1991) are available from AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 or contact William R. Buckley at xwbuckley@fullerton.edu. Prices are unknown at this time, but should be around $5.00 (the original cover price). More recent issues can be found on soda.berkeley.edu (see 10). --------------------------------------------------------------------- Q 9: What is the EBS? A 9: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994. Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- A10: Where is the Core War archive? Q10: 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. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q11: Where can I find a Core War system for . . . ? A11: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are Unix X-Window, IBM PC-compatible (sorry, no systems specifically designed for MS-Windows yet), Macintosh, and Amiga Core War systems available there. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than soda.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. ---------------------------------------------------------------------- Q12: I do not have ftp. How do I get all of this great stuff? A12: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. ---------------------------------------------------------------------- Q13: I do not have access to Usenet. How do I post and receive news? A13: A rec.games.corewar-specific server is in the works. Contact Jonathan Roy (faf@halcyon.com), Vice President of the Free Access Foundation, for more information. If you somehow receive rec.games.corewar but just can't post, you can email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q14: When is the next tournament? A14: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. ---------------------------------------------------------------------- Q15: What is KOTH? How do I enter? A15: King Of The Hill (KOTH) is an ongoing Core War tournament available to anyone with email provided by William Shubert (wms@iwarp.intel.com). You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". 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 daemon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives in an hour, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. MORE ON KOTH COREWAR IMPLEMENTATION Core size: 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 Programs are guaranteed a 100 instruction block (inclusive of their warrior's instructions) without overlapping their opponent. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Rule variants for "eXperimental" corewar: The same as above but use ";redcode-x" to start your program. Your program will be entered into a second tournament with slightly different rules. The rules are: - All addressing modes are allowed with all instructions. - There is an additional addressing mode, called "postincrement". To use it try an instruction like "mov >5,6". - The maximum write distance is 250 instructions. That is, every time your program tries to modify memory, the address is checked; if it is more than 250 instructions from the process doing the modify, then memory is left unchanged, but the instruction continues as normal. - A tie is not declared until 150,000 cycles per program have elapsed. KotH runs on any Unix system with an X windows interface. The source code to KotH is available by email from William Shubert. Write to him at (wms@iwarp.intel.com) for a copy or get it by anonymous FTP from soda.berkeley.edu in the pub/corewar/systems directory. ---------------------------------------------------------------------- Q16: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A16: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. ---------------------------------------------------------------------- Q17: How does SLT (Skip if Less Than) work? A17: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q18: What does (expression or term of your choice) mean? A18: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, Date: Mon, 22 Feb 1993 14:49:06 GMT In article <...> ivner@lysator.liu.se (Anders Ivner) writes: > > loop add const, scan > scan mov jmz loop, > This should work as both an emerald-like bomber and a cmp-scanner, since > something would be found if: > 1) the b-fields of both b and b-1 is non-zero. > or > 2) the b-field of the effective address of " indicate that "a", too, is worth bombing. > Along a similar line is this bomber-scanner called T.Rex. In T.Rex there is a bombing component (line 'stone') into which I drop 2 processes. Note there is no jmp so stone does not grow additional processes. That is to allow the 'scan' component to check the location about-to-be-bombed every 4th or 8th (I can't remember) bomb, just before it is bombed. If the about-to-be-bombed b-field is a 2667-imp, then back up the bomber (it will have advanced past that point now) and change it's increment to 2667. At the same time release some fast replicators. T.Rex works well if the imps are 2667-imps AND they have had time to leave trails of more than a few locations, one or both of which assumptions does not seem to hold on the Hill very much. Also, T.Rex is somewhat of a slow bomber, since one-fourth of the processes in 'stone' are dying at 'dat1' and one additional process is in the scan loop. It does bail out of the scan process after 150 scans. ;redcode quiet ;name T.Rex ;kill T.Rex ;author P.Kline ;strategy stone-paper with a lookout for imps ;strategy added anti-vamp code step equ 2376 boot equ 2000 imp equ 2667 start spl scan,1 ; spl 1,1 spl 1,1 mov Date: 23 Feb 93 08:11:19 GMT Here is an interesting cmp-scanner that has two coreclears! he two coreclears are needed against impspirals. After a small (compared to Charon 8.1) scanning time, the core is blanketed with spl 0. The offset for this coreclear is 381. 381=8001/(7*3) is the optimal coreclear for 3 and 7 point rings. This should write over the ring completely. Now all it has to do is a dat coreclear. I was able to get it down to 14 lines, and all of the major bugs are out. But it doesn't look like the double coreclear is worth the extra lines. ;redcode ;strategy Basic spl/jmp cmp scanner ;strategy with TWO coreclears ;strategy first coreclear spl 0 at offset of 381=8001/(7*3) ;strategy second coreclear dat 0 ;strategy Problem : Two lines larger that Charon 8 add off,1 loc cmp 1,50 slt #20,-1 djn -3,<1499 mov j,@loc dec mov s, Date: Thu, 25 Feb 1993 05:58:42 GMT hi guys, first of all i want to thank paul kline for that fabulous strategy posting, a few more by other authors could make a collection well worth archiving. and now, i want to bounce some ideas off you. i have a kinda new idea, which would hopefully beat the scissors/paper/stone deadlock, and i wanna check the ground before i proceed. i'm kinda wary of reveling the full scope of my idea just yet (not so much for fear of having it stolen, as for fear of being laughed off the net.) so we'll talk in generic terms. the faq indicates that paper-type replicators (mainly imps) are the bane of stone-type bombers, right? so what's the best defense against a paper attack? what are the chances of survival of a very small bomber with some sort of imp-gateway? what are the likely weaknesses of such a program? also, would someone kindly explain the use of reflections. i think i understand what they are, but it would be handy if you could make it clear, perhaps with an example or two. thanx again, i look forward to offering you something worthy of competition. malcolm ryan (c/o andrew miehs) -- +-------------------------------+---------------------------------------------+ | Andrew Miehs | | | Mail: andy@extro.ucc.su.oz.au | $$$ THIS SPACE FOR RENT $$$ | | NB: Don't call me andy! | | From: emeu09@castle.ed.ac.uk (Mech Eng Student) Subject: Re: Sample redcode. Message-ID: <32298@castle.ed.ac.uk> Date: 25 Feb 93 10:40:43 GMT In article , parrinel@ux1.cso.uiuc.edu (Chris Parrinello) writes: |> |> I'm a new player and I have written my first recode which I submitted to |> KotH and was subsequently booted off :-). Anyway, I just read Paul Kline's |> article (thanks!) about reading and writing A LOT of code, he mentions a |> few basic techniques. Is there a place where I could ftp a collection |> of the basic strategies used by programers? Please followup responses |> to this newsgroup because I'm sure other people would be interested. |> |> Thanks in advance... |> |> Chris Would it be possible to have a beginner's hill? If all of your code just gets wasted the same by the semi-permanent guys at the top how do you know what to expand on? It would be nice to know what things work against which types of code. Perhaps even a test hill which includes all of the basic strategies on their own and just posts back how well you did against each thus exposing your weaknesses. Just an idea TTFN Roderick Easton 2nd year Student Edinburgh University SCOTLAND From: pk6811s@acad.drake.edu Subject: Re: Newbie questions about strategy Message-ID: <1993Feb25.090428.1@acad.drake.edu> Date: Thu, 25 Feb 1993 15:04:28 GMT In article <. . .> andy@extro.ucc.su.OZ.AU (Andrew Miehs) writes: > > the faq indicates that paper-type replicators (mainly imps) are the bane of > stone-type bombers, right? so what's the best defense against a paper attack? > what are the chances of survival of a very small bomber with some sort of > imp-gateway? what are the likely weaknesses of such a program? > > also, would someone kindly explain the use of reflections. i think i > understand what they are, but it would be handy if you could make it clear, > perhaps with an example or two. > Paper's strength is in existing at so many locations that a bomber can't kill it all. Eventually it will overwrite the stationary bomber and kill it. But it is susceptible to various attacks incorporating the 'spl' command. Vampires drop 'jmp' instructions all over core to make the paper jump into a 'slave pit' like: trap mov bomb,<-50 spl -1 jmp trap which grow cycles rapidly and slows the rest of the paper down. However, as W. Mintardjo pointed out, it is possible to design paper that can overwhelm a simple trap. Cmp-scanners and B-scanners search for the opponent and drop stun-bombs like: spl 0 jmp -1 or spl 0 spl 0 . . . <- a 'carpet' of spl-zeros spl 0 which also slow the paper down. Under continuous attack, most of the replicators will be stunned, and the rest will be destroyed in the core clear. Other fighters just drop the stun bombs in a pattern and trust to chance to catch the paper - usually a successful strategy. By-the-way, contrary to what was believed a year or two ago, a single spl-zero will not be a successful stun bomb against today's paper. Another strategy is to aim for a tie. If your warrior can beat some group of others on the Hill, but loses to paper, then maybe it could settle for tying paper. That is what imps do. Also, Return of the Living Dead seemed to tie paper a lot. ---- A reflection is a copy of your active code that is placed X locations away. It's sole purpose is to hide your code from a cmp-scanner which uses X as the cmp-distance. Reflections are very successful against scanners like Charon where the cmp-distance is half the inc-distance, but only half as successful against Agony-type's where the cmp- and inc- distances are unrelated. To demonstrate reflections, try running this version of Charon against this version of Eloquent and see how long it takes Charon to drop a bomb on Eloquent. Eloquent is a quad of replicators that stay together and reflect one another at 34 and 49. At one time it was winning up to 80% against Charon and No Mucking About. ;redcode ;name Charon v8.1 ;kill Charon ;author Cisek,Strack,Kline ;strategy (strategy lines deleted) STEP equ 68 ;scan constants: DIST equ 34 ;small, so can be reused in core clear DJNOFF equ decr-DIST FIRST equ DJNOFF+149 ;optimal offset to DJN train attack add switch,@compptr ;switch A- and B-fields mov jump,@comp compptr mov split, Date: Fri, 26 Feb 1993 17:41:06 GMT Here's a tip that was worth 6 points and put Eclipse on the Hill. Eclipse starts with a b-scan. When it finds something it assumes 'imp', saves the found instruction to use as an increment in a bombing run, bombs for a while, then releases some small bombers. To avoid triggering the bombing run when a djn-stream was discovered I checked for minus-one like this: next add #step,@ptrptr scan jmz next,@ptr ptrptr cmp #-1,@ptr <- ignore djn-streams slt #105,@ptrptr jmn next,next . . . What I just realized was that Charon and Agony both have two instructions with minus-one for a b-field, and that Eclipse was therefore ignoring those locations. So I changed it to this: next add #step,@ptrptr scan jmz next,@ptr ptrptr cmp minone,@ptr <- ignore djn-streams slt #105,@ptrptr jmn next,next . . . start sub #1,minone <- create minone about 3000 locations away jmp next Now Eclipse ignores djn-streams but recognizes the locations in Charon and Agony as 'opponent'. Result - 6 more points and finally on the Hill. I'm still working on the bombers, but here is one interesting variation which bombs forward and decrements backward: b1 add #2,2 spl -1,<-51 mov <-1,<51 jmp -2,<-2 Paul Kline pk6811s@acad.drake.edu From: wangsawm@prism.CS.ORST.EDU (W. Mintardjo) Subject: Twilight Pits evolution Message-ID: <1mm16cINNq2u@flop.ENGR.ORST.EDU> Date: 26 Feb 93 21:13:48 GMT Here is my vampire program, Twilight Pits. It has been my favorite vampire since the first time I wrote it. I wrote an article: > They are better than bombers against replicators. But still, both Sucker 4 > and Twilight Pits lose 75% of the time against Note Paper. Oops, a correction here. After running some more battles. I figured out that the number to be more accurate should be 60% (still in favor for Note Paper). First incarnation, Twilight Pits 3: ------------------------------------------------------------------------------- ;redcode verbose ;name Twilight Pits 3 ;author W. Mintardjo ;strategy v1: bombs --> pits --> slavers ;strategy v2: 2 pass core-clear (1 SPL + 1 DAT) ;strategy v3: simplification of version 2 offs EQU 196 start SPL 0, <-290 ;135x < b-field s MOV t, @t ;JMP spot SUB trap, t JMP -2, pits --> slavers ;strategy v2: 2 pass core-clear (1 SPL + 1 DAT) ;strategy v3: simplification of version 2. One pass and delayed core-clear ;strategy v4: IMP protection aided with DJN stream. DJN reset core-clear ;strategy v5: Separated module. Different init ;strategy v6: Launched code. Draining more enemy's process. Use decoys ;strategy : Different step-size ;strategy Bugs: Its mirror is unprotected step EQU 91 init EQU 86 boota EQU 3000 spacea EQU 6 spaceb EQU 8 setup MOV trap, boota ptra MOV start+3, boota-spacea+setup+2 MOV start+2, boota-spacea+setup+1 MOV start+1, boota-spacea+setup MOV start+0, boota-spacea+setup-1 ptrb MOV clear+3, boota+spaceb+setup+1 MOV clear+2, boota+spaceb+setup MOV clear+1, boota+spaceb+setup-1 MOV clear+0, boota+spaceb+setup-2 MOV dbomb, boota+spaceb+setup-2+step JMP boota-spacea+setup-1, <1112 dbomb DAT <0-(spacea+spaceb-2+spacea), <0-(spacea+spaceb-2+spacea) ; Put some decoys here start SPL 0, <0-(spacea-1) s MOV spacea, @spacea ;JMP spot SUB spacea+spaceb+s-2, spacea+s p DJN s, <3025 trap JMP spaceb-2-init, 60. Or perhaps we could try to use different evaluation to see how good a program is. There are at least seven types of programs: stone, paper, cmp-scanner, b-scanner, vampire, spl/jmp bomber and spiral. If our program works fine against at least four of them (half the number of type), then our program must be not bad at all? What's about writing program that could easily take >60 victories over imps? paper does not seem to be the answer. A pure paper (like Note Paper) with anti-imp could hardly beat them >30. An intermediate class between replicators and spirals could serve the same purpose. What's about multi imp-threader? (from there I started writing Paratroops). The ratio is still 2:1 in favor for multi imp-threader programs. Not quite enough. Can this kind of program or paper program enhanced? Probably, and to add a little complexity to the situation, here is Chimera. The first time I wrote Chimera, it seemed as an awkward combination between Twilight Pits and spirals. But works great against paper and multi imp-threader. It doesn't quite catch up bomber or spiral/stone combos. A slightly win over cmp-scanners. Again, this deprived many multi process programs, even pure paper like Note Paper. Maybe replicator/anti-vamp/anti-spiral program? ------------------------------------------------------------------------------- ;redcode ;name Chimera v3.5 ;author W. Mintardjo IMP0 EQU imp IMP1 EQU IMP0+2667 IMP2 EQU IMP1+2667 step EQU 283 init EQU 276 boota EQU 3211 spacea EQU 8 spaceb EQU 1 ; decoys go here setup MOV trap, boota ptra MOV start+3, boota-spacea+setup+2 MOV start+2, boota-spacea+setup+1 MOV start+1, boota-spacea+setup MOV start+0, boota-spacea+setup-1 ptrb MOV clear+2, boota+spaceb+setup+2 MOV clear+1, boota+spaceb+setup+1 MOV clear+0, boota+spaceb+setup MOV dbomb, boota+spaceb+setup+step SPL 16, <3706 SPL 8, <1933 SPL 4, <1812 SPL 2, <2009 JMP IMP0, <7368 JMP IMP1, <6011 SPL 2, <5810 JMP IMP2, <4809 JMP IMP0+1, <3908 SPL 4, <7515 SPL 2, <4914 JMP IMP1+1, <2213 JMP IMP2+1, <7212 SPL 2, <7011 JMP IMP0+2, <6710 JMP IMP1+2, <6509 SPL 8, <6108 SPL 4, <5615 SPL 2, <5214 JMP IMP2+2, <3509 JMP IMP0+3, <1908 SPL 2, <2415 JMP IMP1+3, <3314 JMP IMP2+3, <4601 SPL 4, <3600 SPL 2, <4159 JMP IMP0+4, <3102 JMP IMP1+4, <2901 SPL 2, <2168 JMP IMP2+4, <1515 SPL boota-spacea+setup-1, <7115 SPL boota-spacea+setup-1, <6302 SPL boota-spacea+setup-1, <5301 SPL boota-spacea+setup-1, <5900 JMP boota-spacea+setup-1, <1112 dbomb DAT <1-(spacea+spaceb+spacea+spaceb), <1-(spacea+spaceb+spacea+spaceb) start SPL 0, spacea+1 s MOV spacea, @spacea ;JMP spot SUB spacea+spaceb+s, @-1 p DJN s, <3154 trap JMP spaceb-init, Date: Sat, 27 Feb 1993 01:00:12 GMT In <32298@castle.ed.ac.uk> emeu09@castle.ed.ac.uk (Mech Eng Student) writes: >Would it be possible to have a beginner's hill? If all of your code just gets >wasted the same by the semi-permanent guys at the top how do you know what to >expand on? It would be nice to know what things work against which types of code. >Perhaps even a test hill which includes all of the basic strategies on their own >and just posts back how well you did against each thus exposing your weaknesses. I would like to see a beginners hill also. Here are a few specific suggestions: 1. Have the warriors score be calculated by ((2*wins)+ties-age) rather than ((2*wins+ties). This automatically will remove successful warriors, leaving room for new beginners code. 2. Ban specific successful authors. I would suggest banning anyone that has had a warrior in the top ten on the regular hill that is age > 100. 3. Do not post beginners hill results to the net. Also, do not automatically forward warriors from beginners hill to other to tournaments. Hopefully the lack of noterity will discourage authors from `sandbagging'. 4. Keep the rules the same as for KOTH, to make the transition easier. Rodney Schuler Nuclear Engineering Remember: One, JUST ONE thermonuclear device Iowa State University can ruin your whole day! rschuler@iastate.edu From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Beginners Hill Message-ID: <1993Feb27.030042.23549@oucsace.cs.ohiou.edu> Date: 27 Feb 93 03:00:42 GMT In article rschuler@iastate.edu (Rodney A Schuler) writes: > >I would like to see a beginners hill also. Here are a few specific >suggestions: > >1. Have the warriors score be calculated by ((2*wins)+ties-age) rather >than ((2*wins+ties). This automatically will remove successful warriors, >leaving room for new beginners code. I think this is not a good enough scoring method and would result in too many changes... if there are good beginning programs, shouldn't they at least stay on long enough for those others to test their programs against? Maybe we should keep the scoring the same (so that it is similar to the real hill) and look for other ways to improve it for beginners. >2. Ban specific successful authors. I would suggest banning anyone that >has had a warrior in the top ten on the regular hill that is age > 100. I thought about this, and even thought at one time that this was a good idea... but I think it would be better to say that each author may have at most one warrior on the hill at a time... this would give more authors the chance to get on the hill... Also, the age limit is a good way to limit warriors as well... this would supercede the #1 above... >3. Do not post beginners hill results to the net. Also, do not >automatically forward warriors from beginners hill to other to tournaments. >Hopefully the lack of noterity will discourage authors from `sandbagging'. I somehow have an uneasy feeling about this. I am more under the impression that a beginner's hill should automatically release the code to any of the contestants that are trying to get on the hill... This would allow each person to learn about how the other warriors tick, as well as discourage those who think their code is valuable from playing on the hill to begin with... (they should play on the real hill at that point). The beginner's hill is one for learning, not stagnation... sandbagging is a problem for all hills and tournaments and archives and ... >4. Keep the rules the same as for KOTH, to make the transition easier. Exactly... this means no #1 above... Changes would mean the following: 1) age > 100 knocks a warrior off (should there be a penalty for resubmission of same warrior?) 2) maximum of 1 warrior per author on the hill at one time 3) source for each warrior currently on the hill should be automatically given to the person trying to get on the hill -- Scott W. Adkins Internet: sadkins@bigbird.cs.ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Hills in general... Message-ID: <1993Feb27.031654.25038@oucsace.cs.ohiou.edu> Date: 27 Feb 93 03:16:54 GMT Well, while we are still on the subject of hills and beginners... what about having a Hall of Fame or something... if a warrior got pushed off the hill because the age > 100 or something like that, then another hill should be created to accomodate these warriors. The hill could grow without size (I am sure it would grow slowly, so boundless is not too bad) and allow others to challenge those on that hill just to see how they would do... To make things easier, I think we would need a few more comment lines: 1) ;redcode-b [ quiet | verbose ] Challenge the Beginner's Hill... 2) ;redcode-h [ quiet | verbose ] Challenge the Hall of Fame Hill... quiet -> just send back results of battles (none) and verbose -> send back redcode and results of battles 3) ;report [source] ;report-b [source] ;report-x [source] ;report-h [source] Give current standings of the hills... this would eliminate all those suicide programs that check to see the current hill standings. If the source option is provided, then include the sources of the programs as well. For the real and experimental hills, the ;source line must be included before the source is released. 4) ;source Allows the source of your warrior to be distributed when challenging the hill or while on the hill. Note: This is the default case for the beginner's hill and the hall-of-fame hill. It is *not* the default case for the experimnetal hill and the real hill... Well, I had better stop here. I plan on setting up a corewar server eventually, but it will be quite different from KotH style... it will be both a mail server and a socket server (i.e, you can telnet to it), which will allow you access to all warriors in the archive, and also allow you to test and debug your warriors, etc. But that will be later. Scott -- Scott W. Adkins Internet: sadkins@bigbird.cs.ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: durham@cup.portal.com (Mark Allen Durham) Subject: State of the EBS Address Message-ID: <76612@cup.portal.com> Date: Sat, 27 Feb 93 20:26:33 PST State of the EBS Address February 27, 1993 Fellow Core War Enthusiasts, The Electronic Branch Section of the International Core War Society has existed informally since the Summer of 1991. In the Fall of 1991, I petitioned the ICWS, on behalf of all Core War enthusiasts with access to electronic mail, to recognize the EBS as an official Branch Section. Although I never received an official "Certificate of Recognition" from the (then) Director, as stated in the "Guidelines for Establishing A Local Core Wars Section" document, I HAVE received affirmation from both the (then) Director and the present Director of the ICWS of the EBS's official status. Part of being an official Branch Section is the establishment of Branch Section rules. The EBS has only one rule: 1. Members of the EBS are those with access to electronic mail. The EBS currently charges no dues and has no other membership rules. Since the establishment of the USENET newsgroup rec.games.corewar, the vast majority of the EBS's business has been carried out there. An effort is underway to provide a server for those members of the EBS without access to rec.games.corewar. As a Branch Section of the ICWS, the EBS currently has the following obligations only: 1. The EBS is required to promote the use of MARS and Redcode programs consistent with standards documents approved by the ICWS and its Director (currenty Jon Newman, jonn@microsoft.com). 2. The EBS is required to conduct tournaments in a timely, periodic fashion, and will choose no more than ten (10) winners yearly from such tournaments. Programs chosen as winners are then to be presented formally by the EBS to the ICWS for inclusion in the annual ICWS tournament. Throughout the existence of the EBS, I have served as its de facto Representative to the ICWS. It is with a heavy heart and a light wallet that I am forced to bid farewell to the net, at least for awhile. Obviously, I can no longer serve in that position. The EBS's most important need is for someone to come forward and volunteer to serve as liason and Representative to the ICWS. All that is needed is your own personal conviction, a willingness to work under the above constraints, and to contact the Director and inform him that you are currently representing the EBS. You should also see to it that the EBS holds its annual tournament, selects ten finalists, and sends them on to the annual ICWS tournament. I hope to be back by March of 1994 when Core War celebrates its Tenth Anniversary. In the interim, I will try to maintain as much contact as possible through the ICWS and other avenues. Other than the above, the EBS is in excellent condition. The EBS is well served by its archive in /pub/corewar at soda.berkeley.edu and the ongoing Core War tournaments known as King of the Hill. Activity on rec.games.corewar, although somewhat seasonal, continues to be strong and even increase over time. The rec.games.corewar FAQ continues to improve and now reaches a much wider audience, possibly bringing others into the fold. The benefit to Core War enthusiasts is clear when you consider that the EBS entrants have dominated the last two ICWS tournaments. In fact, the EBS has become the tail that wags the dog. I hope that the EBS does not turn its back on the ICWS, but continues to work with the ICWS and Core War enthusiasts in general. I do not want to be alarmist. I do not see signs that there may be a parting of the ways. I am just pointing out that there is potential here. There are two items the EBS needs to tackle over the next year. The first is the draft of the new standard. Although new standards fall under the jurisdiction of the ICWS, it is clear that the EBS can serve a very useful function in developing, testing, and proposing the adoption of a new standard. Second, the EBS should probably establish some rules for choosing officers. Volunteerism has served us well so far, and part of the appeal of the EBS has been its lack of rigid structure, but the continued survival of the EBS depends on developing at least some semblance of structure to hold the group together. Personal Reflections: For perhaps the first time in nine years, I truly feel that Core War is not in immediate danger of being forgotten. I am confident that I could leave civilization for five years, come back, and find that there is still a rec.games.corewar, still an ICWS, and still a group of the finest people on the face of the Earth engaged in playing Core War. And probably someone saying, "It won't last a month." About a year ago, maybe more, someone posted to rec.games.corewar that there really was no point to a King of the Hill program. XTC, the best warrior at the time, was considered to be practically invincible. They said it would still be on the hill a month later; even a year later. They were almost right. XTC fell off the hill somewhere around a month later. I recently submitted it to KotH to see how well it would fare now that it is a year later. XTC did make it onto the hill. Dead last. It survived only until the next challenger appeared. When you consider that the hill is twice the size it was a year ago, it is clear that Core War HAS progressed over the last year, and that there is always room for innovation and improvement. Mark A. Durham From: durham@cup.portal.com (Mark Allen Durham) Subject: April Fools Message-ID: <76613@cup.portal.com> Date: Sat, 27 Feb 93 20:28:02 PST (It's a month early, but I just had to get this off my hard disk before signing off. Like postcards from mortuaries which state "We hope that you did not receive this in a time of personal crisis", I did not intend to personally offend if you see yourself in this mirror. MAD ;) ) April 1, 1993 Dear rec.games.corewar, Could someone please send me the standards, the Redcode warriors, all of the posts to rec.games.corewar, and anything else having to do with corewar over the last nine years? Could someone post the FAQ? I didn't feel like reading it last time and I can't wait around to see if it will ever be posted again. Of course, I don't have FTP and this isn't even my account. So don't bother posting a reply. I don't even have time to read this newsgroup. Is there a corewar system for a Cray? Could you bring it to me? I don't trust the Post Office or UPS. Oh, and bring the Cray. I don't have one of those either, but I won't play games on anything less. I have no money and I can't read. Someone else is typing this for me. Average Student Prestigious University