Declaration

I, T F Letocha, hereby release ZROM and its documentation to AMPLINEX and its registered members for their personal, non-profit making use, free of charge. I prohibit the use of ZROM and its documentation in any form whatsoever by any third party for any purpose whatsoever. The penalty to any such third party for the use of ZROM and its documentation for any purpose whatsoever without my prior written consent will be 50 pounds (Sterling) or 20% of any profits made using ZROM and its documentation, whichever is greater. I hereby declare that I retain all rights (including copyright) over ZROM and its documentation.

Disclaimer

While every effort has been taken to make ZROM and its documentation both useful and error-free, the author takes no responsibility for any loss or damage arising as a result of the use of ZROM and its documentation.

Introduction

What annoys you about instrument definitions in AMPLE? Is it the fact that to be of most use they are best kept as *EXEC files? Or is it that you can only get 31 of them on a standard DFS disc with no room for anything else (even though the disc is more than 90% empty)? It might even be the fact that it's difficult to remember where you saved that particularly good-sounding instrument?

With me, it was all of these and more. Wouldn't it be nice if I could somehow group together my instrument definitions in a single file - a library? Perhaps have different libraries for instruments belonging to my MIDI-controlled drum machine and my Casio keyboard? What about grouping instruments from many libraries into a library of ensembles, or bands? What about building up a library of percussion parts? Now what did that instrument definition look like? Just think - having libraries saved on different discs and not having to worry about where?

Imagine a utility to do all of this - then imagine ZROM!

ZROM lets you collect all of your EXEC-type files together as separate modules into one file which you can then use as a library. ZROM lets you call up any of the modules in the library and EXEC it automatically - with minimum effort from you. What's more, with ZROM you can have many libraries containing many different types of module spread over one or more disc sides all at your immediate disposal.

Installing ZROM

ZROM has been produced as a sideways ROM image so you can install and use it in two ways:

1 - As a sideways ROM

To use ZROM this way, just use the file supplied called ZROM19 to program a 4, 8 or 16 K EPROM. Then install the EPROM in a spare sideways ROM socket in the normal way. Having done this ZROM will always be present in your machine ever ready to help you out!

2 - As a ROM image in sideways RAM

The ZROM file (called ZROM19) is simply a ROM image and can be loaded directly into any spare bank of sideways RAM which you have available. For the Aries-B32 the command to achieve this is:

*RLOAD ZROM19 14

followed by a press of the Break key. After this ZROM will be available for your use!

Applications

Although ZROM was written for a specific application it is useful enough to be applied in many different areas. The specific application was for use with AMPLE - Hybrid Technology's Advanced Music Production Language and Environment.

AMPLE is an extremely powerful tool and one of its features allows you to define your own musical instruments which you can play through the synthesiser. The definition of a simple instrument typically consists of perhaps 10 lines of about 20 characters each: pretty small! The most useful way to keep an instrument definition for use within your own music compositions is in text form, so that they can then be *EXEC'd into the AMPLE environment. The problem here is that 31 files, each containing an instrument definition, leaves no more room in the catalogue for other files but only takes up maybe 2% of the total space on the disc. What a waste! Thus was born ZROM.

With ZROM, a library of 200 instrument definitions was quickly constructed - all held in a single file whose size was about 40000 bytes. Such an instrument library would have required 200 files spread over 7 disc sides using conventional methods! Furthermore, very soon a number of libraries had been constructed, each containing keystroke definitions relating to different musical peripherals controlled through AMPLE. For example, a drum machine library and an external synthesiser library. The fun really started, however, when an "ensemble" library had been built up: this contained definitions of ensembles, i.e. instruments grouped together to form a band. The definitions of these ensembles was simple - they just called up instrument definitions in other libraries!

This example of a ZROM application is typical of its use: wherever and whenever you need to repeat keystrokes you can use ZROM. A more basic example follows...

The three commands

*WORD

*TV 0,1

MODE 3

are a very commonly-used method for calling up the View word processor, and would normally appear in the !BOOT file on a word processing disc. By storing this in the default ZROM library UTILS under the name 'VIEW' say would allow you to use the following ZROM command:

*zx VIEW

which would have the effect of executing the above three commands. This idea can be applied in an almost unlimited number of ways!

Command Summary

ZROM offers the following commands:

ZSHOW ZS shows the module names in a library

ZXEC ZX executes a named module

ZEND ZE terminates the execution of a module

ZTYPE ZT displays the contents of a named module

ZLIB ZL displays/changes the default library name

ZCAT ZC displays the available libraries

ZPATH ZP displays/changes the disc drive search path

ZWAIT pauses the execution of a module until a key is pressed

ZINIT sets the default library to UTILS, and sets scroll mode

ZMAKE compiles a library from a library source file

ZSCROLL changes the display mode for some commands to scrolling

ZPAGED changes the display mode for some commands to paged

Where a command has a two-letter companion, the two-letter version can be used instead of the full command. Naturally, commands can also be abbreviated with a full stop and can be in upper or lower case. Note that all commands must be prefixed by '*' to indicate an operating system command.

A list of all commands recognised by ZROM is given by the help facility, obtained by typing *HELP ZROM.

A full description of each command is given later - but first you need to know a bit about modules and libraries.

Modules

A module is simply a sequence of instructions - usually operating system commands or language-specific commands - which are grouped together under a name.

Every module which you can define will consist of a header part, the body of the module, and a trailer part.

The header part defines the name of the module and always takes the form:

*|=name

The '*|=' characters tell ZROM that this line is the start of a module; it also tells ZROM that whatever follows immediately after - on the same line - is the name of the module. The module name can be any combination of 1 to 32 printable characters (do not use the space character however).

The body of the module is the sequence of instructions which you want performed whenever the module is executed. So if you were trying to define a 4-channel bass instrument the body of the module might look like this:

"bass4" [4 CHANS

ODD CHAN

Bright Flat Strike

2 CHAN

Bright Delvib Onoff

4 CHAN

Metal Flat Percuss

1 CHAN

100 OFFSET -2 POS

2 CHAN

-192 SHIFT

3 CHAN

-100 OFFSET 2 POS

EVERY CHAN

ON PHSET 128 AMP

]

The trailer part of a module is always the same. It is:

*ze

although you can always add an optional comment at the end of the line.

So the complete definition of our 4-channel bass instrument "bass4", in module form, could look like:

*|=bass4

"bass4" [4 CHANS

ODD CHAN

Bright Flat Strike

2 CHAN

Bright Delvib Onoff

4 CHAN

Metal Flat Percuss

1 CHAN

100 OFFSET -2 POS

2 CHAN

-192 SHIFT

3 CHAN

-100 OFFSET 2 POS

EVERY CHAN

ON PHSET 128 AMP

]

*zend (bass4)

You'll recognise this as an ordinary instrument definition - so how does it help you? Well the real usefulness comes when you collect many different modules together in the same text file.

Libraries

A library is constructed from a "library source". The source is simply a text file containing the definitions of many modules, each one being like the one above in terms of structure. The library itself is constructed from the source by using the ZMAKE command (see later). An example library source called INSLIB is supplied on the disc. Have a look at it; it's rather large so it's best to *TYPE it after first pressing control-N, i.e. put the screen in paged mode first.

To turn INSLIB into a useable library, copy it to a disc and (assuming ZROM is installed as a ROM image in sideways RAM or as a sideways ROM) type the following

*zmake 20 INSLIB

ZROM will respond with:

Making index - please wait... INSLIB

At this stage ZROM actually scans the library source (in this case the file INSLIB) looking for lines beginning with '*|=' which marks the start of a module. Having found a line beginning thus ZROM stores the module name in a new file called X.INSLIB together with where in the library the module actually resides (its random access address). When it has scanned the whole library source, ZROM then just copies the source onto the end of the newly-created index and closes both files: the library source file and the new library file (which also contains the index).

The number 20, in the above example, tells ZROM to reserve up to 20 characters for each module name in the index. You can use any number from 1 to 32 - although I've found that the most useful values to use are 10 and 20. These make sure that when you do a *ZSHOW, the module names then displayed are all aligned nicely and look neat on the screen. Whatever value you do use in any case is also stored as part of the index so you never have to remember it again!

Note that ZROM will always try to create the library file on the same disc side as the one holding the library source - so make sure there's enough room on the disc before you start.

General ideas

In normal use, once you've made the library as described above, you should copy the library onto one of your working discs (such as the reverse side of your boot disc). You never need to keep the library and its source together. In fact I've found it very convenient to keep a library source 'master' disc containing all my different library sources. This means that when I need to modify a library, I go to the master disc, edit the library source there and then remake the library, after which I copy it to the work disc. Remember that when you're copying the library around, it must always reside in the 'X' directory, i.e. the library file is always called "X."-something.

If you look closely at INSLIB you'll notice that the modules are arranged in alphabetical order. This is not required - I've done this so that when you use the *ZSHOW command on the library the module names will be displayed in alphabetical order, because ZROM orders the index into the library by order of occurrence. However, you can alter this - as I have indeed done with INSLIB. Running the following command:

*zs * INSLIB

will result in the following display (or something similar):

INSLIB

INS-AB INS-CD

INS-EF INS-GH

INS-JKLM INS-NOPQR

INS-S INS-TUVWXYZ

airshow arcopiano

backsyn bass4

bassa bassdrum

bassguit bassins

bassinsa bel

bigmoog16 binatone

blast bmoog

brassbow brush

bubbly chime

church click

: :

: :

: :

wave whab

willywarble wokblik

woodbash wurlitzer

XDR zang4

zizzysyn8 zumm4

You can see that all of the modules' names are listed in the same order as they are defined in the library source.

You might also notice the strange modules called, for example, INS-AB and INS-TUVWXYZ. What are they? Well, if you list one of them out with the command

*ztype INS-AB INSLIB

you'll see:

*zx airshow INSLIB

*zx arcopiano INSLIB

*zx backsyn INSLIB

*zx bass4 INSLIB

*zx bassa INSLIB

*zx bassdrum INSLIB

*zx bassguit INSLIB

*zx bassins INSLIB

*zx bassinsa INSLIB

*zx bel INSLIB

*zx bigmoog16 INSLIB

*zx binatone INSLIB

*zx blast INSLIB

*zx bmoog INSLIB

*zx brassbow INSLIB

*zx brush INSLIB

*zx bubbly INSLIB

Basically these "funny" modules let you load in many instruments in one go. So if you typed:

*zx INS-AB INSLIB

all instruments whose names begin with the letters A and B would be loaded into your AMPLE environment.

This is just an example of how you can make ZROM work for you. You can extend this idea quite easily by grouping instruments together into ensembles and having an ensemble library. Each module in such a library would consist of a number of *ZX calls to load in a number of different instruments - thereby making up your ensemble! The hard part is, of course, creating your ensemble library in the first place, but that's half the fun, isn't it!

The concept of the "default" or "current" library is a useful one to grasp. In all of the above ZROM commands I've written

*Z<command> <1st parameter> <library name>

In other words I've always explicitly specified the name of the library which should be used. If instead I had written

*Z<command> <1st parameter>

then most ZROM commands would (where appropriate - see full command definitions later) actually implicitly assume a library which should be used. This library I variously call the "default" or "current" library. When your computer first runs up (after a hard break for example), type the following ZROM command:

*ZLIB

You'll get a response of:

UTILS

What this means is that whenever you use a ZROM command which requires a library to be specified - if you don't specify it on the command line then ZROM will use the UTILS library by default. If you use this form of the command:

*ZLIB <library name>

then ZROM will set the default library to whatever you've specified - thus allowing you to type in nice short ZROM commands without the library tagged onto the end of each one!

If you've set up a default library by using *ZLIB you can still type ZROM commands with the library name specified - ZROM will still remember what your default library is called but, for the duration of the command, it will use the explicitly-mentioned library.

In the example of the INS-AB module above, you can see that each invocation of ZROM's *zx command has the library explicitly named. This is simply because firstly, not all of the modules need necessarily reside in the same library; and secondly, the default library which is current when you choose to run

*ZXEC INS-AB INSLIB

might not actually be INSLIB. It is therefore wise within modules to always explicitly name libraries whenever you are "nesting" modules. This means that you can always *ZXEC any module with any library being the default one knowing that when the module has loaded the default library will remain unchanged.

Another feature which you can use to your advantage is this: ZROM lets you tell it on which disc sides libraries might be found and from then on always looks in those places whenever it is trying to find a specific library. Thsi feature is called the "drive search path" or simply "path".

You specify the path with the ZROM command *ZPATH. If you use it in this form:

*ZPATH

ZROM will display what the current drive search path is. After a hard break, ZROM will print "*". This means that ZROM will search only the current drive for the library it needs. So, if you're on drive 0 ZROM will search the "X." directory for all libraries.

If you are lucky to have 2 double-sided drives then you have available to you drives 0, 1, 2 and 3. So if you typed the following command:

*ZPATH 0231*

it would tell ZROM, from then on, to always search directory X on first drive 0, then drive 2, then drive 3, then drive 1 and finally the current drive for any specified library.

I normally use this command only once during any session. I have the convention whereby I store instrument libraries on the reverse side of my !BOOT disc (i.e. drive 2) and piece-related libraries on the reverse of my music discs which are always in drive 1. So my piece-related libraries are on drive 3. The path which I set up therefore in my !BOOT file is:

*ZPATH 23*

I always include the "current drive" specifier '*' because occasionally I store libraries on my music disc - i.e. drive 1.

For descriptions of the other ZROM commands to manipulate modules etc. see the Command Definitions given later.

Compatability

ZROM was written on an Acorn BBC 'B' microcomputer fitted with a 1770 DFS disc interface, 2 double-sided 80-track disc drives, an Aries B32 sideways RAM expansion system, an Aries B12 sideways ROM expansion system, plus many other bits and pieces including Hybrid's Music 5000 (upgraded from 500), Music 4000 keyboard, and Music 2000 midi interface.

ZROM will only work on systems fitted with discs as it makes extensive use of random access techniques which cannot be provided by a cassette-based system.

ZROM uses only legal and documented OS calls and facilities and should therefore present no problems from that point of view.

ZROM requires and uses RAM workspace, but rather than claim workspace from main working RAM (and thereby even further reduce the amount of RAM available to you) it reuses RAM which would normally be used for other purposes. ZROM actually makes use of 2 areas of RAM as follows:

Firstly the area $90 to $9F: this is allocated to the Econet system.

Secondly the area $A00 to $AFF: this is normally used as an input buffer for cassette or RS423 input, and as a buffer for the Staff Editor within the Hybrid Music 5000 AMPLE environment.

Use of the first area should cause problems only on systems fitted with Econet.

As ZROM will only work on disc-based systems, the only real problem which AMPLE users will come across with respect to the usage of the second area of RAM will be with the Staff Editor. If you are using the Staff Editor and decide to then use any ZROM facility you will quickly discover that everything in the Staff Editor is lost! Don't worry too much, however: as long as you discipline yourself no disasters will result!

All you have to do is this: before using the Staff Editor use ZROM to load in all of the instruments you require; in this way you won't run the risk of having to use a ZROM facility to get another instrument while you are composing (i.e. plan your work!) Then after you start composing (or editing) with the Staff Editor, whenever you exit to do anything else ALWAYS issue a MAKE command to ensure that your composition is safe. Remember - ZROM can't affect AMPLE words! Then, even after using ZROM, you can go back to the Staff Editor to edit the AMPLE word which you created with the MAKE command.

The final problem which some AMPLE users will encounter comes through the use of a ZXEC call within the !BOOT file - one of which calls the C.PREPARE utility supplied as part of the MUSIC 5000 environment. This problem isn't so easy to understand - but suffice it to say that if you've a Model B with no shadow RAM expansion then you will notice the problem. All the rest of you - relax!

I only came across the problem because I was trying to be clever: I wanted to be able to load up my MUSIC 5000 with combinations of the M5, M4 and M2 modules. The reason behind this is that if I load up all three modules, then I can never load A.MPLINEX into the system. For "standard" loading I had a !BOOT file containing the command

*ZX 245 BOOT

which basically caused modules M2, M4 and M5 to be loaded. My BOOT library contained the following module definitions:

*|=5

*ZX COMMON BOOT

"M5" INSTALL

"EW" INSTALL

"MENU" INSTALL

"FX1A" INSTALL

"INS1" INSTALL

*ZE

*|=245

*ZX COMMON BOOT

"M2" INSTALL

"M4" INSTALL

"M5" INSTALL

"EW" INSTALL

"MENU" INSTALL

"FX1A" INSTALL

"INS1" INSTALL

*ZE

*|=45

*ZX COMMON BOOT

"M4" INSTALL

"M5" INSTALL

"EW" INSTALL

"MENU" INSTALL

"FX1A" INSTALL

"INS1" INSTALL

*ZE

*|=25

*ZX COMMON BOOT

"M2" INSTALL

"M5" INSTALL

"EW" INSTALL

"MENU" INSTALL

"FX1A" INSTALL

"INS1" INSTALL

*ZE

*|=COMMON

*BASIC

*DR.0

*/C.PREPARE R S K C

*FX 202,48

*FX 118 *

AMPLE

% Release 3

":0.M." MPREFIX

*DRIVE 1

"INT" INSTALL

*ZINIT

*ZLIB INSLIB

*ZPATH 2

*ZPAGED

*DRIVE 1

*ZCAT

*ZE

If ever I started off my system with no shadow RAM at all, module 245 would start loading. Then it would continue by calling up module COMMON. As soon as execution got as far as calling C.PREPARE, some strange characters would appear on the screen, the bell would beep, and all I would then get would be "Syntax error"s.

The problem would appear to be linked to the fact that C.PREPARE sets PAGE to $1300 only if it is originally at $1900. Furthermore (cf. page 89 of MUSIC 5000 User Guide) this prevents you having more than one file open at a time.

Things get a little more puzzling when I explain that after loading up my BBC B using a normal !BOOT file (i.e. one that doesn't utilise ZROM calls), I can then happily load up "nested" modules with no errors at all!

The moral here is: don't make use of a ZXEC call in your !BOOT file if you're using a BBC B with no shadow RAM. Neither should you try to use "nested" modules.

Command definitions

All commands accepted by ZROM are detailed in the following pages. The description for each command is presented in a consistent way as follows:

Command: name of the command.

Usage: syntax of the command.

Parameters: a description of each parameter required by the command (if any), and an indication of its default value if the parameter is optional.

Function: brief description of the effects and purpose of the command.

Comments: miscellaneous comments regarding the command and its use.

Limitations: comments on any known limitations and bugs associated with the command.

In the "Usage:" section, the syntax of the command is presented using the following conventions:

[ ... ] indicates that the item enclosed by the brackets is optional

library represents the name of a library

module represents the name of a module within a library

path represents a drive search path, e.g. 02* means that drives 0 then 2 and then the current drive will be searched in any operation involving the discs.

Also the command name used is shown in lower case although ZROM is not case sensitive when it comes to the command name and library name. Whenever you specify the name of a module, however, be careful as ZROM is case-sensitive on module names.

Command: ZCAT ZC

Usage:

*zc

Parameters: None.

Function: To display the current (default) library, the disc drive search path, the current drive, and the libraries present on each drive in the search path.

Comments: Use of this command on a machine which has just been powered on will result in a response of the form:

Current library: UTILS

Path: *

Drive: 0

Drive 0: UTILS INSLIB MIDILIB

This gives a convenient way to establish quickly your current set-up and the libraries available to you.

Limitations: None identified.

Command: ZEND ZE

Usage:

*ze [ comment text ]

Parameters: the comment text, if supplied, can be any text which you can use to place a comment at the end of a module; ZROM totally ignores the comment.

Function: This function is used in a module definition to mark the end of the module. For example, taking the earlier View boot-up module, this would be stored in the library as

*|=VIEW

*WORD

*TV 0,1

MODE 3

*ze

Comments: None.

Limitations: None identified.

Command: ZINIT

Usage:

*zinit

Parameters: None.

Function: This command sets the current library to UTILS and sets the scrolling mode.

Comments: None.

Limitations: None identified.

Command: ZLIB ZL

Usage:

*zl [ library ]

Parameters: The name of a library.

Function: If the optional parameter is supplied, then the current default library will be set to that name. If no parameter is supplied, then the name of the current default library will be displayed.

Comments: ZROM does not care whether you specify the library name in upper or lower case, or even a mixture of both!

Limitations: None identified.

Command: ZMAKE

Usage:

*zmake [ length [ library ] ]

Parameters: length represents the maximum number of characters which will be used for module names when creating the library; it defaults to the value of 10 if not supplied; length should be from 1 to 32.

library represents the name of the file containing the library source; it defaults to the current library if omitted.

Function: This command is used to create a library file from a source library. It assumes that the source library file is called 'library' in the current directory. If a file of this name cannot be found, then an error message is displayed and the command terminated. Otherwise the source file is read and the library file is constructed; the library file will be called 'X.library' and should not be renamed.

The module names within the library will be retained during the construction of the library up to the number of characters specified by the 'length' parameter. Module names longer than this are simply truncated.

Comments: This command does not alter the contents of the source library file.

For the value of 'length', the default (10) and 20 seem to be the most useful from the point of view of displaying module names in 40- and 80- character width screen modes.

Because of the nature of the library file, if you want to make changes to its content you should edit the source file and then reprocess it using this command.

Limitations: None identified.

Command: ZPAGED

Usage:

*zpaged

Parameters: None.

Function: This turns on the paged mode for ZROM displays.

Comments: After use of this command, subsequent ZROM commands will produce their displays in paged mode, i.e. the displayed output will pause after every screenful until you press the SHIFT key. This is particularly useful when using the ZS and ZT commands which, potentially, can produce a lot of output to the screen.

This command has no effect on the display produced by use of the ZXEC command.

Limitations: None identified.

Command: ZPATH ZP

Usage:

*zp [ path ]

Parameters: path specifies the drive search path.

Function: This facility allows you to locate your library files on any disc surface in your system; it also allows you to specify to ZROM the order in which you want it to search your discs for libraries.

If you specify the path, then the drive search path will be set to that value.

If path is omitted, then ZROM will display the currently set-up drive search path.

Comments: Suppose that you had 2 double-sided disc drives on your computer. You would then have available to you drives 0, 1, 2 and 3 for the storage of data and programs.

It may be that you have a BOOT disc containing your !BOOT file on what would normally be drive 0. Further you may use the second drive, with sides 1 and 3, to hold music files etc. It would be a sensible strategy, therefore, to store your libraries on your BOOT disc, but on drive 2. You might also find yourself storing piece-related libraries on drive 3, rather than clutter up your music files stored on drive 1.

A sensible use of the ZPATH command would then be:

*zp 23*

This would tell ZROM that whenever you asked it to perform an operation involving a library, it would first look for that library on drive 2, then on drive 3, and finally on the current drive.

You would normally include the use of the ZPATH command in your !BOOT file and never use it again during your session with the computer.

Limitations: None identified.

Command: ZSCROLL

Usage:

*zscroll

Parameters: None.

Function: This turns on the scroll mode for ZROM displays.

Comments: This has basically the opposite effect to the ZPAGED command. After using it all subsequent displays to the screen produced by ZROM commands will not pause after every screenful.

This command has no effect on the display produced by use of the ZXEC command.

Limitations: None identified.

Command: ZSHOW ZS

Usage:

*zs [ module [ library ] ]

Parameters: module is a character string which ZROM will use to match against the module names in the library; if omitted then ZROM will use the character string '*'.

library is the name of the library which ZROM is to search; if omitted then the current default library will be used.

Function: This facility allows you to display on the screen which modules are present in a library.

Comments: If you want to see if a particular module is defined in a library then use the command and specify the full module name. For example, to see if the definition of the piano module exists in your instrument library you would type:

*zs piano inslib

This would result in the module name 'piano' being displayed on the screen - assuming that it is present in the library of course!

If you want to see which modules whose names begin with the letter 'p' exist in your library, however, use this form of the command:

*zs p*

You can read this as "find the names of all modules in the library beginning with the letter 'p' and ending with zero or more characters". The use of the asterisk in this manner is called "wildcarding" and the asterisk itself is called the catch-all wildcard.

You can use the catch-all wildcard anywhere in the string which you supply to this command, so for example

*zs *moog*4

would show you all of the 4-channel moog-type instruments which are defined in the current default library.

If you want to see a list of all modules within the current default library then just use the command on its own, i.e.

*zs

Limitations: The wildcard function doesn't always work as you might expect it in complex cases. For example, ZROM would not match 'p*s*b*e' with 'possible'. This is an error in the algorithm but is of no great significance.

Command: ZTYPE ZT

Usage:

*zt [ module [ library ] ]

Parameters: module is a character string which ZROM will use to match against the module names in the library; if omitted then ZROM will use the character string '*'.

library is the name of the library which ZROM is to search; if omitted then the current default library will be used.

Function: This facility allows you to display on the screen the contents of a particular module in a library.

Comments: If you want to see how a particular module is defined in a library then use this command and specify the full module name. For example, to see the definition of the piano module in your instrument library you would type:

*zt piano inslib

This would result in the contents of the module named 'piano' being displayed on the screen - assuming that it is present in the library of course!

You can use the wildcard function described under the ZSHOW command to save on typing. For example, this command

*zt p*o inslib

would have the same effect as the one above. You can read this as "display the definition of the module whose name starts with a 'p', ends in an 'o' and has zero or more characters in between".

Because the ZHOW command can type out only one module definition at a time, using this form of the command:

*zt p*

would result in the first module whose name begins with the letter 'p' being displayed.

Lastly, typing

*zt

would result in the very first module defined in the current default library being displayed!

Limitations: The wildcard function doesn't always work as you might expect it in complex cases. For example, ZROM would not match 'p*s*b*e' with 'possible'. This is an error in the algorithm but is of no great significance.

Command: ZWAIT

Usage:

*zwait [ comment text ]

Parameters: None.

Function: To cause the execution of the current module to be halted until a key is pressed.

Comments: Use of this command will result in the following message being displayed:

Press any key to continue..

.

To then resume execution of the module, you must press and release any key on the keyboard.

Limitations: Any key except the BREAK key can be pressed to resume execution of the module.

Command: ZXEC ZX

Usage:

*zx module [ library ]

Parameters: module is a character string which ZROM will use to match against the module names in the library.

library is the name of the library which ZROM is to search; if omitted then the current default library will be used.

Function: This command results in the specified module being executed using the EXEC facility of the BBC microcomputer.

Comments: The module name can be specified using the widcard facility described under ZSHOW and ZTYPE.

Any module can include uses of the ZXEC command itself to execute other modules. These calls to ZXEC are "nested" up to a maximum depth of 5. This means that a module can ZXEC another module which ZXECs another module etc. which is best illustrated as follows:

*zx module_1 (typed at the keyboard)

: : : :

*zx module_2

: : : :

*zx module_3

: : : :

*zx module_4

: : : :

*zx module_5

: : : :

: : : :

*zend (module_5)

: : : :

*zend (module_4)

: : : :

*zend (module_3)

: : : :

*zend (module_2)

: : : :

*zend (module_1)

Limitations: When a module is executed from a !BOOT file, at the end of execution of the module control does NOT pass back to the !BOOT file; instead execution of the !BOOT file terminates.