Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
AHelper: I'd at least like something people can easily draw out on paper and write in ASCII. I don't mind a secondary compressed format at all, of course. Smile Also, can I grab that new libc from you soon? Smile

Edit: Thanks, AHelper. Now loading Lua scripts from files via run("script.lua") works great! I am currently running mem.lua from Vebveb to see how much RAM is available for Lua scripts to use, and will put the number at the end of this post. I should document the run("file") command in WikiPrizm, and I also want to have a run() command that launches a file browser. Could you gents (ladies?) who are particularly good at finding and probing syscalls see if you can find a general file-browser syscall?

Edit: The mem.lua program printed as high as 105.1777 before terminating with a "not enough memory" error, which I suppose means add-ins have about 105KB to work with.
KermM, what about this: reformat the addin ram and use a custom malloc function? You can expand the heap to be much larger (I assume you don't need 512KB of stack space).

Also, very nice! Great job on this so far, I will have to try this.

File-browser, like opendir/readdir? That is a syscall. I can test it out if you want. (non-graphical, it just lists files and folders. Not sure if it does fun stuff like filtering) If you really want an OS-like file browser, I can try to make one Smile
Well, it sounded like there was a fully-graphical, OSy one for (at least) pictures, so I wanted to see if either that or another one could be used for any file type (or, even better, only .lua files). I'd love help with a graphical file browser if not, but it's up to you. Actually, considering that previous Casio calcs have only allowed 40KB-60KB for LuaFX, I'm not too disappointed with 105KB.
Yeah, LuaFX max is 42kb. However, we can run much larger .lc files.
flyingfisch wrote:
Yeah, LuaFX max is 42kb. However, we can run much larger .lc files.
What is .lc? Are those the lzo-compressed files?
LC files are compiled Lua programs, similar to how PYC files are compiled Python programs. Lua programs are compiled to bytecode (again like Python) before they're interpreted, and LC files are precompiled for size and speed.
Deep Thought wrote:
LC files are compiled Lua programs, similar to how PYC files are compiled Python programs. Lua programs are compiled to bytecode (again like Python) before they're interpreted, and LC files are precompiled for size and speed.
Ah yes, LuaZM can handle those too. I'll ask vebveb if there is any way to test the size of .lc files that LuaZM can handle. In the meantime, I'll press onward with libraries.
Wait, is 100KB the max size of the loaded file in ram? If so, why not directly read the flash chip? So long that the data in the file will not be changed, you can remove the file limit (then again, I haven't touched lua)
Well, the max ram size available for luaFX programs is 38kB on fx9860 (with the version I havn't posted yet. With the available version it is 33kB) and 43kB for AFX.

The interpretation has two parts : first the text file is precompiled, this requires a lot of memory. Then the extra memory used is freed and we launch the execution on the precompiled file.

On AFX, we can only execute precompiled file (which I decide to name .lc . We precompile .lua on our PC)

fx9860 can read lua file, but not big programs since the precompilation needs a lot of memory. It can reads .lc like the AFX.

Then I'm sorry to say that you are wrong flyingfisch. 38KB and 43kB are for both format.

If the prizm has a huge stack place, then you can use this space an other way: for example having a huge integer table that the programmer can use without allocating anything.

If you want to have colors like that: "zmg.color.red", then consider that the user should always define the colors as local, since when we load zmg.color.red we have to:

find the global variable zmg
find the index color
find the index red

when you use local variables, these research are done only one time, since the local variables contains directly what contains zmg.color.red

Why not using strings like that:

the library will be composed of:

addcolor(name, a, b, c)
name will be associated with the color defined by a,b,c (I think we define colors with percentage of blue, yellow and red)

drawpixel_name(x,y, name)
will draw the color at x,y.
name : "red" -> draw in red, ...
There will be already registered names: red, green, blue ,....

drawpixel(x,y,a,b,c)
same but without using names.

AHelper : I though once we could do that, but no it isn't possible since when lua load the files, it isn't contain in the memory like in the precompiled file and because even functions are considered variables (code can be free from memory if some conditions are met).
vebveb wrote:

...
Then I'm sorry to say that you are wrong flyingfisch. 38KB and 43kB are for both format.
...


Oh, I didn't know that. Are .lc files smaller then?
Well there is a little difference I forgot to tell:

you can choose to precompile with/without the debug informations.
when you load a .lua, you have the debug informations in memory. Then for big programs, .lc are better.

The debug informations help to know when an error appen, the line and the name of the local variables. They can take a big part of the memory.
Any more progress?
Well, kermm is working on zmg library functions. Last I read was working key input.
Spenceboy98 wrote:
Any more progress?
As AHelper says, with file execution functioning, I'm fleshing out the ZMG library more. If I fix key input and add a text-output method, maybe there's no point in delaying a public beta. I was hoping to wait until Juju improved the PrizmIO text input modes to a less frustrating system, but if people aren't going to get hugely bent out of shape about that, perhaps I'll consider it. Smile
jwalker wrote:
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).

The reason strings are draw different are because the computer has vector based fonts and the calculator bitmap based. The calculator can only use the following font sizes (in 3.2, 3.1 might have less): 7,9,10,11,12,16,24.
If you use a different font size in a Lua program, the handheld will choose one of these sizes, but the computer will use the font size number you gave. So, if you want to have strings drawn the same on both platforms you should choose a font size from this list.

Also, if you know more screwups please report them to me; I'd be happy to send a report to TI.

Now regarding LuaZM, nice work !
I've checked the docs of the API that you have implemented so far, and it's pretty good.
I have a little suggestion though, regarding the sprite function. Currently it uses r5-g6-b5, but I think it might be interesting to support something like a1-r5-g5-b5, where a1 represent one bit for alpha (so that the pixel on that location doesn't get redrawn). This would allow me to implement the TI.Image sprite stuff, as they support an alpha bit.
Of course it might be hard to implement in ZMG ..

Also, could you add a function that returns the amount of milliseconds (or microseconds) since boot (or epoch, all the same)? That is of course only if the Prizm has a timer of that sort.
I changed the fonts to the ones in the list but this is what Im Getting.

Handheld:


student software:
Hmm, I see. The text is shifted with one pixel down on the software.
I've not noticed it before, so I reported it to TI.

For now, you could add some code to the top of your script to fix it:

Code:

if platform.hw() == 7 then
    local gc = platform.withGC(getmetatable)
    local dS = gc.drawString
    function gc:drawString(str, x, y, pos)
        dS(self, str, x, y-1, pos)
    end
end


Anyway, going a bit offtopic here .. so back to LuaZM.
I need to create some extra graphical functions to implement all the functions TI-Nspire programs can use. While I can code them in Lua, it might be better to extend the ZMG lib itself so the functions work faster. What do you think ?
I think that extending the ZMG library (or making an NSG library) would be the better choice. For alpha sprites, I going to make the copySpriteMask use a specific color for the transparent pixels, something which I've used with success in C programs for the Prizm. Do you object to that? It would seem that 0x7FFF colors would be wasted with a one-bit alpha channel, while using one out of 65536 colors to represent a transparent pixel is significantly more efficient. Also, the Prizm LCD is natively r5-g6-b5, so I am loath to deviate too far from that. For text, I was planning on having one or two font sizes based off the native Prizm PrintXY() and PrintMiniMini() fonts, but I see the value of multiple sizes. I'll have to ponder that one further. As far as time, I have implemented an epoch time function based on the RTC, and the Prizm also has a 64Hz timer that games like Tetrizm use to maintain a constant game rate regardless of CPU clock speed or user input. I should probably expose both of those functions to users.
OK, I guess the functions should be part of ZMG then. This just is a bit harder for me as I can't start coding native stuff for the Prizm because I don't have one.
In case you are interested, here is alist of the graphical functions that the Nspire API exposes: http://wiki.inspired-lua.org/gc.

Regarding the alpha color, I see your point and I think your solution is pretty good Smile

As for the timer, I might have a little problem implementing the Nspire Lua one as it can tick at 1/100s but the Prizm's one only at 1/64. This could cause problems because some games/programs use 0.01s as timer setting. Any idea how I could somehow make it a bit more accurate ?
jimbauwens wrote:
In case you are interested, here is alist of the graphical functions that the Nspire API exposes: http://wiki.inspired-lua.org/gc.
I am very interested. Those actually look surprisingly easy to implement, with the exception of performing clipping in an arbitrary rectangle, the pen settings, and the text functions. I'll probably get started on those after I release my first LuaZM alpha or beta.

jimbauwens wrote:
Regarding the alpha color, I see your point and I think your solution is pretty good Smile
Woot.

Quote:
As for the timer, I might have a little problem implementing the Nspire Lua one as it can tick at 1/100s but the Prizm's one only at 1/64. This could cause problems because some games/programs use 0.01s as timer setting. Any idea how I could somehow make it a bit more accurate ?
Hmm, that's a good question. Looking at the Prizm RTC Unit documentation, I probably can't use anything from that, but I wouldn't be surprised if I could derive a (rough) 100Hz clock from one of the CPU clocks.
  
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
Page 3 of 6
» All times are GMT - 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