Subject: KotH source with graphics
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: Mon, 3 Feb 1992 00:08:28 GMT
Message-ID: <1992Feb3.000828.3242@iWarp.intel.com>

I have finally finished the first part of my X windows interface for King of
the Hill corewar.  If anybody wants it, just send me a mail request and I'll
send you a shar file of the sources.  It seems to work fine on my system with
X11R5.  I'm not sure if I used X11R5-specific stuff or not; I doubt it because
I didn't do all that much.

   This does have switches to let you run on the experimental hill, ICWS '88,
or a few other variants with differing core sizes, etc.

   As I add more features or corewar variants, I'll post notices and release
newer versions.
				-Bill (wms@iwarp.intel.com)



Subject: Re: No bombers here.
From: kwhyte@dickson.uchicago.edu (Kevin Whyte)
Organization: Dept. of Mathematics, Univ. of Chicago
Date: 3 Feb 92 04:33:57 GMT
Message-ID: <1992Feb3.043357.1259@midway.uchicago.edu>

In article <1992Feb2.154255.12368@herkules.sssab.se> pausv@sssab.se (Paul Svensson) writes:

>And this is how it does agains everyone else...
  
 I imagine it would massacre Sargent.  Do you have the
results against Kinch (a far improved Sargent)?  For 
those who are curious, the idea Kinch was based on is:

 Search through memory for non-zero B fields.  If you
find one, bomb with jumps to a piece of code which first
changes the search code to make it bomb all of core with
dat 0's, and the splits like mad.  The idea here is that
once something actually jumps to the piece of code you
have set up for it, it will quickly be so slow as to be
useless ... thus just mop up, making sure not to miss
anything.  As far as I can tell, if it finds code you
execute, you are dead.  The reason it got pushed off the 
hill is that it was long enough that the best programs
would find it before it found them.  I am currently
working on a more robust version, which should be at #1
any day now :).


>Paul Svensson   _   /|   - Every absurdity needs a champion to defend it -
>SM5SJS          \'o.0'   Scandinavian System Support    Fax: +46 13 115193
>paul@sssab.se   =(___)=  Box 535        _             Phone: +46 13 111660
>sunic!sssab!paul   U     SE-581 06  Linkoping, Sweden  Home: +46 13 121021


Kevin



Subject: MUTAGEN /PAR
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 3 Feb 92 07:30:17 GMT
Message-ID: <1992Feb3.073017.29502@vuse.vanderbilt.edu>

Here's MUTAGEN /PAR, which was tied for first place a week ago on the
standard hill for a few hours, but got quickly pushed to the lower ranks.
It's a single-process bomber that also creates some confusion by decrementing
two core-addresses per loop at long interval. It does fairly well against
larger bombers, vampires and XTC-style scanners.

;redcode
;name MUTAGEN /PAR
;author Stefan Strack (stst@vuse.vanderbilt.edu)
;strategy laces the core with crippling point-mutations and cleans up
;strategy the debris with systematic deletions (parallel version)

dist    equ     422

start   mov     <start-1, <start-1
        add     #dist,  loc
loc     djn     start,  <0
        jmp     start

        end     start



Subject: Walze
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 3 Feb 92 07:33:11 GMT
Message-ID: <1992Feb3.073311.29729@vuse.vanderbilt.edu>

This is Walze (german for {steam}roller), last I checked somewhere in the
middle of both the standard and the -x hill. Walze is simply an imp and a
mod-2 bomber that doubles as an imp-stomper. The imp is separated by a large
DAT #0 stretch to avoid triggering JMZ-scans. Primitive, but surprisingly
effective.

;redcode
;name Walze
;author Stefan Strack (stst@vuse.vanderbilt.edu)
;strategy Submitted: @date@

impstop EQU     start-14
bomb    EQU     impstop+1

start   SPL     imp
        SPL     bomber
bomber  MOV     bomb,   <impstop
        JMP     bomber, <impstop
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
        DAT     #0
imp     MOV     imp,    imp+1

        END     start



Subject: Trinity Zwo
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 3 Feb 92 07:35:47 GMT
Message-ID: <1992Feb3.073547.29862@vuse.vanderbilt.edu>

The last installment, Trinity Zwo, is a hybrid between MUTAGEN /PAR and
Walze. It starts off launching a long-interval B-field decrementer, a mod-2
bomber, and an imp. As the imp gets about half-way thru the core, the
decrementing process falls thru and joins the mod-2 bomber/imp-stomper to
catch even single-process opponents subverted by the imp. Trinity Zwo never
made it above rank 7 on the standard hill and is currently somewhere in the
lower half of the -x hill.

;redcode
;name Trinity Zwo
;author Stefan Strack (stst@vuse.vanderbilt.edu)
;strategy     1) Decrements B-operands at large intervals
;strategy     2) Cleans up debris with imp
;strategy     3) Finishes off with mod-2 bomber/imp-stomper
;strategy (Version 2.0: smaller, should tie less)
;strategy Submitted: @date@

DIST    EQU     212
impstop EQU     trinity-12
bomb    EQU     trinity-8

trinity SPL     bomber
        SPL     imp
mutagen ADD     #DIST,  decrem
decrem  DJN     mutagen,<decrem
bomber  MOV     bomb,   <impstop
        JMP     bomber, <impstop
imp     MOV     imp,    imp+1

        END     trinity



Subject: KotH weekly update
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: Mon, 3 Feb 1992 17:40:23 GMT
Message-ID: <1992Feb3.174023.15313@iWarp.intel.com>

Well, it's Monday again.  Here's the current hill:
  W/  L/  T                                      Name   Score
232/190/ 18                                 SplitBomb     714
215/161/ 64       Snow White and the Seven Dwarfs 1.2     709
203/139/ 98                                    CAKE B     707
209/194/ 37                                 Leech 1.2     664
205/197/ 38                                  Copy 1.4     653
194/190/ 56                                SmallDat D     638
193/191/ 56                             Sleepless 1.2     635
180/193/ 67                                     Walze     607
193/234/ 13                              Scanner 1.21     592
194/236/ 10                               Scanner 1.2     592

As you can see, Sleepless 1.2 has been dropping down the list and Splitbomb
has gained the #1 position.  Here's the ";strategy" for splitbomb:
;strategy Slows the opponent down, and then unleashes a single deadly dwarf
;strategy to finish the job nicely.  Uses "spl -1" similar to XTC, but in a
;strategy more efficient way, and much, much faster.  Does well against many
;strategy splitters and bombers, but does poorly against mice and leech.

And for the experimental hill:
  W/  L/  T                                      Name   Score
215/104/121                                 CLONER II     766
237/172/ 31                                  QUARTER8     742
203/185/ 52                         Schizo parasite-x     661
194/176/ 70                                    csapda     652
199/212/ 29                                 Cat's Paw     626
185/189/ 66                                     Walze     621
174/170/ 96                               Trinity Zwo     618
183/195/ 62                                 Leech 2.0     611
138/108/194                                ramscoop-x     608
182/197/ 61                                Cat Paws B     607

I'm not sure as to whether I posted the strategy for Cloner II before; in any
case, here it is:
;strategy	quickly copies itself to a new location, splits, and then
;strategy	searches for a new location to copy itself.

Well, that's the hill for now!  For entry instructions or the KotH source code,
send mail to me.
				-Bill (wms@iwarp.intel.com)



Subject: EBS Valentine Tournament
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Mon, 3 Feb 1992 18:10:55 GMT
Message-ID: <16782AB4F.DURHAM@ricevm1.rice.edu>

I received six votes total with respect to double-elimination versus
round robin.  The final tally is DE 4, RR 2.  Thus the tournament will
be double-elimination.

Deadline for entry is February 14th.  Send one Redcode program to me at
durham@ricevm1.rice.edu by that date to enter.  Because a DE tournament
requires more active participation by the entrants, I will be working
hard to accomodate any scheduling conflicts (Spring Break, etc.).  Let
me know of conflicts ASAP so I can inform your opponent.

Mark A. Durham
MAD



Subject: Thanx!
From: conjgr@lut.ac.uk (Neil Robertson)
Organization: Loughborough University, UK.
Date: 3 Feb 92 16:34:29 GMT
Message-ID: <1992Feb3.163429.11949@lut.ac.uk>

I got an amazing ammount of help (9 replies) when I put my program on here      and asked if anyone could tell me what was wrong so instead of e-mailing
those people individually (simply havent the time) I'd like to say a big
THANX to all of you.Unfortunately having tryed all combinations of all the
hints & tips it still doesnt work so I have a sneaking suspicion that the
assembler is duff.Oh well.

I have 2 questions (unrelated to the above) about corewars in general

1.Does an END statement take up an address in the core or does the
  assembler discard it?

2.What is the point in having DAT statements? Surely just a value at
  position X in memory is all thats required.
  eg instead of -  DAT #3
                   MOV -1 @-1
                   ADD #1 -2
                   JMP -2
     
     just have  -  3
                   MOV -1 @-1
                  ADD #1 -2 etc....

Neil Robertson
LUT 
Leicestershire
England



Subject: Re: No bombers here.
From: pausv@sssab.se (Paul Svensson)
Organization: Scandinavian System Support AB
Date: 3 Feb 92 21:45:25 GMT
Message-ID: <1992Feb3.214525.24773@herkules.sssab.se>

In posting <1992Feb2.154255.12368@herkules.sssab.se>
Paul Svensson <pausv@sssab.se> writes:

>I'll give y'all a little more time to knock Sleepless 1.2 off the hill
>before posting the source (and sending in 1.3).
>A little more information to help you along:

Okay, you deserverd it :)
Sargent beat Sleepless 40 to 0,
and knocked it off the hill.


target		DAT	#0,	#0
bomb		DAT	#0,	#0
		;
sleepless	MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		SPL	0,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		MOV	bomb,	<target
		JMP	bomb,	<target
		;
		END	sleepless

-- 
Paul Svensson   _   /|   - Every absurdity needs a champion to defend it -
SM5SJS          \'o.0'   Scandinavian System Support    Fax: +46 13 115193
paul@sssab.se   =(___)=  Box 535        _             Phone: +46 13 111660
sunic!sssab!paul   U     SE-581 06  Linkoping, Sweden  Home: +46 13 121021



Subject: ARMY
From: conjgr@lut.ac.uk (Neil Robertson)
Organization: Loughborough University, UK.
Date: 4 Feb 92 15:41:28 GMT
Message-ID: <1992Feb4.154128.1842@lut.ac.uk>

I realise that this approach has probably been taken befor but I thought I'd
put this program on here anyway.

;ARMY by Neil Robertson
;strategy - copy itself to a location 300 ahead then bomb either side of  
;strategy - itself using dwarfs which are reset when there bomb runs are
;strategy - getting close to the next copy of army

	dat #22
	dat #300
start:  mov <-2,<-1
	jmn start,-3
	mov #22,275
	mov #300,275
        spl 275 
        spl check
	jmp dwfs
 datd:  dat #-9
 dwfs:  spl 5
	mov -2,@-2
	sub #7,-3 
	jmp -2
 datu:  dat #9
	mov -1,@-1
	add #7,-2
	jmp -2
check:	slt #250,datu
	jmp -1
	mov #-9,datd
	mov #9,datu
	jmp check 
	end start	



Subject: Crobots Tourny: ROUND 2+3 RESULTS
From: <JJJ101@psuvm.psu.edu>
Organization: PSU
Date: Tuesday, 4 Feb 1992 13:41:31 EST
Message-ID: <92035.134131JJJ101@psuvm.psu.edu>

I ran round 2 and round 3 together. Only round 4 is left to play.
Once again, the actual output from rounds 1-3 can be obtained
from jesensky@endor.cs.psu.edu.


Author(s)                  Program             Round1  Round 2+3  Total
---------                  -------             ------  ---------  -----
Chris Beauregard           Seeker v1           1104     2265      3369
    and Royce Vaughn Fay
James Jesensky             Stush Version 1.0    756     1467      2223
Eugene Hu                  Hitnrun              717     1425      2142
Steve Patrick              Cruiser              261      531       792
Greg Bailey                RUNGUN               222      423       645
J. Pekkanen                HeatSeeker 1.8        39       72       111
Ray Cromwell               Marksman V2           27       66        93
Gary Haussmann             Fred 1.0               6       18        24
David Richter              Trial 4                9       12        21
Ray Cromwell               Ambush                 6        0         6



Subject: FTP site soda.berkeley.edu
From: blojo@xcf.berkeley.edu (Jon Blow)
Organization: University of California, Berkeley
Date: 5 Feb 1992 19:51:28 GMT
Message-ID: <30hrgje9hsdfghfgdwkhas@scam>

The machine soda.berkeley.edu went down recently due to a drastic hardware
failure.  Consequently, the Core War ftp and archive site has been
inaccessible for about 72 hours.

The Core War data will be restored as soon as the machine comes back up,
which will hopefully be tomorrow, Thursday 5 Feb 1992.

 -Jon



Subject: Crobots Tourny: FINAL RESULTS
From: <JJJ101@psuvm.psu.edu>
Organization: PSU
Date: Wednesday, 5 Feb 1992 14:07:42 EST
Message-ID: <92036.140742JJJ101@psuvm.psu.edu>

Here are the final results:


Final Scores...

Author(s)                 Program          Rounds 1-3  Round 4  Final
---------                 -------          ----------  -------  -----
Chris Beauregard          Seeker v1          3369       1098    4467
    and Royce Vaughn Fay
James Jesensky            Stush Version 1.0  2223        771    2994
Eugene Hu                 Hitnrun            2142        732    2874
Steve Patrick             Cruiser             792        267    1059
Greg Bailey               RUNGUN              645        195     840
J. Pekkanen               HeatSeeker 1.8      111         36     147
Ray Cromwell              Marksman V2          93         30     123
Gary Haussmann            Fred 1.0             24          3      27
David Richter             Trial 4              21          6      27
Ray Cromwell              Ambush                6          3       9



Subject: Re: EBS tournament 14th Feb
From: scc@rlgvax.Reston.ICL.COM (Stephen Carlson)
Organization: International Computers Limited, Reston, Virginia, USA
Date: 5 Feb 92 23:45:13 GMT
Message-ID: <1992Feb5.234513.22165@rlgvax.Reston.ICL.COM>

In article <1992Jan31.133553.6353@dcs.glasgow.ac.uk> fraserc@dcs.glasgow.ac.uk (Campbell Fraser) writes:
>e.g. XTC is a very effective program and will probably do very resectably if
>entered and the tournament is a round robin. However there will certainly be
>a number of programs capable of beating it which could put it out after the
>second round if XTC is drawn against them.

I have a program that was specifically designed to beat xtc.  In fact, it
even made it on the Hill for about ten rounds.  The program is called B2,
named after the stealth bomber:

;redcode verbose
;name B2
;author S.C. Carlson
;strategy Low-profile bomber
b2      add #45,ptr
        jmp 3
        dat #0
        dat #0
        mov sbomb,@ptr
        jmp 3
sbomb   dat #0
        dat #0
        mov dbomb,<ptr
        jmp b2
dbomb   dat #0
        dat #0
ptr     dat #2


Every fourth instruction of this program has a non-zero B-field.  This means
that from the get-go, xtc has only a 25% chance of even detecting it.
Furthermore, only two out of every four addresses are executed, so pattern
bombers modulo 4, like dwarf, have only a 50% chance of hitting it from the
initial position.  Also, its eventual bombing pattern is very thorough: in
the end 50% of all locations are bombed.

The disadvantages are primarily slowness and impotency against mice-like
programs.  The "jmp 3" instructions slow down the program making it about
half of the speed of dwarf and other single threaded bombers.  An updated
version (with the "sbomb spl 0" instruction at line 7) can sometimes beat
mice (with a maximum process limit of 64), the added advantage of a being a
split bomber for this program is marginal.  The updated version did not make
on the Hill.  I think this is because the Hill evolved away from bombers.

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



Subject: Re: FTP site soda.berkeley.edu
From: jjstrout@miavx1.acs.muohio.edu
Organization: Miami University, Oxford, OH
Date: 7 Feb 92 13:09:09 GMT
Message-ID: <1992Feb7.080909.8979@miavx1.acs.muohio.edu>

In article <30hrgje9hsdfghfgdwkhas@scam>, blojo@xcf.berkeley.edu (Jon Blow)
writes:

> The Core War data will be restored as soon as the machine comes back up,
> which will hopefully be tomorrow, Thursday 5 Feb 1992.

Well, it's back up, but it seems to be having trouble.  Yesterday all day I got
a "too many users, try again later" message... this may have in fact been true,
but considering the frequency of my attempts, I tend to doubt it.

This morning I connected, but it wouldn't talk to me.  When I send just my
email address as password (without a dash), I get friendly messages, but
commands such as "cd" or "ls" either repeat the messages or have no effect at
all.  When I put a dash before the password, I see no messages and get no
response to my commands, either.

Is there any other archive site for CoreWar info?  Would anybody who has some
introductory documents (e.g., the ICWS '88 standard) be willing to post or mail
them, or make them available on another ftp site?  I'm sure soda.berkeley.edu
will iron out the bugs in its system in time, but meanwhile I'm trying to get
started in Core War and it's very frustrating.

Any help is greatly appreciated.

|o|    /////    Joe Strout          Text> JJSTROUT@MIAVX1.ACS.MUOHIO.EDU   |o|
|o|   | @ @     Miami University    NeXT>  JSTROUT@ROGUE.ACS.MUOHIO.EDU    |o|
|o|   C   >     Oxford, OH 45056  Flames> JS5JSANU@MIAMIU.ACS.MUOHIO.EDU   |o|
|o|    \ o      USA                Dames> JJSTROUT@SORRY.IM.ALREADY.TAKEN  |o|



Subject: Re: FTP site soda.berkeley.edu
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 8 Feb 92 07:48:25 GMT
Message-ID: <167871983.DURHAM@ricevm1.rice.edu>

soda seems to be working fine for me, except that when I connected I
was placed one directory above where I am used to being.  What would
have been /corewar is now /pub/corewar.

MAD


Path: overload.lbl.gov!dog.ee.lbl.gov!network.ucsd.edu!usc!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!ohstpy!miavx1!jjstrout
From: jjstrout@miavx1.acs.muohio.edu
Newsgroups: rec.games.corewar
Subject: Two Redcode questions from novice
Message-ID: <1992Feb7.213624.8998@miavx1.acs.muohio.edu>
Date: 8 Feb 92 02:36:24 GMT
Organization: Miami University, Oxford, OH
Lines: 16

I'm a novice to Core War.  I have Mark Durham's Redcode Introduction, but
there is a point or two which is not quite clear...

1. In ICWS'88, JMP allows both operands.  What, exactly, does the B operand DO?

2. Also in ICWS'88, immediate B-modes are not allowed with CMP and SLT.  Why?
How are we expected to, say, compare a counter to a value (i.e., 
CMP @cntr,#16) ... do we have to store the value 16 in a DAT statement
somewhere and reference it by label?  Isn't there a better way?

Thanks for your help... and wish my first creation ("Dumbo") luck in KotH!

|o|    /////    Joe Strout          Text> JJSTROUT@MIAVX1.ACS.MUOHIO.EDU   |o|
|o|   | @ @     Miami University    NeXT>  JSTROUT@ROGUE.ACS.MUOHIO.EDU    |o|
|o|   c  _)     Oxford, OH 45056  Flames> JS5JSANU@MIAMIU.ACS.MUOHIO.EDU   |o|
|o|    \ o      USA                Dames> JJSTROUT@SORRY.IM.ALREADY.TAKEN  |o|



Subject: Re: Two Redcode questions from novice
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Sat, 8 Feb 1992 16:53:59 GMT
Message-ID: <167879955.DURHAM@ricevm1.rice.edu>

In article <1992Feb7.213624.8998@miavx1.acs.muohio.edu>
jjstrout@miavx1.acs.muohio.edu writes:
>1. In ICWS'88, JMP allows both operands.  What, exactly, does the B operand DO?
>2. Also in ICWS'88, immediate B-modes are not allowed with CMP and SLT.  Why?

Well, the answer to question 1) is that the B-operand does not DO anything
unless the B-mode is Predecrement Indirect (in which case the B-operand
decrements memory).  But storing data in unused operands is a very good way
to trim code size by eliminating several DAT statements.

The answer to question 2) is that Immediate B-modes were considered to be
meaningless for MOV, CMP, SLT, etc. by Mr. William R. Buckley (Director of
the ICWS at the time) and Mr. Thomas Gettys (Standards Focal of the ICWS
at the time).  I strongly disagreed.  I strongly favor a symmetric instruction
set.  But my gentle persuasion could not sway them.  (Neither did my ranting
and raving which followed).

Unfortunately, only a handful of people (one hand's worth or so) voted on
ICWS'88.  Anyone interested in having a vote in the next ICWS standard
should be sure to join the ICWS.  I'll be certain to post more about the
ICWS when the current transfer of the Directorship has been finalized.

Of course, you all have a say in what is going into the next draft and I
personally appreciate all of the interest shown on the net in possible
changes.  The experimental hill is just one very big example.

Mark A. Durham
MAD



Subject: Valentine Tournament Reminder
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Sat, 8 Feb 1992 17:13:36 GMT
Message-ID: <167879DE1.DURHAM@ricevm1.rice.edu>

I only have four (4) submissions for the Valentine's tournament.  I know
you are all trying to put the finishing touches on your best programs,
but I really would like to receive at least four more submissions and
preferably twelve more for a total of sixteen.  Of course, if I have
two-hundred and fifty six submissions, that is fine to.  Any power of two
will do nicely.

Send mail for more info, or just send me your submission.  Thanks!
Mark A. Durham
MAD



Subject: KotH corewar for the PC available at soda
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: Tue, 11 Feb 1992 06:50:23 GMT
Message-ID: <1992Feb11.065023.21434@vuse.vanderbilt.edu>

Thought some of you might find this useful: I just finished porting Bill
Shubert's King of the Hill corewar program to DOS (I don't have access to
X-Windows and, besides, my boss doesn't like games at work :-( ). All
switches are implemented (including "experimental hill" of course), except
for display slowdown.

I have uploaded the DOS executable to soda.berkeley.edu as

pub/corewar/{incoming|systems}/kothpc.zip

 Length  Method   Size  Ratio   Date    Time   CRC-32  Attr  Name
 ------  ------   ----- -----   ----    ----   ------  ----  ----
   3004  Implode   1790  41%  02-10-92  00:52  3dfce260 --w  README
  20353  Stored   20353   0%  02-10-92  04:46  8e980c38 --w  KOTH.EXE
 ------          ------  ---                                 -------
  23357           22143   6%                                       2

Mail me for a uuencoded copy if you don't have FTP-access.

Miscellaneous:

. compiled using Turbo C 1.5, small memory model; exec size 20353 bytes
(lzexe-compressed). Runs in 76K memory (!); tested under DESQView and
Windows. 500 to 1000 instructions/sec on my 386SX/20MHz PC-clone.

. reclaimed storage from the Redcode parser and reduced storage size
of core addresses from 10 to 5 bytes to fit everything into a 64K data
segment.

. substituted the X-Windows display with a simple color-textmode display
(similar to CoreWar Pro) using direct-video writes for speed.

. interpreter can be interrupted to show the current score, refresh the
display (if in display mode) or exit. No debugger (yet?)

Direct all bug reports to me, as I'm sure that Bill's original source was
bug-free :-)

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



Subject: Dwarfer II
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Organization: Ohio University CS Dept., Athens
Date: 11 Feb 92 13:16:30 GMT
Message-ID: <4904@oucsace.cs.OHIOU.EDU>

Once again, I post some more of my Redcode, in an effort to promote the
sharing of code between Core War programmers.  I hope that beginners will 
be able to learn from the code, and experts will be able to write more 
effective code from the strategy my programs include. 

The program below is my Dwarfer program with an Anti-Leech program stuck to
the front of it.  I submit it every once in awhile when I get sick of the 
leech programs taking control of Koth.  This will most certainly force much
better Leech programs to be created and to become immune to such attacks, such
as Rat B for instance, which is also currently on the Koth board.

;redcode verbose
;name Dwarfer II
;author Scott Adkins
;
;strategy Kills any leech-like programs and copies a dwarf program to every
;strategy 400 memory locations.  It also repairs all of the dwarves as they
;strategy get hurt, and provides itself with a bit of split bomb immunity.
;
bomb	dat	#0,	#0
trace	dat	#0,	#0

start	spl	dwarf

find	jmz	find,	<bomb
	add	@bomb,	catch
	mov	#0,	catch
catch	mov	#0,	0
	add	catch,	trace
	add	trace,	bomb

reap	mov	bomb,	<bomb
	jmp	reap

dwarf	mov	d2,	<dst
	mov	d1,	<dst
	spl	@dst
	add	#400,	dst
	jmp	dwarf

d0	dat	#0,	#0
d1	mov	d0,	d0
d2	jmp	d1,	<d1

dst	dat	#0,	#400
	end	start



Subject: Splitbomb
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Organization: Ohio University CS Dept., Athens
Date: 11 Feb 92 13:22:54 GMT
Message-ID: <4905@oucsace.cs.OHIOU.EDU>

Here is a program that did so well, that I didn't have a heart to change it
and make it Splitbomb V1.2 or something like that.  The heart of the program
is the searching and the slowing down of its enemy in much the same way that
XTC does it.  I must say, XTC does a fair job of converting from split bombing
mode to dat bombing mode, by the use of a simple pointer.  All my efforts to
do such a thing in smaller code proved useless... making splitbomb more and 
more vulnerable to its own and XTC's attacks with each change.  So, I now just
slow them down with SPL -1 statments, like XTC, but with twice the size... 
I use 44 of then (I think) instead of 23.  To finish the job off, I was forced
to use a Dwarf to clean the memory out.  I was really surprised how well it
did, but as always, the Koth board does change away from certain types of 
programs...

;redcode verbose
;name SplitBomb
;author Scott Adkins
;
;strategy Slows the opponent down, and then unleashes a single deadly dwarf
;strategy to finish the job nicely.  Uses "spl -1" similar to XTC, but in a
;strategy more efficient way, and much, much faster.  Does well against many
;strategy splitters and bombers, but does poorly against mice and leech.
;
bomb1	spl	-1

start	add	#412,	dest
dest	jmz	start,	dest

kill	mov	#44,	loop+1
	mov	dest,	20
loop	mov	bomb1,	<19
	djn	loop,   #44
look	spl	dwarf,	bomb1-1
	jmp	start

dwarf	mov	bomb2,	<look
	jmp	dwarf

bomb2	dat	#0,	#0
	end	start



Subject: Corporate Program
From: nautilus@acm.rpi.edu (John M. Twilley)
Date: Wed, 12 Feb 1992 00:52:31 GMT
Message-ID: <+_hsa#_@rpi.edu>


This program reminds me of a corporation:
 
Seven hard-working drones who do nothing but look for a non-zero B field.
One administrator who does nothing but look for a drone who has found
something, then bombs where the worker tells it to.
:-)

Seriously, this is my first attempt at writing MARS code for no other
purpose but to experiment.  This code uses semaphore-type signalling,
and loses miserably on the KotH.  Against stationary targets, it does
very well... those that don't fight back too hard, anyway...

(Maybe should have named it Federal Contract Program? :-) )
---
;redcode
;name Corporate Program
;author Jack Twilley
;----
;strategy This program is designed to copy off seven small portions
;strategy of code whose sole purpose is to find something abnormal.
;strategy If they do, then they set a flag in their routine to a 
;strategy non-zero value, and wait until it becomes zero again.  
;strategy The second part of the program scans each of the small 
;strategy portion's flags, and based on the response, bombs a 
;strategy certain portion of core heavily.  Having completed that, 
;strategy then it resumes scanning the other pointers.
;----
csize     equ 8000
num       equ 7                     ;Number of scanning programs
slen      equ (send-sstart+1)       ;Length of scanning program
dist      equ 1000                  ;(csize/(num+1)) - Distance between the programs
step      equ 5
stepx2    equ step*2
;----
; Scan unit
;----
sstart    add #step,          spoint
snext     jmn scall,          @spoint
spoint    jmp sstart,         #-1           
          dat #0,             #0
scall     add spoint,         send        
          jmn 0,              send
sback     jmp sstart,         0    
send      dat #0,             #0           
;----
; Copy-split unit
;----
cstart    add #dist+slen,     dest
          mov #send-2,        source
cloop     mov <source,        <dest
          cmp #sstart-1,      source
source    jmp cloop,          #source
dest      spl @dest,          sstart
cend      djn cstart,         #num
;----
; Bomb unit
;---- 
bstart    mov #dist-slen-14,  bdist
          mov #num,           bcount
bloop     jmn bkill,          @bdist 
bback     add #dist,          bdist
bcount    djn bloop,          #0
bbomb     jmp bstart,         #stepx2
bkill     mov @bdist,         btemp
          add bdist,          btemp
          add #step,          btemp
burp      mov btemp,          <btemp
          djn burp,           bbomb
          add #stepx2,        bbomb          
bexit     sub @bdist,         @bdist
          jmp bback,          #0
bdist     dat #0,             #0
btemp     dat #0,            #0
;----
          end cstart

-- 
John M. Twilley            |  Statistically, most authors _are_ dead...
nautilus@acm.rpi.edu       |          -- Time Magazine, about multiculturism



Subject: B-field scanners: what and how?
From: chu@sv001.sandiego.ncr.com (Patrick Chu)
Organization: NCR/Teradata, San Diego, CA
Date: 11 Feb 92 23:39:49 GMT
Message-ID: <1992Feb11.233949.9872@sv001.sandiego.ncr.com>


I've seen mention of B-field scanners, but really no explanation of
what they are.  Could someone give me an example of one and how to
code one?

Also, how do I get a copy of the ICWS newsletter?

Thanks.
--Patrick Chu			sv001!chu@ucsd.edu




Subject: scoring system
From: <ASMQK@ASUACAD.BITNET>
Organization: Arizona State University
Date: Monday, 10 Feb 1992 17:24:41 MST
Message-ID: <92041.172441ASMQK@ASUACAD.BITNET>

First every warrior play against every others. Let the number of programs 10.
Let the 10. warrior that one with the worst avarage point.
After that choose the 9. warrior using the same algorithm . So it does not
matter what did a warrior against the 10. warrior.
In the last turn there is only 2 warrior, and the better is the winner.
In this way a warrior cannot be the best program just because it does well
against poor warriors.
nandor    asmqk@asuacad.bitnet




Subject: Re: B-field scanners: what and how?
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: Wed, 12 Feb 1992 07:25:01 GMT
Message-ID: <1678B1402.DURHAM@ricevm1.rice.edu>

In article <1992Feb11.233949.9872@sv001.sandiego.ncr.com>
chu@sv001.sandiego.ncr.com (Patrick Chu) writes:
>I've seen mention of B-field scanners, but really no explanation of
>what they are.  Could someone give me an example of one and how to
>code one?
>Also, how do I get a copy of the ICWS newsletter?

A B-field scanner is any program which looks for opponent's by comparing
just the B-fields of instructions.  Since core is initialized in ICWS'88
with B-fields of zero, an instruction such as

   JMZ 0, <search    ; Loop here decrementing pointer until B-field of
                     ;    pointed-to instruction is non-zero.

can very quickly find an opponent who's B-fields are non-zero.

The Core War Newsletter is still in stasis awaiting the imminent transfer
of the Directorship of the International Core War Society.  I will post
info about both the ICWS and TCWN as soon as it is available.  I do
apologize for the enormously long wait.  Thank you for your patience.

Mark A. Durham
MAD



Subject: KotH quirk
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: Wed, 12 Feb 1992 21:07:31 GMT
Message-ID: <1992Feb12.210731.440@iWarp.intel.com>

   King of the Hill has been taking core dumps periodically.  I finally managed
to track it down to the point where it is clearly happening NOT during
tournament play (so the top 10 list is correct), but during mail handling.
Unfortunately, the stack seems to have become corrupted so dbx cannot produce
a lot of useful information.
   What I can tell is that the crash occurred while trying to compile a
program for the ICWS hill.  I'm fairly sure that some sort of return letter
got send the the originator of this program.
   If anybody entered a program into King of the Hill and got a bizarre letter
back (for example, one that said your program was rejected but didn't say why)
sometime between early Tuesday Feb. 11 and noon Wednesday Feb. 12 PLEASE let
me know.  In addition, if you submitted a program during that time and got
NO response back this may be the problem also.  Thanks.
				-Bill (wms@iwarp.intel.com)



Subject: X5 V1.2
From: acaldwel@bigbird.cs.ohiou.edu (Adam C. Caldwell)
Organization: Ohio University CS Dept., Athens
Date: 13 Feb 92 01:43:17 GMT
Message-ID: <4922@oucsace.cs.OHIOU.EDU>


;
; Since this program has been in the top 10 for a week or two, I
; decided I would post it here.
;
;author Adam Caldwell
;name X5 V1.2
;strategy unleash 3000 spl 0, #1 statements into the core
;strategy at 411 byte intervals.  Next, repair the damage
;strategy that this caused to my program and then sweep
;strategy through memory with the deadly dat #0,#0
start	mov	bomb, -1
	sub	#411, -1
	djn	start, #3000
	spl	0, #0
	mov	0, <0
	jmp	1, #0
	mov	0, <0

kill	mov	bomb1, <kill
	djn	kill, #-4
	jmp	1, #0
	mov	0, <0
	jmp	kill
bomb	spl	0, #1
bomb1	dat	#0, #0
	end	start



Subject: Signal (redcode example)
From: <JJJ101@psuvm.psu.edu>
Organization: PSU
Date: Wednesday, 12 Feb 1992 23:36:13 EST
Message-ID: <92043.233614JJJ101@psuvm.psu.edu>

Here's a program called signal. It should be obvious how it works.
It scored 399 on the Koth. I'm posting it because it uses an
interesting strategy.

;redcode verbose
;name Signal 1.1
;author James Jesensky

start    djn  start, <where  ;modify 1 memory location per instruction
         jmn  start, signal  ;check if we reached our own code
         mov  #1, signal     ;\
         mov  #7990, where   ; Yes, so reset data and continue.
         jmp  start          ;/
where    dat  #7990
signal   dat  #1
         end



Subject: New reader: could someone explain....
From: bootle@rigel.cs.pdx.edu (Lee Booth)
Organization: /etc/organization
Date: 13 Feb 92 04:27:09 GMT
Message-ID: <4736@pdxgate.UUCP>

Could someone explain what's going on?  I saw a version of corewar a LONG time
ago, and this is totally different...
TIA.   
(Reply via email to bootle@rigel.cs.pdx.edu)


Lee Booth       bootle@rigel.cs.pdx.edu  
STRESS = The confusion created when one's mind overrides the body's basic 
desire to choke the living daylights out of some jerk who desperately
deserves it.



Subject: Re: scoring system
From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser)
Organization: Glasgow University Computing Science Dept.
Date: 13 Feb 92 10:02:10 GMT
Message-ID: <1992Feb13.100210.27663@dcs.glasgow.ac.uk>

In article <92041.172441ASMQK@ASUACAD.BITNET>, ASMQK@ASUACAD.BITNET writes:
> First every warrior play against every others. Let the number of programs 10.
> Let the 10. warrior that one with the worst avarage point.
> After that choose the 9. warrior using the same algorithm . So it does not
> matter what did a warrior against the 10. warrior.
> In the last turn there is only 2 warrior, and the better is the winner.
> In this way a warrior cannot be the best program just because it does well
> against poor warriors.

Smart idea for a new scoring system. However the number of battles thus required
is very high. Perhaps 2 or 3 programs at the bottom could be taken of at a time.

Campbell <fraserc@dcs.glasgow.ac.uk>


-- 
---------------------------------------------------------------
 fraserc@dcs.glasgow.ac.uk |
---------------------------------------------------------------
| Mail   : Campbell Fraser, Department of Computing Science, |



Subject: Re: scoring system
From: stig@Lise.Unit.NO (Stig Hemmer)
Organization: Anarchy
Date: 13 Feb 92 14:36:18 GMT
Message-ID: <1992Feb13.143618.27618@ugle.unit.no>


In article <1992Feb13.100210.27663@dcs.glasgow.ac.uk>, fraserc@dcs.glasgow.ac.uk (Campbell Fraser) writes:
> Smart idea for a new scoring system. However the number of battles
> thus required is very high. Perhaps 2 or 3 programs at the bottom
> could be taken of at a time.
>
> Campbell <fraserc@dcs.glasgow.ac.uk>

Any pair of programs don't have to fight more than once. You could
just use the same battles for every round.

Stig 'Tortoise' Hemmer   aka   stig@lise.unit.no
I'm a member of The League for Programming Freedom.
Contact the League at league@prep.ai.mit.edu.
This is NOT a .signature virus. Do NOT copy it into your .signature



Subject: ICWS 1991 Tournament
From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser)
Organization: Glasgow University Computing Science Dept.
Date: 13 Feb 92 18:44:38 GMT
Message-ID: <1992Feb13.184438.4053@dcs.glasgow.ac.uk>

Has there been any announcement on the results of the 1991 ICWS tournament ?
If not, when can we expect one ?

Thanks

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



Subject: Re: ICWS 1991 Tournament
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 13 Feb 1992 19:29:39 GMT
Message-ID: <1678CBDCE.DURHAM@ricevm1.rice.edu>

In article <1992Feb13.184438.4053@dcs.glasgow.ac.uk>
fraserc@dcs.glasgow.ac.uk (Campbell Fraser) writes:
>Has there been any announcement on the results of the 1991 ICWS tournament ?
>If not, when can we expect one ?

No announcement yet.  It is my understanding that the tournament has yet
to be run.

When can you expect an announcement about the tournament?  My suggestion
is don't.  At least not until the transfer of the Directorship has taken
place.

I'm sorry.  I wish it were otherwise, but it is not and it is not in my
hands.

Mark A. Durham
MAD



Subject: djn 0,<x
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC-CH School of Medicine
Date: 14 Feb 92 05:27:07 GMT
Message-ID: <1992Feb14.052707.19433@samba.oit.unc.edu>


   I too have been playing around with this kind of instruction for a
little while.  I nickname it a "Djnie" (like the kind that comes out of a
bottle).  I submitted a prog to the hill which consisted of code which
copied five "djnies" throughout the core, split to each of them and died.
They looked like this:
     djn 0,<x   (x is any number)
     jmp -1,0   (in case they hit a xxx x,1)
This actually had a small degree of success and made it onto the hill
briefly a little while ago.  Unfortunately, it suffers primarily from
non-lethality; there is lots of stuff which will get plenty confused after
being hit, but which will not die.  As has been pointed out before in this
group, you aren't going to make it onto the hill by getting a lot of ties.
The one big advantage is its size; it needs a direct hit to take it out
(of course, programs which know about its existence will be sure to
sprinkle the occasional xxx x,1 around the core, making the djnie a two
instruction target).  
     -Andy
ajpierce@med.unc.edu



Subject: more short but destructive programs
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC-CH School of Medicine
Date: 14 Feb 92 05:38:34 GMT
Message-ID: <1992Feb14.053834.20373@samba.oit.unc.edu>


   While on the topic of short, yet effective, programs here is another I
have toyed with on occasion.  This is the meaty bit to the "Scanner"
series that was on the hill for a while a few weeks back (one of which was
briefly #1).

       mov <where,<where
       jmp -1,<where        (where 'where' is any specific place you like)

   This moves a memory location into the preceeding spot, skips one spot
and repeats.  Its big plus is that it is very fast:  it covers three
locations in two instructions (although only one gets hit).  With careful
choice of 'where' you can get interesting effects when the program "runs
over itself" and you can help insure it's continued survival by putting a
few jmp -1,0 instructions immediately after the executing code.  It also
suffers from non-lethality to a degree.  One version of the program I
wrote was designed to go through the core twice and then on the third time
self modify into:   mov dat,<x / jmp -1,0 in order to clear out the core.
Unfortunately, I think that this was too subtle for brute force rapid
pattern bombers (of which the Sieve series currently on the hill are such
an example).  I still like the idea though and am kicking around giving it
some mods and another whack at the hill.
     -Andy
ajpierce@med.unc.edu



Subject: Specialized Imp
From: rjc@geech.gnu.ai.mit.edu (Ray)
Organization: Free Software Foundation
Date: 15 Feb 92 02:19:32 GMT
Message-ID: <1992Feb15.021932.15769@mintaka.lcs.mit.edu>


  I've been pondering the use of this specialized imp lately. Briefly,
here's what it does.

 mov 	0 , <2

   The imp first decrements the address 2 ahead (which at first is dat #0,#0)
. The new address becomes `dat #0,#-1', then the imp moves to that address
which just happens to be one ahead of the current position. How is something
like this useful? It's not that useful except for one side effect
that it causes. If the imp collides with the beginning of a program it
decrements it's first instruction or pointer. Which could mutate
its behavior. The imp also dies on the first non-zero core location so
you can periodically toss them out and make sure they die and don't
over run you. Even better, you can bomb the core with them.



Subject: Nova.s
From: rjc@geech.gnu.ai.mit.edu (Ray)
Organization: Free Software Foundation
Date: 15 Feb 92 02:33:36 GMT
Message-ID: <1992Feb15.023336.16373@mintaka.lcs.mit.edu>


   This program has been on the list several times and a few months ago
held the #1-#4 position for almost a week.

;redcode-x verbose
;name Nova
;author Ray Cromwell
;strategy Start up an imp, then imp stomp
  
fence dat #0
     dat #0
     dat #0
     dat #0
     dat #0
     dat #0 
     dat #0

main spl part2
loop jmp loop, <fence
       dat #0,#0
       dat #0,#0
       dat #0,#0
       dat #0,#0
       dat #0,#0
ptr    dat #-100,#-100
       dat #0,#0
       dat #0,#0
       dat #0,#0
part2  spl impit
dwarf  mov ptr,<ptr
       jmp dwarf,<ptr
impit  spl imp
imp    mov 0,1
       end main





Subject: Threader
From: rjc@geech.gnu.ai.mit.edu (Ray)
Organization: Free Software Foundation
Date: 15 Feb 92 02:47:03 GMT
Message-ID: <1992Feb15.024703.16817@mintaka.lcs.mit.edu>


  The strategy for this program is to "thread" the core with jmp's that
jmp back through the core to the main program (and die). This event
is never really expected to happen, the real reason for "threading" the
core was to cause programs to die by their own fate. Vampires would
eventually execute their own fang, and so on. If any jmp's get over written
the opposing program, if it gets hit, will die by its own fate.

  Never the less, it only scored about 500 on both hills.

;redcode-x verbose
;author Ray Cromwell
;name Threader 2.0

jmp5  jmp 5,0
      dat #0,#0
      dat #0,#0
      dat #0,#0
      dat #0,#0
catch jmp 1
kill  spl -1
count dat #1580,1580
start sub #5,jmp5
      add #5,jmpn5
      mov jmp5,@jmp5
      mov jmpn5,@jmpn5
      djn start,count
      mov count,kill
      mov count,kill2
      spl imp
loop  mov catch-1,<catch-2
      jmp loop,<catch-2 
imp   mov 0,1
      spl 0
kill2 jmp -1
      dat #0,#0
      dat #0,#0
      dat #0,#0
      dat #0,#0
jmpn5 jmp -5,0
      end start



Subject: How to win with a losing warrior
From: Corey_Lynn_Nelson@cup.portal.com
Date: 15 Feb 92 06:51:39 GMT
Message-ID: <9202142251.1.28716@cup.portal.com>

---
	The non-transitive nature of Corewar, 
		- or -
	how to win with a losing warrior.


	My purpose in writing this is to point out one the problems with 
determining the "best" warrior, and possibly suggest some answers to a 
problem involved with it.  Basically the problem is the non-transitive 
nature of Corewar.

	While writing this, it occurred to me that there is no precise 
definition of how warriors are scored against each other.  For this piece I 
use the concept of "average score" to describe how two warriors perform 
against each other.  The average score for a warrior is theoretically 
computed by pitting the warriors against each other, going both first and 
second, from every possible distance.  The scores for all these battles are 
then averaged.  (A win is worth three, a tie one, a loss zero.)  In practice 
I calculated the average by running only about 100 battles.  When talking 
about tournaments, I assume that each warrior actually receives the average 
score when it is pitted against another, when actually in a tournaments, each
warrior is pitted against the others only a few times.  In a tournament with 
several warriors this is so close to the same score that the difference is 
negligible.

	For those who are not familiar with the concept, I'll define what I 
mean by non-transitive as it relates to Corewar. Stated simply, 
Non-transitive means that if A beats B, and B beats C then A does NOT 
necessarily beat C. For a more concrete example, consider the warriors 
Chalk, Dumbo and Echo.  (See the example code at the end of this message.)
It is easy to see that Chalk beats Dumbo, Dumbo beats Echo, and Echo beats 
Chalk.  There is no clear "Best" warrior of these three.  The non-transitive 
nature of Corewar makes it very difficult (some might say impossible) to 
pick the best warrior from a group.

	The non-transitive nature of Corewar can yield bizarre results.  For 
instance, Consider a contest between Alpha, Chalk And Dumbo.  When Alpha 
fights Chalk, Alpha's average is 3.0. When Chalk fights Dumbo, Chalk's 
average is 3.0.  When Alpha fights Dumbo, Alpha's average is about 2.3 and 
Dumbo's is about 0.7. The average tournament score for Alpha is therefore 
2.7 ((3+2.3)/2). The average for Chalk is 1.5 ((0+3)/2).  The average for 
Dumbo is 0.3 ((0+.7)/2).  It seems clear that Alpha is the better warrior,
(after all it beats Both of the others), but consider what happens when not 
one, but ten Dumbos are entered.  The average score for Alpha is now 2.32 
((3+10*2.25)/11), the average for each Dumbo is 1.3 ((0+.75+9*1.5)/11) and 
the Average for Chalk rises to 2.73! ((0+10*3.0)/11)  Chalk is the winner! I 
will refer to the technique of winning by beating your own warriors as
"Parasitism", and the warriors which lose to the parasite as "hosts", though 
"cheating" might be a more apt name for the whole process.

	Parasitism could be exploited to make even the most pathetic warrior 
a winning warrior.  For example if one were to enter Dumbo and 10,000 copies 
of Echo, then Dumbo would almost certainly win the contest.  The practice of 
splitting the tournament in two, with the top five warriors fighting  
separately seems to defeats this, but the same thing can still be done, 
though it's a bit harder.  To defeat a two level tourney, one must have 
three warriors like Bravo, Chalk, and Dumbo. Bravo and Chalk beat Dumbo,  
averaging 3.0 against it.  Bravo beats Chalk, so if Dumbo was entered 10,000 
times, Chalk four times and Bravo once, Bravo and Chalk would be the  
Finalists, with Bravo winning in a close match at the end.  Of course it's 
unlikely that anyone would even attempt to enter 10,000 copies of something, 
but even three or four Hosts could raise a Parasite's average enough to make 
the difference between second place and first.  

	What can be done to prevent this?  Limiting the number of warriors 
one is allowed to enter helps, though I suspect a dedicated person could find
someone willing to enter warriors for him, or simply enter it "anonymously." 
In practice I can't imagine any tournament that would allow someone to enter 
even two copies of the same warrior (except maybe a computer moderated one). 
I think most people barely have time to work on one good warrior, without 
trying to work on three, so the problem is very rare in any case.  One 
simple safeguard would be to have an extra elimination round.  In the 
elimination round, eliminate all warriors which averaged 1.5 or less 
(winning half the time).  Since a program can at best average 1.5 against 
itself, this would eliminate any warriors which didn't beat at least half of 
the other (non-copy) warriors.  This doesn't guarantee that hosts will be 
eliminated, but it makes it very likely that they will be.


; Alpha	- a wimpy varient of dwarf
ALPHA	MOV	BOMB	BOMB
	ADD	#3	ALPHA
	JMP	ALPHA
BOMB	DAT		0
	END	ALPHA

; Bravo - a speedy, but larger varient of mini-dwarf
BRAVO	MOV	BOMB	<PTR
	MOV	BOMB	<PTR
	MOV	BOMB	<PTR
	MOV	BOMB	<PTR
	JMP	BRAVO
PTR	DAT		BRAVO
BOMB	DAT		BRAVO
	END	BRAVO

;Chalk - a speedy, but larger varient of mini-dwarf
CHALK	MOV	BOMB	<PTR
	MOV	BOMB	<PTR
	MOV	BOMB	<PTR
	JMP	CHALK
PTR	DAT		CHALK
BOMB	DAT		CHALK
	END	CHALK

;Dumbo
DUMBO	MOV	BOMB	BOMB
	ADD	#2	DUMBO
	JMP	DUMBO
BOMB	DAT		0
	END	DUMBO

;Echo
SRC	DAT		0
ECHO	MOV	GAIT	GAIT+30	
E1	MOV	PTR	<PTR
	CMP	GAIT+30	GAIT+31		;Check for incoming
	JMP	E1			;If none, loop back
	MOV	#10	SRC		;Else, run away.
	MOV	#40	GAIT
S1	MOV	@SRC	<GAIT
	DJN	S1	SRC
GAIT	JMP	@GAIT
PTR	DAT		ECHO
	END	ECHO

--- Post Script --- 
I originally wrote this before there was a King of The Hill server, but much 
of it is relavent even for KotH.  I believe One could put a program on the 
top of the hill using paratisim, but it is much harder to do than in a 
regular tourney.  Still I wouldn't be surprised if some day soon ALL programs
on the hill (for a few minutes) were just one line- - - JMP 0. 


Path: overload.lbl.gov!agate!ucbvax!cup.portal.com!Corey_Lynn_Nelson
From: Corey_Lynn_Nelson@cup.portal.com
Newsgroups: rec.games.corewar
Subject: Proposed Modifications
Message-ID: <9202142254.1.28716@cup.portal.com>
Date: 15 Feb 92 06:54:29 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 230

---
        Here is a  partial list of suggested modifications to corewar.  I 
have listed them roughly in order from those I would like to see 
implemented, to those I want explored, and therefore feel are deserving of 
mention.  My arguments for these modifications, pro and con, follow.  I have 
tried to list only those modifications which make Redcode; less complex, 
clearer, less ambiguous, more consistent/complete, and/or smaller.  I am not 
particularly fond of the idea of changing corewar at all, (I have often 
remarked "I don't care what the rules are, just tell 'em to me in advance.") 
but it's better to make a few big changes than lots of small ones.

1.)     Create a classification system for tournaments which encompasses all 
arbitrary numbers.  I.e. a class "A" tournament would be fought in 8192 words
of core, with 64 processes for a maximum of 100000 cycles, warriors limited 
to 64 words with all warriors fighting all other warriors 6 times from 
random locations not less than 64 words from each other.  

2.)    Change the score reported for a warrior to the average score for that 
warrior.

3.)     Limit warriors to a specific size, larger warriors are truncated,
smaller warriors are filled with DAT instructions.  Warriors may not be 
loaded over another warrior (immediately after the end of the other warrior 
is O.K.).

4.)     Add the SKP (Skip n words) directive to the assembler.  The skip
directive is the same as N words of whatever core is initialized to.

5.)     Move the Jump field to the B-field, (Changing JMP, JMZ, JMN, DJN, 
and SPL) and eliminate immediate mode from the B-field.

6.)     Split MOV and CMP  into four instructions, MOV (move to B-field 
only), MVW (move whole word), CMP (compare with B-field) and CPW (compare 
word).

7.)     Redefine SPL to divide into two equal parts and have no effect on
other processes.  Whenever a process halts, the process(es) which alternated
with it run twice as often.  Processes can only add/subtract from processes 
in their own "family."  

Example:  Process P executes an SPL and becomes processes P1 and P2.  
Both P1 and P2 execute 1/2 as often as P0 did.  
P1 executes an SPL becoming P1a and P1b.  The order of execution is now 
P2 P1a P2 P1b P2 P1a P2 P1b etc.  Process P1a now executes an SPL becoming 
processes P1a1 and P1a2.  The order of execution is now  P2 P1a1 P2 P1b P2 
P1a2 P2 P1b P2 P1a1 P2 P1b P2 P1a2 P2 P1b etc. 

If process P1a1 halted the order of execution would become: 
 P2 P1a2 P2 P1b P2 P1a2 P2 P1b P2 P1a2 etc.
If process P1b halted the order of execution would become: 
 P2 P1a1 P2 P1a2 P2 P1a1 P2 P1a2 P2 P1b etc. 
If process P2 halted the order of execution would become: 
 P1a1 P1b P1a2 P1b P1a1 P1b P1a2 P1b etc. 

8.)    Add an EXC (exchange) instruction.  This would swap the A-field and
B-field of a location.

9.)     Un-modify ADD so that it does not affect the A-field.

10.)    Remove the JMP instruction.

11.)    Change the range of A and B to less than core (+127 to -128?)

12.)     Add the JOB instruction.  (JOB is actually two instructions, one for
each warrior, so CPW would not skip if warrior A's JOB instruction were CPW 
with warrior B's.)  JOB must be executed after (coresize*9) cycles and before
(coresize*10) cycles or that warrior losses.  Battles would run the full 
number of cycles, even if only one side is running.  If no JOB is executed, 
all warriors lose.  Scoring as follows: Sole winner- 3 points, Two winners- 
one point each, Zero winners- zero points each.


Arguments for the above.

1.)     This modification would help clarify one of the least clear aspects 
of corewar, how tournaments are run.  In the event that future tournaments 
change some of these numbers, it can be specified easily and given a new
classification (For example; a class "B" tournament might be fought in a
random core of size between 8000 and 8197, and a class "KotH_N" might have 
a core of 8000, and 8000 process, max. words of 100.)  What class the ICWS 
tournament is will of course still be debated, but at least some basis for 
comparison will exist.  Class info should include;
 Number of cycles until a draw,
 Instruction set used, (1988, 1986, KotH-X)
 Maximum number of processes (or maximum number of splits),
 Scoring for win tie and loss,
 Number of battles each warrior will fight (method of elimination),
 Maximum size of a warrior,
 and the separation (if any) between warriors.  
Are there any I missed?  If so they should be included.

2.)    This change is nice because it allows the scores from tournaments 
with vastly different numbers of warriors to be compared.  The information is
of course already available (just divide the score by the number of battles 
fought), but I would like to see more people use the average when talking 
about a warriors performance.  (I still like the W/L/T format for reporting 
just change the "total score" column to "average score".)  Knowing that the 
top warrior scored an average of 2.31 and the second place warrior scored on 
average 2.01 says a lot more about the warriors then knowing the top warrior 
scored 208, the second place warrior 181.  On the con side it takes four or 
five digits to meaningfully report an average instead of two or three for the
raw score, and it is also less precise.  

3.)     The reason for this is simple, it eliminates any unfair advantage a
larger program might have.  Without this rule it behoves a warrior to fill
every legal location, even if only to know that a warrior will not be loaded
there.  I suspect that some corewar systems will not allow warriors to be
loaded closer than 1024 words, they would obviously need to be changed if 
this modification is put into effect.

4.)     This directive improves things in two ways, first it provides a 
means of assembling the word that core is initialized to without knowing 
what value that word is.  Second, it allows for shorter and more readable 
program listings (Xtc could be listed in 12 lines instead of 22)   This is 
especially important if programs can be large, say 1000 words, since some 
programs will want to be in the middle or at the end of those 1000 words.

5.)     The major advantage here is the simplification of the language
specification.  By eliminating immediate from the B-field most of the
"Illegal" instructions are eliminated.  It isn't necessary to consider what
happens when JMZ #0 #2 is encountered, or rule that such an instruction is
"Illegal" the instruction simply doesn't exist.  The B-field can now be
thought of as the Destination field, and only DJN needs to handle the 
special case of an inappropriate immediate ("DJN #10 loop" would still have 
to be made illegal by exception.) Note that CMP #a #b is also eliminated by 
this.

        On the con side, this mod would require some programs to be 
rewritten. SLT $a #b is now impossible, (though it isn't really necessary, 
the B-val can be specified in a DAT statement at cost of one addition word.) 
Data values can no longer be stored in the B-field of JMP's (some people 
might think that's a plus.)  

6.)     This mod eliminates the current exception MOV and CMP have when
operating with Immediate data.  It also allows one to easily move the 
B-field only, from one location to another.  (My assembler ALREADY treats 
MOV and CMP as if they were these four instructions, converting MOV and CMP 
at load time.)  At a minimum, the fact that MOV and CMP operate on words 
when no immediate data is specified, and B-fields when immediates are 
specified, should be better documented.

7.)     This is perhaps the strongest point with me, though I list it here 
and not first because I can think of so many objections to it.  This 
modification would fundamentaly change the way many programs work.  several 
warriors would need to be modified somewhat to work and a few would need to 
be scrapped and rethought.  There is still a maximum (and arbitrary) number 
of SPL's allowed. (A process would be limited to some fraction of execution 
speed, say 1/1024)
        On the pro side, this eliminates my strongest objection to corewars, 
the fact that the two warriors are treated differently.  With this 
modification it is possible to imagine that both warriors were spawned from 
the same parent process.  This completely eliminates the need for process 
limitation, an SPL would neither gain nor lose cycles, (note that if SPL did 
either, then a warrior could gain unfair advantage by either executing it or 
forcing the other warrior to execute it.)  It is no longer bad for a warrior 
to split into just two processes, if one process is enslaved, the other 
process will still run at 1/2 speed.  No action except the code actually 
executed by a process actually affects the speed of that process (well, 
actually a process halting could speed up another process.)

8.)    The EXC instruction adds an ability currently lacking in redcode, a 
way to easily examine the A-field of an instruction.  ADD's ability to 
modify the A-field helps with half the problem, but half is worse than none.

9.)     Add was changed under the '88 standard so that it modified the 
A-field under certain circumstances.  This added yet another exception to 
the instruction set (ADD modifies the A and B fields except when the data is
immediate)  Further, this allows programs to modify the A-field of a
location, but provides no (convenient) way to examine the A-field of a
location.  instead of allowing programs to "hide" data in the A-field, some
more global change, such as allowing All instructions to operate on either 
the A-field or the B-field (or the EXC function), is called for.  Half a 
needed function is worse than no function at all.

10.)    JMP is a completely unnecessary instruction.  The only advantage it
offers is a tiny amount of clarity.  JMP N is a little clearer than JMZ #0 
N, but only a little, (a macro for JMP could be defined to be "JMZ #0")  If 
it were removed the instruction set would be more compact, and the number of 
exceptions (i.e. JMP <1 <1) would be reduced.

11.)    One justification given for this is that it would force programs to
move around.  This seems crazy to me, as if programs like mice aren't bad
enough, now only programs which move (like mice) can have ANY chance.  There
is one saving grace to this modification however, if the range were limited 
to a small value (say +127 to -128) then the A-field and B-field could be 
specified in fewer bits.  It also make core size less important, though not 
completely unimportant.

12.)	Several varients on the JOB instruction are possible, I have listed 
my favorite, but warriors might need to execute JOB least every N cycles in 
order to have their side win, or the last JOB executed determines the 
winner, or the first side to execute 2000 JOB's wins.  The key factor is 
that the instruction, not the process executing it, is what determines who 
wins and who loses.

	The JOB instruction adds a very interesting dimension to corewar.  
It nicely solves the problem of who should win if two slaver programs 
capture each other.  It adds an instruction to every program (Some people 
might consider this a minus) giving a slight edge to larger programs (the 
relative difference between a ten line and a twelve line program would drop 
from 10/12 to 11/13)  But mainly it somehow seems more appropriate, after all
the 
question shouldn't be can you keep running, but can you keep doing what you 
want.

         On the con side, JOB fundamentally changes the nature of corewars, 
I question whether it is the same game at all.  All warriors written 
previous to the JOB instruction would become obsolete.  It also causes 
tournaments to run longer (approximately 8 times as long) and adds another 
possible outcome to any battle.



         In summary I'll state my feelings about the modifications I have 
suggested.  On 1-4 I feel strongly that these things should be done.  They 
are basically good things, with little or no consequences what so ever.  On 
5-10 I feel that corewar would be better if these modifications were made, 
but I feel some trepidation about the possible consequences of such 
modifications.  For the most part I list them because I would rather see 
these modifications than some of the other modifications that have been 
proposed.  On 11-12, I do not feel that the good parts of these 
modifications overcome the bad.  There are good ideas in these suggestions 
however, and I hope they inspire someone to come up with something even 
better.

--- Post Script ---
This list has been trimmed down from the original 30 modifications to just 
those I actually like.  Depending on the kind of response I get from these, 
I may post the others.
---



Subject: Core War ftp site soda.berkeley.edu
From: blojo@xcf.berkeley.edu
Organization: Experimental Computing Facility, Univ. of California, Berkeley
Date: 15 Feb 1992 11:08:36 GMT
Message-ID: <asdgkfjh2398hsg@xcf>

The ftp site soda.berkeley.edu is down again because of continuing hard-drive
flakiness.  This is related to the problem which kept the machine down
for a few days earlier.  If the problem persists, I will move the Core War
archive to another machine.  More news as it happens.

  -Jon



Subject: Pun & MOV -(PC),-(PC)
From: karttu@mits.mdata.fi (Antti Karttunen)
Organization: MITS, Helsinki, Finland
Date: 15 Feb 92 03:18:39 GMT
Message-ID: <1992Feb15.031839.23857@mits.mdata.fi>

First the pun:

If you translate "Core War" literally to Finnish you get "ydinsota"
("core" = "ydin", "war" = "sota"). When you translate this back to
English you get the "Nuclear War"...

Then the MOV -(PC),-(PC)
This is one possible instruction in PDP-11, (in octal 014747).
As you can easily (?) see, it has peculiar effects. It is one word
program to move itself backward one word (= 2 bytes) by each execution step.
I.e., after the instruction is fetched from memory, the PC (program
counter) is incremented by 2. First -(PC) decrements it by two, back
to pointing to itself, then fetches the contents (instruction itself!),
decrements PC again by two, and puts itself there. And continues
from that point, ad crashium systemae. (<- Latin here is probably wrong! ;-)

It's a pity that redcode hasn't any addressing modes allowing this
kind of tricks. I wonder whether any other architectures allow that kind
of operations, (VAXen, 68k ?) as I understand that originally "Core War"
like games were played in actual computers, not in simulated ones.

Disclaimer: It's 5:17am here.

-- 
Antti J. Karttunen       A fork is a cold shiny tool
karttu@mits.mdata.fi     To pierce, tear and ingest (Agh! Agh! Agh!)



Subject: Valentine Tournament
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 17 Feb 92 08:33:55 GMT
Message-ID: <167902413.DURHAM@ricevm1.rice.edu>

The Valentine's Day Tournament (VDT) is under way!  I have twelve
entrants and am willing to accept three or four latecomers if I missed
someone (or you missed the VDT).

Entrants are:
   Stefan Haenssgen with Quarter
vs                                  (The battle of the Stefans)
   Stefan Strack with Trinity

   Nandor Sieben with Shark
vs
   Scott W. Adkins with SplitBomb

   Arne Henrik Juul with Rat
vs
   Adam C. Caldwell with X5

   Campbell Fraser with PiedPiper
vs
   S. Halvorsen with RoadRunner

   William Shubert with Leech
vs
   John Wetmiller with Wave

and

   Stig Hemmer with Vivor
vs
   Aleksey A. Baulin with Varjag


Strangely, all warrior names fall in the second half of the alphabet
(if you give me Leech).

The two Stefans swapped battles and will therefore have to play each
other again.  Same thing for Sieben and Adkins.  X5 won and tied Rat
to advance.  Same thing for RoadRunner over PiedPiper.  Wave self-
destructed twice allowing Shubert to advance.  Same thing happened
to Varjag vs Vivor with Hemmer advancing.  (Sorry for mixing
programmers and programs).

The next round is March 1st.  All programmers should have their
previous opponent's code as well as their upcoming opponent's previous
code.

Again, anyone that wants to join in - it is not too late.
Mark A. Durham
MAD



Subject: Re: How to win with a losing warrior
From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser)
Organization: Glasgow University Computing Science Dept.
Date: 17 Feb 92 11:06:57 GMT
Message-ID: <1992Feb17.110657.4448@dcs.glasgow.ac.uk>

In article <9202142251.1.28716@cup.portal.com>, Corey_Lynn_Nelson@cup.portal.com writes:

> 	My purpose in writing this is to point out one the problems with 
> determining the "best" warrior, and possibly suggest some answers to a 
> problem involved with it.  Basically the problem is the non-transitive 
> nature of Corewar.
>....
> 	Parasitism could be exploited to make even the most pathetic warrior 
> a winning warrior.  For example if one were to enter Dumbo and 10,000 copies 
> of Echo, then Dumbo would almost certainly win the contest.  The practice of 
> splitting the tournament in two, with the top five warriors fighting  
> ....

My conscience must be satisfied. My program Intangible Worm 88.2 made it to the
top of the hill half a dozen times. The first time it was because I entered a
small program called Weedeath which I knew would beat the B-field searchers,
one of which would keep pipping Intangible Worm 88.2 to the post. Plan worked
well, the worm went to the top for a round but Weedeath didn't stay on.

It's a fair cop

Campbell


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



Subject: superior scanning technique
From: kdmiller@m11-113-2.MIT.EDU (Kenneth D Miller)
Organization: Massachusetts Institute of Technology
Date: Mon, 17 Feb 1992 17:28:53 GMT
Message-ID: <1992Feb17.172853.4776@athena.mit.edu>

Here's a dirty trick I put together after examining such programs as SUD, 
ASI-R, and several others.  These programs keep track of two separate positons,
and comparing the contents.  If they're different, then you've found something.

However, this approach can be somewhat problematic.  You either have to 1.
figure out which spot is the one you want to hit (which takes time to 
calculate), or 2. hit both of them (big speed loss).

I thought to myself "hey, that's a really cool technique!", and simplified it
fairly well (don't know how well it works in the "Real World (tm)" ;), so
there is no further testing...if it's found, blow it up.  And it's great!
B-Field hiders get wasted just like everyone else.  Basically, if you have two
adjacent instructions that aren't the same, the program will get dumped on...

When I put the program on KotH, and it falls off (fairly likely), I'll post
the code to it.  It's a nice little Judo-like thing (use opponent's strength
against 'em)


Sorry if I'm wasting too much space, it's just that I really like my new
program.  It can kick my old one (CLONER II) around pretty hard...

-- 
kdmiller@athena.mit.edu   |  Yep, it's KENNY MILLER... 



Subject: CROBOTS team play
From: gyugyi@leland.Stanford.EDU (Paul Gyugyi)
Organization: DSG, Stanford University, CA 94305, USA
Date: Tue, 18 Feb 92 00:52:01 GMT
Message-ID: <1992Feb18.005201.2859@leland.Stanford.EDU>

I have experimented with an enhancement for the CROBOTS game.
It adds 16 globally read/writable registers of integer size.
Consider the registers as "Frequencies" and the values you
put in them as "signals" you transmit.  I added two primitives
transmit(frequency,signal) and receive(frequency).
As a simple example, consider a team of two robots.  Robot 1
has the job of scanning for a target, and when it finds one, it
places the target's x coordinate on frequency 0, and the y
coordinate on frequency 1.  Robot 2 just blindly fires at 
whatever position it reads from frequencies 0 and 1 while moving
around at high speed.  Robot 3, the enemy, can use Electronic
Countermeasures (Jamming) by writing random numbers to
random frequencies whenever it has a spare cycle or two.
Obviously Robots 1 and 2 could communicate by an error
correcting code, or use spread-spectrum trachiniques to jump
between frequencies in a way that appears random to others.

In addition, I'm considering adding missiles to the game.
When a robot fires a missile, you give the missile two
frequencies to listen to.  The missile travels to the
(x,y) position present on those frequencies, so you can correct
it's flight in mid-path.

It's a simple idea thathas a lot of potential and doesn't add
much complexity to the game.

-Paul Gyugyi
gyugyi@earthsea.stanford.edu



Subject: VDT Correction
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 18 Feb 92 03:43:49 GMT
Message-ID: <1679013195.DURHAM@ricevm1.rice.edu>

I made an error in assessing the behaviour of Aleksey Baulin's warrior
Varjag in a core size of 8000 versus 8192.  Varjag was indeed fine-tuned
to 8192 and does not properly function with a core size of 8000.  Thus,
with the kind permission of Stig Hemmer (who's program Vivor runs the
same in 8192 as 8000), I re-ran the Vivor/Varjag battles.

The new result is that Varjag wins both battles.  It is a truly
ingenious and complex warrior.  My apologies to Mr. Baulin for the
unexpected change in core size and its deleterious effect on his
program.

Those programmers affected by the change have been properly notified.

Mark A. Durham
MAD



Subject: Huge Nasty *BUG!!!* in Amiga MADgic Core
From: kdmiller@athena.mit.edu (Kenneth D Miller)
Organization: Massachusetts Institute of Technology
Date: 18 Feb 92 05:01:21 GMT
Message-ID: <1992Feb18.050121.27980@athena.mit.edu>

I was playing around with the Amiga MADgic core (cool Corewar proggy), and
found some pretty serious problems with it (maybe it's just old).

1.	The SLT (skip if less than) instruction is broken.  It works just fine
	in 'Trace' mode (single-step), but it REFUSES to skip in normal mode.
	This would be fine, if it werent for the fact that my program depends
	on this instruction.

2.	The program wedges for several minutes every now and then.  For example
	I load two programs into it, and then hit R-Amiga-G ("go"), and it
	just sits there comatose for a minute or so.  Then it goes.

3.	The program WILL NOT respond to any form of input (no menues, nothing.
	they are all ghosted out) while it's running a combat.  This really
	sucks when you're in 80000 cycle mode and the programs are obviously
	not going to kill each other (you have to wait it out).  The "Stop"
	menu item, therefore, is completely useless.

Do I just have a really old version, or is it that MARS doesn't like my A3000?

Problem #2 just suddenly showed up, and I don't understand why.  It works fine
for a while and then flakes out completely, sometimes even crashing.  Ugh.

It's a really great program, but it needs some fixes (maybe it's 2.0, but I
doubt it)

--
kdmiller@athena.mit.edu   |  Yep, it's KENNY MILLER... 
    ///                   |  DESTINED TO BE THE GREATEST PROGRAMMER
\\\///  Amiga Makes It    |          *** E V E R ! ! ! ***
 \XX/     Possible!       |     (or at least second-greatest...)



Subject: Re: CROBOTS team play
From: <JJJ101@psuvm.psu.edu>
Organization: PSU
Date: Tuesday, 18 Feb 1992 00:01:38 EST
Message-ID: <92049.000138JJJ101@psuvm.psu.edu>

In article <1992Feb18.005201.2859@leland.Stanford.EDU>,
gyugyi@leland.Stanford.EDU (Paul Gyugyi) says:
>
>I have experimented with an enhancement for the CROBOTS game...

Who wouldn't have a few cycles to spare to stop enemy robots
from communicated. I thought of similar ideas, and feel they
would interesting, for say 8 vs. 8 with an extra large battlefield.
But, these global variables must be private to robots not on
the same "team".

J.J.


Subject: Re: Huge Nasty *BUG!!!* in Amiga MADgic Core
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 18 Feb 92 06:54:28 GMT
Message-ID: <16791CE4.DURHAM@ricevm1.rice.edu>

Boy, that subject line REALLY hurt!  Because Mr. Miller posted here, and
because many of The MADgic Core's users read r.g.cw, allow me to reply.

In article <1992Feb18.050121.27980@athena.mit.edu>
kdmiller@athena.mit.edu (Kenneth D Miller) writes:
>1.	The SLT (skip if less than) instruction is broken...

Yup.  I accidentally reversed the sense of the comparison in GO mode.
More on GO mode below.

>2.	The program wedges for several minutes every now and then.  For example
>	I load two programs into it, and then hit R-Amiga-G ("go"), and it
>	just sits there comatose for a minute or so.  Then it goes.

Yup.  This is a KotH induced problem (sort of).  Until KotH, people
(including myself) were mostly content with 64 tasks per side.  With
8000 tasks, I (you and others) discovered much to my horror that dynamic
memory deallocation can be exponential.  I allocate a task node every time
an SPL is executed.  This allows you to change the task limit even
while a battle is occuring.  Because you may wish to continue a battle
after time has expired, I do not deallocate the memory until you load
new warriors or quit the program.  Intuition is buffering your Amiga-G.
If you check the menu, the item is ghosted.

I have done two things to fix this problem.  The first is that I have
changed the memory allocation so that deallocation is very fast and no
longer exponential.  The second is that I have added a wait pointer so
you'll know you are supposed to wait.

The MADgic Core v4.0 will be available on soda.berkeley.edu after this
next weekend - if soda is working by then.  I have fixed many other,
less likely to occur bugs as well as add some new features and SOUND!

>3.	The program WILL NOT respond to any form of input..

Nope.  Not a bug.  This is a FEATURE!  (Honest!)  It's even documented
in the manual.  Should I stop bothering with including a manual in the
archive?

But seriously, I should have documented it better.  I was so used to
players having older versions of The MADgic Core that I forgot new ones
would go instantly to the Go item without first contemplating the
lovely Continue item!  Ignore Go.  Just use Continue.  It does not have
the SLT bug, and you can use all of the menus and all of the windows
and even the Stop command.  I added Go to the version you are using
because I thought that perhaps people with faster Amigas (such as
yourself) would like a faster command than Continue.  Go sacrifices
all of the I/O (including Stop) to go as fast as possible.

There is a better solution - one I've included in v4.0.  I will be
including all of the non-graphical, speedy versions of MARS that I used
to offer seperately.  I will also include tournament Redcode and the
tournament manager program.  I am sure everyone will consider these
programs a great addition.  Just my way of saying thank you for
continuing to use The MADgic Core.  We all know that the Amiga is the
best computer for Core War.


>kdmiller@athena.mit.edu   |  Yep, it's KENNY MILLER...
>    ///                   |  DESTINED TO BE THE GREATEST PROGRAMMER
>\\\///  Amiga Makes It    |          *** E V E R ! ! ! ***
> \XX/     Possible!       |     (or at least second-greatest...)

Well, we can't all be the second-greatest programmer ever.  That is
my only excuse.  For those of you who use The MADgic Core, please
EMail to me FIRST, and then I'll post any necessary notices -
probably without a giant *BUG* in the subject line.  It breaks my heart....

Mark A. Durham
MAD



Subject: Re: Proposed Modifications
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Organization: Rice University, Houston, TX
Date: 18 Feb 92 07:31:32 GMT
Message-ID: <167911579.DURHAM@ricevm1.rice.edu>

Here are my thoughts on some of the suggested modifications.  I have
deleted much of the original posting (hopefully without losing any
pertinent information) and also merged the discussion with the presentation.

>>1.) Create a classification system for tournaments which encompasses all
>>       arbitrary numbers.

This seems harmless but unnecessary.  As long as the number of free
parameters in Core War remain small, it makes more sense to list all of
the parameters when announcing a tournament.  Otherwise, we will be seeing
many "What is a Class A tournament?"-type messages on rec.games.corewar.
A "standards" document for tournaments is a good idea though.


>>3.) Limit warriors to a specific size, larger warriors are truncated,
>>smaller warriors are filled with DAT instructions...

Because Core is initialized to DAT instructions, it hardly seems
necessary to "fill-up" small warriors with DAT instructions.  Warrior
size limits and initial warrior placement fall under the catagory of a
free tournament parameter.

SKP seems useful, but any skipped instructions would have to be considered
part of the warrior in determining warrior size.  What 4) giveth,
3) taketh away.


>>5.)     Move the Jump field to the B-field, (Changing JMP, JMZ, JMN, DJN,
>>and SPL) and eliminate immediate mode from the B-field.
>>5.)     The major advantage here is the simplification of the language
>>specification.  By eliminating immediate from the B-field most of the
>>"Illegal" instructions are eliminated.  It isn't necessary to consider
>>what happens when JMZ #0 #2 is encountered, the instruction simply
>>doesn't exist.

This modification does not eliminate illegal instructions.  Saying an
instruction "simply doesn't exist" is no different from branding an
instruction as illegal.  If you take the set of opcodes { DAT, MOV, ADD,
SUB, JMP, JMZ, JMN, DJN, CMP, SLT, and SPL } and the set of modes { #, $,
@, and < }, there are 176 (11 x 4 x 4) different instructions possible.
To simplify the language, eliminate exceptions - not instructions.  I
remain in favor of allowing all possible instructions.


>>6.)     Split MOV and CMP  into four instructions, MOV (move to B-field
>>only), MVW (move whole word), CMP (compare with B-field) and CPW (compare
>>word).
>>6.)     This mod eliminates the current exception MOV and CMP have when
>>operating with Immediate data.
>>9.)     Un-modify ADD so that it does not affect the A-field.

MOV and CMP operating on Immediate data are not exceptional.  ADD and SUB
are exceptional when operating on instructions (they do not modify opcodes
- and I'm not arguing they should).  Un-modifying ADD and SUB so that they
do not affect the A-field makes them even more exceptional (and I'm not
arguing they should not be).  I favor 9) but believe 6) unnecessary,
without merit, and based on a faulty and inconsistent premise.


>>7.)     Redefine SPL to divide into two equal parts and have no effect on
>>other processes.

There was a poll question about SPL posted on the net.  What were the
results?  They have not been posted yet.  I do not wish to re-engage in
the free-for-all that took place prior to the New Year over changing SPL
without knowing how many people favor SPL's current behaviour.


>>8.)    Add an EXC (exchange) instruction.  This would swap the A-field and
>>B-field of a location.

I am in favor of such an instruction.  The mnemonic should be XCH however,
for historical reasons.  XCH was the form in which it was first introduced
to Core War.


>>10.)    Remove the JMP instruction.

I'll appeal to history again and request that JMP remain.  It is an old
friend without whom Core War would be a lesser game, even if no one ever
uses it.


>>11.)    Change the range of A and B to less than core (+127 to -128?)

I am in favor of range limitation, but I am not in favor of specifying a
range as part of the standard.  It should remain a free tournament
parameter.  This has the added benefit of allowing Core War as it is played
today to continue (Range = CoreSize).


>>12.)     Add the JOB instruction.

Any warrior that can successfully (as defined by JOB) enslave an opponent's
warrior can successfully (as defined by current day Core War) kill off an
opponent's warrior.

JOB merely eliminates ties, rewarding a hollow numeric advantage by
declaring it a win.  As for me (OK, my warriors),
                  "Give me Victory, or give me Death".
                             Mark A. Durham
                                  MAD



Subject: Spaced
From: scst72@csc.liv.ac.uk (Mr. P. Lewin)
Organization: Computer Science, Liverpool University
Date: 18 Feb 92 13:55:57 GMT
Message-ID: <1992Feb18.135557.1157@and.csc.liv.ac.uk>

I was just browsing through the different topics and reading the occasional
letter when I saw this group and thought sounds interesting. After reading what
there was I think I sort of understand what goes on like:-

(a) Programs written in code are put in a buffer together and executed at the
same time to see which one kills the other?

(b) Is the code actual processor code or a psuedo code made for the purposes of
corewar?

(c) Forgive me if I've gotton it all wrong but I just think this sounds so cool!!!

(d) Where are the corewars fought and do they run constantly with the surviving
warriors permanantly in residence.

(e) Whats with the draw thing?

(f) Survival of the fittest and death to all enemys.

(g) Is it copyrighted?

(h) Has it been done on a personal computer yet?

(i) Whats with the program size restrictions, it is war isn't it!!!

(j) How is the processor time allocated?

(k) Is it similtaneous ie. Instructions are executed in parrallel or is it a case
of each program gets an instruction or so many words executed at a time.

(l) Is there like a PC for each warrior which keeps track of the current
instruction and the warrior dies when the PC can't execute.

(m) Please reply I need answers!!!!!

(n) Thanks!

(o) Phil Lewin!



Subject: Re: CROBOTS team play
From: gyugyi@leland.Stanford.EDU (Paul Gyugyi)
Organization: DSG, Stanford University, CA 94305, USA
Date: Wed, 19 Feb 92 00:39:51 GMT
Message-ID: <1992Feb19.003951.3918@leland.Stanford.EDU>

In article <92049.000138JJJ101@psuvm.psu.edu> <JJJ101@psuvm.psu.edu> writes:

>Who wouldn't have a few cycles to spare to stop enemy robots
>from communicated. I thought of similar ideas, and feel they
>would interesting, for say 8 vs. 8 with an extra large battlefield.
>But, these global variables must be private to robots not on
>the same "team".

Well, if you go to more than 4 robots, you'll have to increase
the number of frequencies correspondingly, say to 256.  With
enough frequencies, and some good intelligence, I could
write comm software that you'd have a very low chance of jamming.
A cycle is a cycle.  If you've got cycles to spare, you're
probably not doing things like plotting the course of your enemy
and prediciting where to fire, etc.
Having 256 frequecies for a 4 player game greatly reduces the chance
of jamming, and it isn't as "fun".  Having private registers is
no fun at all.
-gyug



Subject: Re: Huge Nasty *BUG!!!* in Amiga MADgic Core
From: jmichael@killer.rain.com (Jesse Michael)
Organization: Guido's Public Access, Portland, Or.
Date: 18 Feb 92 23:55:52 GMT
Message-ID: <703@killer.rain.com>

Same thing happens on my 500 with one meg...

I also had problems with the file requester (ie: patterns not working, program freezing up...)

-Jesse



Subject: Re: CROBOTS team play
From: JJJ101@psuvm.psu.edu
Organization: PSU
Date: 19 Feb 92 01:56:12 GMT
Message-ID: <92049.205612JJJ101@psuvm.psu.edu>

In article <1992Feb19.003951.3918@leland.Stanford.EDU>,
gyugyi@leland.Stanford.EDU (Paul Gyugyi) says:

>Having 256 frequecies for a 4 player game greatly reduces the chance
>of jamming, and it isn't as "fun".  Having private registers is
>no fun at all.

I see your point now. For 8 vs. 8, though, 256 would be the minimum.


J.J.



Subject: Freeze-x! and "Oh no, yet another bug"
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 19 Feb 92 03:22:08 GMT
Message-ID: <1992Feb19.032208.22621@vuse.vanderbilt.edu>


In our series of somewhat successful KotH warriors, here's Freeze-x!
Optimized to beat CLONER II on the -x hill, Freeze-x! does well against
mice-type programs in general. The program scans for non-zero B-fields
and drops a JMP 0 bomb there to paralyze. When the bomb is re-encountered
on the next sweep (or any address with BVal=1), Freeze-x! switches to
kill-mode and drops DAT 0's.

;redcode-x
;name Freeze-x!
;author Stefan Strack
;strategy Bomb with JMP 0, then with DAT 0
;strategy Submitted: @date@

dist    equ     211
scanptr equ     (scan-3)

scan    add     #dist+1,scanptr    ; simple imptrap
        jmz     scan,   <scanptr
        slt     #bomb-scanptr,scanptr
        jmp     scan
        slt     #1,     @scanptr   ; is this a bomb?
        mov     bomb+1, bomb
        mov     bomb,   @scanptr
        jmp     scan
bomb    jmp     bomb,   #1

        end     scan

On the topic of bug-reports: I've received a couple of inquiries as to
why the DOS-port of KotH corewar sometimes aborts with the message
"Out of memory creating new thread". DOS memory constraints put a limit
to the maximum number of threads a program can spawn off. This limit
is significantly lower than the KotH default of 8000 (ca. 700 for the
standard hill, half that for the experimental). If koth.exe aborts,
rerun the game with a smaller thread maximum using the "-maxprocs nnn"
switch.

Just to prevent the imminent "A huge, nasty bug" post ...  :-)

-Stefan (stst@vuse.vanderbilt.edu)



Subject: Re: CROBOTS team play
From: pwh@bradley.bradley.edu (Pete Hartman)
Organization: Bradley University
Date: 19 Feb 92 03:10:20 GMT
Message-ID: <1992Feb19.031020.1823@bradley.bradley.edu>

In <1992Feb18.005201.2859@leland.Stanford.EDU> gyugyi@leland.Stanford.EDU (Paul Gyugyi) writes:
>Obviously Robots 1 and 2 could communicate by an error
>correcting code, or use spread-spectrum trachiniques to jump
>between frequencies in a way that appears random to others.

How hard would it be to "jam" the firing robot's coordinates
into this?  Doesn't sound like it would be hard at all....first
blow up the scanner, then the firing robot, or take over the firing
robot yourself.  Sounds pretty insecure if you use blind reading....

-- 
Pete Hartman		       Bradley University	pwh@bradley.bradley.edu
   Suppose that you were an idiot and suppose you were a member of congress.
                              But I repeat myself.



Subject: Huge Nasty *BUG!!!* in my brain... ;)
From: kdmiller@athena.mit.edu (Kenneth D Miller)
Organization: Massachusetts Institute of Technology
Date: 20 Feb 92 01:37:47 GMT
Message-ID: <1992Feb20.013747.16213@athena.mit.edu>

In article <16791CE4.DURHAM@ricevm1.rice.edu> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes:
>Boy, that subject line REALLY hurt!  Because Mr. Miller posted here, and
>because many of The MADgic Core's users read r.g.cw, allow me to reply.

See the title line.....sorry Mark, I really do like your program, but I was
tired and frustrated when I wrote this (My harddrive was acting up, among
other things...)


>Well, we can't all be the second-greatest programmer ever.  That is
>my only excuse.  For those of you who use The MADgic Core, please
>EMail to me FIRST, and then I'll post any necessary notices -
>probably without a giant *BUG* in the subject line.  It breaks my heart....
>
>Mark A. Durham
>MAD

Sorry, I just happened to be at a terminal when I was writing.

Hmm...I wonder if "poison cursor letter" describes what I did?

Or maybe I just post too much...?

Or maybe I need to just chill out, even?
--
kdmiller@athena.mit.edu   |  Yep, it's KENNY MILLER... 



Subject: moral programming?
From: un035300@wvnvms.wvnet.edu
Organization: West Virginia Network for Educational Telecomputing
Date: 20 Feb 92 10:19:29 GMT
Message-ID: <1992Feb19.222618.2404@wvnvms.wvnet.edu>

I am fairly new to the hill and I was wondering if someone could explain
what, and how a "leech" program might work. The other question I have is
about designing a program. Is it frowned on to copy bits and peices of
other people's programs to create your own? Should you give credit to who
ever wrote the code you took? I have a program on the experiment hill
(middle earth 1.4) that is bits and peices of code I saw posted and thought
looked interesting.  I can't understand a lot of the instructions people
use but i just keep changing the distance that the program moves through
memory untill it does better against the hill then it did the time before.

Thanks for any advise........

Rob Shultz
UN035300@WVNVMS.WVNET.EDU



Subject: CROBOTS stuff
From: cpbeaure@descartes.waterloo.edu (Chris Beauregard)
Organization: University of Waterloo
Date: 20 Feb 92 13:53:51 GMT
Message-ID: <1992Feb20.135351.29509@descartes.waterloo.edu>



First off.  About the concept of communications in CROBOTS.  You might check
out RoboWar on the Mac.  I can't remember exactly how it works, but they use
about 16 channels for communication.  I don't think those channels are
jameable, though, so having a larger number with jamming isn't too bad an
idea.  



Someone mentioned something about missiles in CROBOTS.  I thought of an
idea of how to use them that just has me shivering with glee.  It involves
a serious change in how program are written, and definitely makes the 
game a touch more fun.

Programmable drones.

Basically, they're smaller robots which get some intelligence systems.
They have limited scanning ability (say, 60 degree arc cetered on their
heading) but a higher top speed and a much higher turning speed.

We need to add a few commands to the game though.

exit() - Causes the process in question to self-destruct, with a rather
		 large explosion.

fork() - Basically, it splits off a new process, copying over the code for
		 the current process.  All the processes of a robot share the
		 CPU time, similar to Core Wars.  This is similar to the unix
		 command, having the return value of the new process and such.

launch() Takes the intelligence of the current process, puts it in a
		 drone, and drops it out of the robot.  Don't, and I mean don't,
		 accidentaly drop your robots main program like this.

Now, let's try some code/pseudo-code.

First, the typcal missile, launched from the main robot in a certain
direction...

while(1)
	if((range=scan(sc,20))>700) /* at 700-, we use the cannon, eh... */
	{
		if(fork()==0)	/* the new process - the drone - has zero */
		{
			launch(sc);
			drive(sc,100);	/* go for the target */
			while(1)
			{
				if(((range=scan(sc,20))!=0)&&(range<40)) /* within expl rng */
					exit();
				else if((range=scan(sc+=20,20))>0)
					drive(sc,100);
				else if((range=scan(sc+=320,20))>0)
					drive(sc,100);
				else
					exit();	/* lost target...too bad */
			}
		}

.....		/* main process continues here */

That was basically a smart missile.  Tracks the target in question, and
when it's within explosion range, torches it.  Also, to make sure it
doesn't keep slowing down the main robot, it explodes when it loses the target.

The next bit is a drone landmine function.  

...
...
dropmine()
{
	int hdg,timer,range;

	if(fork())
		return;
	
	launch();
	timer=5000;	/* give the main robot a chance to get away */
	while(--timer);
	while(1)
	{
		if(((range=scan(hdg,20))>0)&&(range<40))
			exit();
		drive(hdg+=20,0)	/* turning on the spot?  maybe... */
	}
}

The landmine sits and waits for a robot to get too close, and explodes.  

A few specifics about the drones.

A drone can be picked up by a scan routine.  They can also be shot at
(and any damage kills them)  This leads to major tactic changes.  Robots
will now scan in the direction of travel at all times, to make sure they
don't run over a mine.  Mines can be dropped in strategic areas of the field
(such as corners, or anywhere along the walls)  Missiles, by the 
intelligent nature of them, can almost be blind fired, and then look for their
own target (make sure it doesn't come back at you though...)

Anti-missiles?  The fact that these things travel so fast makes leading the
target even more important.  IFF?

And with communications, robots could tell their drones where not to go and
when not to explode.  

Go nuts.

Don't ask me how to implement this stuff though...

-------------------------------------------+---------------------------------  
Chris Beauregard                           |  Live, free(),    
cpbeaure@descartes.waterloo.edu            |  and exit(0).
"If you can't beat 'em, take 'em with ya!" |                 - Me 



Subject: Re: CROBOTS stuff
From: gyugyi@leland.Stanford.EDU (Paul Gyugyi)
Organization: DSG, Stanford University, CA 94305, USA
Date: Fri, 21 Feb 92 01:20:27 GMT
Message-ID: <1992Feb21.012027.5454@leland.Stanford.EDU>

Re: drones:
I like it!  Add to the list a scanner drone that you can fork
off and have it transmit when it detects a robot!

Maybe instead of forking off, have the code in a seperate
file, and let robots carry other robots (protecting them
from damage).  Drone robots would be limited to 1/4 the
program and stack size, and a subset (two?) of the following:
a scanner, a cannon, a communications unit, a self destruct
mechanism, and a drive motor.

Maybe add a jet drive which moves faster, and assign a "weight"
to each of the above elements, and say a robot can carry 10
units of "weight" made up of one or more drones?

-gyug
gyugyi@earthsea.stanford.edu
---
sigwars:
This is the standard disCLOBBER*CLOBBERng me from respoCLOBBERty
from anCLOBBER opinions.



Subject: New corewar fan...
From: besu@sdf.lonestar.org (Christopher W. Carlson)
Organization: sdf Public Access UNIX, Dallas--unrestricted free shell access
Date: Fri, 21 Feb 1992 15:42:15 GMT
Message-ID: <1992Feb21.154215.3107@sdf.lonestar.org>


Hi!  I just recently downloaded a program for my Amiga called `The MADgic
Core -- CoreWar' and have become enamoured of the entire Corewar concept.

I've got two questions:

1)  The aforementioned MADgic Core program has, well, locked up as tight as
    a vault on me, on occasion.  Are there other Amiga CoreWar simulators
    out there, or a bug-free version of the MADgic Core?

2)  Where can I find archives of essays on RedCode programming strategies
    and/or previously-written CoreWar programs?

Any assistance at all is very much appreciated.

(BTW, I may very well have missed much or all of any ongoing discussions on
 either of these topics, as my site apparently had NO articles from this
 newsgroup.  So, if you're able, mail is much preferred over postings, as
 we may not receive this group at all, but I know we get mail.)

Thanks much.

-=* Christopher W. Carlson

-- 
   besu@sdf.lonestar.org  |  egsner!sdf!besu@uunet.uu.net (I think!)
  ---------------------------------------------------------------------
   a.k.a. Christopher W. Carlson, Galataeus, `That rotten twerp Chris'




Subject: Re: moral programming?
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC-CH School of Medicine
Date: 22 Feb 92 14:40:12 GMT
Message-ID: <1992Feb22.144012.3904@samba.oit.unc.edu>


   If you get a piece of code or an idea from someone else, I think it
would be only polite to mention your source/inspiration in a strategy
line.  People who post code (to this group for example) are effectively
putting their code/ideas in the public domain and it would be nice
(although not necessary) to give them some credit.  This would also
encourage more people to "share" their ideas, something which appears to
be somewhat lacking at the moment (with a few notable exceptions).
     -Andy
ajpierce@med.unc.edu



Subject: Re: KOTH
From: wms@iwarp.intel.com (William Shubert)
Organization: Intel iWarp, Beaverton, Oregon, USA
Date: 22 Feb 92 20:48:01 GMT
Message-ID: <1992Feb22.204801.20472@iWarp.intel.com>

Entry rules for King of the Hill "standard" Corewar:

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

2) Put the line ";redcode" at the top of your program.  This MUST be the first
   line.  Anything before it will be lost.
   In addition, writing ";redcode verbose" or ";redcode quiet" will alter how
   much information you get on your program.  See part 5) below.
   Additionally, adding ";name <program name>" and ";author <your name>" will
   be helpful in the performance reports.  Do NOT have a line beginning with
   ";address" in your code; this will confuse the mail demon and you won't
   get mail back.
   In addition, it would be nice if you have lines beginning with ";strategy"
   that describe the algorithm you use.

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

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

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

   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 10 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 10 list.

That's it!

MORE ON KOTH COREWAR IMPLEMENTATION
       Core size: 8,000 instructions
   Max processes: 8,000 per program
        Duration: After 80,000 cycles per program a tie is declared.

SAMPLE ENTRY:
;redcode verbose
;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

Rule variants for "eXperimental" corewar:
The same as above but use ";redcode-x" to start your program.

Your program will be entered into a second tournament with slightly different
rules.  The rules are:
   - All addressing modes are allowed with all instructions.
   - When a process executes a "SPL" instruction the children processes
     share the PARENT'S cpu time only.  For example:

start  spl loop2
       spl loop3
loop1  jmp loop1
loop2  jmp loop2
loop3  jmp loop3
       end start

In this example, the loop "loop2" will get 1/2 of the CPU time (it gets 1/2
of it's parent's time, and it's parent was the original process) while "loop1"
and "loop3" will each get 1/4 of the CPU time (their parent was a child of the
original process, so they each get 1/2 of 1/2 of the CPU time.)  The order
of execution would be like this:
loop2 <other player> loop1 <other player> loop2 <other player> loop3
   <other player> loop2 <other player> loop1 <other player> ...etc...


Path: overload.lbl.gov!agate!spool.mu.edu!wupost!cs.utexas.edu!rice!ricevm1.rice.edu!DURHAM
From: DURHAM@ricevm1.rice.edu (Mark A. Durham)
Newsgroups: rec.games.corewar
Subject: MAD MADgic v4.0 soda KotH init
Message-ID: <16795124E1.DURHAM@ricevm1.rice.edu>
Date: 23 Feb 92 02:49:37 GMT
Article-I.D.: ricevm1.16795124E1.DURHAM
Sender: news@rice.edu (News)
Organization: Rice University, Houston, TX
Lines: 30

If the subject line is confusing, it is because I am posting many
unrelated bits in this message.

MAD
   I will be incommunicado until March.  I'll still get EMail and
I'll still be able to read r.g.cw, but don't expect to hear back
from me until March.

MADgic v4.0
   The MADgic Core, Core War for the Amiga, version 4.0 was ready
to go but also will have to wait until March.  See below.

soda
   soda.berkeley.edu was not responding when I tried to upload the
above update; hence the delay.

KotH init
   I received a message about King of the Hill initialization
being DAT #0, #0.  I just wanted to warn everyone that an
appropriately initialized ICWS'88 standard implementation MARS should
be filled with DAT 0, 0 before loading programs - not DAT #0, #0.
It is in the standard for all to see (well, if soda were up ;) ).
Curiously, DAT 0, 0 is NOT a legal instruction in ICWS'88.

Valentine Warriors!  Get those next-round submissions in soon!

Until March, remember: the secret is to use Continue, not Go.

Mark A. Durham
MAD



Subject: Bow-n-arrow 2.2
From: JJJ101@psuvm.psu.edu
Organization: PSU
Date: 23 Feb 92 05:14:12 GMT
Message-ID: <92054.001412JJJ101@psuvm.psu.edu>

This program has been on the experimental hill for a long time.
It has made it as high as 2nd.

J.J.

----------------------cut------------------
;redcode-x verbose
;name Bow-n-Arrow 2.2
;author James Jesensky
;strategy bombs and imps...

start    spl  gun
         mov  #16, where
loop     add  #4, where
         mov  death, @where
         jmp  loop
where    dat  #0
death    dat  #0, #69
gun      spl  imp
         spl  imp
         spl  imp
         jmp  gun
imp      mov  0, 1



Subject: UT IEEE Computer Society Programming Contest
From: unbelver@ccwf.cc.utexas.edu (Carlos Y. Villalpando)
Organization: The University of Texas at Austin, Austin TX
Date: 22 Feb 92 06:07:31 GMT
Message-ID: <67096@ut-emx.uucp>

IEEE Computer Society, Student Branch
The University of Texas at Austin
ENS 103
Austin TX 78712
(512) 471-5038

	The time has come for the IEEE Computer Society's tenth Semi-Annual
State-Wide Programming contest.  This semester the contest will be held on
April 4th at 10 am on the University of Texas campus in Austin.

	This contest follows a slightly non-traditional format. Instead of
being given a set of problems to solve within a time limit like other 
contests, this contest challenges a team of two or three to write a 
program that will compete against another team's program.

	The programs will compete through an arcade style game.  The 
contestants will have to write a player that will be self sufficient, and
intelligent enough to win the game.  This poses an interesting challenge.
Computers are dumb, it is difficult for a computer to view the "big
picture" and come up with a strategy, but they have quick reflexes. A human,
on the other hand, can see the the big picture and change strategies as 
needed. The drawback is that humans have poor reflexes compared to the 
blinding speed of today's computers.  The challenge to the contestants is to
integrate the best of both human and computer qualities into a formidable
player.

	This contest has received excellent reviews by previous contestants.
Previous contest examples are Pong, Tetris, Sub Battles, the popular Snakes!,
and the breakthrough game Tanks!. Tanks!, last semester's contest, introduced
using the ability of the 386 and 486's ability to multitask.  Using a 
multitasker/memory manager written totally by one of our contest staff, we
were able to make the contest a real-time game.  The player algorithm a 
contestant turned in not only had to have a good algorithm, it also had to be
a fast thinker because the opponent was thinking at the same time as well.

	If you are interested in our contest and would like to get more
information about it, or getting involved it it. Contact me at:
			unbelver@ccwf.cc.utexas.edu
or call the IEEE CS office at the above number.

					Sincerely,
					Carlos Villalpando
					Contest Publicity
 



Subject: No B-field scanners here
From: ajpierce@med.unc.edu (Andrew Pierce)
Organization: UNC-CH School of Medicine
Date: 26 Feb 92 18:11:50 GMT
Message-ID: <1992Feb26.181150.7100@samba.oit.unc.edu>

Hi people.  I want to discuss the evolution of the KotH programs with
respect to evading detection by programs which scan for non-zero B-fields
through the use of "B-field stealth", i.e. having as many of your B-fields
as possible being zero.  A perusal of the hill seems to me to show that
the scan-and-bomb type programs such as sargent, kinch, leech? and
splitbomb? have taken a real beating of late.  What do you think about
this?  Are the programs now on the hill all simple "pattern bombers" or is
an intelligent search still a viable option?
     -Andy
ajpierce@med.unc.edu



Subject: Re: No B-field scanners here
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 26 Feb 92 20:05:45 GMT
Message-ID: <1992Feb26.200545.26388@vuse.vanderbilt.edu>

In article <1992Feb26.181150.7100@samba.oit.unc.edu> ajpierce@med.unc.edu (Andrew Pierce) writes:
>Hi people.  I want to discuss the evolution of the KotH programs with
>respect to evading detection by programs which scan for non-zero B-fields...

KotH is cyclical, scanners will return (submitted one myself a couple
of minutes ago). "B-field stealth" might be a factor in the current
demise of scanners, but just as important is that many programs on the
current hill are SPL-resistant.

>this?  Are the programs now on the hill all simple "pattern bombers" or is
>an intelligent search still a viable option?
I don't think a B-field scan is much more "intelligent" than pattern bombing.
Here's an alternative search strategy that works well against B-field stealth:

ptr	DAT #0
loop    ADD #DIST,ptr
        CMP @ptr, <ptr
        JMP bomb
        JMP loop
bomb	<some killing code goes here>

This search triggers when two adjacent addresses are different. I have yet 
to write a warrior that uses this strategy and makes it onto the hill, though.

>     -Andy
>ajpierce@med.unc.edu

-Stefan (stst@vuse.vanderbilt.edu)



Subject: coresize
From: ASMQK@ASUACAD.BITNET
Organization: Arizona State University
Date: 27 Feb 92 21:46:39 GMT
Message-ID: <92058.144640ASMQK@ASUACAD.BITNET>

It would be interesting to try out a coresize wich can divide by 3.
mod 3 bombers could be more successfull than mod 4 bombers.
The other interesting coresize is a prime.
What do you think of it?

Nandor    asmqk@asuacad.bitnet

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

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

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

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



Subject: ramscoop-x
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 2 Mar 92 04:03:22 GMT
Message-ID: <1992Mar2.040322.29456@vuse.vanderbilt.edu>


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

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

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

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

        end     start



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

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

iraun1.ira.uka.de (129.13.10.90)

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

Mark A. Durham
MAD



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


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

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

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



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

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

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

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

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

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

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

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



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

Attention!

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

What is Core Wars?

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

The rules:

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

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

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

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

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

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

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


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

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


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




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


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

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

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

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

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



Subject: RR.BTM - round-robin cw tournament scheduler for 4DOS (PC)
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: 8 Mar 92 22:05:05 GMT
Message-ID: <1992Mar8.220505.29036@vuse.vanderbilt.edu>

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

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

C>rr xtc dwarf pest-x trinity2 mutagenp

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

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

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

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


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

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

rem verbose output flag
set $verbose=y

rem fighter filename extension
set $ext=red

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

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

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

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

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



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

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

Here are the VDT Super Tuesday Round Two Tournament Results!

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


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

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


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

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

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


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


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

X5 / Cake                                  X5                   18170
Cake / X5                                             Tie

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


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

Leech / V2                                Leech                  319
V2 / Leech                                  V2                  25564


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

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


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

Gulliver / HideOut                                      Tie
HideOut / Gulliver                                      Tie


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

Mark A. Durham
MAD




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

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

Thanks,
Mark A. Durham
MAD

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



Subject: Locusts 2.2
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: Wed, 11 Mar 1992 18:08:31 GMT
Message-ID: <1992Mar11.180831.18809@vuse.vanderbilt.edu>

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

-Stefan (stst@vuse.vanderbilt.edu)

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

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

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

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

        END     scan




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

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

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



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

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

would be

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

Nandor.    asmqk@asuacad.bitnet



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

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

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

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

Mark A. Durham
MAD



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

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

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

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

* in tournaments run by MAD.

Campbell

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



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

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

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

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


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

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

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

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



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

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

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

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

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

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


