[Prizm] Introducing LuaZM

[KermMartian]

The Casio Prizm is a powerful calculator, great for both math and playing games. It is particularly great for programming, and for months thoroughly bested the TI-Nspire calculator in offering ASM, BASIC, and C programming. In an attempt to reduce criticism of their apparently anti-student stance, Texas Instruments improved the TI-Nspire to run Lua programs. Lua is a "fast, lightweight, embeddable scripting language," an interpreted procedural language. The language has allowed budding Nspire programmers to quickly write games and programs without needing to use a computer.

I am happy to announce that I am now bringing Lua to the Casio Prizm graphing calculator, in the form of a full-featured Lua interpreter. After days of porting, rewriting parts of libc (including the longjmp/setjmp system), and learning some SH4 assembly, I am proud to present the first screenshot of the interpreter successfully running on a Prizm. Special kudos to Juju for the PrizmIO library, a port of an Nspire I/O library for C programmers. As you can see from the screenshots, this is just the raw interpreter; although it understands Lua syntax and can parse/lex the language, load libraries, and recognize incorrect code, it is almost entirely lacking in functioning libraries. From here, I will be porting over each of the standard libraries, starting with numbers, strings, and I/O. Please feel free to share thoughts and suggestions in the attached thread. Bonus features: Planned transparent support for Nspire and Lua FX programs.


_________________

[Deep Thought]

This is really great news I'd love to see compatibility between Nspire and Prizm programs, and especially Lua now that TI seems set on keeping that public on the Nspire.

What version of Lua is this?
_________________

[KermMartian]

Check the very first line of output: Lua 5.2.1. That was the latest one that I could find source for on the Lua download page. Most likely I'll implement compatibility libraries for the Nspire and give the Prizm libraries their own extra functions. As discussed previously, the Nspire has a smaller screen than the Prizm, if you discount the top statusbar.
_________________

[juju2143]

5.2.1 (as seen on the screenshot). Glad you're using my library to a pretty good use

And yeah, an eventual compatibility with Nspire Lua programs would be nice. Nonetheless, once the project will mature, I bet the quantity of Prizm coders will exponentially increase, like Axe on the 83+ and Lua on the Nspire.
_________________

[Deep Thought]

[KermMartian]

It doesn't stand for anything, as far as I know, so I think it's more reasonable to call it the Prizm. We call the "TI-83 Plus" the "TI-83+", so I don't see why we can't also make a de facto name for the Prizm. And to reassure people, the errors just mean that the interpreter is functioning fully, and just successfully finding that the libraries are not present. Notice the lack of crashes and segfaults.
_________________

[DJ_O]

I heard about this project from Juju IRL a few times so far and I was anxiously waiting for the announcement. I'm glad Lua is finally arriving on the PRIZM. Hopefully this should increase the userbase considerably.

When Lua arrived on Omni, about 30 new games (a lot of which were pretty fun to play) came out on the TI-Nspire during the year after. With Ndless out since 2010, C and ASM support has never come close to that amount. I'm betting here too Lua will generate a lot of interest (at least once Summer ends).

[jwalker]

DJ_O is right, TI screwed up bad. It is prety fast, but I found things out like how it draws string on the computer isnt how it draws strings on the handheld (draws the same string in diffrent places).

I also did a test with collectgarbage() to see how many kb's lua was using, before and after a clean.
I found out that it is prety close when just clicking, or pressing the enter key to push the button that I was using( using enter used less memory), and if you move the mouse in circles (trying to keep the circle in the same place) 6 times before the clean would register about 288 kb and after it was cleaned it would register about 181 kb.
I dont know if this is good or not, as I cant test on anything else right at this moment. the 181 is prety constant though.
I also did it on the calculator(the previous test was on the computer) and the values are similar.
_________________

Support Casio-Scene against the attacks of matt @ matpac.co.uk ! For more information: Casio-Scene shuts down & Matt actions threads

[KermMartian]

jwalker: Very interesting. I'm using the stock Lua interpreter as a base, stripping out what I don't need or requires too much rewriting as I go. For what it's worth, the interpreter package itself is 134KB on-calc now, and I've successfully compiled in the following libraries:

- Lua string library
- Lua bit32 library
- Lua table library
- Lua database library
_________________

[totoyo]

Hi Kerm,

Very nice project ! It is a port of LuaFX on PRIZM or Lua for Ti-nspire of PRIZM ?

Sorry if the answer is in the messages, i need a lot of time to translate.

[Lionel Debroux]

Interesting project, as usual

Nspire compatibility is a laudable goal, but you'll be chasing a moving target with lots of quirks.
I've pointed jimbauwens to this topic.
_________________
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

[vebveb]

It seems there are still many things to do.

Why does "name = 3" not work? I saw you had an implementation of strtod in libfxcg. It should work...

[flyingfisch]

Just curious... Why is it called LuaZM instead of LuaCG?
_________________

[vebveb]

I just look at the code of strtod in libfxcg, and it is not complete at all.
Strtod should read the number if the string begins with spaces before the number. It doesn't read exponents, don't care underflow, ... Why don't you take an already finished libc ? I think you can find an open source libc somewhere and adapt it. (could you take the gnu libc? (glibc) )

[Spenceboy98]

[TheStorm]

[KermMartian]

[flyingfisch]

[vebveb]

TheStorm: you could take parts of the code, like a complete strtod function, the code to manage some specific options (%f %g ,...) of printf, ...

[Lionel Debroux]

But it's not necessarily easy to take parts of the code, because those parts of the code can have some dependencies, which themselves have dependencies, etc. The transitive closure of a seemingly simple function can be surprisingly large
I think that it's what Kerm wanted to refer to by "Yup, it's hopelessly tangled".

When working on improving an old and little-known TI-68k/AMS port of an older version of Lua ( http://www.omnimaga.org/index.php?topic=9228.0 ), I had a look at several existing implementations of snprintf and vsnprintf. They usually depended on vasprintf, which is a lot of code, has lots of dependencies, maybe both (I don't remember exactly).
Therefore, I reimplemented my own snprintf & vsnprintf, because it yielded smaller code. See https://github.com/debrouxl/gcc4ti/commit/dc5a1376c25f10daf3c51988da4f90636bee4d8f
Based on that experience, I would probably have made the same choice as TheStorm wrt. strtod - but I didn't have to reimplement it, since it's built in AMS. I added strtod to GCC4TI nine years after I told several others about it, but they didn't bother: https://github.com/debrouxl/gcc4ti/commit/8050b9546ef21a02b113e10394697da103b200bb .

EDIT: BTW, if Lua 5.2.1 still depends on snprintf, and you want to use my implementation of snprintf in LuaZM, go ahead
It only depends on setjmp, longjmp and vcbprintf, all built into AMS.
_________________
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.