This file describes the archimedes implemention of Corewars, and explains
some of the features.
Desktop front end
In the Corewars suite of programs, there should be four different applicat-
ion directories, !CoreInfo, !CoreDebug, !CoreProgs and !CoreWars. This suite
is PUBLIC DOMAIN and may only be distributed with all four parts complete.
The purpose of each application unit is as follows:-
!CoreInfo - Double clicking on this will open a directory viewer holding
six text files, '!Corewars', 'colours', 'intro', 'commands', 'contacts' and
'glossary'. Some information may be repeated in different files. See the end
of file 'intro' for the contents of the other files. Most information in this
file is for beginners to Corewars, and should be read carefully (if you have
any other queries, problems or have found bugs, please get in touch with me).
!CoreDebug - Double clicking on this will load up the REDCODE debugger,
which sits on the icon bar. This will process files dragged on to it, giving
a full report on the compilation, in order that you can trace mistakes in
your programs. The same compiler is present in the main program, but does not
give any specific errors, and the actual application !Corewars normally does
not have enough memory to multi-task with !Edit.
In order that a program is recognized by Corewars, it must have a filetype
'text', and may contain either line-feeds (ASCII 10) or carriage-returns
(ASCII 13) to seperate lines. It cannot contain the ASCII value 0, as this
is used as a marker by the compiler. For more details on the actual syntax,
see the file 'commands'.
!CoreProgs - Double clicking on this will open up a directory viewer of a
directory called 'progs'. Various example programs are in here, and you may
wish to use it for your own programs, but !Corewars doesn't care where you
keep them (which is an advantage over any non-desktop versions).
!CoreWars - This is the main program in the suite, and deals with the
actual execution of the various programs. It has a desktop front end, with
an options window from which you can select various different configurations,
although once a battle is started, it can be paused and the options changed
via a different menu on-screen.
To begin with, the various different options are:-
'Flash when dead' - when selected, the program will pause every time a split
halts execution (ie dies) and flash the cell where it tried to execute the
instruction which was invalid. This can slow things down a fair bit, however,
when running programs which repeatedly split execution and then get killed
quickly. Otherwise, the split dying will disappear without a trace.
'Pause between rounds' - this applies to tournaments (see below), and when
selected, the program will beep and display the result at the end of each
round, waiting for space, otherwise it will keep reloading and fighting
rounds until the prescribed number have been fought (without requiring user
interaction).
'Timeout no win' - if the executions limit has been reached (limit set by
user - see below) or the game has been aborted, this will decide the result.
If selected, this will mean that the game is marked 'timeout' and neither
side would score a point in a tournament. Otherwise, the side with the most
instructions originally compiled will win and gain a point in a tournament
(this was to encourage the practice of writing longer, and therefore more
interesting programs).
'Single step' - if selected, the program will pause between each individual
execution of every different split (if more than one exist), to facilitate
easier debugging (if used in conjunction with a debug mode), and you need
to press and release Ctrl-S to step to the next instruction.
'No limit to executions' - normally, there is a limit set to the number of
executions performed by each side before the game is declared a draw, or
whatever. With this option selected, however, the execution counter will
reset itself every time it reaches the limit, so in effect the game never
ends, until a side has died or the user terminates the game with Ctrl-A etc.
'Executions limit' (number) - This determines how many executions will be
performed on either side before the game is considered a draw etc. The limit
is 256-999999 executions (999999 sounds a lot, but some battles last a long
time!)
'Last result: .. in .. executions' - This gives the result of the last
game, or round played. The possible results are 'green/red win', 'draw' and
'timeout'. The difference between draw and timeout is thus: If 'timeout no
win' is selected, and a game runs out of time, it is considered a 'timeout'.
Otherwise, if programs are judged for winner by length, and they are of equal
size (ie same program on both sides), then the result is considered a 'draw'.
'Main display window...' - Part of the screen during the actual execution is
set aside for a display of the battle. What the different displays are is as
follows: 'Debug 1' = Dissassembles and prints the last execution performed by
each side underneath the filename of each side, as well as the cell number.
'Nothing' = just prints the name of each program up, and does nothing else
during the battle to gain extra speed. 'Debug 2' = dissassembles in the
same fashion as 'debug 1', but scrolls each pair of instructions down the
display window, and wraps around constantly, so you can see the previous few
instructions performed by each side, although different splits are not
distinguished between. NB Both debug modes are comparatively slow modes, and
so should only usually be used when debugging if you want more speed at other
times. Finally.. 'Closeup' = During the battle, the pointer is turned on, and restricted to the battle area. Clicking the select button on a point will
enlarge the surrounding cells to x16 in the display window. Clicking the adj-
ust button on a point does the same, but dissassembles the instructions. If
you use <control> with any cursor key, the enlarged display will scroll in
the direction you choose, cell by cell, until you reach the limit of the
battle area.
'random start' - when selected, the place at which the relevant program
will be initially compiled into memory is determined randomly, and can be any
cell between 0-31999 and no nearer than 2000 cells to the start of the other
program (to prevent overlap of programs) - similarly programs may not extend
more than 1000 cells in either direction when being compiled.
'define start' - if selected rather than 'random start', the place at which
the relevant program is initially placed in memory is defined by the user,
and the cell address given in the box to the right, with the limitation of
0-31999 and it cannot be closer than 2000 cells to the other program. If you
are playing a tournament, both programs cannot be in fixed positions for
obvious reasons (work it out for yourself!)
Tournaments and related options
One game may not be representative of a program's overall performance
against another, and so to cater for this, a system of tournaments exists
whereby a set number of different 'rounds', or seperate games, are fought
automatically by the computer, and the results collated afterwards. The
number of rounds which can be played is between 1 and 500 (which should give
scope for more realistic results!). This value is entered in the box below
'number of rounds'.
To play a tournament, just choose 'tournament' from the main corewars menu
instead of 'one game', and the menu option 'reset table' will reset the
tournament results.
The results are presented in the box to the right of the program info boxes.
Program execution
Once the programs to fight have been selected by dragging them on the
options window or the !Corewars icon, and either a tournament or one game has
been selected on the menu, the screen is cleared and set up to execute the
programs. The programs are loaded and compiled in turn, and the screen up-
dated to show where they have been placed in memory. The actual compiling
takes only a small fraction of a second once the programs have been loaded.
The screen display needs a little explanation, and can be divided up into
different areas:-
Main memory display (grey outlined black box in centre of screen) - this is
a visual representation of the heart of the MARS computer - the core. A
complex colour scheme is used to indicate the status of the different cells
of memory and this is detailed in the file 'colours'. Initially, however, it
is all cleared to black. As the battle progresses, this area will be updated
rapidly as the programs execute.
Display window (blank space below main core window) - this is used in diff-
erent ways depending on the current display mode, but this is where the
debugging, closeups or whatever are displayed during the battle, and also
where the result is displayed after a battle, if applicable.
Options (at top of screen) - Normally inaccessable during the battle, these
options mirror the options on the corewars window on the desktop. If you
press Ctrl+P the battle will be paused, and the mouse appear above the op-
tions. Clicking on an item will either select it (in the case of display
mode) or toggle it. Most items are straightforward, and described above.
To resume the battle, click on the bottom left item 'RESUME'.
Time (long bar along bottom of screen) - This bar shows the relative prog-
ress of the current battle in red, and when the bar reaches the right-hand
end, it will either end the battle in a timeout etc., or reset if 'no limit
to executions' is selected. The length of the bar is calculated to be prop-
ortional to the executions limit.
Splits (counters up left-hand side) - These indicate the number of active
(living) splits existing on both sides (when either reaches zero, one side
has completely died).
Speed (indicator up right-hand side) - This indicator is altered by pressing
Ctrl and either + or - during the battle. When the red bar is fully up, the
programs will execute at full speed with no delays, but otherwise they will
execute more slowly as the bar goes down, to quite a slow speed.
Controls
A summary of the controls available during the battle are as follows:
(Ctrl=control)
Ctrl alone - select very slow mode; when Ctrl is held down, two things
happen: both programs execute very slowly (1 execution per side per 1/50
second [vsync]) and every instruction executed is highlighted for a short
duration. This also happens during single step mode.
Ctrl+ '+' increase speed
Ctrl+ '-' decrease speed
Ctrl+P pause
Ctrl+S step through instructions (in single step mode)
Ctrl+A abort one round (or game)
Ctrl+Q abort whole tournament including current round
Ctrl+<cursor key> scroll display window when in closeup mode (mouse pointer
will move to point to centre of enlargement)
Programming techniques
The archimedes version of Corewars has several different parts to it. The
desktop front-end of !Corewars and !CoreDebug is written almost entirely in
BASIC. The compiler sections of both programs is written in machine code, and
most of the MARS simulation is machine code except for little sections during
pauses and after battles etc. This is to give the greatest speed possible.
There are two main arrays in memory which are needed to run programs. The
first contains the opcodes of all the instructions, and is bytewise. The
high nibble (top 4 bits) of each byte is the opcode (0-15) and the low nibble
contains the addressing mode flags (a total of 2 bits for each operand).
The second array contains the operands, and each cell is a word long (4
bytes). The high two bytes contain operand A, with the top bit indicating
sign, and the low two bytes contain operand B in the same way.
A further array of a kind would be needed to provide information such as
whether the cell was protected, and unneccessary but useful information such
as whether the cell had been executed, and by whom. Because writing to a
seperate status array and then plotting points on the screen to update the
change in status would be time-consuming and also space-devouring (it would
need another 32000 unit array), I decided to take a risky shortcut and
directly access screen memory, and the different bytes representing the
different colours on screen are manipulated in such a way as if they are
just bit-flags. The result is a high operating speed and a saving of space,
and the closeup display routine, for example, only needs to just copy one
block of screen memory to another, enlarging in the process.
I hope you can make good use of this program and are interested in the ideas
