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 processes of the opposing program to
terminate, leaving your program in sole posession of the machine.

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

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.

Core War was first described in the Core War Guidelines of
March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer
Science at The University of Western Ontario (Canada). Dewdney wrote
several "Computer Recreations" articles in Scientific American
which discussed Core War, starting with the May 1984 article. Those
articles are contained in two anthologies:

Steven Morrell (morrell@math.utah.edu) is preparing a more practically
oriented Redcode tutorial that discusses different warrior classes with lots
of example code. Mail him for a
preliminary version. Michael Constant (mconst@csua.berkeley.edu) is
reportedly working on a beginner's introduction.

There is an ongoing discussion about future enhancements to the
Redcode language. A proposed new standard, dubbed ICWS'94, is currently
being evaluated. A major change is the addition of "instruction modifiers"
that allow instructions to modify A-field, B-field or both. Also new is a
post-increment indirect addressing mode and unrestricted opcode and
addressing mode combination ("no illegal instructions"). ICWS'94 is
backwards compatible; i.e. ICWS'88 warriors will run correctly on an
ICWS'94 system. Take a look at the
ICWS'94 draft
<URL:ftp://ftp.csua.berkeley.edu/pub/corewar/documents/icws94.0202.Z>
for more information. You can try out
the new standard by submitting warriors to the '94 hills of the
KotH servers.
Two corewar systems currently support ICWS'94,
pMARS (many platforms) and Redcoder (Mac),
both available at
ftp.csua.berkeley.edu.

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).

For more information about joining the ICWS (which includes a
subscription to TCWN), or to contribute an article, review, cartoon, letter,
joke, rumor, etc. to TCWN, please contact:

Jon Newman
13824 NE 87th Street
Redmond, WA 98052-1959
email: jonn@microsoft.com (Note: Microsoft has NO affiliation with
Core War. Jon Newman just happens
to work there, and we want to keep
it that way!)

The Electronic Branch Section (EBS) of the ICWS is a group of
Core War enthusiasts with access to electronic mail. There are no fees
associated with being a member of the EBS, and members do reap some of
the benefits of full ICWS membership without the expense. For instance,
the ten best warriors submitted to the EBS tournament are entered
into the annual ICWS tournament. All EBS business is conducted in the
rec.games.corewar newsgroup.

The current goal of the EBS is to be at the forefront of Core War by writing
and implementing new standards and test suites.

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
<URL:ftp://ftp.csua.berkeley.edu/pub/corewar/systems>
(128.32.149.19) in the /pub/corewar directories. Also, most of past
rec.games.corewar postings (including Redcode source listings) are
archived there. Jon Blow (blojo@csua.berkeley.edu) is the archive
administrator. When uploading to /pub/corewar/incoming,
ask Jon to move
your upload to the appropriate directory and announce it on the net.

Much of what is available on soda is also available on the German archive
at
iraun1.ira.uka.de (129.13.10.90) in the /pub/x11/corewars directory.

CAUTION! There are many, many Core War systems available which are NOT
ICWS'88 (or even ICWS'86) compatible available at various archive sites
other than ftp.csua.berkeley.edu. Generally, the older the program - the less
likely it will be ICWS compatible.

Reviews of Core War systems would be greatly appreciated in the newsgroup
and in the newsletter.

Below is a not necessarily complete or up-to-date list of what's available
at ftp.csua.berkeley.edu:

There is an ftp email server at
ftpmail@decwrl.dec.com. Send
email with a subject and body text of "help" (without the quotes) for
more information on its usage. If you don't have access to the net at all,
send me a 3.5 '' diskette in a self-addressed disk mailer with postage and
I will mail it back with an image of the Core War archives in PC format.
My address is at the end of this post.

The ICWS holds an annual tournament. Traditionally, the deadline
for entering is the 15th of December. The EBS usually holds a
preliminary tournament around the 15th of November
and sends the top finishers on to the ICWS tournament.

Informal double-elimination and other types of tournaments are held
frequently among readers of the newsgroup; watch there for announcements
or
contact me.

King Of The Hill (KotH) is an ongoing Core War tournament
available to anyone with email. You enter by submitting via email a Redcode
program (warrior) with special comment lines. You will receive a reply
indicating how well your program did against the current top programs
"on the hill".

There are two styles of KotH tournaments, "classical" and "multi-warrior".
The "classical" KotH is a one-on-one tournament, that is your warrior will
play 100 battles against each of the 20 other programs currently on the
Hill. You receive 3 points for each win and 1 point for each tie. (The
existing programs do not replay each other, but their previous battles are
recalled.) All scores are updated to reflect your battles and all 21
programs are ranked from high to low. If you are number 21 you are pushed
off the Hill, if you are higher than 21 someone else is pushed off.

In "multi-warrior" KotH, all warriors on the hill fight each other at the
same time. Score calculation is a bit more complex than for the one-on-one
tournament. Briefly, points are awarded based on how many warriors survive
until the end of a round. A warrior that survives by itself gets more points
than a warrior that survives together with other warriors. Points are
calculated from the formula (W*W-1)/S, where W is the total number of
warriors and S the number of surviving warriors. The
pMARS documentation
has more information on multi-warrior scoring.

The idea for an email-based Core War server came from David Lee. The original KotH was
developed and run by William Shubert at Intel starting in 1991, and
discontinued after almost three years of service. Currently, KotHs based on
Bill's UNIX scripts but offering a wider variety of hills are are running at
two sites: "koth@stormking.com" is maintained by
Scott J. Ellentuch (tuc@stormking.com) and
"pizza@ecst.csuchico.edu" by
Thomas H. Davies (sd@ecst.csuchico.edu). Up until May '95, the two sites provided overlapping services, i.e. the some of the hill types were offered by
both "pizza" and "stormking". To conserve resources, the different hill types
are now divided up among the sites. The way you submit warriors to both KotHs
is pretty much the same. Therefore, the entry rules described below apply to
both "pizza" and "stormking" unless otherwise noted.

Entry rules for King of the Hill Corewar:

1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that
a comma (",") is required between two arguments.

2) Put a line starting with ";redcode" (or ";redcode-94, etc., see below)
at the top of your program.
This MUST be the first line. Anything before it will be lost. If
you wish to receive mail on every new entrant, use ";redcode
verbose". Otherwise you will only receive mail if a challenger
makes it onto the hill. Use ";redcode quiet" if you wish to
receive mail only when you get shoved off the hill. (Also, see 5
below).

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

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

There are currently seven separate hills you can select by starting your
program with ;redcode-b, ;redcode-94,
;redcode-94x, ;redcode, ;redcode-icws, ;redcode-94m or ;redcode-94xm. The
former three run at "pizza", the latter four at "stormking".
More information on these hills is listed below.

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

5) In an hour or so you should get more
mail telling you how your program performed against the current top 20
(or 10)
programs. If no news arrives during that time, don't worry; entries are
put in a queue and run through the tournament one at a time. A backlog
may develop. Be patient.

If your program makes it onto the hill, you will get mail every time a
new program makes it onto the hill. If this is too much mail, you can use
";redcode[-??] quiet" when you first mail in your program; then you will only
get mail when you make it on the top 20 list or when you are knocked off.
Using ";redcode[-??] verbose" will give you even more mail; here you get mail
every time a new challenger arrives, even if they don't make it onto the
top 20 list.

Often programmers want to try out slight variations in their programs.
If you already have a program named "foo V1.0" on the hill, adding the
line ";kill foo" to a new program will automatically bump foo 1.0 off the
hill. Just ";kill" will remove all of your programs when you submit the
new one. The server kills programs by assigning an impossibly low score;
it may therefore take another successful challenge before a killed program
is actually removed from the hill.

If you just want to get a status report without actually challenging the
hills, send email with ";status" as the message body (and don't forget
"Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject:
koth help" you will receive instructions that may be more up to date than
those contained in this document.

At stormking, a message body with ";help" will return brief instructions.
If you submit code containing a ";test" line, your warrior will be assembled
but not actually pitted against the warriors on the hill.

All hills run portable
MARS (pMARS) version 0.8, a platform-independent corewar system
available at ftp.csua.berkeley.edu.

The '94 and '94x hills allow three experimental opcodes and
addressing modes currently not covered in the
ICWS'94 draft document:

Core is initialized to DAT 0, 0. This is an "illegal" instruction
under ICWS'88 rules and strictly compliant assemblers (such as KotH or
pmars -8) will not let you write a DAT 0, 0 instruction - only DAT #0, #0.
So this begs the question, how to compare something to see if it is empty
core. The answer is, most likely the instruction before your first
instruction and the instruction after your last instruction are both DAT
0, 0. You can use them, or any other likely unmodified instructions, for
comparison. Note that under
ICWS'94, DAT 0, 0 is a legal instruction.

SLT gives some people trouble because of the way modular arithmetic
works. It is important to note that all negative numbers are converted
to positive numbers before a battles begins. Example: (-1) becomes
(M - 1) where M is the memory size.

Once you realize that all numbers are treated as positive, it is clear
what is meant by "less than". It should also be clear that no number is
less than zero.

These terms refer to the way instruction operands are evaluated. The '88
Redcode standard ICWS'88 is unclear about whether a simulator should "buffer"
the result of A-operand evaluation before the
B-operand is evaluated. Simulators that do buffer are said to use in-register
evaluation, those that don't, in-memory evaluation.
ICWS'94 clears this
confusion by mandating in-register evaluation. Instructions that execute
differently under these two forms of evaluation are MOV, ADD, SUB, MUL, DIV
and MOD where the effective address of the A-operand is modified by
evaluation of the B-operand. This is best illustrated by an example:

L1 mov L2,<L2
L2 dat #0,#1

Under in-register evaluation, the 'L2' instruction is saved in a buffer before
the 'L2' memory location is decremented by evaluation of the B-operand of 'L1'.
The saved 'dat #0,#1' instruction is then written to 'L2', leaving it unchanged.

Under in-memory evaluation, the 'L2' instruction is not buffered and
thus decremented by evaluation of the B-operand. After execution of 'L1',
'L2' changes to "dat #0,#0".

(also Slaver, Vampire). A program which enslaves another.
Usually accomplished by bombing with JMPs to a SPL 0 pit with an
optional core-clear routine.

Quick Scan

2c scan of a set group of core locations with bombing if anything
is found. Both of the following codes snips scan 16 locations and
check for a find. If anything is found, it is attacked, otherwise
16 more locations are scanned.
Example:

Copy of a program or program part, positioned to make
the active program invisible to a CMP-scanner.

Replicator

Generic for Paper. A program which makes many copies of
itself, each copy also making copies.

Self-Splitting

Strategy of amplifying the number of processes executing
a piece of code.

example SPL 0
loop ADD #10, example
MOV example, @example
JMP loop

Scanner

A program which searches through core for an opponent rather
than bombing blindly.

Scissors

A program designed to beat replicators, usually a (B-field
scanning) vampire. Part of the Paper-Scissors-Stone analogy.

Self-Repair

Ability of a program to fix it's own code after attack.

Silk

A replicator which splits off a process to each new copy before
actually copying the code. This allows it to replicate extremely
quickly. This technique is only possible under the
'94 draft, because
it requires post-increment indirect addressing.
Example:

Additions, corrections, etc.
to this document are solicited. Thanks
in particular to the following people who have contributed major
portions of this document: Paul Kline, Randy Graham.
Mark Durham wrote the first version of the FAQ.