14 of 158
8 ZBasic is a strongly typed language that doesn’t 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 you’ll 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 you’re 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