The final article from Bernard Hill on using sideways RAM software provides some useful utilities, including the ability to rename any sideways ROM command and avoid all those command-name conflicts.

In the first article of this series (Vol. 5 No. 2) we looked at the way in which a sideways ROM responds to service calls (in particular the *HELP service call - number 9) and produced some useful initialisation routines based on service call 1. Last month's article contained a complete * command parsing routine and illustrated this with * commands to drive a printer in its special effect modes. This month we expand the collection of * commands with some utilities.

These can be incorporated into your growing sideways RAM utility by merging the 1listing here with those of the previous two months. As with the code given last month, the ROM sections are completely independent, so you can omit or include whatever you wish. The only restriction is that you must place the calls to the two procedures somewhere between PROCromhead and PROCendrom.

The first routine, PROCutils, gives two fairly standard utilities: a function key lister and a ROM lister. The commands to call these utilities may be changed by altering the parameters of PROCutils. The function key lister is very standard, but the ROM lister has a feature not often seen elsewhere: the ability to distinguish between 8K and 16K ROMs.

The second routine, PROCredirect, needs more introduction. ROM clashes are a sad fact of life on the Beeb. Despite the Beebug convention of an optional prefix to distinguish the commands from ROMs of different companies, I always seem to have ROMs in my machine whose commands are 'hidden' by other ROMs. For example *EDIT is a command to which at least three ROMs respond - Disc Doctor, Toolkit Plus and Watford DFS.

This very easily customised routine enables you to rename those annoying commands. Now you can call View with *VIEW, or address your ROMs directly with a single command without worrying about their priorities at all.

As with the procedures in the previous articles, the one parameter is the line number of the first DATA statement of the redirection data. Each data item consists of an old command (e.g. the EDIT of *EDIT), the new command you want to use (e.g. *SHOW) and the name of the ROM which you want to respond to this (e.g. DISC DOCTOR) . As long as you get the beginning of the ROM name correct and unambiguous then that will do, but be sure you have the correct case and spacing (e.g. for 'DISC DOCTOR', 'DI' would do, but 'Disc' would not). Consult the output of the ROMlist utility above if you don't know the exact name of any of your ROMs. Should you shuffle the ROMs in your machine then these routines will still work, but if you remove a ROM or mis-spell its name in the DATA statement then an error message is issued when you attempt to use it.

The command works by jumping directly into the relevant ROM, using JSR &8003. However, since you cannot jump into a ROM directly from another ROM, it is necessary to jump first into an area of normal memory. This means we must find a 'safe' area of normal memory, into which our ROM will put 20 bytes of code. The replacement command line also needs to be set up, which involves another free area to receive the reconfigured command (e.g. '*EDIT 10000').

Many areas are possible but be careful that any of the ROMs responding don't use this area for the command you want to process or the system may hang after the command has been executed. In the listing I've chosen the Tape Filing System BGET/BPUT workspace (&380-&3DF) but if you are likely to need to use this while the command is being executed (e.g. Toolkit Plus's *CHECK or MERGE) then you will need to choose some other area. Consider part of pages 6 or 7 (Basic use only), or 9, &A or &D. Simply change the variables 'target' and 'command' in line 20010.

You will have noticed that the program built up in these three articles is highly modular so that you can mix-and-match sections to suit yourself. Writers of other routines may care to conform to this format in order to share their work and ideas with other members through these pages.

Each section of code is contained in a single procedure which generates code to perform a specific action. Entry to the code is from the top and exit from the bottom (i.e. data bytes must be embedded and jumped over) so that the next procedure's code can start executing immediately. The entry will be with A, X, Y and the stack set up exactly as on entry to the ROM. Exit should be just the same, with any scratch space or memory areas used (e.g. &F2-3) completely restored and the stack intact so that the next section of code generated can behave as though it were the first on entry to the ROM.

The one exception to this may be if the ROM needs to signal back to the system that it wants to block all other ROMs (and routines) from having their go. In this case restore the stack, reload X and Y, then put 0 in A and RTS. Remember that 99% of the service calls passing through your ROM will not be for you and ignoring these simple rules can easily lead to a hung machine.

If you wish to use the command parser introduced last month (PROCcommandhandler) then organise your code along the models of this month and last month's utilities, with the parameter to PROCcommandhandler being the address of the command table (as explained last month). If you exit your code without executing a command then the procedure will handle this for you (it exits at the bottom), but if you do execute a command then be sure to put:

PLA:TAY:PLA:TAX:PLA:STA &A8:LDA#0:RTS

to finish securely.

We welcome the submission of further short routines for sideways ROM and RAM compatible with the format developed in these articles.