David Janda looks at a cassette-based C64 Basic compiler

Finding a 'true' compiler for your micro can be a little difficult. Not that there isn't an abundance of them.

Usually, you willfind that there are a few restrictions in use: no floating point, no arrays, no string handling, etc. Many also require the compiler to be present in memory when the object code is run.

The Commodore 64 is no exception, and a disk-based version called DTL-Basic 64 has been available for some time. Now DTL-Basic 64 is available on cassette for the majority of 64 users, and even though it offers a subset of the facilities of the disk based compiler, it still offers the C64 users a very powerful compiler.

The main feature of this package is the total compatibility with Commodore Basic 2, thus allowing many (if not all) existing programs to be compiled. The only restriction is that the source code cannot exceed 12K because the tape version doesn't have the facility to "pull in" bits of code and compile them.

Still on the theme of compatibility, DTL-64 allows the use of cartridge software or other utilities to be used with compiled programs. When compiling, a warning message appears to let you know that the DTL-64 compiler has come across a statement that it doesn't understand. This means that you could write and compile programs that use Simon's Basic for example, but the extra statements wouldn't be compiled. Instead, when the object code is run, the cartridge software or whatever 'cuts in' and takes over until the statement has been executed and then passes control back to the program.

This compatibility has been possible partly because the DTL-64 stores variables and arrays in the same format and place in memory as the interpreter. But the difference here is that the compiler has seprate routines for integer and floating point calculations. Commodore 64 users rarely specify their variables as integers (there being no speed improvement) so that DTL compiler allows you to specify what variables are going to be integer or floating point by declaring said variables in a compiler directive. This saves going through the listing to edit variable names. Also, control variables in FOR...NEXT loops can be declared as integer, and this allows for a dramatic speed improvement.

One of the handiest features in DTL-64 is the special poke mode. This allows you to poke a value into an address. You switch on special mode as a compiler directive. Then, a statement such as Poke 3,23 will actually poke address 3 plus the value in the address with 23. This is handy as the compiler allows integers to a value of 16384 (usual), and the sound and graphics chips have addresses higher than this.

Finally, from the computer itself, several compiler directives are allowed which can do things like disabling the break key and disabling the warning messages.

As manuals go, the DTL-Basic 64 offering is not bad at all. What was missing was a "what do I do if things go wrong" section, which would have been very handy as the compiler is not the easiest to use.

Although the compiler should work with most Basic programs, any additions or amendments should be made before using the compiler. This is because you cannot fiddle about with your source code once it has been loaded into memory by the compiler. Indeed, one you have compiled the program and errors have cropped up, you can't amend them in memory at all! Instead, it's necessary to exit the compiler, load and amend the source code, save it, reload the compiler, reload the amended source code and then compile it.

After the source code has been prepared and saved to tape, you then have to go through the long process of loading and running the compiler which is in three parts.

To keep the compiler at a fairly reasonable price, Dataview issues a security key (dongle) which is inserted into the cassette port after the run-time library has been loaded. The space key is then pressed, and if the security numbers match, you can re-insert the cassette cable and proceed.

In practice, things were not as simple as that. The dongle is not a very secure fit and there is no polarising notch on it, so it is easy to insert it the wrong way.

Normally, improper insertion of the dongle will result in the C64 resetting, but, if like me you insert it too far and at an angle, the Commodore 64 could (as mine did) pack up completely.

Commodore constantly repeats in its documentation that nothing should be attached or detached while the power is on as damage may occur and I agree.

After the key has been fitted and all is well, a menu of options is displayed and yu can choose to use the printer to give reports on compilation as well as a listing with error reports, if any. The names for the source and object code are entered in lower case.

After the source and object files have been specified, you load the source code and compile it. The compiler gives two passes of the code and the line number which it is working on is displayed on the screen together with the pass number. Warning and error messages are also displayed and if the option to use the printer was chosen, a headed listing is generated with the error and warnings placed in the offending part of the code.

The compilation time is quite fast and at the end the compiler warns you that it is going to save the object code to tape. After that you have the choice of compiling another program, or to rewind the tape, load and run an already compiled program. Here there should have been an option to dump the RTL file immediately after the object code to produce a totally free running program. As it is, it is necessary to save the object code, take the cassette out, insert the compiler tape and load the RTL file, re-insert the object tape and save the RTL file after the source code!

The compiler products object code which can run many times faster than ordinary Basic. The fact that there is very little amending to the existing program means that with a few minor adjustments you can compile your existing library of programs without the necessary adjustments to the source code as some compilers require.

The fact that compiling programs is a very long and user-hostile process, makes what is an excellent commpiler a bore to use and the user interface could be dramatically improved. A rethink into using dongles on cassette ports while the machine is on should also be considered.

The DTL compiler offers several compiler directives which allow you to specify integer variables and so on. This can increase the speed of the program, but you can't use the integer directive throughout the program. The break key disable option doesn't make much difference as it is tested after a NEXT as well as an IF statement.