6
ZBasic is a strongly typed language that doesnt allow you to freely intermix different data types. This
helps prevent programming errors or unexpected program behavior that results from unanticipated type
conversions. However, a series of well-defined type conversion functions is provided that allow you to
make explicit type conversions when necessary. See Section 2.13 for more information. Lastly, Section
3.26 contains technical details of the implementation of the various data types. This information is
generally not necessary for most programming purposes but it is sometimes useful to know.
2.3 Modules
A ZBasic program may comprise one or more modules each contained within a separate file. When a
module is compiled, a module name is derived from the name of the file. The module name is mostly for
internal use by the compiler but youll find references to the module name in the generated map file.
Also, in some special situations you may need to use the module name as part of an identifier in order to
refer to a variable or constant in your code. This is usually not necessary but it is good to remember that
it is available. See Section 3.1 for more information on resolving identifier references using the module
name.
The module name is derived by first removing the path prefix, if any, and the extension (typically .bas).
The remaining characters of the filename are examined and any character that is not a letter, a digit or an
underscore is replaced with an underscore. For the most part, this process converts the filename into a
legal ZBasic identifier.
As an example, consider the filename C:\temp\my test code-1.bas. When you compile this
module the derived module name is my_test_code_1. If you compile a file whose corresponding
module name does not begin with a letter, the compilation will proceed as normal. However, you will not
be able to refer to that module by its module name since it will not be a legal ZBasic identifier.
A module is divided conceptually into two sections: an options section which, if present, must be first, and
a definitions section. The definitions section may also be omitted but with no definitions, the module
serves no useful purpose.
2.3.1 The Options Section
The options section contains directives that tell the compiler how to process the definitions section that
follows. In the absence of any option directives, the compiler uses certain default settings as described
below. This means that it is perfectly reasonable, and quite common, not to have any option directives in
a module. The options section may also contain comments. This is useful for documenting what youre
trying to accomplish with each option directive.
Note that some of the settings affected by the option directives described in this section may also be
affected by compiler command line options. Option directives have precedence over command line
options. See Section 7.1 for more information on command line options.
Option <pin> <pin-state>
This option directive provides a way to configure an I/O pin to be an input or an output. If it is being
configured to be an input, you can further specify that whether or not the pull-up resistor is enabled. If it is
being configured to be an output, you can further specify the logic level that you want to be output. This
option directive may only appear in the first module compiled - usually the one containing the Main()
subroutine.
The <pin> element specifies the pin to be configured. The first way to specify the pin to configure is to
use the word Pin followed immediately by a physical pin number, e.g. Pin20. Of course, the set of pin
numbers that can be specified in this way depends on the ZX processor that you are using. For example,
for the 24-pin ZX devices the allowable values are Pin5 through Pin20 as well as Pin25, Pin26 and
Pin27. The second way to specify the pin to be configured is to give the port letter and a bit number of