With many extension boards groaning under their burden of ROMs it was inevitable that someone would produce one more to help organise the others - hence ROM Manager. It responds to 18 commands, of which no less than eight are concerned directly or indirectly with passing ROM commands. Of these, *DIRECT and *VECTOR are two names for the same operation, namely passing a command to a specified ROM. The reason given for the duplication is that it doubles the odds against some future ROM beating the system by using one of these names. *FILE effectively does the same thing as *DIRECT and * VECTOR, but addresses only "external" (i.e. ROM-based) filing systems such as the DFS or NFS. If a RAM-based ROM filing system (see below) is in use, then *RAM replaces *FILE.

*DEFAULT is used in conjunction with *SPECIFY - the latter designates a ROM to which subsequent commands _ will be passed directly by *DEFAULT. Confused? - you won't be when you discover that whereas

*DIRECT can address only one ROM, *DEFAULT will also try (if necessary) all ROMs of lower priority than the one designated by *SPECIFY. The latter does not survive even a soft BREAK, and must be redefined after it.

The last two are *STOP and *START, which disable and enable a specified ROM, respectively, so that it will be ignored (or not) by the operating system. All these commands (except *SPECIFY) hold good only for the current operation. I have to admit that I would gladly have settled for just three - *START, *STOP and *DIRECT, having found the remainder rather a bother, especially when forgetting to reallocate %*SPECIFY after a BREAK resulted in an error. It is also unfortunate that *D. is recognised as DIRECT, *DIS. becoming the minimum abbreviation for disc selection. Minimum abbreviations for ROMs should be longer than comparable OS commands, and preferably not less than three characters.

*CHECKSUM finds the cyclic redundancy checksum for a named ROM. The result is unique for practical purposes, and any change with time indicates trouble, though this is very rare except through physical ill-treatment. *EXAMINE lets you read the contents of any ROM, including BASIC. It is in standard HEX and ASCII format, and the cursor can be wound down to the bottom of the screen to scroll the data upwards, and vice versa.

The cursor also moves sideways between the two formats (using TAB), but you can't actually do anything with it. *NAMES lists all ROMs present, revealing their names, socket numbers, and whether they are active or disabled.

Several commands produce miscellaneous information. *VALUES tells you which socket ROM Manager is in, how many ROMs are active with higher priority, the name of the current filing system, whether the DEFAULT option is active (and if so the defalt socket number), and whether any RAM-based ROM is in use (and if so the service entry address). Further information is available from *STATUS - namely the ROM socket number, its title and copyright message, its nominal length (ie 8K or 16K), whether it has language and/or service entries and whether it is active or not. If you have forgotten your FX calls (and are too lazy to look in the UG) *EXPLAINFX gives a brief rundown on the first twenty-two, and *EXPLAINFX n gives more details about_*FXn (n=<22). Finally, *FUNCTION merely follows a long line of utilities in listing the contents of any one or all of the soft keys for possible editing.

If you are thinking of putting some of your own programs into ROM it is useful to be able to get them running properly in the correct format before actually blowing an EPROM. *INCLUDE lets you use the Beeb's RAM for this. Your program can be assembled anywhere within the normal RAM area, and it will be included in the ROM list until you issue *REMOVE or press BREAK. Your routine must conform with the RM protocol given in Chapter 15 of the Advanced User Guide.

When finalised the routine can be moved to the appropriate location (generally starting at &3000 or thereabouts) ready to be blown into an EPROM. Absolute addresses must be changed appropriately, of course. This, and other editing, can be done using *MODIFY - a standard memory editor. It displays 128 bytes at a time in the usual format, and the cursor moves as in *EXAMINE, but this time amendments may be made in either Hex or ASCII. The single-speed scrolling is slow, but you can always ESCAPE and call for a new start address.

It is ironic that the actual 'management' part of ROM Manager's functions would be unnecessary if all suppliers of ROMs supported the simple and sensible convention agreed (and used) by Beebug and Computer Concepts, whereby an optional 'house' letter can be added to the front of any command name to avoid clashes unambiguously (it is up to every supplier to avoid duplication among his own products). Where it does become necessary to route commands to particular ROMS it is easier to do with ROM Manager than by disabling an interfering ROM by poking its page two flag directly. Users will also find some or all of the general utilities handy.

Perhaps the most useful feature is the ability to develop programs in the Beeb's RAM which will subsequently be put into EPROMs. The manual eschews any example, referring readers to an Acorn Application Note or the Advanced User Guide. Unfortunately, ROM programming is not the easiest exercise for the beginner.