Article 2336 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!dunix.drake.edu!acad.drake.edu!pk6811s
From: pk6811s@acad.drake.edu
Subject: Re: _The_Big_Hill_ at stormking.com
Message-ID: <1993Dec1.081746.1@acad.drake.edu>
Lines: 14
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
References: <1993Nov29.201150.21246@news.vanderbilt.edu> <2dg5e0$jij@agate.berkeley.edu>
Date: Wed, 1 Dec 1993 14:17:46 GMT

> In article <1993Nov29.201150.21246@news.vanderbilt.edu>,
> Stefan Strack <stst@vuse.vanderbilt.edu> wrote:
>I am proposing the parameters below for a new x-hill at stormking.com:
>  ...
>We can have this up and running by coming weekend. What do you think?
> 

I'm hoping that a self-repairing program (Bunker) can survive in
the larger core, since it will be much harder to locate both partners.
Large core-size might prove to be the bane of stand-alone single-process
programs.

Paul
pk6811s@acad.drake.edu


Article 2337 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!soda.berkeley.edu!mconst
From: mconst@soda.berkeley.edu (Michael Constant)
Newsgroups: rec.games.corewar
Subject: Larger Coresizes, The Big Hill at stormking.com
Date: 1 Dec 1993 20:09:01 GMT
Organization: Society for the Destruction of All Known Lifeforms, UC Berkeley
Lines: 34
Message-ID: <2ditkt$d24@agate.berkeley.edu>
References: <1993Nov29.201150.21246@news.vanderbilt.edu> <2dg5e0$jij@agate.berkeley.edu> <1993Dec1.081746.1@acad.drake.edu>
NNTP-Posting-Host: soda.berkeley.edu

In article <1993Dec1.081746.1@acad.drake.edu>,  <pk6811s@acad.drake.edu> wrote:

>I'm hoping that a self-repairing program (Bunker) can survive in
>the larger core, since it will be much harder to locate both partners.
>Large core-size might prove to be the bane of stand-alone single-process
>programs.

This is partly true.  Yes, self-repair programs benefit enormously from the
larger coresize.  This is good - we haven't seen many self-repair programs
recently.  However, a 4-line stone hidden in a 55400-cell core is going to
be awfully hard to find.  This is also good in fact, because it will give
stones a slight boost in performance.  Reason: they take longer to cover the
core is balanced by everything else takes longer to find it.  Then the ad-
vantage comes from the decrement - on average, it will make more decrements
before it is found and thus keeps scanners just that much busier.
Also, BTW, paper will be almost unaffected in the big coresize.  It will be
marginally harder to find by scanners, but all modern paper gets rid of the
scanners beforehand anyway.  And there are a couple of small imp-numbers in
coresize 55440.  Not too many, but certainly not few enough to eliminate imps.
(I think that the smallest possible spiral is 13-point.)

Finally, speaking of coresize 55440, here is another announcement of my
optima program, version 2.0, on soda.  It handles larger coresize, it
estimates the time needed for a long calculation, and it fixes several bugs
from the original version.  I think there are a couple of people out there
to whom I mailed my original optima calculator - they should all (both?)
get the new version from soda.  The file is optimapc.exe for PC users or
optima.shar for anyone else, in the pub/corewar/incoming directory.  (We
need a pub/corewar/misc for things like optima and PK's num8000.zip).
-- 
                      - Michael Constant
			mconst@soda.berkeley.edu

GM/CS d? p c++(++++) l u(++) e(*) m++ s--/- !n h f+ g+ w+ t++(+++) r+@ !y


Article 2338 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Re: Larger Coresizes, The Big Hill at stormking.com
Message-ID: <1993Dec1.212541.10735@news.vanderbilt.edu>
Sender: news@news.vanderbilt.edu
Nntp-Posting-Host: necs.vuse.vanderbilt.edu
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
References: <2dg5e0$jij@agate.berkeley.edu> <1993Dec1.081746.1@acad.drake.edu> <2ditkt$d24@agate.berkeley.edu>
Date: Wed, 1 Dec 1993 21:25:41 GMT
Lines: 20

In article <2ditkt$d24@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes:
>recently.  However, a 4-line stone hidden in a 55400-cell core is going to
>be awfully hard to find.  This is also good in fact, because it will give
>stones a slight boost in performance.  Reason: they take longer to cover the
>core is balanced by everything else takes longer to find it.  Then the ad-
>-- 
>                      - Michael Constant

I did some limited testing with Coresize=32,000 a while ago, using 12 published
warriors that would not only work in this coresize, but also had near optimal
constants. The results indicated that simple stones did actually _worse_ in
the larger core; losing increasingly to CMP-scanners. Paper-types were pretty
much unaffected (I had no imps in this round-up). The likely reason is that as 
coresize increases, the advantage in size that stones have over scanners is
outweighed by their disadvantage in speed.

This is another way of saying large coresizes encourage larger warriors, and
this is a prerequisite for smarter programs.

-Stefan (stst@vuse.vanderbilt.edu)


Article 2339 of rec.games.corewar:
Path: hellgate.utah.edu!caen!spool.mu.edu!agate!soda.berkeley.edu!mconst
From: mconst@soda.berkeley.edu (Michael Constant)
Newsgroups: rec.games.corewar
Subject: Re: Larger Coresizes, The Big Hill at stormking.com
Date: 2 Dec 1993 18:43:44 GMT
Organization: Society for the Destruction of All Known Lifeforms, UC Berkeley
Lines: 21
Message-ID: <2dld10$25u@agate.berkeley.edu>
References: <2dg5e0$jij@agate.berkeley.edu> <1993Dec1.081746.1@acad.drake.edu> <2ditkt$d24@agate.berkeley.edu> <1993Dec1.212541.10735@news.vanderbilt.edu>
NNTP-Posting-Host: soda.berkeley.edu

In article <1993Dec1.212541.10735@news.vanderbilt.edu>,
Stefan Strack <stst@vuse.vanderbilt.edu> wrote:

>I did some limited testing with Coresize=32,000 a while ago, using 12 published
>warriors that would not only work in this coresize, but also had near optimal
>constants. The results indicated that simple stones did actually _worse_ in
>the larger core; losing increasingly to CMP-scanners. Paper-types were pretty
>much unaffected (I had no imps in this round-up). The likely reason is that as 
>coresize increases, the advantage in size that stones have over scanners is
>outweighed by their disadvantage in speed.
>
>This is another way of saying large coresizes encourage larger warriors, and
>this is a prerequisite for smarter programs.

But then, is it not true that without stones to keep them under control,
scanners will proliferate and beat up on all the big, slow smart programs?
-- 
                      - Michael Constant
			mconst@soda.berkeley.edu

GM/CS d? p c++(++++) l u(++) e(*) m++ s--/- !n h f+ g+ w+ t++(+++) r+@ !y


Article 2340 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!soda.berkeley.edu!mconst
From: mconst@soda.berkeley.edu (Michael Constant)
Newsgroups: rec.games.corewar
Subject: MNCT Round 2 Exact Rules
Date: 2 Dec 1993 19:06:16 GMT
Organization: Society for the Destruction of All Known Lifeforms, UC Berkeley
Lines: 37
Message-ID: <2dleb8$2io@agate.berkeley.edu>
NNTP-Posting-Host: soda.berkeley.edu

Several people mailed me to remind me that I had said in the original round
2 posting that I would be lenient regarding input/output locations.  However,
I feel, like everyone who mailed me, that programs really should be
able to handle all possible input numbers, from 2 to 7999.  That's right,
your program has to be able to factorize 7999.  There are several programs
which were submitted to me which cannot handle 7999.  My advice to their
authors: start rewriting quick!  I think that a week is not an unreasonable
time limit for this, but, as always, I will be flexible about time.

To date, I have received entries from the following people (a star by your
name means that your program doesn't handle 7999 and must be rewritten,
a question mark means that I don't know if your program works with all
numbers):

    Alex MacAulay    *
    Timothy Laswell  ?
    Fredrik Orhstrom
    Anders Ivner     ?
    P. Baillargeon   ?
    Mintardjo W.     *
    Nandor Sieben
    Campbell Fraser  ?
    J. Layland       ?
    Stefan Strack

If there's really no way for you to make your program conform, well... I'm
very sorry and all that, but what can I do?  It really is a little unfair to
ask for me not to test a perfectly valid number.

Also, I have found the ten numbers I am going to use to test your programs.
Five of them display specific qualities; the other five are random.  I think
that this is a fair way to test these programs.
-- 
                      - Michael Constant
			mconst@soda.berkeley.edu

GM/CS d? p c++(++++) l u(++) e(*) m++ s--/- !n h f+ g+ w+ t++(+++) r+@ !y


Article 2341 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!dunix.drake.edu!acad.drake.edu!pk6811s
From: pk6811s@acad.drake.edu
Subject: Re: Larger Coresizes, The Big Hill at stormking.com
Message-ID: <1993Dec2.142238.1@acad.drake.edu>
Lines: 17
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
References: <2dg5e0$jij@agate.berkeley.edu> <1993Dec1.081746.1@acad.drake.edu> <2ditkt$d24@agate.berkeley.edu> <1993Dec1.212541.10735@news.vanderbilt.edu>
Date: Thu, 2 Dec 1993 20:22:38 GMT

It would seem that in a large core, paper would have a great advantage.
A scanner would find it very difficult to cripple every single copy
before starting the core-clear.  And the core-clear would take so long
that a single copy of paper would have a chance to replicate before
being erased, even though it was slowed down by all the spl-jmp bombs.
Maybe :-)  Guess we'll find out.

Another thought occurs to me.  I don't really need to know the exact
size of the core to make an optimal program.  I just need to know
that certain small numbers are or are not factors of the core-size.
If I know that 2,3,5,7,17,19 are factors, but 11 and 13 aren't, I can
safely use a selection of mod-x steps and launch a selection of spirals.
So maybe we could design a tournament where only the core-factors are
known but not the core-size.

Paul
pk6811s@acad.drake.edu


Article 2342 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!news.sprintlink.net!news.world.net!speedway.net!valhalla.stormking.com!corewar-l@stormking.com
From: JWOLF@corpus-0.ccc.ox.ac.uk
Newsgroups: rec.games.corewar
Subject: Re: Larger Coresizes, The Big Hill at stormking.com
Date: 2 Dec 1993 19:43:19 -0500
Organization: Storm King Ind. Inc.
Lines: 25
Sender: server@valhalla.stormking.com
Distribution: world
Message-ID: <245BC92774B@corpus-0.ccc.ox.ac.uk>
Reply-To: corewar-l@stormking.com
NNTP-Posting-Host: stormking.com
Originator: corewar-l@stormking.com
X-Mailer: Pegasus Mail v2.3 (R4).

> Date:          Thu, 2 Dec 1993 01:15:11 -0500
> Reply-to:      mconst@soda.berkeley.edu
> From:          mconst@soda.berkeley.edu (Michael Constant)
> To:            Multiple recipients of list <corewar-l@stormking.com>
> Subject:       Larger Coresizes, The Big Hill at stormking.com

> In article <1993Dec1.081746.1@acad.drake.edu>,  <pk6811s@acad.drake.edu> wrote:
>
> >I'm hoping that a self-repairing program (Bunker) can survive in
> >the larger core, since it will be much harder to locate both partners.
> >Large core-size might prove to be the bane of stand-alone single-process
> >programs.
> Also, BTW, paper will be almost unaffected in the big coresize.  It will be
> marginally harder to find by scanners, but all modern paper gets rid of the
> scanners beforehand anyway.
Actually that's a problem I've been facing and I wondered if you
could help me. What is the optimal program to take out scanners as
seen in profusion on the '94 hill? Can you or anyone else post some
example code - I am surely not the only one who is interested in
tailoring offense to the opponent's weaknesses. My anti-vamp program
while causing 95% death to vampires, and doing well against stones
simply flops against scanners. I can tell that its not a vampire or
stone - I just wondered what the best strategy was in response?
Jonathan



Article 2343 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!news.sprintlink.net!news.world.net!speedway.net!valhalla.stormking.com!corewar-l@stormking.com
From: Michael Constant <mconst@soda.berkeley.edu>
Newsgroups: rec.games.corewar
Subject: Re: Larger Coresizes, The Big Hill at stormking.com
Date: 2 Dec 1993 19:43:27 -0500
Organization: Storm King Ind. Inc.
Lines: 13
Sender: server@valhalla.stormking.com
Distribution: world
Message-ID: <199312021839.KAA03698@soda.berkeley.edu>
Reply-To: corewar-l@stormking.com
NNTP-Posting-Host: stormking.com
Originator: corewar-l@stormking.com

Well, it depends on how long it takes your program to realize that it's facing
a scanner.  If you can find out within very few cycles, then you will be able
to launch, say, a quick mod-10 bomber to get rid of any pesky scanners.  Or,
you could use a Flash Paper-type quickscan to get rid of scanners.  You can
implement a one-shot DAT-scanner in very few lines.  However, if your program
takes a while to figure out that it's up against a scanner, then there really
isn't much that you can do.  I suppose that the best would be to start a stone
with a really good core-trasher (that is, lots of decrements and DJN-trains).
Hopefully it would keep the scanner distracted long enough to kill it.

                      - Michael Constant

P.S.  What does your program do vs. replicators and imps?


Article 2345 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!dunix.drake.edu!acad.drake.edu!pk6811s
From: pk6811s@acad.drake.edu
Subject: On beating scanners, scanner vs. stone, large core sizes
Message-ID: <1993Dec3.085931.1@acad.drake.edu>
Lines: 74
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
References: <245BC92774B@corpus-0.ccc.ox.ac.uk>
Date: Fri, 3 Dec 1993 14:59:31 GMT

In article ... JWOLF@corpus-0.ccc.ox.ac.uk writes:
> Actually that's a problem I've been facing and I wondered if you
> could help me. What is the optimal program to take out scanners as
> seen in profusion on the '94 hill? Can you or anyone else post some

A simple 3-line bomber should beat a scanner about 90% of the time.  No
core-clear is required :-)  A self-splitting stone with core-clear should
do almost as well.

In Flash Paper, Matt Hastings started a stone to run in parallel with
his replicators.  He remarked to me once that while it didn't actually
clobber scanners it did pick up a few points that way.  In Smooth Noodle
Map, he ran the stone for a while before starting the replicators, which
scores much better against scanners, but less against other replicators
and, I guess, spirals.  Mintardjo did something like that in 
Gamma Paper, letting a mod-10 bomber clear out the scanners before starting
the paper.  My Vagabond is along those lines also.  Did I post Vagabond?
I don't remember.

Layland's Fly Paper used a short cmp-scanner which located and dat-bombed
one location before starting paper.  I think it did well against some
of the scanners.

The problem with scanners is that they start very fast and run very fast.
The first time they hit part of your program you immediately begin to
slow down.  So if you are facing a scanner you can't afford to put off
dealing with it, your anti-scanner code must be the first (after booting)
phase of the program.  Then determine how much time you spend in that
phase before starting the next phase, 'cause if your opponent is something
other than scanner you need to move on before all your replicators or
whatever are crippled.

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

Stefan's remark about scanners running faster than stones is true enough.
Though it seems that a self-splitting stone should bomb/decrement at
66% of c, just like a scanner, it doesn't happen that way.  The processes
run slightly out of sync and sometimes bomb the same location twice in
succession.  Also, the decrement may have no crippling effect on certain
parts of a cleverly designed opponent.

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

Another problem in a large core for paper, at least the kind that doesn't
increment its next-location pointer between copies, will be the vast
wastage of cycles due to overwriting copies.  Even in 8000 core most
paper leaves a lot of holes when time runs out.  A new strategy might
be to use a fast copier to seed the core with replicators, then start them.
Something like this:

start   spl 1
        spl 1
        spl 1
c1      mov <copyf,<(start*500)
c2      mov >copyf,>(start*500)
c3      mov <copyf,<(start*500)
c4      mov >copyf,>(start*500)
        ...                ; make more copies
        spl (start-c1)*500-8
        spl (start-c2)*500
        spl (start-c3)*500-8
        spl (start-c4)*500
        ...                ; start more copies

paper   mov #8,0           ; 8-process paper
        ...

copyfr  dat #0

Hey!  If anyone has a palindrome version of paper, it would be very
handy under the '94 standard :-)

Paul Kline
pk6811s@acad.drake.edu


Article 2346 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!soda.berkeley.edu!mconst
From: mconst@soda.berkeley.edu (Michael Constant)
Newsgroups: rec.games.corewar
Subject: MNCT Round 2 Again
Date: 3 Dec 1993 19:24:08 GMT
Organization: Society for the Destruction of All Known Lifeforms, UC Berkeley
Lines: 13
Message-ID: <2do3oo$ouf@agate.berkeley.edu>
NNTP-Posting-Host: soda.berkeley.edu

I don't know what to do about the "non-conforming" programs for round 2.
As Stefan pointed out to me, 1) it's difficult/impossible to adapt certain
algorithms to handle numbers near coresize, and 2) if I postpone round 2
any more, it will begin to get intolerable.  So, I will be nice :-)  If your
program doesn't work with large numbers, don't fear, I won't test any number
above 7997.  (As I remember, all programs worked up to 7997.)  I will run
the tournament the instant I finish posting this article.  Sorry if I made
anyone attempt impossible modifications to their program.
-- 
                      - Michael Constant
			mconst@soda.berkeley.edu

GM/CS d? p c++(++++) l u(++) e(*) m++ s--/- !n h f+ g+ w+ t++(+++) r+@ !y


Article 2347 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: _The_Big_Hill_ is online
Message-ID: <1993Dec3.204805.25356@news.vanderbilt.edu>
Sender: news@news.vanderbilt.edu
Nntp-Posting-Host: necs.vuse.vanderbilt.edu
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: Fri, 3 Dec 1993 20:48:05 GMT
Lines: 20


After an overwhelmingly positive response, here it is: The Big Hill at
stormking.com. In case you missed my earlier post, these are the rules:

coresize=55440
max. processes=10000
cycles until tie=500000
max. prog. length=200
min. prog. distance=200
standard: ICWS'94 draft

pMARS switches (+32 bit only): -s 55400 -p 10000 -d 200 -l 200 -c 500000

Mail your warrior to koth@stormking.com with
;redcode-94X
as the first line. Don't get impatient if you don't get results back imme-
diately: first, stormking.com is a UUCP-site with feeds twice a day; second,
battles may take more than 6 times longer due to the higher cycles limit.

See you there, Stefan (stst@vuse.vanderbilt.edu)


Article 2349 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!library.ucla.edu!europa.eng.gtefsd.com!uunet!newsflash.concordia.ca!sifon!broue!bleumont
From: bleumont@rot.qc.ca (Bleumont)
Subject: Re: MNCT Round 2 Rules
Message-ID: <CHHoBt.6w2@rot.qc.ca>
Organization: Groupe de Recherche Operationnelle en Telecommunication (ROT) Inc.
X-Newsreader: TIN [version 1.2 PL2]
References: <2c729v$fkg@agate.berkeley.edu> <CGvABE.1ro@rot.qc.ca> <2cp4c7$mhc@agate.berkeley.edu> <CH660t.Ipq@rot.qc.ca> <2dg5vu$jok@agate.berkeley.edu>
Date: Sat, 4 Dec 1993 02:31:04 GMT
Lines: 72

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

[me ranting about not getting favor for round 2 :)]

: This is a type of problem that has occured quite a bit with round 2 submiss's
: That is, people ask for a slight bending of the rules (different input
: location, different output location, me not using certain input numbers (!),
: etc.) and I'm not sure whether to grant them these changes to the original
: rules.  I'm afraid that if I do, then people with legitimate programs will
: feel cheated.  But if I don't, then the people requesting these changes will
: have to do, in some cases, an awful lot of recoding.  Any opinions?

At least, it more fair that way for all.  And since the submission date has passed,
I can freely divulgate my original design, which needs to get the prime as a
negative number and works `only' for the 1-7950 range.  Only 17 instructions
long with a best case around 300 cycles, worst around 70000 (for 89 * 89).
I had a version 1 instruction longer with a best case of 1 (with 1 as input).

Anyway, here is the original (my submission is slightly different):


de
;name Promotion
;author Pierre Baillargeon

;strategy
;strategy We start with the number, and substract the current prime-divisor
;strategy until the result is lower than the current prime divisor.  While
;strategy doing it, mark the memory with #1 so we can generate the new prime-
;strategy divisors at the same time.  This as the advantage of not having to
;strategy keep a table of divisors in the code (would use 24 locations) nor
;strategy having to compute them before-hand for nothing.  But if number is
;strategy too large, we modify ourselves (oups !).
;strategy
;strategy The calculation loop is four instructions long, which i believe
;strategy would be hard to beat (but not impossible, would make program
;strategy longer though).
;strategy
;strategy If the result of the substract loop is zero, we have found a
;strategy divisor, so keep it and re-use it again.
;strategy
;strategy If the result is non-zero, scan the marked memory, beginning
;strategy at the current prime-divisor to find the new prime-divisor.
;strategy

keep    equ bottom+20      ; where we keep the factors, if any
test    equ top-1          ; pointer for numbers and prime markers
number  equ bottom+2       ; we keep the number there

top
found   sub div,<keep      ; keep track of this good division
new_num mov div_res,number ; use division result as new number
n_found mov #-1,div_res    ; initialize, result of division to one
        mov #0,test        ; init marker
mark    sub test,@test     ; mark mem location as a non-base-prime
        add div,test       ; substract prime-divisor from marker pointer
        slt number,test    ; verify test >= number
div_res jmp verify,#-6479  ; yes -> verify if exact multiple
        djn mark,div_res   ; no -> increase quotient and loop
verify  sub number,test    ; verify equality
        jmz found,test     ; yes -> found a factor !
        mov div,test       ; no, find new prime-divisor
search  jmn search,<test   ; @--pointer, non-zero -> keep searching
        mov test,div       ; keep new prime-divisor
        djn n_found,#24    ; if more than 24 divisors, number is prime
        sub number,<keep   ; keep number as divisor and die
div     dat #0,#-2         ; initial prime divisor
bottom

        end new_num

Own thought, own responsability.


Article 2352 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!soda.berkeley.edu!mconst
From: mconst@soda.berkeley.edu (Michael Constant)
Newsgroups: rec.games.corewar
Subject: MNCT Round 2 Results
Date: 6 Dec 1993 05:59:11 GMT
Organization: Society for the Destruction of All Known Lifeforms, UC Berkeley
Lines: 50
Message-ID: <2duhnf$brm@agate.berkeley.edu>
NNTP-Posting-Host: soda.berkeley.edu

              ------------------------------------------
              -    Michael's New Corewar Tournament    -
              -                                        -
              -           Round 2 Results              -
              ------------------------------------------
 
Finally, the results for round 2 are here!  As with round 1, I will present
the scores now, with analysis to follow as soon as I can manage it.
 
Rank Name                       Author         Length   Av. Time    Score
-----------------------------------------------------------------------------
  1  Fast Factors 5           Anders Ivner       22        7514      51514
  2  Factor-14                Stefan Strack      14       27166      55133
  3  Prime Factory            Alex MacAulay      20       19032      59032 *
  4  Factor 6b                J. Layland         26        9078      61078
  5  FactorIt                 Na'ndor Sieben     21       21156      63156
  6  Prime, Bonus and Big Bucks  P. Baillargeon  22       22842      66842 
  7  No Name                  Timothy Laswell    34       20666      88666
  8  Comprisation             Campbell Fraser    15       88676     118676
  9  The Prime Time Killer    Fredrik Ohrstrom   54       28069     136069
 10  PNF 2                    Mintardjo W.       54      103645     211645 *
                                                                 
(*) means incorrect and will be fixed.  For Prime Factory, there is a problem
with a certain number; that score has been discounted (for now).  For PNF 2,
Mintardjo sent me a new version (PNF 3) which arrived just as I was typing
this list, and I haven't tested the new version yet.
 
Remember that scoring is (2000*length) + cycles, averaged over ten different
test numbers.  They are as follows, along with their prime factorizations
and why I chose them:
 
  75   = 3.5.5             (few small factors)
  4860 = 2.2.3.3.3.3.3.5   (lots of small factors) 
  4501 = 7.643             (small and big factors)
  7993 = 7993              (big prime)
  23   = 23                (little prime)
  1182 = 2.3.197           (random)
  7156 = 2.2.1789          (random)
  4646 = 2.23.101          (random)
  1709 = 1709              (random)
  6765 = 3.5.11.41         (random)
 
I would not be surprised if I made a few mistakes calculating the scores; if
you would like to retest your program please go ahead and let me know what
results you get, if they differ from mine.
-- 
                      - Michael Constant
			mconst@soda.berkeley.edu

GM/CS d? p c++(++++) l u(++) e(*) m++ s--/- !n h f+ g+ w+ t++(+++) r+@ !y


Article 2357 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!olivea!sgigate.sgi.com!sgiblab!cs.uoregon.edu!news.uoregon.edu!gaia.ucs.orst.edu!news.csos.orst.edu!CSOS.ORST.EDU!wangsawm
From: wangsawm@CSOS.ORST.EDU (Mintardjo W.)
Newsgroups: rec.games.corewar
Subject: PNF 3
Date: 12 Dec 1993 06:02:49 GMT
Organization: CS Outreach Services, Oregon State University, Corvallis, OR, USA
Lines: 144
Message-ID: <2eec69$alc@jadzia.CSOS.ORST.EDU>
NNTP-Posting-Host: csos.orst.edu

Here is the way I did with prime number factorization:

PNF 3. Worst cycle around 9970 (prime #7793).

The algorithm description can be found at the end of the code.

Enjoy,
Mintardjo W.

==============================================================================

;redcode
;name PNF 3
;author Mintardjo W.

s1      equ 16
s2      equ s1

copy    equ (input - 1)
out     equ (copy - 1)
posn    equ (out - s1 - 1)      ; this holds the current prime number
i       equ (input - 25)
j       equ (i + 4000)
prime   equ (i - 1)             ; this holds the first prime number
dst     equ (last + s1)
src     equ (dst + 1)
sdst    equ (src + s1)

input   dat #-3          ; please put input here

nprime  dat #prime

;start  jmz last, input
;trace
start   mov #2, prime    ; the first prime starts with 2
;trace off
        mov #1, posn     ; the next starts with 3 - 2. -2 for adjustment
;       mov #0, out

mark0   mov #s1, src
        mov @nprime, <src
        mov #s1, dst
fill    mov #0, <dst      ; fill with numbers: a, a^2, ... a^n until
        mov @nprime, copy ; (n = s1) or (a^n > input)
loop1   add @src, @dst
        slt @dst, @src
        djn loop1, copy

        slt @dst, @src   ; check for overflow
        djn fill, src    ; and src should be decremented as well

        mov #0, @dst     ; mark the max number at the end
        mov input, copy  ; do not alter the input value at input variable
        mov #s1+(sdst-dst), dst

loop2   mov #0, sdst
loop3   slt copy, <sdst
        jmn loop3, @sdst
        sub #-1, sdst
        jmz mark2, sdst  ; if it is, then the remaining is even smaller than
                         ; the base prime which indicates the indivisibility
        sub @sdst, copy  ; get the remainder
        mov sdst, <dst   ; record the exponent. leave it in negative number
        jmn loop2, copy  ; if the result > 0 then reiterate

loop4   sub @dst, 0      ; negate the negative exp number
        add @nprime, <out      ; get the divisor
        djn -1, loop4    ; as many as the positive exponent

; Gets the quotient

        mov #0, input    ; Reset the input
                         ; The order of src & dst, helps to add 1
                         ; which is the self-division of last term ...
        mov #s1+(sdst-src), src
mark1   sub @dst, <src   ; divide each term by subtracting
                         ; the exponent
div2    mov @src, sdst   ; get the index
        add @sdst, input ; to get the right term and add it to input
div3    jmn mark1, @src  ; reiterate until the last sequence of term
        jmz last, input  ; if what's left is only the last term,
                         ; then we are done
        sub dst, input   ; add the quotient from self-division
        add src, input   ; adjust the offset
        sub #(dst-src)-1, input

; This performs the sieve of Erasthosenes

mark2   mov #prime-i, i  ; i, j are parallel variables
        mov #prime-i, j
        mov #0, mark3
        add #2, posn

loop6   jmz mark3, <i    ; assume the rest of the core is 0 b-field
        cmp posn, <j
        jmp loop6

        add @i, @j
        add @i, @j
        jmp loop6, <mark3

mark3   jmn mark2, #0
        mov posn, <nprime ; record the base prime
        mov posn, <j
        add posn, @j
        add posn, @j      ; record the next multiple of base prime. Ignore 2x

        slt #89, posn     ; if greater than 89, whatever input is prime
                          ; because 89 is the upper bound for 8000
        jmp mark0
        mov input, <out

last    end start

==============================================================================

1. Create a table constituting geometric series: a', a'^2, a'^3, ... a'^n
   where a' is a' base prime number. a'^n < 8000
2. Find in this table the largest number which is less or equal to input.
   Record its exponent. Subtract input with the number and redo step 2 until
   input is smaller than the base prime number.
   In general: I = a'^i + a'^j + ... + a'^k + C.
   C should be smaller than input. If C = 0, then the number is divisible by
   that prime number. The next step is 3.
   If C <> 0, then the number is not divisible by current base prime number,
   jump to step 4.
3. Get the quotient.
   The representation of I should be:
   I = a'^i + a'^j + ... + a'^k
   Find in this exponents, the smallest exponent.
   Then for every term, subtract it with the smallest exponent.
   Let's say a'^k is the smallest term, then.
   I / a'^k = a'^(i-k) + a'^(j-k) + ... + 1
   The right hand equation is the quotient of the input divided by the prime
   number. If the sum in right hand equation = 1, then I = a'^k and we are
   done.
   Record a' as many as k in the output.
4. This step is to find the next prime number. I used a modified version of
   sieve of Erasthosenes. Once a prime number is found and if it is less than
   90, then repeat step 1. Otherwise, record the prime in output and stop.

   In PNF 2, I didn't limit the number of base prime number to be searched 
   and the result was pretty amazing a large number of average cycle.



Article 2358 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!caen!usenet.cis.ufl.edu!eng.ufl.edu!spool.mu.edu!howland.reston.ans.net!pipex!sunic!liuida!curofix!d91andiv
From: d91andiv@IDA.LiU.SE (Anders Ivner)
Subject: Fast Factors 5
Message-ID: <D91ANDIV.93Dec14200635@kol5.IDA.LiU.SE>
Sender: news@ida.liu.se
Organization: CIS Dept, University of Linkoping, Sweden
Distribution: rec
Date: Tue, 14 Dec 1993 19:06:41 GMT
Lines: 78

Here's my solution to the factorization problem.

Worst time: ~8200 cycles   (89*89)
Average time: ~7500 cycles
Best time: ~6700 cycles    (2)

The program is based on a faster division algorithm than the simple
loop most people seem to have used (?). My first version included a
table of all primes < 90, and several checks to speed up the execution,
which resulted in a worst case time of ~2000 cycles. After that, I
optimized only for size, at the cost of speed. I removed the primetable
and as many checks as possible (Hence the long best-case time).

Some explanations:

np is a list of multiples of the current factor (2^n * f < 4000).
q is a pointer to the quotient. I can save one instruction by using
  an unused b-field to change the pointer, rather than MOVing #0.
x is the number to be divided, a copy of input.

The code can be divided into four 'parts':

lines foo - yes+3     : Initialize division algorithm.
                        Create 2^n * f.
lines shift - prev+2  : Division algorithm
lines found - found+1 : Last division succeded, store results.
lines next - next+3   : Division failed, try next number.

/Anders Ivner

BTW: Stefan, how did you manage to get it down to 14 instructions??
I tried writing one a short as possible (totally ignoring speed), but
never got it below 16 instructions.

;redcode
;name Fast Factors 5
;author Anders Ivner

np      equ     yes+4000
q	equ	yes+7500
x	equ	yes+1000

input   dat             #2

;dividable
found   mov     factor,         <results
        mov     @q,             input

foo     mov     factor,         <np
        mov     input,          x

yes     mov     @np,    <np             ; B-field = 4000
        add     @np,    @np             ;double it
        slt     yes,    @np             ;ok to double?
        jmp     yes,    <q              ;yes (set q to 0)

shift	add	@q,	@q
factor	jmp	lowp,	#2

subt    sub     @np,    x               ;subtract
        add     #1,	@q

lowp    slt     x,      @np             ;ok to subtract?
results jmp     subt,   #input          ;yes

prev    add     #1,     np              ;previous multiple
	jmn	shift,	np		;if pt=0 then we're done
	jmz	found,	x

;not dividable
next	add	#1,		factor
        djn     foo,            #88
        cmp     #1,             input
        mov     input,          <results

        end     foo

; 22 instructions


Article 2359 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!jlayland
From: jlayland@kilroy.jpl.nasa.gov (James Layland)
Newsgroups: rec.games.corewar
Subject: Factor6b
Date: 15 Dec 1993 23:09:27 GMT
Organization: Jet Propulsion Laboratory, Pasadena, CA  USA
Lines: 70
Message-ID: <2eo5f7$b6o@elroy.jpl.nasa.gov>
NNTP-Posting-Host: 128.149.63.2

Well, my entry was too slow to be the fastest, and much too long to be
the shortest.  My program divided by 2 and all odd numbers.  The time
for divisions was cut roughly in half by subtracting 2*F until the last
iteration.  The division loop was shortened to 3 instructions by 
accumulating the quotient in the A-field.  Unfortunately, each of these
modifications added substantially to the code length.  The worst case
execution time is roughly 29k cycles.  In more detail, algorithm is:

Current factor is F, current number to factor is N
1) add current factor (1,F) to itself to get (2,2F)
2) move N to scratch location test = (0,N)
3) subtract (2,2F) from test until B-value of test <2F
4) subtract (1,F) from test if necessary to make B-value of test <F
5) if B-value of test==0, we found a factor, go to step 8
6) if factor==89, N is prime: save it and exit
7) find next test factor; this adds 1 on first iteration, 2 afterwards
8) now test = (-A,0); N = A*F; save F in factor table, then jump through
hoops to extract A-number and save it as new N
9) If N==1 then exit, else return to step 3

num  equ 4501
factor2 equ loop+4000

first	
x   	dat #num		; input number

tmp	sub #0, x-tmploc

next1	sub #1, factor
	add #next-next1, jptr
next	add #2, factor		; try next possible factor
start	mov factor, factor2
	add factor2, factor2    ; divide by 2F, then divide remainder by F
again   mov x, test
	slt test, factor2	; this line necessary for small prime factors
loop    sub factor2, test	; "division" by 2F loop
	slt test, factor2
loc	jmp loop, first		; keep subtracting	
	slt test, factor	; test is x % 2F
	sub factor, test 	; now test = x % F
	jmz found, test		; remainder ==0, found factor
	cmp #89, factor
jptr	jmp @0, next1
	mov x, <loc		; x is prime, save and die

factor	dat #1, #2		; current factor to try
	
found	mov factor, <loc	; save factor
	mov #0, x
	mov tmp, tmploc
	add test, tmploc
tmploc	sub #0, x
	cmp #1, x		; if x==1 we're done, so die
 	jmp again		; recheck same factor
	  	
test	end start
 

BTW, Anders, I wrote a factoring program which is only 14 instructions
long; unfortunately the worst case times are about 280k cycles (it
divides by every number up to N, which takes forever for large primes).




-- 
James Layland
jlayland@grissom.jpl.nasa.gov

I don't even speak for myself.


Article 2360 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!soda.berkeley.edu!mconst
From: mconst@soda.berkeley.edu (Michael Constant)
Newsgroups: rec.games.corewar
Subject: MNCT Delayed :-(
Date: 16 Dec 1993 05:00:10 GMT
Organization: Society for the Destruction of All Known Lifeforms, UC Berkeley
Lines: 32
Message-ID: <2eoq0q$s5a@agate.berkeley.edu>
NNTP-Posting-Host: soda.berkeley.edu

I'm sorry to say this, but just as finals end (oh joy!) I'm going on vacation
and I won't have access to the internet.  Thus round 3 (and a little cleaning
up of round 2) will have to be delayed :-( .  However, so as not to put the
tournament on hold completely, I am going to wimp out for round 3 and call it,
as Stefan said (he gives me a lot of good ideas!), "an unknown coresize round
robin."  That's right, you just write any 94 program you want, and it will be
run in some coresize against all other submissions.  There will be no
restrictions on the coresize: it might be prime (which would mean that all
patterns are mod 1), it might be prime-1 (which would mean no imps), it might
be wildly composite.  Oh, but it will be <= 8192.  You will not know in advance
what the coresize will be.
And I don't care what all you fairness people say, I am not running this round
in 20 different coresizes.  Maybe something a little more reasonable, like 3.
Suffice to say, your program must be able to function well in a variety of
coresizes. Of course, one might be tempted to simply write a replicator, but
it's not that hard to write a reasonable good scanner in unknown coresize.
And there are other ways to beat replicators (e.g. vampires, imps (for a tie),
spl-jmp bombers, spl-bombers, etc.)

BTW, I leave for vacation on Friday so I won't be able to respond to anything
you e-mail me or post here after that date.  I should be back around January
4 or 5.  However, if anyone has a good idea for this round that they'd like to
tell me about, why not discuss it in this newsgroup and let me know what
popular opinion is like when I get back?

Sorry again about all the delays, and thank you to everyone who has been
participating in this tournament!
-- 
                      - Michael Constant
			mconst@soda.berkeley.edu

GM/CS d? p c++(++++) l u(++) e(*) m++ s--/- !n h f+ g+ w+ t++(+++) r+@ !y


Article 2365 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!cs.utexas.edu!utnut!utcsri!newsflash.concordia.ca!sifon!broue!rot.qc.ca!bleumont
From: bleumont@rot.qc.ca (Bleumont)
Subject: My MNCT 2 warrior
Message-ID: <CIF5BK.1po@rot.qc.ca>
Sender: newsadm@rot.qc.ca (News Administrator)
Nntp-Posting-Host: localhost
Organization: Groupe de Recherche Operationnelle en Telecommunication (ROT) Inc.
X-Newsreader: TIN [version 1.2 PL2]
Date: Wed, 22 Dec 1993 04:18:55 GMT
Lines: 77


;redcode
;name Prime, bonus and big bucks
;author Pierre Baillargeon

;strategy	Load this program at address 500 to make the result fall in
;strategy	the range 7999-7900.


;strategy	The base idea is to use negative numbers.  We can thus take
;strategy	advantage of all the decrease side-effects of MARS-88.  The
;strategy	second idea is the technique to store base-prime in the
;strategy	B-field of the code.  We can therefore calculate the prime-
;strategy	factor at the beginning with very few instructions.
;strategy
;strategy	We use a small substract loop to calculate the division.
;strategy	If the result of the substract loop is zero, we have found a
;strategy	factor, so keep it and re-use it again.
;strategy
;strategy	If the result is non-zero, scan the marked memory, beginning
;strategy	at the current prime-factor to find the new prime-factor.
;strategy
;strategy       Now that I've seen some others, I understand that my downfall
;strategy       is the LOOOONG time it takes to compute division of small
;strategy       primes (2 takes 4000 loops !).
;strategy

bottom	equ next		; last instruction
top	equ base
pprime	equ top-1		; used to erathostene-out prime numbers
result	equ top-500		; where we save factors
number	equ bottom+1		; where the number will be stored as a negative
test	equ bottom+2		; number is temporary stored during calculation

base	mov #5,0		; init the loop count
primes	mov @base,pprime	; (-2) mark the location as non-prime
prime	add @base,pprime	; (-3) move back by the amount of base-prime
	mov #-1,@pprime		; (-4) tag number as non-prime
	cmp #-420,pprime	; (-5) stop at 420 (3 x 4 x 5 x 7)
	jmp prime,-7		; (-7) redo mark loop
	djn primes,base		; do all the base-prime
	mov #-2,pprime		; begin dividing with first factor: 2
	sub #0381,number	; *** place the nymber in the A-field ***

calc	mov number,test		; get number ready for test
CPU	jmz found,test		; if zero, found factor
	sub pprime,test		; substract current divisor
	slt pprime,test		; test < pprime -> new divisor
	djn CPU,@quot		; increase quotient

new_div	jmn new_div,<pprime	; search new divisor
	djn next,#24		; make sure we only use the 24 prime divisors
	sub number,<result	; number itself is prime, save it
quot	jmp number,500		; stop

found	mov @quot,number	; use quotient as new number
	sub pprime,<result	; save factor
	cmp #-1,number		; if number is 1, stop.
next	jmp calc,<quot		; next calculation, same factor

	end top


--
Own thought, own responsability.
dak, bizz, andre, etc...                         AKA bleumont@broue.rot.qc.ca
-----
(by )
-----
C. Surprenant / A. Hebert | Synerlogic (a Anderson Consulting Division)
                          | 1405 Trans-Canada, Suite 300     Voice: 514-685-7575
Consultants for Synerlogic| Dorval, Qc, Can H9P 2V9          Fax:   514-685-7692
      and (part-time)     |
NNAdmins for R.O.T        | Recherche Operationelle en Telecommunication
                          | 5867 De La Roche                 Voice: 514-948-2492
newsadm@rot.qc.ca         | Mtl, Qc, Can, H2S 2C8            IP:   192.77.49.131
-----


Article 2366 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!dunix.drake.edu!acad.drake.edu!pk6811s
From: pk6811s@acad.drake.edu
Subject: Eliminating Spirals?
Message-ID: <1993Dec22.161535.1@acad.drake.edu>
Lines: 10
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
Date: Wed, 22 Dec 1993 22:15:35 GMT

Someone, I think Michael, made the comment that using a coresize of
prime-number minus 1 would eliminate spirals.  This is not true.

A coresize of 52 (53-1) has a three-point spiral using MOV 0,35.

If coresize is M, then spirals can be found by finding factors of M*N+1,
where N is any integer.

Paul Kline
pk6811s@acad.drake.edu


Article 2368 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!microsoft!hexnut!jonn
From: jonn@microsoft.com (Jon Newman)
Subject:  ICWS Tournament -- win prizes!
Message-ID: <CIExKv.4KM@microsoft.com>
Organization: Microsoft Corporation
Keywords: ICWS tournament prizes
Summary: submit your entry now!
Date: Wed, 22 Dec 1993 01:31:40 GMT
Lines: 28

I will extend the deadline until Jan 15 1994.  Furthermore, I will not
enforce the requirement for ICWS membership this year: if you can read
this, you can enter!  As a special encouragement, the ICWS is offering
the following prizes:

1st place:  US$35
2nd place:  US$15
1st place through 3rd place:  1 year membership in ICWS

Rules:
ICWS '88 standard
100K cycles before tie
coresize 8192
maximum length 100 instructions
3 points for win, 1 for tie, 0 for loss

One entry per person.  Entries will be kept private until the
contest, but become public domain after that.  Send entries to:

Jon Newman
Director, ICWS
jonn@microsoft.com
13824 NE 87th Street, Redmond, WA 98052-1959

-- 
jonn@microsoft.com    

This is not the official opinion of Microsoft Corporation.  Bill Rules!


Article 2375 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!peruvian.cs.utah.edu!bdthomse
From: bdthomse%peruvian.cs.utah.edu@cs.utah.edu (Brant Thomsen)
Subject: Fast Food v2.1 (Source)
Date: 31 Dec 93 17:11:46 MST
Message-ID: <1993Dec31.171146.19033@hellgate.utah.edu>
Originator: bdthomse@peruvian.cs.utah.edu
Organization: University of Utah CS Dept

Fast Food is a standard vampire with a CMP scanning bomber tacked onto the
front of it.  The CMP scanning appears to have little effect against most
programs, although it does help against large programs.

It took some fiddling around to figure out how to have the scanner
move a fang (JMP bomb to the pit) once it had found something.  If the current
'94 draft falls through, there are two things it can do that I have found 
"essential":  post-increment, and the ability to move the B-field value of one 
instruction to another instruction without also affecting the second
instruction's A-field value.  This second ability would have made the scanner
for Fast Food less confusing, and is essential for a couple of scanners I 
have been fiddling with.

The vampire used in Fast Food is an exact copy of the one used in 
Distance 8.0.  I found that by moving the pit closer to the vampire,
I tended to do better against optimal stones.  Like all of its ancestors,
this version bombs a large chunk of the core before hitting itself, 
then destroys the pit, leaving only a "wimp" running.
With the wimp as the only process, I can make it difficult
to find me, and kill most imp-spirals that might remain after the core-clear.

(Wimp:        A JMP 0, <-x instruction.

 Starvation:  When one program has used all of its processes, a SPL
              instruction cannot generate a new process,
              and will simply act like a JMP 1 instruction.)

I've tried several variations on the vampire, but have yet to find one that
does any better.

;redcode
;name Fast Food v2.1
;author Brant D. Thomsen
;strategy Uses a CMP method similar to QuickFreeze, except
;strategy  uses fangs (JMP to pit) to bomb with.
;strategy When done, falls through to a "dumb" vampire.
;strategy  2.0 : Uses different Vampire
;strategy        Added boot-straping of vampire
;strategy  2.1 : Different imp-spiral protection
;strategy Submitted: @date@


; EQUs for CMP bomber

comp	equ	281+39	; Comparison distance
cdist	equ	189+26	; Core division
sdist	equ	250	; Distance from start for first comparison


; EQUs for vampire

step	equ	121
dist	equ	4000
init	equ	step
jsep	equ	7
sep	equ	1
wsep	equ	2
wgate	equ	11


mpit	mov	pit+3, pit+dist+3
	mov	pit+2, <mpit
	mov	pit+1, <mpit
	mov	pit, <mpit

top	cmp	top+sdist, top+sdist+comp
	mov	#-data+top+sdist, data
	cmp	top+sdist+cdist*1, top+sdist+cdist*1+comp
	mov	#-data+top+sdist+cdist*1, data
	cmp	top+sdist+cdist*2, top+sdist+cdist*2+comp
	mov	#-data+top+sdist+cdist*2, data
	cmp	top+sdist+cdist*3, top+sdist+cdist*3+comp
	mov	#-data+top+sdist+cdist*3, data
	cmp	top+sdist+cdist*4, top+sdist+cdist*4+comp
	mov	#-data+top+sdist+cdist*4, data
	cmp	top+sdist+cdist*5, top+sdist+cdist*5+comp
	mov	#-data+top+sdist+cdist*5, data
	cmp	top+sdist+cdist*6, top+sdist+cdist*6+comp
	mov	#-data+top+sdist+cdist*6, data
	cmp	top+sdist+cdist*7, top+sdist+cdist*7+comp
	mov	#-data+top+sdist+cdist*7, data
	cmp	top+sdist+cdist*8, top+sdist+cdist*8+comp
	mov	#-data+top+sdist+cdist*8, data
	cmp	top+sdist+cdist*9, top+sdist+cdist*9+comp
	mov	#-data+top+sdist+cdist*9, data
	cmp	top+sdist+cdist*10, top+sdist+cdist*10+comp
	mov	#-data+top+sdist+cdist*10, data
	cmp	top+sdist+cdist*11, top+sdist+cdist*11+comp
	mov	#-data+top+sdist+cdist*11, data
	cmp	top+sdist+cdist*12, top+sdist+cdist*12+comp
	mov	#-data+top+sdist+cdist*12, data
	cmp	top+sdist+cdist*13, top+sdist+cdist*13+comp
	mov	#-data+top+sdist+cdist*13, data
	cmp	top+sdist+cdist*14, top+sdist+cdist*14+comp
	mov	#-data+top+sdist+cdist*14, data
	cmp	top+sdist+cdist*15, top+sdist+cdist*15+comp
	mov	#-data+top+sdist+cdist*15, data

	jmn	done, data	; Quit early if found something

	cmp	top+sdist+cdist*16, top+sdist+cdist*16+comp
	mov	#-data+top+sdist+cdist*16, data
	cmp	top+sdist+cdist*17, top+sdist+cdist*17+comp
	mov	#-data+top+sdist+cdist*17, data
	cmp	top+sdist+cdist*18, top+sdist+cdist*18+comp
	mov	#-data+top+sdist+cdist*18, data
	cmp	top+sdist+cdist*19, top+sdist+cdist*19+comp
	mov	#-data+top+sdist+cdist*19, data
	cmp	top+sdist+cdist*20, top+sdist+cdist*20+comp
	mov	#-data+top+sdist+cdist*20, data
	cmp	top+sdist+cdist*21, top+sdist+cdist*21+comp
	mov	#-data+top+sdist+cdist*21, data
	cmp	top+sdist+cdist*22, top+sdist+cdist*22+comp
	mov	#-data+top+sdist+cdist*22, data
	cmp	top+sdist+cdist*23, top+sdist+cdist*23+comp
	mov	#-data+top+sdist+cdist*23, data
	cmp	top+sdist+cdist*24, top+sdist+cdist*24+comp
	mov	#-data+top+sdist+cdist*24, data
	cmp	top+sdist+cdist*25, top+sdist+cdist*25+comp
	mov	#-data+top+sdist+cdist*25, data
	cmp	top+sdist+cdist*26, top+sdist+cdist*26+comp
	mov	#-data+top+sdist+cdist*26, data
	cmp	top+sdist+cdist*27, top+sdist+cdist*27+comp
	mov	#-data+top+sdist+cdist*27, data
	cmp	top+sdist+cdist*28, top+sdist+cdist*28+comp
	mov	#-data+top+sdist+cdist*28, data
	cmp	top+sdist+cdist*29, top+sdist+cdist*29+comp
	mov	#-data+top+sdist+cdist*29, data
	cmp	top+sdist+cdist*30, top+sdist+cdist*30+comp
	mov	#-data+top+sdist+cdist*30, data
	cmp	top+sdist+cdist*31, top+sdist+cdist*31+comp
	mov	#-data+top+sdist+cdist*31, data
	cmp	top+sdist+cdist*32, top+sdist+cdist*32+comp
	mov	#-data+top+sdist+cdist*32, data
	cmp	top+sdist+cdist*33, top+sdist+cdist*33+comp
	mov	#-data+top+sdist+cdist*33, data
	cmp	top+sdist+cdist*34, top+sdist+cdist*34+comp
	mov	#-data+top+sdist+cdist*34, data

	jmz	mvamp, data	; Start Vampire if found nothing.

	; Put a fang in the A location of the successful scan

done	sub	data, fjump
data	mov	fjump, 0

	; Put a fang in the B location of the successful scan

	add	#comp, data
	sub	#comp, fjump
	mov	fjump, @data

	; Top the vampire.
	; Pit has already been moved

mvamp	mov	vamp+3, pit+dist+vamp-pit-sep+3
	mov	vamp+2, <-1
	mov	vamp+1, <-2
	mov	vamp, <-3

	mov	jump, pit+dist+vamp-pit-sep-1-jsep

mwimp	mov	wimp, pit+dist+vamp-pit-sep-1-wsep

	spl	@mvamp		; Start the vampire.
	jmp	@mwimp		; Start wimp

	; Jump used by the CMP scanner.

fjump	jmp	@-data, #pit+dist-data+1

	; Wimp is necessary so will still have a process when pit dies.

wimp	jmp	0, <wimp-wgate

jump	jmp	pit-vamp+sep-init, vamp+jsep+init

vamp	spl	0, <vamp-1-wsep-wgate
	mov	@0, @jump-jsep
	sub	pit+sep, @-1
	djn	-2, @jump-jsep

pit	mov	@step, <0-step
	spl	0, <vamp-1-wsep-wgate-sep
	spl	-1, <vamp-1-wsep-wgate-sep
	spl	-2, <vamp-1-wsep-wgate-sep

	end	mpit
-- 
Brant D. Thomsen			The teaching of BASIC in schools
bdthomse@peruvian.cs.utah.edu		should be considered a criminal act.
(University of Utah)						- Dijkstra


