From: maniac@unlv.edu (Eric J. Schwertfeger)
Subject: X-Hill Tutorial {LON{LONG}[LONG]
Organization: Too many
Date: Sat, 22 Aug 92 22:34:28 GMT

I.  What makes the Experimental Hill Different.

There is one important difference, and a few minor ones between the
standard hill and the X-hill.  The major difference is that the
X-hill imposes a write limit on everything that your program does. 
This isn't an addressing range limitation, but an actual write
limit.  While you are capable of reading any memory cell, you can
only modify cells within a range of 250 cells from the currently
executing instruction.  If you attempt to change a memory cell, by
any means, that is outside the write limit range, the instruction
will still execute, but the cell will not change.  You can use a
memory cell outside the range as a pointer to another cell, but if
the final destination is farther than 250 cells from the executing
instruction, the write won't take place.  Also note that if you use
predecrement or postincrement addressing mode on a cell outside the
range, the cell won't get changed.  The exact results of this
depend on the interpretation, so you should avoid using those modes
when the intermediate cell is outside the write range.

The other difference is an improvement.  In addition to an
additional addressing mode, postincrement, you gain the ability to
use any addressing mode in any place.  The use of immediate B-field
operations can be particularly helpful.  The two most common uses
of immediate B-field mode instructions I use are DJN WHERE,
#NUMBER, or MOV #INIT, #WHAT.

II.  The Implications of the Write Limit.

The write limitation has major implications on almost all aspects
of the programs.  Since you can only reach one sixteenth of the
core at any one time, you need to either hope the enemy comes
within reach, accept a lot of ties, or find a way to extend your
reach.  The most common method of extending the reach of a program
is to make the program move itself, or move a small part of itself. 
This by itself has almost as many implications as the write limit
does.  

Because movement is almost required, SPL 0 bombing can become very
dangerous to the bomber.  It is quite possible to eventually move
onto a memory range with several processes running, resulting in
mass confusion, and possible death.  There are several ways to
avoid this.  One method is to bomb with JMP PIT instructions, where
PIT is a splitting trap, ensuring that the pit is located somewhere
that your program won't copy itself to, or will DAT bomb long
before moving there.  Spider, Loki, and Halberd all use this type
of bombing.  Another method is to bomb with both DATs and SPLs in
such a pattern that any place that gets SPL bombed will get DAT
bombed long before the code hits that place.  Sonic Boom uses this
type of SPL bombing.  Another type of bombing that reduces the
chances of impaling yourself is to bomb with JMP 0 instructions. 
This isn't as effective, since you are only eliminating a portion
of the opponents CPU time, rather than sucking up most of it. 
There are some traps that you can bomb with that will split for a
while then kill off whatever is trapped, but bombing with a small
program is usually more complex than bombing with a single
instruction.  Finally, something that I have experimented with, but
never found necessary, is bombing with SPL 1, and ensuring that
every 12th instruction or so is a DAT.  This way, you won't need to
kill trapped processes yourself.

One form of attack that gets around the write limit originated in
the program "Splitting Nightmare."  This form of attack finds enemy
code, then split to it.  The idea of this attack is that many
programs on the X-hill will stop working if two processes are
executing the code.  Either the code breaks, and both processes
die, possibly resulting in a win, or neither dies, resulting in a
tie at worst.  This form of attack is becoming less effective on
the hill now, since many programs on the hill are starting to
defend themselves from this form of attack, as described in section
IX.

Another tactic that the write limit promotes is the use of separate
attack programs, often called "fangs."  Spider uses small fangs to
create other fangs, and to attack, so that the opposing program
must hit a very small target, but the program is still capable of
sophisticated behavior, because the large central program is off
safely out of range.  Halberd creates a small fang out ahead of
itself to clear the area that is within range of where it will move
to, so that in order to attack the main program, the opposing
program must either kill the fang, move rapidly past the fang, or
approach from the other direction.

Finally, the write distance considerably complicates the use of
decoys, since you can only directly write a decoy a limited
distance away, which is not sufficient to save the main program. 
On the X-hill, there are a few very fast programs that copy
themselves ahead, dying when they hit code, including themselves. 
This is very useful, because for the cost of a few
hundred cycles, you can create a small decoy spaced out though all
core.  Here is an example of one such decoy, the one I use in
almost all of my programs.

DSTEP   EQU     (200)
DECOY   SPL     1
        MOV     <CALL, <JUMP
JUMP    JMN     @0, #DSTEP+1
CALL    DAT     0, 0

The DSTEP variable sets the rate that the program can step through
memory.  It can be set to any of the following values:  4, 8, 10,
16, 20, 32, 40, 50, 64, 80, 100, 125, and 200.  The larger values
create a more sparse decoy, but consume less time.  It is also
appropriate to delay before executing the main body of your program
if you split off multiple processes.

III.  The basic categories of X-Warriors

Most people have heard that most of the programs on the standard
hill break down into variations on three classes of programs. 
Paper, Stone, and Scissors.  Classification on the X-Hill isn't
quite as clean cut, because only the Paper category performs
properly unmodified, and both Stone and Scissors have several
variations due to the mobility restrictions.  The first basic
category is the core clear program.  This is where a program bombs
all the memory within range, then moves to the outer end of the
write range and repeats the procedure. 

Jumpers are similar, but in this case the bombing, if done, is not
as complete.  The idea with a jumper is to move as fast as
possible, using the program itself as the bomb.

Replicators are the closest to their relatives on the standard
hill, the only difference being that they can only duplicate
themselves within the write range.

Missile launchers are program that create sub-programs capable of
moving themselves.  Some programs launch stupid missiles that just
keep going, or go to a given distance and die.  Some programs fire
missiles with bomber warheads that activate when the program
reaches a given distance.

Finally, ambushers are programs that don't move, but expect that
the opposing program will move into their range.

IV.  Designing Core Clear Programs.

Core clear programs can be quite effective and simple to write. 
The basic idea is to bomb all the memory locations between the
program and the write limit, then copy yourself forward or back. 
Both the bombing and the copying can be done either with a loop or
with multiple processes.  Often the program combines bombing and
moving, where the code and traps or DAT bombs are moved as one
unit.  Odin uses this to rapidly bomb and move without too much
overhead, since the same code bombs and makes the next copy.

Like any bomber on the regular hill, you can bomb with DAT
statements, which will do fine against single process programs, JMP
PIT instructions, or SPL 0 bombing, which is most effective if you
are bombing all the locations, rather than mod-2 or higher bombing.

Core Clear is an almost necessary function of any warrior that
hopes to score well.  Of the six top programs at this time, three
are primarily core clear programs, and the other three have a core
clear cleanup after the primary program finishes.

Two other things to consider with core clear routines.  The first
is territoriality.  Due to the write limitations of the X-hill,
things are a little territorial.  If you have a fast moving core
clear, noone's going to come up from behind you.  If you have two
core programs, one going each direction, the middle area is as safe
as possible.

Another thing to think of is repeat core clears.  This is where you
have a monitor program, which can do something else as well, splits
to the core clear program, waits until the core clear program
should have gone all the way around and killed the monitor, and
then splits to it again.  This way, if the first core clear gets
killed, the second one might just do the trick.  Sonic boom uses
both of these ideas to a great degree of success.

Sections XII and XIII detail two core clear programs that both made
the hill for a short while, with comments.

Core clear programs currently on the hill consist of Sonic Boom,
Halberd, Odin, and Lance.  Several other programs on the hill
contain core clear elements, because it is very necessary to make
sure that all processes are dead.  These include Spider, Loki,
Scorpion, Stomper, and Boston Mangler.

V.  Jumper Design Considerations

Designing a jumper is much like a regular core clear, but with more
emphasis on the movement, and less on bombing.  The way a jumper
wins is by copying itself into the opposing program, and having the
other program either dying when it enters, or having a monitor
program that kills off any jumpers, and any code that winds up
executing the jumper becomes one.  

Loki uses a jumper, with the first instruction being a JMP PIT, so
that if it copies itself into the opponent and the opponent falls
into the program, it will wind up jumping to the pit, rather than
becoming a jumper.  What happens if you copy over a currently
executing instruction?  This should be a major concern to the
designer of a jumper.  If you only have one jumper, and jumping on
top of the opponent will kill both, then you probably won't win
very often.

A jumper program can also have a repeat monitor similar to the one
I discussed in the section on core clear programs, though it
requires a little more coordination.

SkipShot, detailed in section XIV, is my fastest non-destructive
jumper.  Scorpion is another example, with limited SPL and DAT
bombing built in.

VI.  Replicator Design Considerations.

Replicators on the X-Hill are much like they are on the standard
hill, except for the write distance limitation.  I have never had
much success with replicators on the regular hill, but my first
replicator made it to tenth place, and for a while Sigil was in
first place.  I suspect this is because there aren't that many
vampires on the hill, and ties are more prevalent on the X-Hill. 
The basic idea is to copy the program and start it, increasing the
number of copies of the program that are executing.  One of the
considerations of replicators is to ensure that you only have one
process, or set of processes, running in your program at one time. 
The mechanism I use in squish is hardly the best, but it's the only
way I know of doing it.  Squish is detailed in section XV.

VII.  Missile Launcher Design Considerations

Spider is easily the most successful missile launcher on the hill,
though it doesn't use self sufficient missiles like other programs
use.  The simplest missile launchers merely launch several jumper
type programs.  Spider, at the other end of the spectrum, scans for
the enemy program, builds a chain of fangs to the target site, then
uses the last fang to drop JMP PIT instructions all over the target
area.

Having never worked with Missile launchers, I can't help much here,
though I can tell you one thing to avoid.  Judging by what I see
when I run a program against Spider, it starts scanning where it
is, scans up and down till it finds something, then shoots.  It
will shoot once up, and once down, then fall into its core clear
routine.  This is fine, except that if you launch a decoy, then
Spider will rapidly degenerate into a core clear program, loosing
much of it's functionality.  There must be a better compromise than
this.  Either find a way to tell decoys from the actual programs,
or continue scanning after the first shot.  Oh, and be very careful
to enforce a minimum range.  You need to avoid shooting your own
code.

IX.  Splitting Nightmare Design Considerations.

The two biggest problems Splitting Nightmare type programs have is
that they don't always disrupt the code they bomb, and they tend to
bomb things that they shouldn't, like SPL 0 bombed areas, or the
trail an IMP leaves.  There isn't much that can be done about the
first problem, and only careful examination can prevent the second
problem.  I'd suggest comparing two locations, skipping them if
they're the same, then directly comparing the target to MOV 0,1 to
avoid imps, and perhaps even going so far as to move the
destination cell within write range, subtracting it from itself to
clear out the A and B fields, then comparing that to SPL 0, 0.  Of
course, to counter that, use JMPs to SPL traps, or use SPLs with
different addressing modes (such as SPL 0,@0).

X.  Ambusher Design Considerations

Ambushers can be very small targets, don't waste time moving, are
the easiest to write, but loose out if the opposing program doesn't
move all its processes within range.  If you add a core clear
routine to the ambusher, you can reach out to clear the core after
a while, but then you enlarge your target area.  It's all a matter
of trade offs.

The simplest ambusher is a four line program I submitted as my
first X-hill program.  It didn't do well, but it shows the basics.

BOMB      EQU  (LOOP-249)
LOOP      MOV  DATBOMB, @DATBOMB
SUB       #8,  DATBOMB
JMP       LOOP
DATBOMB   DAT  #0, #496

This is an infinite ambusher.  When the bomber would run outside
the write range, it drops a bomb on the bomb pointer, which points
the pointer back up to the top of the write range.  However,
replacing the JMP LOOP with DJN LOOP, #7999 will bomb for almost
24000 cycles, then fall through to the next part of the routine,
possibly a core clear routine.  If this is done, however, you will
need to make sure that every 8th memory cell can be blasted without
hurting your program.  The cell before LOOP is the reference point,
being one of the places that get hit.

By changing the code, you can make this much more effective against
Imps.  The changes require using predecrement mode for both the MOV
and the JMP, as well as initializing BOMB with 1.  The constant
subtracted should also be changed to 6 in this case.

XI.  General Design Considerations

Since multi-process programs are more common on the hill than on
the X-hill, vampiric bombers tend to do better than DAT bombers. 
Often bombing a fang with a DAT won't make much of a difference,
but carpet bombing the fang with SPL 0 will make the main body run
much slower, increasing its vulnerability.  

Also, similar to the regular hill, programs that change their
function after a while tend to do better on the X-hill.  A vampire
might do well at capturing the opposing programs, but if it doesn't
do a core clear to kill everything before the trapped processes die
out, you can still loose to replicators.

Decoys are a necessity when battling Spider or another scanner with
fast deploying fangs.  Even a core clear program moving at an
average speed of two cells per cycle, or twice the speed of
"light," will not clear an area Spider targets before the fang
arrives and drops its bombs.  In fact, using a step of 100 for your
decoy has an additional advantage against large programs like
Spider.  The decoy becomes an offensive program likely to disrupt
the code of Spider, because the step isn't large enough to skip
over the code, and a hit will take place.

While a fast jumper doesn't need a decoy, replicators will still
need a decoy. This is because the replicator that the scanner saw
will still be in the area, and replicators are vulnerable to
vampires, of which Spider is one.

XII.  Rolling Thunder

Here is a core clear program I wrote that made the hill for a
little while, Rolling Thunder.  This one uses a single process and
loops.  Note that unrolling the loops a little will help, though
unrolling too much will make the program too large of a target to
survive.

;redcode-x
;name Rolling Thunder 1.30
;author Eric J. Schwertfeger
;strategy Bomber, now with optimized (but not
;strategy optimal) step.
;strategy Blast far away, move down a little, blast
;strategy far away, move down, etc.  The idea is to
;strategy always hit long, so we hit the other program
;strategy as soon as it comes in range.  Flawed thinking,
;strategy, but it works.
;strategy Submitted: @date@
BOMBSITE  EQU  START-248
BITE      EQU  150
LAUNCH    MOV  #3-BITE,SRC+BITE
          MOV  #2-(BITE*2),DEST+BITE
          MOV  #6,COUNT+BITE
          JMP  START
COUNT     DAT  #0, #6
START     MOV  BOMB, BOMBSITE
LOOP      MOV  BOMBSITE, <BOMBSITE
          DJN  LOOP, BOMBSITE
COPY      MOV  <(SRC+BITE), <(DEST+BITE)
          MOV  <(SRC+BITE), <(DEST+BITE)
          DJN  COPY, (COUNT+BITE)
          JMP  START-BITE
SRC       DAT  #0, BOMB-BITE+1
DEST      DAT  #0, BOMB-(BITE*2)+1
BOMB      DAT  #1234,#BITE
PIT       SPL  1,1       ; this pit isn't used by the code, but is
          SPL  PIT,1     ; here to trap any splitting nightmare
          SPL  PIT,1     ; attacks
          SPL  PIT,1
          SPL  PIT,1
          SPL  PIT,1
          SPL  PIT,1
          SPL  PIT,1
          SPL  PIT,1
          SPL  PIT,1
          JMP  PIT,1
          JMP  PIT,1
; several more JMP PIT,1 lines deleted for brevity.

     END  LAUNCH

XIII.  TEST END

Here's another example of a core clear program.  This was a
performance evaluation test program using 8 processes for the core
clear.  You'll notice that in this version, I don't initialize any
pointers, but rather use the pointers from the previous copy of the
code, then copy the current copy forward, so the original offsets
are retained, eliminating the need to reinitialize them.  You'll
also notice that I only bomb the 32 farthest positions, then copy
forward.  While this is inefficient, it allows this program to get
the jump on a lot of the slower moving or immobile programs,
because it's hitting them soon after it moves within range.

CLEARS    EQU  32
CSTART    MOV  CCSRC,CCSRC+CLEARS
          MOV  CCDEST,CCDEST+CLEARS
          MOV  CBDEST,CBDEST+CLEARS     
          SPL  1
          SPL  1
          SPL  1
CLEAR     MOV  CCDEST, <CBDEST+CLEARS
          MOV  CCDEST, <CBDEST+CLEARS
          MOV  CCDEST, <CBDEST+CLEARS
          MOV  CCDEST, <CBDEST+CLEARS
          MOV  <CCSRC+CLEARS, <CCDEST+CLEARS
CCSRC     JMP  CLEAR-CLEARS, #CBDEST+1-CLEARS
CCDEST    DAT  #0, #CBDEST+1-(CLEARS*2)
CBDEST    DAT  #0, #CLEAR-247
          END  CSTART


XIV.  SkipShot

My fastest jumper, SkipShot, will lap the entire core in under 200
cycles, and won't die if it hits another program. Other programs,
however,  tend to die if they fall into the code, since three
processes are required to make a complete copy of the program.

;redcode-x
;name SkipShot 1.3
;author Eric J. Schwertfeger
;strategy v 1.3 Trying to streamline as much as possible
;kill Echo 1.1
SKIP      EQU  (247)
          MOV  SRC,SRC-SKIP
          MOV  DEST,DEST-SKIP
          SPL  1
          MOV  -1,0
          JMP  START
SRC       DAT  DEST+1+SKIP
START     MOV  <SRC-SKIP,<DEST-SKIP
DEST      JMP  START+SKIP,#1+(SKIP*2)
          END

XV.  Squish

Squish is a replicator, with no other functions.  It does no
bombing other than its own replication.  It still needs work, since
this is the first version, and I'm surprised it did as well as it
did on the hill.

;redcode-x
;name Squish 0.10
;author Eric J Schwertfeger
;strategy Eww, look what you stepped in! :-)
;strategy a rather awkward replicator, but my
;strategy first x-replicator none-the-less.
;strategy Submitted: @date@
SIZE      EQU  14
UPDIST    EQU  (16*13)
DNDIST    EQU  (-16*11)
DSTEP     EQU  (200)
SRC       DAT  0, 0
START     DJN  SRC,#1
          MOV  #UPDIST,UPDST
          MOV  #DNDIST-1,DNDST
          MOV  #SIZE,SRC
LOOP      MOV  <SRC,<UPDST
          MOV  @SRC,<DNDST
          MOV  <SRC,<UPDST
          MOV  @SRC,<DNDST
          JMN  LOOP,SRC
          MOV  #1,START+UPDIST
          MOV  #1,START+DNDIST
          SPL  START+UPDIST
          JMP  START+DNDIST
UPDST     DAT  0, 0
DNDST     DAT  0, 0
          DAT  0, 0
          DAT  0, 0
LAUNCH    SPL  DECOY
          DJN  0,#80
          JMP  START
DECOY     SPL  1
          MOV  <CALL,<JUMP
JUMP      JMP  @0,#DSTEP+1
CALL      DAT  0, 0
          END  LAUNCH


XVI.  Halberd

Halberd is the earliest of my successful programs, and a good
demonstration of fangs as an attack method.  It sets up a small
fang ahead of it, which bombs everything between -250 to -500 mod-6
relative to the start of Halberd.  Once this is bombing is done, it
kills the fang, copies itself forward, then repeats.

;redcode-x
;name Halberd 1.50
;author Eric J. Schwertfeger
;strategy Rolls through memory bombing with JMP PIT 
;strategy instructions, then after two passes, changes
;strategy to DAT bombing.
;strategy v 1.5X 1.3, 1.4 failed experiments, now with
;strategy        decoy and faster splitting pit.
;strategy submitted @date@
DSTEP     EQU  (-200)
STEP      EQU  (228)
DENS      EQU  (-6)
LANCE     EQU  (BOMB-STEP)
PIT       SPL  1
          SPL  PIT
          SPL  PIT
          SPL  PIT
          JMP  PIT
BOMB      JMP  PIT-(LANCE+DENS)-4,#(LANCE+DENS)
START     MOV  #(LANCE),BOMB  ; set up the fang
          SUB  INC,BOMB
          MOV  LANCE1,LANCE
          MOV  LANCE3,LANCE+1
          MOV  LANCE2,LANCE+2
          SPL  LANCE
BCOUNT    MOV  #18,#0         ; loop while the fang is killing
BLOOP     SUB  INC,BOMB       ; help the fang out, rather than sit
          SUB  INC,BOMB       ; idle, we do it's adding
          DJN  BLOOP,BCOUNT
          SUB  INC,BOMB  
          MOV  DATBOMB,LANCE
          DJN  SRC,#79        ; after 79 jumps, we've gone around
          MOV  DATBOMB,BOMB   ; core almost twice, time to start
SRC       MOV  #LANCE2+1,#0   ; killing
DEST      MOV  #LANCE2+1-STEP,#0
COUNT     MOV  #14,#14
MLOOP     MOV  <SRC,<DEST
          MOV  <SRC,<DEST
          DJN  MLOOP,COUNT
          JMP  START-STEP
INC       DAT  #DENS,-DENS
DATBOMB   DAT  #0,#0
LANCE1    MOV  STEP,@STEP
LANCE3    MOV  (STEP-1),@(STEP-1)
LANCE2    JMP  LANCE1
LAUNCH    SPL  DELAY
          SPL  1
          MOV  <CALL,<JUMP
JUMP      JMN  @0,#DSTEP+1
CALL      DAT  0, 0
DELAY     DJN  DELAY,#80
          JMP  START
          END  LAUNCH

XVII.  Loki

Loki is my most sophisticated and intricate X-hill warrior so far. 
It starts a jumper, which drops JMP PIT every 10 bytes, while an
ambush program sits and drops JMP PIT in any programs that come
near it.  Once the jumper has made it through most of core, the
ambusher kills it and goes into core clear mode.

;redcode-x
;name Loki 2.30
;author Eric J. Schwertfeger
;strategy A fairly major rewrite of Loki 1.30.  Changed
;strategy everything but core-clear, and I'd change that
;strategy if I had the room for 2 more instructions
;strategy Multi-Part, synchronized program consisting of
;strategy 1 jumper (eventually killed by dwarf)
;strategy 1 dwarf
;strategy 1 core-clear (started by dwarf after jumper is killed)
;strategy v 2.0 new code, constants do worse vs spider,
;strategy       better vs everything else (it seems).
;strategy v 2.1 found major bug
;strategy v 2.2 2.1 fix didn't fix bug, so I rewrote the
;strategy       core-clear to avoid problem.
;strategy v 2.3 made jumper a little more offensive.
;strategy Submitted: @date@
MOD       EQU  (10)
STEP      EQU  (MOD*23)
BOMB      EQU  (FOO-241)
CLEARS    EQU  32
JLAUNCH   MOV  DEST,DEST-STEP
          JMP  LOOP
SRC       JMP  PIT,#10
LOOP      MOV  <SRC,<DEST-STEP
          MOV  <SRC,<DEST-STEP
          JMN  LOOP,SRC
          ADD  ADJUST,(SRC+STEP)
          MOV  JMPJMP,SRC+(MOD*12)-1
DEST      JMP  LOOP+STEP,#SRC+10+(STEP*2)
JMPJMP    JMP  1-(MOD*12),10
ADJUST    DAT  -STEP,10
          JMP  PIT,20
          DAT  0, 0      ; large blank space where Jumper will land
          DAT  0, 0      ; before being killed
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
CSTART    MOV  CCSRC,CCSRC+CLEARS
          MOV  CCDEST,CCDEST+CLEARS
          MOV  CBDEST,CBDEST+CLEARS     
          SPL  1
          SPL  1
          SPL  1
          JMP  CLEAR
PIT       SPL  PIT
          SPL  PIT
          JMP  PIT
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
LAUNCH    SPL  JLAUNCH
FOO       MOV  JMPBOMB,BOMB
BLOOP     MOV  BOMB,@BOMB
          SUB  OFFSET,BOMB
          JMN  BLOOP,BOMB
          DJN  FOO,#63
KLOOP     MOV  OFFSET,FOO-STEP+2
          DJN  KLOOP,#100
          JMP  CSTART
OFFSET    DAT  #-MOD,MOD
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
          DAT  0, 0
CLEAR     MOV  CCDEST, <CBDEST+CLEARS
          MOV  CCDEST, <CBDEST+CLEARS
          MOV  CCDEST, <CBDEST+CLEARS
          MOV  CCDEST, <CBDEST+CLEARS
          MOV  <CCSRC+CLEARS, <CCDEST+CLEARS
CCSRC     JMP  CLEAR-CLEARS, #CBDEST+1-CLEARS
CCDEST    DAT  #0, #CBDEST+1-(CLEARS*2)
CBDEST    DAT  #0, #CLEAR-247
JMPBOMB   JMP  PIT-BOMB-480,480
          END  LAUNCH

XVIII.  Stomper

Stomper is a simple ambusher that eventually goes into a core-clear
mode.

;redcode-x
;name Stomper 1.10
;author Eric J. Schwertfeger
;strategy Sends out a Decoy, Starts an X-Dwarf that 
;strategy bombs with JMP 0, and periodically starts a 
;strategy core-clear.
;strategy v 1.1 Can get scared into core-clear early
DELAY     EQU  (410)
STEP      EQU  (24)
DSTEP     EQU  (200)
BOMB      EQU  (DWARF+239)
RSPLIT    SPL  1
          SPL  1
          SPL  1
          JMP  RMOVE
          DAT  0, 0
RBDEST    DAT  0, #RBDEST-240
RCLEAR    MOV  RBDEST+STEP, <RBDEST+STEP
          MOV  RBDEST+STEP, <RBDEST+STEP
          MOV  RBDEST+STEP, <RBDEST+STEP
RMOVE     MOV  <RCSRC+STEP, <RCDEST+STEP
RCSRC     JMP  RCLEAR-STEP, #RCDEST+2-STEP
RCDEST    SPL  0, #RCDEST+2-(STEP*2)
          DAT  0, 0
DWARF     MOV  JMPBOMB,@BOMB
          SUB  #-8,BOMB
          JMN  RSTART,BOMB+40
COUNT     DJN  DWARF,#0
          MOV  #DELAY,COUNT
          SPL  RSTART
          JMP  DWARF
          DAT  0,0
RSTART    MOV  #RCDEST+2-STEP-RCSRC,RCSRC+STEP
          MOV  #2-(STEP*2),RCDEST+STEP
          MOV  #RCDEST+2-STEP-RCSRC,RCSRC
          MOV  #2-(STEP*2),RCDEST
          JMP  RSPLIT
JMPBOMB   JMP  0,#-480
          DAT  0, 0
          DAT  0, 0
LAUNCH    SPL  DWARF
          SPL  1
          MOV  <CALL,<JUMP
JUMP      JMP  @0,#DSTEP+1
CALL      DAT  0, 0
          END  LAUNCH

-- 
Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu
Newsgroups: rec.games.corewar