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.
Author: Dewdney, A. K.
Title: The Armchair Universe: An Exploration of Computer Worlds
Published: New York: W. H. Freeman (c) 1988
ISBN: 0-7167-1939-8
Library of Congress Call Number: QA76.6 .D517 1988
Author: Dewdney, A. K.
Title: The Magic Machine: A Handbook of Computer Sorcery
Published: New York: W. H. Freeman (c) 1990
ISBN: 0-7167-2125-2 (Hardcover), 0-7167-2144-9 (Paperback)
Library of Congress Call Number: QA76.6 .D5173 1990
A.K. Dewdney's articles are still the most readable introduction to Core War, even though the Redcode dialect described in there is no longer current.
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.
Jon Newman
13824 NE 87th Street
Redmond, WA 98052-1959
email: jonn@microsoft.com (Note: Microsoft has NO affiliation with
Core War. Jon Newman just happens
to work there, and we want to keep
it that way!)
Current annual dues are $15.00 in US currency.
The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites.
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.
The plain text version of this FAQ is automatically archived by news.answers.
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:
MADgic41.lzh - corewar for the Amiga, v4.1
MAD4041.lzh - older version?
MAD50B.lha - corewar for the Amiga, beta version 5.0
Redcoder-21.hqx - corewar for the Mac, supports ICWS'88 and '94 (without
extensions)
core-11.hqx - corewar for the Mac
core-wars-simulator.hqx - same as core-11.hqx?
corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but
not ICWS'88 compatible
koth31.tar.Z - corewar for UNIX/X-windows. This program ran the
former KotH server at intel.com
koth.shar.Z - older version
kothpc.zip - port of older version of KotH to the PC
deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC
mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible
icons.zip - corewar icons for MS-Windows
macrored.zip - a redcode macro-preprocessor (PC)
c88v49.zip - PC corewar, textmode display
mars88.zip - PC corewar, graphics mode display
corwp302.zip - PC corewar, textmode display, slowish
mercury2.zip - PC corewar written in assembly, fast!
mtourn11.zip - tournament scheduler for mercury (req. 4DOS)
pmars08s.zip - portable system, ICWS'88 and '94, runs on UNIX,
PC, Mac, Amiga. C source archive
pmars08s.tar.Z - same as above
pmars08.zip - PC executables with graphics display, req 386+
macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2)
buggy, no display
MacpMARS1.99a.cpt.hqx - port of v0.8 for the Mac, with display and
debugger
MacpMARS1.0s.cpt.hqx - C source (MPW, ThinkC) for Mac frontend
ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1)
wincor11.zip - MS-Windows system, shareware ($15)
SUB COREWAR-L FirstName LastName
to listproc@stormking.com.
You can send mail to
corewar-l@stormking.com
to post even if you are not
a member of the list. Responsible for the listserver is
Scott J. Ellentuch
(tuc@stormking.com).
Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you.
Informal double-elimination and other types of tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me.
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
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.
3) Mail this file to
koth@stormking.com
or
pizza@ecst.csuchico.edu.
"Pizza" requires a subject of "koth" (use the -s flag on most mailers).
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.
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:
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.
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".
(References to an X-like program mean that the term X is derived from the
specific program X and has become a generic term).
The rec.games.corewar FAQ is Copyright 1995 and maintained by:
SAMPLE ENTRY:
;redcode
;name Dwarf
;author A. K. Dewdney
;strategy Throw DAT bombs around memory, hitting every 4th memory cell.
;strategy This program was presented in the first Corewar article.
bomb DAT #0
dwarf ADD #4, bomb
MOV bomb, @bomb
JMP dwarf
END dwarf ; Programs start at the first line unless
; an "END start" pseudo-op appears to indicate
; the first logical instruction. Also, nothing
; after the END instruction will be assembled.
Here are the Specs for the various hills:
ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at
"stormking")
hillsize: 20 warriors
rounds: 100
coresize: 8000
max. processes: 8000
duration: after 80,000 cycles, a tie is declared.
max. entry length: 100
minimum distance: 100
instruction set: ICWS '88
ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws",
available at "stormking")
hillsize: 20 warriors
rounds: 100
coresize: 8192 instructions
max. processes: 8000 per program
duration: After 100,000 cycles, a tie is declared.
max. entry length: 300
minimum distance: 300
instruction set: ICWS '88
ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at
"pizza")
hillsize: 20 warriors
rounds: 100
coresize: 8000
max. processes: 8000
duration: after 80,000 cycles, a tie is declared.
max. entry length: 100
minimum distance: 100
instruction set: extended ICWS '94 Draft
ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available
at "pizza")
hillsize: 20 warriors
rounds: 100
coresize: 8000
max. processes: 8000
duration: after 80,000 cycles, a tie is declared.
max. entry length: 100
minimum distance: 100
instruction set: extended ICWS '94 Draft
max. age: after 100 successful challenges, warriors are retired.
ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x",
available at "pizza")
hillsize: 20 warriors
rounds: 100
coresize: 55440
max. processes: 10000
duration: after 500,000 cycles, a tie is declared.
max. entry length: 200
minimum distance: 200
instruction set: extended ICWS '94 Draft
ICWS'94 Draft Multi-Warrior Hill Specs: (Accessed with ";redcode-94m",
available at "stormking")
hillsize: 10 warriors
rounds: 200
coresize: 8000
max. processes: 8000
duration: after 80,000 cycles, a tie is declared.
max. entry length: 100
minimum distance: 100
instruction set: extended ICWS '94 Draft
ICWS'94 Experimental (Big) Multi-Warrior Hill Specs:
(Accessed with ";redcode-94xm", available at "stormking")
hillsize: 20 warriors
rounds: 100
coresize: 55440
max. processes: 10000
duration: after 500,000 cycles, a tie is declared.
max. entry length: 200
minimum distance: 200
instruction set: extended ICWS '94 Draft
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.
SEQ - Skip if EQual (synonym for CMP)
SNE - Skip if Not Equal
NOP - (No OPeration)
* - indirect using A-field as pointer
{ - predecrement indirect using A-field
} - postincrement indirect using A-field
Is it DAT 0, 0 or DAT #0, #0? How do I compare to core?
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.
How does SLT (Skip if Less Than) work?
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.What is the difference between
in-register and in-memory evaluation?
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.
What does (expression or term of your
choice) mean?
Here is a selected glossary of terms. If you have a definition and/or
term you wish to see here, please
send it to me.
impsize equ 2667
example spl 4 ; extend by adding spl 8, spl 16, etc.
spl 2
jmp imp+(0*impsize) ; jmp's execute in order
jmp imp+(1*impsize)
spl 2
jmp imp+(2*impsize)
jmp imp+(3*impsize)
imp mov 0,impsize ; in '94 use -> mov.i #0,impsize
example add #10,scan
scan jmz example,10
example add step,scan
scan cmp 10,30
jmp attack
jmp example
step dat #20,#20
example dat #100
example ...
...
djn example,<4000
example MOV 0, 1
or
example MOV 0, 2
MOV 0, 2
example ...
...
SPL 0, <example
DAT <example, #0
d EQU (coresize+1)/3
A MOV 0,d ; copy self to B
B MOV 0,d ; copy self to C
C MOV 0,d ; copy self to A+1
d EQU (coresize+1)/3
A MOV 0,d ; copy self to B
B MOV 0,d ; copy self to C
C MOV 0,d ; copy self to A+1
A+1 MOV 0,d ; copy self to B+1
B+1 MOV 0,d ; copy self to C+1
C+1 MOV 0,d ; copy self to A+2
example SPL 0, 8
MOV -1, <-1
impsize equ 2667
example spl 1 ; extend by adding more spl 1's
spl 1
spl 2
jmp @0,imp
add #impsize,-1 ; bump address by impsize after each jmp
dat #0,#0 ; excess processes must die!
imp mov 0,impsize ; in '94 use -> mov.i #0,impsize
start
s1 for 8 ;'88 scan
cmp start+100*s1, start+100*s1+4000 ;check two locations
mov #start+100*s1-found, found ;they differ so set pointer
rof
jmn attack, found ;if we have something, get it
s2 for 8
cmp start+100*(s2+6), start+100*(s2+6)+4000
mov #start+100*(s2+6)-found, found
rof
found jmz moveme, #0 ;skip attack if qscan found nothing
attack cmp @found, start-1 ;does found points to empty space?
add #4000, found ;no, so point to correct location
mov start-1, @found ;move a bomb
moveme jmp 0, 0
In
ICWS'94, the quick scan code is more compact because of the SNE
opcode:
start ;'94 scan
s1 for 4
sne start+400*s1, start+400*s1+100 ;check two locations
seq start+400*s1+200, start+400*s1+300 ;check two locations
mov #start+400*s1-found, found ;they differ so set pointer
rof
jmn which, found ;if we have something, get it
s2 for 4
sne start+400*(s2+4), start+400*(s2+4)+100
seq start+400*(s2+4)+200, start+400*(s2+4)+300
mov #start+400*(s2+4)-found-100, found
rof
found jmz moveme, #0 ;skip attack if qscan found nothing
add #100, -1 ;increment pointer till we get the
which jmn -1, @found ;right place
mov start-1, @found ;move a bomb
moveme jmp 0, 0
example SPL 0
loop ADD #10, example
MOV example, @example
JMP loop
spl 1
mov.i -1, 0
spl 1 ;generate 6 consecutive processes
silk spl 3620, #0 ;split to new copy
mov.i >-1, }-1 ;copy self to new location
mov.i bomb, >2000 ;linear bombing
mov.i bomb, }2042 ;A-indirect bombing for anti-vamp
jmp silk, {silk ;reset source pointer, make new copy
bomb dat.f >2667, >5334 ;anti-imp bomb
example spl 0
jmp -1
impsize equ 2667
example spl 1 ; extend by adding more spl 1's
spl 1
djn.a @imp,#0 ; jmp @ a series of pointers
dat #0,imp+(3*impsize)
dat #0,imp+(2*impsize)
dat #0,imp+(1*impsize)
dat #0,imp+(0*impsize)
imp mov.i #0,impsize
Other questions?
Just ask in the rec.games.corewar
newsgroup or
contact me
(address below). If you are shy, check out the
Core
War archives first to see if your question has been
answered before.
Credits
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.
Stefan Strack, PhD stst@vuse.vanderbilt.edu
Dept. Molecular Physiol. and Biophysics stst@idnsun.gpct.vanderbilt.edu
Rm. 762, MRB-1 stracks@vuctrvax.bitnet
Vanderbilt Univ. Medical Center Voice: +615-322-4389
Nashville, TN 37232-6600, USA FAX: +615-322-7236
$Id: corewar-faq.html,v 3.6 1995/10/12 22:44:37 stst Exp stst $