Hmm... I don't see any syntax errors... Are you sure you copied it correctly?  And did you upgrade to the newest version?

Cool!  I can't wait to see this.  Will macros eventually be supported, because those are really useful!

I'm just wondering, is there really enough memory on the calculator to write decently sized assembly source code?  It would probably have to be saved as groups or on USB since even a small project often takes more room than the entire free ram.  Although this is probably for simpler things I assume, like writing tools, routines, and maybe even small games since large projects are far easier to write on the computer.  And when you take into account the time for scrolling though the program, typing things out, and assembling, you'll definitely have to come up with some type of efficient system.

Good luck, hope this gets completed

Numerical and character input might be a possibility in the far future, but I doubt it will be anything like basic.  However, it may be possible to embed actual BASIC code into axe itself, kind of like how you can embed assembly.  Not sure if it will work, but I'm reading up on it.

The ++ and -- are already supported.  You just write them as +1 and -1.  The compiler automatically optimizes them to the increment.  ElseIf is a possibility, I forgot about that.  A FPS counter is something you could do with interrupts.

Yeah, wabbitemu does sound a bit different than on the calc, I think the calc is a bit cleaner.  But mostly it heavily depends on what the time delay for the sound.  The longer the delay, the better the sound sounds.  Since the delay is in units of about 5-10 micro seconds, you should have pretty long delays.  On the other hand, you probably can make an earthquake sound if you lower the frequency (raise the wave value).

By the way, this routine is a near identical copy to what I used in Pyoro.  In Pyoro, each tone would have had 3000 as the "TIME" argument.  I'm sure someone here will make a routine that plays sound from a music file in ram.  You can get the notes for Pyoro in its music.inc source code.

New update!  I can't believe I added so much, I guess most of it was simple.  Anyway, you can name your programs now and I think the most useful added feature is the double byte reading and writing.  So if you have a number larger than 255 you want to store, like a score for instance, you can store it to memory using S->{L1}^r.  That means it writes the first part of the number to {L1} and the second part of the number to {L1+1} so the entire 2 byte number is saved.  Same goes for reading, you can read the entire byte.  Be careful though, because when you have arrays and things make sure you step by 2 instead of 1 since each number takes up 2 bytes.

Also, I reworded almost the entire commands list to make it less technical.  If you have a specific low level question about a command I can answer it here because I intentionally left out a lot of those details to make it as simple a definition as possible for those used to higher level languages.

It should be 128*sin() so that the number fits in a single signed byte.

Theoretically, you can append buffers to the end of your executable so that they use their own self modifying code as extra buffers.  This is fairly easy and straightforward to do.  Hmm... I don't have an "empty data" command yet... I should add that, it would make this kind of thing easier and it gives another alternative to if you run out of free ram.

This looks like a pretty cool game!