Compiling The Game

Introduction

S31 left Mouse In A Hole about as fast as BASIC would take it: six or so moves a second with a key held. It said the next steps were a compiler, and then machine code. This section takes the first of them.

Crystal Research, who wrote Xtal BASIC, sold a compiler for it. It took them a while. Its manual admits as much:

Continual improvement to Xtal BASIC has meant that the compiler has tended to get pushed further and further back, to the point that we almost felt that it would never appear at all!

It did appear, in 1987, and it is on your course disc. It reads the very same program you have been typing and saving, and it runs Mouse In A Hole twice as fast.

Two Programs

The compiler comes as two programs, and both are run from the DOS prompt, not from inside BASIC:

The .XBS is still the program you edit, list and save. The .XBI is for running.

It is honest about what it is. The manual:

While not operating at anything like machine-code speed, a run-time speed improvement of 1.5 to 5 times is possible, and the speed improvement tends to be greatest in very large programs.

Compiling Mouse In A Hole

Load your finished game and make sure the latest version is saved, then leave BASIC:

LOAD "MOUSE15"
SAVE "MOUSE15"
DOS

At the 0: prompt, compile it:

0:XC MOUSE15

Xtal BASIC Compiler Ver 5.10
(c) Xtal 1987
Compiling MOUSE15  -
Pass 1 Pass 2 Pass 3
Compiled OK
0:

Three passes over the program, and a new file on the disc: MOUSE15.XBI, a few K. Now run it:

0:XR MOUSE15

XR signs on as Xtal BASIC System Ver 5.10, and the title screen appears. Play. It is the same game - the same key reader, the same cheese, the same cats - and it moves twice as fast.

When the game ends, XR hands back to DOS, not to BASIC. Type XBAS to go back to BASIC.

The course disc already has a compiled copy: XR GAME runs GAME.XBI, compiled from the finished game on the disc.

Twice As Fast

S31's clock tells you how much faster. Put S31's two timing lines back into the game, save it under a new name, compile that and run it:

With a key held the mouse now moves about twelve times a second instead of six.

Why? The manual explains its three passes. The second turns every number and every variable name in the program into a short code, so that they need not be worked out or searched for as the program runs. The third replaces the line number after every GOTO and GOSUB with the place to jump to, so that nothing has to be found. Those are the very costs S31 measured - a variable found by searching, a number worked out from its digits, a line found by walking the program - and the compiler pays them once, before the game starts, instead of on every pass.

What it cannot touch is the Einstein's own handling of a held key. That still costs what it did.

Smaller Steps

A faster game can be spent two ways: the mouse can go faster, or it can go at the same speed in smaller steps. The second is what makes movement look smooth.

Under BASIC the mouse walked 6 pixels every 160 thousandths of a second. Compiled, a pass takes 80 - so a step of 3 moves it just as fast, in steps half the size. Change the walking step in lines 300 and 310:

300 VX=0:IF K=64 THEN VX=-3:IF FC<>144 THEN FC=144:SPRITE 0,MX,MY,14,FC
310 IF K=32 THEN VX=3:IF FC<>132 THEN FC=132:SPRITE 0,MX,MY,14,FC

Save it as MOUSE16, compile it with XC MOUSE16, and run it with XR MOUSE16. Timed, a pass still takes 80 thousandths of a second with a key held - the step size costs nothing - so the mouse crosses the floor as fast as it did in BASIC, but glides where it used to jump.

Run the same MOUSE16 in BASIC, uncompiled, and it crawls: the same small steps at half the rate. A smaller step is only worth having when there is the speed to pay for it.

What The Compiler Will Not Do

Nearly every program that runs in BASIC compiles, but not quite every one.

• EVAL is not allowed. A program using it is refused: 'EVAL'' Not Allowed -- Error, and Cannot Compile. The manual says the same of HOLD.
• An error does not say where it happened. The same division by nought that BASIC reports as Division Error in 20 comes out of a compiled program as Division Error - no line number, because the compiled program has none. The manual's advice is plain: "test your programs under the interpreter first".
• The compiler looks at every line, used or not. A GOTO to a line that does not exist, in a part of the program that never runs, goes unnoticed in BASIC. The compiler's first pass lists it, then carries on:

Pass 1 - Reference Error(s):
500 in: 30
Pass 2 Pass 3
Compiled OK

That is worth reading even though it compiled: it is a mistake waiting for the day line 30 does run.

So the way to work does not change. Write and test in BASIC, where LIST, the line numbers and the error messages are; compile when it works.

Why Games Were Compiled

This was not a curiosity. Compiled BASIC games were sold: the Family Fun disc on this site ships its games as .XBI files with XR.COM beside them, ready to run. BASIC to write it; the compiler to make it quick enough to sell.

The Code

There is no new listing. The work is done at the DOS prompt:

XC MOUSE15
XR MOUSE15

and, for smaller steps, lines 300 and 310 above, saved as MOUSE16, then XC MOUSE16 and XR MOUSE16.

Starting from

LOAD "MOUSE15" from S32.

What you should see

Compiled OK after three passes, a new .XBI on the disc, and the game running twice as fast under XR. With MOUSE16, the mouse walking at the old speed in smaller, smoother steps.

Save this. SAVE "MOUSE16" before you leave BASIC.

The disc is filling up now: MOUSE15 and MOUSE16 with their compiled copies take about 20K. If SAVE or XC runs out of room, erase the early stages you no longer need - ERA "MOUSE1.XBS" and so on - since every later stage has everything the earlier ones had.

Change One Thing

• Run the compiled game and press Q, then N. Where do you end up, and how do you get back into BASIC?
• Change the step in lines 300 and 310 to 2, compile and play. Is there a point where smaller stops being better?
• Compile MOUSE15 twice. Does the second compile ask before it replaces the .XBI?

Exercises

33.1 Time the compiled game with S31's method, standing still and with X held, and compare with S31's figures.

33.2 Spend the speed on smoothness: make the compiled mouse walk in steps of 3 and keep its speed the same as it was in BASIC. How do you know the speed is the same?

33.3 Write a three-line program with a GOTO to a line that does not exist, in a line that never runs. Run it in BASIC, then compile it. What does each say?

Worked solutions are in Appendix II.

When It Goes Wrong

Summary

XC compiles a saved BASIC program into a .XBI, and XR runs it - from the DOS prompt. Mouse In A Hole runs twice as fast compiled, because the work S31 measured - finding variables, working out numbers, finding lines - is done once instead of every pass. Spend the speed on smaller steps and the mouse moves smoothly. The compiler refuses EVAL, its errors carry no line numbers, and it checks lines BASIC never reaches: write and test in BASIC, compile when it works. And it is still not machine code.

Next

S34, Reading A Real Program - a game Tatung wrote in 1984, from the disc, read line by line.