PhiLiZound Software
Index   Berty   Demos   Versions
Page updated: 1-Sep-2010

Berty Details

Extracts from Online Help...

Basic Operation

The 'brain' comprises a 3D grid defined by the BS (brain size) command. Each grid location is defined by X,Y,Z coordinates and can hold a 'cell', which is a very simple model of a neuron.

Each cell has an unlimited number of input & output connections (subject to memory), a threshold value and a firing state. Cells can be connected to any other cell in the network, and each connection can be either excitory or inhibitory. A cell will 'fire' if the sum of excitory inputs (from other firing cells) minus the sum of inhibitory inputs (from other firing cells) equals or exceeds the cell's threshold value.

You can define cells (AC - add cell command) and connections (CC - connect cell) as required, switch the simulator to 'online' mode, then press 'r' to run.

Viewports are 2D slices of variable size which can be centred on any X,Y,Z brain coordinate, scrolled up/down, left/right, in/out, and zoomed. Firing and non-firing cells are represented by different coloured blobs within these viewports.

Stimulus keys can be pressed in online mode and will 'stimulate' (i.e. fire) defined ranges of cells.

Eeg traces are derived from 3D rectangular volumes whose diagonally opposite corners are defined by a pair of X,Y,Z coords. The volume can be as small as a single cell, or as large as the whole brain. The trace shows the ratio of firing cells to non-firing cells within the volume range.

Growth Algorithms

The original design aim was to use the simulator as a vehicle for developing 'growth' algorithms for the neurons. Rather than laboriously define a large network of cells, the idea was to start with a single cell and let it grow while the simulation was running. This is why there is a concept of a 3D volume space in which cells can have physical as well as logical neighbours.

Performance

The two main design requirements were speed and brain size, so the program is written in machine code and uses all available extended memory.

There is a compromise between simulation speed, and seeing as much activity as possible in case something 'interesting' happens. The slowest routines are the viewport displays; you can reduce these in size and/or number, zoom in, or even delete them. Alternatively you can reduce the number of viewport 'updates' by varying the cycles-per-display value. Similar options exist for the eeg traces.