home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Overload
/
ShartewareOverload.cdr
/
games
/
corewars.zip
/
COREWARS.DOC
< prev
next >
Wrap
Text File
|
1986-05-20
|
7KB
|
141 lines
COREWARS.DOC 09/22/1984
Documentation for COREWARS.EXE Ver. 2.00
This game was written by A.K. Dewdney and presented in the May,
1984 issue of Scientific American magazine. Since it is
impossible to explain all its details here without infringing on
Scientific American's copyrights, you'll have to get a copy and
read the instructions for yourself.
This particular realization of Dewdney's game was written by
Kevin A. Bjorke, who retains copyrights. Mr. Bjorke has,
however, released the game to the public domain for
non-commercial use only.
Bob Green converted Bjorke's work to MS-DOS V. 2.xx from
Bjorke's original in CP/M and from Small-C V. 2.03 to Computer
Innovations' C86 on June 7, 1984. Mr. Green's version was
customized for the TeleVideo 950 terminal and reduced the size of
Dewdney's core from 8000 bytes to 1000. This game can take a
long time to run if both players' instructions to the computer
are sophisticated. Smaller core may shorten the time of play.
On the other hand, it might not.
Harvey Lord converted Green's work to the Lattice C compiler, V.
2.12 and to the VT-100 terminal on September 22, 1984. It now
runs correctly on the DEC Rainbow 100, 100+ and 100B, and on the
IBM PC (and clones) running DOS V. 2.xx when the ANSI terminal
device drivers have been installed at cold boot.
*****
Core Wars pits one computer program against another in the dark
and lonely corridors of your computer's main memory, "core,"
named after the memory cores or rings of late 1950s-early 1960s
computers. Each player writes his or her program, enters it via
prompts at the outset or by having it in a file which COREWARS
reads. The programs then take turns executing instructions,
first one, then the other. Once execution begins, the first
program to render the other incapable of executing its next
instruction wins.
The programs COREWARS executes are written in a simple version of
assembly code called REDCODE. REDCODE has only nine
instructions.
INSTRUCTION MNEMONIC CODE ARGUMENTS EXPLANATION
----------- -------- ---- --------- -----------
Move MOV 1 A B Move contents of
addr A to addr B
Add ADD 2 A B Add contents of
addr A to addr B
Subtract SUB 3 A B Subtract contents
of addr A from
addr B
Jump JMP 4 A Transfer control
to addr A
Jump if zero JMZ 5 A B Transfer control
to addr A if con-
tents of addr B
are zero
Jump if JMG 6 A B Transfer control
greater to addr A if con-
tents of B are
greater than zero
Decrement: DJZ 7 A B Subtract 1 from con-
jump if zero tents of addr B and
transfer control to
addr A if contents of
addr B are then zero
Compare CMP 8 A B Compare contents of
addrs A and B; if
they are unequal,
skip the next inst.
Data statement DAT 9 B A nonexecutable
statement: B is
the data value
There are three instruction "modes," direct, indirect, and
immediate. In direct mode, arguments are relative addresses on
which the program directly acts. They are "relative" to wherever
the program happens to be when it executes that instruction. In
indirect mode, specified by a @ before the argument, the data
acted upon are found in the address specified by the contents of
the specified address. In immediate mode, specified by a #
before the argument, the argument is treated as data, not as an
address. If you find this explanation confusing, don't worry.
Dewdney provides examples and expansion in his article.
Here are two simple programs written in REDCODE that produce
interesting results. One is called IMP, the other, DWARF.
IMP
MOV 0 1
IMP has only one instruction, executes from there. It moves
itself from its starting location, that is relative address 0, to
the next one and executes again from there. The idea is to plow
right through its opponent, thereby destroying it. It's a dumb
program, but dangerous.
DWARF
DAT -1
ADD #5 -1
MOV #0 @-2
JMP -2
Execution begins at the ADD instruction. DWARF simply sits still
where it is, but peppers the rest of memory with 0s. Since an
instruction is not executable when its memory address contains a
NULL (0), if DWARF fills its opponent's next address with a NULL,
it wins.
Dewdney provides one more, longer program, called GEMINI, that
relocates itself and gives suggestions on how to write others
that protect themselves, relocate themselves, repair themselves,
and attack their opponents. It's a first-rate article; read it.
If you come up with some nifty REDCODE programs, Dewdney would
like to hear of it (and so would I). He's reachable at
Scientific American, 415 Madison Avenue, New York, NY 10017. I'm
a programmer at Traveler's Insurance Co. Contact me at
203-429-8044 after 5:00 P.M. EST or on weekends.
Enjoy.
Harvey Lord