Okay, I've fixed a few bugs

The following kind of code was broken:
If <condition>
Then
    <<do stuff>>
    <<While, Repeat, For, or If/Then (but not If/Then/Else)>>
End:End
If the condition evaluates false, Grammer would search for the matching End token. However, I tried to be clever, and combined it with the code for when it is If without Then, and so it seeked the end of the line (specifically the newline token, colons (":") didn't count). Unfortunately, this meant that the second End was skipped, causing an outer loop to End prematurely. Oof.

In fixing this bug, I noticed another clever optimization that I had made which was really not clever and had broken "!If" for a while! !If works now


An unrelated bug is with copying data from archive to RAM if it crossed a page boundary. Once again, I thought I'd be clever and I noticed that I had an "adc hl,bc" in a place where the carry flag was guaranteed reset, so I "optimized" it to "add hl,bc" to save 4cc and a byte. Whelp, it turned out that I was using "adc hl,bc" because that one affects the sign flag, whereas "add hl,bc" doesn't. Ouch.


For loops had an update, specifically fixing the previously undocumented command For <<expr>> which would loop <<constant>> number of times. Today, @NonstickAtom785 found a bug when trying to use a variable as the expression. In actuality, it was a For bug affecting any expression that started with a pointer var! I fixed this by simply checking if the token following the pointer var was a comma. If it isn't a comma, treat it as an expression, otherwise, treat it as a normal For loop.

---

There were some updates to modules, too: I moved the verification step. Before, every time a module command was run, the module would have its header verified (look for the 4-byte magic number, then make sure the version was compatible). Grammer now verifies when you first initialize it ("5MYMOD->$) and assumes for subsequent calls to module functions that the module is still valid. This removes some overhead, but module functions are still slow to call, and likely always will be

I've been working on the built-in fonts!

As some may have noticed, the variable font was very sparsely populated, only containing some important characters. Part of the reason is that the old font format was... convoluted. Each character had its own width and height, which made it difficult to make an editor for it. I decided to go with a more sensible option, one that I had used in the past-- The fontset has a height-byte, and each char has its own width (which is allowed to be 0).

There were two advantages to this: one, it is easier to code the text routine, and two, DrDnar's Monochrome Font Editor already supports this format (Xeda's Format #2) which means I had an easy-to-use editor. So, with all of this, some motivation, and some free time, I completed the font and reworked the text routines:


I haven't have tested the Input routine with this, so I should work on that and it works, so I hope people like this ^~^
Also, if anyone wants to make their own fonts based on these, I have the "mfefont" files here:
Variable-width font (export this to Xeda Format #2)
Fixed 4x6 font (export to Xeda Format #1)

You can find the download in the GitHub project's /bin folder, or attached.

EDIT: Tested the input routine; it works ^~^
EDIT2: Oh my. Sweet. Baby. Carrots. Fonts can be BIG apparently. I tested a 16-pixel wide character and it works fine :0

---

EDIT3: More updates! I've gone bug hunting and I managed to fix the following:

• The undocumented For <<constant>> can now be nested! This should be documented; it has been around for years.
• An ooold bug report I found mentioned that For X,0,65535 would cause an infinite loop, so I fixed it!
• Rounded square roots, via √(' were pretty broken. I had an old bug report that showed √('255 was returning 0, but that was fixed a few months ago when I totally rewrote the square root routine. But, I did botch the rounding, causing it to round up when it should have rounded down, and vice-versa. This is now fixed

I also overhauled the module documentation, and I realized I had to advance the module version since I broke some support with the original

(We prefer you to edit your post as opposed to "double posting.")

It still seems to me like it is the software trying to write too quickly to the LCD, but that is usually fixed by ALCDFIX. Maybe TI started using a different LCD .__.

Wooh, lots of bug fixes, a few new features! Latest Release.

Try running ALCDFIX and see if that helps.

For the assembly version, you can replace the seed= with just a label, "seed:". Then the (seed) instances need (seed+1).

As for a Grammer version, assuming a 52-card deck, you can initialize once with:
π9872→Z
For K,0,51
WriteB(Z+K,K
End
Then every time you want to shuffle, assuming Z still points to the deck:
.SHUFFLE
51→K
While K>0
randInt(0,K→A
(Z+K→B
WriteB(Z+K,(Z+A
WriteB(Z+A,B
K-1→K
End
End
It's honestly a beautiful algorithm and works well. It helps that Grammer has a pretty good pseudo-random number generator (statistically fantastic, especially for only providing 16 bits at a time )

Hmm, I'm not sure then. Maybe try posting in that thread?