From: estrathm@bu.edu (Eric Strathmeyer)
Subject: Uuuuuummm?
Date: 1 Mar 1995 01:41:14 GMT
Message-ID: <3j0jbq$4b9@news.bu.edu>

Sorry, I had "show only unread" turned on.  sorry.


From: pk6811s@acad.drake.edu
Subject: Re: P.Kline Code
Date: 1 Mar 95 09:52:33 CST
Message-ID: <1995Mar1.095233@acad.drake.edu>

In article <1995Feb28.122450.2029@rhodes>, graham@harlie.mathcs.rhodes.edu (Randy Graham) writes:
> I've been pulling and looking at previous months postings, pulling out
> the good ones, and trying to improve my code.  In Sep94, I found this
> snippet by P.Kline
> 
> step	equ	13
> bomb	dat	step+step
> tstdjn	dat	-1,	-1
> 
> inc	dat	3*step,	3*step
> 
> next	add	inc,	scan
> 	mov	bomb,	@scan
> scan	seq.x	10*step,	@9*step
> 	sne	*scan,	tstdjn
> 	djn	next,	#7700/(step*3)
> attack	...
>...

This looks like the bomb/scan code from Rude Wind.  It is designed to
quickly bomb/scan once through core in an attempt to catch a large or
slow-starting opponent like an imp or paper colony.  If nothing is found
it gets triggered by its own decoy and attacks that.  After attacking
it releases paper.  Rude Wind has a very high win rate against 3-point
imps.  It attacks two of the imp-streams by bombing forward on each
of them with a DAT <2666,<5334.

One-shot scanning or bombing is a time-honored pre-launch strategy for
an otherwise paper warrior.

Paul Kline
pk6811s@acad.drake.edu

;redcode-94 quiet
;name Rude Wind
;kill Rude Wind
;author P.Kline
;macro

step     equ 12
tstdjn   dat    0,-1

pl1      spl   #0                 ; create multiple processes
         mov   p2b,}scan          ; anti-imp attack, part 1
         mov   >0,}5000
         djn   -2,#6              ; let one process through for paper launch
         spl   1,>200             ;
         mov.i -1,#0              ; create 6 processes
         spl   1,>300             ;
         mov   <cp2,{cp2          ; make a copy of 2nd paper
cp2      spl   p2s+1850+6,p2s+6   ;   and launch him

p1s      mov   p1b,>6             ; 1st paper
p1c      mov   <p1s,<p1n
p1n      spl   @p1n,>-1356
         mov   p1b,<p1n
         jmp   @0,>p1s
p1b      dat   <2667,<5334

     for 20
         dat 0,0
     rof
pl2      add   #(2*step)+2691,scan
         spl   #0                 ; create multiple processes
         mov   p2b,>scan          ; anti-imp attack, part 2
         mov   >0,}1000
         djn   -2,#6              ; let one process through for paper launch
         spl   1,<-100            ;
         mov.i -1,#0              ; create 6 processes
         spl   1,<-200
         mov   <cp1,{cp1          ; make a copy of 1st paper
cp1      spl   p1s+1850+6,p1s+6   ;   and launch him

p2s      mov   p2b,>6             ; 2nd paper
p2c      mov   <p2s,<p2n
p2n      spl   @p2n,>-1556
         mov   p2b,<p2n
         jmp   @0,>p2s
p2b      dat   <2667,<5334
                  
     for 20
         dat    0,0
     rof
inc      dat    3*step,3*step
bomb     dat    0,step+step
         
     for 16
         dat 0,0
     rof
     
next     sub    inc,scan          ; scanner bombs one and scans two locations
         mov    bomb,@scan        ; in a four-instruction loop
scan     seq.x  7700+(10*step),@7700+(9*step)
         sne    *scan,tstdjn      ; ignore old-style djn-streams
         djn    next,#7700/(step*3)
         mov    p1b,<scan         ; attack found code
         mov    p2b,}scan
         djn    -2,#step+5
         
attack   spl    pl2,<3500         ; start launch code
         jmp    pl1,>-3500        ;
         end    next+1


From: mreddy@comp.glamorgan.ac.uk (Mike Reddy)
Subject: Pointers in pMARS
Date: 1 Mar 1995 11:59:43 GMT
Message-ID: <mreddy-0103951200330001@mreddy.comp.glam.ac.uk>

I seem to be having a slight problem with pMARS (version 6.0) when
compiled under MetroWorks CW4 on the (Power) Macintosh.

When I run the assemble procedure from ASM.C, a number of pointers are
allocated.  Sometimes, some of these pointers are not freed.  This means
that up to 4 or 5 blocks of memory, 528 bytes in length are lost every
time the procedure is called.

Obviously this is not a problem under normal circumstances, but I am
writing a tournament scheduler, which may involve hundreds or thousands of
calls to this procedure, and the resulting memory loss is quite annoying.

The problem seems to occur when the functions addline and encode are used
(but not every time), and when fgets is used for the first time.

A similar problem occured with simulator1() which was loosing blocks of
128K, but this was fixed by converting from pointers to arrays (by
disabling the #define __MAC__ directive before compiling the source
code).  This solution is not really applicable because pointers are not
used in the same way.

I am not sure if this is due to some pointers being allocated memory
within pMARS, or due to the compiler or compiler settings.

Any suggestion would be gratefuly recieved.

Yours Mike Reddy
--
P.S. I would have had a witty signature, but the Government put VAT on it!

Email: mreddy@comp.glamorgan.ac.uk OR mreddy@glamorgan.ac.uk

P.P.S. Glamorgan University: Top of the League! Applications up 51% this year!


Subject: New Kind of QScan?
Message-ID: <1995Mar1.123337.2035@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 1 Mar 95 12:33:36 -0500

I had a thought last night for a different kind of quickscan.  So, I
worked on it some, tried it out, and found that it didn't work.  It
never properly exited the qscan, and while trying to figure out how to
do that, I realized it wasn't even scanning where I had intended (Dang
programming languages, always doing what you code instead of what you
meant to code).  So, when I realized I couldn't get it to work right,
I scrapped it.

A few minutes later though, I figured out a modified version that does
work.  I am trying it on the beginner's 94 hill, and want a chance to
work out some kinks, but I just wanted to present the idea (from which
I am sure many of you can figure out the implementation) and see if
anyone has done something similar or better.

I have about 25 lines of code to store my original warrior, code to
move me, code to test if my scan found anything, and bomb if so.  In
the remaining 75 lines, I can scan 140 core locations and immediately
bomb if I find something.  After bombing, I move and start my real
warrior.  That is, I only bomb once, and don't continue my scan.

The only big drawback I can find is it takes my 140 steps to do this
scan if no one is found.  Thus, I am only scanning at C, where the
regular cmp/mov scan is C and sne/seq/mov is 1.33C (I think I got
those numbers right.  Because of this, I am extremely vulnerable to
Rave/Charon types that scan forward in small steps. 

Now, has anyone written anything that scans better then 140 locations
in a qscanner and still moved their warrior away?  Using an
sne/seq/mov scan I get only about 80 locations in the same amount of
code.  I feel that I should do better (my original non-working version
theoretically checked about 100 locations at 1.5C, but alas, here was
a fatal flaw).

Sorry for all the long posts lately, but I am frustratingly close to
getting on to the regular 94 hill, and I keep hoping for that
breakthrough that will puch me in (missed by 3 points last time).
Every new idea gets pursued until I can't wrench any more from it.
Then, I turn to the experts.

Thx,
Randy


Subject: Re: New Kind of QScan?
Message-ID: <1995Mar1.134849.2036@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 1 Mar 95 13:48:49 -0500

I (graham@harlie.mathcs.rhodes.edu) wrote:
[Bunch of stuff deleted]
: The only big drawback I can find is it takes my 140 steps to do this
: scan if no one is found.  Thus, I am only scanning at C, where the
: regular cmp/mov scan is C and sne/seq/mov is 1.33C (I think I got
: those numbers right.  Because of this, I am extremely vulnerable to
: Rave/Charon types that scan forward in small steps. 
On this, I meant worst case.  That is, if something is found it takes
one instruction to set up to check it later, so on that particular
scan, it moves C/1.33C.  In general, I belive they both check 2C (If I
understand the C ratings as actual speed by lines of code executed).

Randy

P.S. Sorry for all the typos.  I never checked for spelling before
posting.


From: estrathm@bu.edu (Eric Strathmeyer)
Subject: Crime ring, onion ring, imp ing...
Date: 1 Mar 1995 15:55:02 GMT
Message-ID: <3j25cn$qam@news.bu.edu>

I have even less of an idea of what I'm doing.  I have the previous problems
that you just listed, but I don't even have a clear understanding of what the
warriors are supposed to do (i.e., how one is killed) or where they are
fighting.  I'm sorry if I seem really stupid to some people, but I've been
here about 3 days.


From: hanwen@stack.urc.tue.nl (Han-Wen Nienhuys)
Subject: Re: C++Robots simulator for unix available
Date: 1 Mar 1995 16:39:56 +0100
Message-ID: <3j24gc$8ss@snail.stack.urc.tue.nl>

In article <3ioujv$4tf@news1.best.com>, Dan Melchione <godling@best.com> wrote:
>What directory did this get stored in?

I don't know..... i just put it into the incoming directory
/hw/


From: chris@hiram.edu
Subject: High-level to Redcode??
Message-ID: <1995Mar1.202820.380@hir800>
Date: 1 Mar 95 20:28:20 -0400

Has anyone ever written a compiler to convert a high-level
language like C or pascal into Redcode?  If so, where is it?

-- 
Chris Hodson	| quis custodet custodes 
Hiram College	|
chris@hiram.edu	|


From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant)
Subject: Re: Crime ring, onion ring, imp ing...
Date: 1 Mar 1995 22:57:39 GMT
Message-ID: <3j2u53$nic@agate.berkeley.edu>

In article <adsD4Do5I.I5v@netcom.com>, Anthony Spataro <ads@netcom.com> wrote:
>After the first instruction is executed, the "instruction pointer" moves
>on, to the next instruction in memory--but unless the first instruction
>put something there, the warrior dies!  How then does one manage to create
>a warrior that does anything besides staying one step ahead of itself?

The idea is that you program in several lines of code, so that after
executing the first instruction, it just moves onto the next one.  For
example, here is a simple warrior:

	mov -1, -1
	add #4, -1
	jmp -2

I will use "==>" to indicate thr program counter.  When the program is
first loaded into memory, it looks like this:

==>	mov -1, -1
	add #4, -1
	jmp -2

Then the first instruction is executed (it does nothing).  The program
now looks like this:

	mov -1, -1
==>	add #4, -1
	jmp -2

Now, the second instruction is executed (it adds 4 to the B-field of the
first instruction).  The program now looks like this:

	mov -1, 3
	add #4, -1
==>	jmp -2

Now, the last instruction is executed (it resets the program counter to
the first instruction).  The program now looks like this:

==>	mov -1, 3
	add #4, -1
	jmp -2

Now, the first instruction is executed again -- but this time, it is
different.  It now copies the dat instruction right before the beginning
of the program (recall that all core locations are initialized to dat
instructions) to the location right after the end of the program.  The
program now looks like this:

	mov -1, 3
==>	add #4, -1
	jmp -2

The program will continue in this loop forever, each time moving a dat
instruction (the instruction before the beginning of the program) to a
different memory location.  This program is called a "dwarf", and it is
a type of bomber -- bombers are programs that place dat statements all
over core, without any intelligent operation (i.e. first checking to see
if there is anything there).

Hope this helps!  If you're still having trouble, please feel free to
email me or post here.
-- 
            Michael Constant (mconst@soda.csua.berkeley.edu)


From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant)
Subject: Re: New Kind of QScan?
Date: 1 Mar 1995 23:06:08 GMT
Message-ID: <3j2ul0$ob5@agate.berkeley.edu>

Randy Graham <graham@harlie.mathcs.rhodes.edu> wrote:
>Now, has anyone written anything that scans better then 140 locations
>in a qscanner and still moved their warrior away?  Using an
>sne/seq/mov scan I get only about 80 locations in the same amount of
>code.  I feel that I should do better (my original non-working version
>theoretically checked about 100 locations at 1.5C, but alas, here was
>a fatal flaw).

The measure of a good qscanner is *not* how many locations it scans,
but how fast it scans them.  The more locations you scan, the more you
are vulnerable to small programs.  I have found that 80 locations is
about an optimal amount of scanning.  If your qscanner is more compact
than the standard sne/seq/mov qscanner, you will be able to get 80 scan
locations in a smaller space, and thus leave yourself less vulnerable
(as well as having more space for the main program).

Congratulations on developing a new qscanner algorithm, and good luck
making the '94 hill!
-- 
            Michael Constant (mconst@soda.csua.berkeley.edu)


From: a920101@zipi.fi.upm.es
Subject: C++Robots???What the...!
Date: 2 Mar 95 10:23:01 +0100
Message-ID: <1995Mar2.102301@zipi.fi.upm.es>

Hi you all!
I know what corewar is, but what the heck is that C++ Robots???
Can anybody tell me where can i get a good implementation of it???
(BTW Is it cool?)

Thanks you all boys!

	Juanje.



Subject: See how this looks...
Message-ID: <1995Mar2.122215.2049@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 2 Mar 95 12:22:14 -0500

;Strategy An attempt at a new kind of QScan.  Not as fast as
;strategy cmp/mov or sne/seq/mov, but only three lines to code plus
;strategy however many dat statements I can fit in around regular
;strategy warrior.  Has benefit of attacking as soon as something is
;strategy found.  Can check more locations with fewer lines, thus the
;strategy scan is more dense.

LEN	equ	;Put length of you warrior
MOVETO	equ	;Put where you want to move toC

IGNORE	equ	1000	;How much to ignore of core (1/2 on each side of me)
QDIFF	equ	(CORESIZE-IGNORE)/(QLINES*2)	;difference between sites
QLINES	equ	70	;adjust for how many lines of cmp-data you want
QBOMBS	equ	20	;how long a bomb run to lay

scan	sne.x	*dummy-1,	@dummy-1
	djn.f	-1,	-1	;have this and next line point to
	jmp.a	checker, checker-1	;exchangable .f to avoid self
scandat	for QLINES
	dat.f	IGNORE/2+(QDIFF*scandat*2), IGNORE/2+(QDIFF*scandat*2+QDIFF)
rof

;dummy prevents scan from falling out on jmp.a checker line
dummy	jmz.f	-(checker-scan),	-(checker-moveme)
checker	jmz.f	moveme,	scan	;check if we have something
	add.f	scan,	snechk	;point to location where we found them
	add.f	snechk,	*snechk	;adjust for address difference
	mov.f	*snechk,	snechk	;set up attack
	sne.i	*snechk,	fini	;if *snechk not empty, attack it
	mov.ba	snechk,	snechk ;otherwise, need b-field, so move it
attack	mov.i	spltrap,	}snechk	;carpet them
	djn.b	-1,	#QBOMBS

moveme	mov.ab	#1,	snechk	;set up location to copy from
	mov.i	>snechk,	>site	;now move the real me
	djn.b	-1,	#LEN
site	spl.a	MOVETO+1,	#MOVETO	;start real me
clear	mov.i	snechk,	site		;hide pointer to self

snechk	dat.f	*scan,	@scan

;You warrior here.


OK, I haven't had much success in improving a warrior with my new
qscan, but here is the code minus a warrior to try it out.  You should
be able to take this code, insert your warrior at the end, and modify
the attack line to move whatever you want if not a spl 0 trap.  Note
the spltrap isn't defined in this code.  That is one of my line labels
in my warrior.

I would love to here any comments about this type of scan.  Some notes
I can make.  The scan is a constant C, exitting as soon as something
is found.  The pointers are adjusted for differences between dat lines
and then bombed.  As I have it, the scan checks about every 50th core
location.  The number of scan lines could be reduced to check fewer
locations, thus giving you a quicker exit if nothing is found.  One
thing I like about this scan is it is very small and dense.
Unfortunately, it can't match the speed of sne/seq/mov.  I do believe
it performsabout  as well as cmp/mov scans, but I haven't tested it
carefully to see.  Also, it is still vulnerable to small step scanners
because the whole scan takes place in the first 3 lines.  If only
there were an inc instead of dec, I could locate the scan after the
dats and save on the dummy line.

Notice from the above code, the whole scan and setup for an attack
uses about 10 lines to define with the for/rof loop.  Add in how many
lines you want and how the attack goes, and with a 40 line set of
cmpdat lines, you still have 40-50 lines to move your warrior and
start it, plus erase pointers to yourself, lay out decoys, etc.  Also,
the dummy line is important.  This keeps the scan from exiting when it
points to its own jmp line on line 2.

Please let me know if you use this to any succes so I can try to
improve my warriors.


Randy


From: han@imag.fr (Jay "Thierry" Han)
Subject: About scanners
Date: 03 Mar 1995 10:15:35 GMT
Message-ID: <HAN.95Mar3111535@uvea.imag.fr>

As a followup to Randy's post, here's a warrior I submitted to the
Hill about a year ago. It stayed there for a little while, but never
made it in the top10 and dropped off eventually.

The basic scanner is the same as Randy's except I use a "scantab"
line to check for the end of the scan. Also, it uses pMars constants
like MINDISTANCE and MAXLENGTH to compute an "optimal" scanning run.

When something is found, I set up a trap at the lower end of the
range and vampirize every "j" instructions from there up to the
upper end of the range. The trap itself is simply a SPL-carpet
layer, sort of. After that, I set up a perpetual forward core-clear
*after* the trap and jump there.

The thing that wins is that this setup makes the opponent "marinate"
in the trap for a long time before I go and kill it.

If nothing's found in the scan, then I jump to "boot", which boots
off a simple imp-spiral/stone.

The constants are set up so that I scan approx. every 100
instructions. By making "n" larger you could make it scan tighter
than that, at the expense of startup time of course, which is
critical for the stone to work well.

;redcode-94
;assert CORESIZE==8000 && MAXLENGTH==100
;name Fscan
;author Jay Han
;kill Fscan

		org	entry

j		equ	6
n		equ	38
s		equ	(((CORESIZE-(2*MINDISTANCE)-MAXLENGTH)*2)/((2*n)+1))
q		equ	(s/2)
h		equ	(q/2)
a		equ	(head-MINDISTANCE)
l		equ	(q+MAXLENGTH)
k		equ	(l/j+1)

dat0		equ	head-1
head
entry
scan		sne.i	*fscan,		@fscan
		djn.f	scan,		scan
		jmz.a	boot,		@scan
		add.f	scan,		test
test		add.b	scan,		#scan
		sne.i	dat0,		@test
		sub.ab	#q,		test
		add.b	test,		bite
		mov.i	vamp,		>bite
		mov.i	mega,		>bite
		add.b	bite,		ptr
stun		mov.i	bite,		@bite
		add.f	vamp,		bite
		djn.b	stun,		#k

copy		mov.i	>ptrcclear,	<ptr
		djn.b	copy,		#4
ptrcclear	jmp.b	@ptr,		bomb

mega		mov.i	-1,		<-1

adder		add.a	#step,		jumper
bomb		dat.f	<-1,		j+3
		djn.f	-1,		-j-2
		mov.i	2,		>-j
vamp		spl.b	#j,		<-j

bite		jmp.b	-2,		#test+q

scantab		dat.f	0,		scan
m for n
		dat.f	a-(m*s),	a-(m*s)+q
rof
fscan		equ	scantab+n-1

p2		equ	-73+(972*s2)
s2		equ	-74
p1		equ	75+(972*s1)
s1		equ	74

cast		mov.i	<p1,		p2
stone		spl.b	cast,		<cast-4
		add.f	inc,		cast
		djn.f	stone,		<cast-6
inc		dat.f	s1,		s2

boot		mov.i	<ptr1,		{ptr2
		djn.b	boot,		#5
ptr2		spl.b	head+4000

step		equ	2667
launch
imp		mov.i	0,		step
ptr		spl	1,		bite+j+5
ptr1		spl	1,		inc+1
		mov.i	-1,		#0
		spl	adder
jumper		jmp	imp+step

for 23
		dat.f	0,		0
rof

		end

-=< Jay "Thierry" Han >=-                            han@imag.fr 
Bull-IMAG/Systemes. 2, av. Vignate. ZI Mayencin II, 38610 Gieres.
                          Tel: +33 76.63.48.41. Fax: 76.54.76.15.
Perso: 61, rue Thiers. 38000 Grenoble.               76.46.11.26.


From: pk6811s@acad.drake.edu
Subject: Re: See how this looks...
Date: 3 Mar 95 10:49:56 CST
Message-ID: <1995Mar3.104956@acad.drake.edu>

In article <1995Mar2.122215.2049@rhodes>, graham@harlie.mathcs.rhodes.edu (Randy Graham) writes:
> ;Strategy An attempt at a new kind of QScan.  Not as fast as
>...

Nice.  Try copying your scanning code and warrior far away from your
pointers before you start scanning.  That way you remain a small target
and hopefully offset the speed advantage of the other qscanners, cause
if they attack your pointers you don't get hurt.

Paul Kline
pk6811s@acad.drake.edu


From: drano@simplet_8.univ-lr.fr (RANO Didier)
Subject: Obtain corewar with web ?
Date: 3 Mar 1995 10:49:08 GMT
Message-ID: <3j6s74$3qn@hp_univ.univ-lr.fr>

I don't access to ftp.
But i can have an access to web ...
 
Thank you


Subject: Beginner's hill
Message-ID: <1995Mar3.143702.2056@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 3 Mar 95 14:37:01 -0500

I was looking at the latest standings on the 94-beginners hill, and I
noticed there are duplicates of warriors, only different by version
number, and there are people with multiple warriors up there.  I would
just like to ask everyone with more than one or two warriors on the
beginner's hill to ;kill some of them.  I think it would be good for
others to have a shot, and having those who have made it several
different ways not leave everything up there will help.

I admit I have sent MANY warriors onto the hill in the past two weeks,
but when I make an improvement I try to clear off older attempts.
Let's give other beginners a shot.  

Randy


From: estrathm@bu.edu (Eric Strathmeyer)
Subject: Leaving a trail of bombs
Date: 3 Mar 1995 21:16:12 GMT
Message-ID: <3j80us$hl8@news.bu.edu>

Is there any way to write a program that moves forward, while leaving a trail
of bombs (DAT or SPL) behind it?  I haven't been able to (though that doesn't
say much).

From: ama@athena.mit.edu (Albert Ma)
Subject: Re: Pointers in pMARS
Date: 3 Mar 1995 21:33:23 GMT
Message-ID: <3j81v3$7ng@senator-bedfellow.MIT.EDU>

Mike writes:
>When I run the assemble procedure from ASM.C, a number of pointers are
>allocated.  Sometimes, some of these pointers are not freed.  This means
>that up to 4 or 5 blocks of memory, 528 bytes in length are lost every
>time the procedure is called.


We explicity kept track of every single thing that was malloc'ed
so that they could be freed.  Strange, I thought it was deallocated after
the assembly phase.  Maybe not, I don't remember.

I remember a long time ago we made sure that there were no memory leaks.
Something might have slipped into the newer pMARS versions but I doubt it.


>A similar problem occured with simulator1() which was loosing blocks of
>128K, but this was fixed by converting from pointers to arrays (by
>disabling the #define __MAC__ directive before compiling the source
>code).  This solution is not really applicable because pointers are not
>used in the same way.

Now this is really strange.  Pointers are used only when 
__MAC__ or __AMIGA__ or __MSDOS__ is defined.  There are exactly two
mallocs, one for memory and one for taskQueue.

at the end sim.c there is

#if defined(__MAC__) || defined(__AMIGA__)
  /* DOS taskQueue may not be free'd because of segment wrap-around */
  free(memory);
  free(taskQueue);
  alloc_p = 0;
#endif

which should have freed the memory that was allocated.


Are you using the original pmars06 distribution or the one modified for
the Mac (MacpMARS I think) which has the interface in it?

I believe you're the first person I've heard of to port pMARS on a 
PowerMac.  Right now my gut feeling is it's a compiler problem.

Albert Ma		ama@mit.edu



From: rrognlie@netcom.com (Richard Rognlie)
Subject: Richard's PBeM Server (Monthly Posting)
Message-ID: <rrognlieD4vxpI.9sz@netcom.com>
Date: Fri, 3 Mar 1995 22:12:54 GMT

Richard's Play-By-eMail (PBeM) Server Monthly Posting

A generic Play-By-eMail Server has been set up at pbmserv@netcom.com.  It
currently supports four games (Trax, TwixT, Hex and Abalone) with others
to be added in the future.  Also, the PBeM Server acts as the host for the
ongoing C++Robots King-of-the-Hill tournament.

To get more information send mail to pbmserv@netcom.com with 'help' as the
subject line.

Games Currently Supported

Trax ((c) David Smith)

    Trax is a game played with square tiles.  Each tile is identical
    to all other tiles, one side has a white line connecting opposite
    edges and a black line connecting the other edges, and the other
    side has a white line connecting 2 adjacent edges and a black line
    connecting the other edges.

    The object of the game is to create a loop of your color while
    preventing your opponent from doing the same.  An alternate winning
    condition is to create a line extending from one edge of the board
    to the opposite edge of the board when the board is at least 8
    tiles wide (or tall).

TwixT ((c) Avalon Hill)

    On a 24x24 board, players take turns placing pegs of their color
    on the board.  Any time a peg is placed a "knight's move" from 
    another peg of the same color, a strut is placed, connecting them.
    A strut can not cross over (through) another strut.  The object is 
    to connect your sides of the board while preventing your opponent
    from doing the same.

Hex
 
    On a 11x11 diamond board, players take turns placing stones of
    their color on the board. The object is to connect your sides of
    the board while preventing your opponent from doing the same.

Abalone

    On a hexagonal board (radius 5) two to six players have armies of
    marbles.  Players take turns "pushing" 1, 2 or 3 linearly connected
    marbles, attempting to push their opponents' marbles off the board.

C++Robots ((c) 1994 Richard Rognlie)

    An ongoing "King of the Hill" (KotH) tournament in which players
    use the C++ language to create a control program for a robot.  Your
    robot then fights each of the other robots "on the hill".  If you
    do well enough, your robot will "make the hill", bumping the lowest
    robot from the hill.

    Robots have the ability to scan for opponents, fire a cannon, move,
    and determine current position and status.

    Conceptually based on C-Robots written for the IBM PC by Tom Pointdexter.

-- 
  /\/\/\  | Richard Rognlie / Sr. Computer Analyst / PRC Inc. / McLean, VA
 /  \ \ \ | E-Mail: rrognlie@netcom.com *or* rognlie_richard@prc.com
 \  / / / | Phone:  (Home) (703) 361-4764   (Office) (703) 556-2458
  \/\/\/  |                                 (Fax)    (703) 556-1174


From: Anders Eurenius <eurenius@algonet.se>
Subject: Re: Crime ring, onion ring, imp ing...
Date: Sat, 4 Mar 1995 00:47:26 +0100 (MET)
Message-ID: <Pine.SUN.3.90.950304001024.22851A-100000@aristotle.algonet.se>

On Wed, 22 Feb 1995, Anthony Spataro wrote:

> Yeah, that's me, another Core War newbie.  I've gotten pMARS, read the 
> tutorial.? and the awkwardly-formatted ICWS'88 specs, 

Yeah, I know what you mean, read it three or four time more, and you 
might get /some/ of it...

>and a little bit of 
> the partially-completed book on warriors.

Huh? Where did you find that?

> And, although I have managed 
> to make a simple warrior that just runs through memory, I'm still very 
> confused. The documentation, while doing a good job explaining 
> addressing modes and Redcode syntax, ignored or only briefly mentioned 
> quite a few things.  I'm still in the dark about the spl and dat 
> instructions--I know that spl "starts a new process" and dat "writes data 
> and terminates the current process" but that doesn't mean a whole lot at 
> the moment.  And, perhaps the biggest of all, the apparent contradiction 
> of how a warrior operates.  After the first instruction is executed, the 
> "instruction pointer" moves on, to the next instruction in memory--but 
> unless the first instruction put something there, the warrior dies!  How 
> then does one manage to create a warrior that does anything besides 
> staying one step ahead of itself?

Lemme guess. You're not a programmer, right? The JMP (and others, 
conditionally) instruction changes the instruction counter to whatever 
you like, and by setting the jump-to value negative <something> you make 
a loop; the <something> number of instructions are repeated endlessly. By 
making the jump conditional you can make scan-loops, bombing loops, loops 
that are executed a certain number of times, etc. SPL starts the 
execution of a `new' program (one witch will have to share it's 
execution-time with the first one, however!) at the address in the 
a-operand, or the address in the b-operand of the address it points to. 
Oh, and both have to `die' for you to lose. The DAT instruction doesn't 
do anything but kill any program that executes it, and store information.
However, if executed, the operands can do damage; pre-decrement is done, 
since it is done /before/ the instruction is executed. You know, Redcode 
(IMHO) really isn't a great choice for a first language... And I wish the 
big boys would discuss methods rather their @#$^%$&* `magic' numbers!

Anders Eurenius, Another redcode-newbie.

Ps. I'm still looking for a '94-MARS for the amiga, or at least a 
complete one that I can compile!

-----------------------------
EXiSTANCE iS FUTiLE! GO AWAY!
-----------------------------


From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ)
Date: 4 Mar 1995 14:59:33 GMT
Message-ID: <games/corewar-faq_794329155@rtfm.mit.edu>

Archive-name: games/corewar-faq
Last-modified: 1994/11/25
Version: 2.3.1

These are the Frequently Asked Questions (and answers) from the USENET
newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP
from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z.


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

 1. What is Core War?                                                 69

 2. Is it Core War or Core Wars?                                      82

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

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

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

 6. What is the ICWS?                                                152

 7. What is TCWN?                                                    162

 8. How do I join?                                                   170

 9. Are back issues of TCWNs available?                              187

10. What is the EBS?                                                 194

11. Where are the Core War archives?                                 208

12. Where can I find a Core War system for . . . ?                   226

13. I do not have ftp.  How do I get all of this great stuff?        275

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

15. When is the next tournament?                                     303

16. What is KotH?  How do I enter?                                   314

17. Is it DAT 0, 0 or DAT #0, #0?  How do I compare to core?         483

18. How does SLT (Skip if Less Than) work?                           495

19. What does (expression or term of your choice) mean?              507

20. Other questions?                                                 650

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

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

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

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

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

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

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

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

Author: Dewdney, A. K.
Title: The Magic Machine: A Handbook of Computer Sorcery
Published: New York: W. H. Freeman (c) 1990
ISBN: 0-7167-2125-2 (Hardcover), 0-7167-2144-9 (Paperback)
Library of Congress Call Number: QA76.6 .D5173 1990

A.K. Dewdney's articles are still the most readable introduction to
Core War, even though the Redcode dialect described in there is no
longer current (see Q 4).

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

Q 4: Core War has changed since Dewdney's articles. Where do I get a
copy of the current instruction set?
A 4: A draft of the official standard (ICWS'88) is available by anonymous
FTP from the Core War archives (ftp.csua.berkeley.edu) as
pub/corewar/documents/standards/redcode-icws-88.Z

This document is formatted awkwardly and contains ambiguous statements. For a
more approachable intro to Redcode, take a look at
pub/corewar/documents/tutorial.1.Z
                      tutorial.2.Z
(See also Q11)

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

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

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

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

Q 6: What is the ICWS?
A 6: About one year after Core War first appeared in Sci-Am, the
"International Core War Society" (ICWS) was established.  Since that
time, the ICWS has been responsible for the creation and maintenance
of Core War standards and the running of Core War tournaments.  There
have been six annual tournaments and two standards (ICWS'86 and
ICWS'88).

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

Q 7: What is TCWN?
A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the
official newsletter of the ICWS.  It is published quarterly and recent
issues are also available as Encapsulated PostScript on ftp.csua.berkeley.edu
(see Q9).

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

Q 8: How do I join?
A 8: For more information about joining the ICWS (which includes a
subscription to TCWN), or to contribute an article, review, cartoon, letter,
joke, rumor, etc. to TCWN, please contact:

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

Current annual dues are $15.00 in US currency.

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

Q 9: Are back issues of TCWN available?
A 9: Recent issues can be found on ftp.csua.berkeley.edu (see Q11).
Older issues (up to Winter 1991) are also available (see the next TCWN
for details).

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

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

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

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

Q11: Where is the Core War archive?
A11: Many documents such as the guidelines and the ICWS standards
along with previous tournament Redcode entries and complete Core War
systems are available via anonymous ftp from ftp.csua.berkeley.edu
(128.32.43.51) in the /pub/corewar directories.  Also, most of past
rec.games.corewar postings (including Redcode source listings) are
archived there.  Jon Blow (blojo@ftp.csua.berkeley.edu) is the archive
administrator. When uploading to /pub/corewar/incoming, ask Jon to move
your upload to the appropriate directory and announce it on the net.

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

This FAQ is automatically archived by news.answers.  See the header for
the current archive name and news.answers for how to get it.

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

Q12: Where can I find a Core War system for . . . ?
A12: Core War systems are available via anonymous ftp from
ftp.csua.berkeley.edu in the pub/corewar/systems directory. Currently, there are
UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available
there. It is a good idea to check pub/corewar/incoming for program updates
first.

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

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

Below is a not necessarily complete or up-to-date list of what's available
at soda:

        MADgic41.lzh    - corewar for the Amiga, v4.1
        MAD4041.lzh     - older version?
        MAD50B.lha      - corewar for the Amiga, beta version 5.0
        Redcoder-21.hqx - corewar for the Mac, supports ICWS'88 and '94
        core-11.hqx     - corewar for the Mac
        core-wars-simulator.hqx - same as core-11.hqx?
        corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but
                not ICWS'88 compatible
        koth31.tar.Z    - corewar for UNIX/X-windows. This program ran the
                          former KotH server at intel.com
        koth.shar.Z     - older version
        kothpc.zip      - port of older version of KotH to the PC
        deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC
        mars.tar.Z      - corewar for UNIX, likely not ICWS'88 compatible
        icons.zip       - corewar icons for MS-Windows
        macrored.zip    - a redcode macro-preprocessor (PC)
        c88v49.zip      - PC corewar, textmode display
        mars88.zip      - PC corewar, graphics mode display
        corwp302.zip    - PC corewar, textmode display, slowish
        mercury2.zip    - PC corewar written in assembly, fast!
        mtourn11.zip    - tournament scheduler for mercury (req. 4DOS)
        pmars06s.zip    - portable system, ICWS'88 and '94, runs on UNIX,
                          PC, Mac, Amiga. C source archive
        pmars06s.tar.Z  - same as above
        pmars062.zip    - PC executables with graphics display, req 386+
        macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2)
			     buggy, no display
	MacpMARS.10.cpt.hqx - port of v0.6 for the Mac, with display and 
			      debugger
	MacpMARS.10s.cpt.hqx - C source (MPW, ThinkC) for Mac frontend
        ApMARS03.lha    - pMARS executable for Amiga (port of version 0.3.1)
        wincor11.zip    - MS-Windows system, shareware ($15)

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

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

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

Q14: I do not have access to Usenet.  How do I post and receive news?
A14: To receive rec.games.corewar articles by email, join the COREWAR-L
list run on the Stormking.Com ListProcessor.  To join, send:

        SUB COREWAR-L FirstName LastName
to:
        LISTPROC@STORMKING.COM

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

Another server that allows you to post (but not receive) articles is
available. Email your post to rec-games-corewar@cs.utexas.edu and it will be
automatically posted for you.

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

Q15: When is the next tournament?
A15: The ICWS holds an annual tournament.  Traditionally, the deadline
for entering is the 15th of December.

The EBS usually holds a preliminary tournament around the 15th of November
and sends the top finishers on to the ICWS tournament.

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

----------------------------------------------------------------------
Q16: What is KotH?  How do I enter?
A16: King Of The Hill (KotH) is an ongoing Core War tournament
available to anyone with email.  You enter by submitting via email a Redcode
program with special comment lines.  You will receive a reply indicating how
well your program did against the current top twenty programs "on the hill".
Your program will play 100 battles against each of the 20 other programs
currently on the Hill. You receive 3 points for each win and 1 point for each
tie.  (The existing programs do not replay each other, but their previous
battles are recalled.) All scores are updated to reflect your battles and all
21 programs are ranked from high to low.  If you are number 21 you are pushed
off the Hill, if you are higher than 21 someone else is pushed off.

The original KotH was developed and run by William Shubert at Intel, and
discontinued after almost three years of service. Currently, KotHs based on
Bill's UNIX scripts but offering a wider variety of hills are are running at
two sites: "koth@stormking.com" is maintained by Scott J. Ellentuch
(tuc@stormking.com) and "pizza@ecst.csuchico.edu" by Thomas H. Davies
(sd@ecst.csuchico.edu). Both KotHs provide very similar services and are
therefore covered together. The principal difference is that "pizza" has a
much faster internet connection than "stormking".

Entry rules for King of the Hill Corewar:

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

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

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

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

   There are currently six separate hills you can select by starting your
   program with ;redcode, ;redcode-x, ;redcode-icws, ;redcode-b, ;redcode-94,
   or ;redcode-94x.  More information on these hills is listed below.

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

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

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

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

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

SAMPLE ENTRY:
;redcode
;name Dwarf
;author A. K. Dewdney
;strategy Throw DAT bombs around memory, hitting every 4th memory cell.
;strategy This program was presented in the first Corewar article.
bomb  DAT   #0
dwarf ADD   #4,    bomb
      MOV   bomb, @bomb
      JMP   dwarf
      END   dwarf          ; Programs start at the first line unless
                           ; an "END start" pseudo-op appears to indicate
                           ; the first logical instruction.  Also, nothing
                           ; after the END instruction will be assembled.

Here are the Specs for the various hills:

ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at
"stormking" and "pizza")
         coresize: 8000
   max. processes: 8000
         duration: after 80,000 cycles, a tie is declared.
max. entry length: 100
 minimum distance: 100
  instruction set: ICWS '88

ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws",
available at "stormking" only)
         coresize: 8192 instructions
   max. processes: 8000 per program
         duration: After 100,000 cycles, a tie is declared.
max. entry length: 300
 minimum distance: 300
  instruction set: ICWS '88

ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x",
available at "pizza" only)
         coresize: 4096
   max. processes: 32
         duration: after 65,536 cycles, a tie is declared.
max. entry length: 64
 minimum distance: 64
  instruction set: ICWS '88

ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at
"stormking" and "pizza")
         coresize: 8000
   max. processes: 8000
         duration: after 80,000 cycles, a tie is declared.
max. entry length: 100
 minimum distance: 100
  instruction set: ICWS '94 Draft

ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available
at "pizza" only)
         coresize: 8000
   max. processes: 8000
         duration: after 80,000 cycles, a tie is declared.
max. entry length: 100
 minimum distance: 100
  instruction set: ICWS '94 Draft

ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x",
available at "stormking" and "pizza")
         coresize: 55440
   max. processes: 10000
         duration: after 500,000 cycles, a tie is declared.
max. entry length: 200
 minimum distance: 200
  instruction set: ICWS '94 Draft

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

All hills run portable MARS (pMARS) version 0.6, a platform-independent
corewar system available at soda (see Q12).

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

        SEQ - Skip if EQual (synonym for CMP)
        SNE - Skip if Not Equal
        NOP - (No OPeration)

        *   - indirect using A-field as pointer
        {   - predecrement indirect using A-field
        }   - postincrement indirect using A-field

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

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

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

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

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

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

Q19: What does (expression or term of your choice) mean?
A19: Here is a selected glossary of terms.  If you have a definition and/or
term you wish to see here, please send it to me.

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

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

B-Scanners - Scanners which only recognize non-zero B-fields.
           example  add #10,scan
           scan     jmz example,10

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

CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents.
           example  add step,scan
           scan     cmp 10,30
                    jmp attack
                    jmp example
           step     dat #20,#20

Color - Property of bombs making them visible to scanners, causing them
   to attack useless locations, thus slowing them down.
           example  dat #100

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

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

DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core
   locations.
           example   . . .
                     . . .
                     djn example,<4000

Dwarf - the prototypical small bomber.

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

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

Imp - Program which only uses the MOV instruction.
           example  MOV 0, 1
       or
           example  MOV 0, 2
                    MOV 0, 2

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

Imp-Ring - A minimal Imp-Spiral.
            d        EQU (coresize+1)/3
            A        MOV 0,d   ; copy self to B
            B        MOV 0,d   ; copy self to C
            C        MOV 0,d   ; copy self to A+1

Imp-Spiral - An Imp-like program with two or more processes supporting
   each other.  A three-point spiral, with six processes running in this
   sequence:
            d        EQU (coresize+1)/3
            A        MOV 0,d   ; copy self to B
            B        MOV 0,d   ; copy self to C
            C        MOV 0,d   ; copy self to A+1
            A+1      MOV 0,d   ; copy self to B+1
            B+1      MOV 0,d   ; copy self to C+1
            C+1      MOV 0,d   ; copy self to A+2

Incendiary Bomb - A type of Stun bomb which creates a SPL 0 carpet.
           example   SPL 0, 8
                     MOV -1, <-1

Mirror - see reflection

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

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

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

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

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

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

Self-Splitting - Strategy of amplifying the number of processes executing
   a piece of code.
           example   SPL 0
           loop      ADD #10, example
                     MOV example, @example
                     JMP loop

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

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

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

Slaver - see Pit-Trapper.

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

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

Stun - A type of bomb which makes the opponent multiply useless processes,
   thus slowing it down.  Example is referred to as a spl-jmp bomb.
          example spl 0
                  jmp -1

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

Vampire - See Pit-Trapper.

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

Q20: Other questions?
A20: Just ask in the rec.games.corewar newsgroup or contact me (address
below). If you are shy, check out the Core War archives on soda first to
see if your question has been answered before (see Q11).

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

Additions/Corrections/etc. to this document are solicited.
The rec.games.corewar FAQ is maintained by:

Stefan Strack, PhD                          stst@vuse.vanderbilt.edu
Institute for Developmental Neuroscience    stst@idnsun.gpct.vanderbilt.edu
P.O. 152, Peabody College                   stracks@vuctrvax.bitnet
Vanderbilt University                       Voice: +615-343-0544
Nashville, TN 37203, USA                    FAX:   +615-343-0242


From: andy.hope@almac.co.uk (ANDY HOPE)
Subject: Atari version?
Message-ID: <8A4D594.01880004ED.uuout@almac.co.uk>
Date: Sat, 04 Mar 95 23:48:00 +0100

Where can I get an up-to-date version for an atari ST?
I have an old version, but it is bug-ridden and doesn't have
half the stuff that the new listings have in them.

Thanx in advance.

Email: andy.hope@almac.co.uk




From: C.D.Ward@dcs.warwick.ac.uk (Frugal)
Subject: SURVEY: Multiplayer and Networked games
Message-ID: <1995Mar6.114129.25056@dcs.warwick.ac.uk>
Date: Mon, 6 Mar 1995 11:41:29 GMT


I am a third year Comp Sci student doing a study of the ways in which the
increase in communications has affected the way in which games are played. 
To help with this, I need information on the ways in which people are using
communications to play games such as AirWarrior and X-Pilot.

I would really appreciate all the responses I can get, if you have other
friends who could help with my enquires please feel free to forward this to
them and get them to fill it out as I am sure that there are a lot of people
who play games over modem who do not have e-mail/news access.

I have set the follow up to Poster, but just in case please mail the
responses to me directly.

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

Age:
Country:
Profession:

1) Which multiplayer games do you play
for each game please fill in the following:
	1.1) How did you discover this game
	1.2) What platform is the game running under
	1.3) Who provides the game.
	1.4) What made you start playing
	1.5) Do you play over TCP/Dial up/IPX/Other
	1.6) What features attracted you to this game
	1.7) Do you play this game in you own country or in another.

2) Which games do you not play and why not

3) How long in total do you spend playing these games in total per month

4) How much do you spend on Phone calls a month connected to games

5) How much do you spend buying multiplayer games each month

6) How long do you stick to one game

7) How many games do you play concurrently

8) If you have a TCP link is it from 
	-University/College
	-Company you work for
	-Commercial Internet provider

9) If you use a modem what speed is it

10) How do you forsee the future of Multiplayer games

11) How many other people do you know who play multiplayer games but do not
have internet access (and hence can not reply to this survey).


Please feel free to tell me anything else which you think will be useful in
my research 

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

--
Frugal the curious                         + Tries hard, fails to achieve 
(Chris Ward)                               + the low standards he sets for
frugal@dcs.warwick.ac.uk                   + himself, works well with a broom
http://www.dcs.warwick.ac.uk/~frugal/index.html             VOTE: SCHLAAAP!!!

PS. If you have seen this before it's because our cross posting is screwed,
sorry.


From: kevin@admin.pacsci.org (Kevin Deitchman)
Subject: Newbie (all most..)
Date: 7 Mar 1995 04:51:48 GMT
Message-ID: <kevin-0603952053490001@79.rahul.net>

   I haven't played with Core War for a long time. What is the best
introduction to icws'94 (or has that been changed?) for someone familiar
with the 88 standard?

Also, this is one of my Little Warriors. It's a reverse imp (kind of, anyway).

   SPL 1
   MOV <3, <3
   JMP -2, 0
   JMP -2, 0
   
It moves backwards, leaving a trail of JMP -2, -4 behind. Anyone like it?

Kevin Deitchman
kevin@admin.pacsci.org


From: tusk@daimi.aau.dk (Martin M|ller Pedersen)
Subject: Re: C++Robots???What the...!
Date: 7 Mar 1995 07:36:51 GMT
Message-ID: <3jh2ej$mg3@belfort.daimi.aau.dk>

Thus spake a920101@zipi.fi.upm.es:

>Hi you all!
>I know what corewar is, but what the heck is that C++ Robots???
>Can anybody tell me where can i get a good implementation of it???
>(BTW Is it cool?)

>Thanks you all boys!

>	Juanje.

A have a WWW-page about C++Robots.

Try:

http://www.daimi.aau.dk/~tusk/pbmserv/crobots.html

=
tusk@daimi.aau.dk
=
"One of the symptoms of an approaching nervous breakdown is the belief
that one's work is terribly important."
                -- Bertrand Russell


Subject: Stormking
Message-ID: <1995Mar7.134824.2067@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 7 Mar 95 13:48:24 -0500

Yesterday I got mail from Stormking concerning a warrior I sent in
some time back.  The fact that it gave me an error didn't concern me -
I could see the error.  What surprised me was that my original message
to Stormking was sent Jan. 26th.  I haven't sent to Stormking in a
long time because of the turnaround time, but 6 weeks?

Just wanted to see if anyone else uses Stormking and has had this much
of a delay on entries.  I have a couple of other entries I never saw
responses for, and now I expect those will show up sometime soon also.

Randy


From: emoyer@valhalla.cs.wright.edu (Eric Moyer)
Subject: Scanner...
Date: 7 Mar 1995 23:47:38 GMT
Message-ID: <3jirar$nei@alpha.wright.edu>

What is a qscanner.  What is the basic algorithm that they use.  I know what
a bomber, an imp ring (or spiral), and a replicator are.  But the FAQ and
the literature on soda don't mention much but the name for scanners.


--
------------------------------------__|__ -------------------------------------
"A wise man once said nothing"        |  Emoyer@valhalla.cs.wright.edu
--------------------------------------| --------------------------------------- 


From: tmcs01 (Tim McSweeney)
Subject: absolute Newbie
Date: 8 Mar 1995 00:53:07 GMT
Message-ID: <tmcs01-0803951353080001@130.216.105.80>

hello all, I'm an absolute beginner at corewars. I have for a long time
known about it and yearned to get involved but have been unable to find
any information about it.  
then I discovered this news group., Oh how happy I am, I have read the FAQ
and ftp'ed a couple of mars systems, however the docs I FTP'ed are garbled
(I have access to the Inet thru' the Varsity macs and must convert
everything to IBM format b4 using it at home), I shall try again with the
documentation but a reply to this message would be nice.

Tim McSweeney


From: speaker.for.the.dead@akron-info.com
Subject: Re: What is this group an
Message-ID: <9503081839.0GTEJ31@akron-info.com>
Date: Wed, 08 Mar 95 18:39:16 -0400


Another great robot programming and fighting program is Arena.  The language
isn't as sophisticated as Redcode, but it shows an ANSI graphic display ohe
fighting.  It's reather an interesting game.

Oh, and would you have any interesting new ideas for Core Warriors? I seem to
be using the same ones over and over again, except for one that sends out
thousands of "PCT 0" statements that it splits to




From: mreddy@comp.glamorgan.ac.uk (Mike Reddy)
Subject: Re: Pointers in pMARS
Date: Thu, 09 Mar 1995 07:16:04 +0000
Message-ID: <mreddy-0903950716040001@mreddy.comp.glam.ac.uk>

In article <3j81v3$7ng@senator-bedfellow.MIT.EDU>, ama@athena.mit.edu
(Albert Ma) wrote:

[Removed - Details about compiler problems portig pMars to PowerPC]

> I believe you're the first person I've heard of to port pMARS on a 
> PowerMac.  Right now my gut feeling is it's a compiler problem.
> Albert Ma               ama@mit.edu

Well actually, it is a student of mine and he has had some trouble with
the compiler (CodeWarrior for Mac and PowerPC). I believe that it is the
original pMars rather than the MacpMars, though I'm not sure. The
difficulty may indeed come from CW as he has failed to get the Mac version
to work correctly, even when the same code runs (with the memory
difficulties described earlier) on the PowerPC. Sometimes file generation
fails, with no explanation.

So, what is he doing? (His email is smejones@glamorgan.ac.uk by the way).
Well, he is attempting to use pMars in a similar way to TIERRA (see
comp.ai.alife or Steven Levy's book "Artificial Life" for details). He has
already seeded a few generations of RANDOMLY generated code. Each
generation of 100 warriors was run against all the others in a two player
tournament. On the PowerPC this took 30 seconds! However, the large
majority ended after only a few instructions (as would be expected. I
beleive that trials with hand coded programs, such as previous ICWS
tournament entries, took up to 45 minutes, which is still a major
improvement).

Intersetingly, even without multiple generations - the long term goal of
the project is to seed new tournaments using one or two part cross-over -
there were a couple of random warriors that never lost against siblings
and occasionally beat hand coded programs. These fell into two categories:

* Ones that were small and did little apart from hide, jump to self or split

* Ones that wrote to random or sequenced memory locations i.e. bombers

It remains to be seen whether cross-over and/or multiple generations have
an effect on performance. Or whether breeding with previous winners will
produce the first computer generated ICWS Tournament winner!

Yours Mike Reddy
--
P.S. I would have had a witty signature, but the Government put VAT on it!

Email: mreddy@comp.glamorgan.ac.uk OR mreddy@glamorgan.ac.uk
Web (coming soon!): http://sal9000.comp.glam.ac.uk/
Snail Mail: Mike Reddy, J228, Dept. of Computer Studies, University of
Glamorgan, Pontypridd, Mid Glamorgan. CF37 1DL Wales, UK
Tel: +44 (0)443 482 240 Fax: +44 (0)443 482 715

P.P.S. Glamorgan University: Top of the League! Applications up 57% this year!


Yours Mike Reddy
--
P.S. I would have had a witty signature, but the Government put VAT on it!

Email: mreddy@comp.glamorgan.ac.uk OR mreddy@glamorgan.ac.uk
Web (coming soon!): http://sal9000.comp.glam.ac.uk/
Snail Mail: Mike Reddy, J228, Dept. of Computer Studies, University of
Glamorgan, Pontypridd, Mid Glamorgan. CF37 1DL Wales, UK
Tel: +44 (0)443 482 240 Fax: +44 (0)443 482 715

P.P.S. Glamorgan University: Top of the League! Applications up 57% this year!


From: Robert@buchanan.demon.co.uk (Robert Macrae)
Subject: Re: See how this looks...
Date: Thu, 9 Mar 1995 17:28:37 +0000
Message-ID: <794770117snz@buchanan.demon.co.uk>

One day I'll work out how to quote from news. In the meantime, I hope these
comments make sense without.

I like your DAT-based quickscanner. I've been looking at quickscans for a
while; it seems to me that if you're going to have a decoy anyway, you should 
make it work for for you by doing something! The advantage of your dat-based
one is that the bulky/vulnerable part need never be executed, and you could 
launch the scanning code if it is short. 

As you point out, the big problem is the scanning speed. A SNE/SEQ 
quickscan looks at 2 locations per cycle, a fast looping scanner
like "Taking Names" can manage 0.8 locations, and the DAT-based scanner
manages 1 per cycle. You don't have too much of an edge over normal
scanners in speed, but maybe you don't have too much of a penalty either. 
The scanning code can be launched and hits on the DATs aren't as serious 
as they are for a conventional Quickscan, so you are in the middle -- slower 
than a normal quickscan but less vulnerable; faster than a normal scan, 
but with bulky DATs.

Sounds like an interesting compromise. Could you use this approach to do 
multiple scans? Indirecting with {< in place of *@ in the SNE step, you 
would attack a different location the next time round; I know the 
separation is lousy but it might be good enough against papers? Or how 
about the large hill? I've never tried writing anything there but I guess 
that if quickscans work at all, the greater density of the DAT-scan would 
pay off since there is more ground to cover...

BTW, I didn't really understand the launch code in QCmp-Hunter. Wouldn't
something like

moveme  mov.i }datsite, >datsite     
        mov.i }datsite, >datsite
        djn   -2,       #(LEN+1)/2

be faster than splitting?
--
Robert Macrae


From: rittiman@cs.utexas.edu (Johnny Wayne Rittiman)
Subject: Uncompressing .Z files
Date: 10 Mar 1995 11:32:55 -0600
Message-ID: <3jq2g7$cs9@earth.cs.utexas.edu>

I've seen several people ask about .Z files so I figured I'd say this:

 .Z files are created by the compression program: compress   which
is found on UNIX systems...if you have a UNIX account you,most likely,
could just type

myprompt> uncompress <filename>

make sure you don't type the .Z part of the name. For Example: if the
file's name was myfile.Z  then you would type:  uncompress myfile

pretty simply really....unless you don't have a Unix account...I'm not
sure if there are programs on other platforms that will decompress 'em.

Hope you find this helpful...

Wayne.


Subject: Re: See how this looks...
Message-ID: <1995Mar10.161010.2070@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 10 Mar 95 16:10:09 -0500

Robert Macrae (Robert@buchanan.demon.co.uk) wrote:
: BTW, I didn't really understand the launch code in QCmp-Hunter. Wouldn't
: something like

: moveme  mov.i }datsite, >datsite     
:         mov.i }datsite, >datsite
:         djn   -2,       #(LEN+1)/2

: be faster than splitting?
Yes, or even
 moveme mov.i }datsite, >datsite
        mov.i }datsite, >datsite
        mov.i }datsite, >datsite
        mov.i }datsite, >datsite
        mov.i }datsite, >datsite
        spl.a cmper+MOVETO, <2667
        mov.i }datsite, >datsite
        mov.i }datsite, >datsite
        mov.i }datsite, >datsite
        mov.i }datsite, >datsite
        mov.i }datsite, >datsite
        mov.i }datsite, >datsite
        mov.i }datsite, >datsite

I have just been trying several ways and seeing what trade-offs are
involved between speed and code-size.  Haven't dound the right thing
yet (they all sem to give about the same end result).
: --
: Robert Macrae

Randy


From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant)
Subject: Re: Windows Program
Date: 11 Mar 1995 02:16:44 GMT
Message-ID: <3jr16c$3p0@agate.berkeley.edu>

Randy Graham <graham@harlie.mathcs.rhodes.edu> wrote:
>I have written a simple Visual Basic program to help me with figuring
>step sizes.  I was wondering if I should put the source and .exe on
>scotch/soda/berkeley/WhateverItIsThisMonth ;-) for others to use.

While the actual computer that the ftp stuff it stored on keeps changing,
the name "ftp.csua.berkeley.edu" will always point to the right computer.
-- 
            Michael Constant (mconst@soda.csua.berkeley.edu)


From: brekerg@cuug.ab.ca (Breker)
Subject: PCrobots
Message-ID: <D59Gxw.L75@cuug.ab.ca>
Date: Sat, 11 Mar 1995 05:37:08 GMT

Anyone using the 1992 program... PcRobots?

Can anyone direct me to where I can get other ppls robots to try??

Thanks



Subject: Re: Scanner...
Message-ID: <1995Mar11.094023.2071@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 11 Mar 95 09:40:22 -0500

Eric Moyer (emoyer@valhalla.cs.wright.edu) wrote:
: What is a qscanner.  What is the basic algorithm that they use.  I know what
: a bomber, an imp ring (or spiral), and a replicator are.  But the FAQ and
: the literature on soda don't mention much but the name for scanners.

You are right, this should be in the FAQ.  I asked the same question a
few weeks ago, and after some work figured it out.  Basically, a
QuickScan is a series of cmp/mov instructions or sne/seq/mov
instructions in '94 to quickly scan a predetermined set of locations.
When a discrepency is found, the mov command moves a pointer to some
test location.  Otherwise, the cmp or sne/seq commands run, checking
two locations every turn, skipping the mov commands.  At the end of
the run, your warrior checks the test location, and if it is still #0
(which it should be written with originally) jump to a section to mov
and start your real warrior.

I posted a couple of different versions
of a QuickScanning Hunter (my current attempt at the 94 hill).  I will
try to pull them back together and post them again or mail them to
you.  Also, look through the archives of this group.  One of them has
code for Pyramid, the only other Q-Scanner I remember seeing posted
here.  It is really a good program.

OK, now the examples.  You basic 88 code Quick scanner uses cmp/mov
combinations:


found  dat #0,   #0
       mov #-750, found
       cmp -950, -1050
       mov #-950, found
       cmp -1150, -1250
       mov #-1150, found
test   jmz moveme, found

With the above code, you test 2 locations for every 2 lines of code.  
50% efficiency isn't that bad, but '94 rules do better.  So, '88 takes
60 lines to test 60 locations.  Following is the '94 version:

start  sne.i   -750,   -850
       seq.i   -950,   -1050
       mov.ab  #-750,  test
       sne.i   -1150,  -1250
       seq.i   -1350,  -1450
       mov.ab  #-1150, test

test   jmz.b   moveme, #0    ;#0 gets changed by above if anything found
attack [code to do some sore of attack here]
moveme [move your warrior and start him, leaving big decoy behind]

With this code, in 60 lines of code, you check 80 locations, getting
2 compares of 2 sites in 3 lines.  M.Constant (I hope it is he) is
working on chapter 3 of his book, I understand, which will cover
scanners.  Hopefully this means quick scanners also.  Look through old
archives of this newsgroup for pyramid.  A good vampire which starts
off with a quick scan.

Now, after explaining some how QScanners work, I want to tell how I do
them differently, so when I send or post my code, you'll know what the
difference is.  Instead of moving indicating a memory location I found
different, I mov a pointer to the line which found the difference.
That way, I can adjust that lines pointer and mov it where my attack
always uses the same location as a memory pointer.  So above, instead
of #-750 on my move, I would mov #-5, pointing test to the first seq.i
line. Then, in my attack, I would again check -950 and -1050, only
they would now be -955, -1055 (look at the code when you get it).
This takes a little longer to set up (usually two more instructions),
but allows for a shorter bombing run, thus getting me to running the
real me sooner.

I have also done a different version of a QScan which I call a QDat
scan which has the speed of an 88 QScan but greater code density than
a '94 scan (I can check over 100 locations in 60 lines of code).
I'll post it also.  Unfortunately, I haven't written a warrior yet
that was improved by a Quick Scan, but I know others have, so maybe
they can give you better info.

I know this is a long post, but I tried to be fairly complete in my
explanation.  Feel free to post any more questions here or mail me
directly.

: --
: ------------------------------------__|__ -------------------------------------
: "A wise man once said nothing"        |  Emoyer@valhalla.cs.wright.edu
: --------------------------------------| --------------------------------------- 

Randy
graham@mathcs.rhodes.edu



Subject: Re: Scanner...
Message-ID: <1995Mar11.103913.2073@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 11 Mar 95 10:39:13 -0500

Oops, in my earlier post I said my Dat scan matched an 88 qscan.
Obviously not true.  I meant it matches the basic structure.  I claim
an early morning incoherence plea for why I said that.  Also one extra
note on the Dat scan.  It exits the scan and attacks as soon as an
enemy is found, which is the only thing about it I find beats the
regular QScans (other than density, which is less useful than speed
except to big guys like some imps).
Randy


From: pk6811s@acad.drake.edu
Subject: Re: Scanner...
Date: 11 Mar 95 21:34:09 CST
Message-ID: <1995Mar11.213409@acad.drake.edu>

In article <1995Mar11.094023.2071@rhodes>, graham@harlie.mathcs.rhodes.edu (Ran
>...
> OK, now the examples.  You basic 88 code Quick scanner uses cmp/mov
> combinations:
>
>
> found  dat #0,   #0
>        mov #-750, found
>        cmp -950, -1050
>        mov #-950, found
>        cmp -1150, -1250
>        mov #-1150, found
> test   jmz moveme, found
>

Close.  More acurately it should be:

 found  dat #0,   #0
        mov #-750, found            <- not sure what this is??
        cmp -950, -1050             <- start scanning here
        mov #-950-found-1, found
        cmp -1150, -1250
        mov #-1150-found-1, found
 test   jmz moveme, found           <- test found after some scans

Attached is QuickFreeze, the original '88 qscanner.  It uses named offsets
to compute the scan locations but is basically the same idea as above.
Under '94 rules using sne/seq/mov you don't scan faster, but you do it
with less code so that would be preferred.  On the other hand, Randy's
dat-scanner has the advantage of placing the scanning code far away from
the scan pointers so is less likely to be hurt by another scanner
in the early moments.

Paul Kline
pk6811s@acad.drake.edu

;redcode quiet
;name QuickFreeze v1.5
;kill QuickFreeze
;author P.Kline
;contact pk6811s@acad.drake.edu
;strategy faster-than-c scan finds large opponents fast
;strategy also anti-imp paper and anti-vamp
csize   equ -400
cmpsp   equ (csize/35)/4-1     ; scan every 2*cmpsp locations
cmpdif  equ -1/2+1             ; cmp N and N+cmpdif+1
cmpstrt equ start+100+cmpsp    ; start scanning at cmpstrt
boffset equ 5                  ; adjust for bombing
bspl    dat <-40,#(3+cmpdif)   ; bomb

stms    spl 1,cmpsp
        spl 1,cmpdif
        mov -1,0
p1s     mov p1b,<1000
p1      mov #7,p1s             ; 7-process paper
        mov <p1s,<p1n          ; create child
p1n     spl @p1n,-1188         ; start child
        mov p1b,<p1n
        jmz @0,@p1             ; if i'm ok, go again
p1b     dat <2667,<5334

start   spl start2             ; a little redundancy
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        jmn btest,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        jmp btest
start2  cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        jmn btest,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
        cmp cmpstrt-(start*cmpsp)+cmpdif,cmpstrt-(start*cmpsp)+1
        mov #cmpstrt-((start+1)*cmpsp)-bombptr+boffset,bombptr
btest   mov 100,0             ; only need one process now
        jmz st2,bombptr       ; skip bombing if nothing found
binc    spl 0,<-5
bomber  mov bspl,@bombptr     ; drop two bombs per loop
        sub #4,bombptr 
bombptr mov bspl,@0
        djn bomber,#4         ; short spread
        add #98,bombptr       ; reset pointer for extended spread
        mov p1b,binc          ; don't generate any more cycles
st2     spl stms              ; go to next phase
avamp   spl 0,bspl-10         ; stationary anti-vamp
av2     sub <avamp,@av3
av3     mov p1b,<bspl-10+4
        djn av2,#120
        mov bspl,-1
        end start



From: pk6811s@acad.drake.edu
Subject: Re: Scanner...
Date: 11 Mar 95 21:58:22 CST
Message-ID: <1995Mar11.215822@acad.drake.edu>

In article <3jirar$nei@alpha.wright.edu>, emoyer@valhalla.cs.wright.edu (Eric Moyer) writes:
> What is a qscanner.  What is the basic algorithm that they use.  I know what
> a bomber, an imp ring (or spiral), and a replicator are.  But the FAQ and
> the literature on soda don't mention much but the name for scanners.

Before quick-scanners there were two basic kinds, cmp-scanners and b-scanners.
A cmp-scanner uses the CMP instruction to compare two locations in core.  If
they are not equal it proceeds to attack one or both locations, usually with
some kind of spl-bomb.  A b-scanner uses a JMN instruction to check the b-field
of a core-location for zero.  B-scanners suffered somewhat from author's 
deliberately making b-fields zero to shield them from detection.  Under
'94 rules b-scanners are turned into f-scanners, making them much more
difficult to fool.

A basic cmp-scanner algorithm is Charon:

;redcode
;name Charon v8.0
;kill Charon
;author Cisek,Strack,Kline
;strategy cmp-scanner, using spl-jmp bomb and imp-killing step
;strategy (extensive history deleted <- PK)

STEP    equ 164                          ;scan constants:
DIST    equ 82                           ;small, so can be reused in core clear
DJNOFF  equ decr-DIST
FIRST   equ DJNOFF+794                   ;optimal offset to DJN train

attack  add switch,@compptr              ;switch A- and B-fields
        mov jump,@comp
compptr mov split,<comp
scan    add incr,@compptr
comp    cmp FIRST-DIST,FIRST
        slt #incr-attack+DIST+1,@compptr ;don't hit self
decr    djn scan,<DJNOFF                 ;countdown to clear
        jmz attack,0                     ;enter clear when this is decremented
split   spl 0,<2667                      ;clear core
switch  mov @0-DIST,<1-DIST
jump    jmp -1,<2667
incr    dat #STEP,#STEP

        end comp

And here is a formerly very tough b-scanner, which was only run off the Hill
by the onslaught of imp-spirals.

;redcode quiet
;name B-scanners live in vain
;author Matt Hastings
      add #1226,3
start jmz -1,@2
      mov grave,@1
      mov prog,<-2+1226
      jmn -4,-4
prog  spl 0,0
mov   @10,<-1
grave jmp -1,0

      end start

B-scanners scan 1 core location in a 2-instruction loop for a 50% rate,
while cmp-scanners scan 2 locations in a 3-instruction loop for a 66% rate.
Yet b-scanners are smaller than cmp-scanners so tend to be harder to destroy.

Paul Kline
pk6811s@acad.drake.edu


From: tusk@daimi.aau.dk (Martin M|ller Pedersen)
Subject: Re: How do I view .Z docs?
Date: 12 Mar 1995 11:40:22 GMT
Message-ID: <3jumj6$ml0@belfort.daimi.aau.dk>

Thus spake rcallum@primenet.com (Roy Callum):

>Can someone take the time to tell us newbies how to view the .Z format 
>documentation. I have seen this question asked twice now so it might be
>an idea to add the answer to the FAQ.

.Z files is packed with the old unix commando compress.
If you are on a unix system you can uncompress the files simply
with the program 'uncompress'.

tusk@daimi.aau.dk
"Anything too stupid to be said is sung."
                -- Voltaire








Subject: Re: Scanner...
Message-ID: <1995Mar12.130709.2076@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 12 Mar 95 13:07:08 -0500

pk6811s@acad.drake.edu wrote:
: Close.  More acurately it should be:

:  found  dat #0,   #0
:         mov #-750, found            <- not sure what this is??
:         cmp -950, -1050             <- start scanning here
:         mov #-950-found-1, found
:         cmp -1150, -1250
:         mov #-1150-found-1, found
:  test   jmz moveme, found           <- test found after some scans

Well, that line is the result of tremendous line noise while working
on the reply.  I got kicked out of my account several times while
working on the reply, and had to use vi -r reply several times to get
it right.  I thought I had everything cleaned up, but apparently
didn't.  Here is what I MEANT to send...


  found  dat #0,   #0
  begin  cmp -750, -850       ;Begin here
         mov #-750, found     ;now does this make sense here?? :-]
         cmp -950, -1050          
         mov #-950, found
         cmp -1150, -1250
         mov #-1150, found
  test   jmz moveme, found    ;if nothing found, move me

Hope that looks a little better.  And thanks for making the adjustment
on the mov lines.  I do this in my code, but forgot them when posting,
even though I mentioned that I do them when writing my own.  Will I
never learn?

Randy


From: KLOTZ@deimos.oit.umass.edu (Jay Klotz)
Subject: Instruction set - where?
Date: 12 Mar 1995 19:52:22 GMT
Message-ID: <3jvjdm$avi@nic.umass.edu>


Does anyone know where I can find the most recent (official?) Core War
instruction set? I've seen reference to several versions. Which one is
the current standard, if any?


--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
< jay klotz		     	| Mae'n brydgell ac mae'r brochgim stwd  >
< klotz@phast.umass.edu		| Yn gimblo a gyrian yn y mhello:        >
< UMass Amherst			| Pob colomrws yr feddabwd               >
< 413-585-0760/413-545-0163	| A'r hoch oma'n chwibruo.               >
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/


From: thorfinn@jolt.mpx.com.au (David Goh)
Subject: Re: How do I view .Z docs?
Date: 13 Mar 1995 12:33:10 GMT
Message-ID: <3k1e26$13k@inferno.mpx.com.au>

On Thu, 9 Mar 1995 11:02:51 MST Roy Callum (rcallum@primenet.com) wrote:
> Can someone take the time to tell us newbies how to view the .Z format 
> documentation. I have seen this question asked twice now so it might be
> an idea to add the answer to the FAQ.

.Z files are 'compress'ed.

You can either uncompress them, or view them with zcat if they're
text.  'uncompress file.Z' will create 'file' and remove 'file.Z'
Once uncompressed, view as normal... Otherwise, you can do:
'zcat file.Z | more' to view the compressed file...

Later,

	Thorfy

--------------------------------------------------------------------------
| Polyamorous.  Switch.  | "and my domino happens at midnight            |
| Bisexual (Mostly).     |  he rides on a wave of destruction            |
| Painslut.  Always!     |  he lives for excess and seduction" -- Clouds |
--------------------------------------------------------------------------


From: sbeitzel@netcom.com (Stephen Beitzel)
Subject: Re: Uncompressing .Z files
Message-ID: <sbeitzelD5E6Fs.A1M@netcom.com>
Date: Mon, 13 Mar 1995 18:38:16 GMT

Johnny Wayne Rittiman (rittiman@cs.utexas.edu) wrote:
: pretty simply really....unless you don't have a Unix account...I'm not
: sure if there are programs on other platforms that will decompress 'em.

There is MacCompress for the (obviously) Macintosh.  I'm pretty sure that
somebody has ported compress over to DOS as well.
-- 
Stephen Beitzel
DoD# 4E71   '91 SwitchIt in-lines   '93 Vision R40    '95 BMW K75


Subject: PMars and Linux
Message-ID: <1995Mar14.194436.2110@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 14 Mar 95 19:44:36 -0500

Tonight, I ftp'ed the source for PMars6.2.  I zcat | tar xvf - it, and
did a make.  It stopped on unknown library libtermlib.  Well, sure
enough I have no libtermlib.  So, on a hunch, I edit the makefile to
only link libcurses.  It compiles fine, and runs fine (text only
display, but I don't even want that much - just final output - so I
can -v it).  Anyway, my question is, for what is termlib linked?  Why
is it needed in the makefile, but not needed in Linux?

Randy


Subject: Re: PMars and Linux
Message-ID: <1995Mar15.140639.2115@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 15 Mar 95 14:06:38 -0500

Albert Ma (ama@snuff.erlm.siemens.de) wrote:
[My letter deleted]

: libtermlib is required for some other platforms.  In linux I think that
: functionality is in libc.  It's safe to remove it.
: Does curses work completely for you?  My curses libraries are really
: messed up.  Does control-c bring you into the debugger?
Yes, but I like to run without the display normally.  I just want
results.  But curses display does work.  Painfully slow though...
Also, does anyone know if work has been done on an SVGALib port of
PMars for Linux (I'll look, but I'm not good enough to do it - not a
real C-man).

: By the way, you could do tar xvzf instead of zcat | tar
I know, but I've gotten so used to my system at work, which uses SCO
that I'm used to zcatting.  Maybe I need to upgrade them???  :-)


: Albert Ma	ama@mit.edu

Randy


From: ama@snuff.erlm.siemens.de (Albert Ma)
Subject: Re: PMars and Linux
Date: 15 Mar 1995 17:41:11 GMT
Message-ID: <3k78rn$bta@senator-bedfellow.MIT.EDU>

Randy Graham (graham@harlie.mathcs.rhodes.edu) wrote:
: Tonight, I ftp'ed the source for PMars6.2.  I zcat | tar xvf - it, and
: did a make.  It stopped on unknown library libtermlib.  Well, sure
: enough I have no libtermlib.  So, on a hunch, I edit the makefile to
: only link libcurses.  It compiles fine, and runs fine (text only
: display, but I don't even want that much - just final output - so I
: can -v it).  Anyway, my question is, for what is termlib linked?  Why
: is it needed in the makefile, but not needed in Linux?

libtermlib is required for some other platforms.  In linux I think that
functionality is in libc.  It's safe to remove it.
Does curses work completely for you?  My curses libraries are really
messed up.  Does control-c bring you into the debugger?

By the way, you could do tar xvzf instead of zcat | tar

Albert Ma	ama@mit.edu


From: hordurk@rhi.hi.is (Hordur Kvaran)
Subject: Re: How do I view .Z docs?
Date: 15 Mar 1995 23:58:59 GMT
Message-ID: <3k7v03$rec@eldborg.rhi.hi.is>

In <rcallum.1.001822D9@primenet.com> rcallum@primenet.com (Roy Callum) writes:

>Can someone take the time to tell us newbies how to view the .Z format 
>documentation. I have seen this question asked twice now so it might be
>an idea to add the answer to the FAQ.

This is a UNIX compression.  Try uncompress filename.Z and then read it.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Hordur Kvaran 			|				 |
| University of Iceland 		|	"I can resist everything |
| Mechanical Engineering		|	 except temptation	 |
| hordurk@vel.verk.hi.is		|		-Oscar Wilde	 |
| URL:  http://www.rhi.hi.is/~hordurk/	|				 |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant)
Subject: Corewar Tutorial (maybe)
Date: 16 Mar 1995 21:15:01 GMT
Message-ID: <3ka9ol$nhv@agate.berkeley.edu>

Aargh, I was basically finished the corewar tutorial I've been writing,
and the computer with my only copy of it just died.  I am currently in the
process of trying to restore as much of the data as I can... but I don't
know how successfull I'll be.  If I do get the computer working again for
long enough to grap a copy of the tutorial, I will post what I have so far.

Sorry for the delay.
-- 
            Michael Constant (mconst@soda.csua.berkeley.edu)


From: cm4bcrjc@bs47c.staffs.ac.uk (Richard.Clamp)
Subject: Re: Obtain corewar with web ?
Date: 17 Mar 1995 13:53:59 GMT
Message-ID: <3kc49n$lvi@bs33n.staffs.ac.uk>

RANO Didier (drano@simplet_8.univ-lr.fr) wrote:
: I don't access to ftp.
: But i can have an access to web ...
:  
: Thank you
Then you have ftp, as the URL just type ftp://ftpsite instead of
http://website and take it from there.

Richard

--
---------1---------2---------3--------4---------5---------6---------7
Richard Clamp / Doolittle    |  Standard Disclaimer: My views are my 
cm4bcrjc@bs47c.staffs.ac.uk  |  own no one else wanted them.


From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Re: Instruction set - where?
Date: 17 Mar 1995 15:14:42 -0600
Message-ID: <9503172114.AA02892@vvcs.vuse>

In article <3jvjdm$avi@nic.umass.edu> KLOTZ@deimos.oit.umass.edu (Jay Klotz) writes:
>
>Does anyone know where I can find the most recent (official?) Core War
>instruction set? I've seen reference to several versions. Which one is
>the current standard, if any?
>
>< jay klotz		     	| Mae'n brydgell ac mae'r brochgim stwd  >

The "official" standard is still ICWS'88 and you can read about it in
ftp://ftp.csua.berkeley.edu/pub/corewar/documents/standards/redcode-icws-88.Z
(use "gunzip" or "uncompress"). The unofficial standard (i.e. not yet ratified
by the ICWS), at least judging by the prevalence of '94 code on the hills and
this newsgroup is ICWS'94. The pointer here is
ftp://ftp.csua.berkeley.edu/pub/corewar/documents/icws94.0202.Z
This file is my 02/02/94 update of the draft initiated mostly by Mark Durham.
It does not yet contain the new instructions and addressing modes (SEQ,SNE,NOP,
{.},*) that were recently added to the pMARS simulator. A quick reference to the
redcode language currently supported by pMARS (essentially a '94 superset) is
in the file redcode.ref, part of the pMARS distribution archive.

As to when ICWS'94 will be formally accepted, I don't know. ICWS directorship
is currently in transition, and we haven't decided how to organize the discussion/
voting process yet. If you have comments about ICWS'94 as it currently implemented
on koth, this is a good time and place to voice them.

-Stefan


Subject: spl.? question
Message-ID: <1995Mar18.153719.2166@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 18 Mar 95 15:37:18 -0500

I have a warrior I am using to figure something out with the spl
command.  The full source (as read in from my file) is:
      spl    0,   5
When I put this against an imp (mov  0,  1), it always ties.  When I
look at the assembly of spl.war, I see
[assert warning deleted]
START  SPL.B  $     0, $     5

Now, the way I thought modifiers worked, this would take the b-field
as its location to spl to.  Thus, spl.war would go
     spl.b    0,    5
     dat.f    0,    0   <-execute this next
     dat.f    0,    0
     dat.f    0,    0
     dat.f    0,    0
     dat.f    0,    0   <-then execute this and die
But that isn't what happens.  This whole problem came about when I had
a warrior never win that should have.  At first I thought I had coded
something wrong in the scan or attack.  But when I used cdb (in
PMars), it went different from what I expected at the instruction:
     spl.b   >-15,   #-15
Instead of splitting to itself, which I thought the .b indicated, it
split to spl-15.  So, my core clear didn't work, thus I died or tied
all the time.I had a similar problem with my jmp command in a spl/jmp
bomber I wrote.  I don't remember it now, but when I can look it up
again I will ask about it.

Ultimately I worked around both problems, but I would like to
understand why my splits always split to the a-field.  I could not
find a reason in the '94 draft, but I may have overlooked it.  Anyone
able to help me?

Randy


From: bmellows@jolt.mpx.com.au (Bruce Mellows)
Subject: Re: How do I view .Z docs?
Date: 18 Mar 1995 18:52:30 GMT
Message-ID: <3kfa5e$a85@inferno.mpx.com.au>

Roy Callum (rcallum@primenet.com) wrote:
: Can someone take the time to tell us newbies how to view the .Z format 
: documentation. I have seen this question asked twice now so it might be
: an idea to add the answer to the FAQ.

Also you can just "get" them without the .Z and the sending machine 
should uncompress it before sending it.

eg. instead of "get foo.bar.Z" try "get foo.bar"

I dont know how widespread this is, but I have seen it mentioned, and I 
think I actually did it myself on occasions, before I found out how to 
uncompress it at my end.

Hope that helps
Bruce Mellows


Subject: Re: spl.? question
Message-ID: <1995Mar19.071425.2169@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 19 Mar 95 07:14:24 -0500

Michael Constant (mconst@soda.CSUA.Berkeley.EDU) wrote:
: > [spl.b question deleted]

: Yes, spl.b does split to its A-target rather than its B-target.  The reason
: for this, briefly, is that if spl.b split to its B-target than spl.f would
: have to split to its A-target *and* B-target, and this would make spl-bombs
: far too powerful.  So, the problem of spl.f was neatly dodged by making spl
: ignore its modifier and always split to the A-target.

: In fact, all of the opcodes which affect the process queue will only accept
: the A-target as the new location, regardless of the modifiers.  Spl and jmp
: ignore their modifiers entirely, while jmn, jmz and djn use the modifier
: only for the secondary part of their operation (testing/decrementing core
: locations, rather than the jump itself).
Seems to me that spl.f could be made to fall back to spl.a or spl.b
the same way djn.i is made to fall back to djn.f.  Regardless, thank
you for the explanation.  That explains why my warrior failed so much.
Thx.

: -- 
:             Michael Constant (mconst@soda.csua.berkeley.edu)
Randy


From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant)
Subject: Re: spl.? question
Date: 19 Mar 1995 09:48:39 GMT
Message-ID: <3kguln$t3d@agate.berkeley.edu>

Randy Graham <graham@harlie.mathcs.rhodes.edu> wrote:
> [spl.b question deleted]

Yes, spl.b does split to its A-target rather than its B-target.  The reason
for this, briefly, is that if spl.b split to its B-target than spl.f would
have to split to its A-target *and* B-target, and this would make spl-bombs
far too powerful.  So, the problem of spl.f was neatly dodged by making spl
ignore its modifier and always split to the A-target.

In fact, all of the opcodes which affect the process queue will only accept
the A-target as the new location, regardless of the modifiers.  Spl and jmp
ignore their modifiers entirely, while jmn, jmz and djn use the modifier
only for the secondary part of their operation (testing/decrementing core
locations, rather than the jump itself).
-- 
            Michael Constant (mconst@soda.csua.berkeley.edu)


From: albino@ns.net (Byron C. Ellis)
Subject: Re: Pointers in pMARS
Date: 19 Mar 1995 20:56:46 GMT
Message-ID: <3ki5qe$7ka@falcon.ns.net>

In article <mreddy-0903950716040001@mreddy.comp.glam.ac.uk>, mreddy@comp.glamorgan.ac.uk (Mike Reddy) says:
>
>In article <3j81v3$7ng@senator-bedfellow.MIT.EDU>, ama@athena.mit.edu
>(Albert Ma) wrote:
>
>[Removed - Details about compiler problems portig pMars to PowerPC]
>
>> I believe you're the first person I've heard of to port pMARS on a 
>> PowerMac.  Right now my gut feeling is it's a compiler problem.
>> Albert Ma               ama@mit.edu
>
>Well actually, it is a student of mine and he has had some trouble with
>the compiler (CodeWarrior for Mac and PowerPC). I believe that it is the
>original pMars rather than the MacpMars, though I'm not sure. The
>difficulty may indeed come from CW as he has failed to get the Mac version
>to work correctly, even when the same code runs (with the memory
>difficulties described earlier) on the PowerPC. Sometimes file generation
>fails, with no explanation.
>
>So, what is he doing? (His email is smejones@glamorgan.ac.uk by the way).
>Well, he is attempting to use pMars in a similar way to TIERRA (see
>comp.ai.alife or Steven Levy's book "Artificial Life" for details). He has
>already seeded a few generations of RANDOMLY generated code. Each
>generation of 100 warriors was run against all the others in a two player
>tournament. On the PowerPC this took 30 seconds! However, the large
>majority ended after only a few instructions (as would be expected. I
>beleive that trials with hand coded programs, such as previous ICWS
>tournament entries, took up to 45 minutes, which is still a major
>improvement).
>
>Intersetingly, even without multiple generations - the long term goal of
>the project is to seed new tournaments using one or two part cross-over -
>there were a couple of random warriors that never lost against siblings
>and occasionally beat hand coded programs. These fell into two categories:
>
>* Ones that were small and did little apart from hide, jump to self or split
>
>* Ones that wrote to random or sequenced memory locations i.e. bombers
>
>It remains to be seen whether cross-over and/or multiple generations have
>an effect on performance. Or whether breeding with previous winners will
>produce the first computer generated ICWS Tournament winner!
>
>Yours Mike Reddy
>--
>P.S. I would have had a witty signature, but the Government put VAT on it!
>
>Email: mreddy@comp.glamorgan.ac.uk OR mreddy@glamorgan.ac.uk
>Web (coming soon!): http://sal9000.comp.glam.ac.uk/
>Snail Mail: Mike Reddy, J228, Dept. of Computer Studies, University of
>Glamorgan, Pontypridd, Mid Glamorgan. CF37 1DL Wales, UK
>Tel: +44 (0)443 482 240 Fax: +44 (0)443 482 715
>
There's also a paper on soda.berkeley.edu called evolving warriors that 
does nearly the same thing with generations of 1000 warriors.


From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant)
Subject: Re: spl.? question
Date: 20 Mar 1995 07:09:57 GMT
Message-ID: <3kj9o5$2n7@agate.berkeley.edu>

Randy Graham <graham@harlie.mathcs.rhodes.edu> wrote:
>Michael Constant (mconst@soda.CSUA.Berkeley.EDU) wrote:
>: Yes, spl.b does split to its A-target rather than its B-target.  The reason
>: for this, briefly, is that if spl.b split to its B-target than spl.f would
>: have to split to its A-target *and* B-target, and this would make spl-bombs
>: far too powerful.
>
>Seems to me that spl.f could be made to fall back to spl.a or spl.b
>the same way djn.i is made to fall back to djn.f.

It could, but that wouldn't really make too much sense.  Djn.i is treated
as djn.f just because djn.i makes no sense -- it is impossible to decrement
an instruction.  However, spl.f makes perfect sense, it's just too powerful
if it is treated in the more intuitive fashion (i.e. split to both the A-
and B-targets).
-- 
            Michael Constant (mconst@soda.csua.berkeley.edu)


From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ)
Date: 20 Mar 1995 13:21:43 GMT
Message-ID: <games/corewar-faq_795705691@rtfm.mit.edu>

Archive-name: games/corewar-faq
Last-modified: 1994/11/25
Version: 2.3.1

These are the Frequently Asked Questions (and answers) from the USENET
newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP
from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z.


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

 1. What is Core War?                                                 69

 2. Is it Core War or Core Wars?                                      82

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

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

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

 6. What is the ICWS?                                                152

 7. What is TCWN?                                                    162

 8. How do I join?                                                   170

 9. Are back issues of TCWNs available?                              187

10. What is the EBS?                                                 194

11. Where are the Core War archives?                                 208

12. Where can I find a Core War system for . . . ?                   226

13. I do not have ftp.  How do I get all of this great stuff?        275

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

15. When is the next tournament?                                     303

16. What is KotH?  How do I enter?                                   314

17. Is it DAT 0, 0 or DAT #0, #0?  How do I compare to core?         483

18. How does SLT (Skip if Less Than) work?                           495

19. What does (expression or term of your choice) mean?              507

20. Other questions?                                                 650

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

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

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

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

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

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

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

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

Author: Dewdney, A. K.
Title: The Magic Machine: A Handbook of Computer Sorcery
Published: New York: W. H. Freeman (c) 1990
ISBN: 0-7167-2125-2 (Hardcover), 0-7167-2144-9 (Paperback)
Library of Congress Call Number: QA76.6 .D5173 1990

A.K. Dewdney's articles are still the most readable introduction to
Core War, even though the Redcode dialect described in there is no
longer current (see Q 4).

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

Q 4: Core War has changed since Dewdney's articles. Where do I get a
copy of the current instruction set?
A 4: A draft of the official standard (ICWS'88) is available by anonymous
FTP from the Core War archives (ftp.csua.berkeley.edu) as
pub/corewar/documents/standards/redcode-icws-88.Z

This document is formatted awkwardly and contains ambiguous statements. For a
more approachable intro to Redcode, take a look at
pub/corewar/documents/tutorial.1.Z
                      tutorial.2.Z
(See also Q11)

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

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

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

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

Q 6: What is the ICWS?
A 6: About one year after Core War first appeared in Sci-Am, the
"International Core War Society" (ICWS) was established.  Since that
time, the ICWS has been responsible for the creation and maintenance
of Core War standards and the running of Core War tournaments.  There
have been six annual tournaments and two standards (ICWS'86 and
ICWS'88).

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

Q 7: What is TCWN?
A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the
official newsletter of the ICWS.  It is published quarterly and recent
issues are also available as Encapsulated PostScript on ftp.csua.berkeley.edu
(see Q9).

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

Q 8: How do I join?
A 8: For more information about joining the ICWS (which includes a
subscription to TCWN), or to contribute an article, review, cartoon, letter,
joke, rumor, etc. to TCWN, please contact:

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

Current annual dues are $15.00 in US currency.

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

Q 9: Are back issues of TCWN available?
A 9: Recent issues can be found on ftp.csua.berkeley.edu (see Q11).
Older issues (up to Winter 1991) are also available (see the next TCWN
for details).

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

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

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

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

Q11: Where is the Core War archive?
A11: Many documents such as the guidelines and the ICWS standards
along with previous tournament Redcode entries and complete Core War
systems are available via anonymous ftp from ftp.csua.berkeley.edu
(128.32.43.51) in the /pub/corewar directories.  Also, most of past
rec.games.corewar postings (including Redcode source listings) are
archived there.  Jon Blow (blojo@ftp.csua.berkeley.edu) is the archive
administrator. When uploading to /pub/corewar/incoming, ask Jon to move
your upload to the appropriate directory and announce it on the net.

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

This FAQ is automatically archived by news.answers.  See the header for
the current archive name and news.answers for how to get it.

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

Q12: Where can I find a Core War system for . . . ?
A12: Core War systems are available via anonymous ftp from
ftp.csua.berkeley.edu in the pub/corewar/systems directory. Currently, there are
UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available
there. It is a good idea to check pub/corewar/incoming for program updates
first.

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

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

Below is a not necessarily complete or up-to-date list of what's available
at soda:

        MADgic41.lzh    - corewar for the Amiga, v4.1
        MAD4041.lzh     - older version?
        MAD50B.lha      - corewar for the Amiga, beta version 5.0
        Redcoder-21.hqx - corewar for the Mac, supports ICWS'88 and '94
        core-11.hqx     - corewar for the Mac
        core-wars-simulator.hqx - same as core-11.hqx?
        corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but
                not ICWS'88 compatible
        koth31.tar.Z    - corewar for UNIX/X-windows. This program ran the
                          former KotH server at intel.com
        koth.shar.Z     - older version
        kothpc.zip      - port of older version of KotH to the PC
        deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC
        mars.tar.Z      - corewar for UNIX, likely not ICWS'88 compatible
        icons.zip       - corewar icons for MS-Windows
        macrored.zip    - a redcode macro-preprocessor (PC)
        c88v49.zip      - PC corewar, textmode display
        mars88.zip      - PC corewar, graphics mode display
        corwp302.zip    - PC corewar, textmode display, slowish
        mercury2.zip    - PC corewar written in assembly, fast!
        mtourn11.zip    - tournament scheduler for mercury (req. 4DOS)
        pmars06s.zip    - portable system, ICWS'88 and '94, runs on UNIX,
                          PC, Mac, Amiga. C source archive
        pmars06s.tar.Z  - same as above
        pmars062.zip    - PC executables with graphics display, req 386+
        macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2)
			     buggy, no display
	MacpMARS.10.cpt.hqx - port of v0.6 for the Mac, with display and 
			      debugger
	MacpMARS.10s.cpt.hqx - C source (MPW, ThinkC) for Mac frontend
        ApMARS03.lha    - pMARS executable for Amiga (port of version 0.3.1)
        wincor11.zip    - MS-Windows system, shareware ($15)

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

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

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

Q14: I do not have access to Usenet.  How do I post and receive news?
A14: To receive rec.games.corewar articles by email, join the COREWAR-L
list run on the Stormking.Com ListProcessor.  To join, send:

        SUB COREWAR-L FirstName LastName
to:
        LISTPROC@STORMKING.COM

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

Another server that allows you to post (but not receive) articles is
available. Email your post to rec-games-corewar@cs.utexas.edu and it will be
automatically posted for you.

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

Q15: When is the next tournament?
A15: The ICWS holds an annual tournament.  Traditionally, the deadline
for entering is the 15th of December.

The EBS usually holds a preliminary tournament around the 15th of November
and sends the top finishers on to the ICWS tournament.

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

----------------------------------------------------------------------
Q16: What is KotH?  How do I enter?
A16: King Of The Hill (KotH) is an ongoing Core War tournament
available to anyone with email.  You enter by submitting via email a Redcode
program with special comment lines.  You will receive a reply indicating how
well your program did against the current top twenty programs "on the hill".
Your program will play 100 battles against each of the 20 other programs
currently on the Hill. You receive 3 points for each win and 1 point for each
tie.  (The existing programs do not replay each other, but their previous
battles are recalled.) All scores are updated to reflect your battles and all
21 programs are ranked from high to low.  If you are number 21 you are pushed
off the Hill, if you are higher than 21 someone else is pushed off.

The original KotH was developed and run by William Shubert at Intel, and
discontinued after almost three years of service. Currently, KotHs based on
Bill's UNIX scripts but offering a wider variety of hills are are running at
two sites: "koth@stormking.com" is maintained by Scott J. Ellentuch
(tuc@stormking.com) and "pizza@ecst.csuchico.edu" by Thomas H. Davies
(sd@ecst.csuchico.edu). Both KotHs provide very similar services and are
therefore covered together. The principal difference is that "pizza" has a
much faster internet connection than "stormking".

Entry rules for King of the Hill Corewar:

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

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

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

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

   There are currently six separate hills you can select by starting your
   program with ;redcode, ;redcode-x, ;redcode-icws, ;redcode-b, ;redcode-94,
   or ;redcode-94x.  More information on these hills is listed below.

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

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

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

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

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

SAMPLE ENTRY:
;redcode
;name Dwarf
;author A. K. Dewdney
;strategy Throw DAT bombs around memory, hitting every 4th memory cell.
;strategy This program was presented in the first Corewar article.
bomb  DAT   #0
dwarf ADD   #4,    bomb
      MOV   bomb, @bomb
      JMP   dwarf
      END   dwarf          ; Programs start at the first line unless
                           ; an "END start" pseudo-op appears to indicate
                           ; the first logical instruction.  Also, nothing
                           ; after the END instruction will be assembled.

Here are the Specs for the various hills:

ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at
"stormking" and "pizza")
         coresize: 8000
   max. processes: 8000
         duration: after 80,000 cycles, a tie is declared.
max. entry length: 100
 minimum distance: 100
  instruction set: ICWS '88

ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws",
available at "stormking" only)
         coresize: 8192 instructions
   max. processes: 8000 per program
         duration: After 100,000 cycles, a tie is declared.
max. entry length: 300
 minimum distance: 300
  instruction set: ICWS '88

ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x",
available at "pizza" only)
         coresize: 4096
   max. processes: 32
         duration: after 65,536 cycles, a tie is declared.
max. entry length: 64
 minimum distance: 64
  instruction set: ICWS '88

ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at
"stormking" and "pizza")
         coresize: 8000
   max. processes: 8000
         duration: after 80,000 cycles, a tie is declared.
max. entry length: 100
 minimum distance: 100
  instruction set: ICWS '94 Draft

ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available
at "pizza" only)
         coresize: 8000
   max. processes: 8000
         duration: after 80,000 cycles, a tie is declared.
max. entry length: 100
 minimum distance: 100
  instruction set: ICWS '94 Draft

ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x",
available at "stormking" and "pizza")
         coresize: 55440
   max. processes: 10000
         duration: after 500,000 cycles, a tie is declared.
max. entry length: 200
 minimum distance: 200
  instruction set: ICWS '94 Draft

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

All hills run portable MARS (pMARS) version 0.6, a platform-independent
corewar system available at soda (see Q12).

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

        SEQ - Skip if EQual (synonym for CMP)
        SNE - Skip if Not Equal
        NOP - (No OPeration)

        *   - indirect using A-field as pointer
        {   - predecrement indirect using A-field
        }   - postincrement indirect using A-field

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

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

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

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

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

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

Q19: What does (expression or term of your choice) mean?
A19: Here is a selected glossary of terms.  If you have a definition and/or
term you wish to see here, please send it to me.

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

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

B-Scanners - Scanners which only recognize non-zero B-fields.
           example  add #10,scan
           scan     jmz example,10

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

CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents.
           example  add step,scan
           scan     cmp 10,30
                    jmp attack
                    jmp example
           step     dat #20,#20

Color - Property of bombs making them visible to scanners, causing them
   to attack useless locations, thus slowing them down.
           example  dat #100

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

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

DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core
   locations.
           example   . . .
                     . . .
                     djn example,<4000

Dwarf - the prototypical small bomber.

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

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

Imp - Program which only uses the MOV instruction.
           example  MOV 0, 1
       or
           example  MOV 0, 2
                    MOV 0, 2

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

Imp-Ring - A minimal Imp-Spiral.
            d        EQU (coresize+1)/3
            A        MOV 0,d   ; copy self to B
            B        MOV 0,d   ; copy self to C
            C        MOV 0,d   ; copy self to A+1

Imp-Spiral - An Imp-like program with two or more processes supporting
   each other.  A three-point spiral, with six processes running in this
   sequence:
            d        EQU (coresize+1)/3
            A        MOV 0,d   ; copy self to B
            B        MOV 0,d   ; copy self to C
            C        MOV 0,d   ; copy self to A+1
            A+1      MOV 0,d   ; copy self to B+1
            B+1      MOV 0,d   ; copy self to C+1
            C+1      MOV 0,d   ; copy self to A+2

Incendiary Bomb - A type of Stun bomb which creates a SPL 0 carpet.
           example   SPL 0, 8
                     MOV -1, <-1

Mirror - see reflection

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

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

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

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

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

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

Self-Splitting - Strategy of amplifying the number of processes executing
   a piece of code.
           example   SPL 0
           loop      ADD #10, example
                     MOV example, @example
                     JMP loop

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

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

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

Slaver - see Pit-Trapper.

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

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

Stun - A type of bomb which makes the opponent multiply useless processes,
   thus slowing it down.  Example is referred to as a spl-jmp bomb.
          example spl 0
                  jmp -1

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

Vampire - See Pit-Trapper.

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

Q20: Other questions?
A20: Just ask in the rec.games.corewar newsgroup or contact me (address
below). If you are shy, check out the Core War archives on soda first to
see if your question has been answered before (see Q11).

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

Additions/Corrections/etc. to this document are solicited.
The rec.games.corewar FAQ is maintained by:

Stefan Strack, PhD                          stst@vuse.vanderbilt.edu
Institute for Developmental Neuroscience    stst@idnsun.gpct.vanderbilt.edu
P.O. 152, Peabody College                   stracks@vuctrvax.bitnet
Vanderbilt University                       Voice: +615-343-0544
Nashville, TN 37203, USA                    FAX:   +615-343-0242


Subject: Re: spl.? question
Message-ID: <1995Mar20.132325.2197@rhodes>
From: graham@joshua.mathcs.rhodes.edu (Randy Graham)
Date: 20 Mar 95 13:23:24 -0500

Michael Constant (mconst@soda.CSUA.Berkeley.EDU) wrote:
: >: Yes, spl.b does split to its A-target rather than its B-target.  The reason
: >: for this, briefly, is that if spl.b split to its B-target than spl.f would
: >: have to split to its A-target *and* B-target, and this would make spl-bombs
: >: far too powerful.
: >
: >Seems to me that spl.f could be made to fall back to spl.a or spl.b
: >the same way djn.i is made to fall back to djn.f.

: It could, but that wouldn't really make too much sense.  Djn.i is treated
: as djn.f just because djn.i makes no sense -- it is impossible to decrement
: an instruction.  However, spl.f makes perfect sense, it's just too powerful
: if it is treated in the more intuitive fashion (i.e. split to both the A-
: and B-targets).
: -- 
Well, I can see what you are saying, but I don't agree it makes sense.
I understand spl to continue executing with the next instruction, and
add into the process queue the process at PC+(spl field).  Well, if
you do a spl.f 15, 10 this would add a process PC+(15,15).  Well,
obviously we can't add two dimensions to one.  I imagine that the view
of spl is more likely add (PC+15) and (PC+15) to the queue.  But that
isn't how spl is explained (at least the way I understand the draft).

Regardless, if the instruction is going to always use the a field,
shouldn't PMars at least compile it to spl.a instead of spl.b (when
encountering an instruction woithout a modifier)?  And
how does falling always to spl.a make more sense than falling to spl.a
when encountering a spl.f?  This isn't some significant problem, as I
was obviously able to fix my program by switching the a and b fields,
but I would like to understand what is happening and why certain
choices were made.

:             Michael Constant (mconst@soda.csua.berkeley.edu)

Randy


From: mreddy@comp.glamorgan.ac.uk (Mike Reddy)
Subject: Evolving CoreWar Warriors (was Pointers in pMARS)
Date: Mon, 20 Mar 1995 20:48:37 +0000
Message-ID: <mreddy-2003952048370001@mreddy.comp.glam.ac.uk>

Byron C. Ellis wrote concerning evolving CoreWar warriors:

> There's also a paper on soda.berkeley.edu called evolving warriors that 
> does nearly the same thing with generations of 1000 warriors.

Ah, but this one uses Cross-over. And weighted breeding to ensure a random
mix with predominantly successful warriors producing progeny. And I have
some tentative good news. My student has bred a warrior which managed to
beat most, if not all of the simple hand-coded warriors of the past (e.g.
imp, dwarf, etc) after only six generations of 100 distinct warriors.

The sucessful beast is only about eight instructions long, and seems to
copy a random memory location backwards throughout the core. Apparently,
this seems to foil Imp Gates, etc, though I haven't examined his results
in detail.

This might not sound like much, but he started with seeding warriors which
were generated completely at random. Many warriors lost every battle in
the first generation (as might be expected) but the trend was towards more
draws and less wins and losses as each generation progressed.

I'll keep you informed of future developments.

Yours Mike Reddy
--
P.S. I would have had a witty signature, but the Government put VAT on it!

Email: mreddy@comp.glamorgan.ac.uk OR mreddy@glamorgan.ac.uk
Web (coming soon!): http://sal9000.comp.glam.ac.uk/
Snail Mail: Mike Reddy, J228, Dept. of Computer Studies, University of
Glamorgan, Pontypridd, Mid Glamorgan. CF37 1DL Wales, UK
Tel: +44 (0)443 482 240 Fax: +44 (0)443 482 715

P.P.S. Glamorgan University: Top of the League! Applications up 57% this year!


Yours Mike Reddy
--
P.S. I would have had a witty signature, but the Government put VAT on it!

Email: mreddy@comp.glamorgan.ac.uk OR mreddy@glamorgan.ac.uk
Web (coming soon!): http://sal9000.comp.glam.ac.uk/
Snail Mail: Mike Reddy, J228, Dept. of Computer Studies, University of
Glamorgan, Pontypridd, Mid Glamorgan. CF37 1DL Wales, UK
Tel: +44 (0)443 482 240 Fax: +44 (0)443 482 715

P.P.S. Glamorgan University: Top of the League! Applications up 57% this year!


From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant)
Subject: Re: spl.? question
Date: 21 Mar 1995 07:06:12 GMT
Message-ID: <3kltt4$e8b@agate.berkeley.edu>

Randy Graham <graham@joshua.mathcs.rhodes.edu> wrote:
>Michael Constant (mconst@soda.CSUA.Berkeley.EDU) wrote:
>: It could, but that wouldn't really make too much sense.  Djn.i is treated
>: as djn.f just because djn.i makes no sense -- it is impossible to decrement
>: an instruction.  However, spl.f makes perfect sense, it's just too powerful
>: if it is treated in the more intuitive fashion (i.e. split to both the A-
>: and B-targets).
>
>Well, I can see what you are saying, but I don't agree it makes sense.
>I understand spl to continue executing with the next instruction, and
>add into the process queue the process at PC+(spl field).  Well, if
>you do a spl.f 15, 10 this would add a process PC+(15,15).  Well,
>obviously we can't add two dimensions to one.  I imagine that the view
>of spl is more likely add (PC+15) and (PC+15) to the queue.

The problem is exactly with what you state: if spl can add two processes
to the process queue then it becomes too powerful.

>Regardless, if the instruction is going to always use the a field,
>shouldn't PMars at least compile it to spl.a instead of spl.b (when
>encountering an instruction woithout a modifier)?

Ah, there's the problem.  Spl does *not* treat any modifier as a .a
modifier -- it ignores its modifier completely.  There's a difference.
The description of spl goes something like this: "the spl opcode adds
its A-target to the tail of the process queue".  For comparison, the
description of jmz goes something like this: "the jmz opcode tests its
B-value; if it's zero, it jumps to its A-target, else does nothing".
Does this help explain why modifiers make no difference with spl?  (If
it doesn't, please keep asking questions -- the more people understand
exactly why redcode works the way it does, the better.)
-- 
            Michael Constant (mconst@soda.csua.berkeley.edu)


Subject: QCmpHunt
Message-ID: <1995Mar21.175657.2218@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 21 Mar 95 17:56:56 -0500

OK, finally I have had time to comment the QScan version of Hunter
enough that it might be of use to someone.  So, below is latest
version, slightly updated from the last I had on the 94 hill.  I never
made it above 18th, and only lasted through 5 challenges before
falling off (and 3 I survived were versions of P.Kline's Paper
Dreaming).  

After this has been here a couple of days I will put up my 55440
version of QCmpHunter.  He did significantly better on the big hill
(10th I believe).  

One other thing.  Some of you will probably notice Hunter looks
suspiciously like S.Strack's Rave.  I came across this code honestly
though.  I took a jmz hunter and converted it to a cmp hunter and
after playing around found this to be the most succesful.  Apologies
for the similarities, but this seems to be about the best I can
manage, and I imagine Rave came about the same way (tweak until it
gets a little better).

Randy
---------------------

;redcode-94
;Name QComp-Hunter v2.2
;Author Randy W. Graham
;assert 1
;I always assert 1.  I make assumptions when programming, and it
;is my own problem if my assumptions fail.

;strategy cmp-scanning carpet bomber based on Rave.
;strategy v1.0 Added a small step QScan to hunter - only scan part of core
;strategy v2.0 Finally got right starting point after moving.
;strategy v2.1 Fixed bug that repeated a qscan triple & eliminated one line
;strategy v2.2 two lines longer but - made qscan bomb more efficiently
;strategy   and shortened bombing run on hunter

OPT equ 42	;mod 2
LEN equ (fini-adder+1)   ;adjusted in v2.1 because we moved our code
     ;around in the decoy

DIFF equ 13    ;difference between sites in Hunter's cmp line
BOMBS equ DIFF+2	;how many bombs to lay
MOVETO equ 1176	;where we move to
MOVEADJ equ (MOVETO/OPT*OPT)   ;adjust to allow a full run

OFF equ -381	;djn stream offset - not correct for longest run, but
	;gives best score

QSTART equ -400  ;where to start QScan
QDIFF equ 70     ;how far apart to scan
QBOMBS equ 12    ;how many bombs to lay on QScan target

begin
qscana for 6      ;6 triples scan 4 sites each
         sne.i  QSTART-(QDIFF*(qscana-1)*4), QSTART-(QDIFF*(qscana-1)*4)-QDIFF
         seq.i  QSTART-(QDIFF*(qscana-1)*4)-QDIFF*2, QSTART-(QDIFF*(qscana-1)*4)-QDIFF*3
         mov.ab #-2-found, found	;point to above sne line
rof
         jmn.b  found+1, found    ;if we found something, start attack


qscanb for 7      ;7 triples scan 4 sites each
         sne.i  QSTART-(QDIFF*(qscanb+5)*4), QSTART-(QDIFF*(qscanb+5)*4)-QDIFF
         seq.i  QSTART-(QDIFF*(qscanb+5)*4)-QDIFF*2, QSTART-(QDIFF*(qscanb+5)*4)-QDIFF*3
         mov.ab #-2-found, found	;point to above sne line
rof
         jmn.b  found+1, found    ;if we found something, start attack

qscanc for 7      ;7 triples scan 4 sites each - grand total of 80
         sne.i  QSTART-(QDIFF*(qscanc+12)*4), QSTART-(QDIFF*(qscanc+12)*4)-QDIFF
         seq.i  QSTART-(QDIFF*(qscanc+12)*4)-QDIFF*2, QSTART-(QDIFF*(qscanc+12)*4)-QDIFF*3
         mov.ab #-2-found, found	;point to above sne line
rof

found    jmz.b  moveme,   #0      ;if we don't have anyone, move me
found2   mov.ba found,    found	  ;otherwise set up to attack
         mov.i  found,    found2  ;make found2 point to seq line

         add.f  *found,   found   ;adjust found to point to scanned location
         add.f  *found2,  found2  ;adjust found2 to scanned location
         add.a  #1,       found2  ;we will move this later, so adjust it

         sne.i  *found,   @found  ;if found points to difference, use it
         mov.i  found2,   found   ;otherwise set up to bomb found2
         jmn.f  attack,   *found  ;if a-field isn't empty, attack it
         mov.ba found,    found   ;otherwise 

attack   mov.i  spltrap,  }found  ;bomb a field
         djn.b  attack,   #QBOMBS

moveme   mov.i  >traps,   >moveto  ;move me away now

for 6                              ;simply rolled move into macro
         mov.i  >traps,   >moveto
rof

moveto   spl.a  MOVETO+1, #MOVETO  ;we haven't finished copying, but
    ;we can start scanning anyway.  We will finish copying in time
    ;to bomb or to add to our cmp line

for 4
         mov.i  >traps,   >moveto
rof
         mov.i  datadd,   >moveto
         mov.i  traps,    moveto
datadd   dat.f  >-1-OPT,  <-1-OPT+4	;set up imp gate

adder    add.f  spltrap,  cmper	;adjust our compare sites

cmper    cmp.i  adder-DIFF-OPT-MOVEADJ-(OPT*2), adder-OPT-MOVEADJ-(OPT*2)
;cmper    cmp.i  adder-DIFF-OPT, adder-OPT

     ;see if they differ - need to skip past decoy.  This does
     ;leave some unscanned first time through, but otherwise I
     ;waste too much time bombing my own decoy first time through

         slt.ab #LEN+BOMBS, cmper
     ;above cmp found a difference.  We must make sure that
     ;my code isn't the difference.

         djn.i  adder,    <OFF	;lay djn stream, jump to add line
     ;if the cmp found nothing, or if the slt sees we are about to
     ;bomb ourself, we hit this djn line.  It decrements to a and b
     ;fields of whatever OFF points to after being decremented.
     ;IFF the field contains 1 in a and b, we would fall through to
     ;the bomb routine, otherwise we loop back to our adder.

setup    mov.ab #BOMBS,   traps	;get bombs ready

         mov.i  spltrap,  }cmper	;start carpetting

traps    djn.b  -1,       #adder	;keep bombing for a while
     ;use b-field of traps above in MOVEME routine

         sub.a  #BOMBS,   cmper	;reset cmp pointer

         jmz.i  adder,    adder-1	;if we haven't bombed ourself, scan more

spltrap  spl.a  #0-OPT,   >0-OPT	;trap, and stay alive line.
     ;by adding the f value in adder above, we make our way backwards
     ;scanning memory 13 locations apart

sweep    mov.i  1,        <traps	;lay dats down til we bomb here
     ;we copy this throughout memory to kill of spl-trapped opponents

fini     end    begin



Subject: Re: spl.? question
Message-ID: <1995Mar21.182452.2220@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 21 Mar 95 18:24:52 -0500

Michael Constant (mconst@soda.CSUA.Berkeley.EDU) wrote:
: Randy Graham <graham@joshua.mathcs.rhodes.edu> wrote:
: >Michael Constant (mconst@soda.CSUA.Berkeley.EDU) wrote:
[Lots deleted]
: (If
: it doesn't, please keep asking questions -- the more people understand
: exactly why redcode works the way it does, the better.)
While composing a rather lengthy response to this, I came across what
I feel is the real problem.  I do understand what you have said, and
still feel that at the very least PMars should compile an unmodified
spl to spl.a so at least in learning '94 others can see what is
happening if they don't read the part of the draft dealing with stuff
they THINK they already know (which is what I did with spl and jmp).

In any case, I THOUGHT I had come up with a declaration of spl the
allowed .a or .b but naturally eliminated .f, .i, .ab, etc.  Well, I
believe my ideas were correct, but expressing them in the language
used to define the standard turned out to be difficult (I couldn't do
it in 1/2 an hour).  I will still work on it, but for the meantime, I
think we can stop this thread.  I do understand, and I will work on a
definition which satisfies me to see if it is workable.

: -- 
:             Michael Constant (mconst@soda.csua.berkeley.edu)

Thanks and then some for taking the time to explain to me,

Randy


From: sieben@imap1.asu.edu
Subject: Re: Evolving CoreWar Warriors (was Pointers in pMARS)
Date: 22 Mar 1995 18:15:47 GMT
Message-ID: <3kppgj$i07@news.asu.edu>

: beat most, if not all of the simple hand-coded warriors of the past (e.g.
: imp, dwarf, etc) after only six generations of 100 distinct warriors.

Could you give us the exact list of these simple warriors. 	
Nandor.


From: tusk@daimi.aau.dk (Martin M|ller Pedersen)
Subject: Re: PCrobots
Date: 23 Mar 1995 15:27:21 GMT
Message-ID: <3ks40p$alb@belfort.daimi.aau.dk>

Thus spake brekerg@cuug.ab.ca (Breker):

>Anyone using the 1992 program... PcRobots?

>Can anyone direct me to where I can get other ppls robots to try??

>Thanks

I once had the 1992 probots but I lost it.
Where can I get a copy ?

/thanks

tusk@daimi.aau.dk


From: stanne@nbnet.nb.ca (John E. Montgomery)
Subject: King of the hill warning
Date: 23 Mar 1995 16:13:17 GMT
Message-ID: <stanne.25.0@nbnet.nb.ca>

After my first attempt at the 'koth' hill, I got
a warning  
General Warning
[22] Missing ";assert'
Could some one explain this to me

JEM 


From: jgordon@grin.io.org (John Gordon MacPherson)
Subject: Compiling pmars under Linux
Date: 23 Mar 1995 16:14:09 GMT
Message-ID: <3ks6oh$lt7@ionews.io.org>

	I'm afraid I'm quite ignorant when it comes to programing.  Could
someone please let me know what modifications have to be made to the makefile
in order to compile pmars06s under Linux?  Perhaps you could email me the 
Makefile.  My address is: jgordon@io.org.  Thankyou.


From: mreddy@comp.glamorgan.ac.uk (Mike Reddy)
Subject: RE. Pointers in pMARS
Date: Thu, 23 Mar 1995 17:34:36 +0000
Message-ID: <mreddy-2303951734360001@mreddy.comp.glam.ac.uk>


> Mike writes:
> >When I run the assemble procedure from ASM.C, a number of pointers are
> >allocated.  Sometimes, some of these pointers are not freed.  This means
> >that up to 4 or 5 blocks of memory, 528 bytes in length are lost every
> >time the procedure is called.

> We explicity kept track of every single thing that was malloc'ed
> so that they could be freed.  Strange, I thought it was deallocated after
> the assembly phase.  Maybe not, I don't remember.
>
> I remember a long time ago we made sure that there were no memory leaks.
> Something might have slipped into the newer pMARS versions but I doubt it.
>
>

It was suggested to me that I should use the functions NewPtr and Dispose
instead of malloc and free, and this has helped a bit.  The pointers to 
500+ bytes of memory have become pointers to blocks of 9 or 10 bytes, and
some have been freed completely.  

There are some compiler problems with allocation, but I have been informed
that they are fixed with the new release (which I received last week).

I can use a program to display the memory usage, and there appears to be a
block of pointers to small memory units that appear after assembling. 
After the warriors are freed, there are some gaps in this allocation where
memory has been freed, but the bulk of allocated memory remains allocated.

Could the use of static variables be affecting this?

> >A similar problem occured with simulator1() which was loosing blocks of
> >128K, but this was fixed by converting from pointers to arrays (by
> >disabling the #define __MAC__ directive before compiling the source
> >code).  This solution is not really applicable because pointers are not
> >used in the same way.
>
> Now this is really strange.  Pointers are used only when
> __MAC__ or __AMIGA__ or __MSDOS__ is defined.  There are exactly two
> mallocs, one for memory and one for taskQueue.
>
> at the end sim.c there is

> #if defined(__MAC__) || defined(__AMIGA__)
>   /* DOS taskQueue may not be free'd because of segment wrap-around */
>   free(memory);
>   free(taskQueue);
>   alloc_p = 0;
> #endif
>
> which should have freed the memory that was allocated.

I don't know what the problem was exactly, but I have shuffled some things
around in the procedure which calls simulator1, and the problem has fixed
itself.  The calling of the procedure is not in pmars.c as in the
original.

> Are you using the original pmars06 distribution or the one modified for
> the Mac (MacpMARS I think) which has the interface in it?
>
> I believe you're the first person I've heard of to port pMARS on a
> PowerMac.  Right now my gut feeling is it's a compiler problem.
>
> Albert Ma               ama@mit.edu

I am using the original distribution, since the MacpMARS is not written
for my compiler, but after examining the memory usage of MacpMARS, it
seems that it does not suffer from the same problem.  Maybe this does
point to the compiler.

Simon.

smejones@glam.ac.uk


Yours Mike Reddy
--
P.S. I would have had a witty signature, but the Government put VAT on it!

Email: mreddy@comp.glamorgan.ac.uk OR mreddy@glamorgan.ac.uk
Web (coming soon!): http://sal9000.comp.glam.ac.uk/
Snail Mail: Mike Reddy, J228, Dept. of Computer Studies, University of
Glamorgan, Pontypridd, Mid Glamorgan. CF37 1DL Wales, UK
Tel: +44 (0)443 482 240 Fax: +44 (0)443 482 715

P.P.S. Glamorgan University: Top of the League! Applications up 57% this year!


From: gga@info.fundp.ac.be (Geoffroy Gailly)
Subject: C++Robots
Date: Fri, 24 Mar 1995 12:58:17
Message-ID: <gga.39.000CF914@info.fundp.ac.be>

Hi !

Does anyone know  if there is a PC version of C++Robots (by Richard Rognlie on 
PbmServ) ? Or anything similar that would help me working out my robots.

Please let me know in the news or use my mail adress

Thanks in advance

Geo

   Y
  / \
  o o         ___________________________________________
  \ /         |Geoffroy "Blue Lizard" Gailly            |
|| | ||       |Student in Computer Sciences             |
\\/ \//       |                                         |
 \| |/        |adress : rue du Maitrank, 8, B-6700 Arlon|
||| |||  /    |phone : +32 63 22 40 06                  |
\\| |// //    |e-mail : gga@info.fundp.ac.be            |
 \   / //     |_________________________________________|
  \ /_//
   \__/



From: rrognlie@netcom.com (Richard Rognlie)
Subject: Re: C++Robots
Message-ID: <rrognlieD60J16.3x9@netcom.com>
Date: Sat, 25 Mar 1995 20:17:30 GMT

Geoffroy Gailly (gga@info.fundp.ac.be) wrote:
: Hi !

: Does anyone know  if there is a PC version of C++Robots (by Richard Rognlie on 
: PbmServ) ? Or anything similar that would help me working out my robots.

: Please let me know in the news or use my mail adress

: Thanks in advance

: Geo

To the best of *my* knowledge, C++Robots will only work on a Sun SPARC.  
C-ROBOTS will work on a PC, but is not compatible with C++Robots.

You can write C-Robots robots, and port them to C++Robots robots easily, but
not the other way around...

To port a C-Robot to a C++Robot, do the following:

    Convert to ANSI C (if not already done)

    Make sure that any functions invoked are fully prototyped or implemented
    prior to the first invocation.

    Make any global variables "static"

    Multiply range numbers by 10.

Richard

-- 
  /\/\/\  | Richard Rognlie / Sr. Computer Analyst / PRC Inc. / McLean, VA
 /  \ \ \ | E-Mail: rrognlie@netcom.com *or* rognlie_richard@prc.com
 \  / / / | Phone:  (Home) (703) 361-4764   (Office) (703) 556-2458
  \/\/\/  |                                 (Fax)    (703) 556-1174


Subject: Good paper products
Message-ID: <1995Mar26.175513.2271@rhodes>
From: graham@harlie.mathcs.rhodes.edu (Randy Graham)
Date: 26 Mar 95 17:55:13 -0500

I have, of course, been working on getting on to the 94-hill.  I have
gotten my third warrior on, but as usual am near the bottom.  I do
well enough in testing against the warriors I have, but always fall
short on the 94-hill.  I do well enough against imps and scanners, and
I feel I do OK against stones considering I am a scanner.  However, I
have significant trouble with paper.  As just a scanner, I do OK
against paper.  Now, I have added a QVamp, which significantly
improved my scores vs. imps, but now I have trouble with paper (I
believe only against silk, but I don't know if that's all that is out
there or not).  Any way, I was wondering if someone could give me a
good paper product to test against.  I have flashpaper, gammapaper,
and Silk warrior 1.3.  I do great against silk 1.3 and FlashPaper, and
OK against gamma.  Could someone send me a tougher paper to test
against so I can tell how I am going to do in long runs against paper.

Randy


From: Robert@buchanan.demon.co.uk (Robert Macrae)
Subject: Re: Good paper products
Date: Tue, 28 Mar 1995 09:48:19 +0000
Message-ID: <796384099snz@buchanan.demon.co.uk>

In article <1995Mar26.175513.2271@rhodes>
	   graham@harlie.mathcs.rhodes.edu "Randy Graham" writes:

> there or not).  Any way, I was wondering if someone could give me a
> good paper product to test against.  I have flashpaper, gammapaper,
> and Silk warrior 1.3.  I do great against silk 1.3 and FlashPaper, and
> OK against gamma.  Could someone send me a tougher paper to test
> against so I can tell how I am going to do in long runs against paper.
 
Here's my version...

 

;redcode-94
;name Vanilla 1.1
;author Robert Macrae
;strategy  6-word Paper with fast launcher. 
;assert CORESIZE == 8000

	spl     1
	mov     -1,       0
	spl     1                       ; Get 6 processes

launch  spl     2340,     0             ; Launch multiple copies
	mov     >launch,  }launch
	mov     bomb,     {600          ; Throw in a bomb for luck
	mov     >launch,  }launch       ; Complete launch 

paper   spl     1910,     0             ; Start of paper proper
	mov     >paper,   }paper
	mov     bomb,     {bomb         ; (Forget why) 
	mov.f   <paper,   {800          ; Lazy bomb + redecrement paper
	jmz     @paper+1, @paper+1      ; Repeat if paper && paper+1 OK

bomb    dat     >paper,   <2667
	dat     >0,       <2667         ; Ballast, so I don't waste time
	dat     >0,       <2667         ; launching colourless space.


I don't think this was ever the best, but its simple. I havn't seen code for
Silk itself, but I think the key element is the use of the SPL, MOV >} pair
to achieve very fast splitting at the start. The advantage is that the second
copy is executing only 1 step behind the first ie SPL when the first is doing
the MOV, MOVing when the first is bombing -- and by now the third copy is 
splitting! This makes the paper vampire resistant as it can split almost as 
fast as traps.

There is a downside, at least in my version. Because you have six processes
executing every instruction, it is very expensive to change the split 
destination, so papers tend to end up in strips close together, and 
eventually overlapping which wastes cycles. The launch stage is an attempt to
overcome this because, silk-like, it splits off 9 copies before the first
paper has completed one cycle. The constants 2340 and 1910 came from a quick
check with MOPT, looking for the best step size (1910) when lots of bombing
runs where repeated at equal offsets (2340). Actually, for speed I used an 
800 coresize and came up with 191 and 234 as the optimal pair, so this could 
be improved. Constants 600 and 800 are content free.

The bomb during launch helps by creating dead targets for scanners, as well
as attacking. The choice of bomb is vaguely anti-impish (though I don't
think this achieves much. Using MOV bomb, { will pick up any pointers. This
works well against vamp-based quickscanners :-) such as Midge, recently 
deceased :-(. 

This paper was meant to be the basis for a more sophisticated, self-checking
variant but I couldn't get the sophistication to pay. In the end I got 
frustrated by the number of failed "Major improvements", which is why there 
is so much unfinished. 

-- 
Robert Macrae


From: suk@usceast.cs.scarolina.edu (Peter Kwangjun Suk)
Subject: Re: Evolving Warriors in CoreWar
Date: 28 Mar 1995 11:06:51 -0500
Message-ID: <3l9c6r$1cn@senna.cs.scarolina.edu>

mreddy@comp.glamorgan.ac.uk (Mike Reddy) writes:

>As promised, here are the three RedGen warriors that were produced by
>evolution after six generations. I did them a disservice, placing them
>21st etc, when in fact they came 9th, 12th and 13th. The sources and
>tournament results are shown below. I've not yet analysed their contents
>but I would not be surprised if they contain code that was never used,
>rather like genetic code that sits there doing nothing.

Mitchell Quinn, an undergraduate in our department, has already
undertaken a project like this some time ago.  He let the thing run
for several months, and came up with warriors that could best the most
recent competition winners something like 70%-80% of the time.

[I'll let the rest of you figure out to contact him.  I don't know
if he's still interested in this stuff.]



From: mreddy@comp.glamorgan.ac.uk (Mike Reddy)
Subject: Re: Evolving CoreWar Warriors (was Pointers in pMARS)
Date: Tue, 28 Mar 1995 11:17:42 +0000
Message-ID: <mreddy-2803951117420001@mreddy.comp.glam.ac.uk>

In article <3kppgj$i07@news.asu.edu>, sieben@imap1.asu.edu wrote:

> : beat most, if not all of the simple hand-coded warriors of the past (e.g.
> : imp, dwarf, etc) after only six generations of 100 distinct warriors.
>
> Could you give us the exact list of these simple warriors.
> Nandor.

I will, once I get it from my student today. From memory, he ran three of
the best from the sixth generaition of his first run against the entrants
for the 1987 competition. The positions reached were 21, 23 and 24th with
Mice being 22nd (we were quite chuffed that one of our artificial warriors
beat Mice).

Again from memory, the behaviour of two were effectively that of a
'reverse' Imp (going backwards throught the Core), with one transforming
into a Mice-like splitter. This behaviour was allowed because most of its
competitors were unable to find it before it had written to the whole of
the core; the splitting started when it found its own tail. The third
warrior bombed in both directions at once and was the most successful (I
believe).

Now, the current version of RedGen (our 'fast-breeder') is less than
optimal, in that it does not yet allow the continuation of a set of
existing warriors. And the interface, file and memory handling on the
PowerPC need looking at. It may be we had a lucky first batch, so
extensive evaluation of 'winning strategies' will need to be performed.
However, I believe the platform (which is a thrid year project!) will be
useful for experimenting with the production of artificial warriors, once
the environmental and population modelling aspects are polished up.

Once it is running 'bug free' (if ever? Beware of compilers that have
errors - you never know if it is your fault when something does not work
correctly!), we even hope to put in some hand-coded warriors as seeding
generations to see if more than garbbage comes out. Naturally, this is a
far more complex starting point than randomly seeded code, as mixing two
very specialised programs might produce completely infeasible code each
time.

I will post the source for the three 'best yet' warriors when I get them
off my student.

Yours Mike Reddy
--
P.S. I would have had a witty signature, but the Government put VAT on it!

Email: mreddy@comp.glamorgan.ac.uk OR mreddy@glamorgan.ac.uk
Web (coming soon!): http://sal9000.comp.glam.ac.uk/
Snail Mail: Mike Reddy, J228, Dept. of Computer Studies, University of
Glamorgan, Pontypridd, Mid Glamorgan. CF37 1DL Wales, UK
Tel: +44 (0)443 482 240 Fax: +44 (0)443 482 715

P.P.S. Glamorgan University: Top of the League! Applications up 63% this year!


Yours Mike Reddy
--
P.S. I would have had a witty signature, but the Government put VAT on it!

Email: mreddy@comp.glamorgan.ac.uk OR mreddy@glamorgan.ac.uk
Web (coming soon!): http://sal9000.comp.glam.ac.uk/
Snail Mail: Mike Reddy, J228, Dept. of Computer Studies, University of
Glamorgan, Pontypridd, Mid Glamorgan. CF37 1DL Wales, UK
Tel: +44 (0)443 482 240 Fax: +44 (0)443 482 715

P.P.S. Glamorgan University: Top of the League! Applications up 57% this year!


From: mreddy@comp.glamorgan.ac.uk (Mike Reddy)
Subject: Evolving Warriors in CoreWar
Date: Tue, 28 Mar 1995 14:38:55 +0000
Message-ID: <mreddy-2803951438550001@mreddy.comp.glam.ac.uk>

As promised, here are the three RedGen warriors that were produced by
evolution after six generations. I did them a disservice, placing them
21st etc, when in fact they came 9th, 12th and 13th. The sources and
tournament results are shown below. I've not yet analysed their contents
but I would not be surprised if they contain code that was never used,
rather like genetic code that sits there doing nothing.

Source Code for dawG06al (placed 9th)
--------------------------------------

;name     dawG06al
;author   dawG05co and dawG05dn
;assert MAXLENGTH >= 11
SPL    #   -36, #    -4
MOV    <   -18, <   -23
SLT    >    50, #   -29
ADD    @   -24, $     0
CMP    $   -35, @    48
JMP    <    37, #   -20
MOV    $   -41, $    -4
MOV    <   -18, <   -23
SPL    @    44, @    47
MUL    #   -42, #   -10
DIV    $   -32, #    17

Source Code for dawG06cl (placed 12th)
--------------------------------------

;name     dawG06cl
;author   dawG05bt and dawG05az
;assert MAXLENGTH >= 8
SPL    #   -36, #    -4
MOV    <   -18, <   -23
SLT    >    50, #   -29
ADD    @     1, #   -17
DAT    @   -35, <   -25
MOV    >    36, @    16
MOV    >   -18, <   -23
SLT    >    10, #    13

Source Code for dawG06cg (placed 13th)
--------------------------------------

;name     dawG06cg
;author   dawG05cu and dawG05db
;assert MAXLENGTH >= 5
SPL    #   -27, <     0
SLT    #    50, >   -29
ADD    @   -36, $    -4
MOV    <   -18, <    -1
MOV    <    22, >    44


Tournament Results for RedGen Warriors 'v' 1987 hand-coded warriors
-------------------------------------------------------------------
(Generated using RedCoder 2.1)


    W / L / T  Name                             Author               Score
---------------------------------------------------------------------------
 1  73/ 14/ 11 :   W2                           Unknown                79
 2  58/ 17/ 23 PIPER                            Unknown                68
 3  58/ 23/ 17 KISS (Ultima Ratio Regum)        Unknown                66
 4  58/ 23/ 17 cancer                           Thomas Gettys          66
 5  47/  2/ 50 PINUP                            Unknown                65
 6  52/ 23/ 23 :  DRACULA.1                     Unknown                62
 7  47/ 11/ 41 :  Plague                        Unknown                62
 8  50/ 23/ 26 :  TRAPPER.1                     Unknown                60

 9  50/ 23/ 26 dawG06al                         dawG05co and dawG05d   60
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

10  41/  8/ 50 MICE                             Unknown                59
11  41/ 20/ 38 : DWOMP                          Unknown                55

12  47/ 32/ 20 dawG06cg                         dawG05cu and dawG05d   55
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

13  41/ 29/ 29 dawG06cl                         dawG05bt and dawG05a   52
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

14  35/ 32/ 32 :  ZAMZOW.1                      Unknown                47
15  29/ 23/ 47 :  VAMPSPRD.1                    Unknown                46
16  14/ 17/ 67 jumper                           Unknown                38
17  14/ 20/ 64 :  PHAGE.1                       Unknown                37
18   2/  2/ 94 KIRIN                            Unknown                35
19  14/ 29/ 55 :  MOUSETRP.1                    Unknown                34
20   5/ 11/ 82 :  PMJUMP.1                      Unknown                34
21  11/ 23/ 64 Dr. Frog                         Unknown                34
22   8/ 20/ 70 :  CHANG1.1                      Unknown                33
23   5/ 17/ 76 Imp                              Unknown                32
24   8/ 23/ 67 IMPS                             Unknown                32
25   2/ 14/ 82 PARASITE6                        Unknown                31
26   2/ 14/ 82 :  KWC72C                        Unknown                31
27   8/ 26/ 64 :  OGRE.1                        Unknown                31
28   5/ 20/ 73 FAIRY1                           Unknown                31
29   5/ 23/ 70 E-CALL                           Unknown                30
30  17/ 52/ 29 :  FERRET                        Unknown                28
31   8/ 35/ 55 NULL                             Unknown                28
32   5/ 32/ 61 JR-26-8192                       Unknown                27
33  20/ 64/ 14 :  SCHINDLR.1                    Unknown                26
34   5/ 41/ 52 cleaner                          Unknown                24
35   0/100/  0 Dwarf                            Unknown                 0

Yours Mike Reddy
--
P.S. I would have had a witty signature, but the Government put VAT on it!

Email: mreddy@comp.glamorgan.ac.uk OR mreddy@glamorgan.ac.uk
Web (coming soon!): http://sal9000.comp.glam.ac.uk/
Snail Mail: Mike Reddy, J228, Dept. of Computer Studies, University of
Glamorgan, Pontypridd, Mid Glamorgan. CF37 1DL Wales, UK
Tel: +44 (0)443 482 240 Fax: +44 (0)443 482 715

P.P.S. Glamorgan University: Top of the League! Applications up 63% this year!


Yours Mike Reddy
--
P.S. I would have had a witty signature, but the Government put VAT on it!

Email: mreddy@comp.glamorgan.ac.uk OR mreddy@glamorgan.ac.uk
Web (coming soon!): http://sal9000.comp.glam.ac.uk/
Snail Mail: Mike Reddy, J228, Dept. of Computer Studies, University of
Glamorgan, Pontypridd, Mid Glamorgan. CF37 1DL Wales, UK
Tel: +44 (0)443 482 240 Fax: +44 (0)443 482 715

P.P.S. Glamorgan University: Top of the League! Applications up 57% this year!


From: coa32@cc.keele.ac.uk (W. Zhao)
Subject: test
Date: 28 Mar 1995 16:38:32 GMT
Message-ID: <3l9e28$sj6@gabriel.keele.ac.uk>

this is just a test.



From: ting@teloquent.com (T. Hsu)
Subject: Re: Good paper products
Date: 1995/03/29
Message-ID: <199503291924.OAA07777@kei.teloquent.com>#1/1
newsgroups: rec.games.corewar

Here's my little addition to the field of decent papers.  Ryooki is yet
another silk-like paper, although I had come up with it independantly about
the same time that J.Pohjalainen seemed to (well, almost -- the boot code in
S.Morrell's BlueFunk warrior was the inspiration I used for the now common
place split before copying code).

Trying to keep true to form, Ryooki is a straight forward paper with no
decoy code (just filler to hid her true size) and a simple boot sequence.

ting@teloquent.com

;redcode-94
;name     Ryooki
;kill     Ryooki
;author   T.Hsu
;strategy Just a simple paper
;assert   CORESIZE == 8000 && MAXLENGTH >= 100 && VERSION >= 60
;macro
;-----------------------------------------------------------------------------
;  1.0  Just an imp killing paper.
;  1.1  Use nop and jmz.f in the paper.
;  1.2  Use "mov 0,}0" instead of nop.  Use "spl @nxt" instead of "spl nxt".
;  1.3  Larger due to anti-vampire code.  Use labels instead of numbers.
;  1.4  "nop >0,0" is better than both "mov 0,}0" and "nop 0,}0".
;  1.5  Better constants
;  1.6  Split before copying, shorter

            org     boot_paper

nxt_paper   equ     -3024 ; -3376,-3365

boot_paper  spl     1 ,>4000
            mov.i   -1,#0
            mov.i   -1,#0

paper       spl     @paper,<nxt_paper   ; A-fld is src, B-fld is dest
copy        mov.i   }paper,>paper
            mov.i   bomb  ,>paper       ; anti-imp
            mov.i   bomb  ,}800         ; anti-vampire
            jmn.f   @copy ,{paper
bomb        dat     <2667 ,<2667*2

cnt         for     91
            dat     0,0
            rof



From: pk6811s@acad.drake.edu
Subject: Re: Good paper products
Date: 1995/03/29
Message-ID: <1995Mar29.092014@acad.drake.edu>#1/1
references: <1995Mar26.175513.2271@rhodes> <796384099snz@buchanan.demon.co.uk>
newsgroups: rec.games.corewar

> 	   graham@harlie.mathcs.rhodes.edu "Randy Graham" writes:
> 
>> there or not).  Any way, I was wondering if someone could give me a
>> good paper product to test against.  I have flashpaper, gammapaper,
>> and Silk warrior 1.3.  I do great against silk 1.3 and FlashPaper, and
>> OK against gamma.  Could someone send me a tougher paper to test
>> against so I can tell how I am going to do in long runs against paper.
>  

Paper Dreaming is a Silk-based replicator in which I experimented with
several 'enhancements'.  First was to use a starting copy distance which
is a high-mod number, in this case mod-160.  Mod-160 means that in the
50th generation Paper Dreaming starts overwriting older copies of itself
with the idea of restoring spl-bombed code to activity.  Unfortunately
you rarely get 50 generations against spl-carpet bombing scanners :-(

Second enhancement was to spl back to start immediately after the mov
statement, to keep the replication activity at as high a level as possible.
Bombing instructions follow that spl and are left to die upon completion.

Third enhancement was to use a large number of processes - 16.  This
means that the copied code is largely dat's, which reduces the number
of ties that occur when the copying code overwrites the opponent's
active instruction.

Fourth enhancement was to take advantage of knowing where and when the
offspring is executing, which allows an add/mov combination similar
to stones.  Step-bombing is much deadlier against scanners than 
incremental or decremental so it picks up a few quick wins.

Paul Kline
pk6811s@acad.drake.edu

;redcode-94 quiet
;name Paper Dreaming
;kill Paper Dreaming
;author P.Kline
;strategy paper experiments
;macro

len     equ 16
incr    equ 4320                ; high-mod separation
dec1    equ 5334
dec2    equ 2667
step    equ 13
     for 10
        dat   #1,1              ; decoy to tie Agony up during startup
        dat   1,#1
     rof
     for 45
        dat   0,0
     rof
start   spl 1,>100
        spl 1,>200
        spl 1,>300
        spl 1,>400              ; create 16 processes
        mov   <1,{1
        spl   s1+3040-320+len,s1+len
        
s1      spl   incr,0
sd      mov   >s1,}s1
        spl   s1,<s1
        mov   sc,   >s1-(2*incr)-(15*step)-14       ; here is where we bomb
        add   #step, s1-(2*incr)-(15*step)-14+incr  ; increment son's bombing
sp      mov   sb,>s1-(2*incr)-dec2                  ; more bombing
sp      dat   >s1-(2*incr)-dec2+incr,>s1-(2*incr)-dec2+incr ; triple-incr above
sb      dat   <dec1,<dec2
        dat   0,0
        dat   0,0               ; 3-spacer helps against Taking Names
        dat   0,0
sc      dat   1,1               ; all these dat 1,1's throw Torch's timing off
        dat   1,1
        dat   1,1
        dat   1,1
        dat   1,1
        end start



From: mk4@starbase.neosoft.com (mk4s)
Subject: Re: Evolving CoreWar Warriors (was Pointers in pMARS)
Date: 1995/03/29
Message-ID: <3lbjnp$cbh@uuneo.neosoft.com>#1/1
references: <mreddy-0103951200330001@mreddy.comp.glam.ac.uk> <3j81v3$7ng@senator-bedfellow.MIT.EDU> <mreddy-0903950716040001@mreddy.comp.glam.ac.uk> <3ki5qe$7ka@falcon.ns.net> <mreddy-2003952048370001@mreddy.comp.glam.ac.uk> <3kppgj$i07@news.asu.edu> <mreddy-2803951117420001@mreddy.comp.glam.ac.uk>
newsgroups: rec.games.corewar,comp.ai.alife

Mike Reddy (mreddy@comp.glamorgan.ac.uk) wrote:
: In article <3kppgj$i07@news.asu.edu>, sieben@imap1.asu.edu wrote:

: Now, the current version of RedGen (our 'fast-breeder') is less than
: optimal, in that it does not yet allow the continuation of a set of
: existing warriors. And the interface, file and memory handling on the
: PowerPC need looking at. It may be we had a lucky first batch, so
: extensive evaluation of 'winning strategies' will need to be performed.
: However, I believe the platform (which is a thrid year project!) will be
: useful for experimenting with the production of artificial warriors, once
: the environmental and population modelling aspects are polished up.

Have you considered the moral implications of what you are doing?  This sounds
very much like cruelty to artificial animals to me.  How is it different than
breeding dogs or fighting cocks for the ring?  <grin>




From: inf93b11@mini01.vejlees.dk (Brian Jensen)
Subject: CoreWar-System for UNIX?
Date: 1995/03/29
Message-ID: <3lbhk6$5hv@esanews.denet.dk>#1/1
newsgroups: rec.games.corewar

Does anyone know where I can find a CoreWar-system for UNIX (ULTRIX)?

Thanks...

.-------------------------------------------------------.
| inf93b11@mini01.vejlees.dk |   ()  KEEP CLEAR!  ()    |
| Brian Jensen               |                          |
| Skikballevej 8             |        sig under         |
| DK-7080 Boerkop            |      construction!       |
'-------------------------------------------------------'




From: Scott Ellentuch <tuc@aindev.gtd.eds.com>
Subject: Call for suggestions on Hill improvement
Date: 1995/03/30
Message-ID: <3lf0r0$942@aindev.gtd.eds.com>#1/1
newsgroups: rec.games.corewar

Hello all,

	I'd like to make a call for people to make suggestions on
new/different things to add/enhance on the Storm King Industries
Hills.

	I'll summarize and reply to the whole group.


			Scott (tuc@stormking.com)



From: everdij@chem.rug.nl (Frank Everdij)
Subject: Re: King of the hill warning
Date: 1995/03/30
Message-ID: <D69D3o.9nK@rug.nl>#1/1
references: <stanne.25.0@nbnet.nb.ca>
newsgroups: rec.games.corewar

John E. Montgomery (stanne@nbnet.nb.ca) wrote:
: [22] Missing ";assert'
: Could some one explain this to me

It's nothing to worry about. The ';assert' statement is provided as a
restriction under which circumstances your warrior will compile.

For example, if your warrior will only work for coresize 8192, then put
';assert CORESIZE=8192' and voila, Pmars will only compile your warrior if
the coresize is exactly 8192 cells long. Neat ain't it!

If your warrior can work under all circumstances, just put in: ';assert 1'
and you will be free of any annoying messages.

For further detail chech the Pmars doc.

Cheers
--
 /     Frank Everdij:       \   This is the working hour!
|    Everdij@chem.rug.nl     |  We are payed by those
| http://rugmd0.chem.rug.nl/ |   who learn by our mistakes...
 \_ ~everdij/everdij.html __/                                 Tears For Fears.





From: morrell@jeeves.math.utah.edu (Steven C. Morrell)
Subject: Re: Paper Products
Date: 1995/03/30
Message-ID: <MORRELL.95Mar29220015@jeeves.math.utah.edu>#1/1
newsgroups: rec.games.corewar

I posted this a while back, but it's doing well still, so here is B-Panama X.



;redcode-94 verbose
;name B-Panama X
;kill test
;author Steven Morrell
;strategy  Better Stone / Silk (?) Paper

org boot

step equ 3044

stone     spl #0,>-10
          SPL #-step,<step
          MOV >-step,step+1
          ADD -2,-1
          DJN -2,<stone-50

cc        dat #-7

boot      mov stone+4,boot-200+4
          mov stone+3,<boot
          mov stone+2,<boot
          mov stone+1,<boot
          mov stone,<boot
          mov cc,boot-200+6

a         spl @boot,<-1000
          spl 1,<-2000
          spl 1,<-3000
          spl 1,<-4000
          mov {src,<src
          jmp @src,<1000

          dat <last,<2667
          dat <last,<2667
          dat <last,<2667

src       spl @0+8,2936+8
          mov }-1,>-1
          mov 5,>-2
          jmp -3,{-3
          spl 1,0
          mov 2,<-1
          djn.f -2,>-6
          dat <2667,<5334

;macro
for 70
          dat <last,<2667
rof

last      dat <last,<2667

end


Steven Morrell                 morrell@math.utah.edu



From: Robert@buchanan.demon.co.uk (Robert Macrae)
Subject: Re: Evolving CoreWar Warriors (was Pointers in pMARS)
Date: 1995/03/30
Message-ID: <796562436snz@buchanan.demon.co.uk>
references: <mreddy-0103951200330001@mreddy.comp.glam.ac.uk> <3j81v3$7ng@senator-bedfellow.MIT.EDU> <mreddy-0903950716040001@mreddy.comp.glam.ac.uk> <3ki5qe$7ka@falcon.ns.net> <mreddy-2003952048370001@mreddy.comp.glam.ac.uk>
newsgroups: rec.games.corewar,comp.ai.alife

I'm interested in Genetic Algorithms, which I've been using in developing 
financial forecasts. I think that Corewars is a most appropriate testbed 
for this kind of work because the competitive nature of the problem mirrors 
that in some very real financial environments. I'd definitely like to see 
the results! I've been thinking about writing a GA or similar to test 
combinations of properties in papers, but more of that later.

> This might not sound like much, but he started with seeding warriors which 
> were generated completely at random. Many warriors lost every battle in
> the first generation (as might be expected) but the trend was towards more
> draws and less wins and losses as each generation progressed.

The tendency towards more draws looks a bit worrying; it suggests that you 
may tend to hit a plateau in the warrior development, with warriors which 
don't kill themselves, but don't do anything very offensive either. This 
kind of plateau behaviour has been our major concern with practical use 
of these techniques.

> The successful beast is only about eight instructions long, and seems to
> copy a random memory location backwards throughout the core. Apparently,

This sounds like a bomber variant which is tuned against imps. It will beat 
a wide range of warriors, but it would lose to a "Paper" -- a self 
replicating program which runs many copies of itself in parallel and hence 
has redundancy to handle occasional bombing. This aspect of Corewars (that 
a mediocre paper will beat a good bomber but a good paper will lose to a 
mediocre scanner, etc) makes _populations_ of programs more interesting 
than an individuals since they can encompass several different families of 
programs. 

[ One project I'm going to attempt, real soon now, is to code up the game-
  theory code to calculate the equilibrium population given the score matrix 
  for a set of warriors. This would tell you, for each warrior, the 
  percentage of the time it would be used under the best mixed strategy for 
  the game. In an evolutionary context, it tells you (I believe) the 
  percentage it would make of a stable population. This measure shows which 
  warriors can beat other "Good" programs, rather than ones which are merely 
  efficient lame-duck killers, which would make it a good adjunct to any GA 
  work.]

Now (getting back to the point, I hope) I think the dominance of the bombing 
warrior may chiefly reflect a population problem -- the difficulty of 
evolving replicators. A replicator must both copy itself to a new location 
AND start a new thread there; a near miss won't do. This seats replicators 
in very steep local minima which do not have basins of attraction around 
them, so are very hard for any stochastic minimisation program to find. 
If there are no replicators in the population, then you will only evolve 
variants of bombers (imp rings being even harder to evolve than 
replicators).

To evolve really competitive warriors you'd need to ensure that there are 
always at least one representative of each type of warrior present in the 
population. One way to do this is to include papers and imp rings in the 
starting mix, but I suspect you'd see very few offspring which were better 
than their parents.

Another tack is to change the level at which the genes are expressed in 
Redcode. The most obvious choice (which I assume you've taken) is to map 
genes directly onto Redcode so that any combination of codes, modes and 
constants is available. Our  experience has been, however, that there is 
considerable value in _adding_ higher level constructs to the list of 
available elements so that useful combinations appear more often. In a 
redcode context this would mean adding genes which translate into groups 
of opcodes. For example, the key code from a Silk-type self-replicating 
code is:

	SPL     target, 0
	MOV     >-1,    }-1             (Or similar).

This accomplishes the self-replication, IF located at the start of the 
warrior and IF executed by as many processes as the code length. Now 
clearly this combination is very hard to find through pure random search, 
but if the above code fragment is available as a single gene (with one 
parameter, target), replicators become much easier to generate. I was 
considering using stochastic minimisation on a very restricted subset 
of warriors which consist soley of such replication opcode-pairs 
interspersed with MOV x, {y bombing attacks, but so far hand coding has
been easier.

Some people look at this type of seeding as cheating. Clearly if you seed 
with constructs like this, the creation warriors  which merely survive 
becomes much less impressive. I'd advocate it, however, for three reasons. 

First, you are not making any part of the search space unobtainable, as 
all the basic opcodes are still available. The GA can still produce any 
legal program, you are only concentrating the search in a-priori plausible 
areas. 

Second, the GA process depends on abstraction of structure which can be 
genetically manipulated. It is up to us how we do this, and I'd back 
skilled abstraction against unskilled any day. If skilled examination of 
existing warriors shows that there are recognisable building-blocks which 
involve several co-ordinated opcodes, then make these building-blocks 
available. 

Third, though the success in evolving viable warriors from the redcode 
level up is pretty impressive, the real test in Corewars or finance, 
is how far down the road from viable to ideal you can tread...
 



From: Stuart Rosenberg <stuart@khm.uni-koeln.de>
Subject: pMARS code
Date: 1995/03/31
Message-ID: <3lha3u$3f3@news.rrz.uni-koeln.de>#1/1
newsgroups: rec.games.corewar

HI


Does anyone know where I can obtain the source
code of pMARS for windows? We are developing
an alternative visualization program which
is almost complete for the MAC and we want 
to integrate it into a PC version.

Please let me know. You can mail me direct.


Thanks alot,


Stuart Rosenberg 



From: Robert@buchanan.demon.co.uk (Robert Macrae)
Subject: Re: Evolving CoreWar Warriors (was Pointers in pMARS)
Date: 1995/03/31
Message-ID: <796675629snz@buchanan.demon.co.uk>#1/1
references: <3lbjnp$cbh@uuneo.neosoft.com>
newsgroups: rec.games.corewar,comp.ai.alife

In message <9503311346.AA18033@deep-thought.ericsson.se> Mark Sadler writes:

> Another idea is to run separate evolutions, score one population against each
> type of warrior, this should tend to develop 'paper-killers' or 'imp-killers'
> etc.  This would only required one set of battles for each individual.

Sounds good, but very optimistic. How familiar are you with corewars? This
issue of paper-scissors-stone is key; yes, in theory develop one of each by
feeding it its natural prey, but paper and scissors will be harder to grow
than stones because they require many more co-ordinated instructions. At 
a rough guess 10 opcodes x 5^2 address modes x 20^2 addresses => 100 000
possible instructions. A stone needs 4-5, a scanner (scissors) needs 7-10,
a replicator (paper) 6-10, so the search space is much more tractable for 
stones, at 10^20 rather than 10^40.

Note I'm conservative on addresses, assuming 20. This factors in a strong
preference for small addresses (-3,-2,-1,0,1,2,3 etc). Not compulsory
I guess, but if you fancy searching a (10x5^2x8000^2)^10 space, you must
_really_ believe in GAs! 

Further idea on sources of codes, in spirit of preselection above. Why not
form a large list of handwritten warriors end to end, and select most of your 
random codes from this list of instructions? It would bias you towards 
combinations of opcode, mode, address which appear more often. I guess I'm 
betraying my "Results over purity" bias again, but thats what you get for 
being an engineer in a finance company. How hard does academia push the 
purity line?

-- 
Robert Macrae



From: Robert@buchanan.demon.co.uk (Robert Macrae)
Subject: Re: Paper Products
Date: 1995/03/31
Message-ID: <796651296snz@buchanan.demon.co.uk>#1/1
references: <MORRELL.95Mar29220015@jeeves.math.utah.edu>
newsgroups: rec.games.corewar

In article <MORRELL.95Mar29220015@jeeves.math.utah.edu>
           morrell@jeeves.math.utah.edu "Steven C. Morrell" writes:

> I posted this a while back, but it's doing well still, so here is B-Panama X.
 
 <Header deleted>

> stone     spl #0,>-10
>           SPL #-step,<step
>           MOV >-step,step+1
>           ADD -2,-1
>           DJN -2,<stone-50
 
 <Silkoid paper deleted>

God how I kicked myself when I saw this. I'd given up on getting a bomber 
to work with a fast-splitting paper, but _of_course_ you can add an extra 
SPL 0 to the bomber to compensate... Obvious now, and thanks.

-- 
Robert Macrae