Omnimaga
Calculator Community => Other Calculators => Topic started by: Munchor on May 31, 2011, 06:03:29 pm
-
I'd like to know how much memory the CX has and how much is free (let's say only the OS is there). Thanks
-
iirc, I think it has 64MB RAM and something like ~100MB storage, with the OS taking up 25-28MB in storage.
-
ROM : 115Mo for user (seems to be a 128Mo chip)
As said Ashbad, 64Mo of RAM
-
ROM : 115Mo for user (seems to be a 128Mo chip)
As said Ashbad, 64Mo of RAM
HOLY-
-
Windows 95, anyone?
But that is a lot of ram for a calculator. Storage space seems par.
-
64 Megs of RAM???
Holy Bananas!!!
-
That is excellent for a calc
-
64 MB of RAM is great, but they have cheaped out on storage...
-
Woah! O.O 64 MB of RAM is so much, we have 24 MB in the 84+ :P
That's just great :) Thanks for the info.
-
Woah! O.O 64 MB of RAM is so much, we have 24 MB in the 84+ :P
Not really. The 84+ has 24 KB. :P
-
so Nspire is 1000x more RAM :O
-
Well that's not all that surprising as the screen is 16 bit color and is a much higher resolution than the 84+. Also code size is significantly higher too. I'm just wondering if the OS ever uses all of that ram though.
-
I wonder if its possible to use all of that memory
-
It was the fact for the half RAM space (32Mo) on the TI Nspire non-CX
-
most likely, Lua programs would only be able to use a small fraction of that 64MB, since that's too much and TI isn't THAT generous. Plus, the OS looks like it would need a lot more RAM than previous OSes.
-
what if we were able to use the Nspire to its full potential...
*ruler likes this dream
-
I have heard though that the stack can be overflowed in Lua. That's were the possibility of an ndless exploit is right now.
-
That's very true. In Lua to overflow the stack all you need to do is something highly recursive:
function foo()
foo()
end
I don't remember the procedure from there, but from there you have only a slight-limit of writing space where you can write to memory unchecked for a bit. Using the stack overflow procedure to run/load Ndless programs would be a bit slow, though.
-
Maybe they could make it so that when ndless loads you can just run the programs without needing that overflow anymore. You'd just need it to load ndless
-
Well, I think a good idea (in theory) would be this approach:
1. Keep the compiled binary data for the C/ASM program in an undisturbed format in a fake Lua file.
2. Change around an area of RAM so that the instructions in it allow for executing of assembly code.
3. Exit the Lua version of Ndless and if placed in the right location, the OS will trigger the binary calling routine you embedded and will run the C program.