Subject: mars88 for PC
Message-ID: <92061.172632ASMQK@ASUACAD.BITNET>
From: <ASMQK@ASUACAD.BITNET>
Date: Sunday, 1 Mar 1992 17:26:32 MST

ICWS 88 compatible  (I hope) , EGA/VGA display or no display at all
(CGA 's coming soon) , Turbo Pascal source (fast especially if no display)
warriors can be selected by menu , the compiler gives informations
to find the mistakes .
If you are interested please send me a note  (asmqk@asuacad.bitnet) and
I send you an lharc uuencode file.  mars88.exe -> mars88.lzh -> mars88.uud
Filesizes:exe 30849 , lzh 39941 , uud 56839

Nandor Sieben      asmqk@asuacad.bitnet


Subject: New version of KotH available
From: wms@iwarp.intel.com (William Shubert)
Date: Mon, 2 Mar 1992 01:33:40 GMT
Message-ID: <1992Mar2.013340.21139@iWarp.intel.com>

   I have just finished V2.1 of KotH corewar.  A bunch of people have V2.0
already; V2.1 has the following improvements:
   - Buttons to control the X display.
   - Options to use postincrement addressing, a maximum write distance, and
     an option where killing a parent process kills its children also.
   - The capability to run more than two programs at a time.
   - Minor bug fixes.  All known bugs are now fixed.

   For those who don't know what I'm talking about, KotH corewar is the program
used by the KotH corewar tournament.  In it's standard mode, it is a fully
ICWS '88 compatible corewar program for Unix systems with an X windows graphic
display interface.
   To get this source code, send me mail.  I'll send it to you in the form of
an 80K shar file; if your mailer won't be able to handle this I could also
break it up for you.

   In particular, many people in the past have expressed interest in setting
the maximum write distance for a program.  Well, now it's possible, so if
anybody wants to they can start fooling around and writing programs for this
option.
				-Bill (wms@iwarp.intel.com)


Subject: ramscoop-x
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Date: 2 Mar 92 04:03:22 GMT
Message-ID: <1992Mar2.040322.29456@vuse.vanderbilt.edu>


To break the silence in this newsgroup, I'll post another one of my KotH
warriors. "ramscoop-x" is currently #2 on the experimental hill (which
has just been enriched by an "Age" field for perseverance. Thanks, Bill).
It's of the imp/imp-stomper variety (like bow-n-arrow, Trinity Zwo, and 
Walze) that seems to do so well on the -x hill, but miserably on the
standard hill. In fact, ramscoop-x will not even work correctly under the
standard time-slice allocation scheme, because the imps will breach the
imp-stomping barricade set up by the program itself.
	If anyone else has a warrior that exploits the -x time-slice
allocation for some uniquely offensive behavior, please post. I am getting
the impression that a lot of hill-x programs simply take advantage of their
resistance to SPL bomb.
	Maybe it's time to move on to another experimental hill. We've all
had enough time to evaluate the "split CPU-time" modification, and I 
personally don't think it makes for more interesting warriors.
	How about it, Bill, ready to launch the "limited write-distance"
and/or "post-increment indirect (>)" experimental hill?

Cheers, Stefan (stst@vuse.vanderbilt.edu)

;redcode-x
;name ramscoop-x
;author Stefan Strack
;strategy Blankets the core with imps
;strategy Submitted: @date@
impstop equ     start-6
i1      equ     imp+4000
i2      equ     imp+2000
i3      equ     imp+1000

start   spl     impgun
bloop   mov     <impstop,<impstop       ;runs at 50%
        jmp     bloop,  <impstop
        jmp     -1,     <0
        jmp     -1,     <0
        jmp     -1,     <0
        jmp     -1,     <0
impgun  mov     imp,    i1
        spl     i1                      ;runs at 25%
        mov     imp,    i2
        spl     i2                      ;runs at 12.5%
        mov     imp,    i3
        spl     i3                      ;runs at 6.25%
imp     mov     imp,    imp+1           ;runs at 3.125%

        end     start


Subject: Re: soda.berkeley.edu
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Date: 2 Mar 92 15:39:11 GMT
Message-ID: <1679E87C8.DURHAM@ricevm1.rice.edu>

Another Core War archive site is available in Germany.  It is

iraun1.ira.uka.de (129.13.10.90)

and contains most of what soda has/d under /pub/X11/corewars.

Mark A. Durham
MAD


From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Subject: MAD FAQs (KotH included)
Message-ID: <1679E8C69.DURHAM@ricevm1.rice.edu>
Date: Mon, 2 Mar 1992 15:59:05 GMT

Last Update: March 2, 1992

TABLE OF CONTENTS
-----------------

1. What is Core War?

2. Is it Core War or Core Wars?

3. Where can I find more information about Core War?

4. What is the ICWS?

5. What is TCWN?

6. How do I join?

7. Are back issues of TCWNs available?

8. What is the EBS?

9. Where are the Core War archives?

10. Where can I find a Core War system for . . . ?

11. When is the next tournament?

12. What is KOTH?  How do I enter?

13. What is Core War notation?

14. Other questions?

---------------------------------------------------------------------

Q1: What is Core War?
A1: Core War is a game played by two or more programs (and vicariously
by their authors) written in an assembly language called Redcode and
run in a virtual computer called MARS (for Memory Array Redcode Simulator).
The object of the game is to cause all of the opposing programs to
terminate, leaving your program in sole possesion of the machine.

There are Core War systems available for most computer platforms.
Redcode has been standardized by the ICWS, and is therefore transportable
between all standard Core War systems.

----------------------------------------------------------------------

Q2: Is it "Core War" or "Core Wars"?
A2: Both terms are used.  Early references were to Core War.  Later
references seem to use Core Wars.  I prefer "Core War" to refer to
the game in general, "core wars" to refer to more than one specific
battle.

----------------------------------------------------------------------

Q3: Where can I find more information about Core War?
A3: Core War was first described in the "Core War Guidelines" of March,
1984 by D. G. Jones and A. K. Dewdney of the Department of Computer
Science at The University of Western Ontario (Canada).  Dewdney wrote
several "Computer Recreations" articles in "Scientific American" which
discussed Core War, starting with the May 1984 article.  Those articles
are contained in an anthology:

Author: Dewdney, A. K.
Title: The Armchair Universe: An Exploration of Computer Worlds
Published: New York: W. H. Freeman (c) 1988
Library of Congress Call Number: QA76.6 .D517 1988

---------------------------------------------------------------------

Q4: What is the ICWS?
A4: About one year after Core War first appeared in Sci-Am, the
"International Core War Society" (ICWS) was established.  Since that
time, the ICWS has been responsible for the creation and maintenance
of Core War standards and the running of Core War tournaments.  There
have been six annual tournaments and two standards (ICWS'86 and
ICWS'88).  The ICWS is currently in a state of flux, but should
stabilize soon.

---------------------------------------------------------------------

Q5: What is TCWN?
A5: Since March of 1987, "The Core War Newsletter" (TCWN) has been the
official newsletter of the ICWS.  It is supposed to be published quarterly,
but has appeared sporadically instead.  This should change soon as TCWN
is changing publishers.  In fact, it may be available through this
newsgroup in the near future.

---------------------------------------------------------------------

Q6: How do I join?
A6: For more information about joining the ICWS and/or subscribing to TCWN,
contact:

   Jon Newman
   One Microsoft Way
   Redmond, WA 98052-6399
   EMail: jonn@microsoft.com

If you wish to contribute an article, cartoon, letter, joke, rumor, etc.
to TCWN, please send it to me at

   Mark A. Durham
   P.O. Box 301173
   Houston, TX 77230-1173
   EMail: durham@ricevm1.rice.edu

and clearly indicate its destination.

The ICWS and TCWN are in a transitional period (as of March 1992).
(Things are wrapping up though, believe it or not frequent readers).
Please be patient with them.

----------------------------------------------------------------------

Q7: Are back issues of TCWN available?
A7: Arrangements are being made to make TCWN back issues available.  This
will probably involve a $4.00(US) fee to be sent to the Copyright Clearance
Center as well as an additional postage and handling charge.  Check out
the synopses posted previously (now on soda.berkeley.edu - see below).

---------------------------------------------------------------------

Q8: What is the EBS?
A8: The Electronic Branch Section (EBS) of the ICWS is a group of
Core War enthusiasts with access to electronic mail.  There are no fees
associated with being a member of the EBS, and members do reap some of
the benefits of full ICWS membership without the expense.  For instance,
the ten best warriors submitted to the EBS tournament will be entered
into the annual ICWS tournament.  Now that rec.games.corewar has been
created, the EBS will move most of its business to the newsgroup.

The current goal of the EBS is to be at the forefront of Core War by
writing and implementing new standards and test suites in preparation for
the tenth anniversary of Core War in May of 1994.  Its immediate business
will be to set up a Charter and establish its officers.  Contact me if
you are interested in helping serve the EBS.

----------------------------------------------------------------------

A9: Where is the Core War archive?
Q9: Many documents such as the guidelines and the ICWS standards
along with previous tournament Redcode entries and complete Core War
systems are available via anonymous ftp from soda.berkeley.edu
(128.32.131.179) in the /pub/corewar directories.  Much of what is
available on soda is also available on the German archive at
iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory.

----------------------------------------------------------------------

Q10: Where can I find a Core War system for . . . ?
A10: First, check out the Core War systems available via anonymous ftp
from soda.berkeley.edu.  Currently, there are X-Window, IBM PC-compatible,
Macintosh, and Amiga Core War systems available there.  Others may appear.

The following suppliers have ICWS'88 compatible systems for

IBM PC compatibles:
   The Core War Colosseum
   AMRAN
   5712 Kern Drive
   Huntington Beach, CA 92649-4535
   Price: $39.95

   CoreMaster(TM)
   THINK Software
   524 Paige Drive
   Birmingham, AL 35226
   (205)979-9475
   Price: $34.95 + $3.00 S&H

Apple Macintosh computers:
   Core!
   Jon Newman
   One Microsoft Way
   Redmond, WA 98052-6399
   EMail: jonn@microsoft.com (Note: Core! is NOT a Microsoft product.)
   Price: $14.00 registration fee, plus $3.00 S&H.  S&H fee waived
            if you send 800k disk and stamped, self-addressed envelope.
   Also available from sumex-aim.stanford.edu and
   listserv@ricevm1.rice.edu and soda.berkeley.edu.

Commodore Amiga computers:
   The MADgic Core
   c/o Mark A. Durham
   P.O. Box 301173
   Houston, TX 77230-1173
   EMail: durham@ricevm1.rice.edu
   A version of The MADgic Core is available from soda.berkeley.edu.

   CoreWars (German language version)
   UNICORN systems
   Bernstrasse 67
   CH-4852 Rothrist
   Switzerland
   Price: sFr 45.--

Commodore 64/128 computers:
   Barry Cohen
   65 West 90th Street, #23E
   New York, NY 10024
   Price: Not Available

My apologies to those of you who have Core War systems which are not
listed here or are incorrectly listed here.  Please send me information
about the systems (base system, ICWS standards compatibility, extensions,
price, etc.) and I will be sure to include it in next month's MAD FAQs.

CAUTION!  There are many, many Core War systems available which are NOT
ICWS'88 (or even ICWS'86) compatible available at various archive sites.

Reviews of Core War systems would be greatly appreciated in the newsgroup
and in the newsletter.  Please post or EMail to me any review of any
Core War system you have tried out so that others may learn from your
experience.

----------------------------------------------------------------------

Q11: When is the next tournament?
A11: The EBS is in the middle of a tournament right now.  If you would
like to join in, send me mail.  Otherwise, keep looking to r.g.cw for
upcoming tournament announcements.

----------------------------------------------------------------------

Q12: What is KOTH?  How do I enter?
A12: King Of The Hill (KOTH) is an ongoing Core War tournament available
to anyone with EMail provided by William Shubert <wms@iwarp.intel.com>.
You enter by submitting a Redcode program with special comment lines via
EMail.  You will receive a reply indicating how well your program did
against the current top ten programs "on the hill".  If your program
finished in the top ten, it will remain on the hill until such time as it
finishes eleventh 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.

   Additionally, adding ";name <program name>" and ";author <your name>"
   will be helpful in the performance reports.  Do NOT have a line
   beginning with ";address" in your code; this will confuse the mail demon
   and you won't get mail back.

   In addition, it would be nice if you have lines beginning with
   ";strategy" that describe the algorithm you use.

3) Mail this file to "wms@iwarp.intel.com".

4) Within a few minutes you should get mail back telling you whether your
   program compiled correctly or not.  If it did compile correctly,
   sit back and wait; if not, make the change required and re-submit.

5) In an hour or so you should get more mail telling you how your program
   performed against the current top 10 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.

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.

Example program:

;redcode
;name Dwarf
;author A. K. Dewdney
bomb	dat	#0
dwarf	add	#4,bomb
      mov	bomb,@bomb
      jmp	dwarf
      end	dwarf

If you want, enter your program with ";redcode-x" and PRESTO!  YOU'RE IN
THE EXPERIMENTAL TOURNAMENT!  Now what does this mean?
   1> When a process splits, it's children share it's CPU time.
   2> When a process dies, it's CPU time is given to it's sibling, or it's
      siblings descendants if the sibling has split.
   3> ALL ADDRESSING MODES ARE ALLOWED.  So "add #4, #5" will become
      "add #4, #9" after execution.

The source code to KotH is available by EMail from William Shubert.
Write to him at <wms@iwarp.intel.com>.

----------------------------------------------------------------------

Q13: What is Core War notation?
A13: There are some important notational conventions which should be
followed when writing about Core War.  Before we discuss them, you
need to understand Redcode syntax.

Redcode consists of assembly language instructions of the form

   <label>   <opcode> <A-mode><A-field>, <B-mode><B-field> ; <comment>

The <label> is optional.  <opcode> is DAT, MOV, ADD, SUB, JMP, JMZ,
JMN, DJN, CMP, SLT, SPL, SPACE (obsolete), EQU, or END.  <A/B-mode>
indicators are $ (obsolete), #, @, or <.  A missing <mode> indicator is
considered the same as $.  <A/B-field>s are integers or expressions.
A missing <mode><field> and comma is considered the same as #0.
Which field is considered missing depends on the opcode.
The "; <comment>" is optional and can appear on a line by itself.

When discussing Redcode, one often wants to talk about whole families
of instructions.  Example:

   ??? A, B

describes all possible Redcode statements.  The "???" indicates any
opcode, the capital A indicates any combination of A-mode and A-field,
and similarly for B.  "???" is rarely used.  Most people just put in
any arbitrary opcode, usually MOV (if executed) or DAT (if not).

The capitalization of A and B is important!!!

   MOV A, B

and

   MOV a, B

mean two different things.  MOV A, B means the family { MOV $a, B;
MOV #a, B; MOV @a, B; and MOV <a, B } whereas MOV a, B means the same
thing as MOV $a, B.  Capital 'A' indicates any combination of A-mode and
A-field.  Lowercase 'a' stands for the A-field only.  Similarly for
capital 'B' and lowercase 'b'.

When discussing running code in situ, indicate the cycle with

   T = cycle

at the top.  Indicate the currently executing statement with the number
of the program followed by "-->" if on the left of the code or "<--"
followed by the number of the program if on the right of the code.  The
instruction(s) which will execute next for the opposing player(s) should
be labelled with the pointer only.  Examples:

   T = 0

        MOV  0,  1   <--
   1--> MOV #0, -1
        JMP -1
............................

   T = 0.5

        MOV  0,  0   <--2
        MOV #0, -1
    --> JMP -1


A Note About Commas:  Some systems do not accept or insist on commas
in between operands.  It is a good idea to insist on commas between
operands however to distinguish

   DAT 0 - 1

as either

   DAT 0, -1

or

   DAT (0-1)   ;  Same as DAT -1

----------------------------------------------------------------------

Q14: Other questions?
A14: Just ask.  Either ask in the newsgroup or send your question to
me at durham@ricevm1.rice.edu.  I will do my best to answer your
question or put you in touch with someone who can.

Mark A. Durham
MAD


Subject: csapda.red (trap.red)
From: <ASMQK@ASUACAD.BITNET>
Date: Monday, 2 Mar 1992 15:59:03 MST
Message-ID: <92062.155903ASMQK@ASUACAD.BITNET>

It sometimes makes to the first place on the X-hill.

;redcode-x
;Name csapda
;Author nandor sieben    asmqk@asuacad.bitnet
start   add eltolas,point        ; mod 4 scan
        jmz -1,@point
        mov point,point+10
        mov #20,0; bomb with spl
        mov bomb,<point+10
        djn -1,-2
        mov point,@point         ; bomb with a single jmp in the middle
        jmp start,#0             ; to get a slave
bomb    spl -1,#0
        dat #0
        dat #0

        dat #0
        dat #0
        dat #0
        dat #0

        dat #0
        dat #0
        dat #0
        dat #0

        dat #0
        dat #0
        dat #0
        dat #0

        dat #0
        dat #0
        dat #0
        dat #0

        dat #0
point   jmp -start+200+2,start-1-200
        mov point-1,<1; the slave cleans the core
        spl -1,start-2
        jmp -2,#0
eltolas dat #77*4,#-77*4; eltolas=shift
        end start


Subject: Sorry...bug found, hill rebuilding
From: wms@iwarp.intel.com (William Shubert)
Date: 2 Mar 92 18:24:51 GMT
Message-ID: <1992Mar2.182451.15623@iWarp.intel.com>


   As has been noticed already here, I added an "age" column to KotH so you can
tell how long a particular fighter has been around.  Unfortunately, this also
intruduced a bug that corrupted the hill database.

   I've fixed the bug, but the hill is in the process of re-running all the
programs.  If you submitted a program between Sunday 5PM and Monday 10PM
pacific time, you didn't get a fair run and you might want to re-submit.

   There will be a large backlog until the hills are done rebuilding.  Probably
later tonight.
				-Bill (wms@iwarp.intel.com)


Subject: RPI-ACM Core Wars Contest
From: nautilus@lachesis.acm.rpi.edu (John M. Twilley)
Date: Tue, 3 Mar 1992 04:14:38 GMT
Message-ID: <g=5sfz+@rpi.edu>

Attention!

The RPI Student Chapter of the ACM is holding a Core Wars Competition,
with cash prizes going to the first and second place competitors.

What is Core Wars?

Core Wars is a simulation where computer programs battle each other to
the death inside the memory, or core.  The concept was first developed
by A. K. Dewdney and D. G. Jones in early 1984, and first publicized in
the 'Computer Recreations' column in the May 1984 issue of "Scientific
American".  Since then, it has changed dramatically and gathered a
worldwide following.  The International Core Wars Society, which runs annual
contests to find the best all-around program, has been in existence for
over six years and has its own newsletter. 

The rules:

1.	The ICWS '88 standard will be used for the basis of the
	competition.  However, due to software constraints, certain
	restrictions apply:

	a.	The pseudo-opcode EQU is not properly implemented in
		the simulator being used for this competition.  Hence,
		it cannot be used in this competition.

	b.	The A-fields and the B-fields need to be separated by
		commas.

2.	The competition will be of a "round-robin" style.  Each program
	will fight every other program, as well as itself, fifty times.
	Scoring will be as follows:  three points for each win, zero 
	points for each loss, and one point for each tie.  Ties will be
	called when each program has executed 80,000 instructions.
	The core will be 8,000 instructions long, and each program will
	be limited to 8,000 active processes.

3.	The entry fee will be $1 per submission for RPI students and $3 per
	submission for all other competitors.  Each competitor will be
	limited to five submissions.  All competitors must reside or attend
	college in the Troy-Albany metropolitan area.  Each submission
	must be accompanied by the competitor's name, e-mail address (if
	any), postal address, and daytime phone number.

4.	The competition will take place on April 6, 1992, at 2:00 PM at
	an as-yet-undetermined location.  Submissions must be sent by either
	mail to RPI-ACM GM Week Contest Committee, Box 96, Troy, NY 
	12180-3590 or by electronic mail to info-corewar@acm.rpi.edu by March
	23, 1992.  Entry fees must be sent by mail to RPI-ACM GM Week Contest
	Committee, Box 96, RPI Student Union, Troy, NY 12180-3590, by the same
	date.  Any submission without a corresponding entry fee will be
	disqualified.  If a submission does not compile when tested on or after
	that date, the author will be given until March 30, 1992, to repair the
	submission.  

5.	Competitors will be subject to the Rensselaer Computer Usage
	Policy while competing.  


A working version of the program to be used for the competition will be
available on the RCS system as soon as possible, and on the ACM
machines under the path /usr/games/corewar.  Also, for other
information, see the Usenet newsgroup rec.games.corewar.  There is an
anonymous FTP site for Core War at soda.berkeley.edu (128.32.131.179),
which has simulator versions for many systems, including PC-compatible,
Macintosh and Unix platforms, as well as other valuable text files
including detailed descriptions of standards. 

Any questions or suggestions should be directed to
info-corewar@acm.rpi.edu.  Please watch this space for further updates
on the contest. 


-- 
John M. Twilley            |  Jesus died for your sins.
nautilus@acm.rpi.edu       |          Make it worth his time.



From: Joshua Osborne <stripes@eng.umd.edu>
Subject: RESULT:  rec.games.xtank.{play|programmer} pass {181:36 | 182:36}
Message-ID: <pa5sa5-@rpi.edu>
Date: Tue, 3 Mar 1992 04:59:24 GMT

Results:
========
Here are the results for the rec.games.xtank.play newgroup voting.
There were 181 valid yes votes and 36 valid no votes.  So,
rec.games.xtank.play passes with a comfortable margin (and ratio).

Here are the results for the rec.games.xtank.programmer newgroup
voting.  There were 182 valid yes votes and 36 valid no votes.  So,
rec.games.xtank.programmer passes with a comfortable margin (and ratio).

Votes mailed to lidl@pix.com were, as was stated in the CFV, ignored;
there were three such votes.  Additionally, there were two invalid
votes, that had no content.

There will be a five-day waiting period to revise the tally in case
of lost votes. Please post any comments on the vote, including lost
votes, to news.groups; do not mail them to me.  At the end of the
waiting period, David Lawrence will send out appropriate newgroup
messages for the two newsgroups.

Below are the way the votes were tallied.  Please note the
"Forgeries" section of the votes below.  I have discounted all yes votes
from the site "cogs.sussex.ac.uk", due to the large number of
duplicate votes from that site, as well as near-simultaneous vote of
approximately 20 people from the same machine within a two-minute
period of time, with a byte-for-byte identical message(!).  As all
the votes were all "Yes" votes for both newsgroups, I have discounted
those votes.  Note that doing this does not affect the outcome of
either of the newsgroup votes.

Voted "yes" only to rec.games.xtank.play:
======================================================================
David C. Stewart <davest@sequent.com>
tero mononen <tmo@sauna.cs.hut.fi>
toms@ichips.intel.com

Voted "yes" only to rec.games.xtank.programmer:
======================================================================
Arne Henrik Juul <arnej@lise.unit.no>
Brian Onn <Brian.Onn@Canada.Sun.COM>
dbwilson@theory.lcs.mit.edu (David Bruce Wilson)
gsmith@reed.edu

Voted "yes" on both rec.games.xtank.play & rec.games.xtank.programmer:
======================================================================
"Chris P. Ross" <cross@eng.umd.edu>
"Clayton A. Smith" <csmith@eng.umd.edu>
"Corp Reed" <ecr2@midway.uchicago.edu>
"Email: bill@banana.fedex.com  Phone: (901)797-6328" <bill@banana.fedex.com>
"Eric A. Anderson" <ea08+@andrew.cmu.edu>
"Gordon H. Smith" <aahz@eng.umd.edu>
"Joseph Malcolm" <jmalcolm@sura.net>
"Kurt J. Lidl" <lidl@eng.umd.edu>
"Lui Sieh" <sieh@midway.uchicago.edu>
"Matt T. Senft" <senft@eng.umd.edu>
"Matthew T. Russotto" <russotto@eng.umd.edu>
"Maxime Taksar" <mmt@latour.berkeley.edu>
"Shelley D. Heburn" <errand@eng.umd.edu>
"Timothy L. Nali" <tn0s+@andrew.cmu.edu>
"William T. Katz" <wk5w@davinci.acc.Virginia.EDU>
----------jeff.the.wonder.llama@eos.ncsu.edu,
<JJJ101@PSUVM.PSU.EDU>
Adam Thompson <umthom61@ccu.UManitoba.CA>
Andy Sheen <sheen@src.bae.co.uk>
Anthony Baxter <anthony@nella6.cc.monash.edu.au>
Arthur Stephens <stephens@src.bae.co.uk>
Austin Adam J <cs261111@ucs.usl.edu>
Benjamin Daniel Taylor <bt11+@andrew.cmu.edu>
Billy Yow 283-4051 <yow@sweetpea.jsc.nasa.gov>
Blair Zajac <blair@seismo.gps.caltech.edu>
Chad Phillip Brown <yandros@Athena.MIT.EDU>
Chris Hassell <hassell@ucsu.Colorado.EDU>
Chris Moore <moore@src.bae.co.uk>
Colin Blakeman <blakeman@src.bae.co.uk>
Colum Mylod at ORACLE Europe <cmylod@nl.oracle.com>
Daniel Edward Lovinger <dl2n+@andrew.cmu.edu>
David Hsu <hsu@eng.umd.edu>
David Partain <davpa@ida.liu.se>
David Reeve Sward <dsa3+@andrew.cmu.edu>
David Young <fred@eng.umd.edu>
Debbie Greenberg <darth@eng.umd.edu>
Denis Howe <dbh@doc.imperial.ac.uk>
Dougal Scott <dwagon@nella10.cc.monash.edu.au>
Dougal Scott <dwagon@nella8.cc.monash.edu.au>
Eric Eidson <Eric.H.Eidson@eng.auburn.edu>
Erik Sherk <sherk@sura.net>
Frederick Hartman <fhartman@umaxc.weeg.uiowa.edu>
Ian Borchardt <iborchar@physics.adelaide.edu.au>
J Eric Townsend <JET@UH.EDU>
James Collins <jcollins@nunki.usc.edu>
James da Silva <jds@cs.UMD.EDU>
James.Mangin@Corp.Sun.COM (Benefits Coordinator-Corporate Site)
Jan Mattsson  <janm@Sofia.DoCS.UU.SE>
Jason.Cassee@Corp.Sun.COM (Jason Cassee)
Jeff Butterworth <butterwo@cs.unc.edu>
Jeff Jensen <jeff@jarthur.Claremont.edu>
Jeffrey Spence Jeffress <jsj@ravl.rice.edu>
John Gordon <gordon@osiris.cso.uiuc.edu>
Joshua Osborne <stripes@eng.umd.edu>
Kevin Martin <sigma@ipl.rpi.edu>
Kristof.Verschaetse@cs.kuleuven.ac.be (Kristof Verschaetse)
Lawrence Shields <shiell@rpi.edu>
Leif Hedstrom <leif@ifm.liu.se>
Lewis Bruck <lbruck@eng.umd.edu>
Marc Horowitz <marc@Athena.MIT.EDU>
Mark Bullen <bullen@src.bae.co.uk>
Matt Cooper <matt@computer-science.manchester.ac.uk>
Matthew Ward <scud7@central.sussex.ac.uk>
Mejia Pablo <team13@ucs.usl.edu>
Michael C. Lewis <lewism@rpi.edu>
Michael Jansson <micja@ida.liu.se>
Michael Thomas Lee <mikelee@wam.umd.edu>
Mike McDonald <bigmac@eng.umd.edu>
Neil Matthews <matthews@src.bae.co.uk>
Nightline <aafc6@syma.sussex.ac.uk>
Paolo Montrasio <montra@pluto.sm.dsi.unimi.it>
Per Abrahamsen <abraham@iesd.auc.dk>
Philip.Dutre@cs.kuleuven.ac.be (Phil Dutre)
Po Shan Cheah <pc30@cunixb.cc.columbia.edu>
Rob Dawkins <dawkins@src.bae.co.uk>
Rob McKaughan <rob@jarthur.Claremont.EDU>
Robert Forsman <thoth@reef.cis.ufl.edu>
Rupert G. Goldie <rgg@aaii.oz.au>
Sean Barrett <buzzard@eng.umd.edu>
Seth Robertson <seth@ctr.columbia.edu>
Skeeve <skeeve@eng.umd.edu>
Stefan Svenberg <ssv@ida.liu.se>
Stig Hemmer <stig@lise.unit.no>
Sting Rules! <d098@jupiter.Sun.CSD.unb.ca>
T. Arensman <a0354937@let.rug.nl>
Tasuki Hirata <sukes@eng.umd.edu>
Terence_Donahue@NeXT.COM
Tero Kivinen <kivinen@joker.cs.hut.fi>
The Fire-breathing Penguin <black@westford.ccur.com>
Thorsten Alteholz <ry52@rz.uni-karlsruhe.de>
Tim Day <tday@ps.ucl.ac.uk>
Velu Sinha <velu@src.umd.edu>
WLBRAD03@ulkyvx.louisville.edu
Xtank Mail Account <xtank@shadowfax.knox.tn.us>
Yanek Martinson <yanek@mthvax.cs.miami.edu>
acs97393@zach.fit.edu ( SNEERINGER)
adamfox@homer.super.org
as666@cleveland.Freenet.Edu (Jonathan Roy)
bguest@ems.cdc.com (Brandon Guest)
bjp@sura.net
booga@ibmpa.awdpa.ibm.com (Steve Jankowski)
bouma@cs.purdue.edu
bwoodall@bilbo.Qualcomm.COM (Bill Woodall)
ccoprdg@prism.gatech.edu (Drew Gonczi)
chc@orion.ksc.nasa.gov (Charles Curley)
cs132093@cs.brown.edu (Mark Prince)
csa@pennies.sw.stratus.com (Chris Arthur)
d8ilvja@dtek.chalmers.se
davox!paul@uunet.UU.NET (Paul Kneipp)
djm@gnu.ai.mit.edu (David J. MacKenzie)
eichin@ATHENA.MIT.EDU ("Mark W. Eichin")
evan@cs.mu.OZ.AU (Evan Harris)
even@wisdom.weizmann.ac.il (Even Baruch)
gaynor@remus.rutgers.edu (Silver)
gibbonst@cda.mrs.umn.edu (Tom Gibbons         )
glennc@rigel.cs.pdx.edu
hagger@cs.UMD.EDU
hship@teton.sw.stratus.com (Howard Ship)
jacobsd@prism.CS.ORST.EDU
jamie (Jamie MacDonald)
janssedr@cda.mrs.umn.edu (Devin R. Janssen 1424349)
jdean@psl.nmsu.edu
jerryw@cs.UMD.EDU (Jerry Wieber)
jesup@cbmvax.cbm.commodore.com (Randell Jesup)
jg@cs.brown.edu (Jeremy Gaffney)
jhpace1@eos.ncsu.edu
jimp@dg-rtp.dg.com (Jim Pendergraft)
jmb@ideas.com (Jonathan M. Bresler)
jmb@ideas.com (Jonathan M. Bresler)
jrc@concurrent.co.uk
jsc@slayer.MIT.EDU (Jin S. Choi)
justice@moeng2.minc.umd.edu (Joseph R. Justice)
kane@urbana.mcd.mot.com (Patrick E Kane)
keith@dinosaur.lonestar.org (Keith Cantrell)
labc-1ad@WEB.berkeley.edu (Eric van Bezooijen)
m91kgh@bellatrix.tdb.uu.se (Karl-Gunnar Hultland)
m91nen@bellatrix.tdb.uu.se (Nils Engstrom)
markn@next1.mrs.umn.edu (Mark Nygaard)
mb7@ukc.ac.uk
mba@pd2.ccd.harris.com (Belinda Asbell)
mcphee@nxsci245.mrs.umn.edu (Nic McPhee)
mjr@uther.Calvin.EDU (Matt Ranney)
mouser@cs.UMD.EDU
mox@vpnet.chi.il.us (William Moxley)
msj@cs.brown.edu (Michael S. Johnson)
mute@wpi.WPI.EDU (Joshua Thompson Brandt)
nabil@cse.ogi.edu
neighorn@qiclab.scn.rain.com (Steven C. Neighorn)
nroworth@nl.oracle.com (Nick Roworth)
nwill@cs.tamu.edu (William R Needels)
owens@cookiemonster.cc.buffalo.edu (Bill Owens)
pap@gemini.moscom.com (Patrick Palmer)
pap@moscom.com (Patrick Palmer)
peterstr@cda.mrs.umn.edu (Thomas R. Peterson  1254630)
phillips@swanee.ee.uwa.oz.au (PHILLIPS C J)
pogo@wpi.WPI.EDU (between thought and expression)
poist@ibmpa.awdpa.ibm.com (Gregory Poist)
profesor@wpi.WPI.EDU (Matthew E Cross)
qbarnes@urbana.mcd.mot.com (Quentin Barnes)
reynolds@fsg.com (Brian Reynolds)
rich@grayhawk.rent.com (Richard Harms)
rocky@prism.poly.edu (Rocky Shiotsuki)
rpotter@halibut.cis.upenn.edu
s0132216@usurp.Calvin.EDU (Terrence W. Dexter)
s0146607@usurp.Calvin.EDU (Gideon Glass)
shepard@wse.pa.dec.com
square@cco.caltech.edu (Hung Fai Fong)
stst@vuse.vanderbilt.edu (Stefan Strack)
stus5239@mary.cs.fredonia.edu (Kevin Stussman)
tada@Athena.MIT.EDU
terjej@edb.tih.no
thomas (Georg Thomas)
tom@goat.clipper.ingr.com (Tom Granvold)
triad!jback@spdev.East.Sun.COM (Joseph Backo)
unknown@ucscb.UCSC.EDU (unknown user)
wchuang@Athena.MIT.EDU
wcs@moscom.com (William Swetman)
wjb@moscom.com (Bill de Beaubien)

Voted "no" only to rec.games.xtank.programmer:
======================================================================
tero mononen <tmo@sauna.cs.hut.fi>
toms@ichips.intel.com

Voted "no" only to rec.games.xtank.play:
======================================================================
Arne Henrik Juul <arnej@lise.unit.no>
gsmith@reed.edu

Voted "no" on both rec.games.xtank.play & rec.games.xtank.programmer:
======================================================================
"Todd L. Masco" <tm2b+@andrew.cmu.edu>
Brendan Kehoe <brendan@cs.widener.edu>
Chris Newman <cn0h+@andrew.cmu.edu>
Christophe Wolfhugel <Christophe.Wolfhugel@grasp1.univ-lyon1.fr>
D.W.Wright@bnr.co.uk
Helge Hauglin <helgeha@ifi.uio.no>
James Smith <ENGJS@wombat.newcastle.edu.au>
Jim Roche <roche@cs.rochester.edu>
Kelly Derek Deyoe <kd2a+@andrew.cmu.edu>
Kjetil Torgrim Homme <kjetilho@ifi.uio.no>
Mitchell E. Gold <goldm@rpi.edu>
Nick Sayer <mrapple@quack.sac.ca.us>
Norman Yarvin <yarvin-norman@CS.YALE.EDU>
Roland Kaltefleiter <kaltef@theo-physik.uni-kiel.dbp.de>
Sven Heinicke <sven@cs.widener.edu>
austin@franklin.com (Austin G. Hastings)
barrett@cc.gatech.edu (James C. Barrett)
cdr@kpc.com (Carl Rigney)
dacosta@prl.philips.nl (Paulo da Costa 42147)
don@q-aais.navo.navy.mil (Don Newcomb)
dziuk@hsi86.hsi.com (Ronald V. Dziuk Jr.)
emcguire@ccad.uiowa.edu (Ed McGuire)
homebru!smith!dick@cs.uchicago.edu
jbuck@ohm.Berkeley.EDU (Joe Buck)
jrp@xtree.xtree.com (JIM PICKERING)
kenney@hsi86.hsi.com (Brian Kenney)
koziol@ncsa.uiuc.edu (Quincey Koziol)
marier@blkcmb.zso.dec.com
mehta@ucunix.san.uc.EDU (mehta)
rick@crick.ssctr.bcm.tmc.edu (Richard H. Miller)
schaller@hsi86.hsi.com (Dave V. Schaller)
scott@asd.com (Scott Barman)
scott@xcf.berkeley.edu (Scott Silvey)
tsdavies@mailbox.syr.edu (Real life?  Ha!)

Invalid votes:
======================================================================
Paul Schulz <pschulz@physics.adelaide.edu.au>
ce202a2@prism.gatech.edu (Peter L. Thomas, AE)

Apparently forged "yes" votes:
======================================================================
Ai Li <aili@cogs.sussex.ac.uk>
Alastair S Coles <acoles@cogs.sussex.ac.uk>
Andras Pfening <andrasp@cogs.sussex.ac.uk>
Andy Williams <andyw@cogs.sussex.ac.uk>
Bruce R Leigh <brucel@cogs.sussex.ac.uk>
Chi Y Siu <chis@cogs.sussex.ac.uk>
Christopher Hogg <chrishog@cogs.sussex.ac.uk>
Evil Dan <dwestoby@cogs.sussex.ac.uk>
Gordon M S Jackson <gordonj@cogs.sussex.ac.uk>
James Goodlet <jamesg@cogs.sussex.ac.uk>
Junko Ogiue <jogiue@cogs.sussex.ac.uk>
Keiko Suzuki <keikos@cogs.sussex.ac.uk>
Kieran Turner <kierant@cogs.sussex.ac.uk>
Kristen Hallahan <kristenh@cogs.sussex.ac.uk>
Lord Yak Da Hairy <johny@cogs.sussex.ac.uk>
MUD administrator <mud@cogs.sussex.ac.uk>
Mark Allen <marka@cogs.sussex.ac.uk>
Mark Foster <markfo@cogs.sussex.ac.uk>
Michael Bulford <michaelb@cogs.sussex.ac.uk>
Michael Fransman <michaelf@cogs.sussex.ac.uk>
Neil Chawla <neilch@cogs.sussex.ac.uk>
Pranath Fernando <pranathf@cogs.sussex.ac.uk>
Rajinder Bhalla <rbhalla@cogs.sussex.ac.uk>
Richard Dallaway <richardd@cogs.sussex.ac.uk>
Siu Mak <sium@cogs.sussex.ac.uk>
Stephanie Clarke <stephcl@cogs.sussex.ac.uk>
The Teddy Man <johnm@cogs.sussex.ac.uk>
Toby Champion <tobych@cogs.sussex.ac.uk>
Valda A Dolman <valdad@cogs.sussex.ac.uk>


From: awesley1@gara.une.oz.au (Anthony WESLEY)
Subject: Re: soda.berkeley.edu
Message-ID: <11217@gara.une.oz.au>
Date: 6 Mar 92 02:09:59 GMT

From article <1679E87C8.DURHAM@ricevm1.rice.edu>, by DURHAM@ricevm1.rice.edu (Mark A. Durham):
> iraun1.ira.uka.de (129.13.10.90)
> and contains most of what soda has/d under /pub/X11/corewars.
> MAD
	Beware the file /pub/X11/corewars/corewars.arc as this is NOT a corewar
archive but a hard disk speed testing utility! I found this out the hard way...

					B


From: jesensky@cirith-ungol.endor.cs.psu.edu (James J Jesensky)
Subject: Need cwdisp.h for KotH v2
Message-ID: <vx3Hrad-5@cs.psu.edu>
Date: Fri, 6 Mar 1992 03:09:28 GMT

I seem to be missing cwdisp.h for KotH v2. I'd
appreciate it if someone could send me a copy.

Thanks in advance
J.J.



From: ac999108@umbc5.umbc.edu (ac999108)
Subject: Re: New corewar fan...
Message-ID: <1992Mar6.181611.13119@umbc3.umbc.edu>
Date: Fri, 6 Mar 1992 18:16:11 GMT

I too am a new Corewar fan.  I read about it a long time ago, but only recently
got a program for my ST.  Is there a FTP site or anything that has more 
information and ideas about making programs?

Email is always nice.. :)  Have a nice one...


-- 
   /------------/ Paul Danckaert /---------------------------------------/
   /----------------------/ Ac999108@Umbc5.Umbc.Edu /--------------------/
   /----/ Fnet#500 /-------------------/ GEnie: P.Danckaert /------------/



Subject: Comper-2a
From: ajpierce@med.unc.edu (Andrew Pierce)
Date: 8 Mar 92 13:56:30 GMT
Message-ID: <1992Mar8.135630.15245@samba.oit.unc.edu>


   Here is the code to Comper-2a.  At the moment Comper and Comper-2 are
on KotH floating at around 5th or so.  Basically Comper is similar in
philosophy to Sargent (Kevin Whyte -- kwhyte@zaphod.uchicago.edu) in that
it searches the core looking for a target.  When it finds one, it bombs it
with a jmp to a useless spl routine.  The bottom line on this type of
strategy is:  can you scan the core faster than you can bomb the core?  If
the answer to this is no, then you might as well just bomb directly.
Comper searches memory using the cmp instruction, which after all is
really what the whole point of having a cmp instruction is.  This was
first mentioned to the net by Stefan Strack (stst@vuse.vanderbilt.edu).
The virtue of using cmp rather than jmn is that jmn requires two cycles to
scan 1 memory location, whereas cmp, properly implemented, can in three
cycles scan 2 memory locations, a 50% improvement.  The other plus is that
other programs cannot make themselves look smaller than they really are
through use of zero valued B-fields.  It really is amazing how much you
can do with zero valued B-fields so this is pretty important.
   Technically, Comper uses an off-axis cmp scan, i.e. the locations
examined are not exactly half the core size apart.  In the first Comper
the searches are 4000 unit apart (it is designed for coresize = 8000)
which simplifies the math but which leaves it vulnerable to programs which
make duplicates of themselves half the core away.  This method of hiding
doesn't work against versions 2 or 2a.  Once it finds differing memory
locations, it ensures that it won't bomb itself and then bombs with a
"sliding trap door", a jmp prefaced by slt #-1,0 instructions.  A program
which executes any of the slt's will slide down memory until it hits the
jmp to the spl routine.  In this way the jmp values don't have to be
recalculated and also targets for anti-vampire programs are reduced.
Comper finishes completely scanning the core in 4000 iterations of the
search routine and then zeros the core, zeroing the spl trap last.
   Vulnerabilities:  as any scanner, it gets confused by bombs dropped
around the core.  A small, rapid pattern bomber can have a scanner program
trapping the bombs rather than the program which may slow the scanner down
sufficiently to make the difference.  A scanner is in general also
vulnerable to other scanners.
   Enjoy!
     -Andy
ajpierce@med.unc.edu

;redcode verbose
;name Comper-2a
;author Andy Pierce (ajpierce@med.unc.edu)
;strategy  as all the others which bomb with jmp's to a spl routine
;strategy  except scans using cmp instead of jmz
;strategy  scans 50% faster (2 in 3  vs  1 in 2), not fooled by "stealth"
;strategy  v2:  off-axis compare  -- cannot "hide in own reflection"
;strategy  v2:  unroll killing loop
;strategy  v2a: marginally more robust
;strategy  March 8th, 1992

find	cmp 299,4250
	jmp kill,0
back	add offset,find
	djn find,#4001			;iterations
dest	cmp 0,0
shuff	slt #-1,0
blitz	mov -7,<0
	djn -1,#7997
	jmp 0,0
grind	spl 0,0
index	jmp -1,0
hit1	dat #0,#0
hit2	dat #0,#0

kill	mov #2,index			;find is x,y
	mov mod1,hit1
	mov mod2,hit2
rekill	sub find,@index
	sub dest,dest
	sub @index,dest
	slt #40,dest
	jmp back,0
	sub #5,dest
	mov @index,<dest
	mov shuff,<dest
	mov shuff,<dest
	mov shuff,<dest
	mov shuff,<dest
kloop	djn rekill,index
	jmp back,0

mod1	jmp 6,3946			;  +6,-5  of  0,3951
mod2	jmp -3945,-5			;  +6,-5  of  -3951,0
offset	dat #49,#49


Subject: RR.BTM - round-robin cw tournament scheduler for 4DOS (PC)
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Date: 8 Mar 92 22:05:05 GMT
Message-ID: <1992Mar8.220505.29036@vuse.vanderbilt.edu>

Included below is a poor man's version of the KotH round-robin scheduler for
DOS that uses KOTH.EXE, the PC-version of Bill Shubert's corewar program.
RR.BTM is a batch file that requires the command.com replacement 4DOS
(version 3.0 and above). It will not work with regular command.com, because
it uses 4DOS-specific function calls (4DOS has a myriad of neat features;
check it out, it's shareware).

RR.BTM is invoked with any numbers of programs on the command line, like
this:

C>rr xtc dwarf pest-x trinity2 mutagenp

The filename extension (by default .red) must not be included. RR.BTM
schedules a round-robin tournament, with programs fighting each other 10*N
times (N=number of programs); this can be changed by editing the $opt
variable. Scores are calculated, and the rank-order of performance is stored
in scores.rr!. E.g.:

96 (30 14 6): trinity2
86 (27 18 5): mutagenp
77 (21 15 14): pest-x
75 (22 19 9): xtc
16 (0 34 16): dwarf

Individual scores, ie how well "fighter" did against the other programs, are
stored in fighter.rr!.

Enjoy, Stefan (stst@vuse.vanderbilt.edu)


----- CUT HERE ----- CUT HERE ----- CUT HERE ------ CUT HERE -----
rem     RR.BTM -  4DOS (V3+) batch for Core War round-robin tournament
rem     Version 1.0, 3/7/92 by Stefan Strack (stst@vuse.vanderbilt.edu)
rem     External programs: KOTH.EXE, SORT.EXE (comes with DOS)
rem     Usage: rr fighter1 fighter2 .. fighterN
rem     ("fighter" has no extension, use $ext to set extension)
rem     Result files: *.RR!

rem KOTH.EXE options, append "-spl_time -all_modes" for -x tournament
rem programs fight each other N*2*rounds times (N=number of programs)
set $opt=-rounds 5 -maxprocs 200

rem verbose output flag
set $verbose=y

rem fighter filename extension
set $ext=red

rem temp and result filename extensions
set $tmp={!}
set $res=rr!

if "%&" == "" echo usage: rr fighter1 fighter2 .. fighterN
del *.%$tmp >& nul
for %p1 in (%&) for %p2 in (%&) gosub fight
for %prog in (%&) gosub score
sort /r < unsorted.%$tmp > scores.%$res
echo Scores file scores.%$res:
type scores.%$res
goto end

:fight
        koth %p1.%$ext %p2.%$ext %$opt > raw.%$tmp
        if %? == 1 goto error
        set $aline=%@line[raw.%$tmp,0]
        set $wins=%@word[0,%$aline]
        set $losses=%@word[1,%$aline]
        set $ties=%@word[2,%$aline]
        echo %$wins %$losses %$ties >> %p1.%$tmp
        echo %$losses %$wins %$ties >> %p2.%$tmp
        echo %p1 wins: %$wins, %p2 wins: %$losses, ties: %$ties >> %p1.%$res
        iff "%$verbose"=="y" then
                echo %p1 wins: %$wins, %p2 wins: %$losses, ties: %$ties
return

:score
        iff "%$verbose"=="y" then
                echo Calculating score for %prog ...
        set $wins=0
        set $losses=0
        set $ties=0
        set $nlines=%@lines[%prog.%$tmp]
        set $no=0
        :addup
                iff %$no gt %$nlines goto done
                set $aline=%@line[%prog.%$tmp,%$no]
                set $wins=%@eval[%$wins + %@word[0,%$aline]]
                set $losses=%@eval[%$losses + %@word[1,%$aline]]
                set $ties=%@eval[%$ties + %@word[2,%$aline]]
                set $no=%@eval[%$no + 1]
                goto addup
        :done
        set $total=%@eval[%$wins * 3 + %$ties]
        echo %$total (%$wins %$losses %$ties): %prog  >> unsorted.%$tmp
return

:error
echo KOTH.EXE error: maxprocs to large?
:end
del *.%$tmp > nul
quit


From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Re: RR.BTM - round-robin cw tournament scheduler for 4DOS (PC)
Message-ID: <1992Mar8.230212.2966@vuse.vanderbilt.edu>
Date: Sun, 8 Mar 1992 23:02:12 GMT


Oops, just noticed that the last line of RR.BTM got clipped off. The missing
last line is:

quit

-Stefan (stst@vuse.vanderbilt.edu)


From: tkimball@utopia.rutgers.edu (Timothy Kimball)
Subject: Windows CoreWar?
Message-ID: <Mar.9.10.12.34.1992.19317@utopia.rutgers.edu>
Date: 9 Mar 92 15:12:35 GMT


I know that this was a previous post, but I lost my printout :-)

	Where is the Microsoft Windows version of CoreWars?  I
remember reading a post sometime ago about it.  Please email me.

		Thanks,

	T. S. Kimball   --   just a new netter


Subject: mars88
Message-ID: <92069.172902ASMQK@ASUACAD.BITNET>
From: <ASMQK@ASUACAD.BITNET>
Date: Monday, 9 Mar 1992 17:29:02 MST

You can download it from comp.binaries.ibm.pc
Nandor.


From: gt6525c@prism.gatech.EDU (gt6525c GALLATY,DAMON JAKOB)
Subject: Request for Docs and Code for CoreWars
Message-ID: <51517@hydra.gatech.EDU>
Date: 9 Mar 92 18:08:23 GMT

I know you've probably seen this request hundreds of times before, but
I've only recently been reading this newsgroup. I played CoreWars about
3 years ago, and I can only assume that much has changed since then.
Could somebody either send me or point me in the direction of the
latest rules and documentation for CoreWars? Also, a place where I might
find examples and strategies similar to those posted here would be
helpful. Thanks a lot. You can e-mail me using the address in the header,
or the one below, whatever's easier. Thanks again!

-- 
"Have you ever danced with the Devil by the pale moonlight?
 I ask that of all my prey. I just like the sound of it..."  - the Joker
************************************************************************
Damon Gallaty                                E-mail: dgal@cad.gatech.edu


Subject: VDT Super Tuesday Round Two Results
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Date: Wed, 11 Mar 1992 07:35:07 GMT
Message-ID: <167A7164B.DURHAM@ricevm1.rice.edu>

RESULTS...RESULTS...RESULTS...RESULTS...RESULTS...RESULTS...RESULTS...

Here are the VDT Super Tuesday Round Two Tournament Results!

Battles occured in a core size of 8000 with a maximum of 64 tasks and
ties were called after 100 000 cycles.  Warriors battled head-to-head
twice.  As an example, in the first battle Dime was loaded into location
zero and Locusts was loaded into location 1788.  Dime executed first.  For
the second battle, Locusts was loaded into location zero and executed
first and Dime was loaded into location 1788 and executed second.  The
location 1788 was chosen at random and was used for all battles in Round
Two.


In Round Two of the "Battle of the Stefans", Stefan Haenssgen's "Dime" took
on Stefan Strack's "Locusts":

0 / 1788                                Winner                  Cycle
--------                                ------                  -----
Dime / Locusts                          Locusts                  5222
Locusts / Dime                          Locusts                 11229


In the rematch of Nandor Sieben and Scott Adkins, Nandor Sieben's very
appropriately named "Living Dead" battled Scott Adkins' "Virus":

Living Dead / Virus                      Virus                   8519
Virus / Living Dead                      Virus                  45125

(Incidentally, this was both the most visually and aurally exciting matchup
of Round Two).


Thus, Stefan Strack advances to take on Scott Adkins in Round Three while
Stefan Haenssgen will battle Nandor Sieben.


Meanwhile, in the Round One-Winner's bracket Adam Caldwell's "X5" was up
against S. Halvorsen's "Cake":

X5 / Cake                                  X5                   18170
Cake / X5                                             Tie

Thus, Adam Caldwell continues to advance.  Unfortunately, neither Caldwell
nor Halvorsen have opponents for the next round yet as the rest of the
matches were draws and will have to be replayed in Round Three.


Also in the Round One-Winner's Bracket, William Shubert's "Leech" took on
Aleksey Baulin's "V2":

Leech / V2                                Leech                  319
V2 / Leech                                  V2                  25564


In the Round One-Loser's Bracket, Arne Juul's "Rat" battled the team of
Campbell Fraser and Scott Drummond's entry of "Intangible Worm":

Rat / Intangible Worm                      Rat                  30918
Intangible Worm / Rat                 Intangible Worm           12188


Also in the Round One-Loser's Bracket, John Wetmiller's "Gulliver"
travelled to Stig Hemmer's "HideOut":

Gulliver / HideOut                                      Tie
HideOut / Gulliver                                      Tie


Round Three will be just like Round Two (except with a new random second
location, of course).  Contestants will need to submit new warriors on or
before April 1st, otherwise their Round Two entries will be used for
Round Three.  I apologize for the unfortunate delay in executing and
reporting on Round Two.  Once again, if opponent's enter warriors early,
I will try to execute the round and report the results early.

Mark A. Durham
MAD



Subject: Tournament Players
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Date: Wed, 11 Mar 1992 07:36:05 GMT
Message-ID: <167A71685.DURHAM@ricevm1.rice.edu>

I really could use three more players for the Valentine tournament.  I
especially need one to battle Ray Cromwell who has been waiting for
weeks.  Please, only submit one warrior and those of you already in the
tournament are ineligible.

Thanks,
Mark A. Durham
MAD

P.S. Email me for more details if you wish.


Subject: 28dwarf.red
From: Vision@cup.portal.com (Vision - Tester)
Date: Wed, 11 Mar 92 12:45:43 PST
Message-ID: <55700@cup.portal.com>

Here's a VERY simple little program for some Corewar newbies who want a
step by step explanation, and a nice little warrior to practice against.
He is ICWS '88 compatable(so run it on Nandor's GREAT mars88 program!)

-----BEGIN------CUT---HERE----------------------------------------------------
add #28,2     ;add the number 28 to the B field of 2 ahead
mov 2,@1      ;move the address(ie copy) 2 ahead at the number in the B field 1
jmp -2,#3201  ;ahead.  Jmp to add instruction.  # is like a DAT in the b field
dat #0,#0     ;This is the guy that gets placed in memory, he is very nasty
	      ;when executed, ie, he kills the other code.
	      ;This program will not kill itself, for it bombs every 4, and is
	      ;only 3 long(it doesnt matter if it bombs it's own dat #0,#0
	      ;it's not very efficent, but it gets the job done.
------END-------CUT---HERE----------------------------------------------------
Cut that guy out, and run it in a corewar program, and hopefully you'll be
on your way to a happy and successful career in Corewar.
--pete


Subject: age top ten
Message-ID: <92071.133144ASMQK@ASUACAD.BITNET>
From: <ASMQK@ASUACAD.BITNET>
Date: Wednesday, 11 Mar 1992 13:31:44 MST

Bill, would it be possible?


Subject: Locusts 2.2
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Date: Wed, 11 Mar 1992 18:08:31 GMT
Message-ID: <1992Mar11.180831.18809@vuse.vanderbilt.edu>

Here's my first round VDT entry and winner "Locusts 2.2". It does fairly well
on the standard and -x hills, but was written to take care of Stefan
Haenssgen's QUARTER series specifically. Strategy is simple: scan for
non-zero B-field address, start up a dwarf 110 address before it, and
continue scanning. The 110-offset seems to improve the odds against programs
that have their code scattered in the 100-address segment maximally allowed
by KotH.

-Stefan (stst@vuse.vanderbilt.edu)

;redcode
;name Locusts 2.2
;author Stefan Strack
;strategy Spawn off bombers near enemy code
;strategy Version 2.0: smaller, changed constants
;strategy         2.1: one less non-zero B-field, changed constants
;strategy              rearranged code to evade mod-4 scanners
;strategy         2.2: copies bombers farther ahead of enemy
;strategy Submitted: @date@

DIST    EQU     79  ; scan increment (mod 5/11 scan)
OFFSET  EQU     110 ; bomber starts that far ahead of enemy
BOMB    EQU     20  ; hopefully DAT #0
bombptr EQU     (b1-2)

spawn   ADD     #OFFSET,scanptr     ; copy bomber OFFSET addresses ahead
scanptr MOV     b2,     scanptr     ; of non-zero B-field address
        MOV     b1,     <scanptr
        SPL     @scanptr            ; and start it up
scan    ADD     #DIST,  scanptr     ; start here: scan for non-zero B-field
        JMZ     scan,   <scanptr
        JMP     spawn               ; found
        DAT     #0                  ; spacing to fool mod-4 scanners

; ----- The Bomber
b1      MOV     BOMB,   <bombptr
b2      JMP     b1,     <bombptr

        END     scan



From: asdyp@acad2.alaska.edu
Subject: Re: Windows CoreWar?
Message-ID: <1992Mar12.042823.1@acad2.alaska.edu>
Date: 12 Mar 92 08:28:23 GMT

In article <Mar.9.10.12.34.1992.19317@utopia.rutgers.edu>, tkimball@utopia.rutgers.edu (Timothy Kimball) writes:
> 
> 	Where is the Microsoft Windows version of CoreWars?  I
> remember reading a post sometime ago about it.  Please email me.
> 
> 		Thanks,
> 
> 	T. S. Kimball   --   just a new netter

Windows Corewar?? Eh?? I just crawled out of the sludge, so please enlighten
me.  Where can I get this Windows Corewar, or is this just something to tease
me for a while?


From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Subject: The MADgic Core Version 4.0
Message-ID: <167A83C4B.DURHAM@ricevm1.rice.edu>
Date: Thu, 12 Mar 1992 10:17:15 GMT

Well, it is finally here.  I have uploaded version 4.0 of The MADgic Core
to both soda.berkeley.edu (YES! soda is back) and ab20.larc.nasa.gov.
(The MADgic Core is for Amiga computers).

On soda, you'll find it in /pub/corewar/incoming or /pub/corewar/systems
as MADgic40.lzh along with MADgic40.readme which describes some of the
changes.

On ab20, you'll find it in /incoming/amiga or /amiga/games/strategy as
madgic-corewar-4.0.lzh along with madgic-corewar-4.0.readme.

The archive should be decompressed to an empty floppy disk to get the
full effect of the system.  It requires about 90% of an 880K disk.

New for 4.0:
   Keys:
      Menu short cuts now work with or without the Right Amiga key
      depressed.  Foreign keyboard?  Strange keymap?  Dvorak lover?
      No trouble!  It is taken care of.  While we are on the subject
      of keys, be sure to try Left Amiga-V for OK gadgets and
      Right Amiga-B for Cancel gadgets.  Also, play with the cursor keys
      (and SHIFTed cursor keys and ALTed cursor keys) in the new Load
      requester (see below).  Don't forget these other short cuts:
      Right Amiga-ALT to deselect string gadgets; Right Amiga-Q to undo
      changes in a string gadget; and Right Amiga-X to clear a string
      gadget.

   Configurable Sound:
      Allows you to assign different frequencies (in Hz) to different
      instructions.  Instructions for Player A are one octave above
      instructions for Player B - the frequencies for which are displayed
      (and alterable) in the Sound... requester.  Hit the Sound button to
      turn sound on or off.

   Load Requester with that Release 2.0 look-and-feel:
      Many 3.x problems have been fixed here.  The AReq, BReq, and Random
      gadgets are all accessible from single keystrokes.

   Go:
      Go has cleaned up its act.  It is now a synonym for Continue.

   Windows:
      The main Core Window can now be sent Forward and Backward with single
      keystrokes.  The Tasks Gauge and Timer Windows can both be moved
      about (as well as the Trace and Memory Windows) by selecting the
      window and then depressing the cursor keys.  Be sure to try them
      SHIFTed and ALTed.

   Bugs, bugs, bugs:
      I have discovered and eradicated many potential 3.x bugs.

   FastMARS
   FastMARS88
   SmallMARS
   SmallMARS88:
      When you want blazing speed and versatility in a small package, these
      four programs are it.  No graphics or debugging - just fast and small.

   Redcode:
      Redcode programs from the 1987, 1988, 1989, and 1990 ICWS tournaments.
      No assembly required!

   TMARS:
      A round-robin tournament manager program.  It is actually encrypted
      in the archive.  This is to encourage you to register your copy of
      The MADgic Core with me.  Registration is free.  I just want to keep
      track of those using the system.  When I receive your registration,
      I'll send you the MADgic word which decrypts the program.


I think you'll agree that The MADgic Core v4.0 is "Worth its wait in gold!"

        Mark A. Durham (MAD)
 Email: durham@ricevm1.rice.edu
 GEnie: M.DURHAM2
USmail: P.O. Box 301173
        Houston, TX 77230-1173



From: brown-sh@news.cis.ohio-state.edu (shawn c brown)
Subject: This game
Message-ID: <9203150014.AA18323@boa.cis.ohio-state.edu>
Date: Sun, 15 Mar 1992 00:14:05 GMT


	I'm new to this game and have no idea where to start.  I'm a computer
science major, so I know how to program, and I've had some assembly experience.
Could anyone give me some instruction or the location of a good .doc file on
corewars?  Thanks a lot...


Shawn Brown
Ohio State University


From: mwilson@crash.cts.com (Marc Wilson)
Subject: Re: Windows CoreWar?
Message-ID: <1992Mar15.005404.19441@crash.cts.com>
Date: 15 Mar 92 00:54:04 GMT

In <1992Mar12.042823.1@acad2.alaska.edu> asdyp@acad2.alaska.edu writes:

>In article <Mar.9.10.12.34.1992.19317@utopia.rutgers.edu>, tkimball@utopia.rutgers.edu (Timothy Kimball) writes:
>> 
>> 	Where is the Microsoft Windows version of CoreWars?  I
>> remember reading a post sometime ago about it.  Please email me.
>> 
>> 		Thanks,
>> 
>> 	T. S. Kimball   --   just a new netter

>Windows Corewar?? Eh?? I just crawled out of the sludge, so please enlighten
>me.  Where can I get this Windows Corewar, or is this just something to tease
>me for a while?

     I, too, would VERY much like to know where this can be obtained!

						mwilson@crash.CTS.COM


From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Re: Windows CoreWar?
Message-ID: <1992Mar15.050641.25730@vuse.vanderbilt.edu>
Date: Sun, 15 Mar 1992 05:06:41 GMT

In article <1992Mar15.005404.19441@crash.cts.com> mwilson@crash.cts.com (Marc Wilson) writes:
>In <1992Mar12.042823.1@acad2.alaska.edu> asdyp@acad2.alaska.edu writes:
>
>>In article <Mar.9.10.12.34.1992.19317@utopia.rutgers.edu>, tkimball@utopia.rutgers.edu (Timothy Kimball) writes:
>>> 
>>> 	Where is the Microsoft Windows version of CoreWars?  I
>>> remember reading a post sometime ago about it.  Please email me.
>>> 
>>> 		Thanks,
>>> 
>>> 	T. S. Kimball   --   just a new netter
>
>>Windows Corewar?? Eh?? I just crawled out of the sludge, so please enlighten
>>me.  Where can I get this Windows Corewar, or is this just something to tease
>>me for a while?
>
>     I, too, would VERY much like to know where this can be obtained!
>
>						mwilson@crash.CTS.COM


Sorry to disappoint you, folks. There is no "Core Wars for Windows" (yet).
The "previous post" that T. S. Kimball is referring to is in all likelyhood
my announcement of the DOS-version of KotH corewar, which I said I *tested*
under Windows.

-Stefan (stst@vuse.vanderbilt.edu)


Subject:    new opcode
From: <ASMQK@ASUACAD.BITNET>
Date: Monday, 16 Mar 1992 11:43:47 MST
Message-ID: <92076.114347ASMQK@ASUACAD.BITNET>

What do think of a new pseudo opcode to put dat #0 , #0  n times in
the warrior? For example
stop    jmp 0 , <-2
        spc 80
start   spl stop
        mov 0 , 1

would be

stop    jmp 0 , <-2
        dat #0 , #0       ; # 1
.
.
        dat #0 , #0       ; # 80
start   spl stop
        mov 0 , 1

Nandor.    asmqk@asuacad.bitnet


From: dvljrt@cs.umu.se (Joakim Rosqvist)
Subject: Re: 28dwarf.red
Message-ID: <1992Mar16.154831.28101@cs.umu.se>
Date: Mon, 16 Mar 1992 15:48:31 GMT

In article <55700@cup.portal.com> Vision@cup.portal.com (Vision - Tester) writes:
>Here's a VERY simple little program for some Corewar newbies who want a
>step by step explanation, and a nice little warrior to practice against.
>He is ICWS '88 compatable(so run it on Nandor's GREAT mars88 program!)
>
>-----BEGIN------CUT---HERE----------------------------------------------------
>add #28,2     ;add the number 28 to the B field of 2 ahead
>mov 2,@1      ;move the address(ie copy) 2 ahead at the number in the B field 1
>jmp -2,#3201  ;ahead.  Jmp to add instruction.  # is like a DAT in the b field
>dat #0,#0     ;This is the guy that gets placed in memory, he is very nasty
>	      ;when executed, ie, he kills the other code.
>	      ;This program will not kill itself, for it bombs every 4, and is
>	      ;only 3 long(it doesnt matter if it bombs it's own dat #0,#0
>	      ;it's not very efficent, but it gets the job done.
>------END-------CUT---HERE----------------------------------------------------

I'm a bit new to this, can someone explain why 28 is added above, shouldn't
it be 4 if every 4th instruction was to be stomped?
And from where comes the number 3201??

/Joakim Rosqvist     ($DR.HEX$)   Email to: dvljrt@cs.umu.se
----------------------------------
Hi! I am a .signature virus. Copy me into your .signature to join in!


From: tkimball@busboys.rutgers.edu (Timothy Kimball)
Subject: Re: Windows CoreWar?
Message-ID: <Mar.16.12.38.54.1992.8317@busboys.rutgers.edu>
Date: 16 Mar 92 17:39:01 GMT

In article <1992Mar15.050641.25730@vuse.vanderbilt.edu>, stst@vuse.vanderbilt.edu (Stefan Strack) writes:
> >>In article <Mar.9.10.12.34.1992.19317@utopia.rutgers.edu>, tkimball@utopia.rutgers.edu (Timothy Kimball) writes:
> >>> 
> >>> 	Where is the Microsoft Windows version of CoreWars?
> 
> Sorry to disappoint you, folks. There is no "Core Wars for Windows" (yet).
> The "previous post" that T. S. Kimball is referring to is in all likelyhood
> my announcement of the DOS-version of KotH corewar, which I said I *tested*
> under Windows.
> 
> -Stefan (stst@vuse.vanderbilt.edu)

	Sorry -- I guess I misread :-).  Since the subject has been
brought up, though, I would be interested in trying to make a Windows
CoreWar.  The program is likely to be made in Turbo Pascal /w Object
Windows (Pascal is all I know), so suggestions, source code of
Dos-corewar programs, hints, etc. would be appreciated (sp?) by
e-mail.

			Thanks,
		     T. S. Kimball

--Still a new netter, still no .sig, and still not very good in grammar.--


From: mph@pssparc2.oc.com (Mike Hare)
Subject: Re: Windows CoreWar?
Date: 16 Mar 92 21:57:10 GMT
Message-ID: <mph.700783030@pssparc2>


Where can I get a copy of CoreWars for ms-dos???  Or (gag) MS Windows 3.0??


Tanx,

Mike


---
 no .sig file
---


Subject: Re: new opcode
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Date: Tue, 17 Mar 1992 03:16:11 GMT
Message-ID: <167AC12B20.DURHAM@ricevm1.rice.edu>

In article <92076.114347ASMQK@ASUACAD.BITNET>
ASMQK@ASUACAD.BITNET writes:
>What do think of a new pseudo opcode to put dat #0 , #0  n times in
>the warrior?
>        spc 80

I think the application of inserting multiple copies of "DAT #0, #0" is
too limited to warrant a new pseudo-op dedicated to the purpose.  I more
general pair of pseudo-ops for the repetition of blocks of code or a
multi-line macro facility would be more appropriate.

I must comment on the use of such simple devices as inserting "DAT #0, #0"
blocks of code into one's programs to facilitate scatter loading.
I truly believe that the advantage gained over a similar smaller program
which copies the appropriate instructions ahead in memory is minimal.  Your
time is much better spent working on a better strategy.

Mark A. Durham
MAD


From: gibsonm@milton.u.washington.edu (Michael Gibson)
Subject: Looking for C source for corewars for a school project..
Message-ID: <1992Mar17.110133.8822@u.washington.edu>
Date: Tue, 17 Mar 1992 11:01:33 GMT


Hi. I'm looking for some C source code for an implementation of Corewars
on an ibm 386 computer. The deal is, my teacher is looking for it because he
might want to use it for some of our class next quarter ( it would be
pretty cool to use corewars for school)  So if anybody knows where C source
can be found, or where to register for it or any way to get some C source,
please e-mail me. Thanks.                

                  Michael                 gibsonm@milton.u.washington.edu


  p.s. We use Borland C++ 2.0 if that makes any difference..


Subject: Re: new opcode
From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser)
Date: 17 Mar 92 14:48:49 GMT
Message-ID: <1992Mar17.144849.22822@dcs.glasgow.ac.uk>

In article <167AC12B20.DURHAM@ricevm1.rice.edu>, DURHAM@ricevm1.rice.edu (Mark A. Durham) writes:
> 
> I must comment on the use of such simple devices as inserting "DAT #0, #0"
> blocks of code into one's programs to facilitate scatter loading...

Given the 64 line limit of a corewar program(*), it CAN BE very expensive to
copy/ move chunks of code throughout memory, with respect to line usage. Also
copying instructions elsewhere results in a bigger target for scanning programs,
- USUALLY not desirable.

The advantage gained from "scatter loading" as opposed to programs which build
themseleves can be great. I have programs to prove it.

* in tournaments run by MAD.

Campbell

-- 
| fraserc@dcs.glasgow.ac.uk                                  |
+------------------------------------------------------------+
| Mail   : Campbell Fraser, Department of Computing Science, |
|          The University, Glasgow G12 8QQ, Scotland, UK.    |


Subject: Re: new opcode
From: sbeitzel@wet.UUCP (Stephen Beitzel)
Date: 17 Mar 92 15:03:24 GMT
Message-ID: <3644@wet.UUCP>

In article <92076.114347ASMQK@ASUACAD.BITNET> ASMQK@ASUACAD.BITNET writes:
>        spc 80

Well, the question arises, can't you do that manually with whatever text
editor you're using?

Aside from that, you're going to have to get a new MARS (everybody would)
when the standard changes.  Right now it's tough enough to get them all to
agree on things that are explicitly defined in the standard let alone
getting them to agree to convention.  What do you suppose the odds are on
getting people to agree on loader/compiler syntax?

Really, I'd have to say that putting everybody through the hell of trying to
acquire compatible MARSs for all the various platforms is not the solution
to this particular problem.  Rather, I suggest you look into getting a text
editor that allows you to cut and paste blocks.

Steve
-- 
"I claim responsibility for all opinions in this message, particularly the
offensive ones, and especially if they aren't mine."
--------------------------------------------------------------------------
Stephen Beitzel  -- wet!sbeitzel

Date: Tuesday, 17 Mar 1992 15:08:25 MST
From: <ASMQK@ASUACAD.BITNET>
Message-ID: <92077.150825ASMQK@ASUACAD.BITNET>
Subject: Re: new opcode

Yes I can do it by hand, but it isn't so easy with my editor so I do it
one by one. I think everybody can agree that it would be nice to have a
kind of macro processor in the next standard.
The other thing is that it takes more space on the disk and if I print it
out I see only uninteresting dat #0 , #0 .

Nandor.


Subject: Weekly (?) KotH update
From: wms@iwarp.intel.com (William Shubert)
Date: 17 Mar 92 16:44:24 GMT
Message-ID: <1992Mar17.164424.17545@iWarp.intel.com>

Well so it's been about a month since I've remembered to post a weekly KotH
update...better late than never.

Here's the standard hill:
  W/  L/  T                                     Name   Score     Age
219/110/111                return of the living dead     768       6
248/175/ 17                              scissors3.1     761      55
226/177/ 37                                    Droid     715       2
201/132/107                             Shwing! v1.7     710      16
218/200/ 22                                SplitBomb     676      22
170/198/ 72                         Double Pesticide     582      47
178/217/ 45                                shark 1.0     579       1
168/204/ 68                              Pesticide-x     572      55
128/158/154                             Shwing! v2.0     538       9
161/242/ 37                            Fast Bomb V77     520       4

"return of the living dead" has arrived (fairly) recently to take the #1 spot.
The strategy is kinda vague, but if you know what Nandor Sieben means by a
"living dead" you should know what he's talking about:
;author nandor sieben
;strategy  more better living deads


In the experimental hill, things are moving arounds as much as always.
"ramscoop -x", which was #1 for a long time, has finally been pushed off.
 W/  L/  T                                     Name   Score     Age
225/ 63/152                             Shwing! v1.7     827       6
199/175/ 66                              Spread v3.0     663      16
189/155/ 96                         Double Pesticide     663      26
112/ 15/313                              As If! v0.0     649      19
162/118/160             return of the living dead -x     646       2
165/146/129                                Lemma 1.1     624      17
171/180/ 89                              Pesticide-x     602      20
177/233/ 30                               Mantis 1.1     561       3
112/112/216      Snow White and the Seven Dwarfs 1.2     552      10
159/216/ 65                           killer worm -x     542       1

Shwing! v1.7, which is on both hills, is #1 here; here's the ;strategy:
;author T. H. Davies
;strategy  clone like mice, bomb like dwarf
;strategy  1.7  updated bomb routine 
;strategy  Submitted: Tue Mar 10 11:20:43 PST 1992

Several people have suggested changing the experimental hill; I tend to agree
now.  It's been running for a while, and while it definitely tends to attract
a different kind of program than the ICWS '88 hill, I'm not sure that it's any
more interesting.

   For entry directions or source code for the unix/X-windows corewar program
used in the KotH tournament, send me mail.
				-Bill (wms@iwarp.intel.com)


From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Subject: Re: new opcode
Message-ID: <167AD10513.DURHAM@ricevm1.rice.edu>
Date: Wed, 18 Mar 1992 00:33:37 GMT

In article <1992Mar17.144849.22822@dcs.glasgow.ac.uk>
fraserc@dcs.glasgow.ac.uk (Campbell Fraser) writes:
>Given the 64 line limit of a corewar program(*), it CAN BE very expensive to
>copy/ move chunks of code throughout memory, with respect to line usage. Also
>copying instructions elsewhere results in a bigger target for scanning programs
>- USUALLY not desirable.
>
>The advantage gained from "scatter loading" as opposed to programs which build
>themseleves can be great. I have programs to prove it.
>
>* in tournaments run by MAD.
>
>Campbell

I'm addressing Stephen Beitzel's reply as well, but only tangentially, so
I have not quoted it here.

The idea as originally presented was a "pseudo-opcode" for multiple
instructions.  I know many people use systems which do not explicitly use
a Redcode assembler as a seperate pass (i.e. one that writes an object file
as input for the MARS), but the distinction between pseudo-opcode and
opcode remains.  A line of Redcode with an opcode produces one instruction
of object code when assembled.  A line of Redcode with a pseudo-opcode
produces no object code under the current standards.

The inclusion of a multiple-instruction pseudo-opcode (SPC was the example)
is an entirely different beast altogether -- a macro.  I agree that a
standard macro capability (more generalized than the SPC example) would be
a fine addition to Core War.  The addition is to the Redcode assembler
however, not to the MARS (Memory Array Redcode Simulator) which interprets
assembled Redcode (no labels, negative offsets, EQUates, etc.).

Here is the rub though.  The 64 instruction limit mentioned above is not
a limit on the number of lines of Redcode you can assemble.  Indeed, you
can write as many EQUates and comment lines as you like.  END does not
count either.  What counts is the number of instructions loaded into MARS.

And SPC (or whatever) does not obviate that limit.  If you insert
   SPC 80
in your Redcode program, the Redcode assembler is going to generate 80
DAT #0, #0 instructions and you will have exceeded the limit.  The
destinction between a "useful" instruction and a placeholder is not one
I (for one) care to build into the standards.  A simpler solution is to
support scatter loading with an ORiGin pseudo-opcode.

start ??? A, B
      ...
      ORG OFFSET1
off1  ??? A, B
      ...
      ORG OFFSET2
off2  ??? A, B
      ...

where OFFSET1 and OFFSET2 are both absolute numbers of instructions to skip
before starting to load the following code.

I WANT TO STATE EMPHATICALLY THAT I AM DEFINITELY NOT IN FAVOR OF SCATTER
LOADING!!!!!!!  I am just pointing out a better way to do it.  Scatter loading
affords programs too much power without exacting any price.  If it were
included in a standard, everyone would use it (they would have to) and that
would nullify the advantage people for which people are striving.  And so
far I have completely avoided mentioning the problem of assuring that one
program does not load on top of another.  This would be especially difficult
for those simulators which support more than two warriors.

Does it really cost that much to copy code to a new location?  Not if the
appropriate initializations have been made and you give it a little thought.
You only need three instructions (only one if you have two free B-fields
elsewhere in your program).  The one that does all the work is
   DJN <from, <to
Since the code is looped only once (if you only make one copy), it does not
matter if your opponent overwrites it once you have made the copy.  The only
terrible disadvantage is if the increased span of your program enables your
opponent to find you when otherwise she would not have done so -- not very
likely.

So there definitely is an advantage to scatter loading, it is just that
the advantage is somewhat proportional to the amount of scatter.  And the
advantage is definitely uninteresting.  I am sticking to my statement about
time being better spent working on a better strategy.

Lastly, a note about the current Valentine tournament.  There is no preset
limit on the number of instructions for submissions to that tournament.  I
will return submissions that take unfair advantage of that fact however.  My
Core War system may not be able to make the distinction between useful
instructions and placeholders, but I certainly can and I try to pay careful
attention to the submissions -- mostly to make sure people's programs are
doing what they say they are supposed to do, not to police the game.

The 64 instruction limit was imposed on the ICWS tournaments of the last
few years, and the only time I imposed that limit was on the EBS preliminary
tournament since the top ten finishers were to go on to the ICWS annual
tournament.

Mark A. Durham
MAD


From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Subject: Should I shut up?
Message-ID: <167AD1120A.DURHAM@ricevm1.rice.edu>
Date: Wed, 18 Mar 1992 01:29:14 GMT

Here is my question:  Should I shut up?  I really do not mean to stifle
creativity and discussion, but it seems to me that I might be unintentionally
intimidating some of you out there.  After all, I have an eight-year start
on many of you.  There is very little "new" to me in Core War.

You can take some solace in the fact that I am not very good at writing
successful Redcode warriors - as KotH participants can attest.  I have
discovered (along with many other people) and discussed and popularized
and taught many of the Redcode "tricks" of successful warriors, but alas
have not spent the necessary time to develop a real world-beater.  No doubt,
I spend too much time hogging the net instead of writing warriors.

So here is your opportunity to tell me to be quiet.  Go ahead an let me
have it.  I suggest you use Email, but I can take it if you want to post
to the net.  I will restrain from replying to the net, and I encourage no
one to respond on my behalf.

The MAD FAQs will keep coming once a month though, no matter what kind of
mail I receive.  Thanks for putting up with even more of my babble in
this message.

Mark A. Durham
MAD


From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Subject: Re: new opcode (errata)
Message-ID: <167AD118A3.DURHAM@ricevm1.rice.edu>
Date: Wed, 18 Mar 1992 01:57:17 GMT

>                              The addition is to the Redcode assembler
>however, not to the MARS (Memory Array Redcode Simulator) which interprets
>assembled Redcode (no labels, negative offsets, EQUates, etc.).
>
I hope you do not mind my having left out a discussion of the loader which
takes care of normalizing operands.  It is sometimes in the assembler
(when the assembler knows the core size) and sometimes in the MARS (for
when the assembler does not know the core size).
>destinction
 distinction
>You only need three instructions (only one if you have two free B-fields
>elsewhere in your program).  The one that does all the work is
>   DJN <from, <to
Good grief.  I need some sleep.  Four instructions (two if two free B-fields).
The loop is
 loop MOV <from, to
      DJN loop, <to

I missed a couple of earlier typos.  Duplicated words, I for A, etc.
Forgive me.  I'm going home to take a nap.
MAD


Date: Wednesday, 18 Mar 1992 11:22:15 EST
From: <JJJ101@psuvm.psu.edu>
Message-ID: <92078.112215JJJ101@psuvm.psu.edu>
Subject: Re: Should I shut up?

Keep talking!!


From: wag@georwell.EBay.Sun.COM (Rick Wagoner)
Subject: Core War revs
Message-ID: <q81inINN9nv@grapevine.EBay.Sun.COM>
Date: 18 Mar 92 18:19:03 GMT

As a relative newcomer to the Corewar world I would like to know what are
the latest revs of Corewars and its tools exist for the IBM PC. Also where
might these files be found?

I have FTP capability so getting the files is not a problem.

Was there/is there a FAQ?

Thanks,

Rick


---
+-----------------------------------------------+
+ Rick Wagoner					+
+ Sun Microsystems Education Dept.		+
+ 408-276-5658					+
+ 						+
+ email rick.wagoner@Ebay 			+
+ or	rwagoner@sun.com			+
+						+
+ or whateverthehell the DNS server mangles my	+
+    address into!				+
+						+
+-----------------------------------------------+
+ Opinions: MINE!	Systems: Theirs!	+
+-----------------------------------------------+
+  Everybody likes to stir the excrement        +
+  but nobody likes to clean the paddle...	+
+-----------------------------------------------+


From: jlb0170@zeus.tamu.edu (BAY, JEFFREY LOYD)
Subject: Re: Core War revs
Message-ID: <19MAR199219595911@zeus.tamu.edu>
Date: 20 Mar 92 00:59:00 GMT

In article <q81inINN9nv@grapevine.EBay.Sun.COM>, wag@georwell.EBay.Sun.COM writes...
>As a relative newcomer to the Corewar world I would like to know what are
>the latest revs of Corewars and its tools exist for the IBM PC. Also where
>might these files be found?
> 
>I have FTP capability so getting the files is not a problem.
> 
>Was there/is there a FAQ?
[long sig and signature deleted in the interest of saving bandwidth]

I swore, after reading Rec.Games.Hack for quite a while, that I would never
jump on the bandwagon for a spoiler file there... or anywhere... or
to ask somebody how to get a hold of a game... but if this game will
run on a PC compatible 386-16 under MS-DOS, I would like a copy, and
therefore, am going against my principles because I just know everyone
is going to reply to this person through mail.

Please post, or possibly mail me, the FAQ and the location for these
binaries(if they exist).

I have little experience in MAKEing huge files, so I'm screwed if no
binaries exist, and if not, don't bother.

Messiah
Jeff Bay


From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Subject: ICWS '89/'90 Tournament Code
Message-ID: <167AF10BE4.DURHAM@ricevm1.rice.edu>
Date: Fri, 20 Mar 1992 01:03:00 GMT

Under the "Better Late Than Never" catagory:

The Redcode submissions to the 1989 and 1990 ICWS tournaments are
now available on soda.berkeley.edu.


From: ajpierce@med.unc.edu (Andrew Pierce)
Subject: Droid
Message-ID: <1992Mar20.193711.20546@samba.oit.unc.edu>
Date: 20 Mar 92 19:37:11 GMT


   Here is the code to "Droid".  This prog has survived 11 successful KotH
challenges so far and is still on the hill.  It wanders around from 5th to
7th or so.  Actually, I quite like this one.  It is a cmp scanner which
bombs with spl instructions.  It seems to be particularly effective against
multi-process programs.  If you have an amiga and use Mark Durham's MADgic
core 4.0, it sounds pretty impressive too.  There is the soft whine of the
search engine, then the staccato machine gun bombing sound and the final 
sound of a tank rolling over crushed enemy programs. :-)  Enjoy.
     -Andy
ajpierce@med.unc.edu

;redcode verbose
;name Droid
;author Andy Pierce (ajpierce@med.unc.edu)

start	cmp <a,<b
	spl b,0
	djn start,b
	mov -5,<0
slow	spl 0,0
stop	jmp -2,0
b	mov slow,5328
a	mov slow,-8


From: charbocj@watt.ccs.tuns.ca
Subject: Help! Need fighter!
Message-ID: <1992Mar20.211549.1@watt.ccs.tuns.ca>
Date: 21 Mar 92 01:15:49 GMT

Help!!!

	I am involved with a couple of others on a core-wars project
	usind REDCODE.

	We have ben trying to come up with a reasonbly successful fighter,
but have had little or no luck.

	If anyone can help in any way (like mybe an algorithm for good
steps to follow or an old fighter you maybe have discarded)
it would be greatly appreciated!!!

	*Please* *Please* *Please* don't respond to this with a general
newsgroup posting! We are in competition with other groups, so a general
posting would defeat the purpose.

	Thanx in advance.

	C.J.

			charbocj@newton.ccs.tuns.ca
			Technical University of Nova Scotia


From: Corey_Lynn_Nelson@cup.portal.com
Subject: Re: new opcode
Message-ID: <56162@cup.portal.com>
Date: 21 Mar 92 06:39:46 GMT


    O.K. one more time.  I am in favor of modifying the current 
standard so that the SKP (skip) instruction is added.  (The 
psuedo-op SPC should be avoid to prevent confusion with the space 
psuedo-op, which generates N spaces in the listing.)  I assume 
that SKP will NOT allow a program to scatter load, and is 
functionally the same as N words of what ever core is 
initialized to.  I like skip because: 
1.) It reduces the size of a LISTING.  I do not want to read 40 
DAT #0 instructions, when 1 SKP would suffice!
2.) It increases the clarity of a LISTING.  I have difficulty 
counting over three, so any help counting is appreciated!
3.) It adds a capability currently lacking in Corewars!  It is not 
possible (currently) to write a program which contains the word 
which core is initialized to!  Please note that this value 
has changed with time, it could change again!
-----
A tie is better than a loss, or half a loaf is better than no bread.
-----


From: Corey_Lynn_Nelson@cup.portal.com
Subject: Re: Should I shut up?
Message-ID: <56163@cup.portal.com>
Date: 21 Mar 92 06:45:02 GMT

Please keep talking, if it weren't for you, I feel like an audience of one.
You were not the only one to reply to my proposed mods, just the only one to 
do so Publicly.  I wish more people would stand up and say what they think,
not less!


From: blojo@soda.berkeley.edu (Jon Blow)
Subject: Core War materiel
Message-ID: <asdgh23408haw8hgwoegh@soda>
Date: 22 Mar 92 05:09:06 GMT

Many many things have been posted requesting information on where to get
Core War stuff, so here goes...

The he ftp site soda.berkeley.edu (128.32.150.124) has all sorts of useful
things in it, including (but not limited to):

* A constantly updated digest of this newsgroup, rec.games.corewar.  The
  digest is complete, ranging all the way back to this group's creation
  last year.

* ICWS annual competition entries from 1986-1990.

* Documents describing the various Core War standards and implementation
  hints.

* Core War MARS simulator binaries and/or source code for:

        + Unix
        + IBM personal computers
        + Amigas
        + Macintoshes

If you have *any* core-war related material you think is interesting and
that the world in general might want to get, you may upload it to the
directory soda.berkeley.edu:/pub/corewar/incoming.


    -Jon
     Archive Maintainer Guy


Subject: age top
Message-ID: <92084.130346ASMQK@ASUACAD.BITNET>
From: <ASMQK@ASUACAD.BITNET>
Date: Tuesday, 24 Mar 1992 13:03:46 MST

max age

scissors 3.1              78 alive
double pesticide          74
pesticide-x               68
shark 1.0                 34

return of the living dead 29 coming

These are the warriors of age 30 or more. If you have a warrior not on the
list please send the name and the age to me (asmqk@asuacad.bitnet).
I'm doing it by hand so there could be some mistakes.
Nandor.


From: Scott.Maxwell@bbs.oit.unc.edu (Scott Maxwell)
Subject: A utility for MADgic Core -- doc file
Message-ID: <1992Mar24.211247.18906@samba.oit.unc.edu>
Date: 24 Mar 92 21:12:47 GMT


	Here's the doc file for Points, a program for use with Mark Durham's
MADgic Core 4.0. The .LHA'ed and uuencoded executable will be posted in a 
separate message.

----- begin doc file -----
       "Points" -- a public domain ditty by Scott Maxwell
       23 March 1992



       "Points" is a little program designed for use with Mark Durham's
excellent Amiga Core War game, "MADgic Core 4.0." MADgic Core's associated 
tournament manager program produces its output in terms of how many 
battles a core warrior won, lost, or tied. While this information is 
useful, I wanted to be able to come up with a single number for comparing 
the programs. And so ... Points was born!

       To use Points, first redirect the tournament manager's output to a 
file. E.g., type

               TMARS >outfile tournament_file.tm

       Invoke Points on the output file by typing

               Points outfile

       You may redirect Points's output to a file, if you like.

       By default, Points assigns 3 points for a win, 1 for a tie, and 0 
for a loss (I understand those values are fairly standard). However, you
may choose different "weights," including non-integer values. See the usage
text (by typing "Points" with no arguments) for more details.

       I release Points into the public domain with the following caveat: 
I hacked it together in a couple of hours, so don't expect it to be 
pretty. Also, I'm *not* responsible for bugs or anything else that might 
come of your choosing to use this program, including but not limited to
fires, locust plagues, and the heat death of the universe.

       If you use Points, I'd appreciate your dropping me a note at 
CSMAXWEL@ECUVM1.BITNET or Scott.Maxwell@bbs.oit.unc.edu. Pretend you like 
it.

       The source is included (I used SAS/C 5.10b, but I imagine it's 
highly portable). I don't know why the executable is so fat; 
floating-point math, I guess.

       Enjoy.

                               -- Scott Maxwell

----- end doc file -----

Scott Maxwell (CSMAXWEL@ECUVM1.BITNET or Scott.Maxwell@bbs.oit.unc.edu)

--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80


From: ajpierce@med.unc.edu (Andrew Pierce)
Subject: Small 2
Message-ID: <1992Mar26.050719.7531@samba.oit.unc.edu>
Date: 26 Mar 92 05:07:19 GMT


   My program "Small 2" has survived 10 successful challenges on KotH.  It
seems to hover between 5th and 3rd, although it did (very briefly) make it
to number 1.  Here is the source.

;redcode verbose
;name Small 2
;author Andy Pierce  (ajpierce@med.unc.edu)
;strategy small bomber/clearer
;strategy v2:  fix kill routine

start	add #15,1
	mov hit,1
	jmp start,0
hit	spl 0,0
	mov -6,<-6
	jmp -1,0

	end start


From: Vision@cup.portal.com (Vision - Tester)
Subject: Auto
Message-ID: <56425@cup.portal.com>
Date: 26 Mar 92 07:22:15 GMT

Hello fellow corewarriors!  I've just written an interesting, but not very
effective program(in corewarrior terms, it sux) and I'm posting it to the net
so you can run your favorite corewar simulator to beat it's coded ass.  It's
a pretty simple, easy to understand program that will maybe help some of the
corewar newbie programers come up with their first effective programs.  It's
a dwarf bomb routine, with a copy and jump routine.  It's VERY effective
against programs that just bomb in very small increments, because it just
jumps over the bombing code.
;name Auto v1.0
;author Peter Olcott
;strategy  Dumb jumping bomber, not very effective, but fun to beat
jmp start
len   dat #0,#14
start mov #13,len    ;reset sequence
      mov #131,cyc
      mov #1001,b1
go    add #7,b1      ;bomb sequence
      mov ddt,@b1
      djn go,cyc
copy  mov <len,<b1   ;copy sequence
      jmn copy,len
      jmp 1909,#0    ;jumpes to new code location, this was manually fine
ddt   dat #0,#0      ;tuned for all my fancy algorithms failed miserably.
cyc   dat #0,#131
b1    dat #0,#1001

P.S.  It's very pleasing to watch, and fun to sting, bite, whatever to it ;)


From: Vision@cup.portal.com (Vision - Tester)
Subject: Roll
Message-ID: <56502@cup.portal.com>
Date: 28 Mar 92 05:59:48 GMT


  Well, since the most exciting thing to do with corewars is to have as many
fun programs as possible to run yours against, here's another simple corewar
program which is very similar to small2.  I have never run it on KoTH because
I have better programs than it.  It uses a mov a,<b djn c,b which provides a
faster memory coverage than a mov a,<b jmn c,b one.  (ie covers 2 spaces per
2 cycles instead of 1)
;name Roll v1.0
;author Peter Olcott
;strategy  Simple spl backwards, then bomb backwords when memory is covered.
;strategy  This program does not kill itself when it starts to clear memory
START
mov 5,<5	;mov the spl 0 at the decremented pointer at the spl 0.
djn -1,4	;decrement and jump if not zero  -- double decrementation.
mov 2,3		;this part resets the code, substituting in dat #0's.
jmp -3,#0	;jmp back and reset using the dat #0's.
dat #0,#-5	;has to be -5, otherwise code will kill itself.
spl 0,#-5	;this is the sting code.
END

Well, I hope you like my creation, it's good to use to decide whether one
current creations has any future ;)
			--pete


From: fau@po.CWRU.Edu (Francis A. Uy)
Subject: Q: Initial Separation...
Message-ID: <1992Mar28.194154.5394@usenet.ins.cwru.edu>
Date: 28 Mar 92 19:41:54 GMT


One thing I've never seen in any documentation
 is "How is the initial distance between the two
 programs determined?"  In the standard 8192 
 core, what is the minimum separation?  The
 average?  Etc?

Obviously, these answers have great impact on
 program design.  Please respond.
-- 
Francis A. Uy
fau@po.cwru.edu
cs201329@umbc5.umbc.edu


Subject: Corewar Archives on Soda
Message-ID: <56523@cup.portal.com>
From: Ordania-DM@cup.portal.com (Charles K Hughes)
Date: 28 Mar 92 20:42:35 GMT


  I downloaded RedcodeFromSpain.Arj from the archives and found it about 60k
short.  Anyone have a good copy and does anyone know how to get it removed
or fixed?


  Thanks
Charles_K_Hughes@cup.portal.com


From: gapdrr@gsusgi2.gsu.edu (Daniel R T Rothman)
Subject: FAQ list?
Message-ID: <gapdrr.701823183@gsusgi2.gsu.edu>
Date: 28 Mar 92 22:53:03 GMT

i'm looking for the FAQ list for this group, and can't seem to find one.
Specifically: where is there a RedCode spec? and what's the latest/currently
    most used version? anonymous FTP sites? is there any source for CoreWars
    back ends (ie, interpreters, with source, with/without a front end...) esp
    for unix and in C?

thanks folks, i'll be scanning for a list....


daniel rothman                        | gapdrr@gsusgi2.gsu.edu  Internet
computer specialist - GAP             | gapdrr%gsusgi2@gsuvm1   Bitnet
 - - funny quote thingy - - 


From: fau@po.CWRU.Edu (Francis A. Uy)
Subject: Q: wondering about ICWS stats...
Message-ID: <1992Mar29.022110.18385@usenet.ins.cwru.edu>
Date: 29 Mar 92 02:21:10 GMT


I have copies of the programs from the ICWS
 tournaments '87 - '90, but I don't know 
 how well they did.

I'm about to get timed out.  Please respond..
-- 
Francis A. Uy
fau@po.cwru.edu
cs201329@umbc5.umbc.edu


From: fau@po.CWRU.Edu (Francis A. Uy)
Subject: modified '90 warrior, (was Re: Help! Need fighter!)
Message-ID: <1992Mar29.025522.19023@usenet.ins.cwru.edu>
Date: Sun, 29 Mar 92 02:55:22 GMT


In a previous article, charbocj@watt.ccs.tuns.ca () says:

>	We have ben trying to come up with a reasonbly successful fighter,
>but have had little or no luck.
>
>	*Please* *Please* *Please* don't respond to this with a general
>newsgroup posting! We are in competition with other groups, so a general
>posting would defeat the purpose.

Oh, sorry, I'll just post it here anyways.

I just picked up the programs from ICWS 90, and was
 playing with them.  "CatCan" caught my eye for some
 reason -- it's a fairly simple minded piece, but not
 ineffective.  Plenty of room for improvement, I
 discovered.  The original fired pairs of
        SPL 0, 0       JMP -1, 0
 at eight address intervals, then erased the core
 with   DAT 0, 0.

By changing the initial bombs to
        SPL 0, x       JMP -1, x   (x not equal to zero)
 and pushing the initial fire address up by 1024,
 suddenly this creature has an even chance at 
 beating XTC (which I've heard was the winner,
 is that correct?).

;    Warrior: Cat Can
;   Standard: CWS'88
;     Author: A. Kirchner
;
;    Remixor: F. Uy
;
start     mov       trap2   < bomb
          mov       trap1   < bomb
          sub     # 6         bomb
          jmn       start     bomb ; trap loop
set       mov     # -12       bomb
kill      mov       bomb    @ bomb
          djn       kill      bomb ; kill loop
reset     jmp       set       0
          jmp       set       0
          dat       0         0    ; buffer
bomb      dat       0         -1024
trap1     spl       0         2
trap2     jmp       -1        1
          end       start
;
; Your basic two sweep methodical bomber.
; Fires SPL 0 and JMP -1 at every eight
; addresses, then erases the core with
; DAT bombs.

Also, I have yet another question.  When writing
 a "bomber" program -- i.e. indiscriminately fires
 bombs without checking to see what it hits --
 are there any circumstances where a zero B field
 is better than nonzero?  By setting the B field
 nonzero, you can trick "hunter" programs into
 firing at your otherwise wasted bombs, thereby
 gaining a little extra time to hit them before
 they home in on you.  This trick is virtually a
 MUST to beat XTC + similar programs.  

Comments?
-- 
Francis A. Uy
fau@po.cwru.edu
cs201329@umbc5.u�bc.edu


From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Subject: Re: Q: Initial Separation...
Message-ID: <167B9CB76.DURHAM@ricevm1.rice.edu>
Date: Sun, 29 Mar 1992 20:28:01 GMT

Initial separation is up to the person(s) running the tournament/match.

There have never been standards for running tournaments.  Generally,
initial separation is picked at random with the single provision that
programs do not overlap.

Mark A. Durham
MAD


From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Subject: Re: Q: wondering about ICWS stats...
Message-ID: <167B9CCE4.DURHAM@ricevm1.rice.edu>
Date: Sun, 29 Mar 1992 20:34:08 GMT

ICWS Winners:
   1986 - Mice
   1987 - Ferret
   1988 - Cowboy
   1989 - Hypray
   1990 - Paper

   Grand Final - XTC

The results of all the tournaments are at least slightly suspect
due to the peculiarities of the assemblers/MARSs used and the strange
scoring/brackets - with the possible exception of the 1990 and Grand
Final battles.  These are listed below.

1990
Warrior          Wins         Losses        Ties         Score
paper             115           27           10           355
dblstrm2          113           27           10           349
xtc               109           24           17           344
scissors          105           32           13           328
warior42           96           35           19           307
zd                 86           38           26           284
catcan             90           46           14           284
dervish            83           51           16           265
ze                 76           51           23           251
basilisk           76           65            9           237
vlad               69           61           20           227
mrbeef             72           69            9           225
stone              72           75            3           219
c2n863             57           72           21           192
divers             37           39           74           185
leaptoad           52           69           29           185
c10n642            43           69           38           167
dac                38           60           52           166
lightnin           35           72           43           148
trout              46          100            4           142
infester           42           93           15           141
spook              31           82           37           130
jujitsu            19           61           70           127
beamer             34          113            3           105
gato               23          103           24            93
net                 5           92           53            68

Grand Final
Warrior           Wins       Losses         Ties         Score
xtc                65           12           13           208
paper              53           15           22           181
dblstrm2           52           23           15           171
plague             45           21           24           159
sud                44           29           17           149
mice               43           27           20           149
cowboy             44           36           10           142
ferret             37           37           16           127
muledna            27           25           38           119
piper              32           45           13           109
wang1              30           43           17           107
chang1             13           21           56            95
imp                 6           19           65            83
hypray             19           49           22            79
midget             16           43           31            79
pwrbomb             1           82            7            10

For anyone who does not know, the Grand Final was held in 1990 just
after the 1990 tournament and pitted the top three finishers from all
five previous tournaments against each other, plus IMP for good measure.

Mark A. Durham
MAD


From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Subject: EBS
Message-ID: <167B9D904.DURHAM@ricevm1.rice.edu>
Date: Sun, 29 Mar 1992 21:25:55 GMT

In case anyone is wondering about the status of the EBS (Electronic
Branch Section of the ICWS), we are still awaiting the return of our
petition for Branch Section status.  We will set up rules after the
petition is returned.

In the meantime, the status quo holds.  Anyone with access to electronic
mail is considered a member of the EBS.  We will hold a preliminary
tournament November 15th, and the top ten finishers will progress to the
annual ICWS tournament.  There are no fees.

Mark A. Durham
MAD


From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Subject: ICWS'94
Message-ID: <167B9DA97.DURHAM@ricevm1.rice.edu>
Date: Sun, 29 Mar 1992 21:32:39 GMT

I am hoping that the ICWS will be able to release a new standard in
1994 in honor of ten years of Core War.  Toward that end, I would
like to form an ad hoc committee to work on that new standard.  I
would prefer that members of the committee have access to electronic
mail for the next two years, and also that they be members of the
ICWS.  Neither of these preferences are strict requirements however,
and if you are interested in helping out on the committee for a
limited time please feel free to join in.  I expect the committee
to post straw polls about various subjects to the net on occassion
just to get the feel of the public - so even if you do not join the
committee you will have the opportunity for some input.

In the end, the ICWS is the final arbiter of all things Core War.  This
committee will not be forming the actual standard quite so much as
forming the base document of said standard.  The ICWS may make changes
or ignore the document altogether.  The members of the ICWS will vote
on any standards before they become official.

So here is my plea.  If you would like to serve on a powerless ad hoc
committee for the betterment of Core War, then please send me your
name and EMail address and any issues you wish to see addressed
immediately by the committee.

Mark A. Durham
MAD
durham@ricevm1.rice.edu


Subject: Re: Q: Initial Separation...
Message-ID: <56569@cup.portal.com>
From: Corey_Lynn_Nelson@cup.portal.com
Date: 29 Mar 92 21:35:44 GMT

> One thing I've never seen in any documentation
>  is "How is the initial distance between the two
>  programs determined?"  In the standard 8192 
>  core, what is the minimum separation?  The
>  average?  Etc?

    I proposed that the minimum distance between warriors be 
standardized at maximum warrior size.  (MAD disagreed, I have
not heard from anyone else)  There currently is NO standardized 
separation.  A random number is usually chosen with no favoring 
for any distance (i.e. 500 is just a likely as 5000) therefore 
the average distance in a 8192 core is 4096.
---


From: fau@po.CWRU.Edu (Francis A. Uy)
Subject: about C2N863.RED + other fighters in hex...
Message-ID: <1992Mar30.065458.20330@usenet.ins.cwru.edu>
Date: Mon, 30 Mar 92 06:54:58 GMT


My copies of the 1990 fighters c2n863 + c10n642
 appear to be written in hexadecimal or somthing
 similar.  In any case, I can't read them, I can't
 run them.  Could someone post their code in plain
 red?
-- 
Francis A. Uy
fau@po.cwru.edu
cs201329@umbc5.u�bc.edu


From: ajpierce@med.unc.edu (Andrew Pierce)
Subject: KotH diversity
Message-ID: <1992Mar30.131641.21276@samba.oit.unc.edu>
Date: 30 Mar 92 13:16:41 GMT


   Over this past weekend I have been experimenting with the Synch series
of programs on KotH.  While I have been very pleased with their successes,
I have one point of concern that needs to be addressed.  The hill, as we
all know, is small, holding only 10 entries.  As such, when someone
submits an experimental series such as I did with Synch, or Stefan Strack
(?) did with Dynamic Duo, the lower programs on the hill necessarily get
pushed off.  This is not really fair.  As has been discussed extensively
before, certain program types will consistently beat other program types.
Thus, if you have a type of program which just happens to lose to the
experimental series, you will take a lot of losses.  With three
trials on the hill, you will in fact take three times as many losses as
you would have, for no real reason.  It has been established by fighting
the first of the series how well you do against it; fighting the others in
the series then just adds insult to injury.  Likewise the other way -- if
you win against the series, your rating will appear inflated.
   Accordingly, I have asked Bill to remove my programs "Synch 2" and
"Synch 2a" from KotH, which should leave just "Synch 3".  If you have had
a (recently) lower rated program which has been pushed off the hill by
this series, please consider resubmitting (Scissors?).  Similarly if you
submitted what you thought was a worthy entry this weekend which didn't do
as well as you thought due to triplicate losses against the series, please
also consider resubmitting.  I know that this "multiple whammy" effect is
a problem -- my own program Small 2 fell victim to it.  Look for a new
improved Small 3 in the next few days. :-)
     -Andy
ajpierce@med.unc.edu


From: wms@iwarp.intel.com (William Shubert)
Subject: Re: Q: Initial Separation...
Message-ID: <1992Mar30.163036.23132@iWarp.intel.com>
Date: Mon, 30 Mar 1992 16:30:36 GMT

Corey_Lynn_Nelson@cup.portal.com posted:
>> One thing I've never seen in any documentation
>>  is "How is the initial distance between the two
>>  programs determined?"  In the standard 8192 
>>  core, what is the minimum separation?  The
>>  average?  Etc?
>
>    I proposed that the minimum distance between warriors be 
>standardized at maximum warrior size.  (MAD disagreed, I have
>not heard from anyone else)  There currently is NO standardized 
>separation.  A random number is usually chosen with no favoring 
>for any distance (i.e. 500 is just a likely as 5000) therefore 
>the average distance in a 8192 core is 4096.

   In KotH, the seperation is randomly set, but it will be at least the
maximum program size (which is 100 instructions).  So essentially each program
is padded with "DAT 0,0" instructions at the end until it is 100 instructions
long, then they are dropped into the core at random locations which do not
overlap.
   Also, in an 8192 core the MAXIMUM seperation is 4096; the AVERAGE seperation
is 2048.  Don't forget that corewar has a circular addressing system.
				-Bill (wms@iwarp.intel.com)


From: wms@iwarp.intel.com (William Shubert)
Subject: KotH hill update
Message-ID: <1992Mar30.163717.23901@iWarp.intel.com>
Date: Mon, 30 Mar 1992 16:37:17 GMT

Here are the current stats for the ICWS '88 hill:
  W/  L/  T                                     Name   Score     Age
244/104/ 92                                  Synch 3     824       2
243/113/ 84                                  Synch 2     813       9
227/135/ 78                                 Synch 2a     759       3
203/128/109                return of the living dead     718      51
227/201/ 12                          Dynamic Duo 2.0     693      15
221/206/ 13                              Dynamic Duo     676      16
190/210/ 40                            Pesticide 1.2     610      22
146/164/130                                Roll v1.2     568      11
141/159/140                            Get addresses     563       1
144/171/125                          PiedPiperKOTH.1     557      12
Notice that there are three versions of "Synch" on the hill.  Synch 2 and
Synch 2a have been marked for death and will drop of the hill with the next
challenger.  The ";strategy" for Synch 3:
;strategy  cmp scan, spl bomb, clear core
;strategy  v2:  reduce footprint, convert losses to ties, better tactics
;strategy  v2a: convert ties to wins, marginally better strategy
;strategy  v3:  reduce footprint again, more extensive smear routine

Not much action in the experimental hill...I guess it's about time to change
it.  In a week, or maybe two, I plan on releasing a new version of KotH with
added tournament functionality (including a way to remove your own programs
from the hill).  At the same time I'll probably change the experimental rules.
  W/  L/  T                                     Name   Score     Age
196/138/106                         Double Pesticide     694      43
179/116/145               Death by Misadventure v1.0     682      12
209/182/ 49                       Dynamic Duo -x 2.0     676       5
194/175/ 71                          prime directive     653       1
188/191/ 61                       Dynamic Duo -x 2.2     625       2
161/150/129      Snow White and the Seven Dwarfs 1.2     612      27
162/178/100                                csapda -x     586       4
140/134/166                            Acid Rain 1.0     586       3
175/209/ 56                                  Drone-x     581       8
101/ 91/248                          Bow-n-Arrow 2.5     551      14
Double Pesticide has been around for a long time, but it's #1, so here's it's
strategy:
;strategy Bomb mod-4 with JMP 0, then zero core. Double process version.
;strategy Submitted: Wed Mar  4 01:30:29 CST 1992

   If anybody wants instructions for entry into the KotH tournament, or source
code to the Unix/X-windows corewar program used in the tournament, send me
mail.
				-Bill (wms@iwarp.intel.com)


From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Subject: Re: about C2N863.RED + other fighters in hex...
Message-ID: <167BAECFB.DURHAM@ricevm1.rice.edu>
Date: Mon, 30 Mar 1992 22:50:34 GMT

In article <1992Mar30.065458.20330@usenet.ins.cwru.edu>
fau@po.CWRU.Edu (Francis A. Uy) writes:

>My copies of the 1990 fighters c2n863 + c10n642
> appear to be written in hexadecimal or somthing
> similar.

Those fighters are MOB files (for MARS OBject file).  They are
a format created by William R. Buckley for his Core War Colosseum
programs, but supported by some other programs such as Jon Newman's
Core! and THINK Software's CoreMaster (whose manual describes the
format).

The first line is ".MOB".
The next line is the start address (first half) and number of
   Redcode instructions (second half).
The remaining lines are five-byte instructions in the following
   format:

Byte 1                     Byte 2              Byte 3
7 6 5 4   3 2     1 0
 Opcode  A-mode  B-mode    A-operand (high)    A-operand (low)

                           Byte 4              Byte 5
                           B-operand (high)    B-operand (low)

Opcodes:
0 - DAT
1 - MOV
2 - ADD
3 - SUB
4 - JMP
5 - JMZ
6 - JMN
7 - DJN
8 - CMP
9 - SLT (I think)
10- SPL

Modes:
0 - # (Immediate)
1 -   (default or $, Direct)
2 - @ (Indirect)
3 - < (Pre-decrement indirect)

This should allow you to disassemble any MOB files.

Mark A. Durham
MAD


From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Subject: Neophyte questions.
Message-ID: <STEPHEN.92Mar31002540@estragon.uchicago.edu>
Date: Tue, 31 Mar 1992 06:25:32 GMT

Hi, questions from someone who has been playing corewars for, oh,
nearly 48 hours :-).

Apparently important things I couldn't find out by reading what seem
to be the Standard Texts:

	(1) there seems to be no FIXED limit on process count at
present. Is there a guarantee that there is always SOME limit? (This
makes the difference between a spl-loop being a sensible defence
against the obvious (spl 0)-bomb tactic, and it being pretty stupid
compared to just minimising your footprint and being nasty.

	(2) if there IS a limit on process count, *what happens on
spawn failure*? Do you drop through, or do you branch, under the newer
redcode standard?

	(3) am I stupid, or is there no way of transferring a value
from the b operand to the a operand other than a huge comparison tree?
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------


From: bigras@mala.bc.ca
Subject: MSDOS MARS environment FTP site?
Message-ID: <1992Mar31.070851.264@mala.bc.ca>
Date: 31 Mar 92 07:08:51 -0800

Hi
I just came accross this conference.  I had messed around with CW in the
mid 80s and found it quite interesting, unfortunatly at that time I was
not able to find others so interested.  
It looks like the instruction set has grown a bit since then. Is there an
FTP site where I can pick up a MARS and a redcode assembler, as well as some
current sources and docs on the current environment? I would require that this
MARS and assembler be for a MSDOS environment.

Thanks,
Tony Bigras

ok


Subject: Re: Neophyte questions.
Message-ID: <56661@cup.portal.com>
From: Scott_-_Nelson@cup.portal.com
Date: 31 Mar 92 09:39:47 GMT

. . .
> Apparently important things I couldn't find out by reading what seem
> to be the Standard Texts:
> 
>         (1) there seems to be no FIXED limit on process count at
. . .
>         (2) if there IS a limit on process count, *what happens on
> spawn failure*? Do you drop through, or do you branch, under the newer
> redcode standard?
> 
>         (3) am I stupid, or is there no way of transferring a value
> from the b operand to the a operand other than a huge comparison tree?
. . .
 
1.) The limit is up to the group in charge of the tourney, who should
    post it along with all other arbitrary numbers.  For KotH it is 8000.
    but it could be 64 (the ICWS tourney standard in '90) or even 125000
    (effectively no limit)
 
2.) Spawn failure results in drop through.
 
3.) You are not stupid, but there are other (equally unsatisfactory) ways 
    to move the B-field to the A-field.
    here is the smallest one I can think of:
 
         ADD  inc, loc
         djn  -1, loc
    inc	 dat  #1, #0
    loc  dat  #0, #10
 
    several million others are possible, but none are fast.
 
    This sounds like a good idea for a puzzle:
    What's the fastest way to move the B-field of a location to the A-field 
    in 100 words or less.  (assume the A-field is initialized to zero as in
    the above example.)  Post your best time!
 

Date: Tuesday, 31 Mar 1992 10:52:23 MST
From: <ASMQK@ASUACAD.BITNET>
Message-ID: <92091.105224ASMQK@ASUACAD.BITNET>
Subject:    age top

Scissors 3.1              91
Double pesticide          74
Pesticide-x               68
return of the living dead 64    alive
Pesticide 1.2             35    alive
shark 1.0                 34

Dynamic Duo 2.0           28    alive
PiedPiperKOTH.1           25    alive


Nandor   asmqk@asuacad.bitnet


From: scc@rlgvax.Reston.ICL.COM (Stephen Carlson)
Subject: Re: modified '90 warrior, (was Re: Help! Need fighter!)
Message-ID: <1992Mar31.171647.17062@rlgvax.Reston.ICL.COM>
Date: 31 Mar 92 17:16:47 GMT

In article <1992Mar29.025522.19023@usenet.ins.cwru.edu> fau@po.CWRU.Edu (Francis A. Uy) writes:
>By changing the initial bombs to
>        SPL 0, x       JMP -1, x   (x not equal to zero)
> and pushing the initial fire address up by 1024,
> suddenly this creature has an even chance at 
> beating XTC (which I've heard was the winner,
> is that correct?).

I just would to point out that being able to beat XTC does not mean you
have a great warrior.  I have a warrior (B2) that can be XTC about 75%-80%
of the time.  The problem is that it less effective against other kinds of
warriors.

I guess this is due to the non-transitivity of Core War.

-- 
Stephen Carlson           | ICL OFFICEPOWER Center    | In theory, theory and
scc@rlgvax.reston.icl.com | 11490 Commerce Park Drive | practice are the same.
..!uunet!rlgvax!scc       | Reston, VA  22091         |    (703) 648-3300


From: minstrel@next10epsl.wam.umd.edu (Edwin Rots)
Subject: Re: Neophyte questions.
Message-ID: <1992Mar31.183011.6359@wam.umd.edu>
Date: Tue, 31 Mar 1992 18:30:11 GMT

In article <STEPHEN.92Mar31002540@estragon.uchicago.edu>  
stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
> Hi, questions from someone who has been playing corewars for, oh,
> nearly 48 hours :-).
> 
> Apparently important things I couldn't find out by reading what seem
> to be the Standard Texts:
> 
> 	(1) there seems to be no FIXED limit on process count at
> present. Is there a guarantee that there is always SOME limit? (This
> makes the difference between a spl-loop being a sensible defence
> against the obvious (spl 0)-bomb tactic, and it being pretty stupid
> compared to just minimising your footprint and being nasty.
> 
> 	(2) if there IS a limit on process count, *what happens on
> spawn failure*? Do you drop through, or do you branch, under the newer
> redcode standard?
> 
> 	(3) am I stupid, or is there no way of transferring a value
> from the b operand to the a operand other than a huge comparison tree?
> ----------------------------------------------------------------------
> stephen p spackman         Center for Information and Language Studies
> stephen@estragon.uchicago.edu                    University of Chicago
> ----------------------------------------------------------------------
some even more neophyte questions:
What is/are corewars?
I just came across this newsgroup and found it very interesting, but haven't a  
clue as to what the *&^%&$ you all are talking about.  could someone please
email a "assinine green wet-behind-the-ears rookie" FAQ? thanks

Edwin
minstrel@wam.umd.edu