The Electron has long been considered the poor relative of the BBC - the little machine that might not ever match its big brother for expansivity or versatility.

To remedy this opinion, Acorn introduced the Plus 1, which allowed the Electron user to have joysticks attached to his machine. However, more far-reaching in its effect on the Electron owner was the fact that the Plus 1 allowed the use of printers and ROM cartridges. Acorn have now taken the next step and introduced the Plus 3. This is Acorn's offering to the more serious user, allowing a disc-based system to be set up for a reasonable price.

The first question that many will ask is: "What is the advantage of a disc system over a tape-based system?"

Well, the immediately noticeable difference is that access to information, be it programs or data, is much, much faster with disc than with tape. Many will say that ROMs provide fast access to software which is true, but there is still the question of user data which must be held on tape or disc. It's all very well being able to load the View ROM-based word processor in a half-second, but how much more convenient it is to load your letter to Auntie Maud, written using View, in two seconds from disc as opposed to a minute from tape.

The second big advantage that disc systems have over tape is that of data storage. It is true to say that if one were to use a C180, then a lot of data could be stored on any one tape. But the point that must be considered as well is that of access to that data. Discs allow non-sequential acess. This is the ability to store and retrieve data whenever it may be on the disc without worrying about the physical location on the disc.

This is just not possible on standard tapes, though a halfway house is such systems as the Hobbit or the Sinclair Microdrive, which are based on the concept of continuous loops of tape. But, whilst these do allow non-sequential retrieval from tape, they are comparatively slow. The Electron's new disc system allows the use of the very robust 3.5" discs which give 320K bytes of data storage (or 640K on double-sided discs). 320K is the equivalent of approximately 120 sides of A4 text on a disc.

When you get your brand new Plus 3 home, the box should contain some strange-looking objects. The first you'll notice is the Plus 3 itself, which is L-shaped and doesn't look like a disc drive at all. There's also a mains adapter, cable, one disc and the manual.

The L-shaped Plus 3 fits flush to the back and right-hand side of the Electron. Should you already have a Plus 1, then this must be disconnected and then refitted to the back of the Plus 3. (I presume that the Plus 2, which is rumoured to be some sort of networking system, will fit between the two.) For the fashion conscious amongst you, the Plus 3 is the same light cream colour as the Electron and the Plus 1.

The Plus 3 fits very firmly to the back of the machine using bolts to ensure no movement. With both expansions fitted the Electron now has the approximate dimensions of a BBC. The part of the Plus 3 at the back of the Electron contains the new wonder disc filing system, christened the ADFS, the Advanced Disc Filing System (what imagination!).

To the right of the keyboard is the disc-drive itself, extending the width of the apparatus by about another five inches. As mentioned previously, there is a new mains adaptor to be used, even bigger than the original Electron one. The old one must *not* be used with the Plus 3, otherwise untold damage may occur. However, worry not, for the old adapter will not go to waste since we are assured by the manual that it may be used with other units in the Electron range, the example given being an external disc drive.

There is no doubt that all-in-all the design of the expansions to the Plus 3 has been well thought out. I am impressed by the thought that has gone into designing a series of pieces of equipment which fit together snugly without the bother or inconvenience of trailing wires.

For many people, the interesting part of the newcomer to the Electron range must be the new disc filing system, the ADFS. Not only will the Electron user be intrigued by its performance, but also the intrepid BBC owner who, it is rumoured, is to benefit from this advance.

For those of you unfamiliar with filing systems they are very simple in concept. The idea is that there is a need for a "manager" of the operations to be performed on the information that is read from and written to disc. That manager is the disc filing system and it will look after such things as creation, updating and deletion of files (i.e. stores of information) on disc. More importantly to the home user, the disc filing system (or DFS) will provide a neat, user-friendly and generally hospitable interface to the physical business of keeping track of data and where it is kept on disc.

To begin with, let us look at how ADFS looks after files. One of the biggest criticism, and rightly so, of the Acorn DFS available for the BBC is that there is a low limit to the number of files that could be kept on a disc, irrespective of how much disc space was still unused! This unsavoury state of affairs has been changed with ADFS using a tree structure for files that is not uncommon amongst micros.

When a disc is formatted, what is called the root directory is created automatically. This directory (which is denoted by $) may be considered to be the patriarch of the family of files that exist on a disc. Any member of this directory must be a file. Now that file must be a program file (BASIC, assembler, machine code and so on), a data file (room descriptions of your mega-adventure, last month's excessive outgoings et al) or, joy of joys, another directory.

For the quicker amongst you this last item is of special interest. The ability to specify directories as being limit of information held on a disc is no longer the number of files held there, but the maximum amount of data that may be held on the disc itself. Of course, there is a drawback, and in this case it is that each directory may have only (?) 47 entries in it.

Each time that a file is created which belongs to a directory, the new file takes on the name of the directory, followed by a full-stop and then the new filename. So, if for example your currently selected directory (CSD) is $.BEN.PROGRAMS and you were to invent a file named CHESS, the name of that program would in fact be $.BEN.PROGRAMS.CHESS.

A couple of points to note before the knives come out about this slightly awkward file-naming convention. Firstly, this is a very common method of naming files and hence Acorn are not breaking new ground with it. Secondly, the long filenames will hardly ever be used as such since (using the example), if $.BEN.PROGRAMS is the CSD, the new program may be referred to as CHESS. It is essential though that the CSD is kept under very close control by the programmer otherwise confusion may arise by having the wrong directory as CSD.

There are several commands which have been included to deal with directories:

*DIR to select CSD

*BACK to revert to previous CSD

*CAT to list directory contents

*INFO to provide extra information about the directory

*CDIR to create a new directory

*TITLE to allow a directory a long meaningful name

*ACCESS to determine a directory's file access permissions

A concept worthy of special mention in this area is that of libraries. The ADFS supports the idea of a currently selected library (CSL) directory. This allows certain specialised commands used in running machine code programs. There are three ways in which a machine code program may be run: using *RUN [file], using */ [file] and by using *[file], as long as [file] is not one of the in-built file commands. The ADFS firstly searches the CSD for the file to be executed. If it does not find it, the next choice for searching is the CSL. If the file still cannot be found then the ADFS gives up and prints a "Bad command" message.

When ADFS is first entered, the CSD and the CSL are unset. However, *MOUNT will set the CSD to $, the root directory, leaving the CSL unset. However, by using CTRL-A-BREAK (which is the equivalent of CTRL-BREAK in a non-disc system), the CSD is set to $ or the first directory in $ which begins with "LIB". After this, it is always possible to change the CSL using the command *LIB.

Of course, there are many commands which are non-directory commands. After all, the point of having discs is to store data and programs, not to have a fancy directory system.

Many of the commands outlined here are also common to the cassette-filing system and, as such, those of you who have used cassettes should have little problem in adapting to these:

*SAVE save a section of memory or file to disc

*LOAD load a section of memory or file from disc

*RUN execute a machine-code program

*DELETE remove a file from disc

*DESTROY delete a group of files

*RENAME to give a file a new name

*COPY make a copy of file(s) in a different directory

Whilst by no means a complete list, the commands show that the basics of a good filing system are available. I found the use of these extremely easy and flexible. The only misgiving I had was that of forgetting which was the CSD. Admittedly, the information was quickly available by doing a *CAT, but even so I kept making mistakes.

When a user has got to grips with the ADFS (which I have only really begun to describe), he will wish to start to become more intricate in his approach to presenting his work to users of his programs. The first program that I decided to write was one to display a menu of the files available in the CSD. This would then allow the user to select an option which, if a directory, would display another menu and whether a program would execute it.

With the help of the manual and a few useful hints in some of their example programs, I was able to do this reasonably easily. But the inevitable happened and I decided to improve the program. I thought I would try and automatically enter the first user menu on start-up of the ADFS. This was when I was introduced to the idea of auto-boot files on the Electron with Plus 3.

When a disc is formatted, the "boot" option is set to "Off". However, it is possible to reset that option to either *LOAD, *RUN or *EXEC a file called $.!BOOT. The auto-boot is set into action by pressing SHIFT-BREAK, releasing BREAK and holding down SHIFT for a couple of seconds more. I can hear you asking how the user may control the effect of an auto-boot: the answer is very simple. By using a combination of *SPOOL and *EXEC the appropriate commands may be inserted into $.!BOOT.

With this information at my disposal I was then able to finish my program and now have a self-documenting, always up-to-date, menu-driven program selection utility.

Up until now I have spent time describing the file-orientated commands available from ADFS. There are also a set of commands that deal solely with the disc organisation itself.

There are a family of useful * commands which give information about the disc and its organisation. These are *FREE: telling how much space in sectors and in bytes has been used to date. *MAP: giving the starting sectors of free space and their lengths and *COMPACT which may be used to concatenate the free space on disc which has been fragmented over time by continually changing the sizes of files.

Further to these is the command *MOUNT (and the opposite *DISMOUNT) which tells the ADFS to get relevant information on the disc currently in the drive so that subsequent commands may be performed on the data therein.

Much of what has been described above is of use for the manipulation of files and discs, no account having been taken of he who wishes to use discs from within BASIC. The good news is that virtually all the commands used from BASIC when the cassette filing system is active are the same for when the ADFS is active. The bad news is that you "don't get 'owt for nowt". Whilst PAGE is set to &E00 for the cassette filing system, it is set to &1D00 for discs, hence there are 3840 fewer bytes available for use. The manual tries to lessen the blow by hinting at possible techniques such as overlaying that because of their speed may be used with discs, but this detraction from memory is still a pain.

The commands available from BASIC follow the format of their * equivalents, but without the *. Hence LOAD is the programming equivalent of *LOAD and SAVE is the equivalent of *SAVE. As well as these, there is the very convenient CHAIN, which is the same as LOAD followed by RUN.

The filing system ADFS supports what are known as sequential files. These are basically the same sorts of file as held on tape, but the access to them is that much faster on disc. This, if it were all that the ADFS supported in the way of data files, would be very disappointing. However, ADFS saves itself in the nick of time by allowing the concept of a pointer within the file. This allows the use of "direct" or "random" access file handling.

Let us consider the situation where a file, fred, is being written to. When opened using OPENOUT"fred" the value of PTR fred is set to zero. For each byte that is written to fred, PTR fred is incremented by 1. This means that since PTR fred is also used to decide where to read from in fred, the user may control his travels around the file by the appropriate setting of the pointer. Whilst this feature is not the most sophisticated of file handling techniques, it is one which opens up a world of "random" accessing to the user's data files.

The commands which are available to the BASIC programmer which affect these files are OPENIN, which opens a file to be read only, OPENOUT, which opens a file to be written to only, OPENUP, which allows a file to be both read and written to, PTR, which has been mentioned and EXTENT, which is in effect the length of the file.

Amongst the bits and pieces that come with the Plus 3 is the Welcome disc. This disc contains a set of demonstration programs and a set of utilities. For those of you who know the wonderful Island and Planets graphic demonstrations from the introductory cassette with the Electron, don't miss out on the same visions of splendour - but in about three seconds flat!

For the more serious users there are a set of utility programs available. The user is introduced to these through a menu and Acorn have been considerate enough to set up a parallel Help menu. This means that should you fall into a problem in trying to use the options from the Utilities menu, help is close at hand without having to search through the user manual.

The utilities that come on the disc are quite extensive. The most important one present is the formatting utility, which of course must be used on every new disc before it is used to store any files of any sort. This sets up all the necessary information on the disc to ensure that when it is accessed, the ADFS knows all that it needs to know about the disc. Amongst the other utilities present are VERIFY, BACKUP and DUMP which perform the obvious on files. Also present are LIST, which displays a text file with line numbers, TYPE, the same as LIST, without line numbers, BUILD, which creates text files from the keyboard and last, but certainly not least, UTILS which produces the menu of utilities.

All of these utilities are in the $.LIBRARY directory and so when this is set up as the CSL they may be accessed by a simple * utility command. Hence to call up the menu, *UTILS is all that is necessary.

The documentation that comes with the Plus 3 is in the form of a 111 page manual or user guide. This user guide is split into some nine chapters and two appendices, as well as the useful index (well done Acorn, you didn't forget this time!).

The first chapters give a gentle lead into the concepts of discs, their maintenance, their method of use and the way that information in the form of files may be stored upon them. The meat of the manual is the five chapters which include the definition and use of the commands described within this article, as well as others that have not been mentioned.

An interesting chapter is the one on filing system entry points, which covers the use of OSFIND, OSGBPB, OSPUT, OSBGET, OSARGS, OSFILE, OSWORD, OSBYTE and OSCLI. Whilst these are not covered in enormous depth, there are examples given which show the way to use them and hence lead the programmer into the world of the operating system. It is this chapter that I found most useful for the menu program that I mentioned above.

I read most of the user guide before I played around very much with the Plus 3. Perhaps this was a mistake, but I found that certain ideas were introduced without explanation at too early a stage. For example, CSDs were mentioned before they were defined! This made for a whole lot of confusion. But even taking this into account, I must say that the documentation was to a good standard. It was usually clear and certainly concise. Importantly, there were many examples, which are essential to describe new concepts to novices. But then we expect good manuals and guides from Acorn; much of their market is to schools.

I have had this review version of the Plus 3 for some five weeks now and consider to have given it a good going over. Over this time, I have used the drive extensively in conjunction with the Plus 1 and the View word processor as well as for general program development.

The drive has worked superbly. I have not had any failures with it and, whilst I know that drives are supposed to last for more than five weeks, I have had no inkling of any problems. The dreaded fate of losing data to corrupt discs has not happened and this is even though I have accidentally taken a disc out whilst the drive light was still on! Not recommended.

By comparison with drives that I have used on other machines, the Plus 3 stands up well. A 15K text file, set up using View, takes some three or four seconds to load and if you're used to cassettes, that is fantastic.

I do have two slight misgivings about "features" of the disc set up using the ADFS. The first is that if any disc accesses are made whilst in Modes 0-3, then flashing of the screen takes place. The reason for this is that for the Electron to keep pace with the fast speeds that the disc drive uses, the machine must temporarily not refresh the screen image! This happens in the 16MHz modes (namely modes 0-3) because you probably already know these are the "slow" modes on the Electron.

The second misgiving is that interrupts are disabled whilst access is being made to disc. The net result of this is that the keyboard is disabled (except for Break) and that the pseudo-variable TIME stops. I had problems with the disabling of the keyboard when I regularly found the first depression of a key did not register after I had performed some disc operation. Maybe I was a little quick sometimes, but I'm certainly no touch typist.

The Electron has finally come of age. Whether the Electron and the Plus 3 together are a success will depend very much on Acorn themselves. There is a rumour that there is a double-sided version of the Plus 3 around. This review is based on the single-sided version. To date, Acornsoft themselves have only produced one disc, and that is a collection of three games. The arrival of Database is imminent.

The Plus 3 itself is a competent, solid piece of engineering which both looks good and works well. The combination of an Electron, a Plus 1 and a Plus 3 will now cost approximately £400 and I defy someone to find a combination of such quality for such a price. Add to this a monochrome VDU, a printer, View, Viewsheet and Database from Acornsoft and for a grand total of about £850 there is an excellent disc-based small business set-up.