Or at least, "trying to prevent tampering" and "trying to make regulation authorities believe that we're preventing tampering"... but as a matter of fact, persistently failing at preventing tampering:)
Actually, one of the older versions, OS 3.0.1, released at the beginning of April 2011, _did_ have a number of wrinkles in the math functionality that were not present in 1.x-2.x OS versions:)
Don't you think that this idea has already surfaced over the years, and multiple times at that ?;) But the fact remains that no viable "open source calculator" model ever surfaced.
You're partially missing the point;) On the one hand, of course, TI is actively trying to block arbitrary native code execution on the platform - and failing at it. But on the other hand, Lua programming is about using something that TI themselves (silently) put into the OS. And TI broke what we had been using so far, documents made of compressed+encrypted part copied from TI's own documents and a part merely compressed. We're back to a situation where only TI can _easily_ generate Lua documents that OS 3.0.2 understands... until the encryption of all document parts is documented and replicated by third parties...
I did actually read the bit you're quoting. But I'm not really (truly, totally or fully, if you prefer) convinced by it: it's a thought exercise. Until such an event happens, it's a probability that it does not happen, see ?;-)
As written in the grandparent of your post, everything in the Nspire is signed. The first-stage boot1 is not rewritable; the second-stage boot is signed and checked by the boot1; the OS is signed and checked by the boot2. Signature is done through 1024-bit RSA public keys, we can easily extract all of these keys... but it's not practical to factor them: three-four orders of magnitude more difficult than the state of the art (currently approximately 768 bits), which is itself three-four orders of magnitude more difficult than the 512-bit RSA keys of TI-Z80 and TI-68k calcs that we factored last year.
Therefore, we can't just "destroy the firmware check absolutely" off-line, we have to do it on-calc... and doing so requires exploiting the OS... and finding reliable exploits requires reverse-engineering, fuzzing, etc.
> How does people running their own programs hurt TI? Agreed, it helps them selling more calculators (because TI-Z80 and TI-68k moddable calculators are more desirable to users than a number of other little programmable models).
> TI does not sell apps do they? They did, many years ago. But they stopped doing so.
> If anything it's the Ndless community that's being counterproductive here. I wouldn't call making calculators more useful to users (it's not just about games - see, on TI-68k calculators, lower-level access to the OS does enable us to do more powerful functionality and do it faster) "counterproductive";-)
Exactly, mod parent up. While we can (and do) build our own OS for TI-Z80 and TI-68k calculators, especially since we factored the RSA public keys used for signature (but before that on both series, in a more hack-ish way), TI has taken significant extra effort for preventing us from doing the same on Nspire calculators. Multiple layers of signature with 1024-bit RSA keys, to begin with.
And we're already working on reverse-engineering OS 2.1;)
> amajor part of TI's calculator business is created by the un-hackability of their calculators. On the contrary: it's a fact that their past calculator lines, TI-Z80 and TI-68k, are _very_ hackable. Yet they sold millions of them (and it's precisely their hackability - games - that makes them more desirable for users than a number of other calculator models) !
People deciding the blunder of banning TI calculators from education would be _severely_ incompetent: * an unfixable exploit which enables hack-ish installation of arbitrarily modified OS on TI-68k calculators has been known for 11 years... but it did not get TI calculators banned from standardized tests for that very reason.
* the factorization of all interesting 512-bit RSA public keys used for signature of OS and FlashApps, and therefore the seamless installation of arbitrarily modified OS (resigned with the deduced private keys) on TI-Z80 and TI-68k calculators, was made in 2009... but again, it did not get TI calculators banned from standardized tests for that very reason. Nowadays, we're even fixing TI's bugs for them (there's an unofficial patch for the terribly unstable OS 2.53 MP for 84+ - the bugfix was reported months ago to TI, but they still don't provide it to users).
I'm not really convinced that too much functionality would hurt sales - but it's a fact that the lackluster functionality of Nspire calculators, prior to Ndless, _did_ hurt sales;-) It's pretty easy to understand why: Nspires are expensive, and users don't get much for their money. The first version of the OS didn't even contain any form of BASIC programming (!!), and that four years later, the BASIC of Nspires remains sub-par compared to the TI-Z80 and TI-68k BASIC.
As for TI calculators being banned from education... people deciding such a blunder would be _severely_ incompetent: * an unfixable exploit which enables hack-ish installation of arbitrarily modified OS on TI-68k calculators has been known for 11 years... but it did not get TI calculators banned from standardized tests for that very reason.
* the factorization of all interesting 512-bit RSA public keys used for signature of OS and FlashApps, and therefore the seamless installation of arbitrarily modified OS (resigned with the deduced private keys) on TI-Z80 and TI-68k calculators, was made in 2009... but again, it did not get TI calculators banned from standardized tests for that very reason. Nowadays, we're even fixing TI's bugs for them (there's an unofficial patch for the terribly unstable OS 2.53 MP for 84+).
> It would take you months to do that in assembler, and half a day to do it in C. Imprecise. If considering only a specific platform and no existing libraries, you're even completely wrong: Coding ASM is significantly more time-consuming than coding C, but the difference is 3-5 times "only". Obviously, with C, you get a higher level of abstraction, therefore more reusability, portability, etc.
> Then the C code would end up faster because compiler optimizations are faster than anything a person could hope to do, Depends on the platform. Hardly anybody is able to optimize for speed a modern x86 processor "by hand", but RISCs and even some CISCs like the 68000 are another story. I have been programming for years as a hobby on the 68000 processor, and I have seen: * GCC missing completely obvious CSEs: a global array used about ten times in a row, the compiler won't put its address into a register even if it has many spare ones; * GCC not using the instruction set possibilities (10-byte code instead of 4-byte code, and that spills one more register; bad code related to local variables on the stack; etc.); * GCC completely messing up a calling convention that should be more optimized ( saves&restores on a register that isn't even changed); * etc. Wonder why a number of not-very-powerful embedded platforms, like calculators, are still partly programmed in ASM...
There may be more appropriate compilers for those processors, but hey, GCC is supposed to be portable, and it has (had, they deprecated some useful things like casts-as-lvalues in GCC 4.0) cool extensions that most other compilers don't have.
> and it would be portable too. If you use external libraries like the SDL, yes. Otherwise, no, not more than ASM.
Both of you raise a valid point. That said, what he did is a good tech demo of what users/programmers out here can do with Canvas on the most recent Firefox versions ! Although older computers should not be neglected, the power of modern computers leaves some room for improvement: it is perfectly usable on my machine, which is more than two years old.
Well, I'm slightly tired of reading multiple posts containing a mention that the news is a dupe, and/or that the./ authors are lame because they couldn't see they were making a dupe. This is one of the kinds of comments responsible for the special reputation of./ readers (although there are gems in mostly every topic).
BTW, where are all those who complained about the lack of a Linux client;-) ? Last time, team Slashdot gained more than 3000 users. This time, less than 400 so far (barely enough to be noticeable in the stats) ! Similarly, this thread has surprisingly few replies for a./ thread. It's true that there's been no mention that both major complaints about the Windows client (it does not accept more than one WU at once - although there's UDMon for that purpose; it does not support multiple cores / multiple instances) have been addressed in the Linux BOINC client.
As someone else posted, there's now the Easynews team. Their growth over the past days is explosive, reminds of that of Team Slashdot on 2004/12/30-2005/01/02.
Good to see that some programmers are interested in hacking a powerful calculator. They should be able to port great games, despite the rather low screen resolution. I was already aware of that project, as an user of the TIGCC board (an environment development including heavily patched GCC for TI-68k calculators), which someone else already told about in those comments.
Slashdot Mirror
Or at least, "trying to prevent tampering" and "trying to make regulation authorities believe that we're preventing tampering"... but as a matter of fact, persistently failing at preventing tampering :)
Actually, one of the older versions, OS 3.0.1, released at the beginning of April 2011, _did_ have a number of wrinkles in the math functionality that were not present in 1.x-2.x OS versions :)
Don't you think that this idea has already surfaced over the years, and multiple times at that ? ;)
But the fact remains that no viable "open source calculator" model ever surfaced.
You're partially missing the point ;)
On the one hand, of course, TI is actively trying to block arbitrary native code execution on the platform - and failing at it.
But on the other hand, Lua programming is about using something that TI themselves (silently) put into the OS. And TI broke what we had been using so far, documents made of compressed+encrypted part copied from TI's own documents and a part merely compressed. We're back to a situation where only TI can _easily_ generate Lua documents that OS 3.0.2 understands... until the encryption of all document parts is documented and replicated by third parties...
I did actually read the bit you're quoting. But I'm not really (truly, totally or fully, if you prefer) convinced by it: it's a thought exercise. Until such an event happens, it's a probability that it does not happen, see ? ;-)
Every problem, no matter how complicated, has a solution that is trivially stated... and wrong (impractical, etc.).
Remember, they're the leader on that market. Many school mandate the usage of TI calcs...
As written in the grandparent of your post, everything in the Nspire is signed. The first-stage boot1 is not rewritable; the second-stage boot is signed and checked by the boot1; the OS is signed and checked by the boot2.
Signature is done through 1024-bit RSA public keys, we can easily extract all of these keys... but it's not practical to factor them: three-four orders of magnitude more difficult than the state of the art (currently approximately 768 bits), which is itself three-four orders of magnitude more difficult than the 512-bit RSA keys of TI-Z80 and TI-68k calcs that we factored last year.
Therefore, we can't just "destroy the firmware check absolutely" off-line, we have to do it on-calc... and doing so requires exploiting the OS... and finding reliable exploits requires reverse-engineering, fuzzing, etc.
Please RTFA: TI is doing much more than just preventing us from mirroring their software (which they don't bother doing themselves) ;-)
> How does people running their own programs hurt TI?
Agreed, it helps them selling more calculators (because TI-Z80 and TI-68k moddable calculators are more desirable to users than a number of other little programmable models).
> TI does not sell apps do they?
They did, many years ago. But they stopped doing so.
> If anything it's the Ndless community that's being counterproductive here. ;-)
I wouldn't call making calculators more useful to users (it's not just about games - see, on TI-68k calculators, lower-level access to the OS does enable us to do more powerful functionality and do it faster) "counterproductive"
Exactly, mod parent up.
While we can (and do) build our own OS for TI-Z80 and TI-68k calculators, especially since we factored the RSA public keys used for signature (but before that on both series, in a more hack-ish way), TI has taken significant extra effort for preventing us from doing the same on Nspire calculators. Multiple layers of signature with 1024-bit RSA keys, to begin with.
And we're already working on reverse-engineering OS 2.1 ;)
> amajor part of TI's calculator business is created by the un-hackability of their calculators.
On the contrary: it's a fact that their past calculator lines, TI-Z80 and TI-68k, are _very_ hackable. Yet they sold millions of them (and it's precisely their hackability - games - that makes them more desirable for users than a number of other calculator models) !
People deciding the blunder of banning TI calculators from education would be _severely_ incompetent:
* an unfixable exploit which enables hack-ish installation of arbitrarily modified OS on TI-68k calculators has been known for 11 years... but it did not get TI calculators banned from standardized tests for that very reason.
* the factorization of all interesting 512-bit RSA public keys used for signature of OS and FlashApps, and therefore the seamless installation of arbitrarily modified OS (resigned with the deduced private keys) on TI-Z80 and TI-68k calculators, was made in 2009... but again, it did not get TI calculators banned from standardized tests for that very reason.
Nowadays, we're even fixing TI's bugs for them (there's an unofficial patch for the terribly unstable OS 2.53 MP for 84+ - the bugfix was reported months ago to TI, but they still don't provide it to users).
I'm not really convinced that too much functionality would hurt sales - but it's a fact that the lackluster functionality of Nspire calculators, prior to Ndless, _did_ hurt sales ;-)
It's pretty easy to understand why: Nspires are expensive, and users don't get much for their money. The first version of the OS didn't even contain any form of BASIC programming (!!), and that four years later, the BASIC of Nspires remains sub-par compared to the TI-Z80 and TI-68k BASIC.
As for TI calculators being banned from education... people deciding such a blunder would be _severely_ incompetent:
* an unfixable exploit which enables hack-ish installation of arbitrarily modified OS on TI-68k calculators has been known for 11 years... but it did not get TI calculators banned from standardized tests for that very reason.
* the factorization of all interesting 512-bit RSA public keys used for signature of OS and FlashApps, and therefore the seamless installation of arbitrarily modified OS (resigned with the deduced private keys) on TI-Z80 and TI-68k calculators, was made in 2009... but again, it did not get TI calculators banned from standardized tests for that very reason.
Nowadays, we're even fixing TI's bugs for them (there's an unofficial patch for the terribly unstable OS 2.53 MP for 84+).
> It would take you months to do that in assembler, and half a day to do it in C.
Imprecise. If considering only a specific platform and no existing libraries, you're even completely wrong: Coding ASM is significantly more time-consuming than coding C, but the difference is 3-5 times "only".
Obviously, with C, you get a higher level of abstraction, therefore more reusability, portability, etc.
> Then the C code would end up faster because compiler optimizations are faster than anything a person could hope to do,
Depends on the platform. Hardly anybody is able to optimize for speed a modern x86 processor "by hand", but RISCs and even some CISCs like the 68000 are another story. I have been programming for years as a hobby on the 68000 processor, and I have seen:
* GCC missing completely obvious CSEs: a global array used about ten times in a row, the compiler won't put its address into a register even if it has many spare ones;
* GCC not using the instruction set possibilities (10-byte code instead of 4-byte code, and that spills one more register; bad code related to local variables on the stack; etc.);
* GCC completely messing up a calling convention that should be more optimized ( saves&restores on a register that isn't even changed);
* etc.
Wonder why a number of not-very-powerful embedded platforms, like calculators, are still partly programmed in ASM...
There may be more appropriate compilers for those processors, but hey, GCC is supposed to be portable, and it has (had, they deprecated some useful things like casts-as-lvalues in GCC 4.0) cool extensions that most other compilers don't have.
> and it would be portable too.
If you use external libraries like the SDL, yes. Otherwise, no, not more than ASM.
Both of you raise a valid point.
That said, what he did is a good tech demo of what users/programmers out here can do with Canvas on the most recent Firefox versions ! Although older computers should not be neglected, the power of modern computers leaves some room for improvement: it is perfectly usable on my machine, which is more than two years old.
Well, I'm slightly tired of reading multiple posts containing a mention that the news is a dupe, and/or that the ./ authors are lame because they couldn't see they were making a dupe. This is one of the kinds of comments responsible for the special reputation of ./ readers (although there are gems in mostly every topic).
;-) ? Last time, team Slashdot gained more than 3000 users. This time, less than 400 so far (barely enough to be noticeable in the stats) ! ./ thread. It's true that there's been no mention that both major complaints about the Windows client (it does not accept more than one WU at once - although there's UDMon for that purpose; it does not support multiple cores / multiple instances) have been addressed in the Linux BOINC client.
BTW, where are all those who complained about the lack of a Linux client
Similarly, this thread has surprisingly few replies for a
As someone else posted, there's now the Easynews team. Their growth over the past days is explosive, reminds of that of Team Slashdot on 2004/12/30-2005/01/02.
Err, why saying mostly the same thing twice (#13184583, #13184649) ?
Have a look at IBM-supported World Community Grid, especially this topic and the links in it.
I don't know if that's exactly what you're looking for, but like many TI-68k games, this game can be ported to HP-49G+.
Yes, that's it.
s sage?topicID=2708.topic. org
devphil, if you want more information, check http://p080.ezboard.com/ftichessteamhqfrm5.showMe
and
http://tigcc.ticalc
> Is this about a port of GCC that runs on the calculator?
No.
Good to see that some programmers are interested in hacking a powerful calculator. They should be able to port great games, despite the rather low screen resolution.
I was already aware of that project, as an user of the TIGCC board (an environment development including heavily patched GCC for TI-68k calculators), which someone else already told about in those comments.