Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Floats are going to be a great addition to Grammer Smile
I've been fixing more bugs added at least one new command, and modified a few more. Of note:

    ▪ ▶Dec has been added to convert text to a float. This is particularly needed for user input (for example, with the Input command Razz). I struggled with this, because I want to add in an int-to-float conversion, but this seemed more important. I'm still not sure what token to use (or if I should just modify the ▶Dec token for both).

    ▪ I documented a bunch of the available float commands. Many of them have been available, but are still incomplete so I didn't want to document them.

    ▪ e and π can now act as floating-point constants. Of course, π is also used to prefix hexadecimal numbers, so this only works when π is not followed by a hexadecimal digit.

    ▪ I absorbed the Grampkg appvar into the main app for now. The appvar was made as a way to extend Grammer as available space got small. Now that I am using two app pages, this isn't necessary. The way it is set up, the appvar code is literally just sitting inside the app, so it still interfaces like the original appvar, just faster to locate.


Here is a screenshot that uses the ►Dec token to convert user input numbers (so that they don't need to use decimals as would be needed for expr( ):


Download Grammer v2.50.2.0
Weirdly enough, Grammer hasn't had real stack operations yet. In my most recent updates, I added two stack variables and three stack-related commands.

Initially, I wanted these to be mostly used for subroutines and parameter parsing and what not, and so I went with some tokens that look pretty similar to the word "parameter."

    Pmt_Bgn defines the base of the stack. When storing to Pmt_Bgn, the stack pointer will be reset to this value, too! In Grammer, this stack grows upward. The current default is saveSScreen+256, but this may change in the future.
    Pmt_End defines the top of the stack. The current default is saveSScreen+768, but this may change in the future.

These tokens are found in the finance app. Just press [up] on the first page and they are there.

Please note that saveSScreen is used by many routines as a scrap location. Inline assembly opcode snippets are copied there, the Menu( command stores info there, module routines are copied there, and I'm sure a bunch of other things. If you aren't using these routines, between push and pop operations, then you should be fine, otherwise your code might be unpredictable and you should relocate the stack to a safer location.

As for commands:

    Param uses the ? variable as a pointer to parameters and pares them. For example, in a subroutine called with prgm(Z,0,1+3,2, then ParamA,B,C will set A to 0, B to 4, and C to 2. This is a much cleaner and easier than the existing method.
    Param' pushes values to the stack. This takes expressions as arguments and is comma delimited.
    Param° pops values off the stack. This takes variable names as arguments and is comma delimited.

The Param token is in the mode menu as "PAR" or the first catalog entry under P.

So as an example of swapping vars:

Code:

Param'A,B
Param°A,B



Finally, we now have the ▶Nom( command which actually operates like a code block so it needs a matching End. It basically takes a list of variable names and pushes them to the stack. When its End is reached, it restores those variables.

Code:

:▶Nom(x,y,z
:<<do stuff>>
:End


While adding this in, I actually found a long-standing bug in the code that finds matching End tokens. It didn't skip over both bytes of the two-byte tokens, so if the second byte happened to be the same as, say, a While token, then it would look for one too many Ends.


Download v2.50.4.0
Grammer has undergone a bunch of updates!



As I've been updating z80float, I've been updating the float routines in Grammer. Since the last update here, I've also added a bunch of new routines. Here is a quick summary of changes for floats:

▪ sin( and cos( now have range reduction!
▪ division now has proper underflow/overflow detection
▪ Fixed a bug with the logarithm routines when the input's exponent was 0 (so on [1,2])
▪ Added in mean( to compute the mean of two numbers.
▪ I switched e^( to perform exp(), not 2^x (see note below)
▪ Added in 10^(, tan(, sinh(, cosh(, tanh(, sin-1(, cos-1(, tan-1(, sinh-1(, cosh-1(, tanh-1(.
▪ rand is a more mathematically correct!

I also changed the token hook so that e^( was no longer renamed 2^(. The regular routine still performs 2^n, but the float routine will compute exp(x).



I also rewrote the Input and Menu( routines, and updated Pt-Off( to allow wider sprites!
▪ Input does away with the highlighted input, but now has a blinking cursor.
▪ The Input buffer can now be relocated and resized! Below is a screenshot where I relocate the Input buffer to a within the source code, and limit it to 9 bytes (8 bytes plus a null byte).

▪ The two new "commands" are →Input (Sets the location of the input buffer) and →Input' (Sets the size of the input buffer).
▪ Pt-Off( draws a clipped sprite to pixel coordinates, but before now has only supported 8-pixel wide sprites with a width field reserved for future use. Well,


▪ Menu( is now a little more memory-friendly, and will scroll if there are too many items.
▪ Menu(' is a new menu routine where you supply pointers to two subroutines-- one routine that takes an index and returns a pointer to a string, and another that takes an index, and generates an output when the user selects an item.

As an example of the new Menu(', here is code that displays a menu with items names "ITEM A" to "ITEM Z".

Code:

Lbl "GET→A
Lbl "SEL→B
Menu('"Title",2,34,59,27,A,B→M
Text('0,0,M
Stop


.GET
→X<26
If !
End
"ITEM A→Z
int(Z+5,X+65
Z
End


.SEL
+1
End

And this is what it looks like:

For this one, each of the items is generated on-the-fly by a Grammer subroutine, and that contributes to it's slowness. It has to execute the subroutine every time the user moves up or down, as well as whenever an element is generated. In this implementation, every time the menu scrolls, it has to generate all of the elements from scratch. I might make it just scroll the contents up or down and generate a single item instead of the whole thing, but that's for future work. At least Grammer already has code for shifting rectangular regions of the screen up or down!.


Anyways, for the latest updates, check out the GitHub repository.

Download v2.50.6.1
Good to see that you keep working on Grammer 2 Smile
Thanks ^~^

i have a minor update in regards to the menu routine. The menu routine is now more efficient in scrolling. I did actually take advantage of the "rectangle shift up/down" routines so now it makes fewer calls to the Grammer parser, thus improving performance.
Here is what it looks like now:


I also remade the rectangle routines. Combined, they are 112 bytes larger, but it is cleaner code, they use 4 bytes of already allocated RAM instead of 24 bytes of specially allocated RAM, and they don't use shadow registers (so they doesn't need to disable interrupts). As well, I added two new methods-- they both invert the border, but one clears the inside, the other sets it to black. I have no idea why that might ever be desirable, but I have all the other methods of setting the border and fill to black/white/clear/invert, so why not? (and it didn't add much to the code).

For those who need the latest, Download (v2.50.6.2)
I added in filled circles to Grammer, so now there are 12 circle methods in all with various combinations of border and fill black/white/invert/clear:


Download v2.50.6.3.

EDIT: Using Cemetech download link Smile
Over the past ~2 months, a bunch of bugs have been found and fixed, thanks especially to NonstickAtom785 and Hans Burch. I also updated the main menu and worked more on documentation. From the main menu, you can now use [*] to archive/unarchive, and the [Hook] option was replaced with [More], where you can enable/disable the token hook and lowercase.
Some of the bugs fixed are:

    Lbl got broken in the previous update, it was fixed for this.
    Vertical was buggy, now fixed.
    ▪ Storing Input to an OS string was broken, now fixed. (it would send too many bytes)
    ▪ Parsing Input with expr( was broken, it works again.
    Archive / Unarchive were messing with some RAM that Grammer occasionally used, causing a crash. This is now fixed.
    ▪ Fixed a bug with using " to end a string.
    ▪ Fixed a bug with custom fonts!
    ▪ Fixed two bugs with Else not being processed properly.


Some other updates:

    ▪ Variable fonts are now slightly indexed for faster access. Text should display faster with it now.
    ▪ You can exit the main menu with [On], now.
    ▪ You can now select with [2nd] from the main menu.
    nCr, a routine that might never be used by Grammerians, now only overflows when the final result would actually overflow (before, it could overflow during some intermediate calculations).


Compatibility-breaking updates:

    ▪ Grayscale is now only offered in 50-50 (3-level) and 33-67 (4-level) modes. I was able to make the LCD update routines faster and smaller. From the old version, presumably nobody would want to use the (uglier) modes anyways.


The download is here: Grammer v2.50.7.6
Grammer v2.50.8.6
In this update, I focused on fonts!

    ▪ I broke compatibility with third-party variable-width fonts (all zero of them) made for Grammer. Whereas before, Grammer had a variable font in which each char had its own height and width, now the whole font gets a height byte, and each char gets a width. This seemed a lot more reasonable-- it's a lot easier to program with it, it's a bit faster to access chars, and I could use DrDnar's Monochrome Font Editor
    ▪ I converted both the fixed 4x6 font to an mfefont, and I totally remade the variable font as an mfefont
    ▪ Whereas before, the variable width font was sparse (missing many chars), now it is complete!
    Yes, huge fonts are supported, technically.



Now for bug fixes. Again, big thanks to NonstickAtom785 and Hans Burch for reporting:

    For <<expr>> is officially documented, and fixed, and now you can nest them.
    For <<var>>,0,65535 no longer causes an infinite loop.
    ▪ Rounded square roots now round in the correct direction.
    ▪ Yet another If-related bug was fixed, this time the bug was with Then (but not with Then...Else). This bug caused the program to erroneously skip End statements if they were programmed as End:End. Ouch.
    !If works again.
    ▪ A page boundary bug was fixed that could cause major issues when reading variables from archive.


Some other updates:

    ▪ Modules are no longer verified when calling a module function. Instead, they are verified when they are initialized (ex. "5MYMOD->$) and after verified, Grammer assumes that they remain correct. This reduces some overhead for module functions.


Download Grammer 2.50.8.6
Good to see that you keep improving Grammer 2 Smile
Lionel Debroux wrote:
Good to see that you keep improving Grammer 2 Smile


I feel like he favors making most of the updates on Omnimaga. Here's the link if you want it...
https://www.omnimaga.org/grammer/grammer-2-the-app/msg407331/#msg407331
Thanks for the link. You had no way to know that I'm subscribed to that topic as well Smile

"She", BTW.
Lionel Debroux wrote:
Thanks for the link. You had no way to know that I'm subscribed to that topic as well Smile

"She", BTW.


Omg I knew I assumed their gender somewhere. I feel so bad now... Sorry Zeda.

So anyway Debroux, do you use Grammer alot?
In fact, I do basically no longer program for calculators themselves, I've been mostly on the computer side (computer software for dealing with calculators) for over a decade. When I programmed for calculators, at the beginning on my calculator but soon mostly on the computer, it was for the TI-68k series. I did a bit of Nspire and HP Prime development as well, but no TI-Z80 or TI-eZ80 development, so no Grammer. Also, I write news items for ticalc.org.

My post was some sort of motivational thumb for Zeda Smile
Oh okay. That makes sense. I wish there were a lot of Grammer users. It would boost development by a tenfold!
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 4 of 4
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement