I have one word about this: woah. Can't wait till it's done.

For making variables, do you mean using tokens that aren't used too often? If so, maybe dbd(? Perhaps int(?

Forgive my ignorance, but this (Grammer) is an assembly library for TI-BASIC, right?

Actually it is a programming language as opposed to a library. An assembly program interprets the code instead of the BASIC interpreter. It is probably confusing since I use the TI-BASIC tokens (for now).

I have one word about this: woah. Can't wait till it's done.

For making variables, do you mean using tokens that aren't used too often? If so, maybe dbd(? Perhaps int(?

Well actually, I have been working on another side project for somebody and the project required that I make my own variables. The way I would do this with Grammer is to create a temp string to store variables such as strings, sprites, pictures, lists, et cetera. I have the format for the vars created already and it allows all the vars to be named, to.

Basically I just mean that I have to make variables that are not the BASIC vars. It will let Str1 be seperate from the Str1 in BAIC, for example.

I'd second int( or perhaps expr(.

lol looking through the catalog, you could make ►nom( do something.

Hehe, I like that one I will try to figure out something for that one... maybe an easteregg for ►nom(►nom())

Now aside from that, I got myself another calculator, because I have been thinking of a fun little link protocol routine that will allow for some seriously cool multi-player stunts... if I can figure out how to use the USB port I have been working with the serial port, but I can only work on WabbitEmu since I do not have a serial cable. Anywho, to give an idea of some of the link commands that I want to add, I want to:
-Send code over from one calc for the other calc to execute
-Send Grammer vars and OS vars
-Force recieve vars or info
-Read/write memory from other calculators
-Synchronize LCDs so that both calcs display the same thing

This will allow for some great multiplayer games, yes? It would require both calcs running Grammer, but it would be a pretty powerful command set... if I can figure out how to use the USB

Quote from: buttsfredkin on July 19, 2011, 04:21:19 pm

Forgive my ignorance, but this (Grammer) is an assembly library for TI-BASIC, right?

Actually it is a programming language as opposed to a library. An assembly program interprets the code instead of the BASIC interpreter. It is probably confusing since I use the TI-BASIC tokens (for now).

Like Axe?

Quote from: buttsfredkin on August 08, 2011, 10:53:45 pm

Quote from: Xeda112358 on August 08, 2011, 02:54:29 pm

Quote from: buttsfredkin on July 19, 2011, 04:21:19 pm

Forgive my ignorance, but this (Grammer) is an assembly library for TI-BASIC, right?

Actually it is a programming language as opposed to a library. An assembly program interprets the code instead of the BASIC interpreter. It is probably confusing since I use the TI-BASIC tokens (for now).

Like Axe?

Yes. (Methinks)

Axe is a compiled language, and Grammer is an interpreted one.

Axe is a compiled language, and Grammer is an interpreted one.

Will it be able to compete speedwise with Axe and/or ASM? Cause thats cool.

ReCode was as fast as Axe. If not, possibly slightly faster (from what I saw)

If Grammer is based off of ReCode, then yes. As fast as Axe.

Theoretically, Axe should be faster, but I digress.

Grammer is WAY faster than TI-BASIC, and that's what counts. (As both are interpreted languages)

I think speed wise, Axe should be a little faster, but memory-wise, Grammer code should be able to get the job done, smaller. However, I have plans for "tokenisation." This will be kind of like compiling, but not really. Even so, this will make Grammer about as fast as Axe or Assembly while possibly using less memory than a TI-BASIC program. What it would do is convert all numbers, values, offsets, and arguments directly to hex, that way it no longer gets converted on the fly and label names and comments can be taken out.

As a side note, the only work that I have put into this in a while was only to allow the user to use hexadecimal or decimal inputs. I don't think I have added anything else...

Back to the USB topic, I was looking through the USB code in the OS and jeez is that a lot to take in. I now wish I had a cord for the serial port that worked Anywho, USB communications would be pretty awesome, but it looks very complicated (the way TI does it). I thought it would be simple and be like the serial port except sending more bits at a time !_!

Thanks I think I learned a lesson, though-- Even if I do not have the coding experience for a feature now, I should at least try to give the possibility that I will have the ability in the future. I think with ReCode/BatLib, I should have at least allowed the user to input pixel coordinates even if it couldn't draw to all pixel coordinates... At the moment, I am looking at some of the documentation and I will be saving it to my computer for when I do not have internet.