They being the programs that you compile from Grammer source code into Grammer executables. Also, I'm grading a Cemetech Contest 8 entry that uses Grammer! Huzzah.

Awesome! Also, Grammer does not compile source (yet) into executables. For Grammer, source==executable, (which is why you need the Grammer app on the calc, as well). Speaking of Grammer 2, I have an update. I am currently working on even better implementations of grayscale and it works nicely already. Actually, I rewrote the routine to update the LCD and it is now faster and updates in 3-level gray at all times. As default, though, the gray buffer and black buffer pointers point to the graph buffer to maintain a black/white appearance. To change the buffers:

Disp <<address>> will point the gray and black buffers pointers to <<address>>. This is to maintain back compatibility. Essentially, this exits grayscale.
Disp '<<address>> will point the black buffer to <<address>>.
Disp ^o<<address>> will point the gray buffer to <<address>>.
ClrDraw[<<address>>] will clear the black buffer if the <<address>> argument is not present, else it will clear the 768-byte buffer at <address>>.
Adding an extra argument to the Line( routine will draw a rectangle at that buffer. I plan to add this ability to all the other drawing commands as well, so they can draw to the gray or black buffers as needed.

Also, I added in two new options for Fill( to either set the screen or part of the screen "on fire."
Grammer 2


So now I have combined particles+fire, now I need to combine that with grayscale >.>

That is....cool!

would it be hard to get a grammar like programming language on the prizm?

For the Prizm, I feel like we'd almost be better off with a very lightweight Python interpreter or something, since we have the processing power and the memory to fit such things.

Edit: Also, Xeda, thanks for keeping up your hard work, and thanks for ceding to my screenshot request.

I have wanted and intended to port Grammer to the Prizm, but I am making no promises.

@Kerm: It was no problem, I understand Is linking to images on other sites any kind of burden? I often link to lots of screenies :/

This code seems to not work and I can't see anything wrong I have done.


Code:


it works for a while and it kinda stops (idk if it froze or not, but it let me quit vio ON button)

No, linking is great and not a problem at all. I'm miserly with the disk space on my shared hosting; I've managed to keep Cemetech around just over a gigabyte of data for over a year now.

Ah, nice And for Yeong, the issue is that C is sometimes 0. To fix it, try randInt(1,12 and For(A,1,C I added in an error handler so that when it got stuck and you break it with ON, it stores the value of C to the OS var C so you can check it out To set up the error handler, use solve(3,Lbl "<<labelname>> and at label name you can do this:

Code:

I am now working on the last stretch of Grammer 2. I will not have internet in one week, so i hope to have everything tidied up by then

-I am rewriting the readme and tutorial
-I am making any final additions and bug fixes
-I have to finish the documentation for assembly programmers who want to use the Grammer calls

So for the past few hours, I have been working on the main menu. The menu items now all do something, so they aren't just place holders.
Exit will exit.
Hook will toggle the token hook
Appv will toggle between showing programs or appvars
Asm will only display programs with an assembly header (only compiled assembly programs).
Gram will show only programs with a Grammer header. For interpreted programs, this is .0: and for assembly, it is BB6D55C9.

As a note, this will not run BASIC programs. If it runs a non-asm program, it is run as a Grammer program, regardless of the header (this is because you can create subprograms for Grammer programs that don't have the header).

So here is a sloppy screenie:

And the download: (just the .8kx)
Grammer.8xk

Some more work that I have done with Grammer lets you draw lines using patterns. Merth has been bugging me to add these, so I rewrote the line drawing routine to allow patterns and support full clipping I finished it yesterday and I have since found out that raycasting in Grammer code is not very fast :/



No release quite yet, though, the internet is rather buggy for me and uploading takes close to forever :/

I remembered a feature yesterday that I never added to Grammer 2, so I am trying to figure out how to implement it. Basically, the feature is just a parser hook for Grammer. I have two ideas for implementing it:

1) Make it so that apps can install such hooks to Grammer. This way, apps can extend the command set.

2) Make it so that unrecognised tokens are directed to program code (similar to how errors can be redirected and handled by the program). If I do this option, I will use the token "?" as a pointer to the program code so that the programmer can parse arguments as needed. If I do this, programmers will be able to use functions that can have arguments passed to them easier.

Also, I have about 100 more bytes to work with. I am going to work on option 2 first, but if there is overwhelming requests for option 1, I will try to add that, too

That looks more like Mode7 than raycasting to me, to be honest. But still cool stuff.

With regards to your last post, option 2 sounds good enough to me; good luck implementing it.

Ah, okay. If I had turned those squares into cubes, then would it have been raycasting? (That was what I was working towards when I made that, originally)

As to the option 2, I have it almost working. You can now treat a subroutine as a function that you can pass arguments to by using prgm( instead of prgm. I am having a slight problem with passing the unrecognised tokens to the error handler. Well, actually, I am having issues with exiting the error handler because Grammer backs up Ans and restores it. This means that you cannot return a result in Ans :/ I am trying to make some way to signal Grammer not to restore Ans.

I have completed the features mentioned before, but I also realised that I never showed off one of my other commands that I added at the end of May. The Input command looks very snazzy at this point (a huge improvement over the original). You can add an argument to the Input command to draw text after what you are inputting. Since Input starts taking input at the last on screen text location, input looks great for functions! Also, I added in highlighting, DEL and Clear now delete the whole token, and only keys that correspond to a token register.



Anyways, I thought it was worth some eyecandy
The code for that program in the screenie is:

Code:

Some eye-candy indeed! I'd like to know more about how you wrote that variable-width font text input routine, especially considering how many headaches I dealt with the summer that I wrote the DCS GUI API and had to wrestle with the intricacies of backspacing a character in the middle of a line that might affect several lines down the screen. It looks great as shown.

Oh, there is no handling for variable width font. That will be for a future version, but I didn't even attempt it here. This routine just sticks with the fixed width font (4x6). However, since Grammer stores the string in a buffer, it can check what token it is deleting, find the width and height of the string in pixels, then it could simply erase that region of the screen. Since Grammer uses its own font routines and syntax for storing fonts, this wouldn't be difficult except for the fact that there is about 30 bytes of code space left.

Necro-update.

I lost a good chunk of work back in 2012/2013 and that really helped to kill the project. A little over two years ago, a programmer named Hans Burch emailed me some dissected (and slightly modified) source that I'm assuming they got via disassembly and comparing to old source code.

While the project is pretty much still dead, I made some modifications in 2016, and again over the past couple of days. It's not compatible with Grammer Assembly programs as the jump table is removed to make room, so it is not backwards compatible.
2016
▫ I added an experimental command called module (the ►DMS token). It allows you to access a custom function from the Grampkg appvar, and would be useful if I want to expand the functionality of Grammer. Realistically, I'd want to put functions that are not speed-critical there. Don't count on this being a permanent feature, just for experimentation.

▫ I removed the jump table to make more room
▫ I got rid of the custom VAT searching routine and now use the OS routines. No need to re-invent the wheel.
▫ I got rid of the 32-bit multiplication routine that wasn't even being used, not even via the jump table for Grammer Assembly programs.

5~8 Nov. 2018
▫ I did a lot of cleaning up of the source code.
▫ Without the jump table, I decided to remove some code that was only accessible that way (mostly math routines intended to make the lives of assembly programmers easier).
▫ Re-invented the wheel by making custom VAT traversal code in place of _FindAlphaUp and _FindAlphaDn. I wanted to make the start menu more responsive and at ~100 programs on my calc, the OS routines are far too slow. This is in part because I want to make a better start menu. for the App
▫ Added in code to throw an error if a Grammer Assembly program is run. Without the jump table, they'd likely crash.
▫ Version number is going to be sensible now, starting at 2.50.0.0
▫ Various minor optimizations. I'm a bit more mature in my programming now.
▫ I cleaned up the filtering code for the main menu. It was pretty ugly, and now it's pretty straight-forward. In general, I like how the main menu works a lot more, but it needs more work (in my opinion).
▫ I added key debouncing to the main menu that allows you to press and hold a key instead of having to press multiple times to get to traverse the program list.
▫ I completely rewrote the psuedo-random number generator and fire code. Haven't even tested it.
▫ I probably did some other major modifications that will crash your calc.

What I want to do:
▫ Re-re-invent the wheel. With the VAT being sorted, as long as I keep it sorted as variables are created, then I can optimize the VAT search routine that mimics _ChkFindSym. It might not be worth it, actually.
▫ I want a scrollable menu. I've wanted it for years. It's closer to happening with the improvements under the hood, but will require a lot of extra work.

I have 486 bytes of space, so I could add in the jump table and the associated routines that I removed, but the room is nice.
Download 2.50.0.0 (no readme or anything)

I have discovered today Grammer and it's very impressive.
I am lucky, i still have my ti-84plus.
Thank you a lot Xeda112358

PS: a little translation joke:
Grammer know how to do a good coffee
(in french "Grand-mère sait faire un bon café")

Hahaha, thank you for the language joke! Also, there used to be a French tutorial, but it seems to have disappeared

---

In other news, modules have better support, allowing third-party extensions to the language (it's not well documented, though). I made GFLOAT, which interfaces with Floatlib, providing some float support. I have since started to include float support in the main app, making Grammer a 2 page app. The readme has been updated and reorganized, and includes more detailed info on how to use floats in Grammer. I think you can reasonably expect about 700 to 1000 float operations per second, but maybe higher. I can't remember what my results were.

Download