Thanks! Now I just have to figure out exactly where to start.
Can AXE programs run BASIC programs as subroutines? I am more used to BASIC math.

I am saying that because I think BASIC is easier to use with algorithms. Can you "Include" basic code inside an axe program? Like, inline? I don't want too many sub programs.
Oh, I see. How does that work, the last line?
Also, could I have the program stored into an appvar instead? Or something like that?

How different is AXE math from BASIC math?

How different is AXE math from BASIC math?

Axe numbers use 2 bytes to represent an integer from 0 to 65535.  Using different methods, you can modify this range to be from -32768 to 32768, still integer.  And then using a method called fixed-point-arithmatic, you can store numbers from -256 to 256, but with accuracy past the basic integer.  In hex, your Fixed point number would look like ##.##, where the ##'s represent the individual bytes.  The advantages of Axe math is that they are extremely fast, as well as being directly integrated with all of the Axe functions.  The disadvantages of Axe math is that they have limited accuracy, and don't work as well in cases where extremely high accuracy is needed.

Basic math (in regards to using it in Axe) is extremely limited simply because Axe only supports importing and exporting Basic variables as integers.  Additionally, Axe does not support doing mathematical operations on Basic variables, and lots of Hex code would need to be used to either access the arithmetical BCALLS, or run a Basic program.  Additionally, basic math is much slower than Axe math, because the code is not compiled, and instead is being manipulated by the (inherently) slow BCALLS.  The advantage Basic math has is it's high accuracy, from -1*10^99 to 1*10^99, with a decimal accuracy of 14 decimal places.  Little of this is accessible to an Axe program however, since Axe only supports the integer side of Basic math.

In short, I highly recommend that if you plan to make this an Axe program, you learn how to use Axe fixed point math, as it's not really worth it to jump through hoops simply to use the slower Basic version for a small gain in accuracy.

which part? 

Grey is really qutie simple: It is accomplished by flashing two images onscreen, one after the other, in a special way axe handles for you.

You have two sets of screen buffers: The front buffer (the one you always use) and the back buffer (the one you've never heard of.)

To draw to the backbuffer, you simply add the superscript r (under ANGLE) to a drawing command. To display grey, use either dispgraphr or dispgraphrr, for 3 or 4 level grey, respectively. Those are still the angle rs.

for 3 level: If there's a pixel on the front buffer it shows black. If there's a pixel on the back buffer without a front pixel, it is grey.

For 4 level: front off back on = light grey. front on back off = dark grey, both on = black, neither on = white.

You need to have the dispgraphrr happen really often to get good grey though, once won't do it.

You need to have the dispgraphrr happen really often to get good grey though, once won't do it.

how about Full mode?

Could you just draw to the buffers while loading the map and then put the DispGraphrr in a Repeat Getkey()? No animation is needed for golf.

Yes you could, just remember that in order for grey to work, you need to continually call the DispGraphrr function.