Previous Next

This is an integer compiler for the 48K Spectrum only. The program is supplied in a standard cassette tape box (i.e. not one of those overgrown video cassette ones) with an eight-page fold-out instruction leaflet, which is brief but to the point.

Loading the program is simplicity itself - just type LOAD"". There is a Basic loader which tells you that the compiler is invoked by the RAND USR 60000 command, and that your Basic is compiled to locations 40000 upwards. This is the default address, however, and may be changed using CLEAR n where n is the address at which your Basic is compiled. This facilitates stacking of programs in memory, but more of this later.

MCODER must always be present in memory before any Basic is entered. This is because the loader program does a NEW when you press any key after MCODER is fully loaded. Basic programs can then by typed in as usual, or loaded from tape. Once your Basic program is entered and checked you compile it simply by typing RAND USR 60000. If MCODER comes across an invalid line it will return to Basic with a flashing question mark near the offending command. If this should happen, Caps Shift and 1 (Edit) will bring down the offending line for correction.

Some typical errors include:

1. Using illegal variable names;
2. GOTO 'variable' or GOSUB 'variable', which are not allowed;
3. Illegal statement type such as LOAD or SCREEN$.

Actually most Basic programs as printed in magazines and so on will not compile in their original form, and will have to be modified, taking into account the list of allowed commands. As it says in the instructions, 'You should be aware that you will probably have to make considerable alterations to your program before it will successfully compile as it is liely that the Basic was not written to suit MCODER." However, most programs can be made to work, albeit in a modified form. Errors are reported using standard Sinclair error codes as listed in the Spectrum manual, appendix B.

At the end of a successful compilation three pieces of information are shown:

1. A 'compilation OK' report;
2. The length of the compiled code;
3. The run address.

If all is well, and your compiled Basic is stored safely above RAMTOP, it can be run using RAND USR 'address', where 'address' is given in 3, above.

As was stated earlier, it is possible to stack several programs on top of each other. This is achieved by moving RAMTOP around in memory. The procedure is to initially set RAMTOP to a fairly high place in memory and compile program A at this address. Then RAMTOP is moved down in memory to allow enough room for program B to be compiled underneath program A. This process is repeated for programs C, D, E, etc. Care must be taken not to overwrite any existing programs as no check is made by Mcoder. These programs can then be treated as subroutines and called as required.

As Mcoder is an integer compiler, it will only operate on whole numbers, and these must be in the range -32768 to +32767. As it has no time-consuming floating point calculations to do there is a considerable increase in execution speed in compiled programs. However, as stated before, it will not compile all Basic, and continual reference to the instruction leaflet is necessary to check which commands are allowed.

Variable names may consist of upper and lower case letters, and numbers. Multi-dimensional arrays and string arrays are not allowed. Strings have a default length of 32 characters but this may be altered with a poke.

By using special REM statements, the BREAK key can be:

0. Disabled except at 'scroll' and INPUT - this gives the most efficient code (i.e. fastest)
1. Enabled - this gives less eficient code than 0, but allows the program to be broken into for debugging, etc;
2. Enabled and with current line of execution displayed at the top right-hand corner - this runs at about normal Basic speed, but is very useful for debugging purposes.

Option 1 is chosen by default, but this can be changed as often as you lke in programs by including a REM statement - REM # 0, REM # 1 or REM #2 - corresponding to the options above.

The compiled code may be saved from Basic (SAVE is not compiled) using the usual SAVE 'name' CODE n. However, as Mcoder contains certain runtime routines, it must be saved along with the compiled code.

Compiled Basic is generally more efficient than interpreted Basic, which means that it runs faster and is more compact. This is advantageous for games writing as games will run much faster. As this is a mainly games-orientated magazine, some thought will be given to this.

In general, arcade games written in Basic are slow and jerky - slow because of inherent qualities of the interpreter, and jerky because of the whole character block steps used or movement. Using a compiler such as Mcoder can more or less solve the problem of speed. However, the jerkiness is still there. The result is games, which instead of being slow and jerky, are now fast and jerky. The speed partly compensates for this, but the results are never particularly realistic and in no way are they comparable to most commercially available games. Some people will accept this but many, I feel, will be disappointed.

M-Coder II is easy to use, and if you can overcome the omission of some commands it could be quite useful. The speed improvement is significant, but the program is not really intended for beginners. Using a compiler is supposed to be an alternative to using machine code, but in reality some knowledge of machine code is needed to fully understand its operation.

At £9.95 I cannot help feeling that it is overpriced, as the Softex IS Compiler is the same price, and this offers far superior (in theory) facilities. However, there seemed to be some anomalies in the operation of the Softek compiler, whereas the Mcoder worked without fault, so this can only be in Mcoder's favour.