If nothing happens, it probably means that the program uses something that isn't supported yet (like files, for example).  And yes, multiple source files are supported, but they must be in the same folder, and for now, named like PROGNAME.8xp.

Also, you can always send me the source code, and I can try to implement what is necessary to make it work.

Edit: I haven't tried it on Vista, so you might want to make sure that one of the examples that comes with Axe works.

Someone wondered if this was possible, and I was curious, so I tried it. Unfortunately, I don't think I will be able to this to an arbitrary program for a while.

-How does grayscale and motion blur work compared to the calc?

Because Axe uses high level commands for grayscale, I am able to just display it perfectly, without having to worry about dithering or blur.

-Also ashbad on SAX chatroom a few minutes ago was being curious about how does the emulator or parser operates with Axe code. To me it seems to require the source code, rather than the compiled executable, but he was wondering how do you emulate the TI-OS and if you were actually including TI-OS code in the emulator (which I doubt you would do, since I'm sure you know copyright stuff very well) to allow the emulator to run Axe programs exactly as they are on a real calc. I myself think it is possible to do an interpreter that would mimic the calc screen behavior to a certain extent like you did, although Ashbad didn't seem so well convinced. He basically found the idea of an Axe emulator useless, which I disagree with (again, maybe it's just that he just has strong biases against everything Axe-related). However I'm kinda curious too, since your emulator emulates Axe programs surpringsly well it seems. Could you give a bit more info about how it manages to run without emulating any part of the TI-OS? In any case, if everything was written on your own and you really use the axe source rather than compiled executables, then that's even more impressive to me, especially that now we can play Axe games without even compiling them.

The compiler program I wrote currently takes Axe source code and produces a computer executable.  This executable does not contain the original source, nor does it contain the executable that Axe would produce.  What it does contain, is native machine code compiled from the Axe source, and hand-written code for every Axe command that is currently supported (Also the calculator screen emulator).  The only thing that it has in common with TIOS is that it contains the data for TIOS's fonts and tokens (This data was created by hand).

-How does it work for Axe programs containing multiple files, such as pictures, sub-programs, etc? Are they detected?

I am already able to compile programs that use multiple program files.  I will definitely be able to support absorbing files, and I will probably be able to support reading and writing files.

-Will in the future it be possible to have a version containing only the emulator, where you can choose the axe project to run, like in any other emulator, for those who have many Axe programs and want to save space? Of course standalone executables are awesome too, since now we can pretty much turn our Axe games into computer games.

I plan to have a single executable.  By default, dragging & dropping an Axe program onto this file will just emulate that Axe program directly, without producing an executable.  However, using command line, I hope to allow you will be able to both produce small executables which require the Axe emulator executable in order to run, and larger stand-alone executables that run by themselves.

-Will the language be expanded in the future so if, for example, below the Axe source header we put something like ANOVA("RES":320x240:Full), your exe file uses 320x240 full screen resolution instead of 96x64 windowed and ANOVA("COLOR":256) if one wants Pt-On/Off/Change to display sprite data in 256 color mode instead of 2 (monochrome) and to allow Line/pxl commands to be useable with colors too That would basically allow someone to create actual computer games by using Axe language, so they don't have to learn a new language if they ever quit calc stuff but still want to make old skool 2D games like Mario on the computer. TokenIDE/SourceCoder could still be used to write programs for the time being, although if both won't let people create 8xp files larger than 24 KB or even 64 KB, that might be annoying.

I can't say for sure since I am currently focused on getting native Axe commands to work, but it is definitely possible.

@Quigibo: I would like to be able to have options (such as clipped/unclipped lines, accurate/approximate sin/cos, optional extra routines) so that I can improve some things while still being able to be as compatible with Axe as possible.

@Xeda: Even giving every DispGraph a 10ms delay, many games run way too fast to be playable (And this is with very unoptimized drawing code, etc. (Although the generated code is already being optimized quite a lot)).

On a side note, I do have linux executables, but the file was too big to upload.

:Lbl Count
:0→r3
:pt-Get(r1,r2)
:For(8)
:{→r1}
:While
:Select(,r3ʳ++) and (-1) .subtract not negative
:End
:r1+1
:End
:Return r3


"Pic0" is actually 3 bytes long (not including the terminating 0).

Since the first two bytes are always the same, you could do:
"Pic0Pic1Pic2Pic3Pic4Pic5Pic6Pic7Pic8Pic9"→Z
"Pic1"→I
GetCalc("varP")→Q
float{Q}→P
{P*3+Z+2}→{I+2}

But an even better method would be:
"Pic1"→I
GetCalc("varP")→Q
float{Q}→P
(P?-1,9)→{I+2} .Pic1-Pic9 is 0-8, and Pic0 is 9.

Edit: Not enough parentheses. Also, that's subtract 1, not negative 1.

Select( is useful for saving values around an expression, but it does not allow saving values around a block of code.  It would be nice if there were a block statement that saved variables on the stack.

For example:
:Save A,B,C
:
:End
would save A, B, and C and restore their values at the End.

It would also be useful to have:
:Save A,B,C
:
:End C,A,B
which would store whatever the value of A is at the beginning of the block, to C at the end of the block, etc.

Hopefully, making it a block statement allows you to disallow jumps and make Return work correctly, like with For(EXPR).

Also, some optimization-related requests:

For(Xʳ) or For(X)ʳ which would loop X^256 times (More optimized than For(X^256)).

[alternative to calc84maniac's post]
A -ʳ operator that performs "reverse-subtract".  For example A-ʳB is the same as B-A.  This is useful when you want something like A-(B*2) which can be replaced with the more optimized B*2-ʳA.  This might also be useful for the other order-dependent operators.

I went with the other order because of the current command: Bitmap(X,Y,BMP,BUF,MODE). Although, I have to admit that the other way makes a lot of sense.

CircleF( is on the Vars Window menu for now.

CircleF(X,Y,R)	Draws a filled circle with center (X,Y) and radius R on the main buffer.
CircleF(X,Y,R)r	Draws a filled circle with center (X,Y) and radius R on the back buffer.
CircleF(X,Y,R,MODE)	Draws a cleared/inverted/filled circle with center (X,Y) and radius R on the main buffer. Mode 0 is clear, Mode 1 is invert, and Mode 2 is fill.
CircleF(X,Y,R,MODE)r	Draws a cleared/inverted/filled circle with center (X,Y) and radius R on the back buffer. Mode 0 is clear, Mode 1 is invert, and Mode 2 is fill.
CircleF(X,Y,R,MODE,BUF)	Draws a cleared/inverted/filled circle with center (X,Y) and radius R on the specified buffer. Mode 0 is clear, Mode 1 is invert, and Mode 2 is fill.