The STOS compiler is a very useful program to have because it does the following things.
It speeds STOS programs up to three times their normal speed.
It saves the program as a single PRG file so there’s no need to copy the STOS folder onto the copy disk.
Compiled STOS programs are smaller than normal ones, saving disk space.
There’s no way a PRG file can be changed back into a BAS file so no-one can hack into it.
Even though the compiler seems like a great piece of software, it does have its issues. For example, when you compile a program to disk and then load it, the Function Key window flashes twice before the program starts. The way around this problem is to remove these commands from the program before you compile it.
key off
mode 0
hide on
curs off
From the Compiler’s main screen, go to the option menu and set the MODE option to LOW. Next, turn off the other commands by clicking on the OFF boxes. Compile the program and the screen appears blank when the program is loaded. Works better when the compiler sets the commands.
If you are pressed for space, then reduce the Sprite Buffer to 500 bytes. If the mouse pointer is not used in your game then select the NONE option in the option menu, but if your program just uses low res pointers then turn off the LOAD MED/HI option instead.
The Compiler has a couple of problems on the STE, first, trying to set it to change to Medium Rez results in the compiled program to run in the rez it was loaded in. Change the mode option to medium.
The second problem is with the STOS Tracker. On the STE the compiler always tells you that the last line of your program has an error, no matter what it is. To fix this you need to update the Compiler with the program on the Tracker disk called COMP207.PRG which updates the Compiler to v2.07 so the tracker commands will compile okay.
The compiler will sometimes list a line in your program and report an error, even though the line is okay. The reason it does this is because it is having trouble compiling it. This can happen on long lines of code and the FOR/NEXT loops. Look at this example.
10 pen 6: for x=1 to 10 : print”Hello” : next x
The compiler doesn’t like this line because of the “pen” command, why is a mystery, but remove the “pen” command and everything is fine. When using the FOR command, make sure it’s the first command on the line, like so…
10 for x=1 to 10 : pen 6 : print”Hello” : next x
See how I have put the “pen” command inside the loop? This lead to another problem I found. Look at this example.
10 box 10,10 to 100,20
When this line is found in a compiled program, the box is drawn in the current paper colour. The solution is to add an “ink” command at the start of the line.
10 ink 1 : box 10,10 to 100,20
The compilers main problems lie in the basic listing, it will report any lines it doesn’t understand. Normal errors would be spelling mistakes or the wrong use of a command. But sometimes it just has trouble compiling it in this case just play about with the listing and re-word it a bit, then try again.
In the COMMANDS.BAS file, there is a list of words that cannot be used in a compiled program. Most of them are Direct Commands so they can’t be put on a line anyway. The “run” command can’t be used so if your program requires a BAS file to load and run later in the program then you’ll just have to add it to the end of the program and call it using the ‘goto’ command.
Also, if your program has LOAD”name.var” in it, it will not work when compiled. The compiler will compile it but prints an error in the compiled program when it comes across this command. The solution is to save your variables as SEQ or RANDOM ACCESS file. For example:
10 open #1,”R”,”varible.dat”
20 put #1,N$
30 close #1
You can then load the contents of N$ like this.
10 open #1,”R”,varible.dat”
20 get #1,N$
30 close #1
Despite these issues most programs should compile fine. One other important thing to remember is that extensions have a compiler version with the extension .ECA. Make sure you have that installed.
