Article 2653 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!overload.lbl.gov!agate!ihnp4.ucsd.edu!swrinde!sgiblab!sgigate.sgi.com!olivea!news.bu.edu!noc.near.net!news.delphi.com!news.delphi.com!not-for-mail
From: mmajorow@news.delphi.com (MMAJOROWICZ@DELPHI.COM)
Newsgroups: rec.games.corewar
Subject: Re: A tutorial full of code
Date: 1 Apr 1994 22:13:27 -0500
Organization: Delphi Internet Services Corporation
Lines: 14
Message-ID: <2ninsn$rve@news.delphi.com>
References: <MORRELL.94Mar29095146@glab1.math.utah.edu>
NNTP-Posting-Host: news.delphi.com

-----
It seems that everyone wants a corewar tutorial that shows how
incresingly complex warriors run.  Well... Okay, I will write one.
-----

I would like to see a set of "benchmark" redcode programs that a person
could judge their warriors against.  Maybe even sets of programs with
different levels of difficulty.

A novice has no idea how to choose a good set of programs to test
their warrior against.

Mike Majorowicz



Article 2654 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!news.byu.edu!news.mtholyoke.edu!nic.umass.edu!noc.near.net!news.delphi.com!news.delphi.com!not-for-mail
From: mmajorow@news.delphi.com (MMAJOROWICZ@DELPHI.COM)
Newsgroups: rec.games.corewar
Subject: More on beginner's hill
Date: 1 Apr 1994 22:29:45 -0500
Organization: Delphi Internet Services Corporation
Lines: 21
Message-ID: <2nior9$stb@news.delphi.com>
NNTP-Posting-Host: news.delphi.com

I've been giving some thought to the idea of a beginners hill.  I doubt
this is a practical idea, but I thought I'd toss it up anyway.

The biggest problem I see with a beginners hill is how to prevent it from
becoming a spot for the top ten programs to get pushed of the regular hill.

A solution to this problem may be to test a warrior against the 
current warriors from the regular hill first, and only allow warriors that 
score below 80% of the lowest score on the regular hill be submitted to the
beginners hill.  To prevent stagnation due to fluctuations in the scores
on the regular hill, the top warrior on the beginners hill could be 
automatically resubmitted once a week.

People with warriors on the regular hill should be automatically excluded
from the beginners hill.

If it turns out to be popular, you could even have different levels of
beginners hills, ie: a 60% hill, a 70% hill, etc.

Mike Majorowicz



Article 2655 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: Re: More on beginner's hill
Date: 2 Apr 1994 04:37:49 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 60
Message-ID: <2nisqt$41d@agate.berkeley.edu>
References: <2nior9$stb@news.delphi.com>
NNTP-Posting-Host: soda.berkeley.edu

MMAJOROWICZ@DELPHI.COM <mmajorow@news.delphi.com> wrote:
>The biggest problem I see with a beginners hill is how to prevent it from
>becoming a spot for the top ten programs to get pushed of the regular hill.

Do you mean "a spot for the top ten programs which got pushed off the regular
hill," i.e. people whose programs didn't make it onto the real hill would
submit them to the beginner's hill instead?  If so, I don't really think
that it would be a problem -- I think that most people know whether they
are "beginners" or not.  And if some program does too well on the
beginner's hill, we can kill it (automatically) and submit it to the real
hill (see below).

>A solution to this problem may be to test a warrior against the 
>current warriors from the regular hill first, and only allow warriors that 
>score below 80% of the lowest score on the regular hill be submitted to the
>beginners hill.  [...]

This sounds like it would put rather a lot of load on the server, testing
every program against two hills.  How about any program that does well
on the beginner's hill is automatically removed after (say) two weeks and
submitted to the regular hill.  This would effectively prevent the
beginner's hill from being overrun with good programs, which after all is
the point (so that beginners have a chance to get on).

>People with warriors on the regular hill should be automatically excluded
>from the beginners hill.

Of course.  As I said, I think people know if they qualify as beginners.

>If it turns out to be popular, you could even have different levels of
>beginners hills, ie: a 60% hill, a 70% hill, etc.

Hmmm.  IMHO, that's a little much -- after all, one hill has 20 spots, and
if good programs are routinely killed and submitted to the regular hill, then
there really wouldn't be much stagnation or anything... no, I think that one
beginner's hill would be enough.


Also, some general thoughts about a beginner's hill: I'm not so sure that it
would be a good idea in the first place.  I remember when I was just starting
to write corewar programs, I had a really horrible program (which of course
had taken lots of work, etc.) which I submitted to the hill with grand hopes,
and I was rather harshly disillusioned when I got the results back :-)
But maybe this is good.  After all, if I had submitted that program to a
beginner's hill and it had done well, then I would have tried to improve it
and make it as good as possible.  This development time would be wasted --
improving a really bad program because it did well on a beginner's hill.
(As a matter of fact, the program was a really primitive version of mice,
and I learned a lot by finding out that this approach had already been tried
and optimized far beyond what I could have done.)  So, instead of wasting my
time reinventing the wheel (as I would have been inclined to do had the
program succeeded on a beginners's hill) I scrapped the program and tried
other approaches, reading tutorials, etc. and finally produced a program
which made it onto 19th place on the hill or thereabouts.  But the point is,
if my program had gotten onto a beginner's hill, I think I would have spent
less time figuring out what I had done wrong.  Invention stops with success.
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2656 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!munnari.oz.au!news.uwa.edu.au!devink
From: devink@tartarus.uwa.edu.au (Devin Kilminster)
Newsgroups: rec.games.corewar
Subject: Re: More on beginner's hill
Date: 2 Apr 1994 13:06:33 GMT
Organization: The University of Western Australia
Lines: 21
Message-ID: <2njqkp$7c5@styx.uwa.edu.au>
References: <2nior9$stb@news.delphi.com> <2nisqt$41d@agate.berkeley.edu>
NNTP-Posting-Host: lethe.uwa.edu.au
X-Newsreader: TIN [version 1.2 PL2]

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

: which made it onto 19th place on the hill or thereabouts.  But the point is,
: if my program had gotten onto a beginner's hill, I think I would have spent
: less time figuring out what I had done wrong.  Invention stops with success.

This is a very good point.  However it must be said that another thing 
that stops invention dead in it's tracks is failure after failure - when 
your program is able to get onto hill it is very encouraging.

So rather than a beginner's hill, maybe we need a hill that is easy to 
get onto (so one can make ones mark) but still represents a wide range of 
difficulty, so that reaching the top is a real acheivement.

Perhaps a way to do this would be to limit each player to only one 
warrior at a time - everyone would have their best warrior on the hill 
and people would be able to see where they stand.


Devin Kilminster.



Article 2658 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!EU.net!sun4nl!hacktic!consolat.hacktic.nl!thegate.hacktic.nl!richard
From: richard@thegate.hacktic.nl (Richard van der Brugge)
Newsgroups: rec.games.corewar
Subject: Re: A tutorial full of code
Message-ID: <040194214432Rnf0.77b9@thegate.hacktic.nl>
Date: Fri, 01 Apr 1994 21:44:00 GMT
References: <MORRELL.94Mar29095146@glab1.math.utah.edu>
Organization: Consolation BBS / temp. system mismanagement
X-Newsreader: Rnf 0.77b9
Lines: 13

morrell@math.utah.edu (Steven C. Morrell) writes:

>To give the reader a sense of how effective each program is, I would
>also like to submit all of these sample programs to the Intel Hill.
>Does anybody object?

No, excellent idea!


__________________________________________________________________________
Richard van der Brugge     | BEWARE : I smoke and i use PGP, this makes
richard@thegate.hacktic.nl | me a criminal in The Netherlands and the USA
--------------------------------------------------------------------------


Article 2659 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: Re: More on beginner's hill
Date: 2 Apr 1994 20:39:51 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 34
Message-ID: <2nkl6n$4d4@agate.berkeley.edu>
References: <2nior9$stb@news.delphi.com> <2nisqt$41d@agate.berkeley.edu> <2njqkp$7c5@styx.uwa.edu.au>
NNTP-Posting-Host: soda.berkeley.edu

Devin Kilminster <devink@tartarus.uwa.edu.au> wrote:
>So rather than a beginner's hill, maybe we need a hill that is easy to 
>get onto (so one can make ones mark) but still represents a wide range of 
>difficulty, so that reaching the top is a real acheivement.
>
>Perhaps a way to do this would be to limit each player to only one 
>warrior at a time - everyone would have their best warrior on the hill 
>and people would be able to see where they stand.

Do you mean that the regular hill would only allow one warrior per person?
This is bad because it would discourage invention -- if I would have to kill
off my standard mediocre program to test a new strategy, I might be more
inclined to just improve my standard program and forget about the new
strategy.

However, a "beginner's" hill (we would need a new name) where anyone could
submit one and only one warrior would be a good idea, IMHO.  It would
represent a wide range of standard, tested, warriors and but would give
new people a chance to get on.  Unfortunately, it could get to the point
where the "beginner's" hill was just as overrun with really good warriors
as the regular hill, and so our poor J. Random Corewarrior will be doubly
disappointed when he can't make it onto *either* :-(

Maybe the best idea would be not a new hill but better tutorials (like the
proposed "tutorial full of code").  With enough help, even the newest of
newbies should be able to write a 20th place program.  And this would have
the advantage of not encouraging development of useless, old-fashioned
programs (see my last post on this thread).

Any other ideas, anyone?
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2660 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: The '94 Warrior
Date: 2 Apr 94 13:48:59 MST
Message-ID: <1994Apr2.134900.8347@hellgate.utah.edu>
Originator: bdthomse@peruvian.cs.utah.edu
Organization: University of Utah CS Dept

__ __| |            ) _ \  |  |    \ \        /              _)           
   |   __ \   _ \  / (   | |  |     \ \  \   / _` |  __|  __| |  _ \   __|
   |   | | |  __/   \__  |___ __|    \ \  \ / (   | |    |    | (   | |   
  _|  _| |_|\___|      _/    _|       \_/\_/ \__,_|_|   _|   _|\___/ _|   
                                                                          
April 2, 1994                                                         Issue #5
______________________________________________________________________________

This newletter covers the current status of the ICWS '94 Draft hills,
and also attempts to keep up with the latest ideas in how the new standard
will affect corewars in general.  I hope you enjoy it!

If you are unfamiliar with the '94 draft standard, you can learn more about
it by reading the FAQ for this newsgroup.  In addition, the program pMARS
includes a highly recommended tutorial on the new standard.  Feel free
to send me e-mail if you have any difficulty finding either of them, if you
need to have a corewar item mailed to you, or if you have any other questions.

The FAQ is available through anonymous FTP to rtfm.mit.edu, as
/pub/usenet/news.answers/games/corewar-faq.Z
______________________________________________________________________________

The ICWS '94 Draft Hill:

       Core size:	8000 instrucitons
   Max processes:	8000 per program
        Duration:	After 80,000 cycles, a tie is declared.
Max entry length:	100 instructions

The current ICWS '94 Draft hill:
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  42/ 31/ 27           Killer instinct         Anders Ivner     154      10
 2  38/ 24/ 38                     NC II       Wayne Sheppard     153      65
 3  38/ 25/ 37               Sphinx v5.1         W. Mintardjo     150      68
 4  32/ 22/ 46                    ttti94        nandor sieben     143      16
 5  43/ 44/ 13           Fire Storm v1.1         W. Mintardjo     142      71
 6  34/ 27/ 40        JustTakingALookSee            J.Layland     141      64
 7  31/ 22/ 47                      ttti        nandor sieben     140      21
 8  40/ 42/ 17            Sylvester v1.0     Brant D. Thomsen     139      47
 9  32/ 25/ 43               Twimpede/88              Jay Han     139       1
10  39/ 43/ 18              Request v2.0     Brant D. Thomsen     136       3
11  39/ 43/ 17               Ntttgtstitd         Simon Hovell     136      11
12  31/ 27/ 42                     Snake       Wayne Sheppard     134      20
13  38/ 42/ 21            Fast Food v2.1     Brant D. Thomsen     134      23
14  38/ 43/ 19       Beholder's Eye v1.7         W. Mintardjo     132      77
15  40/ 47/ 13                    Rave 4        Stefan Strack     132       4
16  40/ 48/ 12                      Rave        Stefan Strack     132      48
17  38/ 44/ 18                      SJ-4            J.Layland     131      14
18  37/ 42/ 21               Christopher       Steven Morrell     131       9
19  36/ 42/ 22                      tiny            J.Layland     130      45
20  39/ 49/ 13           Testing an Idea     Brant D. Thomsen     128       2

21  39/ 50/ 12                Impurge 94     Fredrik Ohrstrom     127       7

It looks like the '94 draft hill has really slowed down.  I would speculate
that this is a result of the greatly increased amount of attention being
given to the '94 experimental hill.  The one new program since the last 
issue to make it onto the hill is Jay Han's "Twimpede/88".
Congratulations, Jay, on this unique honor!
______________________________________________________________________________

The ICWS '94 Draft Experimental Hill:

       Core size:	55,440 instructions
   Max processes:	10,000 per program
        Duration:	After 500,000 cycles, a tie is declared.
Max entry length:	200 instructions

The current ICWS '94 Experimental hill:
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  48/ 28/ 24             Request-55440     Brant D. Thomsen     169      35
 2  33/ 11/ 56           Variation A-1.a              Jay Han     156       4
 3  46/ 40/ 14              Kill Imps!!!       Steven Morrell     152      22
 4  35/ 24/ 41                   CG-X IV     Brant D. Thomsen     145      86
 5  31/ 17/ 52                  Lucky 13        Stefan Strack     144       1
 6  28/ 15/ 57                  Twimpede              Jay Han     141       2
 7  44/ 47/  9                   Rave B4        Stefan Strack     140      44
 8  21/ 10/ 69         Imperfection v2.3     Michael Constant     132      29
 9  36/ 40/ 24                Vanity IIx        Stefan Strack     132      26
10  23/ 19/ 58                    Bimper       Wayne Sheppard     127      10
11  29/ 34/ 36             Night Crawler       Wayne Sheppard     124      45
12  37/ 51/ 12                 The Count              Jay Han     124      25
13  35/ 50/ 16             Dagger v6.0 X     Michael Constant     119      75
14  21/ 22/ 57                   BigImps        James Layland     119      95
15  18/ 20/ 62                    BigImp        Alex MacAulay     117      76
16  18/ 22/ 60                 Skimp 127              Jay Han     113      57
17  27/ 47/ 26               Sunburst 33              Jay Han     107      65
18  10/ 21/ 68               bimp.c test       Wayne Sheppard      99      12
19  11/ 22/ 67               bimp.c test       Wayne Sheppard      99      20
20   5/ 26/ 70                Impale v2a         James Ojaste      84       3

21   1/  1/  3                  Lucky 13        Stefan Strack       5       7

Before I even attempt to summarize what has been happening on the '94
experimental hill, I think it would be helpful to reprint the hill as it
was during the last issue.  (17 Days previously.)

The current ICWS '94 Experimental hill:
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  53/ 12/ 35                    BigImp        Alex MacAulay     194      25
 2  52/ 17/ 30       Imperfection v1.0 X     Michael Constant     187      21
 3  60/ 34/  6            Rave 3 (55440)        Stefan Strack     185      36
 4  42/ 13/ 45                 Skimp 127              Jay Han     171       6
 5  54/ 42/  4           No Ties Allowed       Wayne Sheppard     166      41
 6  51/ 38/ 10             Dagger v6.0 X     Michael Constant     164      24
 7  41/ 17/ 42                   BigImps        James Layland     164      44
 8  49/ 39/ 12               Sunburst 33              Jay Han     159      14
 9  44/ 31/ 25                   CG-X IV     Brant D. Thomsen     157      35
10  49/ 42/ 10                        BS            J.Layland     156      43
11  41/ 34/ 25                 Iron Gate       Wayne Sheppard     148      40
12  35/ 26/ 39                    FatImp              Jay Han     144       1
13  40/ 50/ 10                   Silly 2         James Ojaste     130       7
14  41/ 54/  5                     Silly         James Ojaste     129       9
15  33/ 46/ 21           testing testing     Fredrik Ohrstrom     121      31
16  32/ 46/ 22                     Crimp              Jay Han     118       2
17  34/ 53/ 13                    VJX-2a         James Ojaste     115      28
18  28/ 42/ 31                     Bloom              Jay Han     114      12
19  30/ 50/ 20                Surprise7b         James Ojaste     109      10
20  32/ 59/  8                     VJX-2         James Ojaste     105      29

Since the last issue of _The_'94_Warrior_, 51 new programs have made it onto 
the hill -- this is 3 new programs a day.  Of the first 12 programs on
the hill, only one was on the hill during the last issue.  More programs have
been submitted in this period than in the entire life of the hill previously.  
(Are you getting the point yet?!)

Perhaps the most surprising thing about the current standings on the hill
is the amount of diversity there is between the warriors.  Scanners, stones,
and imp-spiral combinations are all well represented.  In fact, the warrior
currently at the top of the hill is a vampire.  (Certainly not what I would
have predicted.)  It looks as if this is the hill where the excitement is!
______________________________________________________________________________

HINTS and HELPS:

To assist program development on the '94 experimental hill, I have used
Michael Constant's "Optima" program to calculate the twenty most-efficient
step-sizes for mods 1 to 10.  (A mod 1 step-size will eventually cover
every location in the core, a mod 2 step-size will eventually cover one-half
of the locations in the core, etc.)

Notice that there is a bug in the version of "Optima" released last year.
A quick fix is to make the variable "i" in the function "opt" long instead
of short.  An easier fix will be to wait until Michael releases the next
version.  This bug only makes itself known when using a large coresize and
a large step size.  In fact, it was due to this bug that I ended up using
a step-size of 9719 in the 55440 coresize version of Request -- it was the
best mod 1 step the program could find.

[The source code for Request-55440 will probably be included in the next
 issue.  I figured the following tables would be more useful given the current
 number of programs being submitted to the '94 experimental hill.  Also, there
 are a couple of points about program development I am finishing up for a 
 future hint, and "Request" will be good example to use for them.]

Results of running "Optima" on a 55440 size core:

Mod 1:

	16211		6.183968
	23269		6.183968
	15481		6.132795
	16921		6.132795
	22889		6.113332
	24151		6.113332
	16369		6.065658
	21649		6.065658
	12689		6.056693
	15611		6.056693
	20509		6.056693
	21151		6.056693
	20617		6.052941
	22873		6.052941
	12503		6.048468
	16393		6.048468
	16817		6.045978
	21247		6.045978
	 9719		6.028265
	23399		6.028265


Mod 2:

	16238		11.586204
	20498		11.477182
	21502		11.477182
	22766		11.439446
	23266		11.439446
	15458		11.393845
	16462		11.393845
	12718		11.343555
	23278		11.343555
	11974		11.340597
	20474		11.340597
	15314		11.325805
	22706		11.325805
	16894		11.307190
	23234		11.307190
	20546		11.242397
	21074		11.242397
	20458		11.233378
	24422		11.233378
	20558		11.232151


Mod 3:

	24357		16.517452
	21381		16.368905
	22971		16.368905
	14907		16.340657
	20373		16.340657
	21057		16.330429
	22503		16.330429
	14691		16.305265
	15261		16.305265
	19461		16.144705
	20571		16.144705
	24483		16.085124
	16473		16.023107
	20607		16.023107
	16827		16.003463
	22773		16.003463
	 9687		16.002976
	23007		16.002976
	19911		15.997132
	23439		15.997132


Mod 4:

	22964		22.001587
	20996		21.523631
	24356		21.523631
	17228		21.204705
	24148		21.204705
	22756		21.191717
	23476		21.191717
	15548		21.175265
	22892		21.175265
	20068		21.112923
	23228		21.112923
	24196		20.981312
	23404		20.955336
	20476		20.869038
	23924		20.869038
	16508		20.834981
	23428		20.834981
	21508		20.811025
	22508		20.811025
	12988		20.771196



Mod 5:

	21445		26.052133
	23435		26.052133
	 9865		25.878055
	21215		25.878055
	24175		25.794624
	24905		25.794624
	12115		25.712546
	21485		25.712546
	16265		25.675566
	22735		25.675566
	11785		25.657527
	16465		25.657527
	20315		25.560566
	24875		25.560566
	16925		25.451881
	24125		25.451881
	 9965		25.415351
	21475		25.415351
	 9925		25.400469
	15445		25.400469


Mod 6:

	16134		31.110510
	21174		31.110510
	15234		30.829960
	21486		30.829960
	21246		30.807230
	20994		30.786449
	16374		30.408486
	14946		30.113649
	19986		30.113649
	19938		29.889598
	21522		29.889598
	17142		29.831800
	24198		29.831800
	16194		29.815564
	24834		29.815564
	20298		29.745427
	24762		29.745427
	20058		29.643468
	21642		29.643468
	17382		29.622686

Mod 7:

	16373		35.304963
	21427		35.304963
	21007		35.243086
	24367		35.243086
	20041		35.102538
	21049		35.102538
	24157		34.939891
	24997		34.939891
	21623		34.906301
	24983		34.906301
	23429		34.649956
	25459		34.649956
	17129		34.616366
	21161		34.616366
	15043		34.480237
	21077		34.480237
	20293		34.479353
	22547		34.479353
	14651		34.413057
	24899		34.413057


Mod 8:

	12104		39.494299
	24184		39.494299
	20344		39.289941
	21256		39.289941
	15272		39.236831
	21752		39.236831
	16232		39.235676
	22952		39.235676
	19864		38.698802
	20296		38.698802
	20456		38.686102
	25064		38.686102
	13144		38.587964
	23384		38.587964
	24424		38.525617
	25096		38.525617
	16024		38.514071
	16904		38.514071
	23416		38.514071
	24296		38.514071


Mod 9:

	12087		44.316123
	21177		44.316123
	14967		43.623478
	24903		43.623478
	21141		43.594252
	21501		43.594252
	20961		43.468583
	21519		43.468583
	16983		43.337068
	22887		43.337068
	11997		43.281539
	21627		43.281539
	14841		43.227472
	22761		43.227472
	19647		43.107647
	21663		43.107647
	16749		42.900146
	24309		42.900146
	16461		42.870921
	24219		42.870921


Mod 10:

	19990		48.630705
	21050		48.630705
	21470		48.029948
	22930		48.029948
	16210		47.889230
	24830		47.889230
	16910		47.670936
	24130		47.670936
	13150		47.441819
	23230		47.441819
	 9970		47.376872
	22910		47.376872
	15350		47.310121
	22790		47.310121
	12490		47.265019
	19930		47.265019
	21430		47.061158
	23930		47.061158
	16930		47.021469
	19330		46.691322

______________________________________________________________________________

Looking to the Future:

The lastest draft of the standard has been on soda.berkeley.edu for a couple
of months now (as /pub/corewar/documents/icws94.0202.Z).  Take a look at it
and let the newsgroup know what you think.  There are some interesting 
additions to the former '94 draft standard, so it's worth your effort
to get a copy and study it.

Also, please submit your programs to the '94 hills.  We'd love to have your
best KOTH warrior on the standard '94 hill, even if it is still '88 
compliant.

If you have any comments or questions about the '94 hills or the '94
standard that you think might be of general interest, please let me know.

Good luck, and happy computing!
______________________________________________________________________________

Brant D. Thomsen, Editor	   Snail mail:	1197 East 6290 South
(bdthomse@peruvian.cs.utah.edu)			Salt Lake City, UT  84121
University of Utah				U.S.A.
-- 
Brant D. Thomsen                  Man will occasionally stumble over the truth,
(bdthomse@peruvian.cs.utah.edu)   but most times he will pick himself up
University of Utah                and carry on.             - Winston Churchill


Article 2661 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!caen!batcomputer!hookup!news.kei.com!sol.ctr.columbia.edu!howland.reston.ans.net!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: stormking.com server update
Message-ID: <1994Apr2.231359.28721@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: Sat, 2 Apr 1994 23:13:59 GMT
Lines: 17

I am about to update the stormking.com server with pMARS v0.5, which
features three new experimental opcodes by popular request:

SEQ - Skip if EQual (synonym for CMP)
SNE - Skip if Not Equal (its antipode)
NOP - do nothing

v0.5 will be uploaded to soda as soon as we finish with some new debugger
features; watch for an announcement here.

This server update would be a good moment to also change the hills over
to "deterministic mode" by adding the -f or -F nnn switches as discussed
previously. The "nnn" would be changed approx. once per month. Please mail
me if you prefer a) the way it's been so far, b) -f, or c) -F nnn, so
Scott can implement the majority preference.

-Stefan (stst@vuse.vanderbilt.edu)


Article 2662 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!darwin.sura.net!nntp.st.usm.edu!whale.st.usm.edu!not-for-mail
From: ehpharr@whale.st.usm.edu (Eugene Houser Pharr)
Newsgroups: rec.games.corewar
Subject: More on beginner's hill
Date: 4 Apr 1994 10:09:13 -0500
Organization: University of Southern Mississippi
Lines: 27
Message-ID: <2npaip$3638@whale.st.usm.edu>
References: <2nior9$stb@news.delphi.com> <2nisqt$41d@agate.berkeley.edu>
NNTP-Posting-Host: whale.st.usm.edu

How about a "Practice" hill(s).  Practice hills would accept submissions
send results but not actually admit new warriors.  Each practice hill 
would have a selection designed to test specific characteristics.

For instance:  
Avamp Hill - loaded with avamp using opponents ranging from weak
             to deadly.  Useful for testing the durability of vamp
             warriors.
Stone Hill - loaded with a variety of "bomb the heck out'a them" warriors.
Paper Hill - "prepare to be papered!"
... etc.

The ability to test a program against all of the various imp approaches
could be very useful in gate perfection; or Whatever....

And of course, one hill could feature the ICWS annual champions....

Just a thought
Gene Pharr

(BTW - would doing all this in the '94 dialect be to much to ask?) :-)


-- 
       ```       | Sometimes Known As:         | "Don't mind me, I'm just
      (o o)      |    genep@ndbc.noaa.gov      |  passing through." --
--oOO--(_)--OOo--| and/or Eugene H. Pharr, Jr. |           Dave Letterman


Article 2664 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!swrinde!gatech!howland.reston.ans.net!news.intercon.com!panix!ddsw1!news.kei.com!ub!acsu.buffalo.edu!bcohen
From: bcohen@acsu.buffalo.edu (Bram Cohen)
Subject: need help debugging
Message-ID: <Cnr2H3.CpG@acsu.buffalo.edu>
Sender: nntp@acsu.buffalo.edu
Nntp-Posting-Host: lictor-14.acsu.buffalo.edu
Organization: University @ Buffalo
Date: Mon, 4 Apr 1994 19:36:37 GMT
Lines: 22

Here's some code which I don't think works but it's hard to tell since pmars 
doesn't have an option for passively viewing an ongoing battle (at least 
none that I'm aware of. If you know of a way of doing that easily under UNIX
*please* let me know about it. The pmars debugger is great, BTW.)

splbomba		SPL	0,#splbombb-artillery
splbombb		SPL	0,#datbomb-artillery
datbomb			DAT	#0,#splbomba-artillery
bomb			MOV	@artillery,<ptr
			JMP	bomb
ptr			DAT	#splbomba
			DAT	#0
			DAT	#0
			DAT	#0
			DAT	#0
			DAT	#0
artillery		DAT	#splbomba
			END	bomb

When working properly, this program should bomb the entire field with
splbomba, then splbombb, then datbomb, then start over, while only 
executing two instructions.


Article 2666 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: Optima v2.1
Date: 5 Apr 1994 02:42:18 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 20
Message-ID: <2nqj6a$i66@agate.berkeley.edu>
NNTP-Posting-Host: soda.berkeley.edu

Optima v2.1 is now on soda.berkeley.edu in /pub/corewar/incoming;
	optimapc.exe (self-extracting) for PC users, or
	optima.shar for everyone else.

The only difference from v2.0 is a bug fix (credit to Brant for both the bug
report and the subsequent fix! Thanks!).  v2.0 would crash trying to calculate
mod-1 numbers (or mod-2 if the coresize is big enough) where the step size
was bigger than 65535-coresize; this is fixed by changing i (in opt()) to
be long instead of short.

Everyone using Optima v2.0 should probably upgrade; this bug tends to
manifest itself rather often.  Of course, everyone *not* using v2.0
is lower scum than ever walked the face of the earth^Ushould get a copy
immediately; this program will make your corewar development *much* easier.
If you're unsure on what it actually does and why you need a copy, please
mail me!
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2667 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!ihnp4.ucsd.edu!swrinde!gatech!asuvax!asuacad!ahnas
Organization: Arizona State University
Date: Mon, 4 Apr 1994 00:11:41 MST
From: <AHNAS@ASUACAD.BITNET>
Message-ID: <94094.001141AHNAS@ASUACAD.BITNET>
Newsgroups: rec.games.corewar
Subject: Re: Newbie questions!
References: <2m7qpl$eac@sun85.elec.mid.gmeds.com>
 <2mtbi5$985@dingo.cc.uq.oz.au> <2mteul$qeu@agate.berkeley.edu>
 <2n2191$d83@gabriel.keele.ac.uk> <2n267g$18l@agate.berkeley.edu>
 <2n4703$qpd@gabriel.keele.ac.uk> <032994193437Rnf0.77b8@thegate.hacktic.nl>
Lines: 4

mars88 doesn't like unix style end of line charachters. The dos edit program
solves this problem.

Nandor.


Article 2668 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!swrinde!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!math.utah.edu!news.math.utah.edu!morrell
From: morrell@math.utah.edu (Steven C. Morrell)
Subject: Chapter 1 beta-release is ready
Sender: news@math.utah.edu
Date: Mon, 4 Apr 1994 21:41:54 GMT
Organization: Department of Mathematics, University of Utah
Message-ID: <MORRELL.94Apr4154155@uglab21.math.utah.edu>
Lines: 16

Okay, corewar fans.  Chapter 1 is done and available for your inspection
via anonymous ftp to soda.berkeley.edu as /pub/corewar/incoming/chapter1.
I am waiting to do all of the KOTH fighting until I have everything written
so that all programs attack the same hill.

I would also like submissions and names of warriors that I can use.  My last
posting seemed to scare everybody away, so my new policy is send in whatever
you want.  I mentioned that you would be responsible for sending out your
code if it wasn't archived.  This is just because I am leaving the
University of Utah in June and won't be able to be a file server for long.
You will still be responsible for supplying code.

Be sure to send me comments -- four warriors on the Intel KOTH with the
"verbose" command just aren't sending me enough mail!

Steven Morrell          morrell@math.utah.edu


Article 2669 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!swrinde!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!math.utah.edu!news.math.utah.edu!morrell
From: morrell@math.utah.edu (Steven C. Morrell)
Subject: Montage
Sender: news@math.utah.edu
Date: Mon, 4 Apr 1994 22:22:43 GMT
Organization: Department of Mathematics, University of Utah
Message-ID: <MORRELL.94Apr4162244@uglab6.math.utah.edu>
Lines: 118

Here is the code for Montage, my first real attempt at an imp-stone combo.
The most important contribution this program makes is that it has a new
stone in it.  I had a tough time deciding whether I wanted gate-breaking
imps or 7-pt imps, so I just put both of them in.  The gate-breaking imps
are closer together than in Cannonade, making them less vulnerable to SPL
bombs but more vulnerable to imp-traps.  (Imp traps?  I forgot to mention
them in chapter 1.  OH NO!!!)  The stone is a mega-self-splitting stone
that's a bit bigger than Extra-Extra, but maybe a little more durable
because it has 2 SPL 0's.  It bombs core with a mod-1 pattern until it
hits itself, at which time it runs a subtraction core-clear.  After that,
mostly for cosmetic purposes, it jumps to an imp-gate.  Of course, by that
time, any free imps should have overrun everything, so I'm not sure it's
worth the extra cycle to plant the imp-gate.

;redcode verbose
;name Montage
;kill Montage
;author Steven Morrell
;strategy  Stone and a bunch of imps and an imp gate.

p1 equ boot+300
p2 equ boot+302+2667
p3 equ boot+303
p4 equ boot+400

stone   spl 0,<-50
        spl 0,<-51
        mov <3359,-3359
        add 2,-1
        djn -2,<-54
        dat <3359,<-3359

imp1    mov 0,2667
imp2    mov 0,2668
imp4    mov 0,1143
gate    jmp -3359,<3359-10

boot    mov stone+5,-200+5
        mov stone+4,<boot
        mov stone+3,<boot
        mov stone+2,<boot
        mov stone+1,<boot
        mov stone,<boot
        spl boot-200,<100
        mov gate,boot-200+6720
        mov imp1,p1
        mov imp2,p2
        mov imp2,p2+1
        mov imp2,p3
        mov imp2,p3+1
        mov imp4,p4
        spl b,<200
        spl ab,<300
        spl aab,<400
        spl aaab,<500
        spl aaaab,<600
        jmp p1,<700
aaaab   jmp p1+2667,<800
aaab    spl aaabb,<900
        jmp p1+5334,<1000
aaabb   jmp p1+1,<1100
aab     spl aabb,<1200
        spl aabab,<1300
        jmp p1+2668,<1400
aabab   jmp p1+5335,<1500
aabb    spl aabbb,<1600
        jmp p2,<1700
aabbb   jmp p2+2668,<1800
ab      spl abb,<1900
        spl abab,<2000
        spl abaab,<2100
        jmp p2+5336,<2200
abaab   jmp p2+4,<2300
abab    spl ababb,<2400
        jmp p2+2672,<2500
ababb   jmp p2+5340,<2600
abb     spl abbb,<2700
        spl abbab,<2800
        jmp p3,<2900
abbab   jmp p3+2668,<3000
abbb    spl abbbb,<3100
        jmp p3+5336,<3200
abbbb   jmp p3+4,<3300
b       spl bb,<3400
        spl bab,<3500
        spl baab,<3600
        spl baaab,<3700
        jmp p3+2672,<3800
baaab   jmp p3+5340,<3900
baab    spl baabb,<4000
        jmp p4,<4100
baabb   jmp p4+1143,<4200
bab     spl babb,<4300
        spl babab,<4400
        jmp p4+2286,<4500
babab   jmp p4+3429,<4600
babb    spl babbb,<4700
        jmp p4+4572,<4800
babbb   jmp p4+5715,<4900
bb      spl bbb,<5000
        spl bbab,<5100
        spl bbaab,<5200
        jmp p4+6858,<5300
bbaab   jmp p4+1,<5400
bbab    spl bbabb,<5500
        jmp p4+1144,<5600
bbabb   jmp p4+2287,<5700
bbb     spl bbbb,<5800
        spl bbbab,<5900
        jmp p4+3430,<6000
bbbab   jmp p4+4573,<6100
bbbb    spl bbbbb,<6200
        jmp p4+5716,<6300
bbbbb   jmp p4+6859,<6400

end boot

Steven Morrell                   morrell@math.utah.edu


Article 2670 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!ames!olivea!charnel!sd
From: sd@ecst.csuchico.edu (Bruno Puntz Jones)
Newsgroups: rec.games.corewar
Subject: New KotH Server Now Available!
Date: 5 Apr 1994 17:49:03 GMT
Organization: California State University, Chico
Lines: 82
Message-ID: <2ns8afINNmop@charnel.ecst.csuchico.edu>
NNTP-Posting-Host: corpse.ecst.csuchico.edu

Yes, that's right, there's a new hill on the block!

Right now the Internet Pizza Server KotH corewar simulator is only up for
beta-testing, but it should be healthy enough to handle most anything. If
all goes well, the hills should be up and running properly within a few days.
So submit your warriors today!  First 20 customers guaranteed a place on
the hill! :)

To submit your corewar programs to the Pizza Hill, simply mail them to
pizza@ecst.csuchico.edu with the subject of "redcode" or "koth".

Due to the variety of services the Internet Pizza Server provides, your
mail _must_ have a subject of "redcode" or "koth" or you will recieve an
error message.  This is easily done with the -s switch in most mailers.
For example, if you usually used the command:

	"cat test.red | mail koth@stormking.com"

to submit the same program to the Pizza Hill, you would use the command:

	"cat test.red | mail -s 'redcode' pizza@ecst.csuchico.edu"

It's as simple as that.

I am looking for input on the ICWS'88 Experimental hill. The most interesting
idea I could think of is listed below, but I'm looking for better, more
permanent ideas.  Also, any ideas on the beginner's hill would be appreciated
as well.

Bug reports, ideas, and anything else you want to tell me should be mailed
to sd@ecst.csuchico.edu, or to the Pizza Server with the subject of "bugs".

and now, here are the specs of the various hills:

ICWS'88 Standard Hill Specs: (Accessed with ";redcode")
         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'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x")
         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")
         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")
         coresize: 8000
   max. processes: 8000
         duration: after 80,000 cycles, a tie is declared.
max. entry length: 100
 minimum distance: 100
      maximum age: At age 100, warriors are retired.
  instruction set: ICWS '94 Draft

ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x")
         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

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~\/~~\ /~~~\/\  / \  \ / /~\ /~~~YY~~~\\   /~~~~
  Thomas H. Davies               V       \/\ /\  V /   V  |\/\/|  V\ /
sd@ecst.csuchico.edu  "Hard before beer,    V  \  /       |  / |    V
                       you're in the clear;     \/        | /\ |
  Member C.W.M.        beer before hard,     Motto of     |/oo\|
   Since 1987          you're in the yard." Chico State    |/\|


Article 2671 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: Re: optima
Date: 5 Apr 1994 21:18:35 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 17
Message-ID: <2nskjb$5rs@agate.berkeley.edu>
References: <94094.224959AHNAS@asuacad.bitnet>
NNTP-Posting-Host: soda.berkeley.edu

In article <94094.224959AHNAS@asuacad.bitnet>,  <AHNAS@ASUACAD.BITNET> wrote:
>I'm a little bit suspicious about the optima numbers for 55440 in the
>94 warrior. The optima numbers usually occure in pairs and for mod 4
>the best number 22964 does not have a pair with the same optima value.
>Since nobody proved this conjecture the numbers can be right as well.

I think that this is simply a false conjecture.  Certainly it is true for
*many* numbers but it's obviously not true in extreme cases (eg. coresize
8000, mod 1000 -- the best number is 3000 == 5000 but there are no others).
I think that 55440 mod 4 is just another one of these cases.

However, it would be interesting to prove which numbers Nandor's conjecture
holds for, because it certainly works a lot of the time.
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2673 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: Re: New KotH Server Now Available!
Date: 5 Apr 1994 23:45:10 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 32
Message-ID: <2nst66$92a@agate.berkeley.edu>
References: <2ns8afINNmop@charnel.ecst.csuchico.edu>
NNTP-Posting-Host: soda.berkeley.edu

Bruno Puntz Jones <sd@ecst.csuchico.edu> wrote:
>Right now the Internet Pizza Server KotH corewar simulator is only up for
>beta-testing, but it should be healthy enough to handle most anything. If
>all goes well, the hills should be up and running properly within a few days.

Sounds great!  This means we'll have 3 hills... maybe the rather outdated
Intel hill is ready to go... I don't know if we really need so many.

>I am looking for input on the ICWS'88 Experimental hill. The most interesting
>idea I could think of is listed below, but I'm looking for better, more
>permanent ideas.

Counting that the '88 standard is being phased out anyway, maybe we don't
really need an '88 experimental hill.  I think that people's corewar
development should be turned instead towards '94 and (especially) '94-x.

>Also, any ideas on the beginner's hill would be appreciated as well.

Well... not like I'm flaming it or anything, but it seems to me that your
specs for a beginner's hill are going against the opinion of the masses
on rec.games.corewar.  If I remember correctly, most of the people expressing
opinions were *against* having a specific age-limit for beginner's hill
warriors.  In fact, I don't know if people in general want a beginner's hill
at all; I personally like <I forget who>'s idea of a beginner's "hill" which
would let you submit programs to it, and would battle them against several
examples each of stone, paper, scissors, imp, vamp, anti-vamp, etc., and
report the scores (so you can see what areas your program could stand
improvement in), but not actually put your program onto the hill.
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2674 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: Optima v2.2
Date: 6 Apr 1994 00:27:36 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 8
Message-ID: <2nsvlo$a14@agate.berkeley.edu>
NNTP-Posting-Host: soda.berkeley.edu

James *would* tell me about another Optima bug right *after* I'd released
Optima v2.1... :-)  Anyway, there's another bug fix and another version
increase, and another reason for you to get your very own copy of Optima
from soda.  If you don't have the filenames memorized by now, mail me.
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2675 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: Re: Optima v2.2
Date: 6 Apr 1994 00:38:33 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 7
Message-ID: <2nt0a9$a7u@agate.berkeley.edu>
References: <2nsvlo$a14@agate.berkeley.edu>
NNTP-Posting-Host: soda.berkeley.edu

Oh, I forgot to say, this bug fix applies only to Unix users.  If you have
the PC version you don't need it (but if you didn't get v2.1 then you should
get v2.2 because the v2.1 bug fix *does* apply to you).
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2676 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: Re: More on beginner's hill
Date: 6 Apr 1994 03:19:48 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 24
Message-ID: <2nt9ok$d1r@agate.berkeley.edu>
References: <2nior9$stb@news.delphi.com> <2nisqt$41d@agate.berkeley.edu> <2npaip$3638@whale.st.usm.edu>
NNTP-Posting-Host: soda.berkeley.edu

Eugene Houser Pharr <ehpharr@whale.st.usm.edu> wrote:
>How about a "Practice" hill(s).  Practice hills would accept submissions
>send results but not actually admit new warriors.  Each practice hill 
>would have a selection designed to test specific characteristics.

I think this is the best beginner's hill idea so far.  It's fair, it's
useful to beginners, and it encourages development of good warriors.  In
fact, we could have veterans (voluntarily) post their best examples of
the different warrior forms on the practice hill(s) (without posting the
code, if they didn't want to) so that beginners would have a chance to see
how their code stands up not only against standard, basic warrior forms,
but against the state of the art programs in that area.

As far as actual implementation goes, I would recommend a single practice
hill which has a sampling of all of the basic warrior forms, say a few
generic examples and a few real examples of each.  The score report would
include W/L/T for each opponent as well as an overall "Paper" rating, etc.,
and finally an overall rating.  Then a beginner could see, at a glance,
where his programs needed improvement.  (I try not to think of myself as
a beginner but I'd use a practice hill like this if we implemented it!)
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2677 of rec.games.corewar:
Path: hellgate.utah.edu!caen!math.ohio-state.edu!howland.reston.ans.net!cs.utexas.edu!asuvax!asuacad!ahnas
Organization: Arizona State University
Date: Tue, 5 Apr 1994 18:16:32 MST
From: <AHNAS@ASUACAD.BITNET>
Message-ID: <94095.181632AHNAS@ASUACAD.BITNET>
Newsgroups: rec.games.corewar
Subject: Re: optima
References: <94094.224959AHNAS@ASUACAD.BITNET>
Lines: 4

I run my optima calculator program and I got the same numbers. So
it seems that optima numbers are not in pairs :-( This is curious.

Nandor.


Article 2679 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!swrinde!cs.utexas.edu!howland.reston.ans.net!EU.net!sunic!uts!diku!gammel
From: gammel@diku.dk (Peter Nyman Hansen)
Subject: Evaluation of adressmodes
Summary: Question about how predecrement is evaluated.
Message-ID: <1994Apr6.113028.9911@odin.diku.dk>
Sender: gammel@dvalin.diku.dk
Date: Wed, 6 Apr 1994 11:30:28 GMT
Organization: Department of Computer Science, U of Copenhagen
Keywords: corewar
Lines: 22

Hi out there. 

I am planning to write a simple simulator to be used in connection with
testing my own corewarprograms. I plan to use it to evaluate a lot of
diferent small programs against each others.

I have a problem tough.

        mov <2,<2

What evaluates first, the source or the destination, and

        mov @2,<2

what in this case?

Some of you experts out there must know the answer.

Please give me an answer. (Post it to the newsgroup)


Peter Nyman Hansen  			email: gammel@diku.dk


Article 2680 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!swrinde!news.dell.com!natinst.com!cs.utexas.edu!asuvax!asuacad!ahnas
Organization: Arizona State University
Date: Wed, 6 Apr 1994 01:18:51 MST
From: <AHNAS@ASUACAD.BITNET>
Message-ID: <94096.011851AHNAS@ASUACAD.BITNET>
Newsgroups: rec.games.corewar
Subject: Re: optima
References: <94094.224959AHNAS@ASUACAD.BITNET>
 <94095.181632AHNAS@ASUACAD.BITNET>
Lines: 14

I tried Michael's optima program with coresize 8000 mod 4 and I got 3516
as best number. I think this is wrong. To make it possible to compare
results I
uploaded optimatp.zip to soda. It contains a turbo pascal source and
dos executable optima calculator program. It's about 2.5 times as fast
as Michael's program ( at least for coresize 8000 and mod 4 ). It's able
to find the best optima number in an intervall [1,k] . For a full search
k should be corsize/2 .

Note that optima calculation is not the ultimate weapon, the idea is to
use a program to optimize constants so everubody should have his own
constant calculator program.

Nandor.


Article 2681 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!usc!elroy.jpl.nasa.gov!jlayland
From: jlayland@kilroy.jpl.nasa.gov (James Layland)
Newsgroups: rec.games.corewar
Subject: Re: optima
Date: 6 Apr 1994 16:41:16 GMT
Organization: Jet Propulsion Laboratory, Pasadena, CA  USA
Lines: 15
Message-ID: <2nuonc$slu@elroy.jpl.nasa.gov>
References: <94094.224959AHNAS@ASUACAD.BITNET> <94095.181632AHNAS@ASUACAD.BITNET> <94096.011851AHNAS@asuacad.bitnet>
NNTP-Posting-Host: 128.149.63.2

In article <94096.011851AHNAS@asuacad.bitnet>,  <AHNAS@ASUACAD.BITNET> wrote:
>I tried Michael's optima program with coresize 8000 mod 4 and I got 3516
>as best number. I think this is wrong. To make it possible to compare

This is wrong, but I believe this should be fixed by the most recent
bugfix Michael uploaded.  I saw this number at one point when I
tried using 32-bit ints instead of 16-bit ints in Michael's code.
Using version 2.2 I get 3364 and 3044 as expected.




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


Article 2683 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!swrinde!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!umn.edu!eelpout!bcolglaz
From: bcolglaz@eelpout.micro.umn.edu (Benjamin Colglazier)
Subject: Re: More on beginner's hill
Message-ID: <Cnuz9p.719@news.cis.umn.edu>
Sender: news@news.cis.umn.edu (Usenet News Administration)
Nntp-Posting-Host: eelpout.micro.umn.edu
Organization: University of Minnesota CIS
References: <2nior9$stb@news.delphi.com> <2nisqt$41d@agate.berkeley.edu> <2npaip$3638@whale.st.usm.edu>
Date: Wed, 6 Apr 1994 22:19:56 GMT
Lines: 9

  The 'practice hill' sounds really good.  I think for BEST effect though, it
should have pre-chosen warriors, whose source code is made public via
anonymous ftp.  That way, a programmer can not only test his warrior against
different levels of opponents, but he can look at their code to see why he's
getting those results.  It also gives novices something concrete & practical to
build off of.

-ben



Article 2684 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: Re: optima
Date: 6 Apr 1994 23:48:18 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 28
Message-ID: <2nvho2$41i@agate.berkeley.edu>
References: <94094.224959AHNAS@ASUACAD.BITNET> <94095.181632AHNAS@ASUACAD.BITNET> <94096.011851AHNAS@asuacad.bitnet>
NNTP-Posting-Host: soda.berkeley.edu

In article <94096.011851AHNAS@asuacad.bitnet>,  <AHNAS@ASUACAD.BITNET> wrote:
>To make it possible to compare results I
>uploaded optimatp.zip to soda. It contains a turbo pascal source and
>dos executable optima calculator program. It's about 2.5 times as fast
>as Michael's program ( at least for coresize 8000 and mod 4 ).

In defence of my program, I think I ought to say several things:

	1.	Mine estimates how long the calculation will take.  I hope
		you did not count the time it takes to make the estimate!
	2.	Mine sacrifices a little speed for the ability to respond
		to a ^C at any time, and to display a progress indicator.
		Nandor's doesn't respond to ^C at all, and so between no
		progress indicator, no time estimate, and no break capability,
		it's hard to tell if your computer's locked up.  (note: I'm
		explaining why mine is slower, not trying to flame Nandor's
		program.  It *is* faster than mine and it calculates optima
		numbers perfectly well.  I just like mine better. ;-)
	3.	Nandor's program does have one speed-increasing feature that
		mine should, relating to the way it counts distances from the
		current bomb.  This is not a difficult feature to add to
		mine, and I am updating mine even as I write this.
	4.	Nandor's is written in Pascal.  Mine is in C.  What more
		need be said? :-)
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2687 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!cs.utexas.edu!asuvax!asuacad!ahnas
Organization: Arizona State University
Date: Thu, 7 Apr 1994 00:11:09 MST
From: <AHNAS@ASUACAD.BITNET>
Message-ID: <94097.001109AHNAS@ASUACAD.BITNET>
Newsgroups: rec.games.corewar
Subject: Re: optima
References: <94094.224959AHNAS@ASUACAD.BITNET>
 <94095.181632AHNAS@ASUACAD.BITNET> <94096.011851AHNAS@ASUACAD.BITNET>
Lines: 5

I was wrong again (maybe I should just shut up for awhile). Michael's
program is prefectly good, though the result is not sorted which caused
my confusion. Sorry about this.

Nandor.


Article 2688 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!overload.lbl.gov!agate!soda.berkeley.edu!mconst
From: mconst@soda.berkeley.edu (Michael Constant)
Newsgroups: rec.games.corewar
Subject: Re: New KotH Server Now Available!
Date: 7 Apr 1994 17:23:04 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 28
Message-ID: <2o1fho$l1n@agate.berkeley.edu>
References: <1994Apr7.045601.105487@ns1.cc.lehigh.edu>
NNTP-Posting-Host: soda.berkeley.edu

Frank Jude Wojcik <fjw2@ns1.cc.lehigh.edu> wrote:
>Umm, there seems to be a small bug in this hill. I can't kill off any of my
>programs. There are now about 5 of them up there at least.

This is probably because there aren't enough programs on the hill yet.
When you kill a program it doesn't actually remove it from the hill, it
just assigns it a ridiculously low score and assumes that the next real
submission to the hill will knock your killed program off.  However, the
Pizza hills are still new and none of them have 20 people yet, so there's
nobody to knock your old versions of Zipper off.  Just wait -- after a
while the hill will fill up and your killed programs should get knocked off.
If they don't then kill them again and then it should work.  (This might
be necessary depending on how the koth server scores new programs fighting
killed programs.  I don't know exactly how it works.)

Also, this doesn't apply to the current situation, but just so that you
know: if you need to send a "fake" program just to kill another one of your
programs off (i.e. if you had two programs on the hill and decided that
one of them was taking too many points away from the other) then the "fake"
program you submit must have at least one line that's *not* DAT 0, 0.
If the program is composed entirely of DAT 0, 0 then the koth server assumes
that you just want to check the standings of the hill, and doesn't bother
battling your program against the rest -- or, more importantly, reading
the header information to find things like ";kill" instructions.
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2691 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!news.cs.utah.edu!utah-morgan!cs.utexas.edu!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!ssd.intel.com!wms
From: wms@ssd.intel.com (William Shubert)
Subject: KotH Server Announcement
Message-ID: <CnwJsy.D2s@SSD.intel.com>
Sender: usenet@SSD.intel.com
Nntp-Posting-Host: snowcrash
Organization: Supercomputer Systems Division (SSD), Intel
Date: Thu, 7 Apr 1994 18:38:58 GMT
Lines: 16

Hello everybody,
   As you have probably heard there is a now Corewar server running on
"ecst.csuchico.edu".  This server promises to have the same fast turnaround
as my server but with more hill options, including a '94 hill.  This makes
my hill at Intel rather redundant, and so I plan to phase it out.
   I have exchanged mail with Thomas Davies, who set up the new site,
and he is completely willing to accept all the submissions that have in
the past been going to my hill.  So please, use his new hill!  It's been
a really fun three (has it really been three?) years providing this service
to the internet community but as some of you know I've somewhat lost
touch with the corewar community and I'll be happy to get my machine
cycles back.  For now my hill will continue to operate, but as soon as
it's use has dropped off enough (hopefully in a few days) I will be
shutting it down for good.  Thanks to all of those who used my server in
the past!
				-Bill (wms@ssd.intel.com)


Article 2694 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!cs.utexas.edu!asuvax!asuacad!ahnas
Organization: Arizona State University
Date: Thu, 7 Apr 1994 12:19:33 MST
From: <AHNAS@ASUACAD.BITNET>
Message-ID: <94097.121933AHNAS@ASUACAD.BITNET>
Newsgroups: rec.games.corewar
Subject: Re: More on beginner's hill
References: <2nior9$stb@news.delphi.com> <2nisqt$41d@agate.berkeley.edu>
 <2npaip$3638@whale.st.usm.edu> <2nt9ok$d1r@agate.berkeley.edu>
Lines: 9

A practice hill is not the same as a beginner hill. For a beginner it's
encourageing to get onto a hill. To get a score is not so exiting.
I support the age limit solution for the beginner hill. Of course a
practice hill is a good idea in addition to the beginner hill. Long ago
I maintained a list of the oldest programs. I think this would work for
the practice hill. The practice hill should contain the oldest programs
on the various hills. So the practice hill would change although very
slowly ( not many warriors live long ).
Nandor.


Article 2696 of rec.games.corewar:
Path: hellgate.utah.edu!utah-morgan!cs.utexas.edu!howland.reston.ans.net!agate!soda.berkeley.edu!mconst
From: mconst@soda.berkeley.edu (Michael Constant)
Newsgroups: rec.games.corewar
Subject: Re: More on beginner's hill
Date: 8 Apr 1994 18:01:15 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 27
Message-ID: <2o465b$eug@agate.berkeley.edu>
References: <2nior9$stb@news.delphi.com> <2npaip$3638@whale.st.usm.edu> <2nt9ok$d1r@agate.berkeley.edu> <94097.121933AHNAS@asuacad.bitnet>
NNTP-Posting-Host: soda.berkeley.edu

In article <94097.121933AHNAS@asuacad.bitnet>,  <AHNAS@ASUACAD.BITNET> wrote:
> A practice hill is not the same as a beginner hill. For a beginner it's
> encourageing to get onto a hill. To get a score is not so exiting.

But the point of the practice hill is that beginners will use it to make
their programs better, so that they can get onto the real hill.
Maybe we could add another 5-10 spots to the real hill to make it easier
for (beginners) to get on.

> Long ago I maintained a list of the oldest programs. I think this would
> work for the practice hill. The practice hill should contain the oldest
> programs on the various hills. So the practice hill would change although
> very slowly ( not many warriors live long ).

This sounds good to me.  People will be able to test their programs
against time-honored strategies, and will start finding ways to defeat
them, which will keep the hill from standing still.  For beginners, it
still has the beneficial effect of testing their program against standard
warrior forms.

However, I think that the practice hill should also have some "generic"
warriors that were never meant to be on the hill (eg. a standard paper with
no extra features at all).  This would make it more useful to beginners.
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2697 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!caen!batcomputer!hookup!news.kei.com!eff!news.umbc.edu!haven.umd.edu!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Re: stormking.com server update
Message-ID: <1994Apr4.212838.5125@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: <1994Apr2.231359.28721@news.vanderbilt.edu> <CnqwE9.8r7@acsu.buffalo.edu>
Date: Mon, 4 Apr 1994 21:28:38 GMT
Lines: 21

In article <CnqwE9.8r7@acsu.buffalo.edu> bcohen@acsu.buffalo.edu (Bram Cohen) writes:
>In article <1994Apr2.231359.28721@news.vanderbilt.edu>,
>Stefan Strack <stst@vuse.vanderbilt.edu> wrote:
>>I am about to update the stormking.com server with pMARS v0.5, which
>>features three new experimental opcodes by popular request:
>>
>[snip]
>>NOP - do nothing
>>
>
>Why not just let people use JMP 1 ?

This was discussed here not too long ago. The argument of the NOP proponents
was that NOP with two operand increment/decrement could be useful in imp-gates.
I am adding support for these three opcodes so we can find out whether they
are worth including in the standard draft. (I don't like NOP much myself, 
although I can see uses for SNE).

-Stefan (stst@vuse.vanderbilt.edu)




Article 2698 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!utah-morgan!cs.utexas.edu!swrinde!gatech!europa.eng.gtefsd.com!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Re: More on beginner's hill
Message-ID: <1994Apr6.230501.25518@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: <2nisqt$41d@agate.berkeley.edu> <2npaip$3638@whale.st.usm.edu> <Cnuz9p.719@news.cis.umn.edu>
Date: Wed, 6 Apr 1994 23:05:01 GMT
Lines: 20

In article <Cnuz9p.719@news.cis.umn.edu> bcolglaz@eelpout.micro.umn.edu (Benjamin Colglazier) writes:
>  The 'practice hill' sounds really good.  I think for BEST effect though, it
>should have pre-chosen warriors, whose source code is made public via
>anonymous ftp.  That way, a programmer can not only test his warrior against
>different levels of opponents, but he can look at their code to see why he's
>getting those results.  [..]
>

Better yet, download those warriors and run the battles at home :-). This way,
you can use your favorite debugger/core viewer to see what's really going on.

Seriously though, if anyone has the time to write the scripts and the 
resources to run a beginner's hill, mail me and I'll send you the scripts
that currently run the stormking.com hills; that might be a good starting
point.

>-ben

-Stefan (stst@vuse.vanderbilt.edu)



Article 2699 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: Re: More on beginner's hill
Date: 9 Apr 1994 01:59:07 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 11
Message-ID: <2o525b$ofo@agate.berkeley.edu>
References: <2nisqt$41d@agate.berkeley.edu> <2npaip$3638@whale.st.usm.edu> <Cnuz9p.719@news.cis.umn.edu> <1994Apr6.230501.25518@news.vanderbilt.edu>
NNTP-Posting-Host: soda.berkeley.edu

In article <1994Apr6.230501.25518@news.vanderbilt.edu>,
Stefan Strack <stst@vuse.vanderbilt.edu> wrote:
>Seriously though, if anyone has the time to write the scripts and the 
>resources to run a beginner's hill, mail me [...]

There's already a "beginner's hill" spot on the Pizza server; why not just
update it to / add a spot for the "practice hill" we've been discussing?
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2702 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: Re: stormking.com server update
Date: 9 Apr 1994 05:31:00 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 14
Message-ID: <2o5eik$r76@agate.berkeley.edu>
References: <1994Apr2.231359.28721@news.vanderbilt.edu>
NNTP-Posting-Host: soda.berkeley.edu

Stefan Strack <stst@vuse.vanderbilt.edu> wrote:
>I am about to update the stormking.com server with pMARS v0.5, which
>features three new experimental opcodes by popular request:
> [SEQ, SNE, and NOP]

While we're implementing controversial new features, how about IJZ (Increment
and Jump if Zero), and the { and } modes (A-field pre-decrement indirect
and A-field post-increment indirect, respectively).  (If it wouldn't be too
much work, of course -- it seems to me that IJZ, at least, would not be hard
to implement.)
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2704 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!torn!uunet.ca!uunet.ca!xenitec!tdkcs!isle!mchapman
From: mchapman@isle.waterloo-rdp.on.ca (M.Chapman)
Subject: Re: Corewar System for BBS?
References: <CnDzn8.Lt9@hkpu01.hkp.hk> <1994Mar30.162918.13790@news.vanderbilt.edu>
Organization: Neat & Nifty
Date: Tue, 5 Apr 1994 15:21:26 GMT
X-Newsreader: TIN [version 1.2 PL2]
Message-ID: <1994Apr5.152126.1003@isle.waterloo-rdp.on.ca>
Lines: 36

Stefan Strack (stst@vuse.vanderbilt.edu) wrote:
: In article <CnDzn8.Lt9@hkpu01.hkp.hk> cs018226@hkpu01.hkp.hk (Kevin Lam) writes:
: >Hi all, is there any BBS door program such that a PC-based BBS can
: >run as a corewar server?
: >
: >Best wishes,
: >Kevin.

: Not that I am aware of. A good start for writing your own would be to take
: a look at my mts.c (in soda.berkeley.edu:/pub/corewar/systems/pmars04s.zip),
: a round-robin scheduler that works with pmars, mercury2 and other corewar
: systems.

: Tell me what you need for a BBS door and I can probably add a KotH server mode
: to mts by the next release of pmars.

: -Stefan (stst@vuse.vanderbilt.edu)


 well.. so far my friend and i have started to right a door for RA BBS.

we have ity setup so the user ul's there warrior and can choose to put it
on the hill or fight someone rightaway or wait for the 2am tourney.

we used mts.c , pmars(the one at berkely) and good old BC++ 3.1 ...

if we get it to work right (for a change) i'll see about getting it out
there.. (I may end up uuendcoding it here .. or mayhaps mail it to 
someone with ftp access) ..


--
| Tass Chapman | m.chapman@ieee.org | FIDO 1:221\403     |
| Conestoga College- Elec' Tech' Eng. Telecommunications |
| Kitchener Ontario Canada                               |
"OOPS... I guess that's not a thing conductive to a long life."


Article 2705 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: Explaining Addressing Modes
Date: 10 Apr 1994 17:55:16 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 82
Message-ID: <2o9ei4$nca@agate.berkeley.edu>
References: <1994Apr2.231359.28721@news.vanderbilt.edu> <2o5eik$r76@agate.berkeley.edu> <2o7nuu$2ee@cwis.isu.edu>
NNTP-Posting-Host: soda.berkeley.edu

FULLMER_ANTONETTE <fullanto@cwis.isu.edu> wrote:
>>and Jump if Zero), and the { and } modes (A-field pre-decrement indirect
>>and A-field post-increment indirect, respectively).  (If it wouldn't be too
>
>How about giving a short explanation of indirect adressing to those of us 
>who are having trouble with DIRECT addressing, much less indirect 
>addressing. (knew I should have taken some time out to learn assembly...)

The tutorial *does* explain this, but not very well.  So, here's my own
attempt to clear up the mystery:

There are 5 addressing modes: immediate (#), direct ($ or just blank),
indirect (@), pre-decrement indirect (<), and post-increment indirect (>).
(Note: The last of these (>) is only available under the proposed '94 standard,
not '88.)  Here is how they work.  For each explanation, X is the number
following the address mode under discussion, eg. for immediate it might be

		MOV #x, 2

So, here are the explanations:

Immediate:	Simply refers to the number x.  (Actually this is slightly
		simplistic and doesn't always work for '94 programming (it's
		fine for '88), but it's good enough for beginning programmers.
		Anyone who wants the *real* explanation of how immediate
		addressing works, mail me.)  Example:

		MOV #5, 2

		copies the number 5 to the B-field of the instruction 2
		ahead of the current instruction.

Direct:		Refers to the instruction x ahead of the current instruction.
		Example:

		MOV 5, 2

		copies the instruction 5 ahead to the instruction 2 ahead.
		(The instruction 2 ahead is overwritten.)

Indirect:	Refers to the instruction that's as far further ahead of
		the instruction x ahead as the instruction x ahead's B-
		field.  (Stop and think about that.)  Example:

		MOV @5, 2

		would look at the B-field of the instruction 5 ahead, and
		go that many more instructions forward (past the instruction
		5 ahead) and copy the instructino *there* to the instruction 2
		ahead.

Pre-decrement	Like indirect, but decrements the B-field in question before
Indirect:	using it.  Example:

		MOV <5, 2

		would look at the B-field of the instruction 5 ahead (just
		like indirect), _decrement_that_B-field_, and then go as
		many instructions further forward as the (new) B-field, and
		copy the instruction *there* to the instruction 2 ahead.
		The B-field stays decremented.  (Note: like the explanation
		of immediate addressing, this explanation does not explain
		all.  Namely, it leaves out a discussion of in-register and
		in-memory evaluation.  If you want to know how it really
		works, mail Stefan (stst@vuse.vanderbilt.edu) and CC the
		mail to me cause *I* don't understand it! :-)

Post-increment	Like indirect, but increments the B-field in question after
Indirect:	using it.  Example:

		MOV >5, 2

		would look at the B-field of the instruction 5 ahead,
		count that many more instructions forward (just like indirect),
		copy the instruction there to the instruction 2 ahead, and
		finally increment the B-field it used.  (Obviously it stays
		incremented, otherwise there would be no point.) Note that
		this mode is only available under the proposed '94 standard.
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2707 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!munnari.oz.au!cs.mu.OZ.AU!uluru7!macaulay
From: macaulay@ecr.mu.oz.au (Alexander_William MACAULAY)
Subject: Redcoder 2.0
Message-ID: <9410120.21598@mulga.cs.mu.OZ.AU>
Sender: news@cs.mu.OZ.AU
Organization: Computer Science, University of Melbourne, Australia
X-Newsreader: TIN [version 1.2 PL2]
Date: Mon, 11 Apr 1994 10:13:12 GMT
Lines: 16


Redcoder 2.0, a Macintosh Core War simulator and full development system,
is now available for ftp from soda.berkeley.edu. At the moment you can find
it in the directory /pub/corewar/incoming, but it should eventually be moved
to /pub/corewar/systems.

Redcoder 2.0 supports the ICWS '94 draft standard (it makes use of the
pMARS assembler so that you can do all those nice things like multi-line
equates, for-rof loops, etc.). Another major addition to Redcoder
is a text core-view window which is great for debugging programs. You
also get to choose from several different sets of patterns to draw changes
to the core. Read the "About Redcoder 2.0" file included with Redcoder
for more information and instructions on how to use the program.

---
Alex MacAulay (macaulay@ecr.mu.oz.au)


Article 2708 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: koth updates
Message-ID: <1994Apr9.072953.18782@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: Sat, 9 Apr 1994 07:29:53 GMT
Lines: 29


Thomas Davies has just updated the pizza server with pMARS v0.5.  The
stormking.com hills will follow shortly. For the '94 hills, this
means that you can now use the experimental opcodes SEQ, SNE and NOP.

    Those who are moving their ICWS'88 warriors from Bill Shubert's
hill should keep in mind that pizza's '88 hills are also running
pMARS. For one thing, this means that you can use for/rof to compact
your decoys. It also means that EQU expressions are no longer
implicitely parenthesized, so if you've been using this "feature" you
will now need to put parentheses explicitely (Mintardjo's "Winter
Werewolf 3" is one of the warriors that wouldn't quite work as
expected on the new ICWS'88 hill).

    By popular demand (ahem, two votes, both in favor of "-F nnn"),
all hills are now running in deterministic mode. The pMARS -F switch
seeds the pseudo random generator with seed "nnn", i.e. the 100
rounds per confrontation will have a fixed series of initial
placements of warrior 2. This reduces random score fluctuations; i.e.
if you submit the same warrior twice, the individual and cumulative
scores will be identical (provided the hill hasn't changed in the
meantime of course). If you submit a new version of your warrior that
doesn't have a new bombing or scanning pattern, you can be sure that
all changes in score are due to the changes you introduced, and not
due to statistical fluctuations. The random number seed (and
therefore the sequence of initial placements) changes automatically
at the 1st of every month.

-Stefan (stst@vuse.vanderbilt.edu)


Article 2709 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!mvb.saic.com!news.cerf.net!usc!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!hookup!batcomputer!cornell!uw-beaver!cs.washington.edu!jayhan
From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: The new Pizza server is great!
Message-ID: <JAYHAN.94Apr11164328@derkins.cs.washington.edu>
Lines: 22
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington
Date: 11 Apr 1994 16:43:28 GMT

Hello all,

	Thanks to Thomas Davies for setting up the new Pizza KoTH
server.  It has all the hills you've wanted (minus the practice
hills, maybe), and has a turn-around time comparable to Intel's.  At
last I can submit my 94x warriors and have the results the same day!

	So, I transfered all my 94 warriors there.  I think stormking
can still be useful as a test site for experimental Corewar (e.g.
with the new opcodes), while Intel's hill is discontinued.

	As an evidence to my ever increasing enthusiasm, I'll post the
code for my latest two warriors, Variation D-1 and Scanalyzer-V.3a.
Variation is riding at the top of the hill, but not #1, though it's
#1 on Stormking.  That's mainly due, IMHO, to the fact that there
still are many ampty slots on the Pizza hill.  So, go ahead and fill
that space!  You have a few *guaranteed* Hill spots right now!

-=<|  Jay "Thierry" Han  |>=-       e-mail: jayhan@cs.washington.edu
Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969
U. of Washington. Seattle, WA 98195, USA.   [Sieg 230] (206)685-1224
Personal: 4820 Burke Ave N. Seattle, WA 98103, USA.    (206)547-8559


Article 2710 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!yeshua.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!uw-beaver!cs.washington.edu!jayhan
From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: Variation D-1
Message-ID: <JAYHAN.94Apr11165939@derkins.cs.washington.edu>
Lines: 164
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington
Date: 11 Apr 1994 16:59:39 GMT

	Remember when I posted my moderately-successful Stimpede?  It
basically had a ExtraExtra stone with a 2-process 19-point
imp-spiral.  I improved it by changing the ending slightly, and
adding more trashing (put DJN where there was a JMP).  Variation
A-1.a was the successor, and it had an extra wimp to tie CG-X and to
have an extra edge againts other stone/imps, at the expense of more
vulnerability to scanners and vampires.

	The latest Variation D-1 has a slightly different twist to the
stone part.  After some bombing, the "buckle" line is replaces by
"stop", so that the stone doesn't generate more processes (the stone
becomes ineffective if we hit the processes max).  Later on, it
drops "patch" onto "stone", which steers away processes into the
core-clear.  However, all the processes at "loop" and "cast" keep
bombing for a while before they're drained.  The constants are
adjusted so that the complete bombing run almost exactly hits every
other core location either by decrementing or bombing (there's a
slight over-reach).

	The core-clear is an ultra-standard one, changing into a
perfect gate.  At this point there are still 3000+ processes
running, so the time spent in my own spiral is negligible (or so I
hope).

	Notice the wimp that's started right after the stone.  This
wimp also generates a number of processes, but nowhere near what the
stone accumulates over time.  The stone and the spiral are
vulnerable to CG-X's decrementing run, but the wimp is not, so I get
90+% ties against CG-X, compared to about 25% losses with Stimpede.

	Finally, notice that when the stone hits itself with "stop"
on "buckle", it becomes a 50% gate, which is enough to gain another
few points againts other spirals.  Againts other stone/imps, my
stone has a 50/50 chance of winning against the opponent's and then
when the stone is dead, the wimp will kill the opponent's stone and
spiral.

	So, why have a spiral at all?  That's a good question, and
I'll answer to it after I experiment with my upcoming Nova series.

;redcode-94x
;name Variation D-1
;author Jay Han
;strategy Variation on the theme of "Twimpede"
;strategy Added a split/wimp
;strategy Stonger imp-gating, less trashing
;macro

		org	start

; Mod-2 stone
p1		equ	27739
s1		equ	34
p2		equ	27705
s2		equ	-34

gate		equ	top-39

top		equ	stop
stop		dat.f	<gate-buckle,	<gate-buckle+1
loop		add.f	inc,		cast
stone		spl.b	loop,		<gate
cast		mov.i	<p1,		p2
buckle		djn.f	stone,		<gate
inc		spl.b	#s1,		<s2
clear		mov.i	plug,		<stop+1
plug		dat.f	<gate,		<gate+1
patch		jmp.b	3,		#1

for 105
		dat.f	0,		0
rof

wimp            spl.b   #0,             <gate
                djn.f   #0,             <gate
for 4
		dat.f	0,		0
rof
start           spl.b   stone
                spl.b   wimp

; 38-process 19-point spiral (coresize 55440, '94 standard)
step		equ	29179
launch
		spl	lbl3
		spl	lbl5
		spl	lbl9
		spl	lbl17
		spl	lbl33
		spl	lbl65
		jmp	imp+0*step+0
lbl65		jmp	imp+1*step+0
lbl33		spl	lbl67
		jmp	imp+2*step+0
lbl67		jmp	imp+3*step+0
lbl17		spl	lbl35
		spl	lbl69
		jmp	imp+4*step+0
lbl69		jmp	imp+5*step+0
lbl35		spl	lbl71
		jmp	imp+6*step+0
lbl71		jmp	imp+7*step+0
lbl9		spl	lbl19
		spl	lbl37
		spl	lbl73
		jmp	imp+8*step+0
lbl73		jmp	imp+9*step+0
lbl37		spl	lbl75
		jmp	imp+10*step+0
lbl75		jmp	imp+11*step+0
lbl19		spl	lbl39
		spl	lbl77
		jmp	imp+12*step+0
lbl77		jmp	imp+13*step+0
lbl39		spl	lbl79
		jmp	imp+14*step+0
lbl79		jmp	imp+15*step+0
lbl5		spl	lbl11
		spl	lbl21
		spl	lbl41
		spl	lbl81
		jmp	imp+16*step+0
lbl81		jmp	imp+17*step+0
lbl41		spl	lbl83
		jmp	imp+18*step+0
lbl83		jmp	imp+0*step+1
lbl21		spl	lbl43
		spl	lbl85
		jmp	imp+1*step+1
lbl85		jmp	imp+2*step+1
lbl43		spl	lbl87
		jmp	imp+3*step+1
lbl87		jmp	imp+4*step+1
lbl11		spl	lbl23
		spl	lbl45
		spl	lbl89
		jmp	imp+5*step+1
lbl89		jmp	imp+6*step+1
lbl45		spl	lbl91
		jmp	imp+7*step+1
lbl91		jmp	imp+8*step+1
lbl23		spl	lbl47
		spl	lbl93
		jmp	imp+9*step+1
lbl93		jmp	imp+10*step+1
lbl47		spl	lbl95
		jmp	imp+11*step+1
lbl95		jmp	imp+12*step+1
lbl3		djn.b	#0,		#2		; Idle 2 cycles
		spl	lbl25
		spl	lbl49
		spl	lbl97
		jmp	imp+13*step+1
lbl97		jmp	imp+14*step+1
lbl49		spl	lbl99
		jmp	imp+15*step+1
lbl99		jmp	imp+16*step+1
lbl25		mov	#0,		#0		; Idle
		spl	lbl101
		jmp	imp+17*step+1
lbl101		jmp	imp+18*step+1
imp		mov.i	#-step,		step		; well, why not?

		end	start


Article 2711 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!hookup!batcomputer!cornell!uw-beaver!cs.washington.edu!jayhan
From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: Scanalyzer-V.3a
Message-ID: <JAYHAN.94Apr11172453@derkins.cs.washington.edu>
Lines: 100
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington
Date: 11 Apr 1994 17:24:53 GMT

	I made several attempts at making a decent scanner for a
long time.  My previous Scanalyzers were just scanners, and I'd
tried different bombing patterns and scanning patterns, but none had
achieved a very good score.  Maybe I should learn to use the Optima
program! :-)

	Anyway, encouraged by the success of my simple vampire,
named The Count, I decided to combine a vampire and a scanner.  The
idea is to have a regular scanner, and when something is detected,
drop a tailored fang on the target location, and continue scanning.
After a while, start a core-clear that ends by killing of the pit,
then become a perfect gate (we never know, those spirals survive
anything!).

	The "fang" is just a JMP, and we first move it to the
target, then substract the target's offset from "scan" from the
fang's A-operand.  The fang now points to "pit".

	One of the problems (as in any scanner) is that there's only
a single process, and I can't have a spiral for life insurance, much
less a wimp.  However, my future plans include a combination
stone/spiral/vampire/wimp.  The vampire would cast fangs in a loop
similar to ExtraExtra, while the stone trashes the core in parallel.
That way, I can start a spiral and even a wimp without too much
penalty in terms of bombing speed.

	The one big problem with ExtraExtra vampire is how to stop
them.  For a stone, it's simple, you just lay out replacement
instruction varefully at predetermined locations, and voila, you
have a self-modifying program.  A vampire, however, only knows
fangs.

	One solution is to set up the stone to kill off the vampire
after a while.  The problem is that your choice of constants is
getting real narrow, because you have to make it so that it hits
three core locations at predetermined time.  Another solution is to
have a wimp to kill your vampire.

	Also, you mustn't let the vampire hit your stone.  That's
even trickier, and involves a careful choice of the constant.

	As I mentioned before, I use a spiral primarily as a life
insurance.  As long as the tail process is not killed, a spiral
survives most anything, except a perfect gate.  And the tail process
is darn hard to find in the big core.  Only stone-type warriors
benefit from this, though, because you can pour thousands of
processes in a stone or a vampire, but not in a scanner.

	How about papers?  I don't think there's any paper on the
94x hill right now (my puny attempt, The Hunt, was quickly
discarded).  Why is that so?  I remember some discussion before the
big hill was set up where we said paper-type fast-replicating
warriors would have an advantage in the big core.  Apparently that
is not so, at least at the current state of the art.

	As usual, all comments are welcome.  I am fervent believer
in the '94 Big hill standard (mainly because that's the rules under
which I have been the most successful! :-) ).

;redcode-94x
;name Scanalyzer-V.3a
;author Jay Han
;strategy Scanner/Vampire
;macro

		org	scan

start		equ	loop-3
step		equ	-34

loop		add.f	inc,		scan
scan		cmp.i	start+step,	start
		slt.ab	#tail+200,	scan
count		djn.b	loop,		#27719
		mov.i	fang,		@scan
		sub.ba	scan,		@scan
		add.f	half,		scan
p		jmn.b	scan,		count
half		spl.b	#step,		<step
		mov.i	bomb,		<p
bomb		dat.f	<step-2,	<step-1
fang		jmp.b	pit-scan,	<step*2-1
for 54
		dat.f	0,		0
rof
inc
pit		spl.b	#step*2,	<step*2
trap		jmp.b	-1,		<step*2-1
for 54
		dat.f	0,		0
rof
m for 44
		dat.f	m+1,		-m-1
rof
for 33
		dat.f	0,		0
rof
tail		dat.f	0,		0

		end	scan


Article 2715 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!sdd.hp.com!elroy.jpl.nasa.gov!jlayland
From: jlayland@kilroy.jpl.nasa.gov (James Layland)
Newsgroups: rec.games.corewar
Subject: Re: Creating N procs
Date: 12 Apr 1994 18:01:25 GMT
Organization: Jet Propulsion Laboratory, Pasadena, CA  USA
Lines: 36
Message-ID: <2oenll$lr9@elroy.jpl.nasa.gov>
References: <1994Apr12.170950.7074@riacs.edu>
NNTP-Posting-Host: 128.149.63.2

In article <1994Apr12.170950.7074@riacs.edu>,
Dave Darling  <graphics_group@qmgate.arc.nasa.gov> wrote:
>     There have been times when I have wanted to create N processes that
>get to one particular instruction at the same time.  I eventually stole a
>bit of code from one program (Extra Extra???  I forget..) and modified it
>to suit my needs...

The way to do this is:

Subtract one from the number of processes you want.
Convert it to a binary number.
Write SPL 1 for every "1".
Write MOV -1, 0 for every "0".

E.g. to create 13 processes:
13-1 = 12.
12 = 1100 in binary

Your code should read

a SPL 1
b SPL 1
c MOV -1,0
d MOV -1,0
e ....        ; there will be 13 processes here

After executing a, there will be 2 processes at b.
After executing b, there will be 4 processes at c.
After executing c once, c becomes SPL 1; the other 3 processes each create a
 new process, for a total of 7 processes at d.
Similarly, d creates 7-1=6 new processes, for a total of 13 processes at e,
 which will all execute consecutively, as desired.

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


Article 2718 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!news.cs.utah.edu!utah-morgan!cs.utexas.edu!swrinde!ihnp4.ucsd.edu!ames!riacs!n243-fsc-4.arc.nasa.gov!graphics_group
From: Dave Darling <graphics_group@qmgate.arc.nasa.gov>
Subject: Creating N procs
Message-ID: <1994Apr12.170950.7074@riacs.edu>
X-Xxmessage-Id: <A9D024288F011EE4@n243-fsc-4.arc.nasa.gov>
X-Xxdate: Tue, 12 Apr 94 10:10:48 GMT
Sender: news@riacs.edu
Organization: RIACS, NASA Ames Research Center
X-Useragent: Version 1.1.3
Date: Tue, 12 Apr 94 17:09:50 GMT
Lines: 17

     There have been times when I have wanted to create N processes that
get to one particular instruction at the same time.  I eventually stole a
bit of code from one program (Extra Extra???  I forget..) and modified it
to suit my needs...
     I'm not sure, but I think that there's room for another tool/utility
program in this--how to get N processes going at once, such that all of
them will hit instruction at the "same time"  (i.e., "r"egisters in pMARS
would look like:  .... [M] -> M M M .....  )  I'm not entirely sure that
it's possible to have those processes be a contiguous chunk out of many
more.  If that confused you, what I mean is:  You've got ten processes
running.  You need six more for some symbiotic stuff you're doing.  Can
you get those six more to execute consecutively, without having one of
the other ten going between two of them?
     I'd give it a try, but I still don't see the pattern for creating N
processes.  Sigh.  Anyone else want to take a crack at it?

--DD


Article 2720 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Re: pMars for OS/2
Message-ID: <1994Apr12.052141.15343@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: <19940411210052IZZYVD5@MVS.OAC.UCLA.EDU>
Date: Tue, 12 Apr 1994 05:21:41 GMT
Lines: 16

In article <19940411210052IZZYVD5@MVS.OAC.UCLA.EDU> IZZYVD5@MVS.OAC.UCLA.EDU writes:
>My friend ported pMars to OS/2, and now he's working on a GUI version
>of it for Presentation Manager... He wants to know if there is any inter
>est for this OS/2 version, and any suggestions as to features he should
>add.  If he get's any interest, he might work a bit faster... :)

Great! Ask your friend to contact me, so we can coordinate integrating
OS/2 specific extensions into the base distribution. pMARS is a
continuously evolving team project; so it's important that ports to
other platforms don't become outdated as soon as we release a new 
version (Chris Lindensmith, are you still working on that Mac port
with display?).

-Stefan (stst@vuse.vanderbilt.edu)




Article 2721 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: pMARS v0.5.0 uploaded to soda
Message-ID: <1994Apr12.062713.15827@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: Tue, 12 Apr 1994 06:27:13 GMT
Lines: 85


I have just uploaded the latest version of pMARS to soda.berkeley.edu. For
now in pub/corewar/incoming, eventually in pub/corewar/systems are:

	pmars05s.zip - C source, portable zip archive
        pmars05s.tar.Z - same, tar'd and compressed
	pmars05.zip - DOS 16-bit executables (BC 3.1), pshell
        pmars05g.zip - DOS 32-bit execs (djgpp), supports large (94x) core

Anyone willing to update the Mac and Amiga ports at soda?

v0.5 has been running at stormking.com and pizza for the past few days. It 
is a major release in that it fixes one pretty serious overflow problem
that may occur with large coresizes. There are also a number of new
features and a menu-driven frontend for DOS, so it's probably worth
downloading. Below is the file "whatsnew.050".

Enjoy, Stefan (stst@vuse.vanderbilt.edu)
(for the pMARS group)

____________________
What's new in version 0.5.0

Bug fixes:

        o MULtiplying large numbers in a large coresize (55440) can no longer
          produce an overflow-related segmentation fault

        o END without argument no longer overrides a previous ORG statement

New features, Simulator/Assembler:

        o added three experimental opcodes:
                SEQ (Skip if EQual, synonym for CMP)
                SNE (Skip if Not Equal, opposite of SEQ)
                NOP (No OPeration = do nothing)
          [You can disable these by compiling without -DNEW_OPCODES]

        o added predefined variables that you can reference in your warrior
          source:
                CORESIZE
                MAXPROCESSES
                MAXLENGTH
                MINDISTANCE
                MAXCYCLES

        o Redcode expressions can now contain C-style comparison and boolean
          operators. Together with predefined variables, this can be used to
          write redcode that adjusts to the core parameters, e.g.:

                POINT   EQU (CORESIZE == 55440)*13 + (CORESIZE == 8000)*3


        Debugger (cdb):

        o The DOS debugger has two side-by-side, independendly scrollable
          display panels. This allows for simultaneous display of both
          warriors, code vs. addresses accessed by code, etc.. The SWITCH
          (macro: <Tab>) and CLOSE (macro: <Shft-Tab>) commands control the
          panel display.

        o The macro language has been enhanced with nestable loop blocks
          (!!~cmd~...~![n]), a macro termination command (RESET), and
          conditional execution via the IF command. It is now possible to
          write complicated macros for automatic selection of constants,
          stepping through code until a particular condition is met, etc..
          The default macro file "pmars.mac" contains a few sample macros,
          including one that calculates imp numbers.

        o The process queue is now as accessible for debugging as the core
          array using the new PQUEUE command. PQUEUE switches cdb into
          "process queue mode" in which the LIST, EDIT and FILL commands act
          on the process queue instead of the core array. PQUEUE is useful
          for debugging complicated multi-process warriors, like
          imp-spiral/stone combos. E.g., it is easy to find out whether a
          spiral executes without "gaps" and how many processes are executing
          a given core location (and to automate these tasks with macros).

	pshell:
          
          The DOS version of pMARS (pmars05.zip) now includes a menu-driven
          frontend. pshell allows you to select warriors from a directory
          listing, configure pMARS and the tournament scheduler MTS from
          pull-down menus, and call an external editor. If you like mars88's
          interface, pshell is for you.


Article 2722 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!uhog.mit.edu!news.kei.com!ub!acsu.buffalo.edu!bcohen
From: bcohen@acsu.buffalo.edu (Bram Cohen)
Subject: Re: Creating N procs
Message-ID: <Co5zq1.642@acsu.buffalo.edu>
Sender: nntp@acsu.buffalo.edu
Nntp-Posting-Host: lictor-14.acsu.buffalo.edu
Organization: University @ Buffalo
References: <1994Apr12.170950.7074@riacs.edu>
Date: Tue, 12 Apr 1994 21:01:10 GMT
Lines: 28

In article <1994Apr12.170950.7074@riacs.edu>,
Dave Darling  <graphics_group@qmgate.arc.nasa.gov> wrote:
>     I'm not sure, but I think that there's room for another tool/utility
>program in this--how to get N processes going at once, such that all of
>them will hit instruction at the "same time"  (i.e., "r"egisters in pMARS
>would look like:  .... [M] -> M M M .....  )  I'm not entirely sure that
>it's possible to have those processes be a contiguous chunk out of many
>more.  If that confused you, what I mean is:  You've got ten processes
>running.  You need six more for some symbiotic stuff you're doing.  Can
>you get those six more to execute consecutively, without having one of
>the other ten going between two of them?

The imp-spiral generation program discussed a little while ago did this.
Just string together a bunch of SPL 1's and MOV -1,0's in the right order.
For example:

start		SPL	1
		SPL	1
		MOV	-1,0
		SPL	1
		MOV	-1,0
		MOV	0,1

will create an imp which gets executed six times before moving to the next
position. The streams are automatically consecutive since they were all
generated by the same initial stream.




Article 2724 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!ames!riacs!n243-fsc-1.arc.nasa.gov!graphics_group
From: Dave Darling <graphics_group@qmgate.arc.nasa.gov>
Subject: s4b source
Message-ID: <1994Apr13.170929.17474@riacs.edu>
X-Xxmessage-Id: <A9D1759577011EE1@n243-fsc-1.arc.nasa.gov>
X-Xxdate: Wed, 13 Apr 94 10:10:29 GMT
Sender: news@riacs.edu
Organization: RIACS, NASA Ames Research Center
X-Useragent: Version 1.1.3
Date: Wed, 13 Apr 94 17:09:29 GMT
Lines: 27

     I am posting the source for s4b, a simple four-line (grew to five)
bomber which made it onto the hill by the skin of its teeth (and, I think,
by someone killing one of their other programs....).
     It's nothing special, but the curious thing is that it converts it-
self into a slow core clear.  A DAT instruction winds up at "start", and
it makes the ADD affect something way out in core somewhere.  The B-field
of "stone" is pointing to "start", and the autodecrement, MOV, (essentally
no-op) ADD, and DJN wind up clearing core.  Some constant fiddling could
probably adjust this so that the SPL is left alive--unforunately, this 
version suicides at the end of the clear.

;redcode
;name   s4b
;author D. Darling
;strategy       Simple 4-line Bomber
;strategy       Apologies if this = Herem, etc...
;strategy       Now 5-line: self-SPL+core clear

step    EQU     2365

start   SPL     0,      <-10
stone   MOV     <-6,    <-12
        ADD     inc,    stone
        DJN     stone,  <-3
inc     DAT     <step,  <step

        END     start


Article 2725 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!news.umbc.edu!eff!news.kei.com!ssd.intel.com!wms
From: wms@ssd.intel.com (William Shubert)
Subject: KotH server at ssd.intel.com down
Message-ID: <Co7LzA.E6J@SSD.intel.com>
Sender: usenet@SSD.intel.com
Nntp-Posting-Host: snowcrash
Organization: Supercomputer Systems Division (SSD), Intel
Date: Wed, 13 Apr 1994 17:59:33 GMT
Lines: 6

   Well, it's been three days since the KotH server at my site got any
mail, so I guess that the traffic has moved to the new Pizza server.
I'll be taking my server down now; thanks everybody who used it, and
thanks to Tom Davies for setting up the replacement!  Bye!
				-Bill (wms@ssd.intel.com)



Article 2726 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 3...
Date: 14 Apr 1994 00:06:25 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 18
Message-ID: <2oi1e1$afv@agate.berkeley.edu>
NNTP-Posting-Host: soda.berkeley.edu

OK, this is it.  I think that the time has come for MNCT to end... maybe this
view is partially caused by the fact that I couldn't run round 3 with
pmars0.4 because it kept crashing with a segmentation fault (I assume this
is due to the bug mentioned in the whatsnew.050 file).  However, with the
new version, Alex MacAulay's program won't even compile because (apparently)
the "coresize" variable has been removed.  Unfortunately his program
depended on the coresize variable and won't even get close to running
without it (am I right, Alex?)

Anyway, if anyone else wants to finish up round 3 (and possibly continue
the tournament) this is fine with me and I'll mail the good person the
submissions for round 3.  If not, I think I'll just post the code for
round 3 and then get on with my life... running a corewar tournament
sure does take a lot of time... <sigh>
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2731 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!news.cs.utah.edu!utah-morgan!cs.utexas.edu!convex!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Announcing: Spring '94 EBS tourney (was Re: MNCT Round 3...)
Message-ID: <1994Apr14.162256.14961@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: <2oi1e1$afv@agate.berkeley.edu>
Date: Thu, 14 Apr 1994 16:22:56 GMT
Lines: 32

In article <2oi1e1$afv@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes:
>OK, this is it.  I think that the time has come for MNCT to end... 
> [...],  Alex MacAulay's program won't even compile because (apparently)
>the "coresize" variable has been removed.   [...]

Not removed, but renamed to "CORESIZE" (identifiers are case-sensitive).

>               Michael Constant (mconst@soda.berkeley.edu)

Anyway, thanks for holding the tournament. I particularly liked the "white
warrior" problem and the prime-factorization round. We should repeat this
some time, with fewer weeks between rounds.

In the meantime, I am going to hold a double-elimination tournament with
weekly rounds, just like the summer and fall tourneys of last year
(soda.berkeley.edu:/pub/corewar/redcode/st93warriors.zip includes a rapport
of this kind of tourney).

Rules will alternate between '94 (coresize=8000) and '94x (coresize=55440)
hill specs. If there's demand, I'll also throw in a pure '88 round. If there
are enough participants, I'll divide them up into an A- and B-league (verterans
and beginners).

The submission deadline for round 1 is Friday, April 22nd. Rules are '94x (big)
hill specs, and you may use the new opcodes. Your opponent in round 1 will be
chosen randomly. 

And as though the fame was not enough incentive already, the tournament
winner will receive a free ICWS membership and subscription to the
newsletter for one year.

-Stefan (stst@vuse.vanderbilt.edu)


Article 2734 of rec.games.corewar:
Path: hellgate.utah.edu!utah-morgan!cs.utexas.edu!usc!nic-nac.CSU.net!charnel.net.csuchico.edu!charnel!sd
From: sd@ecst.csuchico.edu (Bruno Puntz Jones)
Newsgroups: rec.games.corewar
Subject: The Pizza Hill
Date: 14 Apr 1994 19:12:20 GMT
Organization: California State University, Chico
Lines: 40
Message-ID: <2ok4ikINNcod@charnel.ecst.csuchico.edu>
NNTP-Posting-Host: corpse.ecst.csuchico.edu

The Pizza Hill is officially open for business until furter notice.
Special thanks to Stefan Strack for all the help setting this monster up,
and to all you out there who sent in your warriors and showed me this
wasn't going to be a big waste of time. :)

Here is a list of KotH related services.  To access any of these, simply
send mail to (pizza@ecst.csuchico.edu) with the service as the subject.

info, help   - Sends you a complete list of services and some helpful
               information on getting started.

koth         - Submit your corewar programs for challenge of the Pizza
               Hill.  For more information try "koth info".  Additional
               sub-commands are:

               submit     - submit a warrior (default)

               help, info - mails you infomation on the Pizza Hill

               status     - returns the current rankings of the hills

               faq        - mails you the rec.games.corewar FAQ

bugs, beej   - Either will take your message body and forward it to
               beej@ecst.csuchico.edu (and others).  Use this to send
               in bug reports.

I am still looking for input on the ICWS'88 Experimental hill. The most
interesting idea I could think of has recieved a total of three submissions
in the last week (one of them from me :).  Simply mail them to the Pizza
Server with the subject of "bugs", or it might be better to discuss the
ideas here.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~\/~~\ /~~~\/\  / \  \ / /~\ /~~~YY~~~\\   /~~~~
  Thomas H. Davies               V       \/\ /\  V /   V  |\/\/|  V\ /
sd@ecst.csuchico.edu  "Hard before beer,    V  \  /       |  / |    V
                       you're in the clear;     \/        | /\ |
  Member C.W.M.        beer before hard,     Motto of     |/oo\|
   Since 1987          you're in the yard." Chico State    |/\|


Article 2735 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!news.cs.utah.edu!utah-morgan!cs.utexas.edu!howland.reston.ans.net!europa.eng.gtefsd.com!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Re: The Pizza Hill
Message-ID: <1994Apr14.194620.20014@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: <2ok4ikINNcod@charnel.ecst.csuchico.edu>
Date: Thu, 14 Apr 1994 19:46:20 GMT
Lines: 21

In article <2ok4ikINNcod@charnel.ecst.csuchico.edu> sd@ecst.csuchico.edu (Bruno Puntz Jones) writes:
>I am still looking for input on the ICWS'88 Experimental hill. The most
>interesting idea I could think of has recieved a total of three submissions
>in the last week (one of them from me :).   [...]
>  Thomas H. Davies               V       \/\ /\  V /   V  |\/\/|  V\ /

How about a "chaos" or "random" hill: for each submission, pick a coresize
at random, but within a given interval. Other parameters are calculated
based on the random coresize value:
	max processes = coresize
        cycles        = coresize * 10
        max length    = coresize < 32768 ? 100 : 200
        min distance  = max length
(just an example)

Since you can use CORESIZE, MAXPROCESSES, etc. in your warrior, writing 
efficient code for the random hill shouldn't be too taxing. BTW, this better
be a ICWS'94 draft hill, because MUL and DIV can make your life a lot easier.

-Stefan (stst@vuse.vanderbilt.edu)



Article 2737 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!news.cs.utah.edu!utah-morgan!cs.utexas.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!hookup!batcomputer!cornell!uw-beaver!cs.washington.edu!jayhan
From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: Re: The new Pizza server is great!
In-Reply-To: fullanto@cwis.isu.edu's message of 12 Apr 1994 19:10:43 PST-8
Message-ID: <JAYHAN.94Apr14132611@derkins.cs.washington.edu>
Lines: 103
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington
References: <JAYHAN.94Apr11164328@derkins.cs.washington.edu> <2oernj$g0i@cwis.isu.edu>
Date: 14 Apr 1994 13:26:11 GMT

In article <2oernj$g0i@cwis.isu.edu> fullanto@cwis.isu.edu (FULLMER_ANTONETTE) writes:

> From: fullanto@cwis.isu.edu (FULLMER_ANTONETTE)
> Subject: Re: The new Pizza server is great!
> Date: 12 Apr 1994 19:10:43 PST-8
> 
>    Could somebody post the address for the new server?  My news reader 
> only keeps about the last 30 messages or so, it seems...  
>    Also, instructions about how to post a warrior to the hill would be 
> extremely helpful.  Thanks

Following this message is an excerpt of the original posting.

	BTW, what's going to happen to _Push_Off_ and _The_'94_Warrior_,
now that we have both Hills on the same site?  It seems that there's
a move to permanently phase out the '88 standard.  My own experience
is that the two remaining Hills (94 and 94-X) are significantly
different.  I feel that if there are going to be two "reviews", they
should be _The_Small_Warrior_ and _The_Big_Warrior_ (OK, so I'm
biased toward the big Hill :-) ).

--------------------------------------------------------------------
To submit your corewar programs to the Pizza Hill, simply mail them to
pizza@ecst.csuchico.edu with the subject of "redcode" or "koth".

Due to the variety of services the Internet Pizza Server provides, your
mail _must_ have a subject of "redcode" or "koth" or you will recieve an
error message.  This is easily done with the -s switch in most mailers.
For example, if you usually used the command:

	"cat test.red | mail koth@stormking.com"

to submit the same program to the Pizza Hill, you would use the command:

	"cat test.red | mail -s 'redcode' pizza@ecst.csuchico.edu"

It's as simple as that.

I am looking for input on the ICWS'88 Experimental hill. The most interesting
idea I could think of is listed below, but I'm looking for better, more
permanent ideas.  Also, any ideas on the beginner's hill would be appreciated
as well.

Bug reports, ideas, and anything else you want to tell me should be mailed
to sd@ecst.csuchico.edu, or to the Pizza Server with the subject of "bugs".

and now, here are the specs of the various hills:

ICWS'88 Standard Hill Specs: (Accessed with ";redcode")
         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'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x")
         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")
         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")
         coresize: 8000
   max. processes: 8000
         duration: after 80,000 cycles, a tie is declared.
max. entry length: 100
 minimum distance: 100
      maximum age: At age 100, warriors are retired.
  instruction set: ICWS '94 Draft

ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x")
         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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~\/~~\ /~~~\/\  / \  \ / /~\ /~~~YY~~~\\   /~~~~
  Thomas H. Davies               V       \/\ /\  V /   V  |\/\/|  V\ /
sd@ecst.csuchico.edu  "Hard before beer,    V  \  /       |  / |    V
                       you're in the clear;     \/        | /\ |
  Member C.W.M.        beer before hard,     Motto of     |/oo\|
   Since 1987          you're in the yard." Chico State    |/\|
--------------------------------------------------------------------

	See you on the Pizza Hill!

-=<|  Jay "Thierry" Han  |>=-       e-mail: jayhan@cs.washington.edu
Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969
U. of Washington. Seattle, WA 98195, USA.   [Sieg 230] (206)685-1224
Personal: 4820 Burke Ave N. Seattle, WA 98103, USA.    (206)547-8559


Article 2741 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!utah-morgan!cs.utexas.edu!howland.reston.ans.net!news.intercon.com!panix!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!math.utah.edu!news.math.utah.edu!morrell
From: morrell@math.utah.edu (Steven C. Morrell)
Subject: B-Panama V
Sender: news@math.utah.edu
Date: Fri, 15 Apr 1994 17:17:00 GMT
Organization: Department of Mathematics, University of Utah
Message-ID: <MORRELL.94Apr15111701@glab6.math.utah.edu>
Lines: 76

Here is the source for B-panama V, a stone with paper backup.  It reached
the age of 107 on the Intel hill before the Great Core Dump, and is now
hovering about 10th on the standard Pizza Hill.  The stone hogs most of
the processes, so even if a copy of the paper gets stunned, the stone can
often grind out a win.  If all runs smoothly, the stone will do an addition
core-clear and then commit suicide.  The bits of imp-killing paper then take
over.  The key of this paper is that it must be virulent enough to survive
attacks form both the stone and the other program, even when slowed down.

Here's how it does on the Pizza Hill:

Keystone t21              53/10/37
Christopher               47/42/11
SJ-4a                     42/30/28
Dragon Spear              41/45/14
Iron Gate 1.5             38/49/13
Juggernaut v1.5           38/49/13
Night Crawler             35/ 5/60
Vanity II                 35/44/21
Request v2.0              33/33/34
B-Panama V                24/  /55
CAPS KEY IS STUCK AGAIN   22/30/48
Killer instinct           18/16/66
FlyPaper 3.0              13/21/66
Impact v1.0               11/ 7/82
Montage                   11/13/76
Yop La Boum v2.1          10/29/61
Der Zweite Blitzkrieg     10/37/53
ttti                       6/ 7/87
Deck of Many Things        6/34/60
Patapouf v2.0              3/13/84


;redcode verbose
;name B-Panama V
;author Steven Morrell
;strategy  Let's see if we can pick on some imps...
;strategy  Version 5- complete overhaul of stone and paper.

stone     spl 0,<-50
          spl 0,<-51
          mov <3359,-3359
          add 2,-1
          djn -2,<-54
          dat <3359,<-3359

boot      mov stone+5,-200+5
          mov stone+4,<boot
          mov stone+3,<boot
          mov stone+2,<boot
          mov stone+1,<boot
          spl boot-200
          mov stone,<boot

a         spl 1
          mov 1,0
          spl 1
          mov #6,0
          mov <-1,<1
          spl @0,-3365
          mov 2,<-1
          jmz -4,-4
          dat <2667,<5334

          dat <last,<2667
          dat <last,<2667
          dat <last,<2667
                 :
  decoy removed to save bandwidth
                 : 
last      dat <last,<2667

end boot

Steven Morrell               morrell@math.utah.edu



Article 2742 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!ames!olivea!news.hal.COM!decwrl!waikato!auckland.ac.nz!dnor01.cs.aukuni.ac.nz
From: dnor01@cs.aukuni.ac.nz (David Hikaru  Norman)
Newsgroups: rec.games.corewar
Subject: Best ever CoreWarrior?
Date: 16 Apr 1994 10:27:20 GMT
Organization: University of Auckland
Lines: 9
Message-ID: <2ooei8$7it@ccu2.auckland.ac.nz>
NNTP-Posting-Host: cs7.cs.aukuni.ac.nz
X-Newsreader: NN version 6.5.0 #7 (NOV)

One that writes to the core display in such a way as to spell out the message:

"Terminate the others!"

Sorry if this is a really old (and no longer funny) idea, but I just thought
of it. And it wasn't in the FAQ.

David Norman (dnor01@cs.aukuni.ac.nz)
" Of course, I see things like this...X-| " - policeman from the Young Ones


Article 2744 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!usc!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: KotH server at ssd.intel.com down
Message-ID: <1994Apr16.171558.1@acad.drake.edu>
Lines: 11
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
References: <Co7LzA.E6J@SSD.intel.com>
Date: Sat, 16 Apr 1994 23:15:58 GMT

>    Well, it's been three days since the KotH server at my site got any
> mail, so I guess that the traffic has moved to the new Pizza server.
> I'll be taking my server down now; thanks everybody who used it, and
> thanks to Tom Davies for setting up the replacement!  Bye!
> 				-Bill (wms@ssd.intel.com)
> 

Thank you Bill, for being the first.

Paul Kline
pk6811s@acad.drake.edu


Article 2745 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!munnari.oz.au!cs.mu.OZ.AU!kakadu7!macaulay
From: macaulay@kakadu7.ecr.mu.oz.au (Alexander_William MACAULAY)
Subject: Re: MNCT Round 3...
Message-ID: <9410811.8744@mulga.cs.mu.OZ.AU>
Sender: news@cs.mu.OZ.AU
Organization: D.E.C.R. Uni of Melbourne, Australia
References: <2oi1e1$afv@agate.berkeley.edu>
Date: Mon, 18 Apr 1994 01:51:11 GMT
Lines: 18

In article <2oi1e1$afv@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes:
>OK, this is it.  I think that the time has come for MNCT to end... maybe this
>view is partially caused by the fact that I couldn't run round 3 with
>pmars0.4 because it kept crashing with a segmentation fault (I assume this
>is due to the bug mentioned in the whatsnew.050 file).  However, with the
>new version, Alex MacAulay's program won't even compile because (apparently)
>the "coresize" variable has been removed.  Unfortunately his program
>depended on the coresize variable and won't even get close to running
>without it (am I right, Alex?)

Yep, that's right. One option would be for you to put a 'coresize equ ...'
at the top of the program. Anyway, I thought that you had already run the
round 3 and posted the results some time ago. If this is the end, I'd like
to say that I've enjoyed participating in this tournament and that it was
quite unique in the variety of its rounds. I hope to see something like
this again in the future.

Alex MacAulay (macaulay@ecr.mu.oz.au).


Article 2746 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: Re: MNCT Round 3...
Date: 18 Apr 1994 19:01:26 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 20
Message-ID: <2oule6$59b@agate.berkeley.edu>
References: <2oi1e1$afv@agate.berkeley.edu> <9410811.8744@mulga.cs.mu.oz.au>
NNTP-Posting-Host: soda.berkeley.edu

Alexander_William MACAULAY <macaulay@kakadu7.ecr.mu.oz.au> wrote:
> Anyway, I thought that you had already run the round 3 and posted the
> results some time ago.

The results you saw were only for the first coresize I used in testing.
Since it was a variable coresize round, I thought it would only be fair
to run it in more than one coresize, to get an accurate impression of how
well the different programs do.  However, the first coresize I used (the
one you saw the results for) was small (I don't remember the number) and
pmars crashed as soon as it was in a big coresize so I couldn't run the rest.

> If this is the end, I'd like to say that I've enjoyed participating in
> this tournament and that it was quite unique in the variety of its rounds.
> I hope to see something like this again in the future.

Glad you enjoyed it!
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2749 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: The '94 Warrior
Date: 18 Apr 94 23:46:26 MDT
Message-ID: <1994Apr18.234626.6872@hellgate.utah.edu>
Originator: bdthomse@peruvian.cs.utah.edu
Organization: University of Utah CS Dept

__ __| |            ) _ \  |  |    \ \        /              _)           
   |   __ \   _ \  / (   | |  |     \ \  \   / _` |  __|  __| |  _ \   __|
   |   | | |  __/   \__  |___ __|    \ \  \ / (   | |    |    | (   | |   
  _|  _| |_|\___|      _/    _|       \_/\_/ \__,_|_|   _|   _|\___/ _|   
                                                                          
April 18, 1994                                                        Issue #6
______________________________________________________________________________

This newletter covers the current status of the ICWS '94 Draft hills,
and also attempts to keep up with the latest ideas in how the new standard
will affect corewars in general.  I hope you enjoy it!

If you are unfamiliar with the '94 draft standard, you can learn more about
it by reading the FAQ for this newsgroup.  In addition, the program pMARS
includes a highly recommended tutorial on the new standard.  Feel free
to send me e-mail if you have any difficulty finding either of them, if you
need to have a corewar item mailed to you, or if you have any other questions.

The FAQ is available through anonymous FTP to rtfm.mit.edu, as
/pub/usenet/news.answers/games/corewar-faq.Z
______________________________________________________________________________

CHANGES and CORRECTIONS:

There have been several changes since the last issue of _The_'94_Warrior_
came off the electronic presses.  With luck, I'll manage to get most of them.

The first big event is the addition of two (or three) new opcodes for
version 0.5 of pMARS.  It was recently downloaded to soda.berkeley.edu
(in the pub/corewar/incoming directory).  Even if you don't think you will
ever need to use SEQ, SNE, or NOP, there are a couple of bug fixes that make
it worth the effort to upgrade.

The another big event is the creation of a new hill server, "pizza".  "Pizza"
is operated by Thomas Davies, and he's doing a great job at it!  Most of the
programs residing at the "Intel KotH" and "stormking" have already managed to
migrate over, and there are several new programs on "pizza" as well.  The
"pizza" hills eliminate the major complaint users had with the "stormking"
hills:  you no longer need to wait a day or two to get back the results of a
warrior submission.  (The process of submitting a warrior to a hill on "pizza"
is covered in the latest FAQ for the rec.games.corewar newsgroup.  Send me
mail if you didn't receive a copy of it.)

Along with the creation of the "pizza" server came the passing of the Bill
Shubert's hill at Intel.  Thanks, Bill, for the many years you have used your
resources to allow the rest of us to hone our corewars skills.  The game has
improved greatly because of your efforts!

You'll also want to catch the first chapter of Steven Morrell's "MY FIRST
COREWAR BOOK".  It's on soda.berkeley.edu in the pub/corewar/incoming
directory as "chapter1.Z".  Even if Steven didn't mention my name in it and
he attended some school other than the University of Utah, I would still
recommend it.  It's that good!

For those of you developing warriors in large core sizes, the upgraded version
of Optima I mentioned in the last issue is now available on soda.  If you are
experimenting with different core sizes (like the small core on "pizza", this
program is a necessity.)

And, for those of you with a competitive streak, I would highly encourage you
to enter Stefan Strack's upcoming corewar tournament.  In case you missed the
announcement, here it is again:

  In the meantime, I am going to hold a double-elimination tournament with
  weekly rounds, just like the summer and fall tourneys of last year
  (soda.berkeley.edu:/pub/corewar/redcode/st93warriors.zip includes a rapport
  of this kind of tourney).

  Rules will alternate between '94 (coresize=8000) and '94x (coresize=55440)
  hill specs. If there's demand, I'll also throw in a pure '88 round. If there
  are enough participants, I'll divide them up into an A- and B-league
  (verterans and beginners).

  The submission deadline for round 1 is Friday, April 22nd. Rules are '94x
  (big) hill specs, and you may use the new opcodes. Your opponent in round 1
  will be chosen randomly. 

  And as though the fame was not enough incentive already, the tournament
  winner will receive a free ICWS membership and subscription to the
  newsletter for one year.

  -Stefan (stst@vuse.vanderbilt.edu)

Just in case those prizes are not good enough for you, I will also throw in a
free one-year subscription to _The_'94_Warrior_ for the winner.  Seriously
though, Stefan always does a great job with his tournaments, and I heartily
recommend you give this one a try.
______________________________________________________________________________

The ICWS '94 Draft Hill:

       Core size:	8000 instrucitons
   Max processes:	8000 per program
        Duration:	After 80,000 cycles, a tie is declared.
Max entry length:	100 instructions

The current ICWS '94 Draft hill:
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  45/ 20/ 34 Der Zweite Blitzkrieg - 9      Mike Nonemacher     170      13
 2  47/ 31/ 21               Sauron v1.7     Michael Constant     163       3
 3  42/ 30/ 28           Killer instinct         Anders Ivner     154      64
 4  46/ 41/ 13              Dragon Spear             c w blue     151      63
 5  36/ 22/ 42                   Lucky 3        Stefan Strack     150      23
 6  43/ 36/ 21              Request v2.0     Brant D. Thomsen     149      61
 7  45/ 43/ 12             Iron Gate 1.5       Wayne Sheppard     148       7
 8  31/ 17/ 53                 Blue Funk       Steven Morrell     145      30
 9  33/ 21/ 46       Twimpede+/8000-E.2c              Jay Han     144      17
10  32/ 21/ 47         Imperfection v3.1     Michael Constant     142      15
11  34/ 26/ 40                     NC 94       Wayne Sheppard     142      43
12  31/ 24/ 44                    Splash              Jay Han     139       1
13  38/ 38/ 25                    NTA 94       Wayne Sheppard     137      51
14  40/ 43/ 17                      Test        Stefan Strack     137      26
15  40/ 42/ 18            Sylvester v1.0     Brant D. Thomsen     137      60
16  38/ 41/ 22            Fast Food v2.1     Brant D. Thomsen     134      58
17  34/ 34/ 32               Match Stick             c w blue     133      41
18  31/ 32/ 37          Little Flea v1.2     Michael Constant     129       5
19  38/ 49/ 13               Dagger v6.0     Michael Constant     126      67
20  32/ 45/ 23             Assassin v1.0     Michael Constant     119      20

For this issue, I was planning to post the results of both the "stormking" and
"pizza" '94 hills.  However, as I haven't gotten back the results of the
queries I sent to "stormking" almost four days ago, I decided to simply make
a clean switch to pizza this month.  Send any complaints to the editorial
board.

I believe most of the programs that are on the '94 draft hill on "stormking"
have made it over to "pizza".  Next issue, after things have settled down a
little bit on the new hills, I will attempt to analyze what is happening.
______________________________________________________________________________

The ICWS '94 Draft Experimental Hill:

       Core size:	55,440 instructions
   Max processes:	10,000 per program
        Duration:	After 500,000 cycles, a tie is declared.
Max entry length:	200 instructions

The current ICWS '94 Experimental (Big) hill:
 #  %W/ %L/ %T                      Name               Author   Score     Age
 1  49/ 15/ 36             Variation G-1              Jay Han     182       1
 2  47/ 15/ 38           Variation E-2.c              Jay Han     178      13
 3  44/ 16/ 39                  Splash 1              Jay Han     172       2
 4  45/ 22/ 32                  Lucky 13        Stefan Strack     168      43
 5  49/ 32/ 20             Request-55440     Brant D. Thomsen     165      37
 6  35/ 18/ 47         Imperfection v2.4     Michael Constant     153       8
 7  47/ 41/ 12                   Rave B4        Stefan Strack     153      29
 8  45/ 42/ 13                     Virus              Jay Han     148       3
 9  44/ 43/ 13                  bigproba        nandor sieben     145      41
10  42/ 46/ 12              Scanalyzer-W              Jay Han     138       4
11  42/ 46/ 13           Scanalyzer-V.3b              Jay Han     138      11
12  35/ 33/ 32             Big Flea v1.1     Michael Constant     137       7
13  38/ 46/ 15                amoeba v82 Richard van der Brug     131      18
14  38/ 47/ 15               Dagger v8.0     Michael Constant     130      24
15  38/ 46/ 16               Sunburst 33              Jay Han     130      31
16  30/ 31/ 38                 Nova-A.1b                  Jay     129      12
17  29/ 32/ 39                 Skimp 127              Jay Han     127      30
18  34/ 42/ 23               IceCube 1.4 Richard van der Brug     126      17
19  32/ 40/ 28                Veeble Jr.         T. H. Davies     125      27
20  36/ 51/ 13              Kill Imps!!!       Steven Morrell     121      26

The comments for the other hill apply here as well.
______________________________________________________________________________

HINTS and HELPS:

For today's hint, I will be using the source code to "Request v2.0"
for the 55440 size '94 hill.  "Request" is very similar to my earlier
"Distance" vampires (I know, I'm stuck in a rut ...) with the exception
that the fangs use indirect addressing instead of direct addressing to
send the processes to the pit.  By using a two line piece of code that 
contuously rewrites the reference value used by the fangs, I can "undo"
any damage caused by standard anti-vampire programs.

                                *   *   *

Writing code for a large coresize provides an interesting challenge.
Possibly the most frustrating thing about it is that it is hard to display
and analyze 55440 locations.  I find that, more than ever, I am forced to 
rely on other programs to help me generate the information I want for my
corewars warriors.

For instance, when I wanted to make the '94 version of my vampire "Request"
run in the 55440 coresize, I tried several things to make the process easier.
As you may have guessed by reading the last issue of _The_'94_Warrior_, one
of the first programs I used was "Optima" by Michael Constant.

This, however, was just the beginning.  Take a look at the following "c" code:


/* Determine coverage with different RedCode spacing for bombers */

#include <stdio.h>
#include <stdlib.h>

#define WIDTH 80

int main(int argc, char *argv[])
{
	long sp, coresize, first, step, lines = WIDTH+1, printed, count;
	int i, core[WIDTH];

	if (argc < 4 || argc > 5) {
		printf("\nUsage:  %s coresize step first [lines]\n", argv[0]);
		return 0;
	}

	coresize = atol(argv[1]);
	step = atol(argv[2]);
	if(step < 0)
		step += coresize;
	first = atol(argv[3]);

	if(argc > 4)
		lines = atol(argv[4]);

	for(i = 0; i < WIDTH; i++)
		core[i] = 0;

	printed = 0;
	sp = first;
	count = 0;
	printf("%ld:\n", step);

	do {
		if(sp >= 0 && sp < WIDTH) {
			core[sp] = 1;
			for(i = 0; i < WIDTH; i++)
				if(i == first)
					printf("@");
				else
					printf("%c", core[i] ? '*' : ' ');
			printed++;
		}

		sp += step;
		sp %= coresize;
		count++;
	} while(sp != first && printed < lines);

	printf("\nMod: %ld\n", coresize / count);

	return 0;
}



This program simply takes an imaginary chunk of computer core with a given
starting point and step size, and plots how that piece of core will be hit
up as the bombing progresses.  Then I was able to simply take the pieces of
request and fit them into the spaces that were hit latest.
(Since my computer screen is 80 columns wide, I simply used that size of
core.  Feel free to change WIDTH as appropriate.)  In the output, the "@"
indicates the very first location bombed (if it is in the range printed).
Of course, you can also make that the last location bombed by simply adding
one step value to your starting value.

Also, take a look at the bootstrapping code itself.  By using the "FOR" macro,
and using the "SUB" statements in my bootstrapping code, it is trivial to
change the locations of the different parts of the vampire, because the 
distances between them are automatically computed by the boot-strapping code
based on the number of "DAT" statements between the segments.  I can even
change the order of the segments without touching my bootstrapping code; I
simply use the cut an paste tools in my editor to rearrange the segments as
I wanted them.

The end result:  a competitive program that I have never run inside of a 
size 55440 core.  Is this a good way to go about it?  I have no idea.  It is,
however, an excellent example about how much trouble some people will go to
to avoid a little bit of work.

                                *   *   *

;redcode-94x
;name Request-55440
;author Brant D. Thomsen
;strategy '94 Vampire
;strategy The latest program in my "quest"
;strategy to yield less wins to anti-vampiric programs.
;strategy Submitted: @date@

step	equ	9719
init	equ	(pit+1+step)

gate	equ	(jump-12)
decoy	equ	(gate-1+step)

FOR 132
	dat	#start*10, #1	; Provide a large decoy.
ROF

start	mov	jump, <dist

	sub	#jump-adder-1, dist

	mov	adder, <dist

	sub	#adder-pit-5, dist

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

	sub	#pit-vamp-4, dist

	mov	vamp+3, <dist
	mov	vamp+2, <dist
	mov	vamp+1, <dist
	mov	vamp, <dist
	spl	@dist, <10000	; Start the vampire

	sub	#vamp-help-2, dist

	mov	help+1, <dist
	mov	help, <dist
	spl	@dist, <20000	; Send 2 processes to "help" so that will
	spl	@dist, <30000	; execute "MOV" once cycle.

	sub	#help-wimp-1, dist

	mov	wimp, <dist
	spl	@dist, <40000

	sub	#10000, dist	; Erase record of where boot-strapped.
dist	dat	#15501		; Then kill the process.


	; The following is the code for the program.
	; Spacing (for DATs between segments) is computed automatically.

jump	jmp	@decoy-init, init

FOR 8
	dat	#start*10, #1
ROF

	; Wimp is necessary so will still have a process when pit dies.
	; Runs no risk of starvation since no SPL in it.

wimp	jmp	#0, <gate

FOR 3
	dat	#start*10, #1
ROF

pit	mov	@8, <gate-1
	spl	#0, <gate
	spl	-2, <gate
	spl	-2, <gate
	djn.F	pit, >adder-2

FOR 9
	dat	#start*10, #1
ROF

help	mov	#pit-decoy, decoy
	jmp	help, <gate

FOR 6
	dat	#start*10, #1
ROF

adder	dat	<-step, <step

FOR 3
	dat	#start*10, #1
ROF

vamp	spl	#0, <gate
move	mov	@0, @jump
	add	adder, @move
	djn.F	-2, <-step

	end	start
______________________________________________________________________________

Looking to the Future:

There promise to be some interesting times ahead for the '94 draft, the '94
hills, and _The_'94_Warrior_.  With the advent of the "pizza" hills, I have
no doubt that the number and quality of warriors on the '94 hills will
increase at an unprecedented rate.  (In fact, one could probably argue that
they already have.)  Of course, this also means that those of you who have
been putting off experimenting around with the new standard no longer have an
excuse!  (Well, not a _good_ excuse.)

If you have any comments or questions about the '94 hills or the '94
standard that you think might be of general interest, please let me know.

Good luck, and happy computing!
______________________________________________________________________________

Brant D. Thomsen, Editor	   Snail mail:	1197 East 6290 South
(bdthomse@peruvian.cs.utah.edu)			Salt Lake City, UT  84121
University of Utah				U.S.A.
-- 
Brant D. Thomsen                  Man will occasionally stumble over the truth,
(bdthomse@peruvian.cs.utah.edu)   but most times he will pick himself up
University of Utah                and carry on.             - Winston Churchill


Article 2750 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!usc!howland.reston.ans.net!usenet.ins.cwru.edu!lerc.nasa.gov!magnus.acs.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!bb3.andrew.cmu.edu!andrew.cmu.edu!mn2f+
From: Michael N Nonemacher <mn2f+@andrew.cmu.edu>
Newsgroups: rec.games.corewar
Subject: '94 redcode
Date: Tue, 19 Apr 1994 00:18:47 -0400
Organization: Freshman, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Lines: 20
Message-ID: <8hgpibO00WB3FLSmcb@andrew.cmu.edu>
NNTP-Posting-Host: po5.andrew.cmu.edu

OK, I'm (finally) moving into the '94 standard, and I came upon one
major hitch: I have 4 programs to test against - all of which came with
pMARS!  I haven't seen any code for '94 warriors here, other than the 2
or 3 examples from the Big Hill.  I'll post the source for Der Zweite
Blitzkrieg as soon as I get around to making it post-worthy, but it'd be
nice if there were a few more examples of successful '94 redcode for
testing.  Just an idea...

And while I'm on the subject (or close...), I hafta throw in my comments
on the big hill.  It seems to me like there's nothing to limit the
proliferation of stone-spiral combos.  As a few other people have
observed, paper warriors don't last at all on the big hill, so it
doesn't seem like there's enough variation.  Is this as true as I'm
representing?  Of course, I haven't touched the big hill yet, so I'm not
one of the more informed on this topic, but that's my impression.  Any
opinions?

Mike Nonemacher
mn2f+@andrew.cmu.edu



Article 2752 of rec.games.corewar:
Path: hellgate.utah.edu!utah-morgan!cs.utexas.edu!swrinde!ihnp4.ucsd.edu!agate!soda.berkeley.edu!mconst
From: mconst@soda.berkeley.edu (Michael Constant)
Newsgroups: rec.games.corewar
Subject: More Source Postings
Date: 19 Apr 1994 22:13:24 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 231
Message-ID: <2p1l24$35l@agate.berkeley.edu>
NNTP-Posting-Host: soda.berkeley.edu

Here is the source for all the programs (mostly quite bad) that I've
submitted recently to the standard '94 hill at pizza.  I would encourage
everyone else out there to post the code even for your bad programs, because
often others can profit by your mistakes and even improve your programs
to the point where they become really viable.

First and foremost is Sauron v1.8, currently a strong second place on
the Pizza '94 hill.  (Don't you just *love* it when people (like me) are
soooooo nice (like me) that they post their prize program as soon as it
gets a good score on the hill?)  Sauron is a combination program, with the
main feature (at least the one which takes up the most space in the code)
being the quick-scan (label "look").  If it finds anything with the quick-
scan, Sauron will bomb it with spl/jmps (as documented in the program, I got
the idea (and a bit of the implementation) for spl/jmp from Mike Nonemacher's
Blitzkrieg (I was using spl-carpet, which didn't work as well because it
covered less distance in the same amount of time)).  After the spl/jmp
bombing, Sauron will do a double coreclear which degenerates into a
hyperperfect gate (the name I made up just now for a gate which will keep
out gate-crashing imps; so-called because it's even more perfect than the
standard "perfect" gate.) However, if no enemy is found with the initial
quick-scan, Sauron will launch a 3x2 imp-spiral (3 points, 2 layers) and
a stone with a partial coreclear (it wipes *almost* the entire core, but it
commits suicide right before the last bit is done.  I don't consider this
to be a serious problem, especially with the imps around to clean up anything
the stone leaves).

Before you ask: this program was *not* based on Blitzkrieg.  In fact when
I was writing it I thought it was unique until I took another look around my
piles of source listings (yeah, they're on my computer, but they're piles
nonetheless...  I can be a slob electronically too :-)  and found Blitzkrieg.
That's when I got the inspiration to change the quick-scan bombing from
spl-carpet to spl/jmp.

Oh yeah, you were wondering where the poem in the strategy section came in:
well, Sauron was called the "Lord of the Rings" and this program was originally
designed to beat imps (it actually ended up doing better against scanners).
Okay, it's a lame attempt at humor, but *I* thought it was funny...

One last thing: I have not tried to make this program easy to read.  I'm
just posting it as is, so you can have the benefit of seeing it as soon as
possible.  If you don't understand how some bit of it works, please mail
me, I'd be happy to answer any questions you may have.  (Among other things,
it would mean to me that someone actually read the source to my program
and cared about it! Wow!)  Besides, it gives me an excuse *never* to clean
up the code, since (I can say) I've already posted it, so why bother? :-)

Anyway, without further ado:

;redcode-94
;name Sauron v1.8
;author Michael Constant
;strategy  "Three Rings for the Elven-kings under the sky,
;strategy     Seven for the Dwarf-lords in their halls of stone,
;strategy   Nine for Mortal Men doomed to die,
;strategy     One for the Dark Lord on his dark throne
;strategy   In the Land of Mordor where the Shadows lie.
;strategy     One Ring to rule them all, One Ring to find them,
;strategy     One Ring to bring them all and in the darkness bind them
;strategy   In the Land of Mordor where the Shadows lie."
;strategy                       -- J.R.R. Tolkien, _Lord_of_the_Rings_
;macro


DIST    equ     2300

cclear  mov     split,  <-10		; lazy man's two-pass coreclear :-)
        jmz.a   cclear, last+10
split   spl     #11,    <-30
        mov     bomb,   <-5
jump    jmp     -1,     <-32

f
impgen  spl     1,      stone+4+1
        mov     -1,     0
        spl     1 
        spl     2
        jmp     @0,     imp
        add     #2667,  -1

bomb    dat     <-31-2668,<-31     ; is this right?  I'm not very familiar
                                   ; with gate-breaking imps but it seems to
				   ; work against Cannonade.

look
qscan   for     36  ; this would be 38 if there was enough room in the program
        cmp.x   look+((qscan+1)*100), look+4000+((qscan+1)*100)
        mov.ab  #20+look+((qscan+1)*100)-found, @found
        rof

found   jmz     blind,  #0
zap     mov.i   jump,   @found
        mov.i   split,  <found
        sub     #4002,  found
        djn     -3,     #45
t       jmp     cclear, stone+4+1+DIST

stone   mov.i   <1-10,  3+10
        spl     -1,     #incr+1
        sub.f   incr,   stone
        djn.f   -2,     <-3002
incr    mov.i   10,     <-10

blind   spl     impgen
        mov     <f,     <t
        djn     -1,     #5
        jmp     stone+DIST

last
imp     mov.i   #0,     2667

        end     look


I have much less commentary on the rest of my programs, because most of
them don't stand up to much inspection :-)  But I'll at least try to
explain how each of them works (or doesn't).

Little Flea (and its companion program for the 94-x hill, Big Flea) is
a simple spl-bomber with a gate.  There's nothing very special about it...

;redcode-94
;name Little Flea v1.2
;author Michael Constant
;kill Little Flea
;strategy  spl-bomber with gate
;macro

step    equ     3044

split   spl     #0,     <-20
stone   mov.i   split,  hit+step
bar     add     #step,  stone
hit     djn.f   stone,  <-3000
        mov.i   foo,    <bar
foo     dat     <-21,   <-22


Assassin is a slightly more interesting program.  It's a b-scanner with a
big emphasis on small size; it attacks first with spl-carpet and then with
dats to kill the enemy (no coreclear).  Its main problem is imps, against
which it has no defence.

;redcode-94
;name Assassin v1.0
;author Michael Constant
;kill Assassin
;strategy  B-scanner !?

adder   add     #12,    scan
scan    jmz     adder,  which
        mov     #12,    count
        mov     @which, >scan
count   djn     -1,     #0
        jmp     scan,   0

	[ big DAT 0, 0 spacer removed ]

which   dat     0,      #split
split   spl     -1,     #-22


The Red Carpet was my first attempt at a carpet-bombing cmp-scanner, and
I don't think I need to post it because it had no innovations and there
are a lot of better cmp-scanners out there.

Imperfection v3.1 (for regular core) is a standard stone/imp combo.
Note the decoy at the *beginning* to confuse any program which assumes
decoys at the end (I know several programs which do this but I can't call
them to mind right now -- sorry).  The coreclearing stone is awful code,
but it works... the one in Sauron (qv.) is a lot better (at least vs.
scanners).  Maybe I should replace it, but I haven't gotten around to
trying yet.

;redcode-94
;name Imperfection v3.1
;author Michael Constant
;kill Imperfection
;strategy  standard stone/spiral
;macro

DIST    equ     2500
STEP    equ     889
IMPBOOT equ     400

org     boot

foo
decoy   for 74
        spl.i   #500+(decoy*3), #decoy+1
        rof

boot    mov     stone,  stone+DIST
        mov     stone+1,stone+1+DIST
        mov     stone+2,stone+2+DIST
        mov     stone+3,stone+3+DIST
        mov     stone+4,stone+4+DIST
        mov     bar,    stone+DIST+4+76
        mov     bar,    stone+DIST+4+75

        spl     stone+DIST, <-2000
        spl     stone+DIST, <-3000

launch  mov     imp,    imp+IMPBOOT
        spl     1,      <-2000
        mov     -1,     0
        mov     -1,     0
        mov     -1,     0
        spl     1,      <-3000
        spl     1,      <-4000
        spl     2,      <3000
        jmp     @0,     imp+IMPBOOT
        add     #STEP,  -1
        
bar     dat     #1,     #10

stone   mov.i   <foo-DIST+31+(76*2),3-(76*2)
        spl     -1,     <-3000
        sub.f   toadd,  -2
        djn.f   -2,     <-3002
toadd   mov     -76,    >76

imp     mov.i   #0,     STEP


Whew!  That's it, I think.  Well, I hope to inspire another round of source
postings -- there have been a lot of new programs recently.  Does anyone
else want to reveal their secrets?
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2753 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!mconst
From: mconst@OCF.Berkeley.EDU (Michael Constant)
Newsgroups: rec.games.corewar
Subject: Re: '94 redcode
Date: 20 Apr 1994 01:37:26 GMT
Organization: U.C. Berkeley Open Computing Facility
Lines: 19
Message-ID: <2p210m$7sb@agate.berkeley.edu>
References: <8hgpibO00WB3FLSmcb@andrew.cmu.edu>
NNTP-Posting-Host: cyclone.berkeley.edu

In article <8hgpibO00WB3FLSmcb@andrew.cmu.edu>,
Michael N Nonemacher  <mn2f+@andrew.cmu.edu> wrote:
>And while I'm on the subject (or close...), I hafta throw in my comments
>on the big hill.  It seems to me like there's nothing to limit the
>proliferation of stone-spiral combos.  As a few other people have
>observed, paper warriors don't last at all on the big hill, so it
>doesn't seem like there's enough variation.

How can you complain?  There are *two* copies of Variation on the Big
Hill right now!  :-)  But seriously, there are several programs to do
nasty things to imps.  First of all, any program called "Kill More Imps!!!"
(Steven Morrell) can't be exactly cooperative with imp spirals (although
it never seems to beet Imperfection...) and my own Sauron v2.0 (now in
testing on the Big Hill) is also not kind to them.  The imps *will* die,
never fear.
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2755 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!galaxy.ucr.edu!library.ucla.edu!news.mic.ucla.edu!MVS.OAC.UCLA.EDU!IZZYVD5
From: IZZYVD5@MVS.OAC.UCLA.EDU
Newsgroups: rec.games.corewar
Subject: PMpmars for OS/2
Date: Tue, 19 Apr 1994 23:00
Organization: UCLA Microcomputer Support Office
Lines: 6
Sender: MVS NNTP News Reader <NNMVS@MVS.OAC.UCLA.EDU>
Message-ID: <19940419230028IZZYVD5@MVS.OAC.UCLA.EDU>
NNTP-Posting-Host: mvs.oac.ucla.edu

My friend is getting along on his GUI version of PMARS....              C
He wants suggestions.  He is Jason, reachable at:
               p30bjrk@pic.ucla.edu
It's at least as fast as the windows one (WinCore) and it'll be
free (unlike WinCore) like all the other pMars versions.
(He also would like to know if Stefan Strack got his mail...)


Article 2757 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!news.cs.utah.edu!utah-morgan!cs.utexas.edu!howland.reston.ans.net!europa.eng.gtefsd.com!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: EBS Spring Tournament deadline approaches
Message-ID: <1994Apr20.195548.6192@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: Wed, 20 Apr 1994 19:55:48 GMT
Lines: 32


Last call for submissions to the Spring EBS double-elimination tournament
starting this Friday, April 22. Again, rules for the 1st round are that of
the 94x (big) hill, i.e.:

        coresize:       55440
        cycles:         500000
        max procs:      10000
        max length:     200
        min distance:   200
        standard:       ICWS'94 draft + SEQ,SNE,NOP

(round 2 on April 29 will be "standard" hill specs)

Like last time, I will send the code for all entries, along with the player
pairings for the upcoming round to all participants as soon as the round is
played. You can send a new warrior for the next round or tell me to use your
previous one.

Please include a
;contact <your-email-address>
line in your submission and indicate whether you want the warrior sources as
uuencoded tar.Z or zip archive. Send your entry (one per person) to
stst@vuse.vanderbilt.edu by Friday, 20:00 CDT (no late entries). I will run
the 1st round Friday night and post/mail out results Saturday or Sunday.

I especially encourage beginners to participate. This is your chance to get
your hands on some top-quality Redcode. Also, the one-on-one format of this
tournament makes it possible to win with highly specialized warriors that
might never make it onto the hill.

-Stefan (stst@vuse.vanderbilt.edu)


Article 2759 of rec.games.corewar:
Path: hellgate.utah.edu!utah-morgan!cs.utexas.edu!howland.reston.ans.net!agate!soda.berkeley.edu!mconst
From: mconst@soda.berkeley.edu (Michael Constant)
Newsgroups: rec.games.corewar
Subject: '94 Standard
Date: 20 Apr 1994 22:02:59 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 16
Message-ID: <2p48qj$5al@agate.berkeley.edu>
NNTP-Posting-Host: soda.berkeley.edu

I have nothing in particular to say in this post, just a miscellaneous
comment that might start a thread:

I think that the '94 standard is really coming into its own.  About a month
ago, any good '88 program could do well on the '94 hill.  However, by now,
even programs at or near the top of the '88 hill are having trouble doing
well against '94 programs.  (I noticed this because, for some reason, there
have been many '88 and pseudo-88 programs submitted to the '94 hill recently.
A pseudo-88 program (my name) is one which was written for '88 and later
ported to '94, but which probably does not take advantage of all the available
features.)  This is good, it means that people are really finding ways to use
the new standard.  Just thought people might want to know..
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2760 of rec.games.corewar:
Path: hellgate.utah.edu!caen!sol.ctr.columbia.edu!spool.mu.edu!howland.reston.ans.net!gatech!news-feed-1.peachnet.edu!news.duke.edu!godot.cc.duq.edu!toads.pgh.pa.us!news.sei.cmu.edu!bb3.andrew.cmu.edu!andrew.cmu.edu!mn2f+
From: Michael N Nonemacher <mn2f+@andrew.cmu.edu>
Newsgroups: rec.games.corewar
Subject: Der Zweite Blitzkrieg source
Date: Wed, 20 Apr 1994 14:29:51 -0400
Organization: Freshman, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Lines: 78
Message-ID: <IhhLGT200YUnEDvUVb@andrew.cmu.edu>
NNTP-Posting-Host: po2.andrew.cmu.edu

OK, as promised, here's the source to Der Zweite Blitzkrieg.  Any
questions about how it works, E-mail me at "mn2f+@andrew.cmu.edu".  Here
'tis:

;redcode-94
;name Der Zweite Blitzkrieg - 94
;author Mike Nonemacher
;strategy quick-scan -> stone-spiral -> 2-pass coreclear -> gate
;strategy Only very minor mods from '88 version
;kill Der Zweite

;Real strategy:
;Quick-scan, spl/jmps what it found.  Nimbus-style 7-point spiral launch.
;Slightly adapted Blitzkrieg stone (had to make it self-splitting), bombs
;itself to turn itself into a spl/dat coreclear -> gate.  Has at minimum
;around 130 processes in gate, with 15 in the spiral, so I have at least a
;90% gate, but the gate also adds processes constantly, so it's usually
;more than that.  Since I don't bomb myself with the stone's split, I can
;sustain a hit to either the stone's spl 0 or jmp -2.  
;The stone should give me a winning record against scanners, and the spiral
;makes sure I at least tie other stones (without gates) and spirals.  The
;spl/dat coreclear should kill paper (as well as the quick-scan, since no
;one ever has only one copy of their paper anymore), and the 7-point spiral
;will thwart most anti-imp strategies (Iron Trap, 3-point coreclear (Iron
;Sword), 3-point decrement (Imprimis 7), and most anti-imp paper).

BOOT    EQU    3405            ;Just picked this one at random
C    EQU    328            ;bombing increment - small, mod-8
GVAL    EQU    -19            ;decrement for gate
INCR    EQU    20            ;offset of inc from stone
PTR    EQU    -11            ;offset of ptr from stone+4
I    EQU    1232            ;offset of start of spiral from imp
D    EQU    1143            ;7-point spiral
CMP1    EQU    (start-2)*SC/2+CMPST    ;EQUs for quick-scan
CMP2    EQU    CMP1+4000
MOV1    EQU    (start-1)*SC/2+CMPST-BPTR+67
BPTR    EQU    bptr1            ;point 67 past what we found
SC    EQU    112            ;only 34 scans would fit :(
CMPST    EQU    start+33        ;make sure stone doesn't kill spl/jmps

start    
for    34
    cmp.i    CMP1,    CMP2        ;Quick-scan
    mov.ab    #MOV1,    BPTR
rof
bptr1    jmz.b    ok,    #0        ;skip if we didn't find anything
    mov.i    jump,    <BPTR
    mov.i    split,    <BPTR
    sub.ab    #4002,    @-1
    djn.b    -3,    #35
ok    spl    isp            ;launch spiral
    mov.i    gate,    top+BOOT-1+PTR+GVAL    ;set up 2-pass clear
    mov.i    split,    top+BOOT-4-19
    mov.ab    #-PTR-1,    top+BOOT-1+PTR
    spl    1
    mov.i    -1,    0
    spl    1            ;6 processes for bootstrap
    mov.i    <src,    <top
top    jmp    @0,    #BOOT+1
imp    mov.i    #238,    D
split    spl.f    0,    >GVAL
stone    sub.f    stone+INCR,    1
    mov.i    <-19,    1
    jmp.f    -2,    >split+GVAL
    mov.i    @PTR,    <stone+INCR
jump    jmp.f    -1,    >GVAL-2
gate    dat.f    >GVAL-1,    #0
isp    mov.i    imp,    imp+I
    mov.i    inc,    top+BOOT-4+INCR
    spl    1
    spl    1
    spl    1
    mov.i    -1,    0        ;generate 15 consecutive processes
src    spl    2,    #jump+1
    jmp    @0,    imp+I
    add.ab    #D,    -1
inc    dat.f    #C,    #-C
END    start


Article 2762 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!usc!math.ohio-state.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!bb3.andrew.cmu.edu!andrew.cmu.edu!mn2f+
From: Michael N Nonemacher <mn2f+@andrew.cmu.edu>
Newsgroups: rec.games.corewar
Subject: Re: '94 Standard
Date: Thu, 21 Apr 1994 00:02:10 -0400
Organization: Freshman, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Lines: 19
Message-ID: <0hhTf2u00WB2IpYVsp@andrew.cmu.edu>
NNTP-Posting-Host: andrew.cmu.edu
In-Reply-To: <2p48qj$5al@agate.berkeley.edu>

Excerpts from netnews.rec.games.corewar: 20-Apr-94 '94 Standard by
Michael Constant@soda.berkeley.edu
>I think that the '94 standard is really coming into its own.  About a month
>ago, any good '88 program could do well on the '94 hill.  However, by now,
>even programs at or near the top of the '88 hill are having trouble doing
>well against '94 programs.  (I noticed this because, for some reason, there
>have been many '88 and pseudo-88 programs submitted to the '94 hill recently.
>A pseudo-88 program (my name) is one which was written for '88 and later
>ported to '94, but which probably does not take advantage of all the available
> 
>features.)  This is good, it means that people are really finding ways to use
>the new standard.  Just thought people might want to know..

Good point.  I've noticed this, too.  Then again, Der Zweite Blitzkrieg
debuted at #1 with 179, and #2 was Killer Instinct with 160, but things
have since balanced out :(.

Mike Nonemacher
mn2f+@andrew.cmu.edu


Article 2763 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!overload.lbl.gov!agate!msuinfo!netnews.upenn.edu!netnews.cc.lehigh.edu!ns1.cc.lehigh.edu!fjw2
From: fjw2@ns1.cc.lehigh.edu (FRANK JUDE WOJCIK)
Subject: Re: More Source Postings
Message-ID: <1994Apr21.132222.165403@ns1.cc.lehigh.edu>
Date: Thu, 21 Apr 1994 13:22:22 GMT
Organization: Lehigh University
Lines: 89

>Whew!  That's it, I think.  Well, I hope to inspire another round of source
>postings -- there have been a lot of new programs recently.  Does anyone
>else want to reveal their secrets?
Secrets? My code hardly uses any secrets, and does quite badly, and is for the
'88 hill, but here it is anyway. There's a *lot* of optimization that
could possibly be done, but I really don't care to. It could probably be
redone fairly easily (and possibly more effectively) for the '94 hill, which I
may do, but...  Here it is anyway. (WARNING: I am a terrible newbie, so go
easy! :)

This is based on my Zipper series, which also did terribly. But this has
active programs instead of DAT decoys. This was *supposed* to do well against
all those scanners, but it just was too big & not fast enough, I guess...
It starts off with an imp-gate (front program), mod-1 bomber (back program &
middle program)(I fooled around with this a bit - making it mod-something else
did zilch), and (what I thought was) a neat little trick. The processes are
just so that if either the front or back process is killed, "cnt" becomes
!=4000. Based on which program is killed, it then copies the retailation
program out of the way of the attack, attempts to kill off the other
processes, and JMPs to the copied program. The retaliatory bomber is based on
Leprachaun(?)(sp) modified to be a 2/3 imp-gate at the end. It was the best I
could do.

;redcode verbose
;author Frank J. T. Wojcik
;name Banana Split v1.4
;strategy Program which acts like three different ones.
;strategy v1.0 -- Initial release. Slow and long.
;strategy v1.1 -- No more bootstrap! Faster. Better bomber.
;strategy v1.2 -- *Much* faster bomber. Probably won't do much, but...
;strategy v1.3 -- Fixed a really stupid bug introduced in 1.2.
;strategy v1.4 -- Turned final bomber into 2/3 imp-gate when done.
fp      JMP 1,<-5               ;Front Program Top
        JMP 1,<-6
        ADD #1,cnt
        JMP 1,<-8
        JMP -3,<-9              ;Front Program Bottom
        DAT #0, #0
            :
    [lots of DAT #0, #0's deleted]
            :
        DAT #0, #0
cnt     DAT #0, #4000
boot    SPL fp,<fp-5            ;Launch Front Program
        SPL bp,<fp-5            ;Launch Back Program
        MOV bomb,<bomb
        MOV bomb,<bomb
        CMP #4000,cnt
        JMP attack,<fp-5
        JMP -4,<fp-5
attack  MOV mvpt1,fp+4          ;First, kill off out old processes, because
        MOV mvpt1,bp+2          ;WE'VE BEEN ATTACKED!!!!!!!!!!!!!!!!!!!!!!!!!
        SLT #4000, cnt          ;But in which direction?
        ADD #-600,mvpt2         ;If 0>cnt (cnt<0), #1 failed --> move fwd
        MOV <mvpt1,<mvpt2       ;If 0<cnt (cnt>0), #2 failed --> move bck
        CMP @mvpt1,cpb          ;Copy the retaliation program...
        JMP -2,<fp+15
        JMP @mvpt2,<fp+15       ;...and launch it!
mvpt1   DAT #0,#cpe+1
mvpt2   DAT #0,#300
cpb     spl 0,<-1
loop    add #3039,ptr
ptr     mov cpb,81
        jmp loop
        mov 1, <1
cpe     DAT <-3,#-3
        DAT #0, #0
            :
    [lots of DAT #0, #0's deleted]
            :
        DAT #0, #0
bomb    DAT #0, #fp-7
bp      MOV bomb,<bomb          ;BEGIN-->Back Program
        ADD #-1,cnt
        MOV bomb,<bomb
        JMP -3,<fp-5
        END boot

Oh, well, back to the drawing board.
>               Michael Constant (mconst@soda.berkeley.edu)
>
>    GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y
>
-- 
-----
Frank J. T. Wojcik      "This is that thing you call sarcasm, isn't it?" - D.A.
fjw2@lehigh.edu    "Oh, very good, Worf. Eat any good books lately?" - Q
 GE d- -p+ c++++ l u(++) e*() m+@ s++/++ n-@ h+() f- g+(-) w++() t+(+++)@ r !y
finger fjw2@cs2.CC.lehigh.edu = C8 E8 73 86 FB DB C2 61 0D 60 23 7A EB CB 23 61


Article 2766 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!swrinde!cs.utexas.edu!math.ohio-state.edu!cyber2.cyberstore.ca!nntp.cs.ubc.ca!uw-beaver!cs.washington.edu!jayhan
From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: More redcode (Big)
Message-ID: <JAYHAN.94Apr22122551@derkins.cs.washington.edu>
Lines: 21
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington
Date: 22 Apr 1994 12:25:51 GMT

Okay, followin the good example set by Michael, I'll divulge my
little secrets.

I've been going hard at the big hill, and I currently have seven
warriors on the hill.  Yes, I know, I really should retire Splash,
but I still find it interesting that "Variation G-1" and "Splash"
are so close in performance.

Anyway, I'll start with the uninteresting ones.  Sunburst was
mercifully pushed off lately, so good riddance (it was a '88 stone
with new constants).  Skimp 127 is nothing more than a 2-process
127-point imp-spiral.  Interestingly, Kill More Imps!!! doesn't seem
all that efficient againts it.

For the more interesting stuff, I decided to make a separate post
for each warrior.  So here goes!

-=<|  Jay "Thierry" Han  |>=-       e-mail: jayhan@cs.washington.edu
Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969
U. of Washington. Seattle, WA 98195, USA.   [Sieg 230] (206)685-1224
Personal: 4820 Burke Ave N. Seattle, WA 98103, USA.    (206)547-8559


Article 2767 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!usc!math.ohio-state.edu!cyber2.cyberstore.ca!nntp.cs.ubc.ca!uw-beaver!cs.washington.edu!jayhan
From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: Variation G-1
Message-ID: <JAYHAN.94Apr22123643@derkins.cs.washington.edu>
Lines: 152
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington
Date: 22 Apr 1994 12:36:43 GMT

Last time I checked, Variation G-1 was barely #1 on pizza, though it
has had over 10 points of margin over #3 at one point (#2 was
Splash).  Well, enough bragging.

Variation, as the ;strategy line says, is a variation on the theme
of my mildly successful Twimpede.  If you remember, Twimpede was
basically a Mod-2 ExtraExtra stone with a 19-point 2-process spiral,
and a wimp.  The genius (ahem) was to add in the extra wimp, as it
would sometimes be the last thing alive, extolling a tie against CG
and a win over other stones.

There have been a few dozen Variations along the way, as I
experimented with different designs.  Variation A-1.a was #1 at
Stomrking for a while.

In the latest version, I was able to squeeze one more instruction
out of the stone without hindering functionality.  Also, I added
some random core trashing during the spiral start-up sequence.
There's some decoy also, and the wimp is booted off the main body.
With all this confusion, Variation G-1 gets a 60/30/10 against
Dagger v6.0, and 55/35/10 against Kill Imps!!!  As a comparison, it
beats Imperfection v1.0 50/0/50

;redcode-94x
;name Variation G-1
;author Jay Han
;strategy Stone/Spiral with tons of decoy and a wimp
;macro

		org	start

p1		equ	27739
s1		equ	34
p2		equ	27705
s2		equ	-34

gate		equ	inc+s2

loop		add.f	inc,		cast
stone		spl.b	loop,		<gate
cast		mov.i	<p1,		p2
buckle		djn.f	stone,		<gate
patch		djn.b	inc-stone,	<gate-stone
stop		dat.f	<gate-buckle,	#1
inc		spl.b	#s1,		<s2
clear		mov.i	plug,		<patch+1
plug		dat.f	<gate,		<gate+1

for 15
		dat.f	0,		0
rof

fool		equ	55440/153
m for 76
		dat.f	fool*m,		-fool*m
rof

for 15
		dat.f	0,		0
rof
split		spl.b	#0,		<-19
wimp		djn.f	#0,		<-20
start		spl.b	stone,		<trash
newimp		mov.i	wimp,		cast+27722
		mov.i	split,		<newimp
		spl.b	@newimp,	<trash*2

step		equ	29179
launch
		spl	lbl3,		<3*trash
		spl	lbl5,		<4*trash
		spl	lbl9,		<5*trash
		spl	lbl17,		<6*trash
		spl	lbl33,		<7*trash
		spl	lbl65,		<8*trash
		jmp	imp+0*step+0,	<9*trash
lbl65		jmp	imp+1*step+0,	<10*trash
lbl33		spl	lbl67,		<11*trash
		jmp	imp+2*step+0,	<12*trash
lbl67		jmp	imp+3*step+0,	<13*trash
lbl17		spl	lbl35,		<14*trash
		spl	lbl69,		<15*trash
		jmp	imp+4*step+0,	<16*trash
lbl69		jmp	imp+5*step+0,	<17*trash
lbl35		spl	lbl71,		<18*trash
		jmp	imp+6*step+0,	<19*trash
lbl71		jmp	imp+7*step+0,	<20*trash
lbl9		spl	lbl19,		<21*trash
		spl	lbl37,		<22*trash
		spl	lbl73,		<23*trash
		jmp	imp+8*step+0,	<24*trash
lbl73		jmp	imp+9*step+0,	<25*trash
lbl37		spl	lbl75,		<26*trash
		jmp	imp+10*step+0,	<27*trash
lbl75		jmp	imp+11*step+0,	<28*trash
lbl19		spl	lbl39,		<29*trash
		spl	lbl77,		<30*trash
		jmp	imp+12*step+0,	<31*trash
lbl77		jmp	imp+13*step+0,	<32*trash
lbl39		spl	lbl79,		<33*trash
		jmp	imp+14*step+0,	<34*trash
lbl79		jmp	imp+15*step+0,	<35*trash
lbl5		spl	lbl11,		<36*trash
		spl	lbl21,		<37*trash
		spl	lbl41,		<38*trash
		spl	lbl81,		<39*trash
		jmp	imp+16*step+0,	<40*trash
lbl81		jmp	imp+17*step+0,	<41*trash
lbl41		spl	lbl83,		<42*trash
		jmp	imp+18*step+0,	<43*trash
lbl83		jmp	imp+0*step+1,	<44*trash
lbl21		spl	lbl43,		<45*trash
		spl	lbl85,		<46*trash
		jmp	imp+1*step+1,	<47*trash
lbl85		jmp	imp+2*step+1,	<48*trash
lbl43		spl	lbl87,		<49*trash
		jmp	imp+3*step+1,	<50*trash
lbl87		jmp	imp+4*step+1,	<51*trash
lbl11		spl	lbl23,		<52*trash
		spl	lbl45,		<53*trash
		spl	lbl89,		<54*trash
		jmp	imp+5*step+1,	<55*trash
lbl89		jmp	imp+6*step+1,	<56*trash
lbl45		spl	lbl91,		<57*trash
		jmp	imp+7*step+1,	<58*trash
lbl91		jmp	imp+8*step+1,	<59*trash
lbl23		spl	lbl47,		<60*trash
		spl	lbl93,		<61*trash
		jmp	imp+9*step+1,	<62*trash
lbl93		jmp	imp+10*step+1,	<63*trash
lbl47		spl	lbl95,		<64*trash
		jmp	imp+11*step+1,	<65*trash
lbl95		jmp	imp+12*step+1,	<66*trash
lbl3		mov.i	bomb,		67*trash
		mov.i	bomb,		68*trash
		spl	lbl25,		<69*trash
		spl	lbl49,		<70*trash
		spl	lbl97,		<71*trash
		jmp	imp+13*step+1,	<72*trash
lbl97		jmp	imp+14*step+1,	<73*trash
lbl49		spl	lbl99,		<74*trash
		jmp	imp+15*step+1,	<75*trash
lbl99		jmp	imp+16*step+1,	<76*trash
lbl25		mov.i	bomb,		77*trash
		spl	lbl101,		<78*trash
		jmp	imp+17*step+1,	<79*trash
lbl101		jmp	imp+18*step+1,	<80*trash
imp		mov.i	#0,		step
trash		equ	684
bomb		equ	stop

		end	start


Article 2768 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!swrinde!cs.utexas.edu!math.ohio-state.edu!cyber2.cyberstore.ca!nntp.cs.ubc.ca!uw-beaver!cs.washington.edu!jayhan
From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: Splash
Message-ID: <JAYHAN.94Apr22123850@derkins.cs.washington.edu>
Lines: 137
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington
Date: 22 Apr 1994 12:38:50 GMT

Okay, so flame me if you have to, but I'm sort of usurping the #3
spot at the big hill with Splash.  Splash is really "only" Variation
G-1 with a two-pass core-clear.  I thought it would be slightly
better than Variation, but it was slightly worse.  I guess its
mileage will vary with the type of opponents it gets.

;redcode-94x
;name Splash 1
;author Jay Han
;strategy Stone/Spiral with 2-pass core-clear
;macro

		org	entry

p1		equ	27739
s1		equ	34
p2		equ	27705
s2		equ	-34

gate		equ	inc+s2-4
gate2		equ	inc+s2
offset		equ	top-19

top		dat.f	0,		patch+1
loop		add.f	inc,		cast
stone		spl.b	loop,		<gate
cast		mov.i	<p1,		p2
buckle		djn.f	stone,		<gate
stunner		spl.b	#0,		#bomb-ammo
stop		dat.f	<gate-buckle,	#1
inc		spl.b	#s1,		<s2
kill		mov.i	@ammo,		<patch+1
bomb		dat.f	<gate2,		#stop-ammo
patch		djn.f	inc-stone,	<gate-stone
ammo		dat.f	0,		stunner

for 15
		dat.f	0,		0
rof

fool		equ	55440/177
m for 88
		dat.f	fool*m,		-fool*m
rof

split		spl.b	#0,		<-19
wimp		djn.f	#0,		<-20
entry		spl.b	stone,		<trash
newimp		mov.i	wimp,		offset
		mov.i	split,		<newimp
		spl.b	@newimp,	<trash*2

; 38-process 19-point spiral (coresize 55440, '94 standard) (trashing)
step		equ	29179
launch
		spl	lbl3,		<3*trash
		spl	lbl5,		<4*trash
		spl	lbl9,		<5*trash
		spl	lbl17,		<6*trash
		spl	lbl33,		<7*trash
		spl	lbl65,		<8*trash
		jmp	imp+0*step+0,	<9*trash
lbl65		jmp	imp+1*step+0,	<10*trash
lbl33		spl	lbl67,		<11*trash
		jmp	imp+2*step+0,	<12*trash
lbl67		jmp	imp+3*step+0,	<13*trash
lbl17		spl	lbl35,		<14*trash
		spl	lbl69,		<15*trash
		jmp	imp+4*step+0,	<16*trash
lbl69		jmp	imp+5*step+0,	<17*trash
lbl35		spl	lbl71,		<18*trash
		jmp	imp+6*step+0,	<19*trash
lbl71		jmp	imp+7*step+0,	<20*trash
lbl9		spl	lbl19,		<21*trash
		spl	lbl37,		<22*trash
		spl	lbl73,		<23*trash
		jmp	imp+8*step+0,	<24*trash
lbl73		jmp	imp+9*step+0,	<25*trash
lbl37		spl	lbl75,		<26*trash
		jmp	imp+10*step+0,	<27*trash
lbl75		jmp	imp+11*step+0,	<28*trash
lbl19		spl	lbl39,		<29*trash
		spl	lbl77,		<30*trash
		jmp	imp+12*step+0,	<31*trash
lbl77		jmp	imp+13*step+0,	<32*trash
lbl39		spl	lbl79,		<33*trash
		jmp	imp+14*step+0,	<34*trash
lbl79		jmp	imp+15*step+0,	<35*trash
lbl5		spl	lbl11,		<36*trash
		spl	lbl21,		<37*trash
		spl	lbl41,		<38*trash
		spl	lbl81,		<39*trash
		jmp	imp+16*step+0,	<40*trash
lbl81		jmp	imp+17*step+0,	<41*trash
lbl41		spl	lbl83,		<42*trash
		jmp	imp+18*step+0,	<43*trash
lbl83		jmp	imp+0*step+1,	<44*trash
lbl21		spl	lbl43,		<45*trash
		spl	lbl85,		<46*trash
		jmp	imp+1*step+1,	<47*trash
lbl85		jmp	imp+2*step+1,	<48*trash
lbl43		spl	lbl87,		<49*trash
		jmp	imp+3*step+1,	<50*trash
lbl87		jmp	imp+4*step+1,	<51*trash
lbl11		spl	lbl23,		<52*trash
		spl	lbl45,		<53*trash
		spl	lbl89,		<54*trash
		jmp	imp+5*step+1,	<55*trash
lbl89		jmp	imp+6*step+1,	<56*trash
lbl45		spl	lbl91,		<57*trash
		jmp	imp+7*step+1,	<58*trash
lbl91		jmp	imp+8*step+1,	<59*trash
lbl23		spl	lbl47,		<60*trash
		spl	lbl93,		<61*trash
		jmp	imp+9*step+1,	<62*trash
lbl93		jmp	imp+10*step+1,	<63*trash
lbl47		spl	lbl95,		<64*trash
		jmp	imp+11*step+1,	<65*trash
lbl95		jmp	imp+12*step+1,	<66*trash
lbl3		mov.i	bomb,		67*trash	; Idle
		mov.i	bomb,		68*trash	; Idle
		spl	lbl25,		<69*trash
		spl	lbl49,		<70*trash
		spl	lbl97,		<71*trash
		jmp	imp+13*step+1,	<72*trash
lbl97		jmp	imp+14*step+1,	<73*trash
lbl49		spl	lbl99,		<74*trash
		jmp	imp+15*step+1,	<75*trash
lbl99		jmp	imp+16*step+1,	<76*trash
lbl25		mov.i	bomb,		77*trash	; Idle
		spl	lbl101,		<78*trash
		jmp	imp+17*step+1,	<79*trash
lbl101		jmp	imp+18*step+1,	<80*trash
imp		mov.i	#0,		step
trash		equ	684

		end	entry


Article 2769 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: Re: More redcode (Big)
Date: 22 Apr 1994 19:42:34 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 17
Message-ID: <2p99ba$j72@agate.berkeley.edu>
References: <JAYHAN.94Apr22122551@derkins.cs.washington.edu>
NNTP-Posting-Host: soda.berkeley.edu

Jay "Thierry" Han <jayhan@cs.washington.edu> wrote:
> Skimp 127 is nothing more than a 2-process 127-point imp-spiral. 

That's neat... how does it manage to do so well then?  Maybe the sheer
number of points affords it a rather large chance of hitting something
like a scanner right as it starts.

> Interestingly, Kill More Imps!!! doesn't seem all that efficient againts it.

Hmmm... Kill More Imps!!! can't beat Imperfection either.  Hey Steven, what
is it supposed to beat if not imps?  Or are Imperfection and Skimp 127 just
special cases?  I think the original Kill Imps!!! was more effective against
my programs.
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2770 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!utah-morgan!cs.utexas.edu!swrinde!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!hookup!batcomputer!cornell!uw-beaver!cs.washington.edu!jayhan
From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: Re: '94 redcode
In-Reply-To: mconst@OCF.Berkeley.EDU's message of 20 Apr 1994 01:37:26 PST-8
Message-ID: <JAYHAN.94Apr22105413@derkins.cs.washington.edu>
Lines: 35
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington
References: <8hgpibO00WB3FLSmcb@andrew.cmu.edu> <2p210m$7sb@agate.berkeley.edu>
Date: 22 Apr 1994 10:54:13 GMT

In article <2p210m$7sb@agate.berkeley.edu> mconst@OCF.Berkeley.EDU (Michael Constant) writes:

> From: mconst@OCF.Berkeley.EDU (Michael Constant)
> Subject: Re: '94 redcode
> Date: 20 Apr 1994 01:37:26 PST-8
> 
> How can you complain?  There are *two* copies of Variation on the
> Big Hill right now!  :-)

Yeah, sorry about that, but hey, when you have a #1 warrior and want
to improve it, you'd want to try it without having to kill the #1...
Anyway, my Janitors should have taken care of all the
half-duplicates.

> But seriously, there are several programs to do nasty things to
> imps.  First of all, any program called "Kill More Imps!!!"
> (Steven Morrell) can't be exactly cooperative with imp spirals
> (although it never seems to beet Imperfection...) and my own
> Sauron v2.0 (now in testing on the Big Hill) is also not kind to
> them.  The imps *will* die, never fear.

Hahahaha!  That's what you think!  :-)

Seriously again, there are also a few vampires on the big hill that
are doing pretty good (including my own Virus).  The problem is, I'm
not very fond of papers to start with, and I haven't been able to
program even a decent one.  The only one I got on the big hill was
when the hill was far less competitive.

So... any paper wizards? :-)

-=<|  Jay "Thierry" Han  |>=-       e-mail: jayhan@cs.washington.edu
Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969
U. of Washington. Seattle, WA 98195, USA.   [Sieg 230] (206)685-1224
Personal: 4820 Burke Ave N. Seattle, WA 98103, USA.    (206)547-8559


Article 2771 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!caen!math.ohio-state.edu!cyber2.cyberstore.ca!nntp.cs.ubc.ca!uw-beaver!cs.washington.edu!jayhan
From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: Sissy
Message-ID: <JAYHAN.94Apr22124244@derkins.cs.washington.edu>
Lines: 134
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington
Date: 22 Apr 1994 12:42:44 GMT

And what about Sissy?  It's really only an experiment, and I think
I'll retire it before long.  It's another variation on Variation
G-1, this time with a short scanning pass before the stone.  It
doesn't do much good, it's all I can tell you.

;redcode-94x
;name Sissy
;author Jay Han
;strategy SiSSy: Scan-Stone-Spiral, and a wimp
;strategy Fast Scanner/Vampire like Scanalyzer-W
;strategy Stone/Spiral/Wimp like Twimpede
;macro

		org	scan

start		equ	scan-200
step		equ	-50

loop		add.f	pit,		scan
scan		sne.i	start+step,	start
count		djn.b	loop,		#548
		jmz.b	phase,		count
		mov.i	fang,		@scan
		sub.ba	scan,		@scan
		add.f	half,		scan
		jmp.b	scan,		<count
fang		jmp.b	pit-scan,	<-1
half		dat.f	step,		step

for 15
		dat.f	0,		0
rof

p1		equ	27739
s1		equ	34
p2		equ	27705
s2		equ	-34

gate		equ	inc+s2

adder		add.f	inc,		cast
stone		spl.b	adder,		<gate
cast		mov.i	<p1,		p2
buckle		djn.f	stone,		<gate
patch		djn.b	inc-stone,	<gate-stone
stop		dat.f	<gate-buckle,	#1
inc		spl.b	#s1,		<s2
clear		mov.i	plug,		<patch+1
plug		dat.f	<gate,		<gate+1

for 15
		dat.f	0,		0
rof

pit		spl.b	#step*2,	<step*2
		jmp.b	-1,		<scan-3

fool		equ	55440/149
m for 74
		dat.f	fool*m,		-fool*m
rof

for 15
		dat.f	0,		0
rof

split		spl.b	#0,		<-19
wimp		djn.f	#0,		<-20
phase		spl.b	stone,		<trash
newimp		mov.i	wimp,		cast+27722
		mov.i	split,		<newimp
		spl.b	@newimp,	<trash*2

; 26-process 13-point spiral (coresize 55440, '94 standard) (trashing)
t		equ	34117
launch
		spl	lbl3,		<3*trash
		spl	lbl5,		<4*trash
		spl	lbl9,		<5*trash
		spl	lbl17,		<6*trash
		spl	lbl33,		<7*trash
		jmp	imp+0*t+0,	<8*trash
lbl33		jmp	imp+1*t+0,	<9*trash
lbl17		spl	lbl35,		<10*trash
		jmp	imp+2*t+0,	<11*trash
lbl35		jmp	imp+3*t+0,	<12*trash
lbl9		spl	lbl19,		<13*trash
		spl	lbl37,		<14*trash
		jmp	imp+4*t+0,	<15*trash
lbl37		jmp	imp+5*t+0,	<16*trash
lbl19		spl	lbl39,		<17*trash
		jmp	imp+6*t+0,	<18*trash
lbl39		jmp	imp+7*t+0,	<19*trash
lbl5		spl	lbl11,		<20*trash
		spl	lbl21,		<21*trash
		spl	lbl41,		<22*trash
		jmp	imp+8*t+0,	<23*trash
lbl41		jmp	imp+9*t+0,	<24*trash
lbl21		spl	lbl43,		<25*trash
		jmp	imp+10*t+0,	<26*trash
lbl43		jmp	imp+11*t+0,	<27*trash
lbl11		spl	lbl23,		<28*trash
		spl	lbl45,		<29*trash
		jmp	imp+12*t+0,	<30*trash
lbl45		jmp	imp+0*t+1,	<31*trash
lbl23		spl	lbl47,		<32*trash
		jmp	imp+1*t+1,	<33*trash
lbl47		jmp	imp+2*t+1,	<34*trash
lbl3		spl	lbl7,		<35*trash
		spl	lbl13,		<36*trash
		spl	lbl25,		<37*trash
		spl	lbl49,		<38*trash
		jmp	imp+3*t+1,	<39*trash
lbl49		jmp	imp+4*t+1,	<40*trash
lbl25		spl	lbl51,		<41*trash
		jmp	imp+5*t+1,	<42*trash
lbl51		jmp	imp+6*t+1,	<43*trash
lbl13		spl	lbl27,		<44*trash
		spl	lbl53,		<45*trash
		jmp	imp+7*t+1,	<46*trash
lbl53		jmp	imp+8*t+1,	<47*trash
lbl27		spl	lbl55,		<48*trash
		jmp	imp+9*t+1,	<49*trash
lbl55		jmp	imp+10*t+1,	<50*trash
lbl7		mov.i	bomb,		51*trash	; Idle
		mov.i	bomb,		52*trash	; Idle
		spl	lbl57,		<53*trash
		jmp	imp+11*t+1,	<54*trash
lbl57		jmp	imp+12*t+1,	<55*trash
imp		mov.i	#0,		t
trash		equ	990
bomb		equ	half

		end	scan


Article 2772 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!utah-morgan!cs.utexas.edu!swrinde!gatech!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!uw-beaver!cs.washington.edu!jayhan
From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: Virus
Message-ID: <JAYHAN.94Apr22124614@derkins.cs.washington.edu>
Lines: 55
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington
Date: 22 Apr 1994 12:46:14 GMT

A vampire.  Yes, there aren't only stone/imp on the big hill!  My
first campire, The Missionary, was fairly successful, so I followed
up and did The Count, which was even better, and finally Virus.

Virus is a Mod-3.5 vampire, meaning that there are gaps of 3 or 2
untouched locations, but never more.  The pit is a standard pit,
with the added feature that at the end of the fang-planting run, the
pit is neatly surrounded by fangs that jump back into it, in case
for some strange reason the pit overflows.

After the bombing run, a core-clear is started, and the pit is wiped
out last.  Also, the core-clear becomes a perfect gate, because imps
have been known to rise from the dead.

There's a large decoy at the end, just for fun.

;redcode-94x
;name Virus
;author Jay Han
;strategy Vampire
;macro

start		equ	20
step		equ	23
n		equ	16873

		org	bite

gate		equ	head-step

loop		add.x	head		,fang
bite		mov.i	fang		,@fang
ptr		djn.b	loop		,#n-1
head		spl.b	#step		,<-step
kill		mov.i	bomb		,<ptr
bomb		dat.f	<gate+1		,<gate
fang		jmp.b	trap-start	,start

for 16
		dat.f	0,		0
rof

pit		spl.b	#0		,<gate
trap		jmp.b	pit		,<gate

for 15
		dat.f	0,		0
rof

fool		equ	55440/319
m for 160
		dat.f	fool*m,		-fool*m
rof

		end	bite


Article 2773 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!utah-morgan!cs.utexas.edu!math.ohio-state.edu!cyber2.cyberstore.ca!nntp.cs.ubc.ca!uw-beaver!cs.washington.edu!jayhan
From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: Scanalyzer-W
Message-ID: <JAYHAN.94Apr22125005@derkins.cs.washington.edu>
Lines: 51
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington
Date: 22 Apr 1994 12:50:05 GMT

The Scanalyzer-V series was thus named because it bombed not with
SPL/JMP or a SPL carpet, but with a vampire fang.  The advantage of
using fangs is that you control the pit.  You *could* put the slaves
to work, although Scanalyzer-W doesn't... yet.  That's in my plans.
I also plan to include some stone component to get a better edge
againts other scanners.

Anyway, it's a Mod-2 CMP-scanner.  And that's about it.

;redcode-94x
;name Scanalyzer-W
;author Jay Han
;strategy Scanner/Vampire
;macro

		org	scan

start		equ	scan-200
step		equ	-34

loop		add.f	inc,		scan
scan		cmp.i	start+step,	start
		slt.ab	#399,		scan
count		djn.b	loop,		#13860
		mov.i	fang,		@scan
		sub.ba	scan,		@scan
		add.f	half,		scan
p		jmn.b	scan,		count
inc		spl.b	#step*2,	<step*2
half		spl.b	#step,		<step
		mov.i	bomb,		<p
bomb		dat.f	<step-2,	<step-1
fang		jmp.b	pit-scan,	<-1

for 15
		dat.f	0,		0
rof

pit		spl.b	#0,		<scan-3
trap		jmp.b	-1,		<scan-3

for 15
		dat.f	0,		0
rof

fool		equ	55440/311
m for 155
		dat.f	fool*m,		-fool*m
rof

		end	scan


Article 2774 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!news.cs.utah.edu!utah-morgan!cs.utexas.edu!math.ohio-state.edu!cyber2.cyberstore.ca!nntp.cs.ubc.ca!uw-beaver!cs.washington.edu!jayhan
From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: Nova-A.1b
Message-ID: <JAYHAN.94Apr22125322@derkins.cs.washington.edu>
Lines: 149
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington
Date: 22 Apr 1994 12:53:22 GMT

What can I say?  I really didn't expect this one to get on the hill
at all.

It's a warrior derived from The Count (remember, the vampire).  What
I wanted to try was to make a vampire/spiral combo.  Just for fun.
So what I needed was a multi-process vampire.  No easy way to do
that, because unlike stones, who self-destruct, a vampire must
gracefully quit before it is enslaved itself.  I'm still working on
a vampire that really looks like ExtraExtra.  It's tricky.  I need
some tools to come up with good constants that maximize the spread
patterns and land exactly where I want them to, at exactly the right
moment.

;redcode-94x
;name Nova-A.1b
;author Jay "Thierry" Han
;strategy Fast Vampire + Imp-spiral
;macro

		org	start

init		equ	40+3*step
step		equ	52

gate		equ	source-step

source		spl.b	#0,		<gate
p		djn.b	split,		#234
		mov.a	#clear-cplug,	cplug
		mov.a	#clear-aplug,	aplug
inc
clear		spl.b	#step,		<-step
		mov.i	bomb,		<p
bomb		dat.f	<gate,		<gate+1
		dat.f	0,		0
adder		add.x	inc,		fang
aplug		djn.b	adder,		<gate
		dat.f	0,		0
		dat.f	0,		0
split		spl.b	adder,		<gate
caster		mov.i	fang,		@fang
cplug		djn.b	caster,		<gate

fang		jmp.b	pit-init,	init

pit		spl.b	#0,		<gate-1
		jmp.b	-1,		<gate-1

for 15
		dat.f	0,		0
rof

fool		equ	55440/145
m for 72
		dat.f	fool*m,		-fool*m
rof

for 15
		dat.f	0,		0
rof

start		spl.b	source,		<trash

;Imp
; 38-process 19-point spiral (coresize 55440, '94 standard)
t	equ	29179
launch
	spl	lbl3,	<2*trash
	spl	lbl5,	<3*trash
	spl	lbl9,	<4*trash
	spl	lbl17,	<5*trash
	spl	lbl33,	<6*trash
	spl	lbl65,	<7*trash
	jmp	imp+0*t+0,	<8*trash
lbl65	jmp	imp+1*t+0,	<9*trash
lbl33	spl	lbl67,	<10*trash
	jmp	imp+2*t+0,	<11*trash
lbl67	jmp	imp+3*t+0,	<12*trash
lbl17	spl	lbl35,	<13*trash
	spl	lbl69,	<14*trash
	jmp	imp+4*t+0,	<15*trash
lbl69	jmp	imp+5*t+0,	<16*trash
lbl35	spl	lbl71,	<17*trash
	jmp	imp+6*t+0,	<18*trash
lbl71	jmp	imp+7*t+0,	<19*trash
lbl9	spl	lbl19,	<20*trash
	spl	lbl37,	<21*trash
	spl	lbl73,	<22*trash
	jmp	imp+8*t+0,	<23*trash
lbl73	jmp	imp+9*t+0,	<24*trash
lbl37	spl	lbl75,	<25*trash
	jmp	imp+10*t+0,	<26*trash
lbl75	jmp	imp+11*t+0,	<27*trash
lbl19	spl	lbl39,	<28*trash
	spl	lbl77,	<29*trash
	jmp	imp+12*t+0,	<30*trash
lbl77	jmp	imp+13*t+0,	<31*trash
lbl39	spl	lbl79,	<32*trash
	jmp	imp+14*t+0,	<33*trash
lbl79	jmp	imp+15*t+0,	<34*trash
lbl5	spl	lbl11,	<35*trash
	spl	lbl21,	<36*trash
	spl	lbl41,	<37*trash
	spl	lbl81,	<38*trash
	jmp	imp+16*t+0,	<39*trash
lbl81	jmp	imp+17*t+0,	<40*trash
lbl41	spl	lbl83,	<41*trash
	jmp	imp+18*t+0,	<42*trash
lbl83	jmp	imp+0*t+1,	<43*trash
lbl21	spl	lbl43,	<44*trash
	spl	lbl85,	<45*trash
	jmp	imp+1*t+1,	<46*trash
lbl85	jmp	imp+2*t+1,	<47*trash
lbl43	spl	lbl87,	<48*trash
	jmp	imp+3*t+1,	<49*trash
lbl87	jmp	imp+4*t+1,	<50*trash
lbl11	spl	lbl23,	<51*trash
	spl	lbl45,	<52*trash
	spl	lbl89,	<53*trash
	jmp	imp+5*t+1,	<54*trash
lbl89	jmp	imp+6*t+1,	<55*trash
lbl45	spl	lbl91,	<56*trash
	jmp	imp+7*t+1,	<57*trash
lbl91	jmp	imp+8*t+1,	<58*trash
lbl23	spl	lbl47,	<59*trash
	spl	lbl93,	<60*trash
	jmp	imp+9*t+1,	<61*trash
lbl93	jmp	imp+10*t+1,	<62*trash
lbl47	spl	lbl95,	<63*trash
	jmp	imp+11*t+1,	<64*trash
lbl95	jmp	imp+12*t+1,	<65*trash
lbl3		mov.i	bomb,	66*trash	; Idle
	mov.i	bomb,	67*trash	; Idle
	spl	lbl25,	<68*trash
	spl	lbl49,	<69*trash
	spl	lbl97,	<70*trash
	jmp	imp+13*t+1,	<71*trash
lbl97	jmp	imp+14*t+1,	<72*trash
lbl49	spl	lbl99,	<73*trash
	jmp	imp+15*t+1,	<74*trash
lbl99	jmp	imp+16*t+1,	<75*trash
lbl25	mov.i	bomb,	76*trash	; Idle
	spl	lbl101,	<77*trash
	jmp	imp+17*t+1,	<78*trash
lbl101	jmp	imp+18*t+1,	<79*trash
imp	mov.i	#0,	t
trash	equ	693

		end	start


Article 2775 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: Corewar Tutorials
Date: 23 Apr 1994 22:24:34 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 10
Message-ID: <2pc772$9fi@agate.berkeley.edu>
NNTP-Posting-Host: soda.berkeley.edu

To go with Steven Morrell's wonderful corewar tutorial, I would like to write
a basic redcode tutorial for new corewar programmers.  I think that this would
be useful because the standard tutorial.1,2 files are getting dated, and there
is no really good '94 draft tutorial for beginners (that I can find).

Does anyone else think this would be useful?
-- 
             - Michael Constant (mconst@soda.berkeley.edu) -

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


Article 2777 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!swrinde!gatech!news-feed-1.peachnet.edu!apollo1.cacd.rockwell.com!newsrelay.iastate.edu!dunix.drake.edu!acad.drake.edu!pk6811s
From: pk6811s@acad.drake.edu
Subject: '94 Standard
Message-ID: <1994Apr23.190831.1@acad.drake.edu>
Lines: 56
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
Date: Sun, 24 Apr 1994 01:08:31 GMT

It seems likely to me that there are three warrior forms put at a 
disadvantage under the 94 rules.  These may not be completely fatal,
only time will tell.

First is the carpet-bombing cmp-scanner using a djn-stream.  The djn-
stream is succeptible to a stone using post-increment in this fashion:

    stone  mov >a,b

Post-increment leaves DAT 0,1's all over core.  When the djn-stream
of the cmp-scanner runs over a DAT 0,1 it falls into its bombing routine,
wasting time.  Carpet-bombers can waste a LOT of time doing this.  Worse,
both carpet-bombers and spl-jmp bombers can be tricked into bombing
their own code with this technique.

How important is the djn-stream to the success of cmp-scanners?  Or to
stones for that matter?  Stones won't waste a lot of time on these
dat 0,1's, but the continued draining of processes may upset the timing
between the stone and some other component of the program.  My own
Keystone is history, since it thinks any 1's are paper.

Second, under 94 very good antivamp code is trivial.  Here's an example:
    
    spl 1
    spl 1
    spl 1
av1 add.ab <-10,@av2
av2 mov bomb,<-10

av1 adds the a-operand of 8 instructions to the location that av2 is
pointing at, then av2 bombs from wherever that points to.  Since the
vampire fang is a jmp statement, and jmp's always jump to their
a-operand, this routine bombs the pit immediately on detecting a fang.
Put the two lines in one of a set of replicators and you'll rarely
lose to a vampire.  There may be ways for vampires to mask their fangs,
but it certainly will make them less efficient to do so.

Third (sorry Wayne) Night and its derivatives Night Crawler and NC Decoy.
Night uses a mod-2 bombing pattern, then mops up by ADDing
its dat-increment to every instruction in core.  Normally this causes
any surviving SPL 0's to jump into never-never land and die.  However
this can be prevented by using the immediate-mode on the SPL's a-operand:

    spl #0
    
No matter if something is added to the zero, the immediate mode guarantees
the split won't jump away.  

--

This is not meant to be a vote against the 94 rules, I kind of like
the new features.  But you can bet all my warriors will be taking advantage
of THESE features from now on :-)

Paul Kline
pk6811s@acad.drake.edu


Article 2779 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!swrinde!emory!news-feed-2.peachnet.edu!st6000.sct.edu!not-for-mail
From: wsheppar@sct.edu (Wayne Sheppard)
Newsgroups: rec.games.corewar
Subject: Re: '94 Standard
Date: 24 Apr 1994 13:13:03 -0400
Organization: Southern College of Technology, Atlanta
Lines: 42
Message-ID: <2pe9av$n1v@st6000.sct.edu>
References: <1994Apr23.190831.1@acad.drake.edu>
NNTP-Posting-Host: st6000.sct.edu

In article <1994Apr23.190831.1@acad.drake.edu> pk6811s@acad.drake.edu writes:

>Third (sorry Wayne) Night and its derivatives Night Crawler and NC Decoy.
>Night uses a mod-2 bombing pattern, then mops up by ADDing
>its dat-increment to every instruction in core.  Normally this causes
>any surviving SPL 0's to jump into never-never land and die.  However
>this can be prevented by using the immediate-mode on the SPL's a-operand:
>
>    spl #0

Lucky for me, I've already adapted to these changes.  One good trick
for the stones out there is to use the SPL as your constants.

	spl #2234,#-2234

This acts just like an spl 0, but can be added to your MOV statement
to eliminate a DAT line.

Speaking of the ADD/coreclear,  I've discarded that.  Some of you
may notice that NC 94 now picks up 15-20 wins vs imps.  Instead
of the addition coreclear I now jump to a coreclear/gate.

	spl #-3044,<3044
	add -1,1
	mov >1-3044-3044,1
	jmp -2

After bombing the core at mod-4, MOV increments the ADD.  Then
ADD adds the SPL to JMP.  This causes all 100 or so processes
to JMP to the coreclear routine.  Then the MOV increments ADD
again, so the JMP doesn't get changed.

I haven't had time to optimize it, so no full code release yet.
Maybe I need to add a quick-cmp scan?  ;)

Wayne Sheppard
wsheppar@st6000.sct.edu


-- 
Wayne Sheppard
wsheppar@st6000.sct.edu


Article 2781 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Re: '94 Standard
Message-ID: <1994Apr24.214628.12844@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: <1994Apr23.190831.1@acad.drake.edu>
Date: Sun, 24 Apr 1994 21:46:28 GMT
Lines: 24

In article <1994Apr23.190831.1@acad.drake.edu> pk6811s@acad.drake.edu writes:
>It seems likely to me that there are three warrior forms put at a 
>disadvantage under the 94 rules.   [..]
>First is the carpet-bombing cmp-scanner using a djn-stream.  The djn-
>stream is succeptible to a stone using post-increment in this fashion:
>
>    stone  mov >a,b
>
>Post-increment leaves DAT 0,1's all over core.  When the djn-stream
>of the cmp-scanner runs over a DAT 0,1 it falls into its bombing routine,
>wasting time.  Carpet-bombers can waste a LOT of time doing this.  Worse,
>both carpet-bombers and spl-jmp bombers can be tricked into bombing
>their own code with this technique.
>[..]
>Paul Kline

Easy to avoid this one. Simply decrement core with

djn.f -3,<-100

This instruction only falls thru if both A and B-number are 1 (and does
more damage incidentally).

-Stefan (stst@vuse.vanderbilt.edu)


Article 2782 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!caen!saimiri.primate.wisc.edu!ames!agate!howland.reston.ans.net!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: EBS tourney round 1 results
Message-ID: <1994Apr25.031812.19259@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: Mon, 25 Apr 1994 03:18:12 GMT
Lines: 65


Results for the 1st round of the spring EBS tournament are in. This was
truly a battle of the imps (except for Brant's vampire "Request-55440"). As
others have pointed out, the big coresize seems to favor imp/stone combos
heavily. Perhaps this is because two of their "natural ememies" are not very
effective: Quick-scans cannot cover the entire core because of the program
length limit and papers just don't fill the big core fast enough.

Here are the results. Pairings were chosen randomly.
------------------------------------------------------------------------
Der Zweite Blitzkrieg by Mike Nonemacher scores 94 (3 12 85)
Blue Funk by Steven Morrell scores 121 (12 3 85)

BigImps by James Layland scores 115 (10 5 85)
impostor by na'ndor sieben scores 100 (5 10 85)

Sauron v2.4 by Michael Constant scores 88 (25 62 13)
Request-55440 by Brant D. Thomsen scores 199 (62 25 13)

Bakers Dozen by Wayne Sheppard scores 52 (1 50 49)
Big by Jay Han scores 199 (50 1 49)
------------------------------------------------------------------------
In the second round, held coming Friday, April 29th, we'll have the
following confrontations:

Winner bracket:

    James Layland vs. Steven Morrell
    Jay Han vs. Brant Thomsen

Loser bracket:

    Nandor Sieben vs. Mike Nonemacher
    Wayne Sheppard vs. Michael Constant

The finalist of the loser bracket will challenge the finalist of the winner
bracket for the tournament champion title. The rules for the second round
will be "standard" '94 specs, i.e.:

    coresize:      8000
    max processes: 8000
    max cycles:    80000
    max length:    100
    min distance:  100
    standard:      draft '94+SEQ,SNE,NOP

If you don't send new entries by next Friday, I'll use this round's :-)

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

P.S.: these are the round-robin results (no bearing on the outcome of the
tournament):
------------------------------------------------------------------------
Elapsed time: 15025 seconds (04:10:25)

Rank    Name                    Author                   %W  %L  %T   Score
___________________________________________________________________________
  1     Big                     Jay Han                  32  11  57   1380
  2     Request-55440           Brant D. Thomsen         43  35  23   1352
  3     Sauron v2.4             Michael Constant         29  37  34   1088
  4     Blue Funk               Steven Morrell           16  11  73   1081
  5     Der Zweite Blitzkrieg   Mike Nonemacher          14  12  75   1044
  6     BigImps                 James Layland             8  13  78   927
  7     Bakers Dozen            Wayne Sheppard           11  20  70   916
  8     impostor                na'ndor sieben            7  20  73   839


Article 2785 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!darwin.sura.net!news.Vanderbilt.Edu!stst
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: Re: Should a newbie learn '88 or '94+SEQ,SNE,NOP ?
Message-ID: <1994Apr26.044550.17469@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: <2phpsi$n1o@news.iastate.edu>
Date: Tue, 26 Apr 1994 04:45:50 GMT
Lines: 32

In article <2phpsi$n1o@news.iastate.edu> mds@iastate.edu (Mark D. Smucker) writes:
>I've been getting interested in core war now for about a week and have
>a good clue about how to start writing programs, but was wondering
>what the suggested standard is.
>
>Is everyone writing '94+SEQ,SNE,NOP code now?
>

'88 and '94 are not really that much different, but '94 lets you do things
in fewer lines of code. I would actually suggest starting off by learning
'94, because the modifiers make the code more transparent (IMO at least), 
and '94 subsumes '88. (SEQ),SNE,NOP are very much experimental at this
point, i.e. no one has published code that uses these opcodes to an 
advantage.

>Can '88 programs do well against "smarter" '94+SEQ,SNE,NOP programs?
>

Many '88 programs can be shortened by a few intructions by translating
them into '94. This makes them more difficult to find and therefore higher
scoring but hardly smarter. Only time will tell whether the additional
flexibility that '94 allows will result in a greater diversity of strategies.
It took three years after the introduction of ICWS'88 for CMP-scanners, and
four years for imp-spirals to be discovered (imp-spirals were possible even
under ICWS'86), and we have only just started programming in ICWS'94.

>Thanks,
>
>Mark D. Smucker  ---  mds@iastate.edu
>

-Stefan (stst@vuse.vanderbilt.edu)


Article 2786 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!fcom.cc.utah.edu!u.cc.utah.edu!math.utah.edu!news.math.utah.edu!morrell
From: morrell@math.utah.edu (Steven C. Morrell)
Subject: Re: More redcode (Big)
Sender: news@math.utah.edu
Date: Tue, 26 Apr 1994 06:32:20 GMT
References: <JAYHAN.94Apr22122551@derkins.cs.washington.edu>
	<2p99ba$j72@agate.berkeley.edu>
In-Reply-To: mconst@soda.berkeley.edu's message of 22 Apr 1994 19: 42:34 GMT
Organization: Department of Mathematics, University of Utah
Message-ID: <MORRELL.94Apr26003221@jeeves.math.utah.edu>
Lines: 12

In article <2p99ba$j72@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes:

   Hmmm... Kill More Imps!!! can't beat Imperfection either.  Hey Steven, what
   is it supposed to beat if not imps?  Or are Imperfection and Skimp 127 just
   special cases?  I think the original Kill Imps!!! was more effective against
   my programs.

Kill More Imps!!! is designed to trap 13-pt imps only.  But, hey, it's a lot
shorter than Kill Imps!!!  And you need a different kind of decoy to fool
each of them.  It sounds like I'd better submit the original again 8D

Steven Morrell           morrell@math.utah.edu


Article 2788 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: Re: Corewar Tutorials
Date: 26 Apr 1994 17:09:36 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 14
Message-ID: <2pjhsg$16v@agate.berkeley.edu>
References: <2pc772$9fi@agate.berkeley.edu>
NNTP-Posting-Host: soda.berkeley.edu

Due to the overwhelmingly positive response (two posts, 12 (!) letters) I
will be writing the promised tutorial.  To clarify, my tutorial will be a
basic redcode tutorial, with '88 and '94 draft standards.  It will *not*
teach how to write *good* programs -- that's what Steven's tutorial is for.
The two tutorials will complement each other, because Steven's assumes a
basic familiarity with redcode programming.

It should be available on soda within two weeks or so (I'll post an
announcement here).  Anyone who doesn't have ftp can mail me and I will
send them a copy when it's done.
-- 
             - Michael Constant (mconst@soda.berkeley.edu) -

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


Article 2790 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!usc!math.ohio-state.edu!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: '94 Standard
Message-ID: <1994Apr26.210927.1@acad.drake.edu>
Lines: 33
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
References: <1994Apr23.190831.1@acad.drake.edu> <2pe9av$n1v@st6000.sct.edu>
Date: Wed, 27 Apr 1994 03:09:27 GMT

In article <2pe9av$n1v@st6000.sct.edu>, wsheppar@sct.edu (Wayne Sheppard) writes:

> 	spl #-3044,<3044
> 	add -1,1
> 	mov >1-3044-3044,1
> 	jmp -2
> 

And if you arrange it like this:

capstone spl #step,<-step
stone    mov >cnt-(step*count1),cnt+(step*count1)
         add capstone,stone
cnt      jmp stone,capstone

'cnt' will get bombed with the spl and all your cycles can fall directly
into your 2-pass core-clear :-)

The 2-pass core-clear is definitely good for stone against paper, but
seemingly useless against imps :-(

BTW, here's an interesting '94 imp structure:

        spl 1
        spl 1
        spl 1
        jmp >0,imp
imp     mov 0,>1

Not very durable against most opponents, but can overrun a wimp.

Paul Kline
pk6811s@acad.drake.edu


Article 2791 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!usc!cs.utexas.edu!asuvax!asuacad!ahnas
Organization: Arizona State University
Date: Tue, 26 Apr 1994 23:32:53 MST
From: <AHNAS@ASUACAD.BITNET>
Message-ID: <94116.233253AHNAS@ASUACAD.BITNET>
Newsgroups: rec.games.corewar
Subject: pmarsv grx display
Lines: 32

We need help to decide what would be the best way to display in pmarsv
graphics version.
In the last version (DJGPP alpha release) I use
**  *.  ..  .*  *.
**  *.  **  *.  ..
For diplaying execution,increment,decrement,write, read .
The problem with this is that if a location is displayed as execution then
it overwrites any previous access. For example we can't tell who wrote last
the location where a process died.
In mars88 I use 3x3 raster, exetution is displayed as an empty box, and all
the other accesses displayed as a single point in the middle of the box.
This way an execution and a write can be seen at the same time. The problem
with this approach is that read,write,increment all looks like the same.
To solve this problem I made it possible to determine separately which accesses
we want to display and which we don't . In pmarsv it's not possible we can't
display read access only when write access is also displayed.
Since pmarsv works with big coresize I can't use 3x3 raster simply because
I don't have enough room. Michael's suggestion is to use
**
*. for write
and
..
.* for write
I'm not sure what he wants for read, increment, decrement.

Please send your opinion about this problem. I want to implement the most
popular way to do this. Please look at mars88 if you don't know what I
mean by separate adjustment of read/write/increment .
If nobody understands what I'm saying (this is very much possible) just
tell me and I'll try to explain it.
Thanks,
Nandor.


Article 2792 of rec.games.corewar:
Path: hellgate.utah.edu!utah-morgan!cs.utexas.edu!swrinde!ihnp4.ucsd.edu!agate!mconst
From: mconst@OCF.Berkeley.EDU (Michael Constant)
Newsgroups: rec.games.corewar
Subject: Re: pmarsv grx display
Date: 27 Apr 1994 19:34:41 GMT
Organization: Society for Prevention of Cruelty to Vegetables, U.C. Berkeley
Lines: 39
Message-ID: <2pmeoh$s1a@agate.berkeley.edu>
References: <94116.233253AHNAS@asuacad.bitnet>
NNTP-Posting-Host: flood.berkeley.edu

In article <94116.233253AHNAS@asuacad.bitnet>,  <AHNAS@ASUACAD.BITNET> wrote:
>We need help to decide what would be the best way to display in pmarsv
>graphics version.
>In the last version (DJGPP alpha release) I use
>**  *.  ..  .*  *.
>**  *.  **  *.  ..
>For diplaying execution,increment,decrement,write, read .

My main concern is that when a process dies (or malfunctions) you can't tell
who wrote to it last.  We could fix this by making execute
	*.
	**
and leaving all the others the same.  The main problem with *this* is that
then an increment and a decrement to the same location would look like an
execution, which would be a Bad Thing.  Also you wouldn't see anything if
a part of your program was decremented or incremented.

So, the best solution I can come up with is to have two modes -- pmarsv mode
and mars88 mode.  In mars88 mode execute would be
	**
	*.
and everything else would be
	..
	.*
with a selector to determine what is displayed.  In pamrsv mode, the display
would work as it currently does.  That way you could use pmarsv mode when
you want to see exactly what is being done to core (by a stone, for example)
but mars88 mode when you need to analyze why some part of your program is
failing.  Remember, the selector in mars88 mode makes it a good deal more
powerful than you might think at first glance.

Oh, and one other thing.  Would it be easy to make the graphics display use
the easier-to-read 3x3 raster for small (say <10000 or so) coresizes and
only use the 2x2 for big ones, or will it have to use the 2x2 for everything
(like the current alpha version)?
-- 
               Michael Constant (mconst@soda.berkeley.edu)

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


Article 2795 of rec.games.corewar:
Newsgroups: rec.games.corewar
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!ub!acsu.buffalo.edu!bcohen
From: bcohen@acsu.buffalo.edu (Bram Cohen)
Subject: Low competition on the '88 hill?
Message-ID: <Cp1uoK.L35@acsu.buffalo.edu>
Sender: nntp@acsu.buffalo.edu
Nntp-Posting-Host: lictor-14.acsu.buffalo.edu
Organization: University @ Buffalo
Date: Sat, 30 Apr 1994 01:55:31 GMT
Lines: 11

I managed to get a warrior onto the very bottom of the '88 hill a few days ago
and, much to my surprise, it's still there. Has so much of the action now
moved onto the '94 hill that noone wants to bother pushing a poor pathetic 
imp-spiral like myself off the bottom of the '88 hill?


-- 
       ___   ___  /  \____                  ############################
      /   \_/   \ \_   __ \                 # Bram Cohen               #
     /           \_/  /  \/                 # bcohen@acsu.buffalo.edu  #
    /\            ___/                      # Just trying to be myself #


Article 2797 of rec.games.corewar:
Path: hellgate.utah.edu!dog.ee.lbl.gov!ihnp4.ucsd.edu!agate!howland.reston.ans.net!cs.utexas.edu!not-for-mail
From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack)
Newsgroups: rec.games.corewar
Subject: EBS spring tournament: round 2 results
Date: 30 Apr 1994 14:34:17 -0500
Organization: UTexas Mail-to-News Gateway
Lines: 55
Sender: daemon@cs.utexas.edu
Message-ID: <9404301927.AA04550@idnsun.gpct.Vanderbilt.Edu.noname>
NNTP-Posting-Host: cs.utexas.edu

The second round of the EBS spring tourney featured a wide variety of
strategies: next to imps we had paper (repimp), vampires and an
anti-imp scanner (ivscan).

In the winner bracket, James Layland's ivscan outdid Steven Morrell's ^C,
and Jay Han's Small defeated Brant Thomsen's Request. Next week's round
looks like a battle of the big J's when Jay and James meet for the remaining
match in the winner bracket. Steven and Brant move to the loser bracket,
where they will continue to fight until a single challenger for the winner
bracket finalist remains.

    ^C by Steven Morrell scores 93 (22 51 27)
    ivscan by J.Layland scores 180 (51 22 27)

    Request v2.0 by Brant D. Thomsen scores 121 (30 39 31)
    Small by Jay Han scores 148 (39 30 31)

In loser bracket, Michael Constant's Sauron succumbed to Wayne Sheppard's NC
94, and Nandor Sieben's repimp (read rep-imp :-) was defeated by Mike
Nonemacher's Paradox. Michael and Nandor are out of the tournament; thanks
for playing, guys. Wayne and Mike continue on.

    NC 94 by Wayne Sheppard scores 156 (37 18 45)
    Sauron T by Michael Constant scores 99 (18 37 45)

    Paradox v2 by Mike Nonemacher scores 115 (9 3 88)
    repimp by nandor sieben scores 97 (3 9 88)

To recap, here the pairings for round 3, held next Friday May 6th:

J.Layland vs. Jay Han

Steven Morrell vs. Brant Thomsen
Wayne Sheppard vs. Mike Nonemacher

Remember, next round we're back to 94x, i.e. big core rules (and I'll keep
trying to upload the new big core graphics version of pmarsv to soda, so far
no luck).

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

P.S.: as always, here the round-robin results:

Elapsed time: 3461 seconds (00:57:41)

Rank    Name                    Author                   %W  %L  %T   Score
___________________________________________________________________________
  1     ivscan                  J.Layland                34  25  41   1293
  2     Sauron T                Michael Constant         37  33  30   1281
  3     Request v2.0            Brant D. Thomsen         36  36  28   1225
  4     Paradox v2              Mike Nonemacher          20  17  62   1109
  5     NC 94                   Wayne Sheppard           18  22  59   1030
  6     Small                   Jay Han                  17  20  63   1022
  7     ^C                      Steven Morrell           16  22  62   984
  8     repimp                  nandor sieben             3   6  91   894


Article 2798 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: Re: finding mod numbers
Date: 30 Apr 1994 22:38:45 GMT
Organization: Society for the Prevention of Cruelty to Vegetables, UC Berkeley
Lines: 20
Message-ID: <2pumll$l5t@agate.berkeley.edu>
References: <2pt2jt$5vn@cwis.isu.edu>
NNTP-Posting-Host: soda.berkeley.edu

Antonette Nixon <fullanto@cwis.isu.edu> wrote:
>Quick question.  How would I go about writing an algorithm to figure out 
>what mod a particular constant is?  For example, if I had the number 3158 
>(picked randomly just now), how would I go about finding what kind of a 
>bombing pattern using that constant would give?

There are two easy ways.  By far the better of the two is to get my Optima
program (not Nandor's -- his doesn't have this feature) from soda (mail me
for the filenames if you don't have them already).  Optima has a feature for
testing any given step size and telling you its mod number and optima number.

The other way is to write a Dwarf program using that step size, and watch
it on a graphical core-viewer until the pattern repeats.  Then count the
space between bombs.  (You have to write a slightly more complicated bomber
if the mod number is less than 4, so that is doesn't hit itself.  It's not
hard though.  Mail me if you have any questions.)
-- 
             - Michael Constant (mconst@soda.berkeley.edu) -

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