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.

This is really great news Smile 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?
Check the very first line of output: Lua 5.2.1. Smile 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.
5.2.1 (as seen on the screenshot). Glad you're using my library to a pretty good use Very Happy

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.
KermMartian wrote:
Check the very first line of output: Lua 5.2.1. Smile
Whoops, I missed that trying to figure out what the interpreter was trying to say with the rest of the output :/
KermMartian wrote:
That was the latest one that I could find source for on the Lua download page.
That's the most recent public version in any form anyway heh
KermMartian wrote:
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.
Oh, that would be awesome. I'd imagine the chances that TI will do the same (compatibility libraries for programs made for the LuaZM) is basically zero or less. Guess you can't have everything.

And I agree with juju on that—Casio BASIC is pretty limited in terms of game design too, especially in graphics (though compared with Nspire BASIC it's a programmer's dream). But I think LuaZM will have the same effect as Lua on the Nspire, if only because the Prizm is a lot less popular of a calculator than the TI-8x series. Still, that would be a big boost Smile

Off-topic: Is it PRIZM or Prizm? I've always called it Prizm and it seems most people do that too, but Casio themselves call it PRIZM and so do a fair portion of people discussing it on the forums.
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. Smile 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. Smile
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). Very Happy
KermMartian wrote:

Lua is a "fast,
Actually a little correction, it isn't all that fast on TI calcs. Wink On other platforms it is, but TI didn't do the very best job at optimizing it yet, although due to the platform speed, it allows a lot more stuff than TI-83 Plus BASIC, plus it has far more functions (notably the new physics engine) than TI-BASIC on any calculator. In any case, a Casio Lua interpreter gotta be the most welcome software Smile

Good luck!
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.
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
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.
Interesting project, as usual Smile

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.
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...
Just curious... Why is it called LuaZM instead of LuaCG?
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) )
flyingfisch wrote:
Just curious... Why is it called LuaZM instead of LuaCG?


I think it is because of PRI"ZM", but I am not sure.

Kerm, I hope you can progress more with this. Good Luck!
vebveb wrote:
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) )
Trust me, I and others have attempted to modify and exsiting libc but its just not practical to do. Most existing libc's make assumptions about the platform that are just not true on the Prizm or other embedded platforms. I had newlib compiling but rather large chunks of it just didn't work and no real indication as to why. Writing the libc functions as needed will lead to a much more complete and usable project.
flyingfisch wrote:
Just curious... Why is it called LuaZM instead of LuaCG?
Because the calculator has the designation fx-cg, like the fx9860, so it would be LuaFX. The name of the calculator is Prizm, so I'm calling it LuaZM ("loo-az-um").
vebveb wrote:
I just look at the code of strtod in libfxcg, and it is not complete at all.
The errors in strtod() were indeed the fault behind the number error. I rewrote strtod(), and it works nicely now. I'd be happy to upstream my new strtod() to libfxcg.
TheStorm wrote:
Trust me, I and others have attempted to modify and exsiting libc but its just not practical to do.
Yup, it's hopelessly tangled. Even re-writing longjmp/setjmp for LuaZM proved extremely painful.

Progress continues.
KermMartian wrote:
flyingfisch wrote:
Just curious... Why is it called LuaZM instead of LuaCG?
Because the calculator has the designation fx-cg, like the fx9860, so it would be LuaFX. The name of the calculator is Prizm, so I'm calling it LuaZM ("loo-az-um"). ...


Ah, Got it. Smile
TheStorm: you could take parts of the code, like a complete strtod function, the code to manage some specific options (%f %g ,...) of printf, ...
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 Smile
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://ourl.ca/11825 ), 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 Smile
It only depends on setjmp, longjmp and vcbprintf, all built into AMS.
  
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
» Goto page 1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Page 1 of 6
» All times are UTC - 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