Page 143 of 229 Start Back Next End ZBasic Language Reference 133 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.