ZBasic Language Reference
139
ZBasic Microcontrollers
Chapter 7 - Compatibility Issues
The ZBasic language and compiler were designed to be backward compatible with BasicX and to offer
some of the advanced features of Visual Basic along with some capabilities not found in either VB or
BasicX. A design goal was that any BasicX program that compiles error-free would be compiled without
errors by the ZBasic compiler in BasicX compatibility mode. The converse may or may not be true. If you
write a ZBasic program carefully avoiding those features that aren’t supported in BasicX, you can expect
that it will be compiled error-free by the BasicX compiler. Similarly, you can most likely write a Visual
Basic program that can be successfully compiled by the ZBasic compiler if you carefully avoid those
ZBasic features that aren’t supported in Visual Basic as well as those VB features that aren’t supported in
ZBasic.
Another design goal was that, with a few unavoidable exceptions, a program that can be successfully
compiled by both the BasicX compiler and ZBasic compiler (using BasicX compatibility mode) will exhibit
substantially the same behavior when executed on the respective processors. The target behavior is as
described in the BasicX documentation. However, in cases where the BasicX documentation is
ambiguous, incorrect or incomplete, tests were developed to ascertain the actual behavior. Unless it was
impossible, impractical or inadvisable to do so, the empirically determined behavior was implemented in
order to maximize backward compatibility.
When porting a BasicX application to ZBasic it may be best to use BasicX compatibility mode at first.
Once you get the program working in that mode you can then switch to not using compatibility mode in
order to be able to utilize the advanced capabilities of ZBasic. Of course, turning off compatibility mode
may cause your program to behave differently requiring some additional modifications to the program.
7.1 Known Differences and Compatibility Between ZBasic and BasicX
-
ZBasic programs are not object code compatible with BasicX. Existing programs will need to be
recompiled specifically for the desired ZX target.
-
Some BasicX programs rely on I/O pin configuration performed by the Project | Chip dialog in the
BasicX IDE. This configuration information is stored in a .prf file rather than appearing directly in the
source code so it is easy to overlook. Porting such a program to ZBasic will require the addition of
Option Pin or Option Port directives or the addition of equivalent configuration statements to the
source code.
-
Since most ZX microcontrollers run at twice the clock speed of the BX-24 your code will execute
faster. This may reveal latent timing problems that existed in your BasicX application but that never
before caused a problem.
-
Due to the fact that the CPU runs twice as fast, the time units for OutputCapture() and
InputCapture() are half as long. Depending on the particulars of your application it may work to
simply apply the 0.5x scale factor to correct the values. Otherwise, you may be able to choose a
different TimerSpeed setting to achieve the result that you need. Also, time divisors, including the
serial port baud rate divisor must be twice as large to achieve the same effective rates.
-
Also due to the faster clock speed, the SPI interface runs at twice the clock rate. If this is a problem,
you may be able to select a different SPI clock multiplier to get satisfactory results.
-
Some System Library routines are implemented differently on the ZX than they are on the BX-24. For
example, on the ZX series the ShiftIn() and ShiftOut() System Library routines use Timer1 for
speed regulation. This is not the case in BasicX. Also, the X10Cmd() routine will not return until the
command has been transmitted. In BasicX, the documentation suggests that the routine returns
immediately while the transmission is done in the background.
-
In BasicX if the CByte() function is passed an UnsignedInteger argument that is larger than 255,
the result is the low byte of the value. This is inconsistent with the handling of other types. In ZBasic,
CByte() returns 255 when the parameter value is larger than 255 for all parameter types.
 |
 |
 |