### Author Topic: Grammer 2-The APP  (Read 57690 times)

0 Members and 1 Guest are viewing this topic.

#### Stefan Bauwens

• Creator of Myst 89 - סטיבן
• LV10 31337 u53r (Next: 2000)
• Posts: 1799
• Rating: +162/-24
• 68k programmer
##### Re: Grammer 2-The APP
« Reply #435 on: November 13, 2018, 02:19:36 pm »
Looking good Xeda

Very proud Ticalc.org POTY winner (2011 68k) with Myst 89!
Very proud TI-Planet.org DBZ winner(2013)

Interview with me

#### TIfanx1999

• ಠ_ಠ ( ͡° ͜ʖ ͡°)
• CoT Emeritus
• LV13 Extreme Addict (Next: 9001)
• Posts: 6173
• Rating: +191/-9
##### Re: Grammer 2-The APP
« Reply #436 on: November 14, 2018, 02:18:29 am »
Nice! I wonder why scrolling up is slower though...

#### Eeems

• Mr. Dictator
• LV13 Extreme Addict (Next: 9001)
• Posts: 6161
• Rating: +318/-36
• C'est la vie
##### Re: Grammer 2-The APP
« Reply #437 on: November 14, 2018, 09:59:18 am »
From a conversation on IRC it's due to searching through the VAT in reverse. I believe @Runer112 had some suggestions on how to speed it up though.
/e

#### Xeda112358

• they/them
• Project Author
• LV12 Extreme Poster (Next: 5000)
• Posts: 4571
• Rating: +716/-6
• Calc-u-lator, do doo doo do do do.
##### Re: Grammer 2-The APP
« Reply #438 on: November 19, 2018, 03:44:40 pm »
Code: [Select]
13 Nov. 2018
- Cleaning up code, removing (at least temporarily)
routines that aren't vital, or useful.
- Fire graphics code.     **Probably temporary.
- Factoring code.         **Probably permanent.
- Optimized CopyHex
- ConvHexStr is reorganized to be smaller
14 Nov. 2018
- Optimized ConvOP1 to be smaller, updated performance
analysis
- Optimized GetPixelLoc 3 bytes smaller, 10cc faster
- Optimized ReadArc routine. 3 bytes smaller, 18cc
faster for archived data, 3cc slower for data in RAM.
that no longer destroys IX. Next savings of 11 bytes,
even after extended the mov9 LDI chain to a mov13. Saves
172cc overall (186cc, actually, since no more ld ix,**)
- Error also takes advantage of mov13, saving 2 bytes.
- Added a few more fixed-size moves, including mov768.
Total cost was 6 bytes.
- ClrHome uses the faster SetSmallMem, saves a byte.
Makes it 901cc faster, roughly 21% faster
- I removed the unknown routine I labeled "lbl000", as it
isn't used anywhere (or shouldn't be!) It looks like an
attempt at making an off-page call, probably when the
low mem scared me.
- Optimized and fixed IsHexTok. It used to accept the
' and ' token as equivalent to 9. Saved a byte and 2cc
when the token was 0~9.
- Optimized DE_Times_BC. No change in size, 120cc faster
in the average case. No longer leaves A=0.
- optimized HL_Div_BC to be 264cc faster on average, with
a net cost of five bytes. DE_Div_BC is now the
subroutine, though, and is 272cc faster than if you had
called it previously. Nearly 18% speed up
- Fixed SearchString at a cost of 8 bytes, but should
perform roughly 4 times faster. Also, there is now no
risk of it entering an infinite loop, an issue the
- SqrtHL is optimized. Actually replaced with SqrtDE.
Saved 2 bytes, on average 261cc faster (20.17% faster).
Worst case is still 165cc faster (12.75% faster).
15 Nov. 2018
- I replaced the Sqrt routine with Runer112's from Axe.
It is 221cc faster with the small modifications on my
part to fit the output registers, and 2 bytes smaller.
That's roughly 21.5% faster.
- Removed ConvNumBase and HL_Div_C. HL_Div_C was only
used by ConvNumBase, and ConvNumBase wasn't used
anywhere in the code.
- Changed Is_2_Byte. It's no faster or slower, just
a little more sensible and readable.
- Removed HexTok and GetHexAtDE.
- Moved CompatCall so it didn't have to JP to
IsOP1GrammerProg, saving 3 bytes and 10cc
- Removed EndHook2 as it appears unused?
- Optimized ONErr to be 1 byte less, 2cc faster.
- Optimized TileMap1. 21cc faster, 2 bytes smaller.
- Removed HL_SDiv_BC replacing the only use of it
with a wrapper around a call to HL_Div_BC.
Net 21 bytes smaller. Signed division command now
- Removed PutIM, ParseFullArgI, CallI, CopyZStr,
CreateZVar, FindVar.
May have messed something up.
- vPutscr is 1 byte smaller, 3cc faster.
- Optimized DrawRectToGraphI since it didn't need
to preserve registers. Saved 9 bytes.
19 Nov. 2011
- Did some testing and fixed some new bugs.
another 76cc.
- Opted to use interrupts for the Pause routine. It
isn't as close to 1/100 seconds, but it is more
energy efficient, smaller, and more reliable.
No screenshots as it's just behind-the-scenes code modifications.

#### Xeda112358

• they/them
• Project Author
• LV12 Extreme Poster (Next: 5000)
• Posts: 4571
• Rating: +716/-6
• Calc-u-lator, do doo doo do do do.
##### Re: Grammer 2-The APP
« Reply #439 on: November 23, 2018, 12:50:37 am »
I'm too tired for a full report, but I'll use this as a backup.
I fixed a few bugs introduced in the last version, optimized and cleaned up some more code, and most importantly, I totally overhauled the module system. I renamed the token to just '$'. By storing to it, you can basically register a module to be searched after the default one is searched. At the moment, up to 5 additional modules can be used, which could greatly extend the functionality of Grammer. They can be archived now, and I moved the Menu routine to an external module (appv Grampkg). I still need to do a lot of documentation, but not tonight. Attached is a screenshot of what the code looks like (with the token hook). Good night y'all. #### ClainBill • LV1 Newcomer (Next: 20) • Posts: 17 • Rating: +1/-0 • Nuckleheadmcspasatron ##### Re: Grammer 2-The APP « Reply #440 on: November 23, 2018, 03:29:48 pm » Looks awesome ClainBill YouTube #### Xeda112358 • they/them • Project Author • LV12 Extreme Poster (Next: 5000) • Posts: 4571 • Rating: +716/-6 • Calc-u-lator, do doo doo do do do. ##### Re: Grammer 2-The APP « Reply #441 on: January 28, 2019, 08:14:26 pm » Grammer has a few new commands since the last update. • G-T returns the address of the default front buffer. • G-T' returns the address of the AppBackUpScreen, a typical back buffer. • Else is finally back to being supported. • →. will write four bytes from one pointer to another. This is intended for single-precision floats • Text(0,0,.A allows you to print the float pointed to by A. • A+.B adds two floats pointed to by A and B • A-.B subtractss two floats pointed to by A and B • A*.B multiplies two floats pointed to by A and B • A/.B divides two floats pointed to by A and B • √(.A calculates the square root of the float pointed to by A. So an example program using the GFLOAT module to get the pi and e constants: Code: [Select] .0:Return ClrDraw ClrHome "5GFLOAT→$
π8800→X+4→Y
$π→.X$e→.Y
For(A,0,7
√(.X*.Y→.X
Text(A*6,0,.X
DispGraph
End
Stop

#### Xeda112358

• they/them
• Project Author
• LV12 Extreme Poster (Next: 5000)
• Posts: 4571
• Rating: +716/-6
• Calc-u-lator, do doo doo do do do.
##### Re: Grammer 2-The APP
« Reply #442 on: January 31, 2019, 11:59:06 pm »
I made the readme a little easier to read, splitting it up into different files and using tables. I also added in support for automatic conversion of a number to a float if there is a decimal point in there. For example, 3.0 is now converted to a float and its pointer is returned (where it is stored in temp memory). See the readme for a slightly more detailed look at how Grammer handles floats. Finally, a really minor modification was that I found a size and speed optimization in pixel plotting, so you will now be able to get in an extra pixel or two per minute!

#### Xeda112358

• they/them
• Project Author
• LV12 Extreme Poster (Next: 5000)
• Posts: 4571
• Rating: +716/-6
• Calc-u-lator, do doo doo do do do.
##### Re: Grammer 2-The APP
« Reply #443 on: February 20, 2019, 03:54:37 pm »
I fixed some bugs including one with the rectangle routine, line clipping, and floating point conversion (to and from strings). There was a serious bug in the str->float routine that caused it to overwrite the source code when the integer part had an even number of digits :|

#### Xeda112358

• they/them
• Project Author
• LV12 Extreme Poster (Next: 5000)
• Posts: 4571
• Rating: +716/-6
• Calc-u-lator, do doo doo do do do.
##### Re: Grammer 2-The APP
« Reply #444 on: March 12, 2019, 02:36:33 pm »
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 ). I struggled with this, because I want to add in an int-->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.

Attached is Grammer 2.50.2.0 as well as a screeny of a program using the ▶Dec command.

#### Xeda112358

• they/them
• Project Author
• LV12 Extreme Poster (Next: 5000)
• Posts: 4571
• Rating: +716/-6
• Calc-u-lator, do doo doo do do do.
##### Re: Grammer 2-The APP
« Reply #445 on: March 18, 2019, 01:27:11 am »
Grammer now has some basic stack support and easier parameter parsing!

To accomplish the stack routines, Grammer keeps track of three values: The stack base, the stack top, and the stack pointer. Grammer can detect overflows in either direction. I decided to make these actual variables that you can interface with via the Pmt_Bgn and Pmt_End tokens (found at the end of the Finance app). When storing to Pmt_Bgn, the stack pointer is automatically reset. Currently, the stack defaults to saveSScreen+256 and ends at saveSScreen+768, so you have 512 bytes to work with. If you want to relocate the stack, you may. For example, you could create a temp var of 10000 bytes and have a giant stack there !

To push, use Param' followed by an arbitrary number of parameters. To pop, use Param° followed by an arbitrary number of parameters that must be variable names. For example, to swap A and B, you could do:
Code: [Select]
Param'A,B
Param°A,B

The unmodified Param token also takes variable names as its input. A while back, I added the ability for subroutines to be called with arguments, kinda. In order to parse those arguments, you had to do something like:
Code: [Select]
]?→A
]?→B
]?→C
But now you can do:
Code: [Select]
ParamA,B,C

I plan to add the  ▶Nom( token to save variables and then restore them at the end of a subroutine. It is basically just an automated sequence of pushes and pops.

#### Xeda112358

• they/them
• Project Author
• LV12 Extreme Poster (Next: 5000)
• Posts: 4571
• Rating: +716/-6
• Calc-u-lator, do doo doo do do do.
##### Re: Grammer 2-The APP
« Reply #446 on: March 19, 2019, 10:41:10 am »
I added the ▶Nom( command and it is actually implemented as a code block like this:
Code: [Select]
:▶Nom(x,y,z
:<<do stuff>>
:End
What it does is it pushes the list of variables to the stack and when it's End is reached, pops them back off.

My original plan was to make this command useful in subroutines, where when the subroutine's End was reached, it would restore the variables and then exit. However, that was hackish in a future-migraine way, and in implementing it, I realized this routine could be a much more useful as an explicit block.

While coding this, I realized I needed to add ▶Nom( to the internal list of block tokens and found a long standing bug in the routine that finds a block's matching End token-- it wasn't discarding the second byte of a two-byte token. This means, for example, that if a two-byte token's second byte was, say, $D4, it would be interpreted as an End token ! Fortunately, this would only happen in hacked variables (not useful in Grammer) and the (potentially useful) character tokens for ~, @, #,$, and &.

Anyway, here is v2.50.4.0

#### Xeda112358

• they/them
• Project Author
• LV12 Extreme Poster (Next: 5000)
• Posts: 4571
• Rating: +716/-6
• Calc-u-lator, do doo doo do do do.
##### Re: Grammer 2-The APP
« Reply #447 on: March 29, 2019, 09:50:21 am »
I forgot to upload it here!
With the recent updates to z80float, I updated the existing float routines and added in the rest.
• 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(.

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).

#### Xeda112358

• they/them
• Project Author
• LV12 Extreme Poster (Next: 5000)
• Posts: 4571
• Rating: +716/-6
• Calc-u-lator, do doo doo do do do.
##### Re: Grammer 2-The APP
« Reply #448 on: August 23, 2019, 08:37:59 pm »
I rewrote the Input routine and ran into some issues that I finally managed to fix. Now, the cursor blinks, and you can change the location and size of the input buffer! Here is a screenshot where I relocate the input buffer to a spot 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).

#### Xeda112358

• they/them
• Project Author
• LV12 Extreme Poster (Next: 5000)
• Posts: 4571
• Rating: +716/-6
• Calc-u-lator, do doo doo do do do.
##### Re: Grammer 2-The APP
« Reply #449 on: September 03, 2019, 12:46:32 am »
Grammer now has proper support for big sprites! With the Pt-Off( command, you can now specify a width argument and it will actually work (with proper clipping, too).

I also totally overhauled the Menu( command. On the surface, it will look largely the same, except that now it allows scrolling if their are too many elements. Internally, it requires a much smaller memory footprint and has a more powerful menu interface. To take advantage of this, I added the Menu(' command. With this one, you can supply two Grammer subroutines to compute the outputs. The syntax looks like:

Code: [Select]
The subroutine for GET_ELEMENT will receive the index in Ans. Return 0 if it is out-of-bounds, else return a pointer to the string to display. The subroutine for SELECT_ELEMENT will receive the index in Ans. Modify this as you want, the result will be returned as the result of the menu. 0 is returned if the menu exited due to [CLEAR] or [ON]. An example is:

Code: [Select]
Lbl "GET→A
Lbl "SEL→B
Text('0,0,M
Stop

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

.SEL
+1
End
That will display items with the name "ITEM A" through "ITEM Z".