From: f_langleyrh@ccsvax.sfasu.edu Subject: TSR Ascii text editor & Core War Message-ID: <1993Apr1.202849.3838@ccsvax.sfasu.edu> Date: 1 Apr 93 20:28:48 CST Just out of curiosity I was wondering if any of you big time CoreWar coders used a TSR pop-up style editor. I'm in need of one, and thought: "Hey, that might be useful for CoreWars." I'm not a great Redcoding monster that creates unbeatables, but I try. Anyway, if anyone has something like this (preferably free/share ware) I think the group would like to know. -- Adam arasmuss@sfalib.sfasu.edu From: consp07@bingsunn.cc.binghamton.edu (consp07) Subject: b-scan Message-ID: <1pi9lp$165@bingsunn.cc.binghamton.edu> Date: 2 Apr 93 21:02:49 GMT Would somebody be kind enough to explain what a "b-scan" is, and if possible provide a simple, but real good example of how it works. Thanks people. -- | Consp07@bingsuns.cc.binghamton.edu will reach Sir Paul Bobby| From: jlayland@kilroy.Jpl.Nasa.Gov (James Layland) Subject: Re: b-scan Date: 3 Apr 1993 00:27:55 GMT Message-ID: <1pilmbINNron@elroy.jpl.nasa.gov> A b-scanner searches through memory for an enemy program by looking for non-zero b-fields. This can be done very quickly using the JMZ instruction. A simple b-scanner can be written in only 4 instructions: inc equ 3094 ; mod-2 scan of memory loop add #inc, scan scan jmz loop, 0 ; b-field zero when I look here mov loop-1, @scan jmp loop, 0 ; b-field zero so I don't hit myself This program increments a pointer (scan), then checks to see if it has a non-zero b-field. It can check one memory location every 2 cycles. With the increment above (or many others) it will eventually look at every other memory location. Two b-fields are set to zero to avoid a check against the program bombing itself. (The location labeled "scan" actually changes, but since it is zero when it points to itself, "scan" will not be bombed.) While this program is short and (pretty) fast, it will lose to just about anything on the Hill except the cmp-scanners. Hope this helps. James jlayland@grissom.jpl.nasa.gov "What's a disclaimer?" From: jesensky@mix.cs.psu.edu (James J Jesensky) Subject: What is a gate?? Message-ID: Date: Sun, 4 Apr 1993 23:17:06 GMT Greetings... I've been away from corewars for a while and am trying to get back into the game. Could someone explain the concept of a gate? Also, when I left, there was talk of a new standard ('92) with a more complex instruction set, interrupts, semaphores, etc. Did anything come of this or was the idea of a new standard moth-balled?? Thanks... James From: twolf@en.ecn.purdue.edu (Timothy W Wolf) Subject: time-limit question Message-ID: <1993Apr5.063154.16446@en.ecn.purdue.edu> Date: Mon, 5 Apr 93 06:31:54 GMT If you were running a core war simulation with just 2 programs, say maybe a forking program and an imp, with a short time limit, I know that the time limit would cause a CPU time limit expired type error on one of the programs causing a tie with the others. My question is what determines which one would time out...would it be the order in which the programs are run, in which case wouldn't it be the first program ? -- ____________ _________________________ /___________/] / ____________/] From: prechelt@ira.uka.de (Lutz Prechelt) Subject: Announcement: International KNOBELN contest Date: 5 Apr 1993 10:42:37 GMT Message-ID: <1pp2etINNem3@irau40.ira.uka.de> =============================================== Second Announcement of the 1st International KNOBELN --- Game-Strategy Programming Contest =============================================== This is an announcement for the KNOBELN-contest, taking place via e-mail on Saturday, May 8th, 1993 and on Sunday, May 16th, 1993. The contest is run at the University of Karlsruhe, Germany, by Lutz Prechelt. Arbitrary teams can participate in the contest. PLEASE REDISTRIBUTE THIS ANNOUNCEMENT AS WIDELY AS YOU CAN. ----------------- Type of Contest: ----------------- To participate, you must program in C a strategy for a simple game and send it to me by email. The game is quite interesting since there clearly is no canonical best strategy (the success of a strategy depends on the behavior of all other participants). -------------- Rules of Game: -------------- 1. Both players (at the same time) chose an integer number in the interval a..b. This selection of two numbers is called a "throw". The players can watch each throw as it is made (i.e. they can know all numbers they and their opponent have thrown up to the current throw) Assumption: Player P choses p1 and player Q choses q1. 2. If p1 equals q1, nobody wins a point. 3. The player with the higher number wins, unless the number is more than twice as high as that of his opponent. Let's assume that p1 > q1, then P wins if 2*q1 >= p1 and Q wins if 2*q1 < p1. 4. A player who wins a throw with some number N gets floor(log2(N)) points in this throw. The other player gets 0 points in this throw. Example: if P wins, he/she gets floor(log2(p1)) points e.g. if p1 = 6800, player P gets 12 points. 5. A game consists of L throws. 6. Both players must throw series of non-decreasing throws. These series must (for each player individually) have a length of AT LEAST k throws. Example: If P1 throws (p1, p2, p3, .....) then p1 <= p2 <= p3 <= ... <= p(k) is required. After that, p(k) > p(k+1) is allowed. If p(k) > p(k+1) then p(k+1) <= p(k+2) <= ... <= p(k+k) is required. else there exists some smallest number j, with j > k for which p(j) > p(j+1) and then p(j+1) <= p(j+2) <= ... <= p(j+k) is required. and so on through the whole game. If for instance k = 3 then the sequence 1, 2, 3, 1, 4, 5, 6, 8, 2 is allowed, while 1, 2, 3, 4, 1, 2, 1 is not ^ too early In this turnament the parameters are: a = 1, b = 12288, k = 8, L = 1000 -------------------- Rules of Tournament: -------------------- The tournament is performed in successive rounds with randomly mixed groups of 7 to 13 participants. Within each group, every strategy plays one game against every other strategy in that group. Those half of the participants (rounded up), that have won most points in their group (no matter how many their opponents got), proceed to the next round, which is played with newly mixed groups. The winners of the last round are the winners of the tournament; the results of previous rounds are discarded. Any strategy is allowed to fail once per round. Failing means doing anything that is disallowed according to the rules of the game. The game in question is immediately stopped, its intermediate results are discarded and it is rescheduled after all the other games currently scheduled for that group. If the strategy who failed had already failed before in the same round, the game is not rescheduled but the strategy is disqualified from the contest. All its remaining games in that round will not be carried out and all its previous games in that round will not be counted. This tournament is performed twice to find the winners of the contest: After the first tournament is performed, there is an eight day pause, during which the contestants can revise and change their strategy based on the game protocols of their games in the first contest (see below). Then the second tournament with identical rules and the same (or a reduced) set of participants is carried out. Those teams with the highest total rank in both tournaments will be announced as winners of the contest. See section 'requirements for programs' for additional rules. ---------------------------- Characteristics of the Game: ---------------------------- The method of counting within a game and the method of selecting the winners of a group have an interesting impact on the goal of a strategy: It must actually try to arrange a cooperation with its 'opponent', because otherwise none of the two will usually be able to win many points. It is NOT important to have more points than the opponent in any single game. Instead it is important to have more points than the other strategies on the average. The problem of programming a strategy could thus be formulated as "How do I (quickly) arrange a cooperation with a machine partner, if there is no predefined protocol to do so and the only communication channel is mutual exchange of integers, one at a time ?" It is clear, that there exists no optimal strategy: It is impossible to guarantee that a strategy A is able to arrange a cooperation with a strategy B, even if both are perfectly willing to cooperate in principle. This is true because both strategies have to 'guess' what might be suitable protocols to communicate. The two strategies of a game should together form a self-organizing system that organizes for cooperation. I think this makes the contest very interesting. By the way: This game is probably interesting to play with human players, too. ------------------------------ How to Announce Participation: ------------------------------ If you want to participate in the contest, send email of the following form: --- To: prechelt@ira.uka.de Subject: registration for KNOBELN email-address: ourname@machine.domain.alfdkj mail-preference: LAP,LGP,DGP,GRR team-name: the_heavy_lords_of_knobeln Organization: University of Northeast Sacrodata, Intellect City, Eggland team-members: Joe Cool, 45, professional systems programmer, 20-year-experienced programmer Jane More, 20, graduate student of computer science, hackeress fluent in 34 programming languages Mona Morn, 35, Professor of CS, hobby game strategy programmer Bill Neat, 24, undergraduate student of psychology, advanced beginner (will be my first C program!) --- Please use this format exactly as shown. - "email-address" gives the email address that uniquely identifies the team, it should be an internet domain style address. - "mail-preference" is a comma-separated list of some of the following declarators: LAP send list of all participants (full registration format) LGP send list of my groups' participants (team names only) DGP send detailed game protocol for each of my games (every throw) GRP send game result (points) for each of my games GRG send group result (all games of all participants) GRR send group result (ranking) - "team-name" can be any string that is a valid C identifier of at most 50 characters and should be a funny name for the team. - "Organization" should be the name of the institution the team is at or something else sensible, if no such thing exists. Please also give city and country (or state for the US). - "team-members" should contain a two-line informal description of each member of the team, giving his/her name, age in years, occupation, programming background, in this order. Team size should be anywhere between 1 and 10. Personnel should not be shared among teams. When I receive your registration, I will send an answer either (a) that your registration is not accepted, (e.g. because there are already too many participants registered), or (b) that your registration is accepted and your authentification string is . I may also tell you that I have slightly modified your team name, if it conflicts with an already registered one. Please allow some time (ca. 3 days) for the answer to arrive. Notes: - If you are unable to send email to me or if I am unable to send email to you, you can not participate in the contest. Please use only Internet domain style email addresses. - Notification of acceptance or rejection will usually be sent within 72 hours. I reserve the right to limit participation of multiple teams from the same organization. - You must keep the authentification string carefully. It will be used to check, whether a strategy that swears to come from your team really does (see below "Sending Programs"). ----------------- Sending Programs: ----------------- To send in the first version or a new version of your program, send me email of the following form: ---- To: prechelt@ira.uka.de Subject: please compile /* <> team_name authentification_string */ /* your source code goes here */ ---- <> has to be given exactly as shown. The same is true for the "Subject:". For insert the name of your team as given in the registration. For insert the string that I sent you with the registration acknowledge. Your program will be compiled automatically a few minutes after your email arrives and you will be sent a report about the results of the compilation. A successfully compiled program is automatically stored to be used in the contest. The latest version is used always. --------------------------- Requirements for programs: --------------------------- 1. Pure C (Ansi or KR), i.e., no library routines called, except int init_random () int log2 (int number) int next_random (int low, int high) int make_throw (int my_throw) int count_points (int throw1, int throw2, int *points1, int *points2); (You will receive a detailed description of these functions upon registration) 2. Must be compilable with GNU C compiler (gcc). 3. Must be in a single file, no #includes 4. Must have at most 10000 lexical elements (after preprocessing) Lexical elements are: identifier, keyword, number, string denoter, char denoter, special character NO lexical elements (i.e. not counted) are: blank, Tab, newline, comment Information about how many lexical elements your program has is sent to you as a report from automatic compilation as described above. 5. The size of the process that runs the program must not grow beyond 1024 kB on a SUN SparcStation 2 running SUN OS 4.1. The value used to test this is the one shown by 'ps -u' in the column labeled 'SZ' (SIZE). 6. Must finish every game of 1000 throws in less than 60 seconds of cpu time on a SUN SparcStation 2 (which has about 20 SPECmarks). ------------------------------ Recommendations for programs: ------------------------------ 1. Should not use floating point operations. (Or you do it on your own risk) 2. Should be infinite loop (i.e. need not terminate after 1000 throws) ----------------------- Technical Environment: ----------------------- In order to write and hand-test a strategy, you need the definitions of the library procedures mentioned above, called 'knobellib.c'. The source code for these functions is only 130 lines and will be sent to you via email with the notification of acceptance of your registration. Link your strategy with this module, but do not include the source code of the module into your strategy or else it will be rejected. If you want to run complete games between two strategies in the same kind of environment that will be used in the actual contest, you need the source code of the 'knobeln' program. You will need an ANSI-C compiler and a UNIX machine in order to compile and run it. There are two ways to get this source code (about 22 kB): 1. To get 'knobeln.c' by anonymous ftp (prefered method), fetch it from Sanfrancisco.ira.uka.de [129.13.13.110]: /pub/knobeln.c 2. To get 'knobeln.c' by mailserver, send email of the following form: --- To: prechelt@ira.uka.de Subject: SEND knobeln.c --- -------------------- The Actual Contest: -------------------- The actual tournaments will be run at the dates given below. At some time before, every team has to send its strategy as described above. It will be compiled and linked automatically, and you will receive a report about the success of this procedure or any problems that occur. This automatic compilation feature is disabled during the tournaments. During the contest, all participants will receive information about what happens, if they have announced a corresponding mail-preference upon registration: After every game, a detailed throw protocol or a short game result file (giving only the points at the end) is sent to both participants (if requested by their mail-preference, see in 'Registration' above); after every round the group summary is sent to all members of that group (if requested by their mail-preference). ------------- Legal Issues: ------------- By applying for registrations all members of a team assert that they understand and agree with the following points: 1. All participants of the last round of one of the tournaments will send a verbal description of how their strategy works (length 100 to 500 words) after the contest. 2. The team members allow the organizer of the contest to publish all or part of the information contained in the strategy program and in the strategy description. Such publication will mention the contest context and will give credit to the team by mentioning the team name or the team's organization or the names of one or several team members. ---------------------- Status of the contest: ---------------------- By now there are 29 participants registered. I will allow at most 104. ---------------- Important Dates: ---------------- 93/03/28 beginning of registration 93/03/31 beginning of registration acknowledge 93/03/31 beginning of compilation service 93/05/07 registration deadline 93/05/08 first tournament of contest 93/05/16 second tournament of contest 93/05/20 Results posted to Usenet: rec.games.misc, misc.misc Relevant time of day is noon, Universal Time (UT, GMT), for all dates. Good luck and have fun ! Lutz -- Lutz Prechelt (email: prechelt@ira.uka.de) | Whenever you Institut fuer Programmstrukturen und Datenorganisation | complicate things, Universitaet Karlsruhe; D-7500 Karlsruhe 1; Germany | they get (Voice: ++49/721/608-4068, FAX: ++49/721/694092) | less simple. From: pk6811s@acad.drake.edu Subject: Re: time-limit question Message-ID: <1993Apr5.080935.1@acad.drake.edu> Date: Mon, 5 Apr 1993 14:09:35 GMT In article <..> twolf@en.ecn.purdue.edu (Timothy W Wolf) writes: > If you were running a core war simulation with just 2 programs, say > maybe a forking program and an imp, with a short time limit, I know > that the time limit would cause a CPU time limit expired type error > on one of the programs causing a tie with the others. My question > is what determines which one would time out...would it be the order > in which the programs are run, in which case wouldn't it be the first > program ? Actually, one cycle is counted after every program has had its turn, regardless of the number of programs participating, then every program takes another turn and another cycle is counted. Thus every program gets the same number of turns no matter what the cycle-limit is. A tie is scored one point for each participant. -Paul pk6811s@acad.drake.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: What is a gate?? Message-ID: Date: Mon, 5 Apr 1993 14:46:27 GMT In article jesensky@mix.cs.psu.edu (James J Jesensky) writes: >Greetings... > >I've been away from corewars for a while and am trying to get >back into the game. Could someone explain the concept of a >gate? Also, when I left, there was talk of a new standard ('92) >with a more complex instruction set, interrupts, semaphores, etc. >Did anything come of this or was the idea of a new standard >moth-balled?? > >Thanks... >James > I feel lazy, so I'm just quoting from the FAQ: > 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, DAT As to your question about a new standard, a group of ten EBS members is currently putting together a draft proposal for ICWS94 (ready for the 10-year anniversary!), which will be submitted to the ICWS when ready. Sorry, no interrupts, semaphores, etc. :-), but likely a few additional opcodes. -Stefan (stst@vuse.vanderbilt.edu) From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: Re: What is a gate?? Message-ID: Date: Mon, 5 Apr 1993 19:29:42 GMT In article stst@vuse.vanderbilt.edu (Stefan Strack) writes: As to your question about a new standard, a group of ten EBS members is currently putting together a draft proposal for ICWS94 (ready for the 10-year anniversary!), which will be submitted to the ICWS when ready. Sorry, no interrupts, semaphores, etc. :-), but likely a few additional opcodes. -Stefan (stst@vuse.vanderbilt.edu) How about discussing it on the net? What have you come up with so far? ( I assume you're one of those ten) Anders Ivner From: CRJ14530@acuvax.acu.edu (Danger Maus) Subject: Anyone to help me? Message-ID: <1993Apr6.004333.22152@mprgate.mpr.ca> Date: Tue, 6 Apr 1993 00:43:33 GMT I am looking for someone that is willing to help me get started with this game I just found a copy and would like to learn it, but I am a bit(largly) confused. anyone that would be willing to give me a few hints, please mail me thanks in advance dm ++ _ _ +-------------------------+ || //\___/\\ | Danger Maus | || \_ O * _/ | aka: Christopher Judd | || \ / | T.G.S.A.I.T.W. | || \ / | (915)673-6228 | ++ ^ +-------------------------+ . ||\ ||\ ||\ Danger Maus \ (915)673-6228 || \ || \|| \ aka Christopher Judd || / || \| \ CRJ14530@ACUVAX.ACU.EDU /anger \aus\ BITNET%"CRJ14530@ACUVAX" . From: ama@athena.mit.edu (Albert Ma) Subject: New interpreter for 386's Date: 6 Apr 1993 02:16:50 GMT Message-ID: <1pqp6iINNh24@senator-bedfellow.MIT.EDU> Has anyone ever wanted to just run a massive number of simulations without caring about output? (I don't know why, maybe constant tweaking.) If you have a 386 or above computer you need the following program. It is about 20 times faster than C88V32. Written purely in assembly language. EXE size only 5500 bytes. Uses only 160K of memory. A new twist, instead of the interpreter shelling out to an editor, you can have an editor shell out to the interpreter. It is now in soda.berkeley.edu in the pub/corewars/incoming directory under mars.zip. This is a beta version. I can't find any more bugs but I'm in the process of optimizing the program (so it can be 5450 bytes and run 21 times faster than C88V32 :-) ) If you actually find this useful, email me (so I can charge you registration fees... just kidding). It would make my day. Since I'll probably never get on the hill (sigh), I want to make some contribution to this great game. If you find any bugs (ahhh, horrors) please let me know (unless it eats up your hard drive... just kidding). If you would want to see an 8086/80286 version, email me and I'll get to work on it (I need a life). Or if you just want to chat about how I achieve this speed. Albert Ma ama@athena.mit.edu (darn I need a sig) From: DURHAM@RICEVM1.RICE.EDU (Mark A. Durham) Subject: Recalcitrant Forwarding Message-ID: <16BA7144C3.DURHAM@RICEVM1.RICE.EDU> Date: Tue, 6 Apr 1993 04:05:38 GMT My mail server was forwarding my mail and would not cease no matter how much I pleaded with it until I got somebody with more clout to do it for me. If you tried to contact me at durham@ricevm1.rice.edu in March but were unsuccessful, try again now and be patient. I will reply eventually. Mark A. Durham durham@ricevm1.rice.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: New interpreter for 386's Message-ID: Date: Wed, 7 Apr 1993 02:46:04 GMT In article <1pqp6iINNh24@senator-bedfellow.MIT.EDU> ama@athena.mit.edu (Albert Ma) writes: > > If you have a 386 or above computer you need the >following program. It is about 20 times faster than C88V32. Written >purely in assembly language. EXE size only 5500 bytes. Uses only >160K of memory. > >Albert Ma >ama@athena.mit.edu Just downloaded it. The speed is simply awesome: 4-5 rounds/second on a 486/33. Terrific job, Albert! Cheers, Stefan (stst@vuse.vanderbilt.edu) From: pk6811s@acad.drake.edu Subject: _Push Off_ Message-ID: <1993Apr7.091844.1@acad.drake.edu> Date: Wed, 7 Apr 1993 15:18:44 GMT _PUSH OFF_ A midweek review of Corewar April 7, 1993 ------------------------------------------------------------------------------- I. The Standings: # %W/ %L/ %T Name Author Score Age 1 50/ 41/ 9 Agony 5.1 Stefan Strack 158 116 2 48/ 40/ 12 Dragon Spear c w blue 155 64 3 47/ 44/ 9 Medusa's v7 Mintardjo & Strack 150 255 4 46/ 43/ 11 Eclipse II P.Kline 148 232 5 45/ 43/ 12 Iron Gate Wayne Sheppard 148 918 6 45/ 44/ 12 Zipp c w blue 145 18 7 46/ 47/ 7 Juggernaut v1.4 Anders Ivner 144 14 8 36/ 28/ 36 Imprimis 6 P.Kline 144 362 9 44/ 43/ 13 Paratroops v2.1 W. Mintardjo 144 323 10 38/ 36/ 27 Nurgle c w blue 139 54 11 39/ 41/ 21 Leprechaun 1b Anders Ivner 137 874 12 32/ 28/ 40 Midnight Wayne Sheppard 137 6 13 32/ 26/ 42 It nandor sieben 137 1272 14 32/ 29/ 39 +0 Stormbringer Dan Nabutovsky 136 1392 15 32/ 29/ 39 Sphinx v2.8 W. Mintardjo 136 960 16 40/ 45/ 15 Emerald 4 P.Kline 134 21 17 39/ 46/ 15 Sucker 5 Stefan Strack 133 1256 18 38/ 43/ 19 Moonstone 1 Dan Nabutovsky 133 186 19 38/ 44/ 17 Herem II Anders Ivner 132 736 20 30/ 32/ 38 test Unknown 129 1 21 21/ 44/ 36 Demon2.2 Cormac Walsh 97 0 ------------------------------------------------------------------------------- II. The Basics: -Core War Archives are available via anonymous FTP at soda.berkeley.edu in pub/corewar... -FAQ for this newsgroup is available via anonymous FTP at rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.z ------------------------------------------------------------------------------- III. The Scoop: Spring Break seems to mean something other than beaches and bars for KotH competitors. The action has been furious! In the section below, The Quick Look, submissions are listed which fell short, or made it on the Hill in 19/20th position (or so). The number grows and grows, and what is not shown is the number of _duplicate_ submissions - I attempt to show only the highest score achieved. What a great game! A. K. Dewdney - you're keeping teenagers off the streets! [course it has been a while since SOME of us have seen teenage-hood :-)] Agony and Dragon Spear have been taking turns in first place, both scoring 50%+ wins at times. Did I say something about not seeing 50% wins for a while? Check out this top five: 1 52/ 40/ 8 Agony 5.1 Stefan Strack 165 69 2 50/ 39/ 11 Dragon Spear c w blue 162 17 3 41/ 21/ 38 It nandor sieben 161 1225 4 50/ 39/ 11 Iron Gate Wayne Sheppard 160 871 5 50/ 42/ 8 Medusa's v7 Mintardjo & Strack 157 208 Of course there were a couple of under-100 scores at the other end of the Hill :-) [How did It get up there with all those scanners?] Sometime it would be interesting to hear where these fighter-names come from. I finally figured out Agony and XTC - but it took me a while. But 'Nurgle'? 'Herem'? Not to be outdone in the Corewars emulator club, Albert Ma released a new ms-dos version which, according to early reviews, is a screamer. Thanks Ma - er, um, A.M.! W. Sheppard didn't waste anytime getting re-connected. He's been busy hammering away from his new residence: 21 32/ 57/ 11 I'm Back Wayne Sheppard 107 Unfortunately Wayne got back just in time to see his favorite, long-running stone/imp-spiral program get knocked off: 21 29/ 29/ 42 Night Wayne Sheppard 128 989 Just short of a thousand too, what a shame :-) D. Nabutovsky's been warming up some new fighters - maybe this had something to do with it: 19 32/ 28/ 40 +0 Stormbringer Dan Nabutovsky 136 1388 20 38/ 42/ 20 Moonstone 1 Dan Nabutovsky 134 182 which came back from E.J. Andrews' 'Paper-warrior' submission. Yup, paper warriors (replicators) definitely are hard on stones like Moonstone, and imps can't beat them either - only tie. And yours truly woke up and found a bug in Emerald 3, which made a _major_ difference in its performance. Turns out that this is NOT a gate: spl 0,<-5 dat <-7,#0 Now all you friendly Corewars-types had a chance to run Emerald 3, how come you didn't point this out to me? Along with this fix, I arranged things so instead of bombing the anti-vamp component with a dat #0, it is bombed with a 'jmp -1' which makes a faster core-clear. Emerald 4 has stayed up a week so far - hopefully some more bombers can make it up, then maybe we can get back to my favorite warrior form - replicators [I've given up on self- repairing fighters :-(] ------------------------------------------------------------------------------- IV. The Outlook: 2 39/ 20/ 41 G Paper /T W. Mintardjo 159 1 9 36/ 24/ 40 test 8b@s Unknown 148 1 6 45/ 43/ 13 Zipp c w blue 147 1 10 31/ 26/ 43 G Paper /T2 W. Mintardjo 137 1 6 43/ 45/ 12 Iron Gate 1.1 Wayne Sheppard 142 1 ------------------------------------------------------------------------------- V. The Quick Look: 21 27/ 49/ 24 j j.layland 104 0 21 20/ 71/ 9 r j.layland 69 0 20 30/ 50/ 20 v5 j.layland 109 1 21 5/ 82/ 13 Get Andre van Dalen 28 0 20 16/ 47/ 37 TS3 W. Mintardjo 85 1 21 9/ 85/ 6 Try Andre van Dalen 33 0 21 15/ 71/ 14 Coin Mestern 60 0 21 12/ 77/ 12 Get4 Andre van Dalen 46 0 20 33/ 48/ 20 Harm c w blue 117 1 21 24/ 75/ 1 Orff Fredrik 73 0 21 7/ 39/ 54 Zipp c w blue 75 0 21 20/ 77/ 3 bitz Paul Bobby 62 0 19 26/ 52/ 22 rock j.layland 101 1 20 31/ 31/ 38 test Unknown 130 1 21 4/ 64/ 32 test Anders Ivner 44 0 21 32/ 59/ 8 seek1 Sasha Wait 105 0 21 26/ 42/ 32 stone Sasha Wait 111 0 20 16/ 56/ 28 venio Sasha Wait 75 1 21 11/ 77/ 12 Dwarfs Andre van Dalen 45 0 21 13/ 80/ 7 Test 4 Sami Tammilehto 46 0 19 36/ 46/ 18 Zoiks! C. Parrinello 125 1 21 25/ 59/ 15 seek1b Sasha Wait 92 0 21 12/ 86/ 2 seek1d Sasha Wait 38 0 21 2/ 59/ 38 BACKIMP Paul Bobby 45 0 21 28/ 70/ 2 Blofeld Fredrik 86 0 21 36/ 53/ 11 Cleaver Wayne Sheppard 120 0 21 7/ 53/ 40 CraMPon c w blue 61 0 21 18/ 62/ 20 DemonII Cormac Walsh 74 0 21 2/ 72/ 27 GTZ 1.0 James Jesensky 31 0 20 2/ 35/ 62 No Hope Jeff Peters 69 1 21 11/ 81/ 8 Stapper Andre van Dalen 41 0 21 17/ 66/ 17 Sweeper E. J. Andrews 67 0 21 17/ 69/ 14 splits1 Sasha Wait 65 0 21 25/ 61/ 14 veniont Sasha Wait 88 0 21 28/ 50/ 23 Buzzbomb Paul Bobby 106 0 21 22/ 43/ 35 Demon2.2 Cormac Walsh 102 0 20 28/ 49/ 23 Orff 2.0 Fredrik 107 1 21 19/ 42/ 39 Rabbit 1 Mestern 97 0 20 26/ 69/ 5 Roadkill Jeff Peters 83 1 21 8/ 74/ 17 fire 1.0 James Jesensky 42 0 21 13/ 60/ 27 splits1b Sasha Wait 66 0 21 30/ 49/ 21 stone2dd Sasha Wait 111 0 21 18/ 82/ 0 Blah v1.0 Paul Bobby 54 0 21 12/ 58/ 31 Brimstone Sami Tammilehto 66 0 21 33/ 49/ 18 Discovery David Johnson 116 0 21 27/ 52/ 21 Simplex-9 Sami Tammilehto 102 0 21 1/ 47/ 52 pepper1.1 Hank Turowski 54 0 21 1/ 44/ 55 No Hope v2 Jeff Peters 58 0 21 25/ 42/ 34 Oculomotor Fredrik 108 0 20 31/ 62/ 7 Orff 1.1.1 Fredrik 101 1 21 11/ 81/ 8 Pepper 1.5 Hank Turowski 40 0 21 14/ 80/ 6 sub-type-c c w blue 47 0 11 32/ 25/ 43 test 87b@s Unknown 140 1 21 38/ 53/ 9 Light Speed Wayne Sheppard 123 0 19 35/ 46/ 19 Meteor v4.0 W. Mintardjo 125 1 21 1/ 68/ 30 ImpBreed-1.1 Jonathan Roy 34 0 21 12/ 67/ 21 Parasite v 4 Roderick Easton 58 0 21 9/ 46/ 45 Pirates v1.1 Brant D. Thomsen 71 0 19 41/ 54/ 5 Stoned Again c w blue 128 1 21 6/ 71/ 23 SuperImp 1.0 Jonathan Roy 41 0 19 39/ 49/ 12 sub-type-cmp c w blue 130 1 20 7/ 60/ 33 Brimstone 1.2 Sami Tammilehto 55 1 21 0/ 50/ 49 ImpLance2-1.0 Jonathan Roy 50 0 21 0/ 76/ 24 ImpLance3-1.0 Jonathan Roy 24 0 21 0/ 81/ 19 ImpLance4-1.0 Jonathan Roy 20 0 21 0/ 84/ 16 ImpLance5-1.0 Jonathan Roy 16 0 21 30/ 60/ 10 Simple-Bomber E. J. Andrews 101 0 21 30/ 58/ 12 BscannerBomber Wayne Sheppard 102 0 21 10/ 61/ 28 side-pipes 1.0 James Jesensky 59 0 21 4/ 54/ 43 superdwarf 1.0 Cliff Fitzmorris 54 0 21 1/ 69/ 29 DeathLance2-1.0 Jonathan Roy 33 0 21 1/ 92/ 7 ImpLance2-1.0-t Jonathan Roy 9 0 21 39/ 59/ 2 No Ties Allowed Wayne Sheppard 120 0 20 1/ 64/ 35 Self splitting imp W. Mintardjo 38 1 20 29/ 68/ 3 Thundering Buttucks Jordan Horwich 91 1 ------------------------------------------------------------------------------- VI. The Hint: The ADD instruction is used by many of the top programs to maintain their slim figures (size). This is because it adds both the A- and B-operands of the two designated locations. Thus with one ADD, a cmp-scanner can modify both locations of its comparison, a bomber can set up one location for decrement and one for bomb, and a vampire can create the appropriate jmp instruction for its target location. What other instructions act on both the A- and B- operands? Another slimming strategy is to use unrequired B-operands for storing pointers or other data. What instructions do not use their B-operand? ------------------------------------------------------------------------------- VII. The End: Paul Kline pk6811s@acad.drake.edu From: ama@athena.mit.edu (Albert Ma) Subject: New Corewars Interpreter for the 386 [update] Date: 7 Apr 1993 23:51:29 GMT Message-ID: <1pvpe1INNm5n@senator-bedfellow.MIT.EDU> Thanks to everyone for their support of my program. I've just uploaded a slightly revised version of my program to pub/corewar/systems. The old version in incoming has been deleted (Weird how they let me do that). No speed increase (well maybe a few machine cycles per corewars cycle). It just occupies 10K less of memory. (Okay, I'm obsessed with saving every byte of memory.) There's no real reason to get this new version unless you don't have it yet, or you need that 10K. Tips on use: Be careful if you try to run my program in a multitasking environment, windows for example. My program chains into the keyboard interrupt for about a 10% increase in speed. If another program like a TSR hooks into this interrupt while my program is running, my program might remove that hook along with its own. Also, I actually capture all the keys I encounter instead of passing them on to the next program in the link. So a TSR running before my program might not receive the interrupt. I'm not sure how windows handles these things, so there may or may not be a problem. I've also noticed that the escape key doesn't seem to work when I'm running the program through dos through windows. Minor annoyance. Well, have fun Please post or email me your comments or suggestions. However, don't expect me to start any big projects until the summer. Albert Ma ama@athena.mit.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 8 Apr 1993 00:00:07 -0400 Message-ID: Archive-name: games/corewar-faq Last-modified: 1993/03/18 Version: 2.0.3 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? 165 10. Where are the Core War archives? 181 11. Where can I find a Core War system for . . . ? 198 12. I do not have ftp. How do I get all of this great stuff? 215 13. I do not have access to Usenet. How do I post and receive news? 222 14. When is the next tournament? 233 15. What is KOTH? How do I enter? 242 16. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 344 17. How does SLT (Skip if Less Than) work? 356 18. What does (expression or term of your choice) mean? 368 19. Other questions? 496 --------------------------------------------------------------------- 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: Recent issues can be found on soda.berkeley.edu (see Q10). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- 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.149.19) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. 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: Thu, 8 Apr 1993 11:55:56 GMT In article <1993Apr7.091844.1@acad.drake.edu> pk6811s@acad.drake.edu writes: Sometime it would be interesting to hear where these fighter-names come from. I finally figured out Agony and XTC - but it took me a while. But 'Nurgle'? 'Herem'? The name 'Herem' is taken from the field of True Art - Fantasy literature!!! Herem is one of the ravers in Donaldsson's Covenant cronicles. (Which, by the way, is HIGHLY recommended.) What's special about 'Agony'? I just thought it meant 'pain'. Anders From: ama@athena.mit.edu (Albert Ma) Subject: problem with interpreter for 386 Date: 8 Apr 1993 15:28:03 GMT Message-ID: <1q1ga3INNe33@senator-bedfellow.MIT.EDU> Stefan Strack has informed me that my program is in one minor detail incompatible with most other interpreters. For those who understand my program uses in memory evaluation and everybody else uses in register evaluation. For those who don't understand (like me until now) here's what he sent me, taken from MAD's validation suite: ; PVS #12 start MOV 1, <1 stop DAT #0, #1 END start ; Result: Failure on second cycle at stop ; Memory: Unchanged! ; Explanation: This behaviour is open to interpretation. If one ; "completely" evaluates the A-operand first, one should make a copy ; of the instruction labelled "stop" as part of that evaluation. ; Then when the B-operand is completely evaluated as ; start + 1 + (1 - 1) = stop, the copy of the instruction labelled ; "stop" (prior to the decrement) is copied onto the instruction ; labelled "stop" (after the decrement), restoring "stop" to its ; initial state. ; There are those who would argue, and not without ; substantial basis, that there is no explicit reference in the ; standards to a "copy" and therefore the instruction labelled ; "stop" (after the decrement) should be copied onto itself. Thus ; stop would appear as "stop DAT #0, #0" after execution. Complete evaluation (copy- or in-register evaluation) is supported by MADgic Core, Core War Pro, mars88, c88v320, and most importantly, KotH v3.1. I'm getting to work on this as soon as possible. Until then I would stick to other programs for testing. Sorry for the trouble. By the way, when I upload the new version it will be called Mercury. SS pointed out to me that it was really confusing with all the MARS programs out there. Regards, Albert Ma ama@athena.mit.edu From: wsheppar@st6000.sct.edu (Wayne Sheppard) Subject: Anybody know about an email server? Date: 8 Apr 1993 15:59:30 -0500 Message-ID: <9304082056.AA37801@st6000.sct.edu> My school doesn't allow for newsgroups or telnet connections. Fortunately I still have Email. But I have no access to this newsgroup. If anyone knows of an Email server, please let me know. Wayne Sheppard wsheppar@st6000.sct.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: _Push Off_ Message-ID: Date: Thu, 8 Apr 1993 18:38:20 GMT In article d91andiv@IDA.LiU.SE (Anders Ivner) writes: >What's special about 'Agony'? I just thought it meant 'pain'. > It's a word-play and refers to its b-scanning predecessor XTC (read: Ecstasy) whose author's first name is incidentally also Stefan :-) -Stefan (stst@vuse.vanderbilt.edu) From: ama@athena.mit.edu (Albert Ma) Subject: 386 interpreter [again] Date: 10 Apr 1993 02:40:43 GMT Message-ID: <1q5c3bINN4rn@senator-bedfellow.MIT.EDU> Okay, I finally got around to changing that bug (or feature depending on which side you're on) in my interpreter. The latest version can be found in--you guessed it-- soda.berkeley.edu in pub/corewar/systems as mercury.zip. (as you may recall I renamed it from mars). In-register evaluation involves a little extra overhead, but, with some restructuring and careful cycle counting, I managed to keep the program's speed mostly unchanged. Some instructions may take longer, some instructions may take shorter. I did some more testing before releasing this version. These are the results (I don't pretend these are representative, I just had them handy): numbers are wins/ties per 100 Mercury KotH charon v70 49.8 49.9 charon v81 43.7 42.9 ties 6.5 7.2 rounds 600 1000 Imprimis v6 43.8 44.1 Winterwerewolf 28.8 26 ties 27.3 29.9 rounds 600 700 Moonstone v1 48 48.8 sucker v5 44.2 43.9 ties 7.8 7.3 rounds 500 2000 So at least my program can run those six programs :-) Did anyone ever encounter an "integer overflow error" or some other mysterious error while using a previous version of my program? (integer overflow would mean trying to give the interpreter an expression like 65536*65536) My program uses 32-bit integer math so an overflow should never occur (except when you're trying to cause one). Nandor says he got one, but I haven't been able to replicate it. Well, as usual, comments, suggestions, flames to Albert Ma ama@athena.mit.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: System validation Message-ID: Date: Sat, 10 Apr 1993 07:36:35 GMT The program below can be used to determine whether your corewar interpreter complies with ICWS88 and evaluates operands "in-register" (i.e. is compatible with KotH). It is based on Mark Durham's "Validation Suite" collection of code sniplets and adds some timing and core initialization tests. Results for the interpreters in soda's system directory that I could test: c88v320 - passes mars88 - passes mercury - passes KotH v3.1 - passes kothpc - fails (initializes with DAT #0,#0, mixed evaluation modes) corwp302 - fls (initializes with DAT #0,#0) Speaking of which, would somebody volunteer to put together a comparative review of interpreters for one or more of the platforms (PC,Mac,Amiga,UNIX)? This would become part of the FAQ or a separate regular posting. Contact me for details. (You should not be a system author for obvious reasons :-) Regards, Stefan (stst@vuse.vanderbilt.edu) ;redcode ;name Validate 1.0R ;author Stefan Strack ;strategy System validation program - based on Mark Durham's validation suite ; ; This program tests your corewar system for compliance with the ICWS88- ; standard and compatibility with KotH. It self-ties (i.e. loops forever) ; if the running system is ICWS88-compliant and uses in-register evaluation; ; suicides (terminates) if the interpreter is not ICWS compliant and/or uses ; in-memory evaluation. A counter at label 'flag' can be used to determine ; where the exception occured. ; ; Tests: ; -all opcodes and addressing modes ; -ICWS88-style ADD/SUB ; -ICWS88-style SPL ; -correct timing ; -in-memory vs. in-register evaluation ; -core initialization start spl l1 count djn count,#37 ;time cycles t1 dat #0,#1 t2 dat #0,#3 l1 spl l2 dat Could someone run the following program through their 486 and see if they get an error? It works on my 386, but apparently fails on Nandor's computer running a Cyrix 486. Please email me the result. thanks a lot Albert Ma ama@athena.mit.edu ;redcode ;Name aa ;kill aaa ;Author nandor sieben ;Strategy shift equ 37 begin add offset , start start cmp begin-shift , begin slt #17 , start djn begin , offset-2 mov bomb , @start sub start , @start add next , start jmn start , #3500 jmp 0 , <-20 ; spl 0 ,<-20 offset mov -2*37 , <-2*37 ; jmp 0 , <-22 trap mov bomb2 , <1 spl -1 , -37 jmp -2 next dat #-37 , <-37 bomb jmp trap-start-shift , -1 bomb2 end begin From: ama@athena.mit.edu (Albert Ma) Subject: yet another bug fix Date: 10 Apr 1993 22:50:49 GMT Message-ID: <1q7j09INN24b@senator-bedfellow.MIT.EDU> Well, it looks like I forgot to program in the immediate mode for the op codes jmn and jmz. That's fixed now. Must not have been used in the programs I tested. My program used to barf when a file ended in Ctrl-Z (generated by really old editors). It's hopefully fixed now. (Can't be sure I don't have one that does Control-z) Thanks to Stefan for pointing that out. My program would also go into an ininite loop when you specified a filename outside the current directory. That's fixed now. Thanks to W. Mintardjo for finding that one. The only thing left is that strange integer overflow error found by Nandor. Nobody else seems to have that problem. Best guess is Nandor's Cyrix 486 chip is doing some weird things. Anybody else out there with one? Download from soda.berkeley.edu in pub/corewar/systems as mercury.zip Please report anything weird to me. Albert Ma ama@athena.mit.edu From: ama@athena.mit.edu (Albert Ma) Subject: Another bug fix Date: 11 Apr 1993 06:34:33 GMT Message-ID: <1q8e5pINNc10@senator-bedfellow.MIT.EDU> Well, I bet this sounds familiar. Seems I created another serious bug last time when I tried to optimize a small section of code. Download from the usual place. Thanks again to SS for finding yet another bug. At least the compiler's always worked (uh oh, I guess it's due for a bug). To help you keep track, the newest version should print 4/11/93 1:59:49 when you run it without arguments. (I guess now you know what I do late at night) Sorry about all this mess. Please send comments, suggestions, bugs, flames to Albert Ma ama@athena.mit.edu From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: Another bug fix Message-ID: <1993Apr11.142220@IASTATE.EDU> Date: Sun, 11 Apr 1993 19:22:20 GMT In article <1q8e5pINNc10@senator-bedfellow.MIT.EDU>, ama@athena.mit.edu (Albert Ma) writes: > Well, I bet this sounds familiar. At least I now know how to spell Berkeley :-) | __L__ -|- ___ Warren Kurt vonRoeschlaub | | o | kv07@iastate.edu |/ `---' Iowa State University /| ___ Math Department | |___| 400 Carver Hall | |___| Ames, IA 50011 J _____ From: turowski@sciences.sdsu.edu (Hank Turowski) Subject: A new player Date: 12 Apr 1993 00:56:40 -0500 Message-ID: <9304120556.AA12411@sciences.sdsu.edu> Hello. Im a new corewar player, and have tried a few warriors out on the hill... I haven't done too well. Nothing Ive written has made it past 18th. I was wondering if anyone out there has a good help file for redcode. I also have a few specific questions I won't bore you all with here, but if one of you is willing to help through mail, please let me know. Thanks Hank Turowski turowski@sciences.sdsu.edu Date: Monday, 12 Apr 1993 02:50:27 MST From: Message-ID: <93102.025027ASMQK@ASUACAD.BITNET> Subject: icons I uploaded some corewar icons to soda. You can use them with windows. The filename is icons.zip Ouch. An imp just bit me. Nandor. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Summary of ICWS94 draft proposal Message-ID: Date: Tue, 13 Apr 1993 00:06:36 GMT Anders Ivner asked a while back - long enough for his post to expire here - about what changes we might see in the next corewar standard, ICWS94. I am giving a brief summary below. Keep in mind that the draft proposal (primary author Mark Durham) is still very preliminary, so this is all subject to change. We (i.e. the people in the committee) solicit your opinion on the proposed changes; feel free to discuss them here. Summary of ICWS94 draft proposal - redcode syntax is (for the first time) rigorously specified - MARS operation, ditto; resolving ambiguities in the ICWS88 standard (see in-memory/in-register evaluation) - a validation suite defines compatibility - assembly files: comma between operands required, parenthesis allowed, new pseudoop ORG (identifying first instruction to execute; same as END start) - a special load file format is introduced, allowing the separation of assembler and interpreter (this may or may not make it into the final version of the draft) - read/write distance limitations are added as tournament variables. (different from the current X-hill, out-of-range read/writes wrap around rather than fail) - a range of "tournament variable sets" (coresize, maxtasks, cycles-until-tie, etc.) for KotH, ICWS-tournaments are listed - more flexible opcode/addressing mode combinations (no illegal instructions) _VERY_PRELIMINARY_: - new addressing modes: postdecrement indirect, pre/postincrement indirect - new opcodes MUL,DIV,MOD,XCH - ADD/SUB revert back to ICWS86 behavior (no effect on A-operand) -Stefan (stst@vuse.vanderbilt.edu) From: wangsawm@prism.CS.ORST.EDU (W. Mintardjo) Subject: Re: Summary of ICWS94 draft proposal Message-ID: <1qdnegINNddc@flop.ENGR.ORST.EDU> Date: 13 Apr 93 06:43:28 GMT stst@vuse.vanderbilt.edu (Stefan Strack) in his article writes: [Intro & some other items skipped] >- read/write distance limitations are added as tournament variables. >(different from the current X-hill, out-of-range read/writes wrap around >rather than fail) > Rather than using it as a limitation, what's about using it as a feature? (i.e add an opcode that allows the wrapping) [others skipped] >- new addressing modes: postdecrement indirect, pre/postincrement indirect > nod >- new opcodes MUL,DIV,MOD,XCH > what happens to DIV by zero or MOD by zero? >- ADD/SUB revert back to ICWS86 behavior (no effect on A-operand) > In my opinion, the current implementation is very intriguing and tricky. Shouldn't miss it. One suggestion is to add an opcode which functioning as follows: Normally, after executing a non-jump instruction, a process would execute the instruction immediately succeding it. This opcode, say 'zzz 5, 0', would cause all the processes of that warrior to have 5 steps. Therefore, after executing a non-jump instruction, each of them would execute instruction which is 5 steps away and continued until reconfigured. Probably, this opcode sounds confusing. But imagine if one warrior was programmed to move backward while the other was to move forward, or to disrupt paper programs by landing this opcode singly on it, or to write imp as follows: ??? 3369 MOV 0, 3369 Just a suggestion > > >-Stefan (stst@vuse.vanderbilt.edu) Mintardjo W. From: guido@rbg.informatik.th-darmstadt.de (Guido Roessling) Subject: IMPERIUM wanted Date: 13 Apr 1993 07:27:13 GMT Message-ID: <1qdq0hINNhek@rs2.hrz.th-darmstadt.de> Hello, I'm looking for a multi-player PBEM called IMPERIUM (somewhat like VGA-PLANETS, but it plays on a single planet). I _know_ it's somewhere in the anonymous FTP (or at least, it was there), but (1) I can't remember where (and can't find it...), and (2) my version always crashes when I try to make a new map (and without a map, there's no game...). Also, the documentation does NOT include any addresses (EMail or SnailMail) of the producer(s). Can anybody help me ? Any (helpful) comments greatly appreciated, Guido guido@rbg.informatik.th-darmstadt.de From: bdthomse%peruvian.cs.utah.edu@cs.utah.edu (Brant Thomsen) Subject: Redcode Suggestions Date: 13 Apr 93 12:42:53 MDT Message-ID: <1993Apr13.124253.17986@hellgate.utah.edu> As long as the subject is being discussed, there is one suggestion I would like to recommend adding to the ICWS94 (draft) specifications: Allowing immediate operands in the "B" field for the ADD, SUB, and MOV operations. Using immediate "B" operands (in the extended languages where they are allowed) makes it much easier to reset or modify counters or pointers -- and makes it much easier to keep track of where they are. Just a thought ... -- ---------------------------------------------------------------------- Brant D. Thomsen Practice random acts of bdthomse%peruvian@cs.utah.edu kindness and senseless beauty. (University of Utah) From: pk6811s@acad.drake.edu Subject: Eclipse II (with comments) Message-ID: <1993Apr13.091531.1@acad.drake.edu> Date: Tue, 13 Apr 1993 15:15:31 GMT Since Eclipse II has been knocked off the Hill twice recently, I guess it's time to publish. (I did describe parts of it while it was successful :) Eclipse II went up and down KotH like a yo-yo, not so much depending on _what_ was put up as _who_ was putting it up. The theory behind it is simple: if you could find a piece of the opponent, what would you want to do to kill or stun the whole thing. For imps of any size, that would be taking the mov 0,xxxx instruction as a bombing increment and bomb until zero is found. For imps connected to their bombers, follow that step with a right-to-left bombing run, dropping to the next trail as each is finished. During this step, bomb 'through' (like Ike) to kill anything that was boot-strapped away. Even better, use a spl-minusone bomb in this step, if you can't kill all components, you might stun enough of them to make a difference. After the bombing runs, launch a set of small bombers tailored to deal with 2667-imps in case you missed them. If your opponent is a stone, he will be out-numbered by these bombers. As Eclipse II evolved, I added bits to deal with difficult opponents. Paratroops uses an initial scan phase also, and carpet-bombs right-to-left on discovery. So I added code to detect bombs in my next-phase code, and go to mouse if necessary. The spl-minusone bomb has a <57 b-operand which prevents Imprimis 6 from launching its second set of imps. I ran dozens of runs against Leprechaun and Herem to get the placement of the bomb-thru just right. There are three partial reflections at 12 which once gave some protection (but not anymore). Eclipse II beat most of the stone-imps, all of the vampires, some of the stones, and depending on the author - anything else. I have warned about leaving pointers to your active code laying around before. If you boot-strap your program away from a decoy, but leave pointers in the decoy, :-) The decoy is easy to find, so it doesn't take long to find your active code. Here is the (commented) source. Try starting at 'next': ;redcode quiet ;name Eclipse II ;kill Eclipse ;author P.Kline ;strategy bscan, ringkiller, avamp, clear->gate's ;strategy including ideas from Plasma, Paratroops, and old Eclipse ;strategy added mouse for emergencies (Paratroops attack) ;strategy small change in anti-vamp step equ 3094 hold equ scan-250 ptr equ scan-120 ptr2 equ ptr+1 minone equ scan-4000 splmin1 spl -1,<57 ; <57 is to keep Imprimis from launching 7-imp start sub #1,minone ; create a dat 0,7999 for comparison jmp next ; begin initial scan ref3 add @7933,7934 ; partial reflection mov 7984,<7933 mov 7983,@7931 cmp 7950,<7930 jmp 7995 jmn 7994,<7928 sub @52,@48 djn 7992,#8 spl 6 p2ck spl 26 jmp 16 clrback mov ptr,ptr2 ; using a spl-minusone bomb add @ptr,ptr2 ; bomb right to left mov splmin1, Date: Tue, 13 Apr 1993 18:58:22 GMT For better management of this discussion, I have taken the liberty of dating the draft (04/13/93) and numbering the individual proposals. Px is a draft proposition which has gathered some support, Tx is a trial proposition which is waiting support. ----------------------------------------------------------------------------- Summary of ICWS94 draft proposal 04/13/93 P1. - redcode syntax is (for the first time) rigorously specified P2. - MARS operation, ditto; resolving ambiguities in the ICWS88 standard (see in-memory/in-register evaluation) - a validation suite defines compatibility P3. - assembly files: comma between operands required, parenthesis allowed, new pseudoop ORG (identifying first instruction to execute; same as END start) P4. - a special load file format is introduced, allowing the separation of assembler and interpreter (this may or may not make it into the final version of the draft) P5. - read/write distance limitations are added as tournament variables. (different from the current X-hill, out-of-range read/writes wrap around rather than fail) P6. - a range of "tournament variable sets" (coresize, maxtasks, cycles-until-tie, etc.) for KotH, ICWS-tournaments are listed P7. - more flexible opcode/addressing mode combinations (no illegal instructions) _VERY_PRELIMINARY_: T1. - new addressing modes: postdecrement indirect, pre/postincrement indirect T2. - new opcodes MUL,DIV,MOD,XCH T3. - ADD/SUB revert back to ICWS86 behavior (no effect on A-operand) -Paul pk6811s@acad.drake.edu From: pk6811s@acad.drake.edu Subject: ICWS94 draft proposal Message-ID: <1993Apr13.134539.1@acad.drake.edu> Date: Tue, 13 Apr 1993 19:45:39 GMT P1,P3 - I would prefer that P1 and P3 be combined, so that the syntax is actually specified in terms of the assembler-input, rather than some intermediate form. That way people would not get stuck coding in a syntax that prevents them from sharing their source. That would also eliminate the need for P4 (I think). P2 - definitely P5,P6 - if I could specify in some header lines what variable-settings I wanted, then an experimental Hill could be set up to run me against a selected opponent with those settings. Talk about experimentation! P7 - is good, even though it is often the asymmetry of legal/non-legal that creates vulnerability in an otherwise strong program, by making it longer or more predictable. T1 - The only new addressing mode I like is pre-increment indirect, because it allows left-to-right copying/clearing as easily as we now have right-to-left. I suspect that post-increment/decrement would create 'new' capabilities that current programs don't have (like stacks). See my next comment on this. T2 - no, no, no. No new opcodes. Corewars was envisioned as a minimal-instruction game which could be easily learned by many people. The richness should be in the implementation of strategies and the ongoing struggle between authors, not in mimicking professional computer languages. I suggest that the game can be made more interesting by getting more people involved, not by expanding the language. What happens after the new innovations are 'exhausted' - more extensions? (where's that SORT statement anyway? :-) T3 - Nah. Having ADD/SUB operate on both the a- and b-operands seems to help all kinds of programs, and is too ingrained, so leave it alone. New trial proposition: Have settings brought into the program as 'global equates' like: csize = core-size mtask = max-tasks cylim = cycles-until-tie rdlim = read distance limit wrlim = write distance limit -Paul Kline pk6811s@acad.drake.edu From: lind0014@student.tc.umn.edu (Christian A Lindensmith-1) Subject: Re: ICWS94 draft proposal Message-ID: Date: Tue, 13 Apr 1993 22:16:30 GMT In article <1993Apr13.134539.1@acad.drake.edu> pk6811s@acad.drake.edu writes: >Have settings brought into the program as 'global equates' like: > csize = core-size > mtask = max-tasks > cylim = cycles-until-tie > rdlim = read distance limit > wrlim = write distance limit I like this idea a lot--it would make development on small machines easier while allowing code to be instantly portable to any other machine, larger or smaller. It would also allow tournaments to be run in which the submitted programs had no idea in advance what the precise values of the game parameters would be, while still enabling them to make decisions based on these parameters at run time. Chris Lindensmith lind0014@student.tc.umn.edu University of Minnesota From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Redcode Suggestions Message-ID: Date: Tue, 13 Apr 1993 23:46:23 GMT In article <1993Apr13.124253.17986@hellgate.utah.edu> bdthomse%peruvian.cs.utah.edu@cs.utah.edu (Brant Thomsen) writes: >As long as the subject is being discussed, there is one suggestion I >would like to recommend adding to the ICWS94 (draft) specifications: > > Allowing immediate operands in the "B" field for the > ADD, SUB, and MOV operations. > This is already in the proposal. Remember, "there are no illegal instructions". Personally, I agree with Paul Kline that redcode should remain as simple as possible. Of the proposed opcodes I find MUL,DIV,MOD just plain silly (at least until someone shows me that they open up entire new strategies). XCH, maybe; for symmetry post-increment indirect (>), the others are unnecessary (and we are running out of symbols for them :-). I am undecided about SUB/ADD: one on hand, reversion to ICWS86 behavior would kill today's small CMP-scanners and vampires; on the other hand, the present behavior is a real oddity borne out of the absence of a XCH instruction. Some other possible additions to the opcode repertoire I didn't mention include: -additional logical/comparison opcodes (e.g. SKE, "skip if equal", like CMP, except it only compares B-fields). -cousins of SPL: Mark, e.g. suggested "SPI", for SPlit Immediately, which implements the ICWS86 version of split (potentially very powerful for replicators) -Stefan (stst@vuse.vanderbilt.edu) Date: Tuesday, 13 Apr 1993 23:52:53 MST From: Message-ID: <93103.235253ASMQK@ASUACAD.BITNET> Subject: Re: Redcode Suggestions I totally agree, that mul, div and mod are not too interesting. Change the add and sub commands would affect a great amount of warriors on the hill. cmp scanners and and high tech stones are very interesting inventions. I think we should keep them alive. Nandor. Date: Wednesday, 14 Apr 1993 00:03:14 MST From: Message-ID: <93104.000314ASMQK@ASUACAD.BITNET> Subject: Re: ICWS94 draft proposal How about making decisions at compiling time ? If we have these global values then a couple of pseudo opcodes would be very usefull. Especially if else endif. By the way do we need two opcodes org and end with the same purpose ? I admit org seems more logical but it would be hard to get rid of end so why don't we just leave it that way. Nandor. From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Redcode Suggestions Message-ID: <1993Apr14.000737.13605@oucsace.cs.ohiou.edu> Date: 14 Apr 93 00:07:37 GMT In article <1993Apr13.124253.17986@hellgate.utah.edu> bdthomse%peruvian.cs.utah.edu@cs.utah.edu (Brant Thomsen) writes: >As long as the subject is being discussed, there is one suggestion I >would like to recommend adding to the ICWS94 (draft) specifications: > > Allowing immediate operands in the "B" field for the > ADD, SUB, and MOV operations. > >Using immediate "B" operands (in the extended languages where they >are allowed) makes it much easier to reset or modify counters or pointers -- >and makes it much easier to keep track of where they are. This is also one of the things we have been discussing... many of the topics we have been hashing include much of the extended rules that is being used by Koth-X (all modes allowed, write limit, etc). Scott -- Scott W. Adkins Internet: sadkins@bigbird.cs.ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet Subject: _Push Off_ Message-ID: <1993Apr14.093317.1@acad.drake.edu> From: pk6811s@acad.drake.edu Date: Wed, 14 Apr 1993 15:33:17 GMT _PUSH OFF_ A midweek review of Corewar April 14, 1993 ------------------------------------------------------------------------------- I. The Standings: # %W/ %L/ %T Name Author Score Age 1 40/ 20/ 40 Night Crawler Wayne Sheppard 159 44 2 49/ 41/ 11 Dragon Spear c w blue 157 146 3 38/ 20/ 41 NC III Wayne Sheppard 156 1 4 48/ 41/ 12 Zipp c w blue 155 15 5 48/ 44/ 8 Agony 5.1 Stefan Strack 152 198 6 37/ 23/ 40 Imprimis 6 P.Kline 150 444 7 47/ 45/ 8 Medusa's v7 Mintardjo & Strack 150 337 8 34/ 24/ 42 Sphinx v2.8 W. Mintardjo 144 1042 9 43/ 44/ 12 Iron Gate Wayne Sheppard 143 1000 10 32/ 22/ 46 +0 Stormbringer Dan Nabutovsky 142 1474 11 30/ 20/ 50 It nandor sieben 141 6 12 38/ 37/ 24 Leprechaun 1b Anders Ivner 139 956 13 42/ 47/ 11 Pippin v2.0 Arno M. Fuhlendorf 138 3 14 36/ 37/ 28 Nurgle c w blue 135 27 15 29/ 25/ 46 Silver Paper W. Mintardjo 133 75 16 40/ 48/ 12 Emerald 4 P.Kline 133 19 17 39/ 46/ 15 Sucker 6 Stefan Strack 131 66 18 39/ 48/ 12 Charon v9.0 Cisek,Strack,Kline 131 31 19 36/ 46/ 18 Eclipse III P.Kline 126 16 20 27/ 30/ 43 Consumption v2.0 Arno M. Fuhlendorf 124 8 21 12/ 78/ 10 Invest Andre van Dalen 47 0 ------------------------------------------------------------------------------- II. The Basics: -Core War Archives are available via anonymous FTP at soda.berkeley.edu in pub/corewar... -FAQ for this newsgroup is available via anonymous FTP at rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.z ------------------------------------------------------------------------------- III. The Scoop: Last week this newsletter reported the premature demise of W. Sheppard's Night warrior, the first of several long-standing imp-stone programs to fall of the Hill in months. Well, Mr. Sheppard did not take that kindly, no-siree-bob! He has unleashed a series of new fighters in what can only be called "The Week of Wayne's Weveange!". Cover your eyes children :-) First to fall victim to Wayne's attack was S. Strack's much-emulated Sucker 5, at the ripe old age of 1261. We all remember that Sucker 4 fell off the Hill just before making 1000 (when imps reappeared), so we could almost consider this an effective age of over 2000 -- almost! Course it didn't take long for Sucker 6 to appear and stake out a claim, (though it's not riding as high as it used to). Wayne's second victim was N. Sieben's mysterious 'It', another imp-stone program of long-standing (1282). Many times It seemed to be up when other imps were down and down when others were up. Just recently, It was sharing the top 5 with four scanners. But an unfortunate combination of opponents, and a determined Sheppard-attack was all-she-wrote for It. No telling yet how successful the new version of It will be :-). Not content to just knock fighters off of KotH, Wayne released his own stone-imp program, Night Crawler. Studying all those opponents must have given him an idea, 'cause NC is sitting pretty on top of the Hill. On top of that, his Iron Gate made 1000 just in time for this edition (hey, even electronic newsletters have lead times :-) D. Nabutovsky's +0 Stormbringer now has a 400+ lead in the geriatrics competition and still looks tough. Other programs of note to fall this week included Moonstone 1 by D. Nabutovsky (207), a surprising effective stone, and Paratroops v2.1 (393) by W. Mintardjo, which used a scan->bomb->multi-bomber strategy to good effect. Congrats to W. Mintardjo, whose Sphinx v2.8 has now passed 1000 challenges. A. Ma was kept busy handling bug-reports for his new Corewars emulator. As the old saying goes, 'if you never write anything, you will never get written up' or something like that. Hope you get time to work on fighters this week :-) C.W. Blue is a quiet fellow -- quietly been taking over the Hill :-) His Dragon Spear, Zipp, and Nurgle (and assorted sub-type-xxx's) are beating up on a lot of good fighters. Keep it up! ------------------------------------------------------------------------------- IV. The Outlook: 6 34/ 23/ 43 Silver Paper W. Mintardjo 145 1 7 43/ 43/ 14 Charon v9.0 Cisek,Strack,Kline 144 1 7 44/ 40/ 15 Sucker 6 Stefan Strack 149 1 10 39/ 36/ 25 Nurgle c w blue 142 1 6 36/ 24/ 40 Bronze Paper W. Mintardjo 149 1 3 49/ 40/ 11 Zipp c w blue 159 1 1 43/ 20/ 36 Night Crawler Wayne Sheppard 166 4 4 38/ 22/ 40 Test Wayne Sheppard 155 1 2 40/ 20/ 40 NC II Wayne Sheppard 160 1 2 36/ 20/ 44 NC III Wayne Sheppard 151 1 10 28/ 20/ 52 It nandor sieben 136 1 10 39/ 43/ 18 sub-type-ps c w blue 136 1 ------------------------------------------------------------------------------- V. The Quick Look: 21 32/ 47/ 22 v5 j.layland 116 0 21 9/ 82/ 9 Get Andre van Dalen 35 0 19 31/ 44/ 25 Rain Wayne Sheppard 119 1 21 14/ 85/ 1 seer Hank Turowski 43 0 21 30/ 32/ 37 test Unknown 129 2 21 31/ 66/ 3 Dwarf Magnus 96 0 20 26/ 68/ 5 Hunter Hank Turowski 84 1 20 23/ 59/ 18 Invest Andre van Dalen 88 1 20 27/ 30/ 43 Jester c w blue 123 1 21 28/ 50/ 22 Plasma Wayne Sheppard 106 0 21 28/ 36/ 37 Scaper c w blue 119 0 21 23/ 30/ 47 p2roba nandor sieben 115 0 21 11/ 84/ 6 Boinger Jason Grundy 38 0 21 38/ 51/ 12 CraMPon c w blue 125 0 21 20/ 68/ 12 DemonIV Cormac Walsh 71 0 21 27/ 42/ 31 DemonIII Cormac Walsh 111 0 21 21/ 73/ 6 Diplomat Rodney Kinney 68 0 20 28/ 35/ 37 RotLD 2.2 nandor sieben 121 1 21 3/ 67/ 30 Wimp v1.0 Brant D. Thomsen 40 0 19 33/ 48/ 20 Eclipse II P.Kline 118 1 18 40/ 51/ 10 Iron Fence Wayne Sheppard 129 1 21 1/ 90/ 9 LERSSI III Arto Vuori 12 0 18 39/ 46/ 15 Tomb Stone c w blue 132 1 20 21/ 78/ 1 sub-type-b c w blue 64 1 20 4/ 64/ 32 Ground-Zero E. J. Andrews 45 1 21 25/ 72/ 2 dumb bomber Hank Turowski 78 0 21 26/ 55/ 20 Ground-Zero+ E. J. Andrews 97 0 20 1/ 41/ 58 Hand of Doom Jarkko Lindblad 61 1 20 38/ 57/ 5 Stoned Again c w blue 120 1 21 33/ 52/ 15 sub-type-cmp c w blue 114 0 21 24/ 64/ 11 Diplomat 1.03 Rodney Kinney 84 0 21 27/ 55/ 18 Distance v1.1 Brant D. Thomsen 99 0 21 26/ 58/ 16 Distance v2.0 Brant D. Thomsen 95 0 21 32/ 39/ 29 Salamander II Anders Ivner 125 0 21 0/ 88/ 12 Validate 1.0R Stefan Strack 12 0 21 9/ 91/ 0 cheap-scanner A.T. Crowley 26 0 21 30/ 43/ 27 Am I Evil 10.0 Jarkko Lindblad 117 0 21 11/ 52/ 37 BscannerBomber Wayne Sheppard 70 0 20 37/ 47/ 16 Moonstone v1.1 Unknown 127 1 18 28/ 29/ 43 Consumption v2.0 Arno M. Fuhlendorf 128 1 21 23/ 56/ 20 Thundering buttocks Jordan Horwich 90 0 21 14/ 83/ 2 JG-HI2-Hopping Imp 2 Jason Grundy 45 0 ------------------------------------------------------------------------------- VI. The Hint: Newcomers to the game frequently confuse their recode assembler syntax with actual runtime code. Operators like * / + -, as well as EQU's and parens are only 'assembler' operators, they are evaluated before the program is loaded. An example: mov 100,@2*10 is changed to: mov 100,@20 If you are suspicious that your emulator is not doing what you think it should, take a look at the assembled instructions. ------------------------------------------------------------------------------- VII. The End: Paul Kline pk6811s@acad.drake.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: System reviews Message-ID: Date: Wed, 14 Apr 1993 16:16:22 GMT Ok, we have reviewers for deluxe, KotHv3.1, all PC packages and Core! for the Mac. Since they appear to be in widespread use, I would like a few more reviews on the PC systems. Also, MADgic Core for the Amiga is still up for takers. Contact me for guidelines. You don't need to be a corewar wiz to do a review; in fact, as a beginner you are probably much better at judging a programs ease-of-use and debugging- features. Thanks, Stefan (stst@vuse.vanderbilt.edu) From: wsheppar@st6000.sct.edu (Wayne Sheppard) Subject: Subtraction coreclear Date: 15 Apr 1993 01:43:03 -0500 Message-ID: <9304150640.AA32984@st6000.sct.edu> Subtraction coreclear, a new way to coreclear Look at this: ;Name No ties allowed mov <21,1+2234 sub 1,-1 jmp -2,-2234 After about 12,000 cycles, the move statement will decrement the sub statement and it will look like this: a mov <1,1212 b sub 1,-2 c jmp -2,-2234 As this runs, line c is subtracted from every location in the core. Line b actually does the subtraction, while line a decrements the pointer on line b. This almost acts like a DAT coreclear. Instead of MOVing a DAT at every location, line c is SUBtracted from every location. After the mod-2 bombing gets done first, the only things left (besides Paper and Imp) will be SPL 0. Sucker and other programs use the SPL 0 in a self-splitting loop to keep you honest. If the SPL 0 isn't on your bombing pattern, you need a coreclear to eliminate him. This is where the subtraction coreclear comes in. SPL 0 becomes SPL 2,2234. The process that was trapped by the SPL statement now scurries away a dies. I discovered this coreclear by accident, but since then I noticed it in Andy Pierce's Twill and Matt Hasting's SNM. Wayne Sheppard wsheppar@st6000.sct.edu PS: Coming soon, the code for Night Crawler From: maniac@lil-ed.cs.unlv.edu (Eric J. Schwertfeger) Subject: Re: Redcode Suggestions Message-ID: <1993Apr15.021546.11329@unlv.edu> Date: Thu, 15 Apr 93 02:15:46 GMT In article , stst@vuse.vanderbilt.edu (Stefan Strack) writes: ) From: stst@vuse.vanderbilt.edu (Stefan Strack) ) Subject: Re: Redcode Suggestions ) Organization: Vanderbilt University School of Engineering, Nashville, TN, USA ) Date: Tue, 13 Apr 93 16:46:23 PDT ) ) In article <1993Apr13.124253.17986@hellgate.utah.edu> bdthomse%peruvian.cs.utah.edu@cs.utah.edu (Brant Thomsen) writes: ) >As long as the subject is being discussed, there is one suggestion I ) >would like to recommend adding to the ICWS94 (draft) specifications: ) > ) > Allowing immediate operands in the "B" field for the ) > ADD, SUB, and MOV operations. ) > ) ) This is already in the proposal. Remember, "there are no illegal instructions". ) ) Personally, I agree with Paul Kline that redcode should remain as simple as ) possible. Of the proposed opcodes I find MUL,DIV,MOD just plain silly (at ) least until someone shows me that they open up entire new strategies). Hmmm, what was that program I was thinking of a long time ago that needed DIV? Or was it MOD? I don't know, but I remember a few ideas biting the dust for want of one of these instructions. ) XCH, maybe; for symmetry post-increment indirect (>), the others are ) unnecessary (and we are running out of symbols for them :-). ) I am undecided about SUB/ADD: one on hand, reversion to ICWS86 behavior ) would kill today's small CMP-scanners and vampires; on the other hand, ) the present behavior is a real oddity borne out of the absence of a XCH ) instruction. ) ) Some other possible additions to the opcode repertoire I didn't mention ) include: ) ) -additional logical/comparison opcodes (e.g. SKE, "skip if equal", like ) CMP, except it only compares B-fields). I've always wanted SKE (or SEQ). ) ) -cousins of SPL: Mark, e.g. suggested "SPI", for SPlit Immediately, which ) implements the ICWS86 version of split (potentially very powerful for ) replicators) ) ) -Stefan (stst@vuse.vanderbilt.edu) Not a good idea, IMHO. SPI would be far to powerfull as a bomb (same as SPL was under '86 rules), unless something else is changed as well. I haven't had the chance to read the new standard yet, though. -- Eric J. Schwertfeger, maniac@cs.unlv.edu From: sadkins@bird07.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Redcode Suggestions Message-ID: <1993Apr15.125730.8831@oucsace.cs.ohiou.edu> Date: 15 Apr 93 12:57:30 GMT In the last article, maniac@lil-ed.cs.unlv.edu (Eric J. Schwertfeger) writes: >) Personally, I agree with Paul Kline that redcode should remain as simple as >) possible. Of the proposed opcodes I find MUL,DIV,MOD just plain silly (at >) least until someone shows me that they open up entire new strategies). > >Hmmm, what was that program I was thinking of a long time ago that needed >DIV? Or was it MOD? I don't know, but I remember a few ideas biting the >dust for want of one of these instructions. Was it all of those binary tree programs that people were trying to write? I seem to recall that the DIV instructon was useful there... (but it was possible to write such programs without them...) All in all, I favor the addition of the XCH instruction the most. I still have debates about the PCT instruction, but I think it would be nice to add it, if not only for the reason that it was one of the few instruction that was suggested in the original articles of Corewar. Yes, it doesn't really add much to the game (PCT is really kinda week), but it would add a little more dimension to the game without making it too complex or imbalanced. As for the MUL, DIV, and MOD instruction, doesn't make too much difference to me. I don't have much use for them, but somebody else might. I doubt that many programs will find uses to them, so who knows... >) -additional logical/comparison opcodes (e.g. SKE, "skip if equal", like >) CMP, except it only compares B-fields). > >I've always wanted SKE (or SEQ). I do not like the idea of adding a lot of compare instructions. But, it seems that the current set is inadequate, non-symmetric, and inconsistant. I think if equal is in order, and seq would be the best name for it, and just B-fields would be good (all in all, just as Stefan said in the first place... :-) >) -cousins of SPL: Mark, e.g. suggested "SPI", for SPlit Immediately, which >) implements the ICWS86 version of split (potentially very powerful for >) replicators) > >Not a good idea, IMHO. SPI would be far to powerfull as a bomb (same as >SPL was under '86 rules), unless something else is changed as well. >I haven't had the chance to read the new standard yet, though. Yeah, it is definitely *not* a good idea to re-introduce the SPL '86 back into the rules. It was too powerful and not much that could be done about it. IMHO, one SPL instruction (or any process splitting instruction) is good enough for me... :-) Scott -- Scott W. Adkins Internet: sadkins@bigbird.cs.ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: processcounter Message-ID: Date: Thu, 15 Apr 1993 15:06:25 GMT Just an idea: How about a run-time variable that keeps track of the number of processes running? Could be implemented as a new addressingmode. SLT #10, PCR (ProcessCountRegister) It doesn't seem to have any aggressive potential, but could be useful in replicator/imp/bomber/whatever-combinations. One more thing, what about having SPL split to both operands (but not to the next instruction)? hmm.. I suppose this would make SPL 0,0 too powerful. Anders Ivner From: wsheppar@st6000.sct.edu (Wayne Sheppard) Subject: RE: Process count Date: 15 Apr 1993 23:48:44 -0500 Message-ID: <9304160445.AA08942@st6000.sct.edu> -In article <...> d91andiv@IDA.LiU.SE (Anders Ivner) writes: -> Just an idea: How about a run-time variable that keeps track of the -> number of processes running? Could be implemented as a new addressingmode. -> -> SLT #10, PCR (ProcessCountRegister) -> -> It doesn't seem to have any aggressive potential, but could be useful in -> replicator/imp/bomber/whatever-combinations. -> - -What could be done with PCR? A replicator that only wanted a limited -number of copies - but would still replace any that died. That would -be very handy in balancing replicator/stone timing. A self-repairing -program that would know when it had been spl-bombed - still couldn't -fix it however :(. A way to tell when one component had been killed -or crippled. The best thing would be if I could use PCR or JMC or whatever to tell how many processes the enemy had. Then I could tell what the enemy was doing by how many processes he had. - -Maybe an operator would be more consistent, like: - JMC a,b -which would jmp to a if the process count was greater than b. - -Another idea is an instruction that would remove the next X processes -from my task list. So that: - EGO a -would remove a processes, up to but not including the current process. -Then we could overcome SPL-carpets with a single instruction. Replicators -would still be slowed down - they have to allow a certain large number of -processes anyway - but they might make a comeback. This has the potential of being a very powerful bomb. I just nail you with EGO 7999 followed by DAT and you are DEAD. No coreclear needed. - -These are interesting, but my preference would be to put any new operators -out in an 'experimental' status, not part of the base standard, until -they have had a lot of time to be studied. - --Paul -pk6811s@acad.drake.edu Wayne Sheppard From: pk6811s@acad.drake.edu Subject: Re: processcounter Message-ID: <1993Apr15.210251.1@acad.drake.edu> Date: Fri, 16 Apr 1993 03:02:51 GMT In article <...> d91andiv@IDA.LiU.SE (Anders Ivner) writes: > Just an idea: How about a run-time variable that keeps track of the > number of processes running? Could be implemented as a new addressingmode. > > SLT #10, PCR (ProcessCountRegister) > > It doesn't seem to have any aggressive potential, but could be useful in > replicator/imp/bomber/whatever-combinations. > What could be done with PCR? A replicator that only wanted a limited number of copies - but would still replace any that died. That would be very handy in balancing replicator/stone timing. A self-repairing program that would know when it had been spl-bombed - still couldn't fix it however :(. A way to tell when one component had been killed or crippled. Maybe an operator would be more consistent, like: JMC a,b which would jmp to a if the process count was greater than b. Another idea is an instruction that would remove the next X processes from my task list. So that: EGO a would remove a processes, up to but not including the current process. Then we could overcome SPL-carpets with a single instruction. Replicators would still be slowed down - they have to allow a certain large number of processes anyway - but they might make a comeback. These are interesting, but my preference would be to put any new operators out in an 'experimental' status, not part of the base standard, until they have had a lot of time to be studied. -Paul pk6811s@acad.drake.edu From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: processcounter Message-ID: <1993Apr16.131647.8613@oucsace.cs.ohiou.edu> Date: 16 Apr 93 13:16:47 GMT In the last article, d91andiv@IDA.LiU.SE (Anders Ivner) writes: >Just an idea: How about a run-time variable that keeps track of the >number of processes running? Could be implemented as a new addressingmode. > > SLT #10, PCR (ProcessCountRegister) > >It doesn't seem to have any aggressive potential, but could be useful in >replicator/imp/bomber/whatever-combinations. This seems to violate the idea that warriors don't know the details of the battles... (like, absolute addresses, etc). I think constants would be accepted, since they will be known *before* the battle begins and will not change during the course of the battle. PCR is not known before and is volatile... just something I wouldn't support. But, if it is supported, it would be the easiest thing in the world to implement (I think...) :-) Scott -- Scott W. Adkins Internet: sadkins@bigbird.cs.ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: wsheppar@st6000.sct.edu (Wayne Sheppard) Subject: Night Crawler - the code Date: 16 Apr 1993 14:19:24 -0500 Message-ID: <9304161916.AA46448@st6000.sct.edu> After watching many battles between Night and Iron Gate, I recognized the weakness of Stone/Imp. The imps rarely get stunned. Only a hit at the head would get it. A hit anywhere else would quickly be overwritten. The scanners usually stunned the stone, making the imps a sitting duck. Also gone are the days when the imps would get the kill. With every warrior having a gate or some other imp defence, the stone was the place to get the win. Like most of the older impspiral/dwarfs, Night had a very slow startup. I was using a Nimbus style startup. 16 process impspiral took a long time to launch. The first imp did not execute until after 100 cycles had passed. Of course this made the stone start slow, so I had to split a lot of processes to it to speed it up. To make improvements, I went to a smaller spiral with a quicker binary launch. The first imp executes on the 35 cycle. This made the stone much quicker. The seven process imp spiral can run into a coreclear before it has set up a gate. This turns many losses into ties or wins. The stone part is a four line dwarf with a subtraction coreclear. Copied away from the decoy, it is a very small target for scanners. # of DAT bombs for Cycles Night Night Crawler 100 6 15 200 17 37 300 35 62 500 81 115 As you can see, the stone puts out bombs quicker that before. Score results for NC III against scanners --------------------------- W L T 226 Charon v9.0 73 20 7 220 Agony 5.1 71 22 7 198 Iron Gate 62 26 12 192 Medusa's v7 61 30 9 173 Dragon Spear 55 37 8 And finally the code: ;redcode ;name Night Crawler III ;author Wayne Sheppard ;wsheppar@st6000.sct.edu ;strategy Forward decrement ;kill NC III ; ;Night Crawler is an improvement over the standard imp/stone. ;The features: ; -quick startup, bombing starts immediately ; -small ring lets stone run faster ; -small ring can gate crash slow coreclears ; -small profile stone is smaller target for scanners ; -large decoys to confuse scanners ; -forward decrementing, might disable Paratroop attack imp equ impcopy+1700 ;imp start hide equ 1600 ;stone location stone spl 0,<-1001 ;Stone is only four lines long mov <21,1+2234 ;Bombs at light speed sub 1,-1 ;mod 2 pattern djn -2,<-2234 ;converts to addition coreclear dat Date: Fri, 16 Apr 93 17:52:35 PDT I missed the explanation of what XCH does, so I'll ignore what I think it does and just offer my suggestions. I'd like to be able to work with the A field as easily as with the B field (maybe a new mode for this?); see some complementary branching instructions (SLT exists, but SEQ, and SGT do not.); and perhaps my favorite I'd like to be able to read the 'value' of the instruction and change it. Anybody else? Charles_K_Hughes@cup.portal.com From: tftel@tftsys.hacktic.nl (Thomas F. Telkamp) Subject: Corewar (PC) Message-ID: Date: Sat, 17 Apr 93 13:25:10 GMT Hello, What is the latest version of Corewar for IBM-compatibles? I'm now using Mars v 1.01, I believe this is a rather old version. Could somebody E-mail me a newer version (PC executable). I dont't have FTP access, so I can't download it myself. Thanks in advance, _______________________________________________________________________ Ossendrechtseweg 58 ------------------- 4631 BD Hoogerheide Thomas F. Telkamp The Netherlands ------------------- Voice: +31-1646-13776 E-Mail: tftel@tftsys.hacktic.nl Subject: SUGGESTION: new pseudo opcode Message-ID: <1993Apr18.123631.10769@wisipc.weizmann.ac.il> From: fedimit@wisipc.weizmann.ac.il (Dan Nabutovsky) Date: Sun, 18 Apr 1993 12:36:31 GMT REP n means that the next command should be repeated n times. For example, REP 5 DAT #1 is equivalent to DAT #1 DAT #1 DAT #1 DAT #1 DAT #1 DaN Date: Sunday, 18 Apr 1993 17:21:29 MST From: Message-ID: <93108.172129ASMQK@ASUACAD.BITNET> Subject: macrored I uploaded macrored to soda. It's a macroprocessor that implement the pseudoopcode for. Please send me your comments. Nandor. This is before macrored.exe dat #2 for 3 labelfor spl 0 jmp labelfor dat #for*3+1 rof start mov 0,1 end start This is after macrored.exe dat #2 label001 spl 0 jmp label001 dat #001*3+1 label002 spl 0 jmp label002 dat #002*3+1 label003 spl 0 jmp label003 dat #003*3+1 start mov 0,1 end start From: ama@athena.mit.edu (Albert Ma) Subject: No, it's not another bug fix Date: 18 Apr 1993 23:14:43 GMT Message-ID: <1qsnd3INN1ge@senator-bedfellow.MIT.EDU> Well, it's been just over a week since I received my last bug report. I hope this means that my program is working perfectly now. For anyone truly obsessed with speed, I've uploaded a new version (dated 4-18) that actually manages to save 4 cycles (2 for the 486) per (corewar) cycle over the previous version. That means if there are an average of 40000 (corewar) cycles in a round and 1000 rounds are played on a 486/33 you will save 2.4 seconds. Ooooh ahhhh There are no other changes. Amazing what changing 4 lines of code can do. For those of you who weren't here just over a week ago, it can be found at (everybody repeat at the same time) soda.berkeley.edu in pub/corewar/systems as mercury.zip. I'm planning to write a separate version that will do a core display also, no debugging. I've decided on VGA 80*50 text mode (2 cells per character). Any suggestions for the exact format of the output are greatly desired. I will use direct display writing like the other guys. Anybody know how to do this in VGA? Hopefully I can have it done by finals, otherwise I don't know if I'll have a computer to program on (and I may be cut off from the net). To Nandor: don't use this version as overflow checking is still there email me if you want a modified version. Have a nice day/week/month Albert Ma From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: New version of Core Wars Deluxe (v2.0b) Message-ID: <1993Apr19.003712.6025@oucsace.cs.ohiou.edu> Date: 19 Apr 93 00:37:12 GMT I corrected a couple of bugs and worked on "debugging" a little bit for the Core Wars Deluxe package. Naturally, you will find it at the ftp site soda.berkeley.edu. Currently, it is in /pub/corewar/incoming, but it will be moved to /pub/corewar/systems here soon. The new package is now called deluxe20b.README and deluxe20b.tar.Z. Here is a list of changes: 1) The CMP instruction was fixed, since it failed to check for the modes when comparing whole instructions against other instructions. I have no idea how this one got past me... but it did :-) 2) Added a "Dump Core" option to the command line display options. If this option is chosen, then the core will be dumped to the screen (or file) while leaving out the addresses of the core that were never modified (still DAT 0, 0). I did this in order to cut down on the size of the output. It helps tremendously when debugging only one program. 3) Added a #define called PCID which allows the program to assign ID numbers to each process. The ID number assigned will be essentially X-Y, where X is the number of the warrior and the Y is the number of the process (starting at 1 and increasing with each new processes... it will wrap around when it runs out of numbers... in most cases, 65535). If PCID is not compiled in, then all of the process ID's will become X-0. 4) Cleaned up the "Show Execution" option that can be chosen from the command line display options. If this option is chosen, then every instruction that gets executed in the core will be dumped to the screen (or file). The information that is provided includes what address the instruction is at, the contents of the memory location, the process id of the instruction being exected, the memory locations being pointed to by the A and B fields directly, and the memory locations being pointed to by the A and B field indirectly, and finally, the cycle number at time instruction is executed. One more note: I have discoverd that the DOS version does not behave correctly with the SUB instruction (and maybe the ADD as well). I am working on this problem and will get it fixed in the next week. When this is done, I will make a new release and include the DOS executables along with the package. Any questions, bug reports, or just good ol' conversation should be sent to me at sadkins@ohiou.edu. Enjoy! :-) Scott -- Scott W. Adkins Internet: sadkins@bigbird.cs.ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: wsheppar@st6000.sct.edu (Wayne Sheppard) Subject: Iron Sword Date: 19 Apr 1993 12:01:29 -0500 Message-ID: <9304191658.AA08850@st6000.sct.edu> I've tried to develop a scanner that wouldn't need a gate. I got a little success. Last night, using mercury, I ran 25,000 battles. 500 battles for each step size from 2 to 100. The best step for killing imps was 54 with 163 kills out of 100. In desperation I tried a 3 point clear, which worked better, but not good enough. But it can't score enough, so I post it for the general public. ;redcode-quiet ;name Iron Sword ;author Wayne Sheppard ;strategy Cmp scanner/No gate/3 point coreclear dist equ 34;94,98,42,54 <-these numbers worked good also sub off,@x loc cmp dist,0 slt #20,@x djn -3,j mov j,@loc x mov s, Message-ID: <93111.143001ASMQK@ASUACAD.BITNET> Subject: Re: _Push Off_ I just want to show how to implement 2 of the macros mentioned in macrored. 1. copy the next M lines N times. for N . ; line 1 . . ; line M rof 2. bootstrap M lines from 'begin' to the position 'newloc' for M mov begin+for-1,newloc+for-1 rof Nandor. From: pk6811s@acad.drake.edu Subject: _Push Off_ Message-ID: <1993Apr21.100141.1@acad.drake.edu> Date: Wed, 21 Apr 1993 16:01:41 GMT _PUSH OFF_ A midweek review of Corewar April 21, 1993 ------------------------------------------------------------------------------- I. The Standings: # %W/ %L/ %T Name Author Score Age 1 38/ 21/ 41 Night Crawler Wayne Sheppard 154 112 2 47/ 44/ 9 Backstabber Anders Ivner 150 32 3 46/ 45/ 8 Agony 5.1 Stefan Strack 148 266 4 35/ 25/ 40 Imprimis 6 P.Kline 145 512 5 44/ 44/ 11 Dragon Spear c w blue 145 214 6 45/ 46/ 9 Medusa's v7 Mintardjo & Strack 144 405 7 33/ 23/ 44 +0 Stormbringer Dan Nabutovsky 143 1542 8 33/ 24/ 43 Sphinx v2.8 W. Mintardjo 143 1110 9 32/ 22/ 46 Silver Paper W. Mintardjo 143 143 10 43/ 46/ 11 Zipp c w blue 141 21 11 42/ 44/ 14 Sucker 6 Stefan Strack 140 134 12 42/ 45/ 13 Iron Gate Wayne Sheppard 139 1068 13 39/ 40/ 21 Leprechaun 1b Anders Ivner 138 1024 14 30/ 22/ 48 Itt nandor sieben 137 40 15 37/ 37/ 27 Nurgle c w blue 137 95 16 31/ 27/ 42 Full moon Dan Nabutovsky 135 7 17 41/ 48/ 12 cproba nandor sieben 133 39 18 40/ 47/ 13 Emerald 4 P.Kline 132 87 19 32/ 53/ 16 Zoiks! C. Parrinello 110 8 20 24/ 50/ 26 Passport P.Kline 98 1 21 1/ 2/ 1 sub-type-aix c w blue 5 2 ------------------------------------------------------------------------------- II. The Basics: -Core War Archives are available via anonymous FTP at soda.berkeley.edu in pub/corewar... -FAQ for this newsgroup is available via anonymous FTP at rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.z ------------------------------------------------------------------------------- III. The Scoop: This week we have a little of the old, and a little of the new. For the old, a big round of applause to +0 Stormbringer which passed 1500, and also to A. Ivner whose Leprechaun 1b has joined the over-1000 ranks (the over-the-hill gang? :-) In the new category, S. Adkins released a new version of Core Wars Deluxe (v2.0b) and deserves many thanks for supporting CoreWars. Also Nandor Sieben has created a program 'macroed' which takes limited-shorthand input and creates standard redcode. This may be the beginning of a whole new generation of tools for program-writing. Imagine a program which could process instructions like: - copy the next M lines N times - insert the step-increment that optimally bombs M locations without bombing the previous N locations - make me a copy routine to bootstrap M locations starting at location X and write them at location Y - include xxx-program here - ??? (your imagination needed here) Take note of S. Halvorsen's re-entry into the fray, ImpStop, bearing these warnings: ;Strategy This is my first attempt in a long time, so if you beat ;Strategy me, I'll just have to come back with something worse ! Well, sticks and stones may break my bones, but let's see those scores! :-) Did anyone else note the 'irony' in Wayne's comment announcing the source-posting of Iron Sword: "But it can't score enough, so I post it for the general public." Gee, thanks. Lastly, if I had a program that scored like this, I would probably call it 'pu' too :-) 21 11/ 70/ 19 sub-type-pu c w blue 51 -well, actually I have quite a few programs that score like that :-( ------------------------------------------------------------------------------- IV. The Outlook: 1 47/ 44/ 9 Backstabber Anders Ivner 151 1 10 30/ 23/ 47 Night Crawler III Wayne Sheppard 137 1 7 45/ 47/ 8 Juggernaut v1.5 Anders Ivner 143 1 2 35/ 18/ 47 Test Crawler Wayne Sheppard 152 1 2 40/ 21/ 40 sub-type-aix c w blue 159 1 10 28/ 19/ 53 proba nandor sieben 138 1 10 43/ 46/ 11 CraMPon c w blue 140 1 ------------------------------------------------------------------------------- V. The Quick Look: 21 7/ 86/ 7 ik j.layland 28 0 17 24/ 21/ 54 Itt nandor sieben 127 1 21 34/ 62/ 4 ugh j.layland 106 0 21 1/ 0/ 4 Zipp c w blue 6 61 21 19/ 77/ 4 test j.layland 61 0 20 35/ 51/ 14 Irony Wayne Sheppard 120 1 21 30/ 64/ 6 Snake Wayne Sheppard 95 0 21 29/ 61/ 11 Wedge Rodney Schuler 97 0 21 32/ 60/ 8 test1 j.layland 103 0 21 9/ 82/ 9 Dwarfs Andre van Dalen 35 0 21 23/ 69/ 7 Invest Andre van Dalen 77 0 20 33/ 50/ 17 Zoiks! C. Parrinello 116 1 19 39/ 50/ 12 cproba nandor sieben 127 1 21 22/ 24/ 53 p2roba nandor sieben 120 0 21 24/ 70/ 6 spy2.0 Kirk Gorden 79 0 19 33/ 51/ 16 test 2 P.Kline 116 1 21 20/ 74/ 7 Blofeld Fredrik 65 0 18 41/ 48/ 12 CraMPon c w blue 134 1 21 18/ 74/ 7 DemonIV Cormac Walsh 62 0 21 20/ 52/ 28 ImpStop S. Halvorsen 88 0 21 6/ 61/ 33 cmp-add Wayne Sheppard 50 0 20 27/ 68/ 5 Bscanner Wayne Sheppard 86 1 21 4/ 31/ 65 Buzzbomb Paul Bobby 78 0 21 6/ 91/ 3 DNA ring A.T. Crowley 22 0 21 24/ 43/ 33 DemonIII Cormac Walsh 105 0 21 0/ 93/ 7 Dust 1.1 Paul Svensson Message-ID: <93111.184244ASMQK@ASUACAD.BITNET> Subject: mars88 I uploaded a new version of mars88 to soda. The macrored included here is little bit better. The old one doesn't like sapaces at the end of the for macro. New feature: Supports macrored.exe or similar macroprocessors. The name of the macroprocessor is given in the mars88.int file . If the extension of a file is not red, than mars88 calls the macroprocessor given in the mars88.int file with the file name as parameter. The macroprocessor should give a non-zero dosexit code if something went wrong. Please don't use the extension rec . It is a good idea to keep a copy of the original mars88.int file. Please send me your opinion, suggestion. Nandor Sieben aznxs@asuacad.bitnet From: kh004b@uhura.cc.rochester.edu (The Wonderous Flying Fly) Subject: corewar for Unix Message-ID: <1993Apr21.200422.798@galileo.cc.rochester.edu> Date: Wed, 21 Apr 93 20:04:22 GMT Does anyone know of any corewar programs for the Unix (sun 4.1) without needing colors or xwindow or any of that other advanced stuff? -- I would rather be mudding ---- ---- | | | | From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: corewar for Unix Message-ID: <1993Apr22.130907.29042@oucsace.cs.ohiou.edu> Date: 22 Apr 93 13:09:07 GMT In article <1993Apr21.200422.798@galileo.cc.rochester.edu> kh004b@uhura.cc.rochester.edu (The Wonderous Flying Fly) writes: >Does anyone know of any corewar programs for the Unix (sun 4.1) without >needing colors or xwindow or any of that other advanced stuff? There are only two Unix versions out there that I know of that are truly compliant with the Corewar standards. They are as follows: 1) KotH (King of the Hill) This is the same program that runs the Hill for the internet that people submit there warriors too. It will run for X-Windows and Summary (where I define summary as being no display, just results of the battles). It is a very nice program and quite fast, in fact, it is the fasted unix version available. Currently supports the '88 ICWS standard and eXtended standard (more or less). 2) Core Wars Deluxe This program was designed to make it easier to run tournament battles easier. It will run for X-Windows, Curses, ANSI/VT100 displays, and Summary (as defined above). The ANSI display was designed to be run on any vt100 compatible terminal or any IBM with the ANSI.SYS driver loaded. It is also a very nice program, and is probably the most flexible program available for unix. Supports both the '86 ICWS and '88 ICWS standards, and the eXtended standard (more or less). There are other unix versions out there, but they are all a total waste of your time. The first and foremost judge of quality for any corewar system must be whether it is '88 ICWS standard compliant. It is this definition that describes the language of corewars and how it is played. I will be releasing a review of the various versions out there for the IBM PC, Macintosh, and Unix. Somebody else should review the Amiga package and mail be their review when they are done (I *wish* I had an Amiga... in fact, I *wish* I had a computer!) All files can be found at soda.berkeley.edu, as this is a official corewar archive site (for systems, warrior code, and documentation). KotH can be found in the /pub/corewar/systems directory. The file you should grab is "koth31.shar.Z". If you have questions about the program, then send mail to the author at wms@iwarp.intel.com (William Shubert). Core Wars Deluxe can be found in the /pub/corewar/systems directory. The files you should grab are "deluxe20b.README" and "deluxe20b.tar.Z". If you have any questions about the program, then send mail to the author at sadkins@ohiou.edu (Scott Adkins). The files describing the Core War standards can be found in the /pub/corewar/documents/systems directory. The file of main importance is "redcode-icws-88.Z", as this describes the ICWS '88 standard currently in use. Hope this helps!!! Scott -- 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: 23 Apr 1993 00:00:10 -0400 Message-ID: Archive-name: games/corewar-faq Last-modified: 1993/04/16 Version: 2.0.4 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? 165 10. Where are the Core War archives? 181 11. Where can I find a Core War system for . . . ? 198 12. I do not have ftp. How do I get all of this great stuff? 215 13. I do not have access to Usenet. How do I post and receive news? 222 14. When is the next tournament? 243 15. What is KOTH? How do I enter? 252 16. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 357 17. How does SLT (Skip if Less Than) work? 369 18. What does (expression or term of your choice) mean? 381 19. Other questions? 509 --------------------------------------------------------------------- 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: Recent issues can be found on soda.berkeley.edu (see Q10). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- 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.149.19) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. 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: If you have access to telnet, you can read rec.games.corewar (and many more groups) through the gopher information retrieval system. Telnet to consultant.micro.umn.edu (134.84.132.4) or any of the other gopher servers and go through these menus: 1 - Information about Gopher 10 - Gopher+ example server 11 - non-Gopher+ link 7 - News 11 - USENET news 24 - rec 21 - games 6 - corewar 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". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail daemon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives in an hour, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. MORE ON KOTH COREWAR IMPLEMENTATION Core size: 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: 23 Apr 93 14:56:14 GMT This if the first official announcement of the Warrior Library! It contains 260 warriors collected from all over (and all that I could find in the newsgroups)! You can find it currently at soda.berkeley.edu in /pub/corewar/incoming. It will be moved very shortly to /pub/corewar/redcode, where it will stay as its home :-) Currently, I will only release the Unix version, but I will release a PC version (with trimmed filenames) very soon. I will announce it again when I do that. Look for warrior10.tar.Z! Any questions, submissions, and small-talk, send to me as follows: Scott Adkins sadkins@ohiou.edu Here is the README that comes with the distribution: Well, here is the first release of the Warrior Library! It currently has most of the redcode warrior I could collect for both the ICWS '88 standard and the eXtended standard. Later versions of the library will have more warriors, better organization, and maybe a couple of other goodies tossed in with them. Currently, I will only release this version for Unix, but I will release an MS-DOS version (in zip form) here soon. The problem with the MS-DOS is that filenames are limited to 8 characters in length, and this causes problems with those warriors with similar names that are longer than 8 characters... When I resolve this problem, I will release the PC version. I am the official Warrior Library Maintainer. Any warriors that you would like to include in the next release, please send them to me at the following address: sadkins@ohiou.edu (Scott Adkins). Likewise, if you have any questions, corrections, etc, feel free to send me EMail. NOTE: All redcode warriors that are posted to the public (notably, the rec.games.corewar newsgroup), will automatically get included in the next release of the library. Since I promote the distribution of warriors among corewar fans, I suggest that you post your warriors to rec.games.corewar, and I will automatically include them in the next release of the library! :-) The directory structure that I will maintain currently with the warriors is as follows: The 86 directory will contain all warriors that will assemble only for the ICWS '86 standard. Currently, there are no warriors that fit in this category. The 88 directory contains warriors that assembles for the ICWS '88 standard. The X directory contains warriors that do not assemble for either of the previous two standards. Notice that most of the warriors in the X directory will not compile for the ICWS '88 standard because they use certain features not available in any other standard. Examples of this would inclue post-increment mode and B-Field immediate mode for MOV instructions. This release currently has 260 warriors in the library! 245 of them are for the ICWS '88 standard, and 15 of them are for the eXtended standard. I look forward to this library growing, and I hope it will benifit all who wish to learn and play in the game of Core Wars! 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: clolson@me.umn.edu (Curt L. Olson (Admin)) Subject: What's up? Message-ID: Date: Sat, 24 Apr 1993 01:51:45 GMT So why does my news reader get a segmentation violation when ever I try to read the core wars faq recently posted in comp.answers? Could it be ... ?? ... ?? Nah. -- Curtis Olson curt@sledge.mn.org olson@cs.umn.edu clolson@me.umn.edu Ride the Rockies -- 6 Days, 428 Miles -- Over hill and dale. . Try Linux ... if you own a [34]86. If you own a mac ... :( \__[0]__/ Date: Sunday, 25 Apr 1993 17:11:42 MST From: Message-ID: <93115.171142ASMQK@ASUACAD.BITNET> Subject: macrored.c This is the source of macrored. I'm not a real programmer ( I use Pascal :-) so if it seems ugly let me know. ( It seems ugly enough to me like any C source ) . This is not exactly the original, so don't use it with mars88 . I used Turbo C 2.0 . I hope it will work on any platform. Nandor. #include "stdio.h" #include "stdlib.h" #define STRSIZ 200 #include "string.h" FILE *fin , *fout; char dir[STRSIZ], name[STRSIZ], ext[STRSIZ], outstr[STRSIZ], s[STRSIZ], ss[STRSIZ]; char *index; char tomb[100][81]; int tpoint, i, j, k; char number[4],number1[4]; main(int argc, char *argv[]) { if ( ( argc < 3 ) || ( ! strcmp(argv[1],argv[2] ) )) { printf("\nRedcode macroprocessor by Nandor Sieben 4/25/1993\n"); printf("Usage:\n"); printf("macrored infile outfile \n"); printf("\n"); printf("You can use the following macro :\n"); printf(" for 3 ;the compile variable \"for\" goes from 1 to 3\n"); printf("LABELfor dat #for*2-1 ;\"for\" will be substituted by the actual value\n"); printf(" rof ;end of for\n"); exit(1); } if ( (fin = fopen(argv[1],"r") ) == NULL) { printf("******* Macrored error *******\n"); printf("\n"); printf("File does not exist\n"); exit(2); }; strcpy(outstr,argv[2]); if ( (fout = fopen(argv[2],"w") ) == NULL) { printf("******* Macrored error *******\n"); printf("\n"); printf("Can't create file\n"); exit(3); }; while (!feof(fin)) { fgets(s,STRSIZ,fin); index = strstr(s,"for"); if (index == NULL) fprintf(fout,"%s",s); else { index += 3; sscanf(index,"%d",&k); if (k <= 0) { printf("******* Macrored error *******\n"); printf("\n"); printf("Bad \"for\" parameter\n"); printf("%s",s); exit(3); } tpoint = 0; do { fgets(s,STRSIZ,fin); tpoint++; strcpy(tomb[tpoint],s); } while (!((strstr(s,"rof") != NULL) || feof(fin))); for (j = 1; j <= k; j++) { sprintf(number1,"%d",j); switch (strlen(number1)) { case 1: strcpy(number,"00"); break; case 2: strcpy(number,"0"); break; } strcat(number,number1); for (i = 1; i < tpoint ; i++) { strcpy(s,tomb[i]); do { index = strstr(s,"for"); if (index != NULL) { index[0] = number[0]; index[1] = number[1]; index[2] = number[2]; } } while (!(index == 0)); fprintf(fout,"%s",s); } } } } fclose(fin); fclose(fout); exit(0); } From: houk@athena.cs.uga.edu (Socks) Subject: A coupla warriors... Message-ID: Date: Tue, 27 Apr 1993 20:50:03 GMT Here's two pieces of code that I've been working on the past few days. Unfortunately, they don't seem to be going anywhere... Both are pretty good against scanners - but everything else tends to wipe these guys out... Oh well - it was worth a try. :) Bubble-scrape scored around 80-85 on the hill. Mort Aux Vaches was around 75-80. Both were around 20 wins, 60 losses, give or take a few. ----- ;redcode verbose ;name Bubble-scrape ;author Joshua Houk ;strategy ;strategy Bombs entire core with SPL+DAT-bombs, then hits a spl 0 ;strategy to tie... ;strategy datbomb dat #0 ;regular ol' DAT bomb splbomb spl @-1 ;hopefully this will cause the other ;program to split into a neverending ;loop... bomber add #3759,datbomb mov datbomb, Hm, well, no idea if this will post, but here it goes: I have a pc running msdos (I'm sorry, can't run Linux cause I got suckered into getting micro- channel architecture), and Window (REALLY sorry). Which of the many MARS emulators should I snag from soda.etc...I would like it to be ICWS '88 compliant so I can enter in the Koth stuff and lose fabulously. 'Course, I could just download *all* of them and diddle around, as they tend to be tiny :) Scott Adkins (sp?) I believe said he was going to "review" the various versions...that would be *MUCH* appreciated. Sorry for asking lame non-questions. :) Thanks in advance! See ya at the bottom of the hill! *cheer* Jeff Chrisope From: Burch_Ben@msmail.wes.mot.com (Ben Burch) Subject: Core! 1.1 on a Quadra-800; Crashes. Message-ID: <1993Apr29.144950.14968@lmpsbbs.comm.mot.com> Date: 29 Apr 93 14:49:50 GMT Hello! I recently started trying to use Core! 1.1. It crashes a lot on my Quadra-800. Does anybody else have the same experience? Is there a more up-to-date version which does not crash so often? Thanks! -Ben Burch Burch_Ben@msmail.wes.mot.com From: pk6811s@acad.drake.edu Subject: _Push Off_ Message-ID: <1993Apr29.105959.1@acad.drake.edu> Date: Thu, 29 Apr 1993 16:59:59 GMT _PUSH OFF_ A midweek review of Corewar April 29, 1993 ------------------------------------------------------------------------------- I. The Standings: # %W/ %L/ %T Name Author Score Age 1 38/ 23/ 38 Night Crawler Wayne Sheppard 154 163 2 48/ 42/ 10 Backstabber Anders Ivner 154 83 3 46/ 43/ 11 Dragon Spear c w blue 148 265 4 46/ 45/ 9 Agony 5.1 Stefan Strack 146 317 5 44/ 43/ 13 Iron Gate 1.01 Wayne Sheppard 145 21 6 36/ 27/ 38 Imprimis 6 P.Kline 145 563 7 32/ 25/ 43 ttest nandor sieben 140 39 8 39/ 39/ 22 Leprechaun 1b Anders Ivner 140 1075 9 43/ 47/ 10 Medusa's v7 Mintardjo & Strack 139 456 10 32/ 25/ 43 Silver Paper W. Mintardjo 139 194 11 32/ 26/ 42 +0 Stormbringer Dan Nabutovsky 138 1593 12 41/ 45/ 14 a-test nandor sieben 138 41 13 42/ 47/ 11 Pysco IV David Johnson 137 27 14 41/ 44/ 16 Sucker 6 Stefan Strack 137 185 15 32/ 27/ 41 Sphinx v2.8 W. Mintardjo 137 1161 16 30/ 24/ 45 ittt nandor sieben 136 40 17 36/ 38/ 25 Nurgle c w blue 135 146 18 41/ 47/ 12 Eclipse II P.Kline 134 18 19 39/ 47/ 14 Emerald 4 P.Kline 130 138 20 34/ 48/ 18 Distance v6.0 Brant D. Thomsen 120 1 21 33/ 52/ 15 Wimp v5.0 Brant D. Thomsen 114 0 ------------------------------------------------------------------------------- II. The Basics: -Core War Archives are available via anonymous FTP at soda.berkeley.edu in pub/corewar... -FAQ for this newsgroup is available via anonymous FTP at rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.z ------------------------------------------------------------------------------- III. The Scoop: Another member of the OverTheHill Gang was pushed off the Hill this week - W. Sheppard's Iron Gate program which had some success against the imps was pushed off at the ripe old age of 1089. That leaves just three members of the OTH Gang: +0 Stormbringer, Leprechaun 1b, and Sphinx v2.8. We have to look way down the ranks to find the next candidate with a chance at 1000, Imprimis 6. Well, here's one author crossing his fingers, (and wishing he had maybe just left Imprimis 4 or 5 up, they would be there by now :-/ Iron Gate's fall was due in part to a relentless attack by C.W. Blue, who's sub-type-xxx fighters have been appearing all up and down the list from day-to-day. He keeps knocking them off, so it's unclear what he's up to. Is Blue preparing a swarm of tough fighters to release all at once and take over? Stay tuned... The demise of Iron Gate gave rise to speculation that spl-jmp bombing cmp-scanners had lost their competitiveness. Carpet-bombing scanners are still successful, but with Charon and Iron Gate being pushed off, no other spl-jmp bombers were left (as far as I know :). But Wayne gave IG some new points, plugs, and paint - and now Iron Gate 1.01 is ranked fifth. In last week's _Push Off_ I speculated that Backstabber was a bscan, core-clearing type of program. Anders was kind enough to correct me by revealing it is really a cmp-scanner (with a little different bomb). ------------------------------------------------------------------------------- IV. The Outlook: 8 43/ 47/ 11 Pysco IV David Johnson 139 1 9 44/ 45/ 11 sub-type-cmp c w blue 142 1 7 44/ 45/ 11 sub-type-c c w blue 144 1 8 32/ 24/ 44 Snake-crawler Wayne Sheppard 141 1 5 46/ 46/ 8 Cleaver Wayne Sheppard 145 1 1 34/ 20/ 46 sub-type-i c w blue 148 1 ------------------------------------------------------------------------------- V. The Quick Look: 21 4/ 56/ 40 Foo Brant D. Thomsen 52 0 21 15/ 54/ 31 Ally Mestern 75 0 20 35/ 52/ 13 Test Wayne Sheppard 117 1 21 29/ 63/ 7 ice2 Ziad 95 0 21 3/ 67/ 29 test P.Kline 40 0 21 32/ 57/ 11 test j.layland 108 0 17 36/ 40/ 24 test Andy Pierce 133 1 21 5/ 58/ 37 Tiger Mester 51 0 21 18/ 51/ 31 Invest Andre van Dalen 84 0 21 10/ 80/ 10 Lots20 Jeffrey Chrisope 40 0 20 24/ 36/ 40 Scaper c w blue 112 1 18 40/ 46/ 15 a-test nandor sieben 134 1 21 12/ 69/ 19 pebble Mestern 55 0 18 41/ 48/ 11 CraMPon c w blue 134 1 21 16/ 82/ 2 Rounder Jussi Vehkalahti 50 0 21 28/ 59/ 13 ccproba nandor sieben 96 0 21 14/ 48/ 38 MPCC 2.1 A.T. Crowley 81 0 21 15/ 30/ 55 Passport P.Kline 100 0 19 32/ 46/ 21 Iron Gate Wayne Sheppard 118 1 21 38/ 49/ 13 Pysco III David Johnson 126 0 20 7/ 73/ 20 Replicant Paul Whittaker 42 1 21 7/ 87/ 6 Vamp kill Fredrik 28 0 19 32/ 44/ 24 Wimp v3.0 Brant D. Thomsen 120 1 21 29/ 37/ 34 Wimp v3.1 Brant D. Thomsen 121 0 21 34/ 54/ 12 Wimp v4.0 Brant D. Thomsen 113 0 21 39/ 48/ 14 Eclipse II P.Kline 130 0 21 13/ 43/ 43 ScareForce P.Kline 84 0 21 0/ 44/ 55 Sludge 1.0 I'd_rather_not_say 57 0 21 21/ 36/ 42 multi mice nandor sieben 106 0 20 38/ 53/ 10 sub-type-c c w blue 123 1 21 26/ 65/ 9 Double Orff Fredrik 88 0 21 16/ 82/ 2 Spreader v1 Jussi Vehkalahti 50 0 21 10/ 85/ 5 White Kross Joshua Houk 34 0 21 0/ 94/ 5 Witchdoctor Paul Whittaker 6 0 20 38/ 50/ 12 ExtraExtra 2 P.Kline 127 1 21 10/ 68/ 21 Parasite v 5 Roderick Easton 53 0 20 23/ 67/ 10 Vamkill Orff Fredrik 78 1 21 24/ 60/ 16 Bubble-scrape Joshua Houk 88 0 20 34/ 48/ 18 Distance v6.0 Brant D. Thomsen 119 1 21 26/ 69/ 5 Improved Dwarf Ben Burch 82 0 20 11/ 51/ 38 Bubble-scrape 2 Joshua Houk 71 1 21 22/ 68/ 10 Mort Aux Vaches Joshua Houk 76 0 21 13/ 40/ 47 White Kross v1.2 Joshua Houk 87 0 21 1/ 64/ 35 Replicant (Nexus 2) Paul Whittaker 39 0 21 2/ 55/ 43 Replicant (Nexus 2 Revisi Paul Whittaker 49 0 ------------------------------------------------------------------------------- VI. The Hint: How many ways are there to copy code from one place to another? Lots! Here are three ways to copy four lines of code (hide1-hide4): hide1 xxx hide2 yyy hide3 zzz hide4 aaa old dat #0 --------------- copy mov 9 --------------- spl 1 ; multi-process spl 1 ; - you are using multiprocess for other reasons copy mov 8 new spl @0,old+1000 --------------- copy mov 5 new spl @0,old+1000 ------------------------------------------------------------------------------- VII. The End: Paul Kline pk6811s@acad.drake.edu From: jlayland@kilroy.Jpl.Nasa.Gov (James Layland) Subject: Macroized Paper Date: 29 Apr 1993 17:10:27 GMT Message-ID: <1rp263INNpp6@elroy.jpl.nasa.gov> Just thought I'd show that Nandor's redcode macro processor is good for more than abbreviating decoys. Hmmm... now if we just had a few more enhancements we could all quit this programming stuff and write programs like: stone binary launch 7-point imp forward core-clear end Well... maybe not. Anyway, here is a macrored-ized version of Flash Paper. More or less. I still had to write out two copies of the replicator. Maybe multi-line macro subroutines?? This is solely for demonstration purposes; I make no claims that the constants chosen here are anything resembling "optimal". ;redcode ;name Macro Paper ;author J.Layland ;strategy macroized version of Flash Paper ;strategy some constants randomly changed for no good reason. start spl p2 ;hedge bets against lucky stone spl 1 spl 1 ;start 4 processes going for copy spl p002 spl p003 spl p004 for 7 lfor mov #8, 8 ;set source pfor mov Date: Thu, 29 Apr 1993 17:54:51 GMT I have just finished writing Redcoder, a new Macintosh Core War system. Here is a description: Redcoder 1.0 - Macintosh Core War simulator and development system. - Full Macintosh user interface. - Works on systems from version 6.0 to 7.1. - Supports colour. - ICWS '88 compatible plus all modes are allowed (e.g. mov #a,#b). - Postincrement operator is implemented. - Maximum write distance option is supported. - Advanced text editor with Undo, tabs and search/replace. - Simple breakpoint facilities. - Simple tournament controller. - Fighter lists which can hold groups of compiled fighters. - And probably a few bugs. :-) I have uploaded it to soda.berkeley.edu in a file called Redcoder-10.hqx. Alex. --- Alex MacAulay (macaulay@ecr.mu.oz.au) "The following statement is true. The preceding statement is false." From: jlayland@kilroy.Jpl.Nasa.Gov (James Layland) Subject: Re: _Push Off_ Date: 29 Apr 1993 23:03:29 GMT Message-ID: <1rpms1INNgtb@elroy.jpl.nasa.gov> In article <1993Apr29.105959.1@acad.drake.edu> pk6811s@acad.drake.edu writes: >The demise of Iron Gate gave rise to speculation that spl-jmp bombing >cmp-scanners had lost their competitiveness. Carpet-bombing scanners >are still successful, but with Charon and Iron Gate being pushed off, >no other spl-jmp bombers were left (as far as I know :). But Wayne >gave IG some new points, plugs, and paint - and now Iron Gate 1.01 is >ranked fifth. > Since Iron Gate 1.01's strategy line just says he changed the scan constant, perhaps its demise was because it was (I believe) the only scanner on the Hill with a published scan constant? Any programs out there using reflections at 98? Wayne could probably tell us... James jlayland@grissom.jpl.nasa.gov From: wsheppar@st6000.sct.edu (Wayne Sheppard) Subject: Reflections (was Re: _PushOff_) Date: 30 Apr 1993 10:19:32 -0500 Message-ID: <9304301516.AA57385@st6000.sct.edu> <>cmp-scanners had lost their competitiveness. Carpet-bombing scanners <>are still successful, but with Charon and Iron Gate being pushed off, <>no other spl-jmp bombers were left (as far as I know :). But Wayne <>gave IG some new points, plugs, and paint - and now Iron Gate 1.01 is <>ranked fifth. <> Date: Fri, 30 Apr 1993 14:54:26 GMT In article <...> Burch_Ben@msmail.wes.mot.com (Ben Burch) writes: > Hello! I recently started trying to use Core! 1.1. It crashes a lot on my > Quadra-800. Does anybody else have the same experience? Is there a more > up-to-date version which does not crash so often? Thanks! > I used Core! 1.1 for a while before I started having problems. Core! 1.1 has a bug in handling SUB instructions. It does not normalize the a-operand after subtracting, so you can get out-of-range values that cause it to start writing in bad memory locations. If you can avoid using SUB, or use it only against DAT statements, you should be all right. Jon has a fix, but the last time I talked to him he was waiting on other changes before releasing a new version - one of the fun things about being a shareware author is having multiple versions out there :-/ (Just send in your registration and request version 1.2, it works great on my Mac IIci :-) Paul Kline pk6811s@acad.drake.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: EBS summer tournament Message-ID: Date: Fri, 30 Apr 1993 18:18:18 GMT _Announcing: The EBS summer tournament 1993_ This is the third attempt at getting an "interactive" corewar tournament going; may this one will actually finish :-) This is a double-elimination tournament with rounds every week. Emphasis is on pitting programmer vs programmer rather than program vs program. You will receive source for *all* warriors after each round (this is to save myself some work). You can submit a new warrior before the next round (which of course won't be publicized until after the next round), or continue with your previous entrant. Battles are KotH style: coresize: 8000 maxprocs: 8000 cycles until tie: 80,000 maxlength: 100 battles: 100 (win: 3 pts, tie: 1 pt) The entry deadline will be the Friday before each round, 20:00 CST. Results will be posted to r.g.cw and emailed on that same weekend. Source will be emailed at the same time. Send your entry to stst@vuse.vanderbilt.edu. One entry per person. Deadline for 1st round submission is Friday, May 7th, 20:00 CST. The tournament will take place only if there are at least 12 contestants, so please send in your submissions. If there are more than 24 or so, I plan to split the tournament into an A- and B-league. The B-league will be reserved to programmers that do not currently have a warrior on the hill. -Stefan (stst@vuse.vanderbilt.edu)