[comp.sys.amiga] Core Wars for Amiga

maloff@calgary.UUCP (Sheldon Maloff) (06/04/88)

In article <5605@bloom-beacon.MIT.EDU>, rlcarr@athena.mit.edu (Rich Carreiro) writes:
> I just downloaded CoreWars 1.1w (Chad_the_Walrus's Amy port of the
> 1984 Scientific American version of CoreWars).

Any well stocked library will have a back issue.  Unfortunately I just
lent my copy out today so I don't know what month it was.  In the article
you could also send for a detailed description of its implementation
for a few dollars (loonies in Canada).  I recommend getting the article,
it had some simple battle programs as examples and was fairly humorous
and thought provoking.


> So, what I would like is a desciption of each RedCode command does,
> what operands it takes, and what addressing modes it uses (and what
> they mean in the Redcode implementation.)

Corewars pits two programs against each other in core.  The supervisor
program is called MARS.  It loads the two programs into random places
in core and the time-shares by excuting first one instruction of the
first program, then one of the second, and so on.  The first program
that causes his enemy to cease operation (execute and illegal instruction)
wins.

There are only three instructions: (off the top of my head)
(keep in mind everything is relative addressing, as the two battle programs
 are loaded by the system (MARS, I believe) and may never know their
 absolute location.)

MOV x y - move the value located in memory at pc+x, to location pc+y
	  (remember: pc is the program counter and you never know what it is)
	  this is direct addressing mode

MOV #x, y - move the value x, into location pc+y (immediate addressing)

MOV @x, y - move the value located at pc+(pc+x), to pc+y (indirect addressing,
	    as the location (pc+x) is taken to be an address to the actual
	    location where the data is)

JMP x - jump, transfer execution to location pc+x, (I believe JMP does not
	have any other addressing modes)

Offsets may be positive or negative.

The last one is DAT, stands for data, and this is where things go weird.
In the article any memory location whose contents began with zero was
considered to be data, meaning the other two instructions have op codes
whose first digit are non-zero.  This is where the article comes in
handy since it describes the opcodes.  Anything that is DAT by the way
is an illegal instruction if it gets executed.

If corewars is implemented properly it should have an assembler with it,
which means you can try this small battle program, called Imp:

	MOV 0 1

It has the effect of copying the contents of location pc+0 to pc+1.
The contents of pc+0 are the move instruction (with arguments) itself, so
Imp simply moves through memory one location at a time.  The ultimate
goal of Imp is to walk over the enemy program and cause it to stop executing.
This will never happen of course, since Imp simply turns the enemy program
into a second imp (with some thought should be clear).

The article is really helpful, but I hope this will wet your appetite.
There was a follow up article exactly one year later on Core Wars also
in Sci. American relating new developments and some competitions that
were held.

> Thanks in advance,
>     Rich
> 
> ARPA: rlcarr@athena.mit.edu
> UUCP: ...!mit-eddie!athena.mit.edu!rlcarr
> BITNET: rlcarr%athena.mit.edu@mitvma.mit.edu

Now my question, I've heard it was available, but where? is it on a Fish Disk?
I'm itching to try it.

|| Sheldon                               ----========== \\        -----======||
|| maloff@calgary.UUCP                      -----====== //  Calgary, Alberta ||
|| {ihnp4!alberta}!calgary!maloff               -----== \\  Past Host of the ||
|| .. eventually, we'll all be scaled by zero and  ---= //  '88 Winter Games ||
|| converge upon the origin ... then we'll party!    -= \\              ---==||

Chad_The-Walrus_Netzer@cup.portal.com (06/04/88)

In a previous article (Rich Carreiro) writes:

>I just downloaded CoreWars 1.1w (Chad_the_Walrus's Amy port of the
>1984 Scientific American version of CoreWars).  However (and
>understandibly), Chad did not include any docs.  Can some kind soul
>describe to me the Redcode command set, required operands, and
>addressing modes.  For what it's worth, I am familiar with assembly
>language programming concepts (having done some SIMPLE things on a
>Radio Shack CoCo II).

	Sorry, but after I wrote the program, I didn't feel up to typing
in all the docs as to the concept of 'CoreWars' (rather than just the
"usage" docs)...  A while later, I started making a summary, but didn't
finish...  I'll see if I can dig it up, and add a little to it.  Of
course, the best solution would be if you could get the original Sci. 
Am.  article (as well as the followups...  I Think the original was in
the November, 1984 issue) You can ask me questions, and I'll try to
answer them (I've personally never written a single original program in
Redcode...  I just found the source, and after I had learned 'C' and was
taking a break from another project, I ported it, and added some nice
enhancements to make the program non-infuriating...  So I actually might
be of limited help :-) Also, I'm in the middle of finals, so that could
slow things down.  We should probably continue our discussion elsewhere,
so you can direct me to the proper newgroup (probably
rec.games.programmers). 
	Anyway, here goes the summary:


"add." = "address"

INSTRUCTION | MNEMONIC | CODE | ARGUMENTS |	 EXPLANATION
------------+----------+------+-----------+-----------------------------------
	    |	       |      | 	  |
MOVE	    |	MOV    |  1   | A	B | Move contents of add. A to add. B
	    |	       |      | 	  |
ADD	    |	ADD    |  2   | A	B | Add contents of add. A to add. B
	    |	       |      | 	  |
SUBTRACT    |	SUB    |  3   | A	B | Subtract contents of add. A from
	    |	       |      | 	  | add. B
	    |	       |      | 	  |
JUMP	    |	JMP    |  4   | A	  | Transfer control to add. A
	    |	       |      | 	  |
JUMP IF ZERO|	JMZ    |  5   | A	B | Transfer control to add. A if
	    |	       |      | 	  | contents of B are zero.
	    |	       |      | 	  |
JUMP IF     |	JMG    |  6   | A	B | Transfer control to add. A if
GREATER     |	       |      | 	  | contents of B are greater than zero
	    |	       |      | 	  |
DECREMENT:  |	DJZ    |  7   | A	B | Subtract 1 from contents of add. B
JUMP IF ZERO|	       |      | 	  | and transfer control to add. A if
	    |	       |      | 	  | contents of add. B are then zero.
	    |	       |      | 	  |
COMPARE	    |	CMP    |  8   | A	B | Compare contents of add. A and B;
	    |	       |      | 	  | if they are unequal, skip the
	    |	       |      | 	  | next instruction.
	    |	       |      | 	  |
DATA        |	DAT    |  0   | 	B | A nonexecutable statement;
STATEMENT   |	       |      | 	  | B is the data value.
	    |	       |      | 	  |

Addressing modes:	IMMEDIATE	#	(Refers to a numerical
						constant.)

			DIRECT			(Refers to a RELATIVE
						memory location at this
						ABSOLUTE offset.)

			INDIRECT	@	(Refers to the address
						contained at the address
						this points to)

Notes:
	Basically, things are PC relative.  Ie. the instruction:
		MOV #0 @-2 takes the value of 2 subtracted from PC counter
(@-2), takes the value stored there (Which I believe has to be stored as
a DAT statement, but I don't know for sure), and uses this as an offset
from THAT location.  It then takes this final location, and stores the
value of zero there (#0). 

	Direct addressing works as follows:
		MOV	0	1
	Takes the value of the address at the PC ( ie. PC + 0, or PC(0))
and stores it at the next memory location (ie PC + 1, or PC(1)).  Since
a single addressable memory location stores an ENTIRE instruction
including arguments (ie.  "MOV	0  1" can be stored completely at memory
location 1, and not spread out over locations 1,2 and 3, etc.), this
effectively makes a "Rogue" program that copies itself to the next
higher address, then transfers control to the next higher address, only
to copy itself again, ad infinitum...  This will go on forever (assuming
another program doesn't stop it), because CoreWar's memory is a 'loop',
ie. the very last location in memory is also equal to the very first
location in memory (0), and therefore has no logical "End".  Memory
location 8000, in a memory bank containg exactly 8000 "cells", becomes
address zero.  Address 8001 becomes address 1, and so on.
	That's the quick summary... ask me (or the Net) about anything
else you might need cleared.  It would be nice to find some more
programs, or organize a contest...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
				Chad 'The_Walrus' Netzer -> AmigaManiac++

"Amiga -- The computer for the BEST of us..."   - Gary Heffelfinger
			       ^^^^
				|_____ Let's put this one outside
Apple's H.Q.'s, huh? :-)

haitex@pnet01.cts.com (Wade Bickel) (06/04/88)

 
      WHERE CAN I GET A COPY?


                                THANKS,


                                        Wade.

UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COM

Chad_The-Walrus_Netzer@cup.portal.com (06/06/88)

In a previous article (Wade Bickel) writes:
 
>      WHERE CAN I GET A COPY?

	It was posted to comp.sys.binaries and comp.sys.sources a couple
of months ago...  If its not there anymore, E-Mail me, nad I will mail
it to you (as well as you Sheldon, and anyone who asks... But if a lot
of people ask, I might as well post the sources or ask the moderators to
post it agian, etc...)
	I sent it to Fred Fish, so maybe it will come out soon.  (I
think I will call him and ask if he got it... If not, I'll re-send it.)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
				Chad 'The_Walrus' Netzer -> AmigaManiac++

"Now remember, you don't want to stare directly AT Gene's legs."

	- My cousin Dave at the family get together in Florida, during the
"Who-has-the-least-suntanned-legs?" Contest.