T F Letocha
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.
