aboutsummaryrefslogtreecommitdiff
path: root/README.md
diff options
context:
space:
mode:
Diffstat (limited to 'README.md')
-rw-r--r--README.md41
1 files changed, 23 insertions, 18 deletions
diff --git a/README.md b/README.md
index f50caf5..a012fdc 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,7 @@
# SALIS: A-life Simulator
![SALIS simulation](sim.png)
-*SALIS simulation running on the V1 architecture with the ncurses user interface*
+*SALIS simulation running the V1 architecture with the curses user interface*
## Overview
*SALIS* is a platform for conducting artificial life experiments. It enables
@@ -32,26 +32,29 @@ The python script compiles a temporary executable on the fly (compilation
typically takes less than a second) based on the specified arguments and
launches it immediately.
-Different architectures can be implemented as standalone C templates in the
-`arch/` directory. When creating a new simulation, you can select a specific
-architecture using the `--arch` argument.
+Different VM architectures can be implemented as standalone C files, plus an
+associated `arch_vars.py` script, within in the `arch/` directory. When creating
+a new simulation, you can select a specific architecture using the `--arch`
+argument.
-Similarly, different user interfaces are implemented as C templates within the
-`ui/` directory. For example, the `curses` UI launches a terminal-based
-simulation visualizer, allowing easy exploration of *SALIS* memory cores and
-processes. In contrast, the `daemon` UI provides minimal output, making it
-ideal for running *SALIS* as a background service. Unlike the `--arch`
-argument, you can choose a different `--ui` argument each time you load a
-saved simulation.
+Similarly, different user interfaces are implemented as C files, plus an
+associated `ui_vars.py` script, within the `ui/` directory. For example, the
+`curses` UI launches a terminal-based simulation visualizer, allowing easy
+exploration of *SALIS* memory cores and processes. In contrast, the `daemon` UI
+provides minimal output, making it ideal for running *SALIS* as a background
+service. Unlike the `--arch` argument, you can choose a different `--ui` argument
+each time you load a saved simulation.
As an example, the following command will launch a new *SALIS* simulation with 4
-copies of the `55a` ancestor organisms pre-compiled in each memory core. It
-will use the `salis-v1` architecture, run on 8 memory cores, with each core
-having a size of 2^22 bytes. The PRNG seed is set to `123456789`:
+copies of the `55a` ancestor organisms pre-compiled in each memory core. It will
+use the `v1` architecture, run on 8 memory cores, with each core having a size
+of 2^22 bytes. The PRNG seed is set to `123456789`:
```console
-user@host$ ./salis.py new -A55a -asalis-v1 -c8 -C4 -m22 -nworld-1 -s123456789 -o
+user@host$ ./salis.py new -A55a -av1 -c8 -C4 -m22 -nworld-1 -s123456789 -o
```
+Use `Ctrl-C` to exit the simulator.
+
Upon exit, the simulation state will be automatically saved to
`${HOME}/.salis/world-1/`. As long as the contents of this directory are not
removed, you can reload the saved simulation with the following command:
@@ -60,7 +63,9 @@ user@host$ ./salis.py load -n world-1 -o
```
## Requirements
-- C compiler - ideally GCC
-- Python3
-- Jinja2 - installed globally or in an active virtual environment
+- C compiler
+- Python
+## Optional Dependencies
+- SQLite
+- Zlib