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?

*The Lbl would have a description, in the form of a String, that tells the menu what the name should be. If there is no description then the name of the label is used.

I don't understand, sorry. As for the former, you can use the existing Menu(' command. You supply a pointer to a routine that gives the strings, and a routine that does something when an item is selected. In the latter routine, you could Goto different labels based on what is selected.

So my intent was a "parser hook" kind of feature. So when Grammer was getting ready to parse a token, it would first pass it through a third-party program in case they would alter parsing. Now I think it might be useful on the main menu during, say, the filtering step (when it is figuring out which programs to display), or for keypresses or something.