no, comments are two slashes at the beginning of the line.

I'm confused now XP

ah. XP
I was scared for a second that now Grammer's AI had advanced enough that it can compile its own code now

I am not finished updating, but it has been a while since the last update so here goes. Since the last version, I have added:
     length(<<varname>>
     length('DataStart,Size,LineNumber[,linebyte
     inString(Offset,SearchStart,SearchString
     conj(Duration,'Value
     conj(Duration,DataLoc,DataSize
     conj('Time,'Freq Uses the Axe sound routine.
     conj('Time,DataLoc,Size Uses the Axe sound routine but it reads data directly to save time (intead of converting numbers on the fly). Size is the size of the data in words, not bytes.


Some stuff that I haven't mentioned in previous posts:
     >Frac is used to factor and test for primality. Its outputs are the smallest factor in Ɵ' and the result of Ans divided by that in Ans. So for example, if the output Ɵ' is 1, that means the number is prime. If you did this:
221>Frac
Ans would be 17 and Ɵ' would be 13.

I have also added support for running assembly programs with Grammer. So if you want to run an assembly program from the homescreen without Asm( in front of it, you can. Plus, if you do it that way, you can run it from Archive, too. On top of that, I decided to detect ION, MirageOS, and DoorsCS programs. If you try to run those, you will get a custom error message.
The real use, though, is that Assembly programmers can now build assembly programs using a special Grammer header and they can use the calls from Grammer. Unfortunately, while there are over 100 available calls, I have only had time to document about half of them.

So I hope y'all enjoy the new stuff, I hope you make new proggies, and I will see if I can get any useful assembly programs going. I won't have internet for a little while, so I may not be able to respond immediately, but feel free to ask questions.

I feel like I missed something other than the gravity engine buried somewhere in the program...

Okay, so three things:
1) I forgot to mention that I added the commands and , or , xor , and not(. These just perform the basic bit logic operations. For example, 5 and 6 will return 4
2) I added a new particle command that will allow you to convert a rectangular region of the screen to particles.
     P▶Rx('Y,X,Height,Width
3) I have a new update that I am sure will be loved, but may cause yeong and Sorunome to go back and add in some more delays to their programs. Maybe.

Pretty much, I have been working for the past 2 days rewriting the parser and it was worth it. I made the number converting routine about 2.5 times faster for starters and I decided to use a lookup table to jump to commands more quickly. The net effect? Some programs run as much as 8 times faster. Don't believe it? I admit that most programs won't get that kind of a speed boost, but algorithms definitely get a huge speed boost. Pretty much, everything except DispGraph and Pause have been affected (and even those get about a 500 cycle speed boost).

So what kind of a speed boost should you expect? Well, the games that I have toyed with work in 6MHz at the speed you would expect out of 15MHz, so they work about 2 to 3 times faster. I think Tetris didn't get too much of a speed boost, though.

[offtopic]
5 or 6   = 7
5 and 6 = 4
5 xor 6  = 3
 uses 3,4,5,6,7
[/offtopic]

Thanks Also, I would like to note that I am debating on adding a 32-bit mode. It is unlikely, but I already have the math routines coded for most of it (adition, subtraction, multiplication, division).

Oh, and I mentioned that new particle command? Here is a screenie