From: "iapdk@admin.drake.edu" <iapdk@admin.drake.edu>
Subject: Imp Trap
Date: 1 Feb 2006 14:34:22 -0800
Message-ID: <1138833262.786739.60690@z14g2000cwz.googlegroups.com>

Here is what may be a new imp-killer.  It is a passive routine that is
only activated by an imp and therefore requires no processes from your
warrior.

Let's say your end game is a spl-dat wiper.  If you get to the end game
you stand a pretty good chance of winning, but you can not kill
slow-running imps with a forward dat-wipe.  You might have some luck if
your dat-bomb is "dat <2667,<5334" and your opponent is a 3-point imp.
Otherwise the imps keep going and time expires.

Even if you have a perfect gate and a 1c wiper like Dclear the imps
will not all reach it.  But if one of them does, why not recruit him to
wipe his brothers?  An imp does not die on the gate, it dies on the
following instruction because it is unable to write past the gate. So,
recruit that process and put him to work:

trap    spl    #0    ,0
        add.ab #381  ,1       ; spiral wipe for 3,7 point imps
        djn.b  -1    ,20      ; wipe once through core
        mov.i  #0    ,-1      ; mov-wipe the trap
        dat    0     ,0       ; die

P. Kline



From: "iapdk@admin.drake.edu" <iapdk@admin.drake.edu>
Subject: Re: New Imp
Date: 1 Feb 2006 14:48:38 -0800
Message-ID: <1138834118.893458.260070@f14g2000cwb.googlegroups.com>

Lukasz, you reinvented the "binary launcher".   Nothing launches
faster.  But it launches a short spiral, can only be used once, and is
huge.  Continuous launchers and silk-launchers rapidly became the norm
and imps were changed forever from being fast, aggressive, killing
machines to defensive fall-backs.  Note that "The Impire Strikes Back"
actually killed most of the non-paper programs when it was first
released.

Another launcher that may be making a comeback is from Nimbus:

;redcode
;name Nimbus 1.2
;author Alex MacAulay
;strategy Create a 63-point 2-process ring, wait, then clear core.
;strategy 1.2 - Core-clear unaffected by djn streams.
;assert 1
step	  equ 127

start	  spl wait
	  spl 1
	  spl 1
	  spl 1
	  spl 1
	  spl 1
	  mov -1,0
	  spl 1
	  spl inc
spread	  jmp @spread,#imp
inc	  add #step,spread ; need a dat after this instruction
bomb	  dat <-5,<-6

wait	  djn 0,#step-35
cc	  mov bomb,<ptr
	  spl cc,<wait
ptr	  jmp cc,<cc

imp	  mov 0,step

	  end start

P. Kline



From: Christoph Birk <birk@ociw.edu>
Subject: Koenigstuhl News
Date: Wed, 1 Feb 2006 20:04:55 -0500 (EST)
Message-ID: <200602020012.QAA11999@andromeda.ociw.edu>

Congratulations to Wayne Sheppard!

His program 'NightCrawler 2^13' is the new KotH of the ICWS-Koenigstuhl.

On the matter of the OPEN-hill: 
I have deciced to close the OPEN-Koenigstuhl and create a 94draft hill.
It's basically the OPEN-hill MINUS 88-warriors.

On the scoring algorithm:
I will stay with the 'old' interative method for the time beeing ...

Expect the 'construction' signs to come down soon :-)

Christoph
http://www.ociw.edu/~birk/COREWAR/koenigstuhl.html



From: =?ISO-8859-2?Q?=A3ukasz_Adamowski?= <corewars@wp.pl>
Subject: Re: New Imp
Date: Thu, 2 Feb 2006 17:01:34 -0500 (EST)
Message-ID: <43e277e6f0f0c@wp.pl>

Dnia 2-02-2006 o godz. 0:17 iapdk@admin.drake.edu napisal:
> Lukasz, you reinvented the "binary launcher".   Nothing launches
> faster.  But it launches a short spiral, can only be used once, and is
> huge. 

No, I wasn't reinventing binary launcher. :] I've learnt about it from r.g.cw, which I'm thankful. My idea was mixing both A- and B-imps in the same laucher and even mixing 3- and more point spirals . I have no experience in writing... well, in fighting imp-spirals, but I think such mixing may be useful sometimes.
As for Imp Trap: the idea is very nice, I wonder if it's worth implementing. Do you have any results?
Greetings
Lukasz Adamowski

-= "War is a problem, never a solution" =-
-= "Wojna jest problemem, a nie rozwiazaniem" =-


----------------------------------------------------
Harry Potter i Ksi��� P�krwi 
NIEZIEMSKI KONKURS i czarodziejskie gad�ety!
http://klik.wp.pl/?adr=www.harrypotter.wp.pl&sid=645




From: "iapdk@admin.drake.edu" <iapdk@admin.drake.edu>
Subject: Re: New Imp
Date: 3 Feb 2006 06:00:31 -0800
Message-ID: <1138975230.970047.159380@g14g2000cwa.googlegroups.com>

I tried it in a program I'm working on but it was not compatible with
the other parts, so it is on hold for now.  I always seem to have more
ideas than time :-)

Mixing imps is certainly a good idea.  Paper can attack 3-point a-imps
with:
  mov.i #2667,{1
  mov.i #2667,{1

But the same construction does is not effective against b-imps:
  mov.i #x,<1
  mov.i #x,<1

However, if you write those instructions on every-other location it
works very well against any-point b-imps:
  mov.i #x ,<1
  mov.i #y,2667
  mov.i #x ,<1
  mov.i #y,2667

Or a-imps:
  mov.i #x ,{1
  mov.i #2667,*0
  mov.i #x ,{1
  mov.i #2667,*0

P. Kline



From: "Jens Gutzeit" <jens@jgutzeit.de>
Subject: Score Surfaces - Round 2
Date: 4 Feb 2006 05:48:08 -0800
Message-ID: <1139060888.814059.113300@g14g2000cwa.googlegroups.com>

Hi everybody,

it has taken me a while to create a new client for calculating score
surfaces, but now I have a test version ready. Before we actually start
to calculate new score surface, I want to make sure, that everything
works fine. If you want to test the client (Python and pMARS needed),
please come to #corewars before using the client.

The test version can be found at

http://corewars.jgutzeit.de/temp/dissc_client.tar.gz

(DiSSC - Distributed Score Surface Calculation ;-)

- Jens Gutzeit :-)



From: "Jens Gutzeit" <jens@jgutzeit.de>
Subject: Re: Score Surfaces - Round 2
Date: 4 Feb 2006 08:10:03 -0800
Message-ID: <1139069402.994247.36430@o13g2000cwo.googlegroups.com>

So far everything seems to work quite well. If you want to use the
client, just run:

python dissc_client.py --user="Your user name"

You can safely kill the client any time. It fetches information about
which patch to work on from my homepage and sends back the
data after the patch is finished. When a score surface is complete
I'll publish it on my homepage.

Tomorrow DiSSC (Distributed Score Surface Calculation) will get
its own homepage. Until then please post any problems, you might
encounter.

Altough I have some ideas about which score surfaces to calculate,
I'd really like to hear about your ideas.

Regards,

Jens Gutzeit :-)



From: "Jens Gutzeit" <jens@jgutzeit.de>
Subject: Re: Score Surfaces - Round 2
Date: 4 Feb 2006 08:22:12 -0800
Message-ID: <1139070131.982224.202150@g47g2000cwa.googlegroups.com>

I've forgotten to say, that you usually have to edit the file
dissc.cfg and change the path to pMARS.

- Jens :-)



From: "Jens Gutzeit" <jens@jgutzeit.de>
Subject: DiSSC - Distributed Score Surface Calculation
Date: 5 Feb 2006 02:19:48 -0800
Message-ID: <1139134787.996664.35290@g43g2000cwa.googlegroups.com>

Hi everybody,

after a quick test I've decided to officially start to work on new
score surfaces. If you don't know, what score surfaces are,
please take a look at

http://corewars.jgutzeit.de/score_surfaces/index.en.html

Calculating score surfaces needs a lot of time. That's why distributing
the required work among as many computers as possible seems to be
a good idea. DiSSC does that :-)

All you need is a little Python script and pMARS. You can request to
work on the score surfaces any time you want and of course you can
stop to work on them any time you want. Just start (or kill) the Python
script.

The Python script and some information can be found at

http://corewars.jgutzeit.de/score_surfaces/dissc/index.en.html

Feel free to suggest new score surfaces to work on. At the moment there
is only a modified version of YAP (jmp instead of djn.f) vs. Muskrat.

Regards,

Jens Gutzeit :-)



From: roy.van.rijn@gmail.com
Subject: EvolveWars - A virtual peer-to-peer corewar universe
Date: 6 Feb 2006 04:32:16 -0800
Message-ID: <1139229136.090131.157630@g14g2000cwa.googlegroups.com>

Hi all,

Yesterday I had a nice chat with brx, me trying to light up ideas for
his distibuted evolver 'EVE'. While talking to him a old idea of mine
was discussed, and during our talk we came up with new ideas to realize
it.

Currently there are a couple of people evolving, and a most are writing
their own evolver (I tried it myself.. twice). But there is one thing
that hasn't been attempted yet: One big evolver instead of smaller ones

Using a peer-to-peer architecture people can attach their evolvers to a
virtual universe. With this EvolveWars-protocol we imagined you can
evolve like you would normally do using your own software. But once in
a while you connect to the main server, then your pc becomes a little
island in the universe of EvolveWars. You still have your own
population, which evolves the way you like, but you suddenly have
invading parties with 5-10 warriors! Alien warriors from another island
invading your warriorpool. The big advantage here is the introduction
of new code, code that isn't just random, but working.

This protocol would also have more functions, for example sombody might
run a hillnode. The hillnode accepts all invading parties and tests
them against a hill.

Possible advantages of this concept:
1. Might spark new players
2. Competition among evolvers > new better/faster algorithms/faster
marses (?)
3. New evolved warriors
4. Publicity (if we write some good articles)

It wouldn't be so hard to think of a protocol for sending warriors and
connecting your virtual island to other islands. Having a nice open
protocol will make it easier for other programming languages to make a
plugin.
Then people can make their own evolvers, test their own ideas, and see
which node produces the best warriors. It can even turn into this like:

1. Warrior XXX, produced by bvowk with BadassEvolver using fmars
2. Warrior XXX, produced by Roy with RoysEvolver using exMars
3. Warrior XXX, produced by brx with EVE using exhaust

So you have people bragging about their evolver, about the mars
(speed!) they are using, the evolution technique/algorithms etc.

Its just fun to see your evolver as a small chain in a big corewar
world, you can use it online, and if you don't have a connection, just
use it offline for a while like a normal evolver. Statistics could be
kept on a nice webpage, how many warriors you send, how good they
score. Maybe we could even implement monitoring into the protocol. Then
you can keep track of your little warriors while they invade
neighbouring islands. (this would be hard because everybody uses the
warriors differently).

We could even make a dynamic virtual map of the universe with the
currently online nodes. The size of the islands corresponding to the
size of the pools, and on those islands some information on those nodes
(highest scoring warrior, node name, evolver name, which mars its
using).

Even if you are just starting out with evolving, getting code from
other nodes will mean you too have good change of just creating that
little change that could turn a normal warrior into a winner.

People have been using other peoples warrior-code for years, its time
evolvers do the same!

What are your ideas on this concept? Reply!

Ohw and second: Feel free to volunteer us with the protocol and server
implementations, I personally have little experience with that... :)



From: KOTH <koth@koth.org>
Subject: KOTH.ORG: Status - ICWS Experimental 94 02/06/06
Date: Mon, 6 Feb 2006 07:59:40 -0500 (EST)
Message-ID: <200602060506.k16561UU010235@asgard.t-b-o-h.net>

			Weekly Status on  02/06/06
 
-=- irc.KOTH.org is up! Meetings held in #corewars
-=- Tons of new features on www.KOTH.org/koth.html pages
-=- *FAQ* page located at: www.KOTH.org/corewar-faq.html
 


Current Status of the KOTH.ORG ICWS Experimental 94 CoreWar Hill:

Last battle concluded at : Sun Jan 15 22:39:22 EST 2006
 
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  46/ 36/ 19             Fatamorgana X           Zul Nadzri     156      10
 2  45/ 36/ 19                      Ogre    Christian Schmidt     154     171
 3  44/ 37/ 20             The X Machine           Zul Nadzri     151      34
 4  35/ 21/ 43                xd100 test        David Houston     149      20
 5  43/ 39/ 18              Eliminator X           Zul Nadzri     147      35
 6  28/ 11/ 61              Evol Cap 4 X       John Wilkinson     146     292
 7  33/ 25/ 42                    KAT v5          Dave Hillis     142     155
 8  39/ 37/ 24              Trefoil F 13        Steve Gunnell     141     106
 9  23/  6/ 71             Evolve X v4.0       John Wilkinson     141     240
10  39/ 38/ 23         Trefoil Test F 14        Steve Gunnell     139       7
11  39/ 40/ 21                Bewitching          S.Fernandes     139       1
12  41/ 43/ 16        Giant Hazy Test 13        Steve Gunnell     139      50
13  41/ 44/ 15               O_Fortuna3X        Nenad Tomasev     138       6
14  38/ 37/ 25                      test        Some Redcoder     138       4
15  39/ 41/ 20        Simply Intelligent           Zul Nadzri     138      16
16  39/ 40/ 21     Controlled Aggression          Ian Oversby     137     223
17  33/ 30/ 38                  Olivia X             Ben Ford     136     104
18  39/ 43/ 18               Black Moods          Ian Oversby     136     219
19  32/ 28/ 40                 Glenstorm         John Metcalf     136      85
20  39/ 46/ 14              Fatal Choice        Some Redcoder     132       5

21   6/ 76/ 18             : messybomber     : Joshua Renfrey      37       0



From: KOTH <koth@koth.org>
Subject: KOTH.ORG: Status -  94 No Pspace 02/06/06
Date: Mon, 6 Feb 2006 07:59:38 -0500 (EST)
Message-ID: <200602060509.k165917w010484@asgard.t-b-o-h.net>

			Weekly Status on  02/06/06
 
-=- irc.KOTH.org is up! Meetings held in #corewars
-=- Tons of new features on www.KOTH.org/koth.html pages
-=- *FAQ* page located at: www.KOTH.org/corewar-faq.html
 


Current Status of the KOTH.ORG 94 No Pspace CoreWar Hill:

Last battle concluded at : Sun Feb 5 20:01:43 EST 2006
 
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  33/ 26/ 41       Monster_Human_Grunt             inversed     140      50
 2  32/ 26/ 43       Monster_Alien_Grunt             inversed     138      51
 3  29/ 21/ 50               MoonOfChaos        Nenad Tomasev     136      13
 4  27/ 19/ 54                     2by4k              P.Kline     135      11
 5  28/ 21/ 51            Last Judgement    Christian Schmidt     135     235
 6  30/ 28/ 42           Gods Of Destiny        Nenad Tomasev     133     179
 7  40/ 48/ 12                 TheDanube        Nenad Tomasev     133      12
 8  30/ 28/ 41                   Battery          Sascha Zapf     133      57
 9  30/ 28/ 42                HullabaTwo                  Roy     132     380
10  28/ 25/ 47                  Atlas_II        Nenad Tomasev     132      10
11  26/ 20/ 54                      test         Roy van Rijn     132       2
12  36/ 42/ 22                 Razorgirl          S.Fernandes     131      25
13  42/ 53/  6   don't disturb the dust!         John Metcalf     130      53
14  24/ 17/ 59                 Acillatem        Nenad Tomasev     130      15
15  24/ 18/ 58               Tie Fast!!!    Christian Schmidt     130      26
16  26/ 23/ 51               Rust [v0.2]             inversed     128     158
17  27/ 26/ 47                     Amber             inversed     127       4
18  39/ 52/  9              Fish'n'Chips    Christian Schmidt     127       5
19  35/ 44/ 22                     xeper      Andreas Scholta     126       1
20  34/ 42/ 24               Codgeriffic              P.Kline     126       3

21  36/ 48/ 16                 Spy-Glass    Christian Schmidt     125      71



From: KOTH <koth@koth.org>
Subject: KOTH.ORG: Status - Standard 02/06/06
Date: Mon, 6 Feb 2006 08:03:43 -0500 (EST)
Message-ID: <200602060500.k16501j3009997@asgard.t-b-o-h.net>

			Weekly Status on  02/06/06
 
-=- irc.KOTH.org is up! Meetings held in #corewars
-=- Tons of new features on www.KOTH.org/koth.html pages
-=- *FAQ* page located at: www.KOTH.org/corewar-faq.html
 


Current Status of the KOTH.ORG Standard KotH CoreWar Hill :

Last battle concluded at : Wed Feb 1 14:59:46 EST 2006
 
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  34/ 24/ 43                      Test Alexander (Sasha) Wa     144     178
 2  38/ 36/ 26                My 1st try    Christian Schmidt     140      70
 3  34/ 29/ 37         The Next Step '88        David Houston     140      54
 4  31/ 25/ 44            The Hurricaner            G.Labarga     137      25
 5  30/ 23/ 47                      test            G.Labarga     137      21
 6  30/ 24/ 46                  Guardian          Ian Oversby     136     238
 7  31/ 27/ 41           SoundOfDarkness        Nenad Tomasev     135       2
 8  37/ 40/ 23                  Moonwipe    Christian Schmidt     134      35
 9  42/ 49/  9                Replihater        Some Redcoder     134       9
10  38/ 42/ 19              Scan the Can    Christian Schmidt     134      19
11  40/ 47/ 14              Speeed 88mph    Christian Schmidt     133      38
12  32/ 31/ 37                  The Seed         Roy van Rijn     132      56
13  23/ 15/ 61               Utterer '88    Christian Schmidt     131      13
14  36/ 41/ 23                      July        Nenad Tomasev     131      11
15  39/ 48/ 13             Scan Test C 6        Steve Gunnell     131      77
16  38/ 46/ 16                    Kraken        Nenad Tomasev     129       1
17  30/ 31/ 40                    A.I.P.    Christian Schmidt     128      46
18  20/ 13/ 67                 IMParable            G.Labarga     127      26
19  25/ 24/ 51          Scopulos pluviae            G.Labarga     126       5
20  34/ 43/ 22                trick shot         John Metcalf     126      15

21  10/  7/ 84                Jedimp '88             inversed     112       0



From: KOTH <koth@koth.org>
Subject: KOTH.ORG: Status - MultiWarrior 94 02/06/06
Date: Mon, 6 Feb 2006 08:03:42 -0500 (EST)
Message-ID: <200602060503.k16531Ef010116@asgard.t-b-o-h.net>

			Weekly Status on  02/06/06
 
-=- irc.KOTH.org is up! Meetings held in #corewars
-=- Tons of new features on www.KOTH.org/koth.html pages
-=- *FAQ* page located at: www.KOTH.org/corewar-faq.html
 


Current Status of the KOTH.ORG Multiwarrior 94 CoreWar Hill:

Last battle concluded at : Sun Feb 5 20:10:27 EST 2006
 
 #                      Name               Author   Score     Age
 1           Fluffy Paper VI         Jens Gutzeit      42      24
 2                     Urgle         Daniel Rivas      37       4
 3       JustADirtyClearTest        Nenad Tomasev      36      53
 4    the price of hostility         John Metcalf      35      11
 5                   Gungnir         John Metcalf      27       6
 6         nameless fragment          S.Fernandes      25      23
 7 kingdom of the grasshoppe     simon wainwright      25     119
 8                   Diptera        Nenad Tomasev      25      38
 9              Simon Gruber             datagram      20      19
10            simply believe         John Metcalf      19       1

11                     xeper      Andreas Scholta       7       0



From: "Wayne Sheppard" <wayne.sheppard@gmail.com>
Subject: pmars docs
Date: 6 Feb 2006 08:09:30 -0800
Message-ID: <1139242170.386034.103200@g44g2000cwa.googlegroups.com>

I downloaded the pmarsv executable from http://www.koth.org/pmars/
But there was no documentation with it.  Also the debugger seemed to be
unresponsive in Windows XP.

What software works well under WinXP?
Where's the pmarsv documentation?



From: roy.van.rijn@gmail.com
Subject: Re: pmars docs
Date: 6 Feb 2006 09:35:05 -0800
Message-ID: <1139247305.334530.125440@g43g2000cwa.googlegroups.com>

I have no idea about pmars and documentation, I only use the server
version on XP. (also because pmarsv didn't work).

I suggest searching for and downloading CoreWin by Chip Wendel, its
probably the best windows mars. Great for debugging (imo)



From: "inversed" <reoser@mail.ru>
Subject: Re: pmars docs
Date: 6 Feb 2006 12:12:07 -0800
Message-ID: <1139256727.427275.101220@z14g2000cwz.googlegroups.com>

pmars.doc is here (it has appendix about pmarsv):
http://www.koth.org/pmars/pmars08.zip . I was able to run pMarsv in
WinXP through pTools shell. CoreWin2.2 is here:
http://www.geocities.com/corewin2/


From: "Jens Gutzeit" <jens@jgutzeit.de>
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 6 Feb 2006 13:56:29 -0800
Message-ID: <1139262989.323116.251850@g43g2000cwa.googlegroups.com>

Hi,

I think it is a nice idea and if we really get such a thing working,
I will be the first person to participate. Some remarks:

1. To make it easy we should restrict ourselves (for a start) to
the most basic things.

I like the idea of exchanging warriors between different populations,
which were created by different people. That would be such a
"basic thing".

2. I don't have much experience with evolving. Before we start,
I'd like to be sure, that "invasions of 5-10 warriors" is really sth.
useful.

3. The whole idea of exchaning warriors is based on trust. It would
be quite easy for me to submit say 20 imps and get 20 really good
evolved warriors back. So we should ask, whether it is useful to
implement some kind of rating system or similar.

4. Creating a little server script, which does all the distributing
stuff should be quite easy and I already think of creating one
as soon as the first versio of the protocol is finialized.

5. To make this thing work we need people. It would be nice to know
that at least 4 or 5 people are really, really, REALLY will use it
for a long while.

So far I count 1 person (me), Roy (???),????

6. For a start we need an easy to use and simple evolver. Any ideas?

Regards,

Jens Gutzeit :-)



From: sayembara@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 6 Feb 2006 14:17:07 -0800
Message-ID: <1139264227.609319.18570@f14g2000cwb.googlegroups.com>

This is a good idea and I am willing to take part evolving. Not much
skill in programming but always have untested ideas to share.

Evolvers/authors must using the same setup (e.g. same coresize,
processes, length, etc) to achieve maximum work-together. EvolveWars
can impose a standard setup to avoid nano hill mixing with tiny hill.
May be connecting as "Species A" (with other parameters set by
EvolveWars) is better and more flaxible than using the standard
"redcode-tiny"? I wish we could tackle 8000-core hill :)

Other challenge is how the invading warriors can be incorporated in the
current loop. Each evolver seems to have a different way of evolving,
different 'redcode' output and some don't even have a dynamic pool to
accept migrating warriors. Worst case, players have to use
EvolveWars-compatible programs.

The benefit of having one big evolver is the speed to discover new
strategies. I will patiently wait to see how the overall process will
look like.



From: "iapdk@admin.drake.edu" <iapdk@admin.drake.edu>
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 6 Feb 2006 15:14:12 -0800
Message-ID: <1139267652.062562.223730@g44g2000cwa.googlegroups.com>

> "redcode-tiny"? I wish we could tackle 8000-core hill :)

I just shared an idea with inversed which may be of interest.  Coresize
2000 supports imps of 667 and 1143.  If you shortened the cycles to
20000 as well you could emulate imps, launchers, and spl-dat wipers;
and probably turn up stuff that would apply to the 8000-core.

P. Kline



From: "Waknuk" <waknuk@yahoo.com>
Subject: Re: pmars docs
Date: 6 Feb 2006 20:42:27 -0800
Message-ID: <1139287347.494116.127440@o13g2000cwo.googlegroups.com>

Wayne Sheppard wrote:
> I downloaded the pmarsv executable from http://www.koth.org/pmars/
> But there was no documentation with it.  Also the debugger seemed to be
> unresponsive in Windows XP.
>
> What software works well under WinXP?
> Where's the pmarsv documentation?

Joona's SDL port of pmars is good for Windows (and X).
   http://www.cs.helsinki.fi/u/jpihlaja/cw/pmars-sdl/

Same debugger/scripts etc as you'd be used to with pmars.

Some docs for pmars can be found in .zip referenced by the
    "pMARS for DOS (386 and higher)"
download on the KOTH pmars page  http://www.koth.org/pmars/



From: sayembara@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 7 Feb 2006 02:32:10 -0800
Message-ID: <1139308330.521756.106640@g44g2000cwa.googlegroups.com>

> > "redcode-tiny"? I wish we could tackle 8000-core hill :)
>
> I just shared an idea with inversed which may be of interest.  Coresize
> 2000 supports imps of 667 and 1143.  If you shortened the cycles to
> 20000 as well you could emulate imps, launchers, and spl-dat wipers;
> and probably turn up stuff that would apply to the 8000-core.

It will tackle some of the areas but not all. That's why warrior
effective at tiny can't give a good challenge at standard and even
no-appearance at big hill (I may exaggerate here).
Let's see if inversed can adapt the same strategy to all tiny, standard
and big and yet gets good result :)

For nano, it is proven evolver is King. It is achievable at tiny hill
and in fact too many evovers attacking tiny hill. But evolver is way
too weak for standard hill. If this evolver produces good warrior for
8000 hill, that would be a good breakthrough.

/Zul Nadzri



From: roy.van.rijn@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 7 Feb 2006 05:40:12 -0800
Message-ID: <1139319612.759134.292290@o13g2000cwo.googlegroups.com>

The initial idea is just a big evolver that could run forever. Normal
evolvers have a top where there isn't any new code and they stall. But
if you have evolvers running seperatly, sometimes connecting, you keep
adding new code to the pool. Hopefully this will higher the ceiling of
the evolver(s).

To start with I suggest making it for 8000, the tiny and nano hill are
faster, but 8000 really takes advantage of the massive computing power
multible evolvers together have.
The idea is based on the island model, I got it just from reading The
Origin Of Species (which states that seperation/isolation sparks more
diverse and faster evolution). The microGP team found out just the same
thing with their evolver, you can find information about it in their
articles.



From: sayembara@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 7 Feb 2006 13:53:56 -0800
Message-ID: <1139349236.106698.258410@z14g2000cwz.googlegroups.com>

Island models described in MicroGP utilised a sharing of top warriors
i.e. top warriors from all islands are collected and copied to all
islands. In my opinion, this would be similar to modern world where
information can be shared faster...internet, tv, etc.
There is another model...'stepping stone' if I am not mistaken where
top warriors from island A travel to island B, top warriors from B
travel to C and so on completing the cycle. This will be like the old
exploration days where people can only get information from nearby
places from travellers etc but not from many locations at a time. I
have no data to support where each model works best.

In EvolveMars concept, since more 'islands' only appear when they are
connected, it will be more like the stepping stone model. Once
connected, the warriors shared with the 'server' and that's it until
another island connects.
It is better to have the 'island model' on each of the islands to even
speed up the evolution but that would be adjustment to some of the
evolvers.



From: roy.van.rijn@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 7 Feb 2006 15:04:44 -0800
Message-ID: <1139353484.532438.221740@o13g2000cwo.googlegroups.com>

Well, its pretty close to the island model as well isn't it then?
The idea was to copy the few best warriors to the other islands... the
big advantage is had is that you can still use it while offline, and
just connect when you like. (if you force sharing you can't do that) I
think thats the only difference...?



From: Andreas Scholta <andreas.scholta@gmail.com>
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: Wed, 08 Feb 2006 00:04:52 +0100
Message-ID: <87oe1idb3f.fsf@gmail.com>

sayembara@gmail.com writes:

> It is better to have the 'island model' on each of the islands to even
> speed up the evolution but that would be adjustment to some of the
> evolvers.
>

which is what I am doing with eve.

the only justification I see for a *general* "plug in your evolver here"
network protocol is given when different evolving methods are used on
individual islands. and even then it is, without a way to compare each
island's contribution to the total genepool rather moot. such a project
should in my opinion not be dedicated to evolving better warriors
quicker but to discover the means of getting there.

just my two cents


From: roy.van.rijn@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 8 Feb 2006 01:51:12 -0800
Message-ID: <1139392272.868961.185530@g43g2000cwa.googlegroups.com>

Update:

A message from Will (was talking to him on IRC but he can't access his
mail/the group).

Will's idea was instead of P2P or dedicated client-server this could
also be made using email or web.
Using for example SAL's existing email infrastructure or some web
submit form.

This is actually a good idea, for most languages its very easy to send
and retrieve (GET/POST) information on the internet. Maybe this is the
way to go..? It would be easy to save the warriors temporary in a sql
database, saving up to 100 warriors per node maybe. Clients can just
request new warriors from that database.

The problem here is to have a fixed way of submitting and retrieving
information, you don't want the whole warrior in one string that needs
to be parsed. Will also mentioned XML, maybe this is a good idea to
standardize?
It could combine the hills with the raiding party's, all in one...



From: "Xetro" <aldaya@gmail.com>
Subject: Doubt About CoreWar
Date: 8 Feb 2006 05:13:18 -0800
Message-ID: <1139404398.042583.237740@g47g2000cwa.googlegroups.com>

Hi
I'm a begginer in corewar, and I found information about it. But I have
a questions about it:

1 - The lastest version of CoreWar (Redcode) is the ICWS ' 94 ?

2 - How a warrior can get the control of the MARS ? --> the principle
of that.

Very thx for your help

XeTro



From: "elkauka" <kaukasius@yahoo.de>
Subject: yet another imp
Date: 8 Feb 2006 06:26:25 -0800
Message-ID: <1139408785.874377.286960@g43g2000cwa.googlegroups.com>

hi redcoders,

here is another imp variant which is yet completly useless, 'cause it
cant survive a simple dat-clear. nevertheless it is quite interessting
and maybe some of you guys can turn it into something usefull:

;redcode
;name 2pt-screwed-imp
;author elkauka

;any other setting of
; - postion of the imp-points
; - number of imp-points
;possible. though this might need a diffrent launcher :)

back	equ	1022 ;position of the back imp
front	equ	2421 ;position if the front imp
away	equ	354 ;boot launcher away

x	equ	(front-back)

	for 3
		mov.i	<boot,	{boot
	rof
	mov.i	b,	launch+away+back
	mov.i	f,	launch+away+front
boot	jmp	lOff+away+1,	lOff+1

launch	spl	#front,	#back
	spl	*launch
lOff	jmp	@launch

b	mov.i	x,	x+1
f	mov.i	-x,	-x+1
end


for a better style hear that:
http://www.djkeltech.com/video/Knight_Rider_Keltech_Johnny_B.wmv  while
watching the back-imp :P



From: "Mike5" <miha.vitorovic@gmail.com>
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 8 Feb 2006 07:25:03 -0800
Message-ID: <1139412303.879689.46210@z14g2000cwz.googlegroups.com>


roy.van.r...@gmail.com wrote:
> Update:
> Will's idea was instead of P2P or dedicated client-server this could
> also be made using email or web.
> Using for example SAL's existing email infrastructure or some web
> submit form.
>
> This is actually a good idea, for most languages its very easy to send
> and retrieve (GET/POST) information on the internet. Maybe this is the
> way to go..? It would be easy to save the warriors temporary in a sql
> database, saving up to 100 warriors per node maybe. Clients can just
> request new warriors from that database.

I'm so glad I saw this post now, because I'm just in the "slow" process
of writing my own Java evolver (I intend to put it on sourceforge, just
waiting for Subversion service). And I think I just added a new feature
to the TODO list :)

One thing though - IMO this protocol would need some sort a rating
feature (and a mechanism to rate wraaiors objectively), because I guess
you wouldn't want your "just-started-so-dumb-it-hurts" universe
infected with some "top-notch-totally-evolved" warriors, because then
you'd simply evolve those from then on, the would wipe out your
population entirely.

Or am I mistaken?

Cheers, Mike5



From: dhillismail@netscape.net
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 8 Feb 2006 07:40:42 -0800
Message-ID: <1139413242.259203.278750@g43g2000cwa.googlegroups.com>

       This is a good idea that comes up from time to time but never
quite reaches critical mass-so far! There is one policy decision that I
think you might want to address early on.
     What kinds of warriors are allowed: What is your working
definition of "evolved warrior"? The term is used for Alife
experiments restricted to very simple building blocks and operators,
but also to a lot of programs that liberally mix in hand written code
or have such heavily engineered operators that it amounts to much the
same thing.
      In Mantrap Arcade, I evolved the P3 table. About half the code is
evolved so maybe it's an evolved warrior and I should claim some
firsts ;-)  Really, it doesn't matter what I call it. But I think it
matters a lot that you shouldn't compare the performance of something
like that with Alife type experiments.
      If you go the Alife route, you will have serious contamination
issues. If you use a permissive policy, you'll face challenges
defining the difference between evolved and "optimized," and also
in measuring just what the GA is contributing. If you ignore the issue,
any Alife contributors are likely to get sandbagged and may feel that
the rules are changing in the middle of the game. Whatever you do,
people will not hesitate to make direct comparisons of your results and
those of others using completely different ground rules.
      As far as testing the performance of contributing evolvers: If
you like to look at evolved code, then when you publish your warriors
you will be setting yourself up for years of wry amusement as you see
trivial variations and even carbon copies unwittingly touted as success
stories for other projects.
Dave Hillis



From: "Judodudo" <judodudo@googlemail.com>
Subject: Re: Doubt About CoreWar
Date: 8 Feb 2006 07:43:32 -0800
Message-ID: <1139413412.786305.212730@g47g2000cwa.googlegroups.com>

Don't quite understand what you meant by question 2, but the latest
official set of rules is indeed ICWS '94. However, Corewar does have a
number of branches.



From: sayembara@gmail.com
Subject: Re: Doubt About CoreWar
Date: 8 Feb 2006 09:23:28 -0800
Message-ID: <1139419408.209466.310290@g47g2000cwa.googlegroups.com>

question 2:
if MARS = arena / coliseum, then
warrior = gladiator

warriors fight according to ICWS 94 rules by the simulator (mars).



From: sayembara@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 8 Feb 2006 09:42:08 -0800
Message-ID: <1139420528.246232.279390@f14g2000cwb.googlegroups.com>

Looking forward, here comes my other opinion:

I agree with the temporary storage of warrior and I would need to get
evolver such as EVE. Since the 'bank' will only be accesses
occasionally, it can be ranked once in a while and players can take the
top X% out of 100 warriors when in connection. The ranking can be
either among the evolved warriors or against a strong benchmark hill.
Minor, or no, adaptation to your own hill is needed if all evolver have
uniform parameters (but how it evolving surely not the same).

Regarding bank contamination with designed warriors or optimized
warriors, I don't have any clue. If the evolved warriors are better
than the hand-made warrior, then may be it won't have much impact to
the cycle. Looks like we can't control this except to respect each
other and follow the imposed rules.



From: roy.van.rijn@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 8 Feb 2006 11:03:47 -0800
Message-ID: <1139422012.250664.39440@g44g2000cwa.googlegroups.com>

When you first start the evolver a lot of invaders will probably
quickly take control of your 'island'. Thats true, but it also depends
on the way you breed warriors, if you compare warriors and don't let
warriors that are too different breed (like in nature) its a very good
method preserving new code.

Contamination from warriors that have been made by hand is always
possible, but that will just greatly increase the efficiency. Like said
before, even if you partially evolve warriors they can be better then
handmade warriors..

Its just something we have to think about, how are we going to use it
and how do we set it up?



From: roy.van.rijn@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 8 Feb 2006 11:03:00 -0800
Message-ID: <1139422056.965202.56890@f14g2000cwb.googlegroups.com>

When you first start the evolver a lot of invaders will probably
quickly take control of your 'island'. Thats true, but it also depends
on the way you breed warriors, if you compare warriors and don't let
warriors that are too different breed (like in nature) its a very good
method preserving new code.

Contamination from warriors that have been made by hand is always
possible, but that will just greatly increase the efficiency. Like said
before, even if you partially evolve warriors they can be better then
handmade warriors..

Its just something we have to think about, how are we going to use it
and how do we set it up?



From: "Robert Macrae" <ff95@dial.pipex.com>
Subject: Re: Imp Trap
Date: Wed, 8 Feb 2006 12:31:25 -0500 (EST)
Message-ID: <006701c62cc5$dcb35ec0$2200a8c0@Mesh1>

> Even if you have a perfect gate and a 1c wiper like Dclear the imps
> will not all reach it.  But if one of them does, why not recruit him to
> wipe his brothers?  An imp does not die on the gate, it dies on the
> following instruction because it is unable to write past the gate. So,
> recruit that process and put him to work:
>
> trap    spl    #0    ,0
>        add.ab #381  ,1       ; spiral wipe for 3,7 point imps
>        djn.b  -1    ,20      ; wipe once through core
>        mov.i  #0    ,-1      ; mov-wipe the trap
>        dat    0     ,0       ; die

Nice idea.  One potential problem is the increased profile, and risk the
gate is overwritten with something that makes your main warrior self wipe, 
but sometimes that won't matter.

SPL #0 may not split fast enough to help much against heavy imps; if there
are 100 other process out there then the SPL only executes 1% of the time
and may never build up enough processes to cover core.

Perhaps something like

trap    add.ab #380  , loop       ; spiral wipe for 3,7 point imps
loop   spl trap,  20
          mov.i  die,    >loop
          jmp  loop  ,0
die     dat    0     ,0

Not tested, but objectives are to split fast enough to saturate, spiral bomb
with few gaps and then self-wipe.  Unfortunately this approach adds another
potential problem -- it may take something like 32K cycles to die.  That
first process better arrive quite quickly...

Robert 



From: "iapdk@admin.drake.edu" <iapdk@admin.drake.edu>
Subject: Re: Imp Trap
Date: 8 Feb 2006 13:21:29 -0800
Message-ID: <1139433689.382324.191210@f14g2000cwb.googlegroups.com>

 -- it may take something like 32K cycles to die.  That
> first process better arrive quite quickly...

They don't.  They can't arrive until your spl-dat wiper has killed off
all the non-imp processes and one of the imps reaches the gate.  So it
is more important that the trap do a very fast wipe than that it build
processes.  Against paper-imps I found that there are not all that many
processes in the imps after all.  There are just a lot of them.

Another version is to have the imp trigger your spl-dat wiper to using
a dat <5334,<2667 wipe.  Like:

gate    dat   0,x
flag    dat   {wipe+1,{1
           dat  <5336,<2668
wipe    dat  1       ,12
sp         spl  #0     ,12
           mov *wipe ,>gate
           mov *wipe ,>gate
           djn.f  -2     ,}sp

This is the spl-dat wipe from Geist.  When the imp process dies on the
flag it decrements 'wipe' to point at the imp-killing instruction.
Note that because Geist does an F-decrement once through, all the
values before sp have to be incremented by 1.  And the self-a-decrement
on flag is necessary because more than one imp process may land there.

I tried this in one of my trials and it did gain 8-9 % more wins
against imp programs, but lost more than that to scanners, so I left it
out.

P. Kline



From: roy.van.rijn@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 8 Feb 2006 17:05:57 -0800
Message-ID: <1139447157.297272.224760@g47g2000cwa.googlegroups.com>

Sorry guys, pressed the submit button twice (impatient)

brx suggested this on IRC:
"how about giving EvolveWars more of a gamelike aspect. like having the
evolvers battle for control over hills inside the network."

This could be a sub-useage for the protocol, but the main reason I want
to make it is to exchange code... humans have been 'stealing' (getting)
ideas and code for years now, evolver always start from scratch...!
I don't think there is anybody in the world today who can, without
knowing the strategies and tricks used in warriors on the current
hills, make a warrior that is competetive... just by knowing the rules
of the CW language.

The known ideas and coding tricks are what makes the warriors better
and better, and evolvers don't have that. Some evolvers now take basic
warrior-layouts (genes) or look at code distribution, but the best way
to be more competetive with humans is IMO if evolvers too start sharing
code with eachother.

Just my two cents while being a bit drunk and sleepy late at night...
:)



From: "Mike5" <miha.vitorovic@gmail.com>
Subject: Re: Doubt About CoreWar
Date: 9 Feb 2006 01:12:03 -0800
Message-ID: <1139476323.458076.284590@g43g2000cwa.googlegroups.com>

Also, the warrior doesn't get control of MARS. The warrior that
survives all other warriors wins. The warrior is killed by executing an
"illegal" instruction (DAT), which is usually a result of some other
warrior modifying it in such a way that it executes an illegal
instruction.

That is all there is to it.

Cheers, Mike5



From: sayembara@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 9 Feb 2006 02:35:05 -0800
Message-ID: <1139481305.301612.323970@f14g2000cwb.googlegroups.com>

evolving will take very long duration at current capacity. There will
be virtually no Qscan or pspace in evolver world. We are expecting some
sort of scanners or dwarves / bombers or papers. These strategies are
then optimised or incorporate with other design externally.

if a hill is getting bombarded with the current or compatible nop-hill
warriors, I believe the population will be the exact carbon copy of the
nop-hill warriors with slim chance of new evolved warriors to
participate. This is my concern on external warriors -- we are looking
for new strategies but end up with warriors that already exist.

BTW, positively thinking on EvolveMars future, we should start with
general process flow if you want some input from other players. Better
if recorded somewhere for progress review. Otherwise, I will wait until
someone announce the readyness of the trial system.

/Zul Nadzri



From: "Robert Macrae" <ff95@dial.pipex.com>
Subject: Re: Imp Trap
Date: Thu, 9 Feb 2006 10:11:00 -0500 (EST)
Message-ID: <00c901c62d71$0f8a8b10$2200a8c0@Mesh1>

>>  That first process better arrive quite quickly...
>
> They don't.  They can't arrive until your spl-dat wiper has killed off
> all the non-imp processes and one of the imps reaches the gate.  So it
> is more important that the trap do a very fast wipe than that it build
> processes.  Against paper-imps I found that there are not all that many
> processes in the imps after all.  There are just a lot of them.

I seem to remember 100+ processes was reasonably typical?  Obviously it 
depends on what launched them, but a good gate should kill any heavy single 
spiral soon after it's first process falls into the pit so I'd expect the 
trap to be useful mainly against paper-launched imps.

> Another version is to have the imp trigger your spl-dat wiper to using
> a dat <5334,<2667 wipe.  Like:
...
> I tried this in one of my trials and it did gain 8-9 % more wins
> against imp programs, but lost more than that to scanners, so I left it
> out.

Neat.  Definitely a component to add to the palette 8-)

Robert 



From: "Jens Gutzeit" <jens@jgutzeit.de>
Subject: Score Surfaces - The Difference between djn.f and jmp
Date: 10 Feb 2006 03:29:14 -0800
Message-ID: <1139570954.621127.18930@o13g2000cwo.googlegroups.com>

Hi,

today the first score surface, which has been calculated with DiSSC,
was completed. You can find it at

http://corewars.jgutzeit.de/score_surfaces/yap_jmp/index.en.html

Altough it looks very similar to the existing score surfaces of YAP,
it has some nice properties. I have taken YAP and replaced the djn.f
in the backend silk with a jmp.Now we can see, which impact this
has on the performance of the paper. For more information, please go to

http://corewars.jgutzeit.de/score_surfaces/yap_jmp/muskrat.en.html

Almost 70 % percent of the score surface has been calculated by brx
(58.6 %) and Roy (11.3%). THANKS A LOT :-) As usual you can download
the score surface and the raw data from my homepage.

In the next score surface to come I have changed the backend silk
of YAP again and replaced the djn.f with a jmz.a . But it will take
some days before that surface is complete.

During the next week I won't have much time and there won't be
any updates to my pages about score surfaces. It would be nice,
if you would continue to calculate new patches for the score
surfaces though :-)

Regards,

Jens Gutzeit :-)



Message-ID: <games/corewar-faq_1139721973@rtfm.mit.edu>
From: anton@paradise.net.nz (Anton Marsden)
Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ)
Date: 12 Feb 2006 05:26:33 GMT

Archive-name: games/corewar-faq
Last-Modified: September 4, 1999
Version: 4.2
URL: http://homepages.paradise.net.nz/~anton/cw/corewar-faq.html
Copyright: (c) 1999 Anton Marsden
Maintainer: Anton Marsden <anton@paradise.net.nz>
Posting-Frequency: once every 2 weeks

Core War Frequently Asked Questions

(rec.games.corewar FAQ)

These are the Frequently Asked Questions (and answers) from the Usenet
newsgroup rec.games.corewar. A plain text version of this document is posted
every two weeks. The latest hypertext version is available at
http://homepages.paradise.net.nz/~anton/cw/corewar-faq.html and the latest
plain text version is available at
http://homepages.paradise.net.nz/~anton/cw/corewar-faq.txt.

This document is currently being maintained by Anton Marsden
(anton@paradise.net.nz).

Last modified: Sat Sep 4 00:22:22 NZST 1999
  ------------------------------------------------------------------------

To Do

   * Add the new No-PSpace '94 hill location
   * Add online location of Dewdney's articles
   * Make question 17 easier to understand. Add a state diagram?
   * Add info about infinite hills, related games (C-Robots, Tierra?, ...)
   * New question: How do I know if my warrior is any good? Refer to
     beginners' benchmarks, etc.
   * Add a Who's Who list?
   * Would very much like someone to compile a collection of the
     "revolutionary" warriors so that beginners can see how the game has
     developed over the years. Mail me if interested.

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

What's New

   * Changed primary location of FAQ (again!)
   * Changed Philip Kendall's home page address.
   * Updated list server information
   * Changed primary location of FAQ
   * Vector-launching code was fixed thanks to Ting Hsu.
   * Changed the location of Ryan Coleman's paper (LaunchPad -> Launchpad)
   * Changed pauillac.inria.fr to para.inria.fr

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

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. Core War has changed since Dewdney's articles. Where do I get a copy of
     the current instruction set?
  5. What is ICWS'94? Which simulators support ICWS'94?
  6. What is the ICWS?
  7. What is Core Warrior?
  8. Where are the Core War archives?
  9. Where can I find a Core War system for ...?
 10. Where can I find warrior code?
 11. I do not have FTP. How do I get all this great stuff?
 12. I do not have access to Usenet. How do I post and receive news?
 13. Are there any Core War related WWW sites?
 14. What is KotH? How do I enter?
 15. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core?
 16. How does SLT (Skip if Less Than) work?
 17. What is the difference between in-register and in-memory evaluation?
 18. What is P-space?
 19. What does "Missing ;assert .." in my message from KotH mean?
 20. How should I format my code?
 21. Are there any other Core War related resources I should know about?
 22. What does (expression or term of your choice) mean?
 23. Other questions?

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

1. What is Core War?

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 standardised by the ICWS, and is therefore transportable between
all standard Core War systems.

The system in which the programs run is quite simple. The core (the memory
of the simulated computer) is a continuous array of instructions, empty
except for the competing programs. The core wraps around, so that after the
last instruction comes the first one again.

There are no absolute addresses in Core War. That is, the address 0 doesn't
mean the first instruction in the memory, but the instruction that contains
the address 0. The next instruction is 1, and the previous one obviously -1.
However, all numbers are treated as positive, and are in the range 0 to
CORESIZE-1 where CORESIZE is the amount of memory locations in the core -
this means that -1 would be treated as CORESIZE-1 in any arithmetic
operations, eg. 3218 + 7856 = (3218 + 7856) mod CORESIZE. Many people get
confused by this, and it is particularly important when using the SLT
instruction. Note that the source code of a program can still contain
negative numbers, but if you start using instructions like DIV #-2, #5 it is
important to know what effect they will have when executed.

The basic unit of memory in Core War is one instruction. Each Redcode
instruction contains three parts:

   * the opcode
   * the source address (a.k.a. the A-field)
   * the destination address (a.k.a. the B-field)

The execution of the programs is equally simple. The MARS executes one
instruction at a time, and then proceeds to the next one in the memory,
unless the instruction explicitly tells it to jump to another address. If
there is more than one program running, (as is usual) the programs execute
alternately, one instruction at a time. The execution of each instruction
takes the same time, one cycle, whether it is MOV, DIV or even DAT (which
kills the process).

Each program may have several processes running. These processes are stored
in a task queue. When it is the program's turn to execute an instruction it
dequeues a process and executes the corresponding instruction. Processes
that are not killed during the execution of the instruction are put back
into the task queue. Processes created by a SPL instruction are added to the
task queue after the creating process is put back into the task queue.

[ToC]
  ------------------------------------------------------------------------

2. Is it "Core War" or "Core Wars"?

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.

[ToC]
  ------------------------------------------------------------------------

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

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:

                                                                Library of
  Author         Title         Published          ISBN           Congress
                                                                Call Number
           The Armchair
 Dewdney,  Universe: An       New York: W.                     QA76.6 .D517
 A. K.     Exploration of     H. Freeman �0-7167-1939-8        1988
           Computer Worlds    1988
           The Magic                      0-7167-2125-2
 Dewdney,  Machine: A         New York: W.(Hardcover),         QA76.6
 A. K.     Handbook of        H. Freeman �0-7167-2144-9        .D5173 1990
           Computer Sorcery   1990        (Paperback)

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. For those who are interested, Dewdney has a home page at
http://www.csd.uwo.ca/faculty/akd/.

[ToC]
  ------------------------------------------------------------------------

4. Core War has changed since Dewdney's articles. Where do I get a copy of
the current instruction set?

A draft of the official standard (ICWS'88) is available as
ftp://www.koth.org/corewar/documents/standards/redcode-icws-88.Z. This
document is formatted awkwardly and contains ambiguous statements. For a
more approachable intro to Redcode, take a look at Mark Durham's tutorials,
ftp://www.koth.org/corewar/documents/tutorial.1.Z and
ftp://www.koth.org/corewar/documents/tutorial.2.Z.

Steven Morrell has prepared a more practically oriented Redcode tutorial
that discusses different warrior classes with lots of example code. This and
various other tutorials can be found at http://www.koth.org/papers.html.

Even though ICWS'88 is still the "official" standard, you will find that
most people are playing by ICWS'94 draft rules and extensions.

[ToC]
  ------------------------------------------------------------------------

5. What is ICWS'94? Which simulators support ICWS'94?

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 new
addressing modes 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 at ftp://www.koth.org/corewar/documents/icws94.0202.Z for more
information. There is a HTML version of this document available at
http://www.koth.org/info/icws94.html. 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://www.koth.org/corewar. Note that Redcoder only
supports a subset of ICWS'94.

[ToC]
  ------------------------------------------------------------------------

6. What is the ICWS?

About one year after Core War first appeared in Scientific American, 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 no
longer active.

[ToC]
  ------------------------------------------------------------------------

7. What is Core Warrior?

Following in the tradition of the Core War News Letter, Push Off, and The 94
Warrior, Core Warrior is a newsletter about strategies and current standings
in Core War. Started in October 1995, back issues of Core Warrior (and the
other newsletters) are available at http://para.inria.fr/~doligez/corewar/.
There is also a Core Warrior index page at
http://www.kendalls.demon.co.uk/pak21/corewar/warrior.html which has a
summary of the contents of each issue of Core Warrior. Many of the earlier
issues contain useful information for beginners.

[ToC]
  ------------------------------------------------------------------------

8. Where are the Core War archives?

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 ftp://ftp.csua.berkeley.edu/pub/corewar.
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.

This site is mirrored at:

   * http://www.koth.org/corewar/
   * ftp://www.koth.org/corewar/
   * ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/mirror

The plain text version of this FAQ is automatically archived by news.answers
(but this version is probably out-of-date).

[ToC]
  ------------------------------------------------------------------------

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

Core War systems are available via anonymous FTP from www.koth.org in the
corewar/systems directory. Currently, there are UNIX, IBM PC-compatible,
Macintosh, and Amiga Core War systems available there. It is a good idea to
check ftp://www.koth.org/corewar/incoming for program updates first.

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 www.koth.org. Generally, the older the program - the less likely
it will be ICWS compatible.

If you are looking for an ICWS'94 simulator, get pMARS, which is available
for many platforms and can be downloaded from:

   * ftp://ftp.csua.berkeley.edu/pub/corewar (original site)
   * ftp://www.koth.org/corewar (koth.org mirror)
   * ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/mirror (Planar
     mirror)
   * http://www.nc5.infi.net/~wtnewton/corewar/ (Terry Newton)
   * ftp://members.aol.com/ofechner/corewar (Fechter)

Notes:

   * If you have trouble running pMARS with a graphical display under Win95
     then check out http://www.koth.org/pmars.html which should have a
     pointer to the latest compilation of pMARS for this environment.
   * RPMs for the Alpha, PowerPC, Sparc and i386 can be found at
     ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/pmars-rpm/

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 www.koth.org:
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

pvms08.zip              pMARS v0.8 for VMS build files/help (req.
                        pmars08s.zip)
ApMARS03.lha            pMARS executable for Amiga (port of version 0.3.1)
wincor11.zip            MS-Windows system, shareware ($15)

[ToC]
  ------------------------------------------------------------------------

10. Where can I find warrior code?

To learn the game, it is a good idea to study previously posted warrior
code. The FTP archives have code in the ftp://www.koth.org/corewar/redcode
directory. A clearly organized on-line warrior collection is available at
the Core War web sites (see below).

[ToC]
  ------------------------------------------------------------------------

11. I do not have FTP. How do I get all this great stuff?

There is an FTP email server at bitftp@pucc.princeton.edu. This address may
no longer exist. I haven't tested it yet. Send email with a subject and body
text of "help" (without the quotes) for more information on its usage. Note
that many FTP email gateways are shutting down due to abuse. To get a
current list of FTP email servers, look at the Accessing the Internet by
E-mail FAQ posted to news.answers. If you don't have access to Usenet, you
can retrieve this FAQ one of the following ways:

   * Send mail to mail-server@rtfm.mit.edu with the body containing "send
     usenet/news.answers/internet-services/access-via-email".
   * Send mail to mailbase@mailbase.ac.uk with the body containing "send
     lis-iis e-access-inet.txt".

[ToC]
  ------------------------------------------------------------------------

12. I do not have access to Usenet. How do I post and receive news?

To receive rec.games.corewar articles by email, join the COREWAR-L list run
on the Koth.Org list processor. To join, send the message

     SUB COREWAR-L FirstName LastName

to listproc@koth.org. You can send mail to corewar-l@koth.org to post even
if you are not a member of the list. Responsible for the listserver is Scott
J. Ellentuch (ttsg@ttsg.com).

Servers that allow you to post (but not receive) articles are available.
Refer to the Accessing the Internet by E-Mail FAQ for more information.

[ToC]
  ------------------------------------------------------------------------

13. Are there any Core War related WWW sites?

You bet. Each of the two KotH sites sport a world-wide web server.
Stormking's Core War page is http://www.koth.org; pizza's is
http://www.ecst.csuchico.edu/~pizza/koth . Damien Doligez (a.k.a. Planar)
has a web page that features convenient access to regular newsletters (Push
Off, The '94 Warrior, Core Warrior) and a well organized library of
warriors: http://para.inria.fr/~doligez/corewar/. Convenient for U.S. users,
this site is also mirrored at koth.org.

[ToC]
  ------------------------------------------------------------------------

14. What is KotH? How do I enter?

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@koth.org is maintained by Scott J. Ellentuch
(tuc@ttsg.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

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

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

     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
     daemon and you won't get mail back. Using ";name" is mandatory on the
     Pizza hills.

     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-94, ;redcode-b, ;redcode-lp, ;redcode-x,
     ;redcode, ;redcode-94x or ;redcode-94m. The former four run at "pizza",
     the latter three at "stormking". More information on these hills is
     listed below.

   * Mail this file to koth@koth.org or pizza@ecst.csuchico.edu. "Pizza"
     requires a subject of "koth" (use the -s flag on most mailers).

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

   * 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 25 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 25 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.

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.

                                          Duration  Max.
     Hill Name      Hill  Core    Max.     Before  Entry     Min.   Rounds   Instr.
                    Size  Size Processes                   Distance Fought    Set
                                            Tie    Length
 Pizza's ICWS '94
 Draft Hill                                                                 Extended
 (Accessed with       25  8000       8000    80000    100       100     200 ICWS '94
 ";redcode-94")                                                             Draft
 Pizza's Beginner's                                                         Extended
 Hill (Accessed       25  8000       8000    80000    100       100     200 ICWS '94
 with ";redcode-b")                                                         Draft
 Pizza's
 Experimental                                                               Extended
 (Small) Hill         25   800        800     8000     20        20     200 ICWS '94
 (Accessed with                                                             Draft
 ";redcode-x")
 Pizza's Limited
 Process (LP) Hill                                                          Extended
 (Accessed with       25  8000          8    80000    200       200     200 ICWS '94
 ";redcode-lp")                                                             Draft
 Stormking's ICWS
 '88 Standard Hill
 (Accessed with       20  8000       8000    80000    100       100     250 ICWS '88
 ";redcode")
 Stormking's ICWS
 '94 No Pspace Hill
 (Accessed with       20  8000       8000    80000    100       100     250 ICWS '94
 ";redcode-94nop")
 Stormking's ICWS
 '94 Experimental                                                           Extended
 (Big) Hill           20 55440      55440   500000    200       200     250 ICWS '94
 (Accessed with                                                             Draft
 ";redcode-94x")
 Stormking's ICWS
 '94 Multi-Warrior                                                          Extended
 Hill (Accessed       10  8000       8000    80000    100       100     200 ICWS '94
 with                                                                       Draft
 ";redcode-94m")

Note: Warriors on the beginner's hill are retired at age 100.

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.

At "pizza", you can use ";redcode[-??] test" to do a test challenge of the
Hill without affecting the status of the Hill. These challenges can be used
to see how well your warrior does against the current Hill warriors.

All hills run portable MARS (pMARS) version 0.8, a platform-independent Core
War system available at www.koth.org.

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

   * LDP - Load P-Space
   * STP - Store P-Space
   * 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

[ToC]
  ------------------------------------------------------------------------

15. 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 (in source
code) under ICWS'88 rules and strictly compliant assemblers (such as KotH or
pmars -8) will not let you have a DAT 0, 0 instruction in your source code -
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.

[ToC]
  ------------------------------------------------------------------------

16. 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 (core 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.

[ToC]
  ------------------------------------------------------------------------

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

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.

[ToC]
  ------------------------------------------------------------------------

18. What is P-space?

P-space is an area of memory which only your program's processes can access.
The contents of each memory location are preserved between rounds in a
multi-round match.

P-space is in many ways different from the core. First of all, each P-space
location can only store one number, not a whole instruction. Also, the
addressing in P-space is absolute, ie. the P-space address 1 is always 1
regardless of where in the core the instruction containing it is. And last
but not least, P-space can only be accessed by two special instructions, LDP
and STP.

The syntax of these two instructions is a bit unusual. STP, for example, has
an ordinary value in the core as its source, which is put into the P-space
field pointed to by the destination. So the P-space location isn't
determined by the destination address, but by its value, ie. the value that
would be overwritten if this were a MOV. So STP.AB #Q, #R would put the
value Q into the P-space field R mod PSPACESIZE. Similarly,

        stp.b  2, 3
        dat    0, 0
        dat    0, 9
        dat    0, 7

would put the value 9 into the P-space field 7. LDP works the same way,
except that now the source is a P-space field and the destination a core
instruction. The P-space location 0 is a special location. It is initialised
to a special value before each round. This value is:

   * -1 (or CORESIZE-1) at the beginning of the first round
   * 0 if the program died in the previous round
   * The number of surviving programs if the program did not die in the
     previous round

This means that for one-on-one matches, loss=0, win=1 and tie=2.

The default size of P-space is 1/16 of the core size. This size is the value
of the predefined variable PSPACESIZE. The addresses in the P-space wrap
around just like in the core, ie. you can store a value from 0 to CORESIZE-1
in each P-space location. All P-space values (except for location 0) are 0
initially.

[ToC]
  ------------------------------------------------------------------------

19. What does "Missing ;assert .." in my message from KotH mean?

This means you have omitted an ";assert" line in your submission. ";assert"
is used to specify which environments your code will work under or was
designed for. For example, if your warrior was written for the '94 draft
hill then you can put:

;assert CORESIZE==8000

in your code, meaning that an error will occur if you attempt you compile
the code for a different core size. If you don't want to use the features of
";assert" and you want to get rid of the annoying warning just put:

;assert 1

in your code, which means it will compile unconditionally.

[ToC]
  ------------------------------------------------------------------------

20. How should I format my code?

The way you format your code is really your own choice in the end. If you
are new to the game then use the style you feel most comfortable with.
However, using a common format helps others to understand your code quicker.
Most players tend to use the following conventions when writing code:

   * use lower case for location names and opcode names
   * don't add opcode modifiers if you don't need to, eg. add.ab #1, #2 is
     the same as add #1, #2
   * use whitespace after every comma
   * use tabs to align the opcodes, the instruction field(s) and any
     comments
   * do not use $ (direct addressing mode) or : (suffix of some labels)

[ToC]
  ------------------------------------------------------------------------

21. Are there any other Core War related resources I should know about?

Using genetic algorithms to generate warriors has been attempted by a number
of people. There are a number of resources available for people who are
interested in doing some experimentation:

   * There is a Core War genetic algorithms mailing list at
     corewar-ga-request@sunsite.auc.dk. The FTP site for this list is at
     ftp://sunsite.auc.dk/pub/local/corewar/. The administrator is Martin
     Pedersen (martin.pedersen@person.dk).
   * Jason's Core War project page
     (http://www.avalon.net/~jboer/projects/corewar/corewar.html) contains a
     C program which can evolve warriors, along with some previously
     generated warriors.
   * Core Wars Genetics: The Evolution of Predation by John Perry can be
     found at http://www.koth.org/evolving_warriors.html.
   * The most recent paper on Core War evolution is by Ryan Coleman and can
     be found at
     http://www.geocities.com/CapeCanaveral/Launchpad/6898/paper.html.

[ToC]
  ------------------------------------------------------------------------

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

(References to an X-like program mean that the term X is derived from the
specific program X and has become a generic term).

Binary launch
     One of several means to start an imp-spiral running. The fastest launch
     technique, but requires the most code. See also JMP/ADD Launch and
     Vector Launch.

         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

Bootstrapping
     Strategy of copying the active portion of the program away from the
     initial location, leaving a decoy behind and making the relocated
     program as small as possible.

B-Scanners
     Scanners which only recognize non-zero B-fields.

         example   add #10, scan
         scan      jmz example, 10

c
     Measure of speed, equal to one location per cycle. Speed of light.

CMP-Scanner
     A Scanner which uses a CMP instruction to look for opponents.

         example   add step, scan
         scan      cmp 10, 30
                   jmp attack
                   jmp example
         step      dat #20, #20

Colour
     Property of bombs making them visible to scanners, causing them to
     attack useless locations, thus slowing them down.

         example   dat #100

Core-Clear
     Code that sequentially overwrites core with DAT instructions; usually
     the last part of a program.

Decoys
     Bogus or unused instructions meant to slow down scanners. Typically,
     DATs with non-zero B-fields.

Decrement Resistant
     Property of warriors making them functional (or at least partially
     functional) when overrun by a DJN-stream.

DJN-Stream (also DJN-Train)
     Using a DJN command to rapidly decrement core locations.

         example   ...
                   ...
                   djn example, <4000

Dwarf
     The prototypical small bomber.

Gate-busting (also gate-crashing)
     technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0,
     2668) with a standard one to overrun imp-gates.

Hybrids
     warriors that combine two or more of the basic strategies, either in
     sequence (e.g. stone->paper) or in parallel (e.g. imp/stone).

Imp
     Program which only uses the MOV instruction.

         example   mov 0, 1

     or

         example   mov 0, 2
                   mov 0, 2

Imp-Gate
     A location in core which is bombed or decremented continuously so that
     an Imp can not pass. Also used to describe the program-code which
     maintains the gate.

         example   ...
                   ...
                   spl 0, <example
                   dat <example, #0

Imp-Ring
     A minimal Imp-Spiral.

         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

Imp-Spiral
     An Imp-like program with two or more processes supporting each other. A
     three-point spiral, with six processes running in this sequence:

         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

Incendiary Bomb
     A type of Stun bomb which creates a SPL 0 carpet.

         example   spl 0, 8
                   mov -1, <-1

JMP/ADD Launch
     one of several means to start an imp-spiral running. The slowest launch
     technique, but requires the least code. See also Binary Launch and
     Vector Launch.

         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

Mirror
     see reflection.

On-axis/off-axis
     On-axis scanners compare two locations M/2 apart, where M is the memory
     size. Off-axis scanners use some other separation.

Optimal Constants
     (also optima-type constants) Bomb or scan increments chosen to cover
     core most effectively, i.e. leaving gaps of uniform size. Programs to
     calculate optimal constants and lists of optimal numbers are available
     at www.koth.org.

Paper
     A Paper-like program is one which replicates itself many times. Part of
     the Scissors (beats) Paper (beats) Stone (beats Scissors) analogy.

P-Warrior
     A warrior which uses the results of previous round(s) in order to
     determine which strategy it will use.

Pit-Trapper
     (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.

Q^2 Scan
     A modern version of the Quick Scan where anything found is attacked
     almost immediately.

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:

          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

Reflection
     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:

                 spl   1
                 mov   -1, 0
                 spl   1                ;generate 6 consecutive processes
         silk    spl   3620,   #0       ;split to new copy
                 mov   >-1, }-1      ;copy self to new location
                 mov   bomb,   >2000 ;linear bombing
                 mov   bomb,   }2042    ;A-indirect bombing for anti-vamp
                 jmp   silk,   {silk    ;reset source pointer, make new copy
         bomb    dat   >2667,  >5334  ;anti-imp bomb

Slaver
     see Pit-Trapper.

Stealth
     Property of programs, or program parts, which are invisible to
     scanners, accomplished by using zero B-fields and reflections.

Stone
     A Stone-like program designed to be a small bomber. Part of the
     Paper-Scissors-Stone analogy.

Stun
     A type of bomb which makes the opponent multiply useless processes,
     thus slowing it down. Example is referred to as a SPL-JMP bomb.

         example    spl   0
                    jmp   -1

Two-Pass Core-Clear (also SPL/DAT Core-Clear)
     core clear that fills core first with SPL instructions, then with DATs.
     This is very effective in killing paper and certain imp-spiral
     variations.

Vampire
     see Pit-Trapper.

Vector Launch
     one of several means to start an imp-spiral running. As fast as Binary
     Launch, but requiring much less code. See also JMP/ADD Launch and
     Binary Launch. This example is one form of a Vector Launch:

         sz      EQU   2667

                 spl   1
                 spl   1
                 jmp   @vt, }0
         vt      dat   #0, imp+0*sz ; start of vector table
                 dat   #0, imp+1*sz
                 dat   #0, imp+2*sz
                 dat   #0, imp+3*sz ; end of vector table
         imp     mov.i #0, sz

[ToC]
  ------------------------------------------------------------------------

23. Other questions?

Just ask in the rec.games.corewar newsgroup or contact me. If you are shy,
check out the Core War archives first to see if your question has been
answered before.

[ToC]
  ------------------------------------------------------------------------

Credits

Additions, corrections, etc. to this document are solicited. Thanks in
particular to the following people who have contributed major portions of
this document:

   * Mark Durham (wrote the original version of the FAQ)
   * Paul Kline
   * Randy Graham
   * Stefan Strack (maintained a recent version of the FAQ)

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

Copyright � 1999 Anton Marsden.

Verbatim copying and distribution of this entire article is permitted in any
medium, provided this notice is preserved.
  ------------------------------------------------------------------------


From: KOTH <koth@koth.org>
Subject: KOTH.ORG: Status - Standard 02/13/06
Date: Mon, 13 Feb 2006 07:13:36 -0500 (EST)
Message-ID: <200602130500.k1D500pn061373@asgard.t-b-o-h.net>

			Weekly Status on  02/13/06
 
-=- irc.KOTH.org is up! Meetings held in #corewars
-=- Tons of new features on www.KOTH.org/koth.html pages
-=- *FAQ* page located at: www.KOTH.org/corewar-faq.html
 


Current Status of the KOTH.ORG Standard KotH CoreWar Hill :

Last battle concluded at : Wed Feb 1 14:59:46 EST 2006
 
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  34/ 24/ 43                      Test Alexander (Sasha) Wa     144     178
 2  38/ 36/ 26                My 1st try    Christian Schmidt     140      70
 3  34/ 29/ 37         The Next Step '88        David Houston     140      54
 4  31/ 25/ 44            The Hurricaner            G.Labarga     137      25
 5  30/ 23/ 47                      test            G.Labarga     137      21
 6  30/ 24/ 46                  Guardian          Ian Oversby     136     238
 7  31/ 27/ 41           SoundOfDarkness        Nenad Tomasev     135       2
 8  37/ 40/ 23                  Moonwipe    Christian Schmidt     134      35
 9  42/ 49/  9                Replihater        Some Redcoder     134       9
10  38/ 42/ 19              Scan the Can    Christian Schmidt     134      19
11  40/ 47/ 14              Speeed 88mph    Christian Schmidt     133      38
12  32/ 31/ 37                  The Seed         Roy van Rijn     132      56
13  23/ 15/ 61               Utterer '88    Christian Schmidt     131      13
14  36/ 41/ 23                      July        Nenad Tomasev     131      11
15  39/ 48/ 13             Scan Test C 6        Steve Gunnell     131      77
16  38/ 46/ 16                    Kraken        Nenad Tomasev     129       1
17  30/ 31/ 40                    A.I.P.    Christian Schmidt     128      46
18  20/ 13/ 67                 IMParable            G.Labarga     127      26
19  25/ 24/ 51          Scopulos pluviae            G.Labarga     126       5
20  34/ 43/ 22                trick shot         John Metcalf     126      15

21  10/  7/ 84                Jedimp '88             inversed     112       0



From: KOTH <koth@koth.org>
Subject: KOTH.ORG: Status -  94 No Pspace 02/13/06
Date: Mon, 13 Feb 2006 07:13:35 -0500 (EST)
Message-ID: <200602130509.k1D590fG062017@asgard.t-b-o-h.net>

			Weekly Status on  02/13/06
 
-=- irc.KOTH.org is up! Meetings held in #corewars
-=- Tons of new features on www.KOTH.org/koth.html pages
-=- *FAQ* page located at: www.KOTH.org/corewar-faq.html
 


Current Status of the KOTH.ORG 94 No Pspace CoreWar Hill:

Last battle concluded at : Fri Feb 10 16:50:38 EST 2006
 
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  43/ 46/ 11                 pro.Verka             inversed     139      20
 2  29/ 19/ 51                     2by4k              P.Kline     139      33
 3  42/ 45/ 12              Poison Arrow    Christian Schmidt     139       2
 4  33/ 27/ 40           Gods Of Destiny        Nenad Tomasev     138     201
 5  32/ 27/ 41       Monster_Alien_Grunt             inversed     137      73
 6  29/ 22/ 49               MoonOfChaos        Nenad Tomasev     136      35
 7  32/ 29/ 39       Monster_Human_Grunt             inversed     136      72
 8  28/ 21/ 52            Last Judgement    Christian Schmidt     135     257
 9  35/ 36/ 29             Stable Muffin              P.Kline     134       3
10  31/ 29/ 40                HullabaTwo                  Roy     133     402
11  31/ 29/ 39                   Battery          Sascha Zapf     133      79
12  27/ 23/ 50               Rust [v0.2]             inversed     132     180
13  25/ 18/ 57                 Acillatem        Nenad Tomasev     131      37
14  40/ 49/ 11                 TheDanube        Nenad Tomasev     131      34
15  24/ 18/ 58               Tie Fast!!!    Christian Schmidt     131      48
16  36/ 42/ 22           Myrmidon 2 test         Roy van Rijn     130       1
17  28/ 27/ 45                  Atlas_II        Nenad Tomasev     129      32
18  28/ 28/ 44                     Amber             inversed     128      26
19  36/ 44/ 20                 Razorgirl          S.Fernandes     128      47
20  41/ 54/  5   don't disturb the dust!         John Metcalf     127      75

21  34/ 50/ 17               apple pie 7         John Metcalf     118       0



From: KOTH <koth@koth.org>
Subject: KOTH.ORG: Status - MultiWarrior 94 02/13/06
Date: Mon, 13 Feb 2006 07:13:34 -0500 (EST)
Message-ID: <200602130503.k1D530fA061638@asgard.t-b-o-h.net>

			Weekly Status on  02/13/06
 
-=- irc.KOTH.org is up! Meetings held in #corewars
-=- Tons of new features on www.KOTH.org/koth.html pages
-=- *FAQ* page located at: www.KOTH.org/corewar-faq.html
 


Current Status of the KOTH.ORG Multiwarrior 94 CoreWar Hill:

Last battle concluded at : Wed Feb 8 21:00:15 EST 2006
 
 #                      Name               Author   Score     Age
 1                     Urgle         Daniel Rivas      43       4
 2 kingdom of the grasshoppe     simon wainwright      35     119
 3                   Gungnir         John Metcalf      29       6
 4       JustADirtyClearTest        Nenad Tomasev      27      53
 5           Fluffy Paper VI         Jens Gutzeit      26      24
 6         nameless fragment          S.Fernandes      24      23
 7    the price of hostility         John Metcalf      23      11
 8                   Diptera        Nenad Tomasev      23      38
 9            simply believe         John Metcalf      20       1
10              Simon Gruber             datagram      20      19

11               Parasite v3             adenozin       0       0



From: KOTH <koth@koth.org>
Subject: KOTH.ORG: Status - ICWS Experimental 94 02/13/06
Date: Mon, 13 Feb 2006 07:13:33 -0500 (EST)
Message-ID: <200602130506.k1D560hI061836@asgard.t-b-o-h.net>

			Weekly Status on  02/13/06
 
-=- irc.KOTH.org is up! Meetings held in #corewars
-=- Tons of new features on www.KOTH.org/koth.html pages
-=- *FAQ* page located at: www.KOTH.org/corewar-faq.html
 


Current Status of the KOTH.ORG ICWS Experimental 94 CoreWar Hill:

Last battle concluded at : Wed Feb 8 16:18:38 EST 2006
 
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  45/ 36/ 19             Fatamorgana X           Zul Nadzri     155      10
 2  43/ 37/ 20             The X Machine           Zul Nadzri     148      34
 3  43/ 38/ 19                      Ogre    Christian Schmidt     147     171
 4  35/ 23/ 42                xd100 test        David Houston     147      20
 5  41/ 40/ 19              Eliminator X           Zul Nadzri     143      35
 6  27/ 11/ 62              Evol Cap 4 X       John Wilkinson     142     292
 7  32/ 26/ 42                    KAT v5          Dave Hillis     139     155
 8  40/ 41/ 20                Bewitching          S.Fernandes     139       1
 9  33/ 31/ 36                  Olivia X             Ben Ford     135     104
10  39/ 43/ 18               Black Moods          Ian Oversby     135     219
11  32/ 30/ 38                 Glenstorm         John Metcalf     134      85
12  36/ 38/ 26                      test        Some Redcoder     134       4
13  39/ 45/ 16        Giant Hazy Test 13        Steve Gunnell     134      50
14  40/ 45/ 15               O_Fortuna3X        Nenad Tomasev     134       6
15  36/ 39/ 24              Trefoil F 13        Steve Gunnell     134     106
16  37/ 41/ 21     Controlled Aggression          Ian Oversby     133     223
17  38/ 42/ 20        Simply Intelligent           Zul Nadzri     133      16
18  19/  6/ 75             Evolve X v4.0       John Wilkinson     133     240
19  36/ 40/ 23         Trefoil Test F 14        Steve Gunnell     132       7
20  38/ 47/ 15              Fatal Choice        Some Redcoder     129       5

21  33/ 52/ 15                 apple pie         John Metcalf     114       0



From: sayembara@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 15 Feb 2006 05:58:15 -0800
Message-ID: <1140011895.796634.146170@g14g2000cwa.googlegroups.com>

Any updates on this project?



From: roy.van.rijn@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 16 Feb 2006 00:35:46 -0800
Message-ID: <1140078946.212470.281000@g14g2000cwa.googlegroups.com>

No, I don't think so... we are all thinking now about it, but nobody
really wants to take action so it seems :-)
Everybody just thinks a little bit different about it, and nobody wants
to make it... I don't have the time nor expertise to do it.



From: "Mike5" <miha.vitorovic@gmail.com>
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 16 Feb 2006 07:50:12 -0800
Message-ID: <1140105012.511642.203120@g43g2000cwa.googlegroups.com>

I actually wouldn't mind discussing it further, but I don't like this
Google UI that much. Anybnody knows of a forum we could use?

Cheers, Mike5



From: sayembara@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 16 Feb 2006 17:19:25 -0800
Message-ID: <1140139165.201502.237660@g43g2000cwa.googlegroups.com>

I have created a bulletin to make it more convenient:

http://1.myfreebulletinboard.com/corewar/index.php?mforum=corewar

Then go to Mike5 Java Evolver. Create new topic if different.
To get shorter redirection URL....this one is too long to remember.

Among the topic to be discussed should be, IMHO, the basis, the whys,
the hows, etc so that it can be a complete description knowing most of
us are time limited and also expertise limited. Hopefully by logging
the current progress as detail as possible, the unfinished tasks can be
resumed easier later. Similar to Roy, I can only help in very limited
scope. I can give feedbacks and challenges to improve the project but
programming is not my area.



From: dhillismail@netscape.net
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 18 Feb 2006 11:41:48 -0800
Message-ID: <1140291708.565917.171400@o13g2000cwo.googlegroups.com>

    I like the forum.
    IMHO a distributed corewars GA project is a solution in search of a
problem. There needs to be a specific question you're trying to find
the answer to or some other unambiguous goal. It's a very cool
solution, to be sure, but I think a suitably cool objective is needed
and sooner rather than later.
Just my 2 cents,

Dave Hillis



From: "Jens Gutzeit" <jens@jgutzeit.de>
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 19 Feb 2006 05:43:46 -0800
Message-ID: <1140356626.598478.21700@o13g2000cwo.googlegroups.com>

Hi,

after rereading all the posts and the comments on IRC I have some
suggestions/ideas/stolen ideas:

1. There is no need for a central server. For communication between
the different nodes (i.e. running evolver instances), we should use
an already existing infrastructure. Personally I would prefer Jabber,
but IRC is an option, too. Your evolver would simple go online (Jabber)
or connect to the right IRC channel.

2. So far there seem to be three main problems. The first one is the
protocol, that should be used for exchanging warriors. The second
one is how the exchanged warriors are treated by your evolver. The
last one is how to prevent other from submitting "bad" warriors (i.e.
warriors, that aren't accepted by the "current standards")

2.1 How the evolver handles all incoming warriors IS NOT OUR
problem. That should depend on the algorithm, that the warrior
uses. But it should be discussed separately!

2.2 Protocol: See my next post.

2.3. If we take a Jabber (or sth. similar) for communication, it is
quite simple to exclude "bad" warriors. Once node is indentified
to send "bad" warriors, it will no longer be contacted by other
nodes. All you have to do is to maintain a list of "good" nodes
(i.e. list of JIDs).

Regards, 

Jens Gutzeit :-)



From: "Jens Gutzeit" <jens@jgutzeit.de>
Subject: EvolveWars Protocol
Date: 19 Feb 2006 06:54:11 -0800
Message-ID: <1140360851.899576.132800@g43g2000cwa.googlegroups.com>

Hi,

Feel free to comment and change the protocol.

EWP Version 0/2006-02-19

A *node* is one running instance of an evolver, which implements
this protocol. Each node is indentified by an *id* (RSA public key?),
a *name* (sth. like "Jens' evolver, version 1.2.3") and an *owner*
(e.g. "Jens Gutzeit"). Each node maintains a list of hills, it is
currently evolving for. Each hill is identified by its settings, i.e.
CORESIZE, MAXPROCESSES, MAXCYCLES, MINDISTANCE,
MAXLENGTH and INSTRUCTIONSET (88, 94nop, pspace).

Each node should know a list of other nodes to contact. If we
decide on the IRC option this can be the server and channel
to contact. A node is then one user in this channel. If we
decide on the Jabber option this can be a list of JIDs.

At every time a node can contact and be contacted by other
nodes. All communication is text based and I would say, that
ASCII is enough, but UTF-8 might be useful.

Both IRC and Jabber have means to decide, whether a node has
gone offline/is offline. I think, it is easier to check that, instead
of implementing some kind of timeout for the communication
between the nodes. That's why I assume, that each request by
a node is either answered or the contacted node is recognized
as gone offline.

Each of the following commands is case-sensitive.

1. ID

The ID command returns the ID of the contancted node.

> ID
> 123456789

Once we decide on using IDs, it should be specified, what
the answer means. If we don't use IDs, there is not need
for this command.

2. NAME

The NAME command returns the name of the node.

> NAME
> Jens' evolver, version 1.2.3, node 42

The reply by the contancted node should be exactly one
line.

3. OWNER

The OWNER command returns the name of the owner of
the node.

> OWNER
> Jens Gutzeit

Again the reply has to exactly one line.

4. LIST HILLS

The LIST HILLS command returns a list of all hills, the
evoler is currently evolving for. The first line returns the
number of hills. The following lines contain the name
of the hill and its settings. The name of each hill has to
be unique on the contacted node, but not unique on
all nodes.

> LIST HILLS
> 1
> tiny-x 801 2000 8000 21 20 pspace

There is one hill on the node. Its name is "tiny-x".
It uses the following settings:

CORESIZE = 801
MAXPROCESSES = 2000
MAXCYCLES = 8000
MINDISTANCE = 21
MAXLENGTH = 21
INSTRUCTIONSET = pspace

5. GET

The GET command requests ONE warrior from the
given hill to be sent back to the requesting node.

The first line of the answer contains the number of
lines, which follow (and contain the actual warriors code).

> GET tiny
> 8
> ;redcode-tiny
> ;name x928743981734
> ;author Jens Gutzeit
> ;assert 1
>
> mov.i 0, 3
> mov.i 0, 4
> mov.i 0, 3

6. Protocol Errors

If a contacted node cannot fulfill the given request,
it has to reply with "ERROR " followed by an optional
reason.

> GET tiny
> ERROR The Internet is down ;-)

-----

I know, that this protocol is far from perfect, but it
might be a start to work with.

Regards,

Jens Gutzeit :-)



From: sayembara@gmail.com
Subject: Re: EvolveWars Protocol
Date: 19 Feb 2006 08:05:10 -0800
Message-ID: <1140365109.984238.100960@g43g2000cwa.googlegroups.com>

A good start :)

*Googling the word Jabber*



From: "Jens Gutzeit" <jens@jgutzeit.de>
Subject: Re: EvolveWars Protocol
Date: 19 Feb 2006 08:31:07 -0800
Message-ID: <1140366667.335352.220120@g43g2000cwa.googlegroups.com>

http://www.jabber.org

http://en.wikipedia.org/wiki/Jabber



From: sayembara@gmail.com
Subject: Re: EvolveWars - A virtual peer-to-peer corewar universe
Date: 19 Feb 2006 09:02:01 -0800
Message-ID: <1140365699.158275.150150@g43g2000cwa.googlegroups.com>

2.1 : Agreed to discuss separately.
   - how the warrior looks like? can other evolver read it?
   - how evolver let this warrior interacts with other warriors?
   - let this warrior wipe the entire population? [two school of
thought here]

2.2 : the best idea so far but no comment from me at this time.

2.3 : no idea on how Jabber does that...I need time to know Jabber
actually :) 
To define 'bad' warrior



From: "Mike5" <miha.vitorovic@gmail.com>
Subject: Re: EvolveWars Protocol
Date: 20 Feb 2006 01:16:08 -0800
Message-ID: <1140426968.233786.244700@g47g2000cwa.googlegroups.com>

*Sigh* serves me right for asking for a forum, now I have to post
everything twice :(

I like some ideas of the protocol, but I would rather we use a package
format to exchange, beacuse it gives us some flexibilty over the
"transfer text" idea.

Mainly, once we develop the protocol to echange packets, it is then
much easier to upgrade, that is, we separate the transfer layer from
the presentation layer Very Happy If we wan't to upgrade, we just stuff
the extra info in the package, and bump it's version infromation, the
mechanism of transferring packets would remain the same.

It would give us the ability to transfer more warriors in on go.

We could store some meta-data with the warriors, like CRC, signatures
and other things.

Thoughts on the package:

Code exchange format. I guess we'll have to agree on standard package.
Something like a zip file, for example, with different folders in it
(like JAR files for Java). Also some sort of meta-information would
probably be useful, don you think:
- MARS info and parameters
- GA parameters used
- genealogy of a warrior (especially usefull once we start mixing our
warriors, I think)
- some sort of warrior rating, as I mentioned - it would need to be
strictly automated, of course

Please add whatever you think of :)

Cheers, Mike5



From: "Mike5" <miha.vitorovic@gmail.com>
Subject: Re: EvolveWars Protocol
Date: 20 Feb 2006 04:42:37 -0800
Message-ID: <1140439357.070780.77120@f14g2000cwb.googlegroups.com>

Oh yeah, something else I forgot to copy & paste:

I like the idea of using Jabber or IRC, maybe IRC would be even better,
or some other software that supports conference/chat rooms (I see
Jabber does, but it needs a special server or something like that).
That way we would avoid the need to poll all the connected clients. The
client would simply join a channel, and issue LIST HILLS publically and
get a response from all the nodes. Then it would open peer to peer
connections to those peers that it is interested in only.

It would be also good if we chose a protocol that has as much
implementing libraries as possible readily available in most
programming languages. That way developers would not need to reinvent
the wheel if they wanted to add Evolve Wars functionality to their MARS
interpreter.

Cheers, Mike5



From: KOTH <koth@koth.org>
Subject: KOTH.ORG: Status - MultiWarrior 94 02/20/06
Date: Mon, 20 Feb 2006 08:51:26 -0500 (EST)
Message-ID: <200602200503.k1K530XF054743@asgard.t-b-o-h.net>

			Weekly Status on  02/20/06
 
-=- irc.KOTH.org is up! Meetings held in #corewars
-=- Tons of new features on www.KOTH.org/koth.html pages
-=- *FAQ* page located at: www.KOTH.org/corewar-faq.html
 


Current Status of the KOTH.ORG Multiwarrior 94 CoreWar Hill:

Last battle concluded at : Fri Feb 17 13:44:28 EST 2006
 
 #                      Name               Author   Score     Age
 1 kingdom of the grasshoppe     simon wainwright      46     120
 2       JustADirtyClearTest        Nenad Tomasev      33      54
 3                     Urgle         Daniel Rivas      32       5
 4         nameless fragment          S.Fernandes      30      24
 5           Fluffy Paper VI         Jens Gutzeit      28      25
 6                   Diptera        Nenad Tomasev      28      39
 7                   Gungnir         John Metcalf      27       7
 8    the price of hostility         John Metcalf      26      12
 9           rooftop pursuit         John Metcalf      19       1
10            simply believe         John Metcalf      18       2

11      march of the fairies         John Metcalf      11       0



From: KOTH <koth@koth.org>
Subject: KOTH.ORG: Status - ICWS Experimental 94 02/20/06
Date: Mon, 20 Feb 2006 08:51:25 -0500 (EST)
Message-ID: <200602200506.k1K560iX055051@asgard.t-b-o-h.net>

			Weekly Status on  02/20/06
 
-=- irc.KOTH.org is up! Meetings held in #corewars
-=- Tons of new features on www.KOTH.org/koth.html pages
-=- *FAQ* page located at: www.KOTH.org/corewar-faq.html
 


Current Status of the KOTH.ORG ICWS Experimental 94 CoreWar Hill:

Last battle concluded at : Wed Feb 8 16:18:38 EST 2006
 
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  45/ 36/ 19             Fatamorgana X           Zul Nadzri     155      10
 2  43/ 37/ 20             The X Machine           Zul Nadzri     148      34
 3  43/ 38/ 19                      Ogre    Christian Schmidt     147     171
 4  35/ 23/ 42                xd100 test        David Houston     147      20
 5  41/ 40/ 19              Eliminator X           Zul Nadzri     143      35
 6  27/ 11/ 62              Evol Cap 4 X       John Wilkinson     142     292
 7  32/ 26/ 42                    KAT v5          Dave Hillis     139     155
 8  40/ 41/ 20                Bewitching          S.Fernandes     139       1
 9  33/ 31/ 36                  Olivia X             Ben Ford     135     104
10  39/ 43/ 18               Black Moods          Ian Oversby     135     219
11  32/ 30/ 38                 Glenstorm         John Metcalf     134      85
12  36/ 38/ 26                      test        Some Redcoder     134       4
13  39/ 45/ 16        Giant Hazy Test 13        Steve Gunnell     134      50
14  40/ 45/ 15               O_Fortuna3X        Nenad Tomasev     134       6
15  36/ 39/ 24              Trefoil F 13        Steve Gunnell     134     106
16  37/ 41/ 21     Controlled Aggression          Ian Oversby     133     223
17  38/ 42/ 20        Simply Intelligent           Zul Nadzri     133      16
18  19/  6/ 75             Evolve X v4.0       John Wilkinson     133     240
19  36/ 40/ 23         Trefoil Test F 14        Steve Gunnell     132       7
20  38/ 47/ 15              Fatal Choice        Some Redcoder     129       5

21  33/ 52/ 15                 apple pie         John Metcalf     114       0



From: KOTH <koth@koth.org>
Subject: KOTH.ORG: Status -  94 No Pspace 02/20/06
Date: Mon, 20 Feb 2006 08:51:25 -0500 (EST)
Message-ID: <200602200509.k1K590Tq055185@asgard.t-b-o-h.net>

			Weekly Status on  02/20/06
 
-=- irc.KOTH.org is up! Meetings held in #corewars
-=- Tons of new features on www.KOTH.org/koth.html pages
-=- *FAQ* page located at: www.KOTH.org/corewar-faq.html
 


Current Status of the KOTH.ORG 94 No Pspace CoreWar Hill:

Last battle concluded at : Sun Feb 19 17:48:40 EST 2006
 
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  33/ 27/ 40                Hullab3loo         Roy van Rijn     138       9
 2  27/ 17/ 56                   Mascaf�            G.Labarga     137       4
 3  31/ 25/ 44       Monster_Alien_Grunt             inversed     136      95
 4  28/ 19/ 53                     2by4k              P.Kline     136      55
 5  26/ 16/ 58                D3vilstick         Roy van Rijn     135       8
 6  31/ 27/ 42           Gods Of Destiny        Nenad Tomasev     135     223
 7  31/ 28/ 41       Monster_Human_Grunt             inversed     134      94
 8  40/ 47/ 13              Poison Arrow    Christian Schmidt     133      24
 9  26/ 21/ 53               Rust [v0.2]             inversed     131     202
10  41/ 52/  7                 Claw IIIa    Christian Schmidt     130       2
11  27/ 23/ 50               MoonOfChaos        Nenad Tomasev     130      57
12  39/ 49/ 12                 pro.Verka             inversed     130      42
13  36/ 43/ 21                        F3          Sascha Zapf     129      22
14  29/ 30/ 41                   Battery          Sascha Zapf     129     101
15  25/ 22/ 52            Last Judgement    Christian Schmidt     128     279
16  33/ 37/ 30             Stable Muffin              P.Kline     128      25
17  38/ 48/ 14              Dark Crystal         John Metcalf     128       1
18  37/ 46/ 17                    Mutant          Sascha Zapf     128      18
19  26/ 25/ 48                      H5N1          Sascha Zapf     127       5
20  27/ 27/ 46                  Atlas_II        Nenad Tomasev     127      54

21  25/ 25/ 50                 Monkshood    Christian Schmidt     125      15



From: KOTH <koth@koth.org>
Subject: KOTH.ORG: Status - Standard 02/20/06
Date: Mon, 20 Feb 2006 08:51:23 -0500 (EST)
Message-ID: <200602200500.k1K500Zi054634@asgard.t-b-o-h.net>

			Weekly Status on  02/20/06
 
-=- irc.KOTH.org is up! Meetings held in #corewars
-=- Tons of new features on www.KOTH.org/koth.html pages
-=- *FAQ* page located at: www.KOTH.org/corewar-faq.html
 


Current Status of the KOTH.ORG Standard KotH CoreWar Hill :

Last battle concluded at : Wed Feb 1 14:59:46 EST 2006
 
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  34/ 24/ 43                      Test Alexander (Sasha) Wa     144     178
 2  38/ 36/ 26                My 1st try    Christian Schmidt     140      70
 3  34/ 29/ 37         The Next Step '88        David Houston     140      54
 4  31/ 25/ 44            The Hurricaner            G.Labarga     137      25
 5  30/ 23/ 47                      test            G.Labarga     137      21
 6  30/ 24/ 46                  Guardian          Ian Oversby     136     238
 7  31/ 27/ 41           SoundOfDarkness        Nenad Tomasev     135       2
 8  37/ 40/ 23                  Moonwipe    Christian Schmidt     134      35
 9  42/ 49/  9                Replihater        Some Redcoder     134       9
10  38/ 42/ 19              Scan the Can    Christian Schmidt     134      19
11  40/ 47/ 14              Speeed 88mph    Christian Schmidt     133      38
12  32/ 31/ 37                  The Seed         Roy van Rijn     132      56
13  23/ 15/ 61               Utterer '88    Christian Schmidt     131      13
14  36/ 41/ 23                      July        Nenad Tomasev     131      11
15  39/ 48/ 13             Scan Test C 6        Steve Gunnell     131      77
16  38/ 46/ 16                    Kraken        Nenad Tomasev     129       1
17  30/ 31/ 40                    A.I.P.    Christian Schmidt     128      46
18  20/ 13/ 67                 IMParable            G.Labarga     127      26
19  25/ 24/ 51          Scopulos pluviae            G.Labarga     126       5
20  34/ 43/ 22                trick shot         John Metcalf     126      15

21  10/  7/ 84                Jedimp '88             inversed     112       0



From: sayembara@gmail.com
Subject: Re: EvolveWars Protocol
Date: 20 Feb 2006 13:28:06 -0800
Message-ID: <1140470886.578650.291680@g47g2000cwa.googlegroups.com>

Those IRC bots on #corewar, can they be the 'server' or distributor of
the warriors? Add some script to eliminate bad codes to further enhance
their capabilities.



From: sayembara@gmail.com
Subject: Re: EvolveWars Protocol
Date: 20 Feb 2006 13:32:20 -0800
Message-ID: <1140471140.530386.166980@g43g2000cwa.googlegroups.com>

Mike5, that is another challenge...to say everything twice :)
I'll try to copy related info to the bulletin.

Now I have corewar.shortURL.com to point to the same place.



From: "Mike5" <miha.vitorovic@gmail.com>
Subject: Re: EvolveWars Protocol
Date: 20 Feb 2006 23:45:54 -0800
Message-ID: <1140507954.717601.272170@z14g2000cwz.googlegroups.com>

Yeah, I like the p2p thing better too, with the option to get info frm
all hosts at once, as I proposed.

I think we can safely move the validation to client, because even if
there a validation server, I am sure most users would want to have
validation on the clinet as well - I know I would. After all, there may
be some error on the server, and blindly trusting some data from the
Internet is a no-no.

Cheers, Mike5



From: "Jens Gutzeit" <jens@jgutzeit.de>
Subject: Re: EvolveWars Protocol
Date: 21 Feb 2006 06:19:25 -0800
Message-ID: <1140531564.951293.13230@g43g2000cwa.googlegroups.com>

Hi Mike5,

> like some ideas of the protocol, but I would rather we use a
> package format to exchange, beacuse it gives us some flexibilty
> over the "transfer text" idea.

a "package format" might give some flexibility, but it will make
things harder to implement. It will be already quite difficult to
get this project up and running and before we can deal with
upgrade/extensions we should have at least a program, that
does sth. useful. The "text format" is the most simple protocol,
I can think of.

> It would give us the ability to transfer more warriors in on go.

Simple issue several GET commands. You don't need to be
concerned with overhead, especially, if we'll use Jabber ;-)

> We could store some meta-data with the warriors, like
> CRC, signatures and other things.

Nice idea, but it would be more easier to add tags to the
warrior itself like:

;crc 0xdeadbeef
;bla foobar

> - some sort of warrior rating, as I mentioned - it would need to be
> strictly automated, of course

Warrior rating seems to be difficult. A fixed benchmark might be
useful, but that can do the evolver after downloading the warrior.

Regard,

Jens Gutzeit :-)



From: Andreas Scholta <andreas.scholta@gmail.com>
Subject: Re: EvolveWars Protocol
Date: Tue, 21 Feb 2006 06:22:34 +0100
Message-ID: <8764n91e1x.fsf@gmail.com>

well, that's the question. I assume you are thinking letting each client
send some warriors to a central place from where they are distributed,
specific to the irc carrier protocol proposition. now, while this has its
uses for validation of code, it adds more clunk to the protocol and
(well this is a minor issue really..) all traffic will be channeled
through one host. It should be more intuitive to make it a p2p
protocol. then however, things like code validation either has to be
moved to the client side or there exist validation servers which
could work like this: host A wants to send host B some warriors. host A
contacts validation server C which validates the code, md5sums it or
similar and then tells B that there is an impending submission from host
A, sending the md5sum for host B to check against what it receives from
A. now, "why not just send the warriors through C then?" you ask... I
don't know. it just sounded flashy.

bvowk, if you are reading this. you could give some input, I am sure you
have many useful things to note and this needs some determined spin in
one direction.
-- 
staring into the singularity:
http://yudkowsky.net/singularity.html


From: "Jens Gutzeit" <jens@jgutzeit.de>
Subject: Re: EvolveWars Protocol
Date: 21 Feb 2006 06:22:32 -0800
Message-ID: <1140531752.485576.234890@g44g2000cwa.googlegroups.com>

With Jabber you don't really need a "room". It should be as simple
as maintaining a list of all JIDs. Then you can connect to each
address and look up, what it is running.

For IRC there are already plenty of libraries available. For Jabber
please go to http://jabber.org . That should be enough as well.

Regards,

Jens Gutzeit :-)



From: "Jens Gutzeit" <jens@jgutzeit.de>
Subject: Re: EvolveWars Protocol
Date: 21 Feb 2006 06:23:55 -0800
Message-ID: <1140531835.713128.83020@f14g2000cwb.googlegroups.com>

If you want to have a server, why not implement a simple "warrior
store" with PHP/Python/Perl + some database.



From: sayembara@gmail.com
Subject: Genetic algorithm modules
Date: 21 Feb 2006 14:22:27 -0800
Message-ID: <1140560547.453549.92220@o13g2000cwo.googlegroups.com>

Hi,

Is there plan to make the genetic algorithm more selective so that the
changes to preferred modules done in the 'txt' file rather than the
source code? What I mean for modules are the functions such as 1-point,
2-point xover, multiple pt cross over, mutation, addition, subtraction,
permutation, multiply, splice, etc that can be selected or given
probability weights. Selection flexibility should also available for
elitism, methods of eliminations, fitness function, etc which some
evolvers already include.

Sample config.txt file:
;1-point crossover probability
50
;Apply Mutation
No

;2-point crossover probability
10
;Apply Mutation
Yes

;Pure Mutation without xover probability
1
;Line addition probability
1
;Line removal probability
1

;Permutation probability
1

;Random Mixing
5

;Random warrior creation
1

etc
etc
etc

;Elitism
Yes

;Reintroduce warrior from vahalla
Yes

;Fitness (hill, all-fight-all)
Hill

;Elimination (A)-winner replace loser, B).top 1/2 replaces bottom 1/4,
etc)
A

;Remove similar warrior / clone scaling
Yes

etc
etc
etc



From: "Mike5" <miha.vitorovic@gmail.com>
Subject: Re: Genetic algorithm modules
Date: 23 Feb 2006 03:47:20 -0800
Message-ID: <1140695240.228835.169800@g47g2000cwa.googlegroups.com>

Well, yes, there are PLANS :) Now I just need to get to it...

Cheers, Mike5



From: "inversed" <reoser@mail.ru>
Subject: Adressing modes
Date: 23 Feb 2006 14:11:43 -0800
Message-ID: <1140732703.323655.93550@p10g2000cwp.googlegroups.com>

Introduction of #$@ opmodes is natural. But why was predecrement
introduced? I mean, why it was not a postincrement or a postdecrement
for example? It's  possible to use postdecrement and preincrement
opmodes, but why they were never introduced?



Date: Thu, 23 Feb 2006 16:53:25 -0500
From: Richard Rognlie <usenet@feb2006.gamerz.net>
Subject: C++Robots Standings 2006/02/23
Message-ID: <68ednVFo8OJ0s2PenZ2dnUVZ_tOdnZ2d@speakeasy.net>

    Program Name     Score  W / L / T  Age Author
    ================ ===== =========== === ==========================
  1 wilma              664 221/ 28/  1 135 mhamilton
  2 edgar              657 218/ 29/  3 383 joehorn
  3 fox-014            648 216/ 34/  0 457 dohzono
  4 radar              633 211/ 39/  0 382 Radu.Dumitru
  5 tommy              625 207/ 39/  4 564 jacksoew
  6 ths7h5             588 195/ 52/  3 680 TORSTEN.SCHOENFELDER
  7 wobble             552 184/ 66/  0 182 gmail
  8 polarbear          537 179/ 71/  0 477 flandar
  9 snaylle-11         516 170/ 74/  6  48 robots
10 whiper++           503 166/ 79/  5 427 francis.w
11 crbot              502 167/ 82/  1 711 Rosevear.Craig.CA
12 v3                 501 167/ 83/  0 512 zechis
13 mi5                489 163/ 87/  0 355 schreiner.michael
13 jelly              489 163/ 87/  0 180 zbig_mad
15 pipes              478 159/ 90/  1 215 rcroote
16 razor              477 159/ 91/  0 117 godhand.cp29
17 v                  463 148/ 83/ 19 123 zechis
18 whiper_v2          422 140/108/  2 628 francis.w
19 pugna              374 122/120/  8 103 panuwat_cp
20 zquare             373 120/117/ 13  89 panuwat_cp
21 goodness1          370 123/126/  1  71 apicha_sippakorn
22 kamikaze           369 123/127/  0 642 mike
22 robo_basic-03      369 123/127/  0 109 robo_basic
22 phoenix1           369 123/127/  0  81 bigmo2829
25 wrobot             367 122/127/  1  73 pomepook
26 wolfhound2         366 122/128/  0 189 theaidanmurphy
27 noob_out_2         363 120/127/  3  77 noob_robot
28 phoenix            360 120/130/  0  86 bigmo2829
29 ak-sprt-v2.5       354 118/132/  0 173 andrew.kavanaugh
30 kankai             350 116/132/  2 118 too_fast_too_quiz
31 nooby_out_src      348 116/134/  0  95 noob_robot
32 testy              343 114/135/  1 212 jaredjstewart
32 goodness           343 114/135/  1  76 apicha_sippakorn
34 botnaja            342 114/136/  0 126 metal_buddy
35 ak2110435          337 112/137/  1 168 sippakorn
36 ak-sprt-v2.4       330 110/140/  0 174 andrew.kavanaugh
37 duelo              316 101/136/ 13   2 vdelacalle
38 windwalk2          315 105/145/  0 133 windwalk_robot
39 followme           306 102/148/  0 362 aidandunbar
40 duelo+             301  97/143/ 10   1 vdelacalle
41 5150               293  97/151/  2 517 tedpabon
42 tasteofcheese      293  88/133/ 29 358 gwright
43 bigs1              240  80/170/  0  64 niceguyspy65
44 e-vulture          195  64/183/  3  12 jge_coco
45 tracker1           145  48/201/  1  21 rob2005
46 greenbishbot       131  43/205/  2  15 greenbishop
47 robo_basic-06      106  35/214/  1  68 robo_basic
48 t1                  99  33/217/  0  19 rob2005
49 first_strike        49  13/227/ 10  17 engelfl
50 katie               46   3/210/ 37  29 l124rd


For information on playing, visit http://www.gamerz.net/c++robots


From: sayembara@gmail.com
Subject: Re: Adressing modes
Date: 24 Feb 2006 00:53:32 -0800
Message-ID: <1140771212.847471.308410@i40g2000cwc.googlegroups.com>


inversed wrote:
> Introduction of #$@ opmodes is natural. But why was predecrement
> introduced? I mean, why it was not a postincrement or a postdecrement
> for example? It's  possible to use postdecrement and preincrement
> opmodes, but why they were never introduced?

....may be people are too busy? It is about time to update the current
1994 rules and move to new millenium. Most critical path is to develop
/ upgrade current MARS.



From: sayembara@gmail.com
Subject: Re: Adressing modes
Date: 24 Feb 2006 00:54:45 -0800
Message-ID: <1140771285.890349.324920@v46g2000cwv.googlegroups.com>

I mean upgrade MARS *IF* post decrement/increment is accepted.



From: sayembara@gmail.com
Subject: Re: Genetic algorithm modules
Date: 24 Feb 2006 00:57:51 -0800
Message-ID: <1140771471.045429.5310@p10g2000cwp.googlegroups.com>

Good to know that :)
Let me know if anything that I capable to help.

Zul Nadzri
*beta tester @ crap_at_programming*



From: sayembara@gmail.com
Subject: Re: EvolveWars Protocol
Date: 24 Feb 2006 10:18:02 -0800
Message-ID: <1140805082.393163.5670@t39g2000cwt.googlegroups.com>

Mike has produce an evolver:
----
Hey. people. My evolver to be is finally on SourceForge.

http://sourceforge.net/projects/cw-evolver/

I'll add a compiled version (jar file) ASAP.

Cheers, Mike5



From: Sascha Zapf <nc-zapfsa@netcologne.de>
Subject: Re: Adressing modes
Date: Fri, 24 Feb 2006 15:48:17 -0500 (EST)
Message-ID: <200602241513.20368.nc-zapfsa@netcologne.de>

Am Freitag, 24. Februar 2006 10:22 schrieb sayembara@gmail.com:
> I mean upgrade MARS *IF* post decrement/increment is accepted.

There are some other interresting instructions, modifier or adressing modes i 
can imagine.

for example
modifier .o

instruction
spz
spn
djz


I think its time for a brainstorming. What is possible in a 06 or 07 standart.

Too much instructions makes the warriors to to complex, it will be impossible 
to beat. But only a handful can be interresting .

What are the thought of the community ?

Sascha



From: "Mike5" <miha.vitorovic@gmail.com>
Subject: Re: EvolveWars Protocol
Date: 25 Feb 2006 10:49:10 -0800
Message-ID: <1140893350.920419.20920@i39g2000cwa.googlegroups.com>

Evolver _TO BE_. It's still too early, don't expect too much.

Cheer, Mike5



From: "Judodudo" <judodudo@googlemail.com>
Subject: Re: Adressing modes
Date: 26 Feb 2006 03:38:15 -0800
Message-ID: <1140950757.320186.270250@j33g2000cwa.googlegroups.com>

I thhink it's time for a new standard, yes. Should freshen up the game.
Maybe we'll see new types of warrior, rather than variations on the
same thing.

How about SPD, where the new process starts after a delay specified in
the B- Field?



Message-ID: <games/corewar-faq_1140931760@rtfm.mit.edu>
From: anton@paradise.net.nz (Anton Marsden)
Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ)
Date: 26 Feb 2006 05:29:40 GMT

Archive-name: games/corewar-faq
Last-Modified: September 4, 1999
Version: 4.2
URL: http://homepages.paradise.net.nz/~anton/cw/corewar-faq.html
Copyright: (c) 1999 Anton Marsden
Maintainer: Anton Marsden <anton@paradise.net.nz>
Posting-Frequency: once every 2 weeks

Core War Frequently Asked Questions

(rec.games.corewar FAQ)

These are the Frequently Asked Questions (and answers) from the Usenet
newsgroup rec.games.corewar. A plain text version of this document is posted
every two weeks. The latest hypertext version is available at
http://homepages.paradise.net.nz/~anton/cw/corewar-faq.html and the latest
plain text version is available at
http://homepages.paradise.net.nz/~anton/cw/corewar-faq.txt.

This document is currently being maintained by Anton Marsden
(anton@paradise.net.nz).

Last modified: Sat Sep 4 00:22:22 NZST 1999
  ------------------------------------------------------------------------

To Do

   * Add the new No-PSpace '94 hill location
   * Add online location of Dewdney's articles
   * Make question 17 easier to understand. Add a state diagram?
   * Add info about infinite hills, related games (C-Robots, Tierra?, ...)
   * New question: How do I know if my warrior is any good? Refer to
     beginners' benchmarks, etc.
   * Add a Who's Who list?
   * Would very much like someone to compile a collection of the
     "revolutionary" warriors so that beginners can see how the game has
     developed over the years. Mail me if interested.

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

What's New

   * Changed primary location of FAQ (again!)
   * Changed Philip Kendall's home page address.
   * Updated list server information
   * Changed primary location of FAQ
   * Vector-launching code was fixed thanks to Ting Hsu.
   * Changed the location of Ryan Coleman's paper (LaunchPad -> Launchpad)
   * Changed pauillac.inria.fr to para.inria.fr

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

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. Core War has changed since Dewdney's articles. Where do I get a copy of
     the current instruction set?
  5. What is ICWS'94? Which simulators support ICWS'94?
  6. What is the ICWS?
  7. What is Core Warrior?
  8. Where are the Core War archives?
  9. Where can I find a Core War system for ...?
 10. Where can I find warrior code?
 11. I do not have FTP. How do I get all this great stuff?
 12. I do not have access to Usenet. How do I post and receive news?
 13. Are there any Core War related WWW sites?
 14. What is KotH? How do I enter?
 15. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core?
 16. How does SLT (Skip if Less Than) work?
 17. What is the difference between in-register and in-memory evaluation?
 18. What is P-space?
 19. What does "Missing ;assert .." in my message from KotH mean?
 20. How should I format my code?
 21. Are there any other Core War related resources I should know about?
 22. What does (expression or term of your choice) mean?
 23. Other questions?

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

1. What is Core War?

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 standardised by the ICWS, and is therefore transportable between
all standard Core War systems.

The system in which the programs run is quite simple. The core (the memory
of the simulated computer) is a continuous array of instructions, empty
except for the competing programs. The core wraps around, so that after the
last instruction comes the first one again.

There are no absolute addresses in Core War. That is, the address 0 doesn't
mean the first instruction in the memory, but the instruction that contains
the address 0. The next instruction is 1, and the previous one obviously -1.
However, all numbers are treated as positive, and are in the range 0 to
CORESIZE-1 where CORESIZE is the amount of memory locations in the core -
this means that -1 would be treated as CORESIZE-1 in any arithmetic
operations, eg. 3218 + 7856 = (3218 + 7856) mod CORESIZE. Many people get
confused by this, and it is particularly important when using the SLT
instruction. Note that the source code of a program can still contain
negative numbers, but if you start using instructions like DIV #-2, #5 it is
important to know what effect they will have when executed.

The basic unit of memory in Core War is one instruction. Each Redcode
instruction contains three parts:

   * the opcode
   * the source address (a.k.a. the A-field)
   * the destination address (a.k.a. the B-field)

The execution of the programs is equally simple. The MARS executes one
instruction at a time, and then proceeds to the next one in the memory,
unless the instruction explicitly tells it to jump to another address. If
there is more than one program running, (as is usual) the programs execute
alternately, one instruction at a time. The execution of each instruction
takes the same time, one cycle, whether it is MOV, DIV or even DAT (which
kills the process).

Each program may have several processes running. These processes are stored
in a task queue. When it is the program's turn to execute an instruction it
dequeues a process and executes the corresponding instruction. Processes
that are not killed during the execution of the instruction are put back
into the task queue. Processes created by a SPL instruction are added to the
task queue after the creating process is put back into the task queue.

[ToC]
  ------------------------------------------------------------------------

2. Is it "Core War" or "Core Wars"?

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.

[ToC]
  ------------------------------------------------------------------------

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

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:

                                                                Library of
  Author         Title         Published          ISBN           Congress
                                                                Call Number
           The Armchair
 Dewdney,  Universe: An       New York: W.                     QA76.6 .D517
 A. K.     Exploration of     H. Freeman �0-7167-1939-8        1988
           Computer Worlds    1988
           The Magic                      0-7167-2125-2
 Dewdney,  Machine: A         New York: W.(Hardcover),         QA76.6
 A. K.     Handbook of        H. Freeman �0-7167-2144-9        .D5173 1990
           Computer Sorcery   1990        (Paperback)

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. For those who are interested, Dewdney has a home page at
http://www.csd.uwo.ca/faculty/akd/.

[ToC]
  ------------------------------------------------------------------------

4. Core War has changed since Dewdney's articles. Where do I get a copy of
the current instruction set?

A draft of the official standard (ICWS'88) is available as
ftp://www.koth.org/corewar/documents/standards/redcode-icws-88.Z. This
document is formatted awkwardly and contains ambiguous statements. For a
more approachable intro to Redcode, take a look at Mark Durham's tutorials,
ftp://www.koth.org/corewar/documents/tutorial.1.Z and
ftp://www.koth.org/corewar/documents/tutorial.2.Z.

Steven Morrell has prepared a more practically oriented Redcode tutorial
that discusses different warrior classes with lots of example code. This and
various other tutorials can be found at http://www.koth.org/papers.html.

Even though ICWS'88 is still the "official" standard, you will find that
most people are playing by ICWS'94 draft rules and extensions.

[ToC]
  ------------------------------------------------------------------------

5. What is ICWS'94? Which simulators support ICWS'94?

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 new
addressing modes 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 at ftp://www.koth.org/corewar/documents/icws94.0202.Z for more
information. There is a HTML version of this document available at
http://www.koth.org/info/icws94.html. 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://www.koth.org/corewar. Note that Redcoder only
supports a subset of ICWS'94.

[ToC]
  ------------------------------------------------------------------------

6. What is the ICWS?

About one year after Core War first appeared in Scientific American, 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 no
longer active.

[ToC]
  ------------------------------------------------------------------------

7. What is Core Warrior?

Following in the tradition of the Core War News Letter, Push Off, and The 94
Warrior, Core Warrior is a newsletter about strategies and current standings
in Core War. Started in October 1995, back issues of Core Warrior (and the
other newsletters) are available at http://para.inria.fr/~doligez/corewar/.
There is also a Core Warrior index page at
http://www.kendalls.demon.co.uk/pak21/corewar/warrior.html which has a
summary of the contents of each issue of Core Warrior. Many of the earlier
issues contain useful information for beginners.

[ToC]
  ------------------------------------------------------------------------

8. Where are the Core War archives?

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 ftp://ftp.csua.berkeley.edu/pub/corewar.
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.

This site is mirrored at:

   * http://www.koth.org/corewar/
   * ftp://www.koth.org/corewar/
   * ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/mirror

The plain text version of this FAQ is automatically archived by news.answers
(but this version is probably out-of-date).

[ToC]
  ------------------------------------------------------------------------

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

Core War systems are available via anonymous FTP from www.koth.org in the
corewar/systems directory. Currently, there are UNIX, IBM PC-compatible,
Macintosh, and Amiga Core War systems available there. It is a good idea to
check ftp://www.koth.org/corewar/incoming for program updates first.

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 www.koth.org. Generally, the older the program - the less likely
it will be ICWS compatible.

If you are looking for an ICWS'94 simulator, get pMARS, which is available
for many platforms and can be downloaded from:

   * ftp://ftp.csua.berkeley.edu/pub/corewar (original site)
   * ftp://www.koth.org/corewar (koth.org mirror)
   * ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/mirror (Planar
     mirror)
   * http://www.nc5.infi.net/~wtnewton/corewar/ (Terry Newton)
   * ftp://members.aol.com/ofechner/corewar (Fechter)

Notes:

   * If you have trouble running pMARS with a graphical display under Win95
     then check out http://www.koth.org/pmars.html which should have a
     pointer to the latest compilation of pMARS for this environment.
   * RPMs for the Alpha, PowerPC, Sparc and i386 can be found at
     ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/pmars-rpm/

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 www.koth.org:
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

pvms08.zip              pMARS v0.8 for VMS build files/help (req.
                        pmars08s.zip)
ApMARS03.lha            pMARS executable for Amiga (port of version 0.3.1)
wincor11.zip            MS-Windows system, shareware ($15)

[ToC]
  ------------------------------------------------------------------------

10. Where can I find warrior code?

To learn the game, it is a good idea to study previously posted warrior
code. The FTP archives have code in the ftp://www.koth.org/corewar/redcode
directory. A clearly organized on-line warrior collection is available at
the Core War web sites (see below).

[ToC]
  ------------------------------------------------------------------------

11. I do not have FTP. How do I get all this great stuff?

There is an FTP email server at bitftp@pucc.princeton.edu. This address may
no longer exist. I haven't tested it yet. Send email with a subject and body
text of "help" (without the quotes) for more information on its usage. Note
that many FTP email gateways are shutting down due to abuse. To get a
current list of FTP email servers, look at the Accessing the Internet by
E-mail FAQ posted to news.answers. If you don't have access to Usenet, you
can retrieve this FAQ one of the following ways:

   * Send mail to mail-server@rtfm.mit.edu with the body containing "send
     usenet/news.answers/internet-services/access-via-email".
   * Send mail to mailbase@mailbase.ac.uk with the body containing "send
     lis-iis e-access-inet.txt".

[ToC]
  ------------------------------------------------------------------------

12. I do not have access to Usenet. How do I post and receive news?

To receive rec.games.corewar articles by email, join the COREWAR-L list run
on the Koth.Org list processor. To join, send the message

     SUB COREWAR-L FirstName LastName

to listproc@koth.org. You can send mail to corewar-l@koth.org to post even
if you are not a member of the list. Responsible for the listserver is Scott
J. Ellentuch (ttsg@ttsg.com).

Servers that allow you to post (but not receive) articles are available.
Refer to the Accessing the Internet by E-Mail FAQ for more information.

[ToC]
  ------------------------------------------------------------------------

13. Are there any Core War related WWW sites?

You bet. Each of the two KotH sites sport a world-wide web server.
Stormking's Core War page is http://www.koth.org; pizza's is
http://www.ecst.csuchico.edu/~pizza/koth . Damien Doligez (a.k.a. Planar)
has a web page that features convenient access to regular newsletters (Push
Off, The '94 Warrior, Core Warrior) and a well organized library of
warriors: http://para.inria.fr/~doligez/corewar/. Convenient for U.S. users,
this site is also mirrored at koth.org.

[ToC]
  ------------------------------------------------------------------------

14. What is KotH? How do I enter?

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@koth.org is maintained by Scott J. Ellentuch
(tuc@ttsg.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

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

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

     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
     daemon and you won't get mail back. Using ";name" is mandatory on the
     Pizza hills.

     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-94, ;redcode-b, ;redcode-lp, ;redcode-x,
     ;redcode, ;redcode-94x or ;redcode-94m. The former four run at "pizza",
     the latter three at "stormking". More information on these hills is
     listed below.

   * Mail this file to koth@koth.org or pizza@ecst.csuchico.edu. "Pizza"
     requires a subject of "koth" (use the -s flag on most mailers).

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

   * 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 25 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 25 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.

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.

                                          Duration  Max.
     Hill Name      Hill  Core    Max.     Before  Entry     Min.   Rounds   Instr.
                    Size  Size Processes                   Distance Fought    Set
                                            Tie    Length
 Pizza's ICWS '94
 Draft Hill                                                                 Extended
 (Accessed with       25  8000       8000    80000    100       100     200 ICWS '94
 ";redcode-94")                                                             Draft
 Pizza's Beginner's                                                         Extended
 Hill (Accessed       25  8000       8000    80000    100       100     200 ICWS '94
 with ";redcode-b")                                                         Draft
 Pizza's
 Experimental                                                               Extended
 (Small) Hill         25   800        800     8000     20        20     200 ICWS '94
 (Accessed with                                                             Draft
 ";redcode-x")
 Pizza's Limited
 Process (LP) Hill                                                          Extended
 (Accessed with       25  8000          8    80000    200       200     200 ICWS '94
 ";redcode-lp")                                                             Draft
 Stormking's ICWS
 '88 Standard Hill
 (Accessed with       20  8000       8000    80000    100       100     250 ICWS '88
 ";redcode")
 Stormking's ICWS
 '94 No Pspace Hill
 (Accessed with       20  8000       8000    80000    100       100     250 ICWS '94
 ";redcode-94nop")
 Stormking's ICWS
 '94 Experimental                                                           Extended
 (Big) Hill           20 55440      55440   500000    200       200     250 ICWS '94
 (Accessed with                                                             Draft
 ";redcode-94x")
 Stormking's ICWS
 '94 Multi-Warrior                                                          Extended
 Hill (Accessed       10  8000       8000    80000    100       100     200 ICWS '94
 with                                                                       Draft
 ";redcode-94m")

Note: Warriors on the beginner's hill are retired at age 100.

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.

At "pizza", you can use ";redcode[-??] test" to do a test challenge of the
Hill without affecting the status of the Hill. These challenges can be used
to see how well your warrior does against the current Hill warriors.

All hills run portable MARS (pMARS) version 0.8, a platform-independent Core
War system available at www.koth.org.

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

   * LDP - Load P-Space
   * STP - Store P-Space
   * 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

[ToC]
  ------------------------------------------------------------------------

15. 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 (in source
code) under ICWS'88 rules and strictly compliant assemblers (such as KotH or
pmars -8) will not let you have a DAT 0, 0 instruction in your source code -
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.

[ToC]
  ------------------------------------------------------------------------

16. 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 (core 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.

[ToC]
  ------------------------------------------------------------------------

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

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.

[ToC]
  ------------------------------------------------------------------------

18. What is P-space?

P-space is an area of memory which only your program's processes can access.
The contents of each memory location are preserved between rounds in a
multi-round match.

P-space is in many ways different from the core. First of all, each P-space
location can only store one number, not a whole instruction. Also, the
addressing in P-space is absolute, ie. the P-space address 1 is always 1
regardless of where in the core the instruction containing it is. And last
but not least, P-space can only be accessed by two special instructions, LDP
and STP.

The syntax of these two instructions is a bit unusual. STP, for example, has
an ordinary value in the core as its source, which is put into the P-space
field pointed to by the destination. So the P-space location isn't
determined by the destination address, but by its value, ie. the value that
would be overwritten if this were a MOV. So STP.AB #Q, #R would put the
value Q into the P-space field R mod PSPACESIZE. Similarly,

        stp.b  2, 3
        dat    0, 0
        dat    0, 9
        dat    0, 7

would put the value 9 into the P-space field 7. LDP works the same way,
except that now the source is a P-space field and the destination a core
instruction. The P-space location 0 is a special location. It is initialised
to a special value before each round. This value is:

   * -1 (or CORESIZE-1) at the beginning of the first round
   * 0 if the program died in the previous round
   * The number of surviving programs if the program did not die in the
     previous round

This means that for one-on-one matches, loss=0, win=1 and tie=2.

The default size of P-space is 1/16 of the core size. This size is the value
of the predefined variable PSPACESIZE. The addresses in the P-space wrap
around just like in the core, ie. you can store a value from 0 to CORESIZE-1
in each P-space location. All P-space values (except for location 0) are 0
initially.

[ToC]
  ------------------------------------------------------------------------

19. What does "Missing ;assert .." in my message from KotH mean?

This means you have omitted an ";assert" line in your submission. ";assert"
is used to specify which environments your code will work under or was
designed for. For example, if your warrior was written for the '94 draft
hill then you can put:

;assert CORESIZE==8000

in your code, meaning that an error will occur if you attempt you compile
the code for a different core size. If you don't want to use the features of
";assert" and you want to get rid of the annoying warning just put:

;assert 1

in your code, which means it will compile unconditionally.

[ToC]
  ------------------------------------------------------------------------

20. How should I format my code?

The way you format your code is really your own choice in the end. If you
are new to the game then use the style you feel most comfortable with.
However, using a common format helps others to understand your code quicker.
Most players tend to use the following conventions when writing code:

   * use lower case for location names and opcode names
   * don't add opcode modifiers if you don't need to, eg. add.ab #1, #2 is
     the same as add #1, #2
   * use whitespace after every comma
   * use tabs to align the opcodes, the instruction field(s) and any
     comments
   * do not use $ (direct addressing mode) or : (suffix of some labels)

[ToC]
  ------------------------------------------------------------------------

21. Are there any other Core War related resources I should know about?

Using genetic algorithms to generate warriors has been attempted by a number
of people. There are a number of resources available for people who are
interested in doing some experimentation:

   * There is a Core War genetic algorithms mailing list at
     corewar-ga-request@sunsite.auc.dk. The FTP site for this list is at
     ftp://sunsite.auc.dk/pub/local/corewar/. The administrator is Martin
     Pedersen (martin.pedersen@person.dk).
   * Jason's Core War project page
     (http://www.avalon.net/~jboer/projects/corewar/corewar.html) contains a
     C program which can evolve warriors, along with some previously
     generated warriors.
   * Core Wars Genetics: The Evolution of Predation by John Perry can be
     found at http://www.koth.org/evolving_warriors.html.
   * The most recent paper on Core War evolution is by Ryan Coleman and can
     be found at
     http://www.geocities.com/CapeCanaveral/Launchpad/6898/paper.html.

[ToC]
  ------------------------------------------------------------------------

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

(References to an X-like program mean that the term X is derived from the
specific program X and has become a generic term).

Binary launch
     One of several means to start an imp-spiral running. The fastest launch
     technique, but requires the most code. See also JMP/ADD Launch and
     Vector Launch.

         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

Bootstrapping
     Strategy of copying the active portion of the program away from the
     initial location, leaving a decoy behind and making the relocated
     program as small as possible.

B-Scanners
     Scanners which only recognize non-zero B-fields.

         example   add #10, scan
         scan      jmz example, 10

c
     Measure of speed, equal to one location per cycle. Speed of light.

CMP-Scanner
     A Scanner which uses a CMP instruction to look for opponents.

         example   add step, scan
         scan      cmp 10, 30
                   jmp attack
                   jmp example
         step      dat #20, #20

Colour
     Property of bombs making them visible to scanners, causing them to
     attack useless locations, thus slowing them down.

         example   dat #100

Core-Clear
     Code that sequentially overwrites core with DAT instructions; usually
     the last part of a program.

Decoys
     Bogus or unused instructions meant to slow down scanners. Typically,
     DATs with non-zero B-fields.

Decrement Resistant
     Property of warriors making them functional (or at least partially
     functional) when overrun by a DJN-stream.

DJN-Stream (also DJN-Train)
     Using a DJN command to rapidly decrement core locations.

         example   ...
                   ...
                   djn example, <4000

Dwarf
     The prototypical small bomber.

Gate-busting (also gate-crashing)
     technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0,
     2668) with a standard one to overrun imp-gates.

Hybrids
     warriors that combine two or more of the basic strategies, either in
     sequence (e.g. stone->paper) or in parallel (e.g. imp/stone).

Imp
     Program which only uses the MOV instruction.

         example   mov 0, 1

     or

         example   mov 0, 2
                   mov 0, 2

Imp-Gate
     A location in core which is bombed or decremented continuously so that
     an Imp can not pass. Also used to describe the program-code which
     maintains the gate.

         example   ...
                   ...
                   spl 0, <example
                   dat <example, #0

Imp-Ring
     A minimal Imp-Spiral.

         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

Imp-Spiral
     An Imp-like program with two or more processes supporting each other. A
     three-point spiral, with six processes running in this sequence:

         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

Incendiary Bomb
     A type of Stun bomb which creates a SPL 0 carpet.

         example   spl 0, 8
                   mov -1, <-1

JMP/ADD Launch
     one of several means to start an imp-spiral running. The slowest launch
     technique, but requires the least code. See also Binary Launch and
     Vector Launch.

         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

Mirror
     see reflection.

On-axis/off-axis
     On-axis scanners compare two locations M/2 apart, where M is the memory
     size. Off-axis scanners use some other separation.

Optimal Constants
     (also optima-type constants) Bomb or scan increments chosen to cover
     core most effectively, i.e. leaving gaps of uniform size. Programs to
     calculate optimal constants and lists of optimal numbers are available
     at www.koth.org.

Paper
     A Paper-like program is one which replicates itself many times. Part of
     the Scissors (beats) Paper (beats) Stone (beats Scissors) analogy.

P-Warrior
     A warrior which uses the results of previous round(s) in order to
     determine which strategy it will use.

Pit-Trapper
     (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.

Q^2 Scan
     A modern version of the Quick Scan where anything found is attacked
     almost immediately.

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:

          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

Reflection
     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:

                 spl   1
                 mov   -1, 0
                 spl   1                ;generate 6 consecutive processes
         silk    spl   3620,   #0       ;split to new copy
                 mov   >-1, }-1      ;copy self to new location
                 mov   bomb,   >2000 ;linear bombing
                 mov   bomb,   }2042    ;A-indirect bombing for anti-vamp
                 jmp   silk,   {silk    ;reset source pointer, make new copy
         bomb    dat   >2667,  >5334  ;anti-imp bomb

Slaver
     see Pit-Trapper.

Stealth
     Property of programs, or program parts, which are invisible to
     scanners, accomplished by using zero B-fields and reflections.

Stone
     A Stone-like program designed to be a small bomber. Part of the
     Paper-Scissors-Stone analogy.

Stun
     A type of bomb which makes the opponent multiply useless processes,
     thus slowing it down. Example is referred to as a SPL-JMP bomb.

         example    spl   0
                    jmp   -1

Two-Pass Core-Clear (also SPL/DAT Core-Clear)
     core clear that fills core first with SPL instructions, then with DATs.
     This is very effective in killing paper and certain imp-spiral
     variations.

Vampire
     see Pit-Trapper.

Vector Launch
     one of several means to start an imp-spiral running. As fast as Binary
     Launch, but requiring much less code. See also JMP/ADD Launch and
     Binary Launch. This example is one form of a Vector Launch:

         sz      EQU   2667

                 spl   1
                 spl   1
                 jmp   @vt, }0
         vt      dat   #0, imp+0*sz ; start of vector table
                 dat   #0, imp+1*sz
                 dat   #0, imp+2*sz
                 dat   #0, imp+3*sz ; end of vector table
         imp     mov.i #0, sz

[ToC]
  ------------------------------------------------------------------------

23. Other questions?

Just ask in the rec.games.corewar newsgroup or contact me. If you are shy,
check out the Core War archives first to see if your question has been
answered before.

[ToC]
  ------------------------------------------------------------------------

Credits

Additions, corrections, etc. to this document are solicited. Thanks in
particular to the following people who have contributed major portions of
this document:

   * Mark Durham (wrote the original version of the FAQ)
   * Paul Kline
   * Randy Graham
   * Stefan Strack (maintained a recent version of the FAQ)

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

Copyright � 1999 Anton Marsden.

Verbatim copying and distribution of this entire article is permitted in any
medium, provided this notice is preserved.
  ------------------------------------------------------------------------


From: sayembara@gmail.com
Subject: Re: Adressing modes
Date: 27 Feb 2006 01:38:05 -0800
Message-ID: <1141033084.973292.104430@z34g2000cwc.googlegroups.com>

It is *whom* to initiate or lead the initiative :) First to allocate
tasks to volunteers of course.

BTW, SPD is too dangerous, for example:

spd 4000, #8000
spd 2000, #8000
spd 1000, #8000
spd
spd
spd
.
.
.

where it can't be killed until the next 8000 steps. couple with silk,
it will be a new adventure.



From: =?ISO-8859-2?Q?=A3ukasz_Adamowski?= <corewars@wp.pl>
Subject: Re: Adressing modes
Date: Tue, 28 Feb 2006 09:49:42 -0500 (EST)
Message-ID: <44044414be8eb@wp.pl>

Dnia 27-02-2006 o godz. 11:18 sayembara@gmail.com napisa�(a):
> 
> BTW, SPD is too dangerous, for example:
> 
> spd 4000, #8000
> spd 2000, #8000
> spd 1000, #8000
> spd
> spd
> spd
> .
> .
> .
> 
> where it can't be killed until the next 8000 steps. couple with
> silk, it will be a new adventure.

Immortality, cool. :]
I suggest changing the instruction to IMM. ;]
Greetings
Lukasz A

-= "War is a problem, never a solution" =-
-= "Wojna jest problemem, a nie rozwiazaniem" =-


----------------------------------------------------
Interaktywna wystawa HI-TECH z Tokio ODKRYWANIE CZASU 
nauka, eksperyment, zabawa -> Warszawa, Pa�ac Kultury i Nauki
do 29.11.2006 wspania�a rozrywka dla ca�ej rodziny!
http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fczas.html&sid=677