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

Yeah, it isn't exactly the best example of speed for Grammer, but I am trying to figure out what is being so slow. I can plot 1000 random pixels in about a second, but testing should be even faster. For 32*32, that is only 1024 pixels. I am going to check again because I was expecting to get maybe 6 FPS, originally, not a dismal .25 FPS.

EDIT: Okay, I took out the code making it wrap around and took off about 25 % of the time it took. I am testing with 64x64 which is much slower. It is now 11 seconds for one frame, so 32x32 should take less than 3 seconds. Not great, but I sped it up.

EDIT2: I added a new pixel test option to Grammer to test a rectangular border. This should be very helpful for collision detection in games and my gravity engine as well, but also manages 1 frame in 1.5 seconds.  I am still trying to get it faster. At 64x64, it takes about 6 seconds to generate a frame.

Awesome! I was really really tempted to just add CGOL as a Fill( command, but I wanted the fun of coding it in Grammer. I felt like I would be ripping you off if I just added a command, but I really like the idea of UnD. Would you be okay with me really adding the command? I would make it just a general 2D cellular automata like my program used (which has a rule for CGOL).

Anyways, for the prime sieve, I made it in both Grammer and TI-BASIC using a similar idea. The main difference was that Grammer automatically splits up the remainder and whole value and uses a 64*96 screen. So in Grammer, I figured it had 96*64=6144 pixels to work with. So the highest prime you would need to factor out would be 73 (square root of 6144 is 78, the next lowest prime is 73). So the code:
Fill(0
For(A,2,73
If pxl-Test(0,A
Then
A+A→C
0→D
For(B,C,6144
If C>95               ;for wrapping to the next line
C-96→C:D+1→D
B+A-1→B            ;we want to increment every multiple of A and For loops will add 1 automatically
Pxl-Off(D,C
C+A→C               ;get next increment
End
End
DispGraph
End
Stop
This will result in black pixels representing primes (except for 0 and 1 which stay black, though they are neither prime nor composite). Of course, there is the command >Frac that can be used to test if a 16-bit number is prime or not, but that also takes out the fun of a sieve

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

The values are actually RAM addresses. The calculator has 3 buffers the size of the graph screen (768 bytes).

pi9340 is the graph buffer that the OS uses

pi86EC is a 768 byte buffer that Grammer makes use of for temporary operations and whatnot. You are probably safe if you use this to very temporarily store a screen here or something. It gets used by text conversion routines and I believe that is all, now. I have been trying to make Grammer not use this buffer, so I will have to rewrite the text display routine. Pretty much, if you want to use this, you can probably start at pi87EC and be safe with 512 bytes of RAKM there

pi9872 is AppBackUpScreen. At the moment, Grammer initialises this with the first two bytes for the particle buffer. If you are not using the particle routines or you have set your own buffer, you can use this with no problems.


Also, I am about to test my first attempt at a 2D cellular automata as a Fill( option. I am sure it won't work this time, but if it does, I am hoping for 6 to 8 FPS in 6MHz (though it might be much slower ).

EDIT: Yeah, my anticipations went a bit too high it didn't work, but I am sure it only needs minor adjustments. It only gets about 2.3 FPS at 6MHz and about 6FPS at 15MHz

You will want to use this version which is a prerelease, actually http://ourl.ca/13558/288236 If you want, here is my current version of the program... It is a bit glitchy and I still have to tease out the specific bugs (it will draw in places where it definitely should not).

EDIT: To answer my own question: Yes, yes it will. I installed your hook, than the DCS7 hook. Ran a BASIC program, worked. Ran a Grammer program, didn't work. Installed your hook, ran a Grammer program, worked. Ran a BASIC program, didn't work. Maybe you and Kerm talk a bit and get a home-run hook alliance going?

Same for zStart