That is okay, this is more because Yeong asked me to release this I wonder what yeong plans to use this for o.o

So, update time Now that Grammer actually uses grayscale as default, I made a much nicer version that uses grayscale properly Also, I figured out why the checker pattern wasn't looking fast enough... I had Wabbit's color up to 2 shades. On a real calc, it shows it as perfectly gray with no flicker. It gets about 86FPS at 15MHz.

The new version features 3 shades-- black, white, and gray. You now draw with a resizable cursor and it runs at 6MHz.

Controls:

• Use the arrows to move the cursor
• Use 8,2,6,4 to resize the width and height of the cursor
• [Enter] will set the region as black
• [Del] will erase that area
• [2nd] will set the region to gray
• [Clear] will clear the screen
• [Mode] will exit the editor

I am wondering if I should add a save file or not so that people can load and save their pictures... Naturally, it would require 1536 bytes per image, though I could even make it so that it uses OS pictures, too. I have resized them before, so I know it is doable. I think I could even get it so that the OS would read it normally, but you could use it as a grayscale pic for Grammer.

To be clear, this is actually good grayscale, not the flickery stuff I did before

Pretty much, my program works like this to get other forms:
There Surviving, Rebirthing, and Dying conditions based on the number of live pixels. Since there are at most 8 pixels, I can use 9 bits (for zero as well). If surviving is S, rebirth is R, and dying is Q:
S=4 (000000100b)
R=8 (000001000b)
Q is computed by using not(R or S

So if there are 3 pixels around, I do 2^3 to get 8 as a mask. "8 and R" returns nonzero, so I know it gets reborn. That, by the way, is CGOL
The main problem is that I haven't released the Grammer version with e^( which computes 2^n, but here is the code:
If Q and e^(H        ;H is number of pixels around the cell
Pxl-Off(A+1,B+1,Z
If R and e^(H
Pxl-On(A+1,B+1,Z

EDIT: Back from class, I didn't see your edit
So, for the sieve, you can pixel test a number to quickly figure out if it is prime It only works up to 6143, though

Also, for a few other memory saving techniques, you can try using If !pxl-Test(A,B instead of If 0=pxl-Test(A,B

Good luck! I wish I could work out better animations

To display an ascii char, you do something like:
:Text(0,0,'43

To display a token using the hex value, you can do something complicated like this:
:pi8478→A[(2B00
:Text(0,0,A

After working on this topic (and still failing), I have added a few useful functions. First, e^(n now performs 2^n (and the token hook changes this accordingly). This is a function that will likely remain as I have wished it was included for a while. The next thing I added was probably even more important and useful for many projects-- pixel testing boxes. This is especially useful for collision detection and I plan to add more versions at some point. The method I have added pixel-tests the border of the given rectangular region and returns the number of set pixels. (I plan to add methods for pixel-testing filled regions, as well)

It uses a modifier of pxl-Test( and similar arguments to Line(, so here is an example to check the perimeter of a pixel at (Y,X):
pxl-Test('X-1,Y-1,3,3,0    ;0 is the type (test the perimeter)
A value from 0 to 8 will be returned I am putting this in Feature Requests because I was wondering what folks thought and if they had similar suggestions before I release it. Also, I still have to work on it a bit more. It works for my purposes, but it still needs to handle screen boundaries better.

Oh, wow, that would be really cool! I do not think Grammer will be able to do the whole screen quickly (I have made prime sieves using the whole screen and it could only get about .5FPS). However, a 32x32 portion of the screen or something sounds like it would be pretty quick! As for getting the cursor to run as well, that won't be difficult at all, fortunately

So, to display the cursor and not effect the screen:
<<begin loop>>
<<code>>
Pxl-Change(Y,X
DispGraph
Pxl-Change(Y,X
<<code>>
<<end loop>>

So pretty much your idea. That is indeed the fastest way, but you only need to use DispGraph once per cycle. Good luck!


EDIT: Also, for more ideas, you can store the graph screen to another buffer to compute each frame. For example:

(This is now a way to do CGOL, but it is slow )
.0:Return
Full
31→G           ;We are using a 32*32 region because 32 is a power of 2
pi9872→Z      ;use the actual pi symbol
pi9340→W
Repeat getKey(15
DispGraph
Fill(8,Z          ;Copies the current graph screen to the buffer at 9872h
For(A,0,G
G and A-1→C
G and A+1→D
For(B,0,G
G and B-1→E
G and B+1→F
Pxl-Test(C,E
+Pxl-Test(C,B
+Pxl-Test(C,F
+Pxl-Test(A,E
+Pxl-Test(A,F
+Pxl-Test(D,E
+Pxl-Test(D,B
+Pxl-Test(D,F→H
If <2 +H>3
Pxl-Off(A,B,Z
If H=3
Pxl-On(A,B,Z
End
End
Disp Z
Fill(8,W
Disp W
End
Stop
EDIT2: I have been periodically editing this between chores/classes. The current version gets only about .25 frame per second
Changing 31→G to 15→G for a 16x16 region can do 1 FPS
EDIT3: Because of this program, I have added a new command to compute 2^n (I used the token e^(). With it, I made a customisable version (so not just Conway's Game of Life). I also have wanted for a very long time to add a command to pixel test the border of a region, so this shall give me the excuse

I am curious, what choice do you think was best?