Everybody is talking about Acorn Computers Ltd, most of the interest being focussed on the BBC's choice of Acorn to supply a machine around which to base its first consumer computer series. This has generated a wide range of comment in the press, particularly in connection with the exxentricity of Acorn's Basic dialect. The second interesting event has been the announcement of Econet, which appears to offer multi-user computing at an incredible and unprecedented low cost.

The idea behind this network scheme isn't new - you start with a small, cheap, standalone microcomputer and arrange for several of these to be linked to something which lets them access a common disk system, a printer or any other expensive or esoteric peripheral which it may require occasionally but not continuously. In this way a collection of PETs can be clustered by means of the Mupet, Apples by means of Nestar and Acorn Atoms by means of Econet. Of these, the last is the cheapest, British and the subject of this month's Benchtest.

An Econet system consists of three elements - the nodes (or 'stations') which comprise two or more micro-computers, each with a processor, some memory and possibly peripheral devices; the network cable which carries the information between nodes; and the Econet interface card, one of which must be installed in each active node. The review system comprised four fully configured Atoms (cf. Atom Technical Data, for a brief sketch - or Mike Dennis in PCW, July 1980 for a full review); one Acorn System Three (a 6502-based machine built on the Acorn Eurocard bus and featuring a single mini-floppy drive); a Seikosha printer and a number of lengths of four-way cable with standard five-pin din connectors. This is by no means the maximal network - the current Econet will support some 255 stations while a future version is planned to cater for 64K nodes organised as a hierarchy of up to 255 local networks, each comprising up to 255 stations.

Each station has a unique address which is hard-wired into the interface card. Stations number 255 and 235 are respectively designated the File Station and the Print Station. This is because if these facilities are required on the network (and it is reasonable to expect that they would be) then each of the micro-computers located at these nodes must be dedicated to the running of a program called the File Server and the Print Server respectively. On the review machine, for example, the File Station uses the Acorn System Three with its floppy disk but the printer was attached to one of the Atoms which had, consequently, to be sacrificed (as a user station) every time a print-out was required. The next revision of the network software (to be apparently written in machine code, rather than in Basic as is the current one) is expected to offer sufficient flexibility to allow several File and/or Print stations on the same network. However, there are no plans to combine these two functions into a single node (an obvious saving), nor to offer hard-disk facilities.

The Econet interface card comes in two versions: one for the Atom, plugging into the top (i.e. wrong) side of the PCB - a thin strip of board right above the keyboard; the other for the Acorn (Systems Two, Three, Four or Five) - a Eurocard which slots directly into the Acorn bus. Both require a 4K machine code program starting at A000H and, at least in the case of the Atom, is stored in ROM. The Econet software is boot-strapped into the local processor on power-up or when BREAK is pressed.

In the design of a network, it is necessary to define how the information to be transmitted on the network is to be made up (often called the 'packet'); how it is to be transmitted and how all the traffic on the network is to be regulated. On the Econet, much of this work is handled by the Motorola MC 6582 ADLC (Advanced Data Link Controller) which is housed on every interface card. When one station wants to send a message to another, its Econet software will structure the body of the message into one or more packets which are passed onto the ADLC. Each packet contains source and destination identification codes (one byte each), a one-byte 'port-number' which serves to identify the nature of the message (e.g. a command or a piece of data, etc) and the information itself. The ADLC then constructs a 'bit-frame' which contains the packet suitably converted into a serial data-stream, enclosed by start and stop bytes (otherwise known as open and close flags) and a 16-bit CRC (cyclic redundancy check) - see diagram. Obviously, on reception of such a bit frame from the network the ADLC will strip off the extra bits and reformat the messages as parallel data which it puts on the local processor's bus.

Before it can transmit a packet, it is necessary for the ADLC to determine the state of activity on the network. An idle state will be seen by the ADLC as a stream of logic 1s (at least 15 bits long) whereas in a busy state (i.e. another ADLC transmitting somewhere) logic 0s will have been inserted into the bit stream (Zero Bit Insertion). Thus, each ADLC can 'listen' to the network and will only transmit when the network is free.

However, this does not deal with the 'collision' problem, when two ADLCs hear nothing on the network and begin transmitting simultaneously. Should this occur, the information actually on the network becomes corrupted, a circumstance detected by both transmitting stations which listen to their own transmission. These will then back off until the network is clear again. In order to prevent this from happening over and over again, each station generates a unique 'arbitration code'. As soon as the colliding stations have backed off, they rotate their arbitration codes and interrogate the top bit. Depending on its value, they either return to listening or try to retransmit. Since the two arbitration codes are different, eventually one will get the opportunity to transmit without interference.

In fact, each arbitration code is made up of eight 1s and eight 0s, so that any station has a 50:50 chance of going first following any collision. This is also probably necessary to conserve uniqueness under rotation - it will be interesting to see how Acorn copes with arbitrating among its proposed 64K stations. Assuming that a station manages a successful transmission, it first sends a 'scout' message (the first few bytes of the packet) and only transmits the remainder when the receiving station has acknowledged and indicated its willingness or ability to receive the frame. During the entire transaction, the two participating stations have complete control of the network and any other station wanting to transmit would find the network in a busy state.

Physically, the network cable consists of two twisted pairs - one for data transmission and the other for clock signals (in both directions). For short networks, shielding is not necessary, although it is recommended for longer rungs. Any configuration is possible (provided there are no loops), although a straight-line hook-up is recommended for larger networks since the signal deteriorates over spurs and branches. Branch connectors are such that the electrical continuity of the network is not dependent on whether or not any individual node is switched on. (Incidentally, neither the Acorn nor the Atom appear to have on/off switches anywhere on the casing.)

The clock signals are generated by one station, designated the 'master-station'. (Jumpers exist to configure any Econet interface card to perform this function.) These are used to synchronise data transfer. The clock frequency recommended by Acorn depends on the size of the network. The review system was rated at 250 kHz which would have been good up to 300m. For networks up to 1.7km (sounds suspiciously close to a mile), 107 kHz was recommended.

Taking of recommendations, Chris Curry of Acorn Computers felt that a typical Econet configuration will probably consist of as many Atoms as required (fully expanded) and probably an Acorn System Five as the File Station. This has two (Tandem) double-tracked, double sided minifloppies (800 kbytes disk storage) and probably 24K of RAM. Since this is the top-of-the-line in file servers, this works out a bit more expensive than the Econet might appear at first sight.

There are several different parts to the software available on the Econet. Firstly, there is the Econet interface program installed in 4K of ROM in each station. This features the network operating system (NOS) together with its low-level primitives. The latter consist of six routines used in the construction of the high-level NOS commands (see later) and are available to programmers at assembler language level. TRANSMIT and RECEIVE are the lowest level and have obvious functions, while PEEK and POKE have their normal meanings, except they act on another user's memory (this network is the ideal environment for the programmer who is also a busybody!). RESET and START are even worse - RESET tells a distant station to stop what it is doing and wait for a START instruction (so that its memory can be examined/altered in peace), while START itself passes a memory address to the waiting station and causes it to begin execution there.

The high-level commands under NOS can be used in immediate mode or embedded in Basic programs. Some are inherited from Acorn's Cassette and Disk Operating Systems (COS and DOS respectively). These are *SAVE; *LOAD; *CAT(alogue) and *DELETE. The * serves to designate these as NOS commands rather than commands to the resident Basic system (e.g. LIST, RUN, etc). Other commands deal with specific network functions so that *VIEW n provides the user with a snap-shot of station n's screen.

Continuous 'viewing' can be achieved by:

10 *VIEW 3 (for instance)

20 GOTO 10 RUN

However, this viewing can never be entirely surreptitious, since the victim's screen 'snows' slightly during each snapshot and the continuous interruptions slow down processing discernably.

Similarly, the command *REMOTE n will allow the user of a local station (not n) to take over station n (the remote station) entirely. Commands typed into the local keyboard will appear on both screens but will only be obeyed by the remote processor. On the other hand, the remote keyboard is disabled (except for BREAK). So this is what you can do - type *REMOTE 3 (say) and take over station 3. You can load a program into memory, begin execution and the memory on your system will be unaffected. Meanwhile, the user at station 3 just sits helplessly watching.

Unfortunately, when graphics mode is used, the signal does not get back to the local screen. Since *VIEW can transfer graphics signals across the network, we assume this is a bug in *REMOTE. While in remote mode, the remote station can be reset by typing 0 and remote mode itself can be disabled by the command *ROFF. The documentation mentions a further command, *NOTIFY n, which is intended to send a message to the screen of station n (or broadcast to all stations if n=0) - but we couldn't get it to work.

Finally, the printer station is accessed from another station by typing ^B (must be followed by DELETE due to a bug in the current software) and disabled by ^C. The effect is the same as ^P under CP/M in that anything appearing on the screen will be reproduced at the printer. That completes the range of commands recognised by the NOS. They are simple to use and appear to be reasonably efficient, if a little limited. The network error messages are clear and worth mentioning:

The second part of the network software consists of the peripheral utilities. These are called 'servers', so there is a 'file server' and a 'print server'. Both of these programs have to be executed on the processors at the relevant stations before the network is ready for use. The file server must run at station 255. Every time a file is referenced by another station (i.e. SAVEd or LOADed) an entry is made on the file server screen. This consists of the name of the file and other information like its location on the diskette, etc. When the file server is booted in, every station on the network is made known to the file server by a program known as BOOT. A 'qualifier' can be associated with each station - presumably this will be used in future versions to define the status or privilege of users on that station, insofar as this status affects access to disk-files. Likewise, the literature mentions a number of commands covering file operations (including random access), directory operations, and disk operations, including defining and altering public and private access rights. Our file server, however, could only LOAD and SAVE Basic programs or *LOAD and *SAVE small (less than 20 kbytes) chunks of memory. The file server runs on an Acorn System 3, 4 or 5.

The print server on the other hand runs on an ordinary Atom to which a printer is attached at station number 235. When another station types ^B at command level (or $2 in a Basic PRINT statement), it gets control of the printer station until ^C (or $3 in a Basic PRINT statement) is typed or until there is no transmission for several seconds, after which the print server will disengage itself and type 'TIME OUT' on both the printer and the attached station. Should any other station try to get the printer while it is engaged, a 'BUSY' message will be received, and the user will have to try again later.

The third software element includes user utilities and language translators. At the moment all that is offered in this department is Acorn's Basic with Assembler which is supplied in ROM on all Atom stations and on disk in the file station. For those readers who cannot remember Mike Dennis's fairly extensive coverage of this dialect, here is a list of the more idiosyncratic highlights, both good and bad points:

1. 32-bit precision integers named A, B... X, Y, Z (i.e. only 27 allowed).
2. Floating point variables and strings designated by non-alphanumeric prefixes (e.g. $ for strings, etc). Arrays reference by double character variable names (e.g. AA).
3. The prefix '?' has the effect of a PEEK or a POKE depending on the context.
4. The PRINT statement does not automatically append a [CR] - this must be done explicitly.
5. The construct DO [statement] UNTIL [condition] is supported.
6. The command LINK can be used to enable the incorporation of assembler mnemonics directly into the Basic source. (This is how the NOS primitives can be utilised in programs.)

Finally, under NOS it is not at present possible to create or access data files except as chunks of memory referenced by starting address and length.

While we had the Econet, we had the opportunity to preview Acorn's new Pascal. This has not yet been released and is currently missing some features which it will need before it can be regarded as fully vialble. We received a letter from its creator Paul Farrel telling us as much and asking us not to Benchmark it as all the debugging statements were still in. A fuller description of the language itself will be given in a future article but we cannot resist publishing our Benchmarks (floating point tests excluded - not yet implemented); they make quite interesting reading when compared to other 6502 Pascals.

A Pascal compiler would be a very definite boon to the Econet system, but the snag seems to be that part of the compiler's address space overlaps the Econet interface program's space so with the current design this can never be. Perhaps future configurations will support a disk-resident relocatable Pascal which can be downloaded onto individual stations.

In conclusion, we found that the Econet seemed to have very promising potential as the basis of a low-cost network but feel that interested readers should wait until the following enhancements and extensions (some under development or mentioned in the specification, some not) have been implemented and proved satisfactory, before committing themselves to the Econet.

For the NOS:

1. Some means of restricting availability of powerful network commands to 'privileged' stations;
2. Wider range of high level commands providing easier access to NOS primitives;
3. Provision for more than one file or printer station on the system and amalgamation of file and print stations;
4. Pascal.

For the File Server:

1. A simple yet robust security system for user files;
2. Provision for data-file manipulation within programs;
3. Provision for hard-disk or other massive file-store.

For the Print Server:

Implementation of a spooling system whereby output from different users is temporarily stored on a disk and queued to the printer when it becomes free.

The multi-user Benchmarks take on a different shape when run on a network. For instance, the test designed to tie up a single processor will not show any effects when each user has a processor. On the other hand the file accessing tests are crucial and here, unfortunately, we were not able to test as fully as we would have liked. There are two disk tests, each designed to transfer 100 128-byte records to and from the disk. In the first test, the file should be opened and closed before and after each write and read, while in the second test the file is opened for 100 writes, then closed, then opened for 100 reads before finally being closed again.

Since the Econet would not allow data files to be accessed from within a program we had to be content with transferring chunks of memory onto the disk and retrieving them. Since each such transfer involves opening and closing a file we took this activity to be roughly equivalent to the first of the tests described above (i.e. the 'short record' disk test). For the second test, we would have liked to transfer 12,800 bytes in one go, but this proved too much for the file server so we were reduced to transferring 1280 bytes ten times. This gave reductions in timing of the order of one quarter, so, extrapolating, one could expect improvements of a factor of one quarter again for the full disk test. However, there will have to be considerable changes in the software before these tests can be run properly.

Finally, as promised, the Atom Pascal Benchmark figures:

Acorn bills the Econet as a 'low-cost local computer networking system for schools, business and laboratories'. Firstly, let it be said that the system certainly is low-cost but, owing to the unbundling (literally) of chunks of essential hardware, it is not as low-cost as it might seem. For instance, you've probably seen the Atom advertised at £120, but you've still got to get hold of a (separate) power supply and monitor (total price £142) before you could get it up and running. Or you could make do with a domestic television.

Bearing this in mind, each station on the Econet therefore consists of three boxes (computer with keyboard, monitor, power supply) plus inter-connecting wiring, plus network cable - so anyone planning an installation should consider building in this wiring (and installing on/off switches nearby).

Despite this, on a cost per machine basis, the Econet appears to be an attractive proposition for schools - this view has been endorsed by the DOI. Schools need to provide systems for pupils to learn programming on and to run CAL software on. For the former, an Econet system could be a slightly dubious solution. Firstly, a multi-user system in a school environment must be reasonably secure, and the File Server available for review purposes offered no security.

The thought of 20 pupils each on their own machine but each with the capability of deleting and altering everyone else's files and memory, as well as the ability to disable keyboards at will, would deter all teachers save those who take particular delight in anarchic chaos (or strict disciplinarians.)

In fairness, however, Acorn has promised a more secure system. Secondly, there is only a very limited choice of languages available on Econet stations. A strange dialect of Basic and Assembler may not be everyone's idea of the ideal teaching machine. (The Pascal and Econet software occupy the same address space, so cannot be used together.)

Finally, the Atom in particular (that is, the 'cheap' solution) has space in its case for a maximum of 12K and this may not be sufficient for A-level pupils to write their projects on. Besides its price, in its favour are the 250 x 192 resolution graphics, sound and interfacing capabilities useful for CAL and other computer applications. However, there is a dearth of quality software around to exploit these capabilities.

It is hard to see the Econet, as it stands, fitting into a business environment, where there is a need for robust hardware (and lots of it - e.g. hard disks), robust software (and lots of it, such as ledgers, financial planning packages, databases, word processing stuff) and good file security. However, Chris Curry did mention that independent micro firms were developing software to connect several major micros into the Econet (Apple, PET, Research Machines 380Z) which may carry the type of software which business users expect to have. However, there is some doubt that CP/M will perform quickly enough to satisfy the Econet's protocol.

The laboratory user is probably Acorn's longest established type of customer and it is probably in the labs that the Econet will fit with the least trouble. The Acorn systems provide a wide range of extremely useful cards and even the Atom comes with a Versatile Interface Adaptor option. Also, laboratories are accustomed to having cables and connectors leading hither and thither and a cheap, easy-to-use network could prove an excellent and efficient way of collecting, manipulating and storing lab data. The Basic, although eccentric for teaching programming, seems well-suited to lab applications.

The (prototype) Econet system which we reviewed was supplied with a spiral-bound 'Atomic Theory and Practice' covering Basic and Assembler for the Atom, together with several typescripts including 'Econet Version I - User Manual'; 'Acorn (Econet) Technical Manual'; 'Acorn DOS Manual' and a long document entitled 'Atomic Network Operation' which appeared to be some sort of promotional specification for the Econet.

Of these 'Atomic Theory and Practice' was the only document in its final form and, as a microcomputer user document, is of a reasonably high standard. It is 212 pages long, is paginated, includes a table of contents and succeeds in being entertaining and informative with numerous examples. Apart from the DOS manual, the other documents appear to be preliminary versions of different ages and variable accuracy, generated during the Econet project, and describing features, some of which do not yet exist.

No doubt they will become more accurate as they are prepared for final publication but the overall impression is again of reasonably well-written clear descriptions of features and of technical specifications, complete with circuit diagrams. The style of these, however, is not a tutorial nature, in contrast with 'Atomic Theory'.

The minimum Econet consists of two linked Acorn System Twos each with a few K of memory, an Econet interface and only machine code capabilities; one with a cassette for backing store. Currently the maximum an Econet can contain is 255 Acorn System Fives each with 64K memory and two double-sided double tracked mini-floppy drives (no file server), along with a wide assortment of interface cards. The Acorn sales literature promises even larger systems with up to 64K stations connected on subnetworks, all talking to each other and to other computers on the much faster Cambridge Ring.

If there are hardware limitations on an Econet, it isn't with the number of stations one can attach to it but with the size of each station. Larger and faster (Winchester?) disks are needed for a network of any size. On the software side, Acorn offers a fairly limited choice of options for future expansion and extensions to its sparse catalogue of system software would not go unappreciated.

As there is a wide range of products that can appear in an Econet configuration, the list below is a sample of the more commonly purchased products. These prices exclude VAT.