On Wednesday, we revealed that TI was removing ASM/C functionality from the TI-83 Premium CE in OS 5.5, and a TI response documented at TI-Planet subsequently confirmed that the TI-84 Plus CE will also lose ASM/C in OS 5.6. Unsurprisingly, the response here at Cemetech and elsewhere was overwhelmingly negative: although some expressed understanding of the pressures TI is under from exam boards and teachers, and others uncovered sensationalized videos suspected to be part of the impetus for this change, most expressed anger, disappointment, and betrayal.

I later spoke with Peter Balyta, President of EdTech at TI, and he understands that removing ASM functionality is a bitter pill to our community. He reaffirmed that this was a difficult decision, but one that was made out of an abundance of caution to prioritize learning for students and minimize any security risks.

He expressed hope that in lieu of ASM/C support, the community will be vocal in helping guide TI's development of Python support on an increasing breath of TI handhelds. Whether it's what would allow you to make powerful programs and games in Python as you would have done in ASM/C, or control and interface with hardware for physical computing (c.f. the Innovator and Rover), he is keen to hear the community's input. He is even open to hearing other ideas that could balance the needs of students, teachers, exam agencies and the desires of our developer community - please take advantage of this opportunity, and I/we will amplify what we hear.

There has been some brainstorming in the past few days among community members about (for lack of a better name) the TI-84 Plus CE Developer Edition. If we were to float that idea to TI, perhaps a calculator clearly and visibly distinguished from the TI-84 Plus CE that could be used on tests, what would you want from it? Opened up for ASM, C, and Python programming? Having the same specs as the usual TI-84 Plus CE, or something else? Having more features to help you connect hardware to it? And considering that TI is (after all) a business, would you buy one, and how many others do you think would? Beyond the community, who else could it be marketed to? Why would someone choose to buy the Developer Edition over a standard TI-84 Plus CE? Why would TI benefit by having it?

(Poor) Artist's Rendering
Personally, I don't think we need separate hardware (although Python would certainly be nice) since I don't think there will be enough people wanting two calculators, one for programs and one for exams. Instead, I believe it's much more reasonable to have a 'developer OS' that's distinguishable from the normal one. Perhaps an always red status bar could be the difference. As far as I know it's impossible even in ASM to keep a changed status bar color across screen refreshes so that'd make it tamper proof. The developer OS could also disable Exam Mode so there's no confusion there.

TI would benefit by community members having their own playground to continue focusing on making cool projects rather than focusing on finding exploits to get around TI's poor restrictions security.

In a perfect world: We would have OS 5.3.0 features with all the Python abilities of OS 5.5.0. It'd be awesome if TI could enable dual boot functionality so you could switch from one OS to the other easily.
That's an interesting take, TheLastMillennial. I share your concern that there wouldn't be enough people interested in a developer edition to make it worthwhile - although depending on how it was pitched and what specs it has, I could see it as a reasonable alternative to trying to get a Raspberry Pi + LCD + keyboard for an embedded Python development platform.

One of my personal wishlist items would be for them to figure out how to make graphics in Python not be so horrifically slow, whether that's at worst giving the Python libraries some sort of sprite caching and tileset abilities, or at best making the calculator just an ARM chip running an ez80 emulator or even just a TI-OS functionality emulator plus native programming abilities.
I find myself torn on this topic because I can see a "developer edition" calculator being a very cool entrypoint for students akin to the old days (early-2000s). However, students don't normally have the money to foot the bill on two different calculators especially when one can't be used on an exam. It would dilute the experience for me. I miss the "Whoa, that game looks sweet! Can you put it on mine?" social aspect of calculators in school.

Dual-booting is a very interesting concept that I would love to see expounded upon. How would we provide guarantees that one OS isn't the other? Something like would only last as long as that guarantee.

With regards to TI wanting the community to help advance the Python side of the house, I'm a bit sore about it. The community picked up these things because we were interested in them; to be relegate our efforts to Python feels like a bit of a forced march. I'm not opposed to it but I kinda don't want obvious incentives to work with it if that makes sense. I only want genuine curiosity to guide me.
I'm no expert but I don't think there'd be any good reason for them to start selling a whole other line of Developer Edition calculators. It's a cool idea, however if you think about the consumer base it is almost entirely students and teachers (most of which who barely know much more than how to graph something, and who likely have only ever touched the prgm key by accident) not developers. So for a company like them, I don't see it being profitable.

TheLastMillennial brings up a very good idea though, a developer OS would be very cool to have.
I can't see myself programming in Python only: without ASM, I probably won't do anything with these calculators. I also don't think that I would buy a developer edition calculator, because I would like to be able to do everything on the calculator I already have. I also am mad enough about this that I don't see myself ever buying another calculator from TI if they don't restore ASM functionality.

I propose a new solution: add an option in the settings menu to "allow ASM". With it on, PTT mode cannot be enabled. This means that we can both have our ASM, and TI can have whatever exam restrictions they want. If ASM can't run with testing mode on, that means the testing mode can't be disabled with ASM. And we would be able to run ASM under normal circumstances. I think this is a fair compromise. I don't think that releasing a developer OS is a good idea though, because most students would not have it, and therefore be unable to run ASM programs from the Cemetech archives, and because you would need to completely reinstall the OS to allow PTT mode.
As far as I can tell, the current test mode is sufficient as long as there are no arbitrary code execution bugs exploitable in test mode from the keypad & it does not allow running unsigned apps in test mode or any archive access. The boot code verifies the OS before allowing it to start test mode, so there should be no place for ASM to intervene. It could even back up RAM to flash & then restore it on exiting test mode, which would also prevent students taking test information with them.

Boot code security bugs could be patched if the boot code soft-locked itself before handing control to the OS instead of being OTP locked as it currently does. As far as I can tell, the only way to unlock the flash chip's soft lock is to power cycle it, which also resets the CPU & thus gives the boot code control. (If not, then never mind.)

Controlling the LED from ASM code or otherwise faking test mode can be mitigated if people are required to reset & enter test mode the official way at the beginning of the test. & if a teacher does not require test mode, that is already vulnerable to any OS bugs allowing arbitrary code execution.
Zeroko wrote:
if a teacher does not require test mode, that is already vulnerable to any OS bugs allowing arbitrary code execution.

We've been told several times that some teachers do not use/want PTT and make students reset their calcs instead.
Well, nothing on the current dual-headed setup is going to make Python usable, let alone fast, for lots of things which matter to both teachers and pupils Smile
TI totally blew a chance by choosing to embed into the TI-eZ80 Python models the same underpowered ATSAMD21 as in the desperate stopgap measure known as the TI-Python Adapter. At the very least, they should have used an ATSAMD51 instead, which has much more RAM (that's by far the most limiting factor), is faster and has more Flash (the thing you need to embed more modules in an efficient way). And even then, operations which require lots of communication between the eZ80 and the ARM coprocessor probably couldn't be made fast.

Let's just post two recent links showing how unusable TI's Python is, for anything but trivial usage, due to hardware limitations:
* https://ti-pla.net/t23854 : the Python heap on the TI-eZ80 series was already the smallest on the marketplace, now that NumWorks increased the heap in the N0100 & N0110 from 16 to 32 KB. Just import one of TI's charting add-ons and boom, you've just eaten three quarters of the Python heap - you can only write short invocations of that add-on before the Python interpreter embedded on the ATSAMD21 dies on you because it's out of heap;
* https://ti-pla.net/t23812 : the Python graphics library is ludicrously slow. Even without using machine translation on that article, it's easy to understand that setting pixels is nearly three orders of magnitude (!!) slower on the 83PCE EP than on its fastest competitors. Granted, a subsequent news item benchmarks a modified version of that script which leverages the non-portable line drawing functions added by TI, but even with those, the 83PCE loses to even the slowest competitors by a factor of two.

On TI-Planet, before NumWorks expanded the Python heap, a teacher and his students equipped with NumWorks calculators tried to make a periodic table (IIRC). They found that a 16 KB Python heap allowed only dealing with 2-3 KB of Python source code. Needless to say, that isn't enough to make an implementation of many types of programs useful for actual school usage, let alone a readable implementation thereof. Weird optimization tricks can be used to slightly reduce the heap consumption and therefore be able to shoehorn slightly more complex programs in an overly small box, but that's obviously not good for learning...

* for narrow-minded pure school-oriented math usage, Python on the current 83PCE EP & upcoming 84+ CE PE can't even be replacements for hybrid TI-BasicĀ (think function study programs, PineappleCAS, etc.);
* for narrow-minded school-oriented physics usage, Python can't be a replacement for hybrid TI-Basic (think periodic tables and anything whose source code exceeds only 2-3 KB !);
* for non-school things which do interest dozens of thousands of users, namely games, ala Oiram CE... ha ha ha, yeah, try imagining anything like that in 3 KB of Python code Smile

TL;DR: removing access to native code seriously hampers even school usage, because Python is unusably limited on the 83PCE EP (and undoubtedly the soon upcoming 84+CE PE). To add insult to injury for users, removing access to native code will not improve exam security (in fact, the move will worsen exam security).

The limitations I've described above could be alleviated by better hardware, but even on the Nspire CX II, I'm not convinced the upcoming Python implementation can be fast enough to make an equivalent of such popular software as Oiram CE. Python does not have a reputation for being fast, especially when no JIT is used.

Now, as for the idea of making a developer edition of a TI-eZ80 calculator... not that I think that it is bad, but... NumWorks has already made calculators whose schematics are documented publicly, which are not more expensive than the current TI-eZ80 models (despite NumWorks using lower margins than TI due to lower volume), and whose 32-bit ARM Cortex-M processors are much more powerful than any poor little 8-bit eZ80 microcontroller can ever be. Just saying.
IOW, the ARM norm should be embraced by TI ASAP, the (e)Z80 hardware should be put to good rest at last. Note that in that case, TI doesn't even have to let go of the entire legacy (e)Z80 software right away: on older HP calculators, there's precedent using an ARM processor to emulate an older processor, the Saturn, which was probably weirder in some aspects than the eZ80 is.

I've also read elsewhere about the idea of two OS versions (before reading the above posts and editing this message):
* the normal one, with exam mode and whatnot stupid arbitrary functional restrictions mandated by the stupid people regulating stupid standardized tests, lack of access to native code seemingly being one of them;
* the developer one, without exam mode but with access to native code.
That's also interesting in theory, but it requires full reflashing right in the exam rooms. That's a better solution than the current insecure exam mode (which should never have been a thing if standardized testing regulators had been remotely competent in computer security), but creates practical complications which are probably annoying enough to just prefer fully banning calculators instead. Setting the PTT mode is already too hard for some, as mentioned above, so reflashing a single model of calculators right in the exam room, er...
I had a section here about Python, but the sentiment of it was expressed by Lionel Debroux; basically the Python Edition's implementation of Python is too slow to be viable as a replacement for ASM or C.

I agree with Raylin that part of the appeal of programming and putting programs on your calculator is there are other people at school that have the same calculator, and if you have a link cable transferring programs is super quick. Since it is also possible to send an OS to a friend that wants to try out those cool games, TLM's idea of a separate OS seems like a good option to continue to allow ASM in some way.

Also, in my high school experience, very few people actually update their OS, as most teachers do not require it. A RAM reset is the extent of what teachers I've had will do, and we all know that is laughably easy to bypass.
Although I think the idea of a developer edition calculator would be exceptionally cool, I doubt it would be considered reasonable by TI. I guess if its the same hardware as the current CEs, they could probably produce and sell them without breaking the bank, but I don't think there is a big enough market to really justify it. If they would do it, I would certainly buy one, perhaps they could write something along the lines of "NOT AUTHORIZED FOR STANDARDIZED EXAMINATIONS" on it. While they're at it, why not even remove the OS validation and app signing on it if their goal is to make it developer-friendly. If it were marketed towards a general hobbyist/maker audience rather than the student market, I could see it gaining a bit of traction. I think it would go a long way towards appeasing the community, with which they have had a pretty rocky relationship to say the least.
On the question of switching to Python, as it stands, it just isn't a replacement for native code, heck the code barely runs at all.
I think that a developer version of the OS would be a good idea and would make it so that there is no point in having a never-ending exploit war similar to what happened with the nspire series. However, I can see how it might get dicey for examiners to check each calculator for OS versions/flavors, and I guess technically it opens the door for more cheating. Much like Jeffitus and Raylin, what got me hooked on calculators in the first place was sharing games and cool programs with classmates in high school. Like many of the people on here, this is what caused me to pursue a degree in computer science and become a developer. I don't see that happening as much if most students have the regular locked-down version that won't run all those cool home-brew projects.
Regarding moving to an ARM processor, I think part of what makes calculators interesting/cool is the hardware limitations and maybe even the lack of documentation, forcing us to experiment and discover in a very technical way. If someone wants to write python on an arm processor, they can just get a raspberry pi, but to me, that just doesn't have the same vibe as a calculator.
The answer seems pretty clear to me. Because the removal of 3rd party assembly is just a software change (so far), there's no reason to make a "developer edition" calculator whose hardware is identical to the standard model. Instead, TI should make the usage of assembly an option that can be disabled in a Test-Mode-like manner, where an "ASM" text can be read in the hotbar at the top at all times alongside trig and graphing modes. This means that all 3rd party assembly functionality, including running arbitrary hex and running assembly programs can be disabled until the calculator is connected to TI-Connect, similar to Test Mode in its current implementation.

This approach, while technically not being unhackable, still accomplishes TI's main goals: making teachers and prospective customers happy about the calculators' testing integrity and preventing the vast majority of students from running malicious programs on calculators used for testing. All while never actually removing assembly.

I see TI's decision to remove assembly akin to them trying to remove logBASE( or the equation solver, instead of just locking it behind test mode. They're removing features that are truly valuable to students, professionals, and programmers in return for some false security.
The issue there is that, with assembly, it would likely be possible to remove that text, making it pointless. Additionally, you would also have to train teachers about what ASM means. Considering that a decent percentage of teachers don't even know about test mode or archived programs, that seems quite difficult.
commandblockguy wrote:
The issue there is that, with assembly, it would likely be possible to remove that text, making it pointless. Additionally, you would also have to train teachers about what ASM means. Considering that a decent percentage of teachers don't even know about test mode or archived programs, that seems quite difficult.

But the folly there is thinking that this was ever about real security. What I'm proposing is not much less secure than what they've done, because I am 100% positive that a backdoor will be found every time TI tries to keep us from running assembly. What I'm proposing is a way for TI to parade the security theater they see as profitable, while not harming their end users.
For multiple reasons, I don't expect a developer edition of a TI-eZ80 calculator to come up to fruition. However, let's be honest, for users' sake, I'd love to be proved wrong, however unlikely that is. So let's try to play the game a little bit...

IMO, a TI-eZ80 "DE" needs to outflank the existing TI-eZ80 models in every possible way, fixing the well-identified limitations. This means:
* fastest possible Z80 mode execution by using single-cycle access (no wait states, no speed-destroying delays of any sort) for RAM, VRAM and Flash - and why not higher-clocked versions of the eZ80, too. I'm aware that an independent reimplementation of that ISA, which may be necessary to achieve this aim, would be quite a bit more costly, unless there's already something along those lines, in production state, on e.g. LibreCores;
* 1 or 2 MB of RAM, 8 or even 4+8 MB of Flash - in the addressing space, even 2 MB should be enough for VRAM (including double- or triple-buffering) and other MMIO, right ?
* a faster ARM coprocessor (> 100 MHz) with much more RAM (256+ KB) and Flash (1+ MB);
* better integration and much more efficient communication between the eZ80 processor and the ARM coprocessor;
* 2D acceleration usable by both the processor and the coprocessor, with a DMA if need be... making graphics fast, I mean.

However, as I mentioned above, for me, the better solution for a mid-range developer calculator is probably to let go of eZ80 hardware and the overhead of synchronization with a coprocessor, effectively creating a single-processor Nspire lite / super NumWorks N0110 calculator:
* 400+ MHz Cortex-M7, SPFP+DPFP hardware support, ICache + DCache, 2D graphics acceleration - IOW, enough oomph to emulate the eZ80 platform, make Python fast enough, etc.;
* 2-4 MB of RAM (the small RAM of the N0110, 256 KB, is probably its most annoying limitation in practice), 16-32 MB of 100 MHz+ XIP Flash;
* RS232 TTL port (like the Nspire), USB host support (unlike the N0100 & N0110).

Of course, a Nspire-lite / super N0110 calculator would reduce the usefulness of buying a higher-end model...
Note that for exams' sake, a 2 MB RAM, 16 MB Flash calculator is harder to stuff with advanced documents and advanced document viewers than a Nspire CX I / II or a Prime G1 / G2. Not that I think that stuffing lots of documents into a graphing calculator is useful for... just about any exam I can think of, or that I think that it's desirable to restrict calculators to 2 MB RAM + 16 MB Flash for the sole reason that users can't stuff such calculators too much. Artificial restrictions (to functionality levels way below the modern standards, at that) always bite some usage types.
However, as a matter of fact, such hardware specs (not any less, please please please !) are probably a reasonable tradeoff between the current middle-end market range (TI-eZ80, N0110, fx-CG50 / Graph 90+E) and the high-end market range (Nspire CX I & II, Prime G1 & G2). 2 MB RAM + 16 MB Flash still leave some room for spending some time on optimizing stuff and trying to outdo oneself trying to cram stuff which people didn't think was possible / reasonable on the platform.
KermMartian wrote:
He expressed hope that in lieu of ASM/C support, the community will be vocal in helping guide TI's development of Python support on an increasing breath of TI handhelds. Whether it's what would allow you to make powerful programs and games in Python as you would have done in ASM/C, or control and interface with hardware for physical computing (c.f. the Innovator and Rover), he is keen to hear the community's input. He is even open to hearing other ideas that could balance the needs of students, teachers, exam agencies and the desires of our developer community - please take advantage of this opportunity, and I/we will amplify what we hear.

Keen to hear the community's input he says?

Dear Peter Balyta,

Python on the TI-83 PCE/TI-84 Plus CE is a squeaky toy. Its potential is bottle-necked so hard that even TI-Basic in many ways is an upgrade:
  • Performance is bad. It's the slowest Python implementation in a calculator. From TI-Planet's numbers, just about the only calculator that's roughly as slow is a Casio Graph 35+E, a monochrome calculator, and only mostly on integer benchmarks.
  • Memory capacity is ridiculously tiny. TI-Planet measured 17 KiB of heap on the latest firmware and it actually shrunk by 2 KiB when compared to the previous firmware. Simply importing one pre-loaded ce_* Python script will cut that in half. In general, running a script will require at least about one to three times its size in heap, more if it manipulates significant amounts of data. Therefore, TI's Python will choke much, much quicker than the competition on large, complex programs. Teachers and students that try to write something that would not fit on an original 1977 Commodore PET will quickly hit out of memory errors. What will happen when they see that other calculators don't?
  • Graphics performance in particular is simply atrocious. TI-Planet clocked the put_pixel() fill rate at 48 pixels per seconds. The next two best calculators are 100x to 200x times faster. The next one is 1000x times faster. Forget about gLib, how can anyone be expected to write a simple ray-tracing or fractal script on-calc when it'll take nearly half an hour just to push the pixels out? Even when using TI's proprietary ti_graphics primitives it's still several times slower than the competition's put_pixel().

So TI has arguably the worst Python implementation in a calculator so far. This does not even take into account that Python is both at least an order of magnitude slower and much more memory-hungry than C/ASM. That's important not only for video games and emulators, but also for any application that crunches numbers: fractals, 3D plotting/rendering, Monte Carlo experiments... I won't bother explaining about extending the abilities of the calculator since so far it's the calculator that's extending the lackluster abilities of TI's Python.

There's also the growing concern of the legacy of the TI-81 platform. It's nearly 30 years old. The ez80 gave it a new lease on life, but without a modern toolchain it's still one foot in the grave. Say, it'd be a shame if a member of the community was working on an open-source ez80 LLVM backend for free with the explicit goal of running complex C programs on a TI calculator (https://github.com/jacobly0/llvm-project)... Oh wait, Jacobly is doing just that and now why would anyone in the TI community finish this since C is dead on their platform? Congratulations TI, you've just killed your one inexpensive shot at both fixing your Python implementation through a native port to the ez80 and solving a big technological obsolescence concern of your calculator platform. Have fun writing an ez80 emulator to pull a HP-50G, finishing a LLVM backend yourself or designing a new midrange graphical calculator from scratch when the weight of the TI-81 finally breaks your goose that lays golden eggs. I'm especially curious to see how you plan to outperform productivity-wise a competitor that happens to use legacy-free toolchains and modern C++.

If TI is really listening, then backpedal on this FAST. This company just pissed off a lot of smart people that know their calculators inside and out and saying that TI's Python is a replacement only adds insult to the injury. To say that this will not end well for both TI and their community is a major understatement.

Finally, what happens when you embrace power users and open up your platform? NumWorks. I personally contributed the initial implementation of the turtle Python module, which probably made every other competitor sweat for a couple of months since everyone scrambled to get theirs. Embrace your community. Good things for you come out of them.

The only TI calculator I own is a TI-82 Stats.fr. It will be the only TI calculator that I and everyone's who's asking for my input will ever own since TI clearly does not care nor value their community and end-users. I can't be the only one who will discourage people from buying your products. It will take a lot of actions done in good faith from TI to change my mind.

Not presently a member of your community, but you messed up so bad this time I wrote this.
inb5: Why don't we just make a community-made calculator?

(For reference, this has been approached many times over the years, and I still think it would be cool.)
I don't think that flaming the company or the people in it is the way to go here. Nothing good would come out of that, besides making the community look less than reasonable.

I have not been staying updated with this news all that much- the last time I looked at anything related to this was when I posted in the other thread, and I still hold to what I said.

We also don't know what's happening inside the company right now. For example, with some schools moving to mostly online courses, online calculators are now a serious competitor, and they're free. I myself reach more often for WolframAlpha than the CE on my desk for simple computations. Removing this support would allow the calculator division to focus on improving the part of their calculator that actually has potential use in the education market.

This is incredibly saddening, especially with some people in this community working so hard recently on LLVM, etc, but let's not allow our sadness to turn into anger.

I think the fact that TI has maintained contact with leaders in their communities is really awesome. Let's keep in mind that TI announced this in advance and is extremely generous in sharing tech demos and more with TI-Planet. I don't want this fact to be overshadowed- TI clearly cares a lot about its community (even if the email of the same name is less than helpful sometimes).
Zeda: https://symbolibre.org/en/ ? Smile
The NumWorks calculators would be another starting point.

Maybe it's a cultural difference, but boricj's post seems far from being overtly disrespectful to me. Also, as long as the argumentation is based on facts - and it definitely is - I'd expect any well-meaning person to focus more on the meaning than on the wording Smile
Put another way: if I wanted to really ruffle Peter Balyta's feathers, believe me, I'd do it differently from JB's post, so the same certainly holds for him Wink
_iPhoenix_ wrote:
I don't think that flaming the company or the people in it is the way to go here. Nothing good would come out of that, besides making the community look less than reasonable.

Is it about my post? They requested feedback. I can't help if expressing facts in a calm, constructive criticism of the shortcomings of their implementation of Python, their calculator platform and the consequences of their acts with facts and numbers does not put them on a pedestal. The highlighting of my main points in bold is not yelling by the way.

I am biased. Obviously. I have a NumWorks calculator and I enjoy messing with it. However, I believe that I wrote a fair post that happens to not be sugar-coated. I did a similar piece (which was slightly more strongly-worded) for NumWorks' choice of licence for epsilon and they've changed it after the community said "no, it's been a year, you REALLY have to fix this now".

If people consider what I wrote "flaming" then no wonder TI thinks they can get away with this scott-free...
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