I agree. As long as we take the right steps and use it for the right thing, I'm sure they will understand. They are indeed pretty cool for creating the TI graphing calculator line in the first place, even if we disagree with some implementations, it is their code, and we should definitely respect that.

They did not quite understand it (or at least, think it is even remotely high-priority) for the Nspire series, despite multiple rounds of education-oriented explanations sent directly to top-level marketing and management people...

But anyhow, given that the TI-eZ80 models has direct support for Asm( and the AsmPrgm tokens (at least, in prerelease OS versions, but it would be surprising and extremely disappointing to see that support gone from release versions), the situation of the TI-eZ80 platform would be much better than that of the Nspire platform.

Some functionality provided by Ndless (among other programs) could find its way to DoorsCE 9 (*) for other reasons. That is, DoorsCE 9 could have, or maybe somehow want, to provide a hardware / OS hardware abstraction layer to assembly programs.
Ndless definitely has to do this because the Nspire's OS doesn't have a proper ROM_CALL table; the 92 didn't have such a table either, but the 92+ and later models always did, though the table was overly short for the very first 92+ OS 1.00 version, which made so-called "kernels" much less necessary on the newer TI-68k models.

*: or any equivalent so-called "shell", but given that making such programs with sizable built-in libraries takes lots of work, and that there's already a single such program for the 84+CSE, it probably makes limited sense to work on multiple full-featured "shells".

Through the grapevine, the TI-Planet staff have alerted us that the OS is also available for download, should that interest people:
http://education.ti.com/en/us/~/media/Files/Download%20Center/Software/84PlusCE/TI-84_Plus_CE-OS-5.0.8eu

I wonder if this official release fixes the 9 menu item glitch... the OS on prototype samples of the TI-83 Premium CE didn't. http://tiplanet.org/forum/viewtopic.php?f=41&t=11281#p177468

If it came down to it, I think this is actually the path [cracking it's security in some way] the community would take: the CE is set to replace the TI-83+, TI-84+/SE, and TI-84+CSE, and could become the #1 most common calculator. In that case people would obviously not just ignore it.

EDIT: Clarified meaning

I respect that position, and I'll keep that kind of talk away from here as much as possible, but everyone should know that I will *NEVER* stop trying to break whatever arbitrary restrictions they've added.
They have made a lot of security improvements to the ASIC, so in my opinion, it's extremely important that we defeat it, *especially* since it will probably be used in every model going forward.

I started putting some TI-84+CE information up on WikiTI, so there's a place to document what you find in the apps and OS.



TI doesn't care if you develop exploits. They only care if you publish exploits. Reverse engineering and patching exploits costs money. A game that uses 8-bit palette mode or a USB linking program is not likely to make them think, "We need to spend money to put a stop to that." Defeating TestGuard adversely affects sales. It may benefit us if they do not think we are a net source of red ink.

Anyways, it looks like from the little information on WikiTI, that it will be possible to develop apps.

Possible for whom?

Wait, what! No in/out instructions allowed! It also says bcalls are supposed to be used: No thank you in key cases. GRAM flipping is prevented as well, apparently. Probably not too big of a deal because the LCD is memory mapped, so double buffering is still valid, but is probably slower. And no port access... Sad day. This new calculator sounds like a crazy thing. Going to be difficult to get things up and running... But it's always worth a shot.

Which means no configuration of the LCD, in other words. So darn.


Honestly, it is signed with a 2048 bit key. Not going to happen. Period. Unless TI releases anything, it isn't going to work.

It's quite a sore point given that the beefed up hardware could allow for some great graphics were we able to configure the LCD in certain ways.

Yes, indeed. Oh well. I'm curious as to how they intercept port reads and writes; any ideas?

As an electrical engineer, it's logical for me to guess that the new ASIC detects port read/writes and prevents them from reaching the peripherals. The ASIC has always been responsible for moving the values for port reads and writes between the CPU and the peripherals, and checking if the current page is privileged or not is not a stretch to imagine at all. I just wish they had used less of a sledgehammer approach and specifically blocked access to the testing LED's port. I'm not clear why they would block every port.

Honestly, it is signed with a 2048 bit key. Not going to happen. Period. Unless TI releases anything, it isn't going to work.[/quote]
Hopefully, both TI and end users will be able to develop apps. However, you have a good point - it would be weird for TI to upgrade the apps to 2048-bit encryption and then release the key to allow users to develop apps. But we can always hope...

Sledgehammer approach indeed. I think it might have to do with some of the more 'low level tinkering' apps out there for the 83+ etc. line that include flash unlock exploits and are primarily focused with circumventing OS protections and such.

Although the actions of a few, these kinds of things can cost us dearly as a whole.

This is looking more and more like ASM and C development on this calculator will be like PRIZM development, with no direct access to the hardware and severely limited hybrid BASIC programming. This is most likely because of apps like PTTKiller.

For the time being I'm probably gonna wait a bit before buying the calculator to see how much freedom there is for third-party development on it. If it's too limited for BASIC coders then I might as well stick to the HP Prime and 84+CSE.

I feel like this will turn into a Ndless/Nspire OS sort of thing.
(Did I spell that right?)

There's an eminent possibility. Depends all on what TI does in the next few months. If it turns out that way we'll be mad, but we coders/hackers are a minority; TI can ignore us and still make plenty of money. We can hope they won't, but if locking the platform against development wasn't their goal, I don't see why the 2048-bit keys or ASIC issues.

A possible reading of that state of fact:
1) 2048-bit keys are the current minimum recommendation for RSA keys, especially given that we've entered the half-decade where the researchers behind the factorization of RSA-768 pretty much predicted (~"unlikely before 2015, but very likely before 2020") that a 1024-bit RSA key would be factored. (*)
In case the standardized exam testing regulation authorities ask for the size of the RSA keys (which are, after all, a protection they care about, and they are certainly aware of the "TI Signing Key Fiasco" episode), they would frown on TI using anything shorter than 2048 bits. In the Nspire series, it's been a while since TI switched from 1024-bit RSA keys to 2048-bit RSA keys.

2) completely removing direct ASM support would have generated far too much community backlash against the platform before it even hits the market, and far too much incentive to rip it open ASAP. Way too dangerous for TI EdTech's business model.

3) ASIC protections are clearly meant to be spokes in programmers' wheels, and their availability can be used to soothe standardized exam testing regulation authorities' worries: "look, we did something". Although it's likely that this protection will be largely as weak as those on other models, as much of a waste of time.


I know that nontrivial ASM programs have always been an incongruity on the TI-Z80 series (with Flash memory), due to the low amount of RAM and fairly efficient (in that it took many years for them to be reverse-engineered) protections on the size of ASM programs.
However - assuming the TI-eZ80 ASIC protections don't get too much in the way (and I expect things to go that way) - the long TI-68k (official) and Nspire (unofficial) experience has shown ASM programs are seriously good
Currently, the TI-eZ80 series is precisely in the same situation as the TI-68k series has always been, especially before we factored the public validation 512-bit RSA key and deduced the private signing key, after the TI-68k scene died anyway.
TI-68k FlashApps suck because of 1) signing requirements and 2) terrible toolchain, and one has access to "enough" RAM anyway (~180 KB available RAM heap space, maximum block size a bit less than 64 KB). Therefore, ASM programs is the solution used by nearly everyone on the TI-68k series.
TI-eZ80 FlashApps are not doable because of 2048-bit RSA key, and the TI-eZ80 series provides ~150 KB available RAM. Sidestep the problem by making mostly ASM programs ?

Sure, unless there is no execution protection for Flash memory, or it can be easily disabled (the TI-68k series has such a Flash execution protection; disabling it requires disabling the general Protection, and very few programmers ever leveraged the possibility of executing ASM programs from Flash memory), both code and data will be stored in RAM when executing, as opposed to only data with FlashApps. But that's how things have always been with ASM programs on the TI-68k series, and that didn't prevent the making of great programs (a number of which use self-modifying code), BTW

*: that is, factored by a public effort. It's likely that the state agencies of most of the largest countries already can factor a 1024-bit RSA key, because they have access to much higher computing power than academia, and therefore very much higher computing power than small groups of individuals like us.
More than five years after RSA-768 was factored, it remains the (public) record holder. An individual recently factored the equivalent of a 210-digit RSA key with Amazon EC2 for sieving and a 2x8-core x86_64 computer for post-processing, it cost him several thousand dollars over nearly a year. Some numbers sieved by NFS@Home's lasieve5 are equivalent to a 220-digit RSA key, and academic resources were used for post-processing. A 232-digit RSA key is harder still, let alone a 309/310-digit RSA key...

Cemetech's administration and I personally will staunchly not support that course of action.
I don't think that's an accurate analogy; the Prizm was only really limited in what it can be made to do by the lack of documentation. There is/was no hardware protection in place to stymie the developer community.

You have to understand that TI has a lot of facets to balance, and more importantly, that TI is a company of people. Some of those people see me, Cemetech's administration, and even you as allies, and these include people at high levels within TI. We have a number of advocates who have supported our work internally and feel that we overall bring more value to their devices. There are also people that are worried by some of the things we do, and the more the members of the community knee-jerk react to the directions in which it looks the technology will be going, the harder it is for our advocates to defend our work and the more examples those who doubt the value of the community have to point to.

ASIC protections are clearly (to me) meant as a sledgehammer approach to the problem of whether ASM programmers will be able to compromise the PTT mode. I believe the engineers understand that the current approach is overkill, but I think the individuals who work with the CollegeBoard and with teachers wanted to be absolutely sure that PTT couldn't be compromised.

Well-said. And the more we use the current ASM capabilities to show what the community can do (positively!) in terms of educational programs and games as well, and perhaps demonstrate why we need to write Apps, the more leverage I feel the community will have to negotiate writing Apps, accessing the LCD's ports, etc.